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

[burek]

[00:04] <ubitux> > x264asm: warn when inappropriate instruction used in function with specified cpuflags
[00:04] <ubitux> > + %error use of ``%1'' %2 instruction in cpuname function: current_function
[00:04] <ubitux> warn or error?
[00:07] <nevcairiel> error in yasm is actually just a warning :d
[00:08] <nevcairiel> (afaik anyway)
[00:08] <ubitux> mmh i feel like we already had this conversation
[00:09] <ubitux> damn i forget everything
[00:09] <nevcairiel> i think we did
[00:16] <cone-594> ffmpeg.git 03Anton Mitrofanov 07master:a1684311b3de: x264asm: warn when inappropriate instruction used in function with specified cpuflags
[00:18] <ubitux> shouldn't we merge the rest?
[00:18] <ubitux> or that's the only thing interesting so far?
[00:18] <ubitux> (not depending on any previous fixes?)
[00:19] <nevcairiel> noone really seems to care to keep them in sync anymore. I send a bunch of patches a year or so ago to sync them up because a change had a fix I wanted, but otherwise..
[00:19] <nevcairiel> does it still change that much anyway?
[00:19] <nevcairiel> x264 dev seems to also go slower lately, and a lot on arm stuff
[00:21] <jamrial> i remember someone mentioned x264 was "done"
[00:23] <michaelni> ubitux, yes we should merge the rest
[00:25] <cone-594> ffmpeg.git 03James Almer 07master:fa3eccb4f9f3: x86/hevc: add ff_hevc_sao_band_filter_{8,10,12}_{sse2,avx,avx2}
[00:25] <cone-594> ffmpeg.git 03Christophe Gisquet 07master:bff7feb328d8: x86: hevc/sao: aligned source buffers
[00:25] <cone-594> ffmpeg.git 03Christophe Gisquet 07master:6a6aeb538b4b: hevc/sao: use aligned copies
[00:26] <jamrial> michaelni: done, thanks
[00:27] <JEEB> HEVC asm slowly getting merged, nice
[00:29] <jamrial> ported, rather. what's not in our tree is still intrinsics in openhevc
[00:30] <ubitux> but still nothing for idct?
[00:33] <jamrial> i'm doing sao_edge now. someone else could tackle idct
[00:33] <ubitux> is it making an overall speed impact?
[00:33] <nevcairiel> sao has an impact, but its not giant
[00:34] <nevcairiel> idct is the biggest chunk
[00:37] <nevcairiel> the intrapred intrinsics seemed to have practically no impact for me
[00:37] <jamrial> ubitux: sao_edge makes this one 1080p file (BQTerrace_1920x1080_60_qp22.bin) go from 36fps to about 48fps on your haswell notebook
[00:38] <nevcairiel> idct on top would probably make it 100 then
[00:38] <ubitux> jamrial: ah? okay
[00:38] <jamrial> 705125 decicycles in sao_edge_filter_8, 262144 runs, 0 skips
[00:38] <jamrial> 23286 decicycles in ff_hevc_sao_edge_filter_64_8_ssse3, 262116 runs, 28 skips
[00:38] <jamrial> 13057 decicycles in ff_hevc_sao_edge_filter_64_8_avx2, 262115 runs, 29 skips
[00:38] <ubitux> haha nice
[00:38] <jamrial> no idea if the c code is that bad, or the simd that good :p
[00:38] <kierank> jamrial: do you still want a haswell 24/7 machine?
[00:38] <ubitux> sounds like a problem with the C :P
[00:39] <nevcairiel> 700k to 13k? the C must be terrible
[00:39] <jamrial> yeah, i have ssh access to ubitux's, kierank
[00:39] <kierank> I have loads of haswells at work but I need to rewire power and network 
[00:42] <jamrial> if you can give me ssh access to one then that'd be great for ubitux (i'm sure he wants to use his notebook sometimes :P)
[00:42] <jamrial> but no hurry
[00:43] <kierank> I need to buy some PDUs
[00:44] <ubitux> jamrial: i actually have no use of it :D
[00:44] <nevcairiel> I could spawn a new VM on my haswell server box and just install some fresh debian or buntu or something if someone really needs something to work in
[00:44] <ubitux> i was thinking of selling it, that clickpad is too annoying to make it useful
[00:44] <ubitux> (fuck x240 clickpad)
[00:45] <ubitux> so don't worry
[00:45] <jamrial> haha, ok
[01:00] <JEEB> jamrial, btw do you have the Japanese 10bit broadcast sample :D
[01:00] <jamrial> first time i hear about it, so probably not :p
[01:00] <JEEB> could be fun for some testing as well (for stats)
[01:01] <JEEB> grab ...A.ts from https://drive.google.com/folderview?id=0BzkZOi5-Ka62NG1aa2RkaUFldzg&usp=sharing#list
[01:01] <JEEB> it's from a Japanese broadcast
[01:01] <JEEB> I like how they went all out and it's BT.2020, 10bit and all
[01:03] <jamrial> oh nice, thanks
[01:15] <rcombs> JEEB: happen to have any TS's laying around that include a switch from one codec/resolution/<other properties> to another?
[01:15] <JEEB> http://trac.ffmpeg.org/ticket/2261
[01:15] <JEEB> PID switch sample
[01:15] <JEEB> switches from SD to HD
[01:16] <rcombs> oh excellent, thanks
[01:16] <JEEB> because switch without PID switch should already work
[01:16] <JEEB> it's just the PMT-based PID switch that doesn't IIRC
[01:25] <cone-594> ffmpeg.git 03James Darnley 07master:12120174ce8b: lavu/x86/x86inc: deprecate INIT_AVX
[01:26] <rcombs> hmm, that actually demuxes fine here
[01:26] <JEEB> over the switch point?
[01:26] <rcombs> and just neither mpv nor ffmpeg.c automatically switches from one stream to the other
[01:26] <JEEB> yes, because lavf ignores the PMT :P
[01:26] <rcombs> but if I pick the second one to begin with it works
[01:27] <JEEB> yes
[01:29] <rcombs> so, would the correct behavior be to output a single AVStream and just switch what actual stream the packets come from, or to output some sort of extra data indicating that the player (or ffmpeg.c) should switch to reading the other one
[01:30] <rcombs> I'd imagine the former would fuck up lavfi
[01:39] <jamrial> blah, forgot preprocessor guard for the avx2 stuff since we still support old yasm versions
[01:41] <rcombs> why?
[01:41] <rcombs> (as in, why support old yasm versions? I'm not aware of any reason someone would stick to an old version or particular difficulty updating)
[01:42] <jamrial> some distros still use them afaik
[01:43] <rcombs> meh
[01:43] <rcombs> good enough
[01:44] <JEEB> rcombs, I guess PMTs are supposed to be noting programs, which should be the "stream"
[01:45] <JEEB> and it just internally switches the actual PIDs used for it
[01:45] <rcombs> yeah, so it seems like my latter option is more what the spec intends
[01:45] <rcombs> I'm wondering what'd make more sense for ffmpeg to implement
[01:46] <rcombs> and it's probably still the latter, since resolution or codec changes will probably require some renegotiation in filter graphs
[01:46] <JEEB> if you want to keep current behavior as much as possible, you'd probably do the extradata thing, but I think the correct way would be to completely abstract it in the demuxer with just PID overrides being possible or so
[01:47] <cone-594> ffmpeg.git 03James Almer 07master:71e2cb4706c9: x86/hevcdsp: add missing guards to ff_hevc_sao_band_filter_avx2
[01:47] <rcombs> what happens in ffmpeg if your resolution changes without a PID change?
[01:47] <rcombs> (also, got a sample of that as well?)
[01:47] <JEEB> not sure... but the last I tried that seemed to work just fine...
[01:47] <JEEB> at least for MPEG-2
[01:47] <JEEB> probably for H.264 as well
[01:47] <rcombs> even going through e.g. a scale filter?
[01:48] <JEEB> I've only tested that stuff in playback scenarios, but I would guess it would still work
[01:48] <JEEB> the source sizes for the frames would just get different
[01:48] <JEEB> I can test some things after I grab some sleep
[01:48] <JEEB> o/
[01:50] <rcombs> 'night
[01:51] <rcombs> oh hey, the scale filter's actually smart enough to reset its input width/height if there's a change
[01:51] <rcombs> not sure if all filters are quite as nice, though
[01:53] <rcombs> but yeah, as that looks easier than I was thinking it might be, just mapping streams using PMTs in the demuxer might be the way to go
[03:09] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:17d87571c831: ffplay: Fallback to dts if pts is unavailable in pkt_in_play_range calculation
[03:54] <cone-594> ffmpeg.git 03Ben Boeckel 07master:1fe94ea79eb7: vorbis: parse out setup headers as well
[04:18] <cone-594> ffmpeg.git 03James Almer 07master:aa945dc112b0: x86/hevcdsp: add missing vzeroupper in ff_hevc_sao_band_filter_48_*_avx2
[05:15] <cone-594> ffmpeg.git 03Andreas Cadhalpun 07master:103e4c58633f: stop embedding the build date
[05:15] <cone-594> ffmpeg.git 03Andreas Cadhalpun 07master:aa2c75e9adb0: doc/doxy-wrapper.sh: autodetect version
[07:13] <Timothy_Gu> Tell me what you think about reading http://104.131.148.213:8080/history/tgdo-test-nothing-branch1 on a phone
[07:13] <Timothy_Gu> Took me 2 hours to figure out how to make the configuration scrollable
[07:17] <rcombs> Timothy_Gu: my immediate thought is that the hamburger menu looks weird pushing the title down
[07:17] <rcombs> or, to the right
[07:17] <rcombs> esp. since it's not centered vertically with the text
[07:18] <rcombs> also, when I rotate my phone to landscape (so it's plenty wide for the table to be displayed normally), it stays formatted for a smaller width
[07:19] <rcombs> the table header is also missing and that's kinda strange but w/e
[07:20] <rcombs> neat how the revision is hidden in portrait mode, but weird how warnings stays hidden in landscape (even though there appears to be an excess of space)
[07:21] <rcombs> also, scrolling the hamburger menu in landscape is pretty janky, and the main content scrolls independently(?) from it
[07:22] <rcombs> seems plenty usable overall, though, and that's the point
[07:30] <Timothy_Gu> rcombs: the hamburger menu isn't my fault I just copied from ffmpeg.org
[07:31] <rcombs> ignore that bit then :)
[07:31] <Timothy_Gu> what do you mean by "table header"?
[07:32] <rcombs> "Information of the Last Run"
[07:32] <rcombs> (which is kinda awkwardly worded but that's not the layout's fault)
[07:33] <Timothy_Gu> rcombs: yeah im open for wording
[07:33] <rcombs> "Last Run Information"?
[07:33] <Timothy_Gu> rcombs: i can't think of a good way to accentuate the table header
[07:34] <Timothy_Gu> rcombs: hm that sounds much better
[07:34] <Timothy_Gu> rcombs: what phone are you using?
[07:38] <Timothy_Gu> rcombs: see if this is better. I made warnings appear when revision appears
[07:39] <Timothy_Gu> BTW the "table headers" aren't really a table (it's a table on desktop but <dl> on phones)
[07:40] Action: rcombs tries
[07:41] <rcombs> warnings show up in landscape now, yeah
[07:41] <rcombs> though I'm not sure if it'd fit well on a smaller phone
[07:41] <rcombs> I'm on an iPhone 6+
[07:42] <Timothy_Gu> rcombs: that's like the worst phone for testing websites on phones
[07:42] <rcombs> dat 1920x1080
[07:42] <Timothy_Gu> but it's working here on my iPhone 6 too
[07:43] <kurosu__> michaelni, another thing that is present in openhevc is interlaced support
[07:43] <rcombs> kurosu__: fuck
[07:43] <kurosu__> michaelni, but not test sequences available, and if people really want to have it, then they should entice us
[07:44] <kurosu__> *no test
[07:44] Action: rcombs pulls up in windowed browser on laptop
[07:44] <rcombs> ooh, nice and responsive
[07:44] <kurosu__> rcombs, it's not like avc, mostly flags and buffer management to inform how to combine field images
[07:46] <Timothy_Gu> rcombs: I just added "Last Run Information" to phones too. See if you like it. (I don't personally)
[07:46] <rcombs> Timothy_Gu: the wording, or how it looks?
[07:47] <Timothy_Gu> the appearance
[07:47] <rcombs> hmm, yeah, it's kinda weird, maybe partially because it looks a bit like a regular row
[07:48] <rcombs> try inverting the color scheme on it?
[07:48] <Timothy_Gu> rcombs: my gut feelings tell me it'd look weird if i invert the color scheme
[07:48] Action: rcombs shrugs
[07:49] <rcombs> I'm not hugely attached to it
[07:49] <Timothy_Gu> ok i'll just remove it then
[07:51] <Timothy_Gu> bye i gotta sleep
[07:52] <rcombs> 'night!
[08:30] <filterSAC> i have raw videos . i create a mossac screen and all videos are playing....but i want to play this mossac screen using ffplay directlyu rather than using ffmpeg.. can anyone give e\me some idea how i create directly play a mossac screen using ffplay
[09:45] <j-b> 'morning
[10:01] <ubitux> http://b.pkh.me/cg.png nicely balanced
[10:01] <ubitux> :(
[10:10] <cone-436> ffmpeg.git 03Stefano Sabatini 07master:7b35a01ff0d4: doc/ffprobe.xsd: drop build_date and build_time from programVersionType
[10:21] <TimNich> ubitux:  what are they?
[10:22] <ubitux> palette inserted in a stupid way in a kdtree :p
[10:22] <ubitux> should be good enough for a start though
[10:48] <TimNich> Ahh, see what you mean about the balance...
[11:35] <saste> ubitux, do you think it's OK to use vsynth video for pp tests?
[11:35] <saste> or should we use some relevant reference image/video?
[11:36] <ubitux> saste: it probably makes more sense to pick a blocky mpeg video from fate
[11:36] <ubitux> it will also allow to eventually cover the quantization tables
[11:37] <saste> ubitux, arwa is tellign me she's problem with make fate rsync
[11:37] <ubitux> akira4 has the same issue
[11:37] <saste> it's some problem of cheap shitty firewalling policy implemented by their university
[11:37] <ubitux> we can send her the sample to put in the correct tree
[11:38] <saste> yeah, do you know of a suited samples, out of your head?
[11:38] <ubitux> nope
[11:38] <saste> also I'd like to test all pixel formats
[11:39] <ubitux> does it make much sense for these filter?
[11:39] <ubitux> slowdown might be important
[11:42] <ubitux> cram/skating.avi this one is a bit blocky but not mpeg
[11:46] <ubitux> mv/12345.mv again not mpeg
[11:47] <ubitux> hevc-conformance/DBLK_A_SONY_3.bit blocky at the end
[11:48] <ubitux> also, they aren't temporal afaik, so we can probably just use a picture
[11:48] <saste> ubitux, yes
[11:48] <saste> so basically you propose an image, and to test for a single pixel format
[11:48] <ubitux> like the one she uploaded on the trac
[11:48] <ubitux> that could be added to fate
[11:49] <ubitux> we won't be able to test the quantization part though
[11:49] <saste> OTOH ideally we should test for QP
[11:49] <saste> so the sample should be QP
[11:49] <ubitux> she can just make up a small sample of 1 sec
[11:49] <ubitux> at very low bitrate
[11:50] <saste> what about a short clip of matrix_bench re-encoded at low bitrate?
[11:50] <saste> yeah I'm thinking about the same
[11:50] <ubitux> for codecview i use $(TARGET_SAMPLES)/real/spygames-2MB.rmvb
[11:51] <ubitux> which has p/b frames
[11:51] <ubitux> no idea if it uses QP 
[11:51] <ubitux> anyway..
[11:57] <saste> ffmpeg -ss 125 -i matrixbench_mpeg2.mpg -vf crop=720:240:0:192 -t 1 -b:v 200k -y matrixbench_mpeg2.lq1.mpg
[11:57] <saste> ubitux, ^^
[11:59] <ubitux> i see no bframes
[12:01] <ubitux> (i'm thinking of use_bframe_qp option for spp at least)
[12:02] <ubitux> (if we want to ever test this option)
[12:05] <saste> how can i force bframes in the output?
[12:07] <saste> -bf 1
[12:07] <saste> ffmpeg -ss 125 -i matrixbench_mpeg2.mpg -vf crop=720:240:0:192 -t 1 -b:v 200k -codec:v mpeg2video -bf 1 -an -y matrixbench_mpeg2.lq1.mpg
[12:10] <ubitux> sounds good to me, assuming there is indeed qp exported
[12:10] <ubitux> b frames looks present too
[12:10] <ubitux> very blocky just as we like :p
[12:10] <ubitux> and 216K here so yeah, LGTM
[12:11] <ubitux> saste: ah, last yhing you might want to do
[12:11] <ubitux> is use a non % 8 height/width
[12:12] <ubitux> just to be a bit a jerk a bit with the 8x8 boundary checks we have
[12:12] <ubitux> anyway gtg, see you later
[12:13] <saste> ubitux, ok, thanks
[12:15] <saste> ffmpeg -ss 125 -i matrixbench_mpeg2.mpg -vf crop=716:236:2:194 -t 1 -b:v 200k -codec:v mpeg2video -bf 1 -an -y matrixbench_mpeg2.lq1.mpg
[13:04] <michaelni> Timothy_Gu, looks nice overall, the warning number isnt clickable (to view the compiler warnings) and no diff to the previous runs warnings or i failed to find it. This was occasionally useful, that is if the warning number turns yellow you know theres a new warning so clicking on +- then shows the diff an thus which warning is new so one can fix it
[14:23] <kurosu__> michaelni, sao patch regenerated
[14:24] <kurosu__> as for the reason, it's just that too many patches/differences have piled, and untangling that is difficult as openhevc commits are less precisely cut
[14:25] <nevcairiel> thats a nice way to say it :p
[14:26] <kurosu__> https://github.com/OpenHEVC/FFmpeg/commit/91329b755a02675f730a0d5ce0b329df2c234c5d <- an example, but obviously an accidental commit
[14:27] <wm4> "accidental commit"
[14:27] <kurosu__> nevcairiel, openhevc guys are not on the same side of the fence concerning development through trolling
[14:27] <kurosu__> that is aleniating to a lot of people, and we wouldn't be at this stage without them
[14:28] <nevcairiel> even on my own project i try to keep clean-ish commits, in the long run it just helps yourself more than anyone else
[14:28] <JEEBsv> yeah
[14:28] <kurosu__> totally agree
[14:32] <kurosu__> nevcairiel, on a side note, the last batch of patches have given me a 10% speedup on some computers, and that's over something using intrinsics
[14:32] <kurosu__> *has
[14:32] <nevcairiel> 10% total speed?
[14:33] <kurosu__> yeah, a sample decoding went from ~19.5s to ~17.1s, but that's with a lot of threads
[14:33] <kurosu__> the gravity trailer, iirc
[14:34] <kurosu__> and jamrial's numbers on edge filter are a lot better than the intrinsic version, so i'm eager to see that
[14:52] <cone-436> ffmpeg.git 03Michael Niedermayer 07master:6e95c67330b2: avcodec/wavpackenc: remove unneeded L suffixes
[15:27] <ubitux>   91.29%  ffmpeg_g  ffmpeg_g           [.] colormap_nearest_node
[15:27] <ubitux>    2.84%  ffmpeg_g  ffmpeg_g           [.] set_frame_sierra2_4a
[15:27] <ubitux>    1.60%  ffmpeg_g  ffmpeg_g           [.] ff_lzw_encode
[15:27] <ubitux> :(
[15:31] <durandal_1707> how many fps?
[15:32] <ubitux> slow, very slow :p
[15:33] <durandal_1707> it has to be
[15:43] <ubitux> i can't tell if it's because the tree is balanced like a cow on one leg, or if the search is doing something not really smart
[16:19] <kurosu__> michaelni: 1) that patch would conflict 2) it uses a macro that needs to go 3) it would crash 4) if fixed at the same time, you get the new patch
[16:19] <kurosu__> keeping authorship is nice, but here, it's more towards wasting everyone's time, more so mine
[16:20] <kurosu__> and that's my own authorship I'm dropping, here
[16:22] <michaelni> kurosu__, maybe we could post the differences between the cherry picked (not working) and final fixed one so openhevc can easily apply the differences if they like ? This should not add any work as you need to pick the commit and resolve conflicts anyway
[16:22] <kurosu__> as you generated the patches, apply them, or none, as you wish
[16:26] <michaelni> with posting the difference i mean in the future, for this one i alreay posted them ...
[16:34] <Timothy_Gu> michaelni: yeah I'll fix the warning number. The diff is kinda hard to do, but many slots generate diffs with order changes so it wasn't that useful. I
[16:36] <Timothy_Gu> *i'll fix the link
[16:36] <michaelni> thanks
[16:47] <saste> michaelni, how can I upload a file to the FATE samples repository?
[16:48] <saste> I want a sample to use with PP filters
[16:48] <saste> it's ~200KiB
[16:49] <michaelni> post link and say in which directory to put it, ill upload, we have the fate samples ATM on 3 servers so its probably easier if i upload it
[16:56] <michaelni> saste, btw, cant you create a sample as part of the test, like encoding to low bitrate ?
[16:56] <michaelni> or does this have some disadvantage?
[16:56] <saste> michaelni, I can, but I prefer to have "realistic" content
[16:57] <saste> ffmpeg -ss 125 -i matrixbench_mpeg2.mpg -vf crop=716:236:2:194 -t 1 -b:v 200k -codec:v mpeg2video -bf 1 -an -y matrixbench_mpeg2.lq1.mpg
[16:57] <saste> I surely could use synthetic video, what do you think?
[16:59] <michaelni> dunno, pick what you prefer
[17:04] <Timothy_Gu> michaelni: link added
[17:29] <saste> michaelni, I prefer a hardcoded file, to simplify things
[17:30] <saste> this also means that we increase the FATE samples repo size by about 200KiB
[17:38] <michaelni> 200kb is no problem
[17:39] <saste> michaelni, good, how does it work? Is it fine to send the file on list? (together with the test patch?)
[17:41] <michaelni> 200kb, is probably ok, but thats just my personal oppinion others might prefer a link
[17:51] <cone-436> ffmpeg.git 03Jean First 07master:6d1d036e2ca8: lavc/libopenjpegenc: factorize cinema parameters to it's own function
[18:09] <cone-436> ffmpeg.git 03Jean First 07master:ecc92ee717ea: lavc/libopenjpegenc: move opj_create_compress, opj_cio_open and opj_set_event_mgr to libopenjpeg_encode_frame
[18:16] <jamrial> michaelni: your freebsd fate systems are failing with "no space left on device" errors
[18:17] <cone-436> ffmpeg.git 03Mickaël Raulet 07master:7cf6a67ef9c9: avcodec/hevc: adding support for monochrome sequences in hevc
[18:28] <michaelni> jamrial, cleaned it up a bit, should be enough free space now 
[18:28] <jamrial> ok
[18:31] <kurosu__> jamrial, the issue with the avx2 MC patch seems that the needed fixes have been scattered over several commits, some of them containing unrelated changes
[18:32] <kurosu__> so there's that to keep a matching history
[18:48] <jamrial> fate passes with avx2 if i compile openhevc's ffmpeg fork from github, so yeah, something's probably missing from those scattered commits
[19:18] <ubitux> funny, when i moved from bruteforce search to kdtree, i got different results, but both were correct
[19:19] <ubitux> like, i request #12EC7B, one finds me #77A7AD and the other #609938
[19:19] <ubitux> both have an distance of 17462
[19:19] <ubitux> i really need to move to L*a*b instead of RGB
[19:24] <wm4> all for gif, lol
[19:24] <ubitux> ;)
[19:44] <ubitux> http://b.pkh.me/gunkanjima.jpg ’ http://b.pkh.me/gunkanjima.gif 
[19:45] <ubitux> the gif almost looks better (with that cute sharpening effect on the green in the right/bottom)
[19:45] <nevcairiel> you are losing a bit of gamma there
[19:45] <ubitux> :D
[19:45] <ubitux> yeah
[19:45] <ubitux> no gamma correction
[19:45] <ubitux> i'm a bit annoyed by the orange that disappear in the grass in the middle/left
[19:45] <nevcairiel> the sky also has one area that seems to lose a bit of detail somehow
[19:46] <ubitux> but i realized my palette is redundant (like i have 20 color dups i could reuse)
[19:46] <ubitux> also, it's possible the cie-lab will help here
[19:46] <ubitux> so i'm going to try this
[19:50] <ubitux> i should probably make the color search faster and push that first version though
[19:52] <Timothy_Gu> michaelni: https://github.com/FFmpeg/FFmpeg/commit/7cf6a67ef9c9ac95e57867c753f38104f481f6f1#diff-1a6fca498a4664f36b44e65c515bf9c1R486 looks like the indentation is off
[20:03] <akira4> ubitux, I've changed the diff: http://pastebin.com/5JAYjRTY.
[20:03] <ubitux> akira4: in the doc, s/force-style/force_style/g
[20:04] <ubitux> also specify that it's ASS style
[20:04] <akira4> alright.
[20:04] <ubitux> move the option below the stream index one, because order is important when you do not explicit the option names
[20:05] <ubitux> (you can -vf bla=foo:bar:bla instead of -vf bla=x=foo:y=bar:z=bla, and various mixed combination, so order is important)
[20:05] <akira4> yes.
[20:05] <ubitux> looks pretty cute otherwise, but make sure you check for allocation errors
[20:05] <ubitux> and that you do not leak anything in case of error
[20:06] <cone-436> ffmpeg.git 03Michael Niedermayer 07master:d525b45fde17: avcodec/hevc_filter: Fix indention
[20:06] <akira4> okay.
[20:06] <ubitux> you also need to fix your style a bit, but you can do that at the end
[20:06] <michaelni> Timothy_Gu, fixes
[20:06] <michaelni> fixeD
[20:06] <ubitux> akira4: otherwise that looks mostly fine :)
[20:07] <ubitux> akira4: btw, that list need to be freed at the end
[20:07] <akira4> yes. 
[20:07] <ubitux> i don't know if ass keep a copy or not
[20:07] <ubitux> if it does, you can maybe destroy it after the call to ass, but otherwise you need to keep a pointer in the context
[20:07] <ubitux> and free it at uninit
[20:08] <akira4> hmm.
[20:41] <cone-436> ffmpeg.git 03Martin Storsjö 07master:28df0151b661: configure: Add a dependency on vc1_decoder from vc1_parser
[20:41] <cone-436> ffmpeg.git 03Michael Niedermayer 07master:aab902e64668: Merge commit '28df0151b6618226b05ee52e031af0b11ca531b0'
[20:46] <llogan> ffplay -f lavfi -i testsrc -vf lenscorrection=0.5:0.5:-0.5:-0.5
[20:49] <llogan> hmmm...are the lenscorrection docs wrong? for k1 and k2 "0.5 means no correction", but that screws with stuff and 0.0 doesn't.
[21:16] <cone-436> ffmpeg.git 03Diego Biurrun 07master:3d5d46233cd8: opus: Factor out imdct15 into a standalone component
[21:16] <cone-436> ffmpeg.git 03Michael Niedermayer 07master:7b32b35bf5c4: Merge commit '3d5d46233cd81f78138a6d7418d480af04d3f6c8'
[21:26] <cone-436> ffmpeg.git 03Diego Biurrun 07master:11e055331704: Ignore generated file tools/sidxindex.
[21:26] <cone-436> ffmpeg.git 03Michael Niedermayer 07master:8f79cd4764f7: Merge commit '11e05533170485b593974cf90916425a0188e7bd'
[21:47] <wm4> #define LICENSE_PREFIX "libswscale license: "
[21:47] <wm4>     return LICENSE_PREFIX FFMPEG_LICENSE + sizeof(LICENSE_PREFIX) - 1;
[21:47] <wm4> why is it done this way?
[21:48] <ubitux> so it can be grepped into the binary
[21:48] <ubitux> iirc
[21:55] <rcombs> wat
[22:11] <cone-436> ffmpeg.git 03dhead666 07master:48e36f8a1276: libavformat/mpegtsenc: allow to set service_type in sdt
[22:28] <cone-436> ffmpeg.git 03Michael Niedermayer 07master:0935453e84a1: avformat/mpegtsenc: Change the service_type field to enum
[22:32] <ubitux> rcombs: proprietary stuff, where only binaries are available
[22:32] <ubitux> it helps localizing
[22:40] <cone-436> ffmpeg.git 03Michael Niedermayer 07master:c348a42dcc93: Revert "avformat/mpegtsenc: Change the service_type field to enum"
[23:37] <cone-436> ffmpeg.git 03Michael Niedermayer 07master:9d7ae72725e1: swresample: Use int instead of enum for fields which are accessed through AVOptions as int
[00:00] --- Tue Feb  3 2015