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

[burek]

[00:07:13 CEST] <gnafu> llogan: no
[00:11:57 CEST] <Timothy_Gu> Rewriting a fate server should be a gsoc or outreachy task
[00:13:17 CEST] <llogan> gnafu: ok!!!
[00:14:24 CEST] <llogan> Timothy_Gu: feel free to add it to some Wiki page. maybe a generic tasks ideas page would be use(ful|less)
[00:15:42 CEST] <Timothy_Gu> llogan: no I already finished writing it
[00:16:18 CEST] <llogan> ok. i don't pay attention to stuff apparently.
[00:16:31 CEST] <Timothy_Gu> llogan: currently serving at http://fate.ffmpeg.org:8080/ (baptiste hasn't set up proper nginx stuff yet)
[00:18:01 CEST] <Timothy_Gu> speaking of which
[00:18:17 CEST] <llogan> Timothy_Gu: would you qualify as a student for these various projects?
[00:19:51 CEST] <Timothy_Gu> llogan: nope (i'm too young)
[00:20:11 CEST] <Timothy_Gu> (and I'm not female or transexual/genderqueer)
[00:21:08 CEST] <nevcairiel> I think outreachy is just weird, isnt it a kind of discrimination to only accept certain kind of people =p
[00:24:36 CEST] <llogan> looks nice so far. that's quite a brigt yellow though. maybe something like FFEE70 would be nice
[00:43:17 CEST] <Prelude2004c> hello everyone
[00:44:10 CEST] <Prelude2004c> still looking for a solution.. can someone help point me in the right direction.. i am trying to understand if there is something wrong with ffmpeg or something else. ... ffmpeg -i <1 input > -c:v output1 -c:v output 2, etc etc ... i get a max of 120fps
[00:44:40 CEST] <Prelude2004c> if i run all 5 outputs i get only 120fps .. if i run 5 seperate ffmpeg instances i get full fps 60fps * 4 ( 300 fps )
[00:44:45 CEST] <Prelude2004c> does anyone know why thats possible
[00:44:49 CEST] <kierank> yes probably an ffmpeg issue 
[00:45:02 CEST] <kierank> you've asked about 50 times now
[00:46:21 CEST] <Prelude2004c> i know hopping someone new here will have an answer :)
[00:46:39 CEST] <Prelude2004c> can anyone help disagnose it.. i am not a programmer so.. not sure how to fix it
[00:46:43 CEST] <llogan> did you try ffmpeg-user mailing list?
[00:47:11 CEST] <kierank> Prelude2004c: open a  ticket
[00:47:14 CEST] <jamrial> nevcairiel: i ask again in case you missed the question earlier today, are you ok with the libdcadec patch in the ml?
[00:49:29 CEST] <baptiste> Timothy_Gu, sorry about the delay
[01:01:37 CEST] <iive> Prelude2004c: most likely ffmpeg runs all streams in the same thread and you are not using encoder that is thread optimised.
[01:02:19 CEST] <Daemon404> jamrial, is there no api bump needed for that dcadec flag?
[01:02:26 CEST] <Daemon404> i mean teh dcadec ver requirement
[01:03:37 CEST] <jamrial> no, it's been there since the beginning
[01:03:50 CEST] <jamrial> also, the library has no version defines at all :p
[01:03:57 CEST] <Daemon404> ah ok.
[01:04:03 CEST] <Daemon404> lo lreally?
[01:04:05 CEST] <Daemon404> not even in the .pc?
[01:04:33 CEST] <jamrial> only an arbitrary 0.0.0 Timothy_Gu came up with
[01:05:55 CEST] <jamrial> https://github.com/foo86/dcadec/issues/6 it's on the author's to-do list
[01:06:24 CEST] <Daemon404> ic
[01:06:39 CEST] <Daemon404> that foo86 guy really came out of nowhere
[01:07:32 CEST] <Prelude2004c> isn't nvenc thread optomized ?
[01:08:06 CEST] <Prelude2004c> can't be nvenc because i tried with just h264 cpus and it was fine too
[01:08:10 CEST] <Prelude2004c> i mean sorry not fine
[01:08:18 CEST] <Prelude2004c> so its not the encoder because 2 different ones do the same thing
[01:11:17 CEST] <kierank> http://www.mremoteng.org/
[01:11:19 CEST] <kierank> this is quite good
[01:12:36 CEST] <Daemon404> in inherently mistrust freeware
[01:16:20 CEST] <kierank> ?
[01:16:22 CEST] <kierank> it's open source
[01:16:30 CEST] <kierank> https://github.com/rmcardle/mRemoteNG
[01:17:03 CEST] <Daemon404> oh
[01:17:11 CEST] <Daemon404> i clicked contribute and it asked me for bitcoins.
[01:17:36 CEST] <Daemon404> apparently im an idiot and missed 'source code'
[01:29:31 CEST] <iive> Prelude2004c: nvenc is quite recent, external and I remember something about 2 streams limitation.
[01:36:28 CEST] <polygraphed> i have an xbmc machine running my television. but this isn't the right software for what i want. i want for the tv machine to represent its queue as a filesystem having files like 'currently_playing'. this way copying data to this host and telling it which data to play can be the same action. does any of this sound familiar? 
[01:44:22 CEST] <polygraphed> i guess what i'm asking is: can i do something like ffmpeg -i ./ -o /dev ?
[01:51:36 CEST] <Timothy_Gu> nevcairiel: same
[01:52:21 CEST] <Daemon404> Timothy_Gu, i am surprised you did not apply for gsoc
[01:52:25 CEST] <Daemon404> surely you qualify?
[01:52:43 CEST] <Timothy_Gu> llogan: looks good
[01:57:23 CEST] Action: kierank wonders whether to resurrect hall of shame
[01:59:39 CEST] <Timothy_Gu> Daemon404: no im too young
[02:01:19 CEST] <Daemon404> o
[02:01:37 CEST] <Timothy_Gu> post-secondary student developers ages 18 and older stipends im neither
[02:54:52 CEST] <Prelude2004c> we got around with the 2 stream limit by using the k4000 series stuff
[02:55:07 CEST] <Prelude2004c> that's not the issue. i think its a code issue on ffmpeg
[03:02:07 CEST] <selsta> can someone help me writing to memory with avio_open() instead of to disk? do I need to do anything else apart from allocating my own AVIOContext?
[03:02:43 CEST] <selsta> reading from memory with avformat_open_input() works fine
[03:03:25 CEST] <Daemon404> selsta, you dont need to
[03:03:29 CEST] <Daemon404> there isa built in func
[03:03:57 CEST] <selsta> Daemon404: I dont need to do what exactly?
[03:04:05 CEST] <Daemon404> http://ffmpeg.org/doxygen/trunk/avio_8h.html#adb5259ad07633518173eaa47fe6575e2
[03:04:20 CEST] <selsta> oh nice
[03:10:28 CEST] <selsta> is the useage then the same as with a file from disk? avformat_write_header() segvaults, even tho avio_open_dyn_buf returns no error
[03:15:56 CEST] <selsta> found the error: I did not set ofmt_ctx->oformat
[03:25:35 CEST] <selsta> yay, my program finally works.
[03:27:45 CEST] <cone-803> ffmpeg 03Ferdinand Oeinck 07master:eff72a6c7375: libavcodec/hqx: multi threading support
[03:38:30 CEST] <cone-803> ffmpeg 03James Almer 07master:3553b815f66c: avcodec/libdcadec: honor AVCodecContext bitexact flag
[04:28:26 CEST] <Timothy_Gu> goddam nginx caching is FAST (on an SSD that is)
[08:30:59 CEST] <Timothy_Gu> michaelni: your aarch64 machine is dead: http://104.131.148.213/report/aarch64-linux-qemu-ubuntu-gcc-4.8/20150409171115
[09:44:49 CEST] <thardin> https://www.thebroadcastbridge.com/content/entry/2472/sky-and-ebu-endorse-novel-compression-technology-with-claims-to-double-hevc  what do you guys make of this?
[09:45:16 CEST] <nevcairiel> is that the perseus thing?
[09:45:22 CEST] <thardin> yes
[09:46:05 CEST] <nevcairiel> i dont think anyone is going to oppose a new codec if it can deliver what it promises, but many companies made similar claims before...... :)
[09:46:22 CEST] <j-b> and none delivered
[09:46:37 CEST] <j-b> although, some good ideas in HEVC were not merged into the standard
[09:47:20 CEST] <nevcairiel> from what I understand they were worried about increasing computational complexity too much?
[09:49:37 CEST] <thardin> on2 comes to mind
[09:50:19 CEST] <j-b> nevcairiel: sure, but someone could have picked some ideas
[09:50:57 CEST] <thardin> the claim that mpeg2 stbs can decode it is a bit iffy
[09:51:02 CEST] <nevcairiel> didnt perseus also claim that it decodes faster?
[09:51:46 CEST] <kierank> you can find their patents if you look hard enough
[09:52:00 CEST] <thardin> near the end of the article there's a bit that implies it may have explicit contrast/lightness coding (like CELT, but elsewise)
[09:52:07 CEST] <nevcairiel> i only hope they also open the spec if it  really comes to being used by big commercial media
[09:52:24 CEST] <thardin> which daala is doing as well (I think)
[09:56:47 CEST] <TimNich> I thought the word "novel" implied a work of fiction.
[10:06:40 CEST] <TimNich> where do you stuble across these kierank ?
[10:07:39 CEST] <kierank> TimNich: people telling me usually
[10:09:12 CEST] <j-b> thardin: haha, that's a joke, right?
[10:10:03 CEST] <thardin> dunno?
[10:10:09 CEST] <j-b> the mpeg2 part
[10:10:38 CEST] <thardin> that's what one of our sales people said they said at some convention
[10:10:48 CEST] <kierank> http://companycheck.co.uk/company/07888208/V-NOVA-INTERNATIONAL-LTD/group-structure
[10:11:00 CEST] <kierank> https://www.google.co.uk/search?q=LUCA+ROSSATO+patents&oq=LUCA+ROSSATO+patents&aqs=chrome..69i57.3288j0j7&sourceid=chrome&es_sm=0&ie=UTF-8
[10:11:01 CEST] <j-b> "can generate a single stream that incorporates different levels of encoding"
[10:11:07 CEST] <kierank> not rocket science to find out what they are doing
[10:11:23 CEST] <thardin> but that may have been a miscommunication
[10:12:05 CEST] <kierank> s/a miscommunication/marketing
[10:12:16 CEST] <kierank> don't let facts get in the way of good marketing
[10:12:21 CEST] <kierank> wm4: ping
[10:12:31 CEST] <saste> rcombs, I suppose your patch is supposed to help with mkv segmentation, right?
[10:12:38 CEST] <saste> do you have a command to test here
[10:12:55 CEST] <saste> something which doesn't work fine without the patch
[10:14:02 CEST] <wm4> kierank: pong?
[10:14:03 CEST] <rcombs> saste: ffmpeg -i <input> -f segment -segment_format matroska -segment_time 1 -segment_header_filename matroska_test/header.mkv -c copy matroska_test/segment-%05d.mkv
[10:14:20 CEST] <kierank> wm4: so what are the priorities for api fate tests
[10:14:27 CEST] <kierank> see the flac test the student wrote
[10:15:04 CEST] <wm4> kierank: what do you mean? which APIs should be tested?
[10:15:15 CEST] <kierank> which ones should be written first
[10:15:22 CEST] <kierank> h264 imo
[10:15:22 CEST] <rcombs> saste: I was just looking at your segment patches on the ML yesterday, and wondered what the use-case for the never-split mode was?
[10:15:28 CEST] <wm4> I'll look at that patch closer once I finished writing my troll post
[10:15:54 CEST] <saste> rcombs, my use case was to be able to split by size or by chapter
[10:16:17 CEST] <saste> rcombs, i wanted to rip a CD using a single command, and putting each chapter/song in a single track
[10:16:30 CEST] <saste> without to rely on scripting
[10:17:08 CEST] <saste> the libcdio demuxer treats each track as a separate chapter
[10:17:16 CEST] <rcombs> ah, interesting
[10:17:24 CEST] <rcombs> I saw that patch as well but didn't make the connection
[10:22:46 CEST] <saste> rcombs, the logic behind the never-split mode is: with -segment_expr I'm using an expression to detect when to split, and I don't want it to conflict with the -segment_time option
[10:22:57 CEST] <saste> so I need some way to disable -segment_time from splitting
[10:23:21 CEST] <saste> the problem is that it breaks backward compatibility, so it's a bit controversial (that's why I didn't commit it yet)
[10:23:50 CEST] <ubitux> damn i'm missing the drama around libquvi
[10:23:57 CEST] <saste> rcombs, about your patch, how do I use segments and header to get a playable file?
[10:23:57 CEST] <ubitux> even though i'm the author of it...
[10:23:59 CEST] <ubitux> sorry guys.
[10:24:01 CEST] <ubitux> :D
[10:24:13 CEST] <saste> ubitux, why libquvi is still working?
[10:24:30 CEST] <ubitux> i dunno, i can't build it anymore anyway
[10:24:43 CEST] <rcombs> saste: concatenate the header and any consecutive sequence of segments
[10:24:44 CEST] <saste> even now that bigG disabled most downloader plugins?
[10:24:53 CEST] <ubitux> since my distro is distributing 0.9 exclusively
[10:25:01 CEST] <ubitux> and ffmpeg support the 0.4 (before license change)
[10:25:05 CEST] <ubitux> (iirc)
[10:25:27 CEST] <ubitux> i'll send a patch to drop libquvi support when i'm back
[10:25:39 CEST] <nevcairiel> ooh more drama!
[10:25:41 CEST] <rcombs> saste: any particular reason to change the default?
[10:25:45 CEST] <ubitux> (in about 10 days, wait for 2 weeks)
[10:25:48 CEST] <rcombs> saste: other than that, looks good
[10:27:24 CEST] <saste> rcombs, suppose that i want to use an expression to split, now I have to disable the segment_time, right now this is impossible
[10:27:38 CEST] <saste> having a default of "never split" helps with -segment_expr
[10:27:56 CEST] <nevcairiel> that doesnt have to  be the default though
[10:28:00 CEST] <saste> also it's not very intuitive to have an arbitrary value of 2 seconds as default
[10:28:27 CEST] <rcombs> saste: I'd have something like `if (segment_expr) seg->time = -1;`
[10:28:31 CEST] <rcombs> saste: yeah, that is pretty weird
[10:29:14 CEST] <rcombs> I don't have a strong opinion either way, since the default is probably not used much
[10:29:18 CEST] <saste> rcombs, anyway, I'm testing your patch and seems sane, but I think we must work some documentation so people know how to use it, and which use case it covers
[10:29:21 CEST] <saste> now i'll review the code
[10:29:28 CEST] <rcombs> cool, thanks
[10:30:47 CEST] <rcombs> oh, or just put `if (seg->segment_expr)` first
[10:32:32 CEST] <saste> rcombs, but, I also want to allow an OR logic, so if I specify -segment_time 10 -segment_expr EXPR the muxer will split IF segment time is 10 OR the expression is true
[10:32:49 CEST] <rcombs> ah, interesting
[10:33:11 CEST] <nevcairiel> shove that logic into your expression? =P
[10:33:28 CEST] <saste> nevcairiel, not very user friendly, but yes that's a possibility
[10:34:58 CEST] <rcombs> saste: so, the patch doesn't do that now, but could in the future?
[10:35:17 CEST] <saste> rcombs, what patch?
[10:35:31 CEST] <rcombs> yours
[10:35:32 CEST] <rcombs> [WIP] add support to segmentation expression
[10:35:33 CEST] <saste> rcombs, with the complete patchset it will work as I described
[10:36:01 CEST] <saste> the other thing which I'm not sure about is the copy chapter metadata to segment
[10:36:12 CEST] <saste> probably  a dedicated option should be used instead
[10:36:51 CEST] <rcombs> yeah, an option would be good there
[10:39:29 CEST] <rcombs> looks to me like segment_time is ignored when segment_expr is present?
[10:41:41 CEST] Action: rcombs removes the earwax^Hlow-pass filter from his earbuds
[11:00:04 CEST] <ubitux> michaelni: i'll review the sami/srt thing patches, please don't apply before i review
[11:07:38 CEST] <rcombs> wm4: well said, re: ML post
[11:57:48 CEST] <wm4> kierank: so, uh, you have no clear idea yet how exactly API tests should work?
[11:58:03 CEST] <kierank> well yes I want them to go into fate
[11:58:07 CEST] <kierank> and produce the same framecrc stuff
[11:58:09 CEST] <kierank> api_h264
[11:58:19 CEST] <kierank> api_flac
[11:58:19 CEST] <kierank> etc
[11:58:24 CEST] <wm4> ok
[11:58:43 CEST] <kierank> I think it's ok for the student to reuse framecrc
[11:59:28 CEST] <kierank> wm4: but I would personally say h264 is the one where the student should start
[12:00:00 CEST] <kierank> I also guess the codec could be passed as a command line or something
[12:00:03 CEST] <kierank> ./api_test h264
[12:00:05 CEST] <kierank> or whatever
[12:00:57 CEST] <wm4> kierank: the student is in hurry to finish the task tomorrow?
[12:01:02 CEST] <wm4> or even today
[12:01:05 CEST] <wm4> crazy deadline
[12:01:13 CEST] <kierank> no i don't think so
[12:01:20 CEST] <kierank> they can continue until the 27th afaik
[12:01:24 CEST] <kierank> because 27th is the due date
[12:01:26 CEST] <wm4> oh, good then
[12:01:49 CEST] <wm4> was that another student yesterday or am I just making shit up?
[12:01:53 CEST] <kierank> the capability to just write a simple test with the api is more than all the applicants
[12:02:02 CEST] <kierank> wm4: name?
[12:02:57 CEST] <wm4> vibr
[12:03:07 CEST] <kierank> haven't heard from him/her
[12:03:42 CEST] <loki_> what you are taking about? what students? there is unvirsity of ffmpeg or something?
[12:05:08 CEST] <kierank> gsoc and outreachy
[12:06:28 CEST] <wm4> I already feel sorry for the student
[12:06:35 CEST] <wm4> the API examples are somewhat buggy
[12:08:03 CEST] <wm4> and I wish claws-mail would stop corrupting its own database
[12:50:40 CEST] <cone-166> ffmpeg 03Michael Niedermayer 07master:599dc8fee18f: avcodec/hqx: Use av_clip_uintp2()
[13:13:12 CEST] <cone-166> ffmpeg 03Shivraj Patil 07master:8af3ce53786d: configure: add support for mips32r5, p5600 cpu and msa
[13:13:13 CEST] <cone-166> ffmpeg 03Shivraj Patil 07master:076bfe96128f: configure: add support for mips64r6 and i6400 cpu
[13:13:14 CEST] <cone-166> ffmpeg 03Shivraj Patil 07master:7fdd31421cfe: configure: add support for 74kf cpu
[13:13:15 CEST] <cone-166> ffmpeg 03Shivraj Patil 07master:578d99e7c6d1: avutil/mips/intreadwrite: build fix for mips64r6 (instruction 'lwl' not supported)
[13:50:32 CEST] <cone-166> ffmpeg 03Carl Eugen Hoyos 07master:7b39d853b88e: lavf/flac: Autodetect raw flac files.
[13:50:33 CEST] <cone-166> ffmpeg 03Michael Niedermayer 07master:5d0f836f6270: Merge remote-tracking branch 'cehoyos/master'
[14:26:25 CEST] <cone-166> ffmpeg 03Himangi Saraogi 07master:aae9f52c4efa: avformat/rtsp: Fix unchecked return value
[14:53:48 CEST] <cone-166> ffmpeg 03Himangi Saraogi 07master:8d15de7eb265: ffmdec: Check return value of ffm_append_recommended_configuration
[17:41:19 CEST] <kierank> "I for one wish we had this functionality in FFmpeg [at least basic HTTP server]."
[17:42:45 CEST] <BtbN> Throw it into a cgi script and invoke it via apache/lighttpd. ;)
[17:43:02 CEST] <Daemon404> NO WE NEED IT IN LIBAVGRABGEDUMP
[17:43:06 CEST] <Daemon404> garbage*
[17:43:32 CEST] <BtbN> Hm, libavmisc wouldn't be that bad for stuff like this.
[17:44:02 CEST] <michaelni> BtbN, how should hls and http client code be tested ?
[17:44:35 CEST] <BtbN> http client is perfectly fine like it is
[17:45:16 CEST] <michaelni> yes but its being tested in fate
[17:45:23 CEST] <michaelni> its NOT being tested
[17:45:30 CEST] <wm4> the holy scriptures demand that all be in a single repo, with libavcodec, libavformat, libswscale (... skipping to paragraph 10 ...), and no other repos or libs shall exist, for the libs for holy
[17:45:35 CEST] <wm4> s/for/are
[17:46:39 CEST] <BtbN> I'm confused
[17:47:04 CEST] <kierank> anyway if ffmpeg gsoc involves a http server I think I will fork
[17:47:47 CEST] <nevcairiel> that is one of the tasks which a student works on
[17:48:07 CEST] <kierank> I am aware
[17:48:14 CEST] <kierank>  "I for one wish we had this functionality in FFmpeg [at least basic HTTP server]." is from melange
[17:49:18 CEST] <BBB> its not worth forking over
[17:49:21 CEST] <BBB> just make it disableable
[17:49:28 CEST] <BBB> you compile with --disable-httpserver
[17:49:34 CEST] <BBB> or the people that want it compile with --enable-xyz
[17:49:36 CEST] <BBB> and were all happy
[17:49:42 CEST] <kierank> yes but it's bloat
[17:49:58 CEST] <kierank> and a waste of gsoc resources
[17:52:36 CEST] <BBB> I dont think we can tell other people what they should like to work on
[17:52:42 CEST] <BBB> if people want a http server, so be it
[17:53:03 CEST] <BBB> some people might claim hevc or vp9 is a waste of time
[17:53:14 CEST] <BBB> (depending on where in the political spectrum you lie)
[17:53:18 CEST] <kierank> they can work on it but should it really be merged...
[17:53:36 CEST] <Daemon404> i gotta say, i dont think "commit ALL the garabge as logn as you can disable it" is a pretty stupid ideal.
[17:53:43 CEST] <BBB> anyone here familiar with cocoa?
[17:54:01 CEST] <BBB> Daemon404: dont, or do?
[17:54:04 CEST] <BBB> sounds like you do
[17:54:10 CEST] <Daemon404> er
[17:54:18 CEST] <Daemon404> yeah i think it is a stupid ideal.
[17:54:23 CEST] <BBB> hehe gotcha
[17:59:16 CEST] <wm4> <kierank> and a waste of gsoc resources <- weren't these paid student things always waste of resources until now?
[17:59:23 CEST] <wm4> at least according to Daemon404's judgement
[18:00:15 CEST] <Daemon404> it worked once or twic ein 10 years
[18:05:40 CEST] <BBB> I think it worked several times, but utsually succes is predicted by the student being a prior contributor to ffmpeg, or a prior gsoc participant
[18:05:45 CEST] <BBB> which isnt a good thing, I guess
[18:05:49 CEST] <BBB> but weve had several good ones
[18:06:04 CEST] <Daemon404> BBB, well i mean success as in attracted new contribs
[18:06:05 CEST] <BBB> and its not nice to say all their work is wasted, theres a lot of good stuff coming out of it
[18:06:08 CEST] <Daemon404> not "project passed"
[18:06:12 CEST] <BBB> hm, fair enough
[18:08:27 CEST] <BBB> where do I find cocoa experts
[18:08:53 CEST] <gnafu> BBB: Switzerland?
[18:09:02 CEST] <Daemon404> he means hipster cocoa
[18:09:12 CEST] <Daemon404> so probably up their own butts in the valley
[18:09:29 CEST] <kierank> BBB: j-b probably knows some
[18:09:38 CEST] <gnafu> Daemon404: I am always so delighted with your abundant charm.
[18:09:39 CEST] <gnafu> ;-D
[18:10:10 CEST] <BBB> oo good idea
[18:10:10 CEST] <BBB> j-b: pokey!
[18:10:31 CEST] <BBB> he was right though
[18:10:38 CEST] <BBB> its indeed hipster-cocoa Im having issues with
[18:11:16 CEST] <j-b> yes
[18:12:09 CEST] <BBB> j-b: are you familiar with autolayout?
[18:12:37 CEST] <j-b> yes
[18:12:44 CEST] <BBB> wanna help me debug a really odd issue?
[18:12:56 CEST] <BBB> I can push my test code to github if that helps
[18:13:00 CEST] <BBB> I can also pastebin it
[18:13:04 CEST] <BBB> whichever is easier for you
[18:13:09 CEST] <j-b> now, really not
[18:13:12 CEST] <j-b> but query feepk
[18:13:22 CEST] <BBB> -enothere
[18:15:14 CEST] <j-b> query :)
[18:15:22 CEST] <BBB> yup, working on it
[18:15:39 CEST] <BBB> hes away I think, Ill wait for him to get back
[18:26:31 CEST] <cone-166> ffmpeg 03Michael Niedermayer 07master:4d0f6d3fb421: avdevice/vfwcap: revert header reordering from c201069fac9a76e6604f9d84d76a172434d62200
[18:57:36 CEST] <cone-166> ffmpeg 03Michael Niedermayer 07master:bc48c88918f7: avcodec/h264: Do not fail with randomly truncated VUIs
[20:23:53 CEST] <BBB> Timothy_Gu: why does the cabac test need a REF?
[20:24:10 CEST] <BBB> isnt the idea that these tests are refless and pass purely based on exit code?
[20:25:49 CEST] <Timothy_Gu> BBB: that's why REF=/dev/null
[20:26:02 CEST] <BBB> I meant, why do we need that line at all
[20:26:03 CEST] <Timothy_Gu> not sure if it is needed but everything else has it
[20:26:13 CEST] <BBB> I wonder if we can remove it?
[20:26:25 CEST] <BBB> (Im not a makefile expert)
[20:26:32 CEST] <BBB> nor do I care much, I guess
[20:26:43 CEST] <BBB> and +100 for putting that test in fate, thank you
[20:27:22 CEST] <Timothy_Gu> BBB: seems like it's not (at least it's not used in run() in fate-run.sh)
[20:27:46 CEST] <Timothy_Gu> np
[20:51:45 CEST] <Timothy_Gu> jamrial: so do you want me to remove the timer stuff? it doesn't matter for me either way
[20:52:09 CEST] <jamrial> if nobody complains yes, in a separate patch
[20:52:24 CEST] <Timothy_Gu> is this patch good?
[20:58:15 CEST] <Timothy_Gu> jamrial: ^^
[20:58:58 CEST] <jamrial> Timothy_Gu: yeah, the first two are good
[20:59:52 CEST] <jamrial> comment the timer lines out instead of removing them, so people can easily uncomment them if they want to benchmark the cabac code
[21:04:07 CEST] <Timothy_Gu> jamrial: i'll do it after these two are applied if you don't mind. nobody likes merge conflicts.
[21:04:17 CEST] <jamrial> sure
[21:48:12 CEST] <cone-166> ffmpeg 03James Almer 07master:61090db29a3e: avcodec/libx265: print supported presets and tunes on error
[21:57:08 CEST] <cone-166> ffmpeg 03Timothy Gu 07master:744594685e81: cabac-test: Return 1 if there are any errors
[21:57:09 CEST] <cone-166> ffmpeg 03Timothy Gu 07master:28e2bf90b93e: Add cabac test into fate
[22:29:05 CEST] <cone-166> ffmpeg 03Timothy Gu 07master:1a562adb0101: tests: Do not include stdout/stderr or diff if the test passed
[22:34:04 CEST] <wm4> who has write access to the fate samples?
[22:56:19 CEST] <Daemon404> wm4, why?
[22:56:26 CEST] <wm4> just curious
[22:56:48 CEST] <wm4> the samples are not in any way "publicly" managed, unlike a source code repo
[22:57:07 CEST] <Daemon404> i dont know hwo ffmpeg does it
[22:57:11 CEST] <Daemon404> but at libav i scp'd it once
[22:57:15 CEST] <Daemon404> (and long forgoten how to)
[22:57:39 CEST] <Daemon404> er sftp
[22:59:53 CEST] <rcombs> maybe this is a job for git LFS
[23:00:16 CEST] <rcombs> now that that's a thing
[23:02:06 CEST] <Daemon404> its not even special
[23:02:13 CEST] <Daemon404> it's like git annex but less open
[23:02:19 CEST] <Daemon404> and rsync is more than good enough
[23:02:27 CEST] Action: Daemon404 doesnt get the "put everything in git" obsession
[23:54:19 CEST] <BBB> Daemon404: I think its about the ability to branch and see changelogs
[23:54:39 CEST] <BBB> Daemon404: e.g. who uploaded that file or what version of the samples do we use for the 0.x release branch
[23:54:49 CEST] <Daemon404> hmm perhaps
[23:54:49 CEST] <BBB> (you could even branch/tag the samples collection for a release branch)
[23:54:54 CEST] <BBB> rsync doesnt do that
[23:55:08 CEST] <Daemon404> im still unconvinced by git LFS though
[23:55:11 CEST] <BBB> its a little complicated but theres some okish reasons for it
[23:55:14 CEST] <Daemon404> like i said, its like git annex
[23:55:16 CEST] <Daemon404> but more closed
[23:55:42 CEST] <BBB> Im not advocating for any specific implementation, but the idea of version controlling samples is not terrible
[23:56:05 CEST] <Daemon404> right.
[00:00:00 CEST] --- Sat Apr 11 2015