[00:05] <cone-588> ffmpeg.git 03Anshul Maheshwari 07master:93fac23b80e4: avcodec/ccaption_dec: Adding color and fonts for future use in screen [00:55] <cone-588> ffmpeg.git 03Michael Niedermayer 07master:5008605bf25c: avcodec/hevc: Replace more mallocs by av_malloc_array() [00:55] <cone-588> ffmpeg.git 03Michael Niedermayer 07master:2b215b7f5af0: avcodec/hevc: Check for av_malloc failure [01:10] <rcombs> is there a reason why segment.c keeps seg->list_pb open all the time when writing an HLS manifest or using a max list size? [02:55] <cone-588> ffmpeg.git 03Michael Niedermayer 07master:305cbe76d327: avcodec/wma: remove unneeded #includes, there are no assert() only av_assert* [02:55] <cone-588> ffmpeg.git 03Michael Niedermayer 07master:a73c4118092d: avcodec/aacdec: remove unneeded #include, theres no assert() in aacdec [10:03] <cone-864> ffmpeg.git 03Paul B Mahol 07master:b5004f32133f: avformat/nut: add GIF[0] [10:34] <cone-864> ffmpeg.git 03Paul B Mahol 07master:64815d1f0c78: avformat/nut: support WavPack [11:19] <durandal_1707> mplayer broken with yuv444p? [11:24] <wm4> durandal_1707: in what way? unless it broke, it should probably work [11:25] <JoshX> Good morning :) [11:53] <cone-864> ffmpeg.git 03Stefano Sabatini 07master:40b026b1d0a3: doc/muxers/segment: document strftime option [11:54] <JoshX> ah nice [11:54] <JoshX> i did trigger something ;) [12:01] <ubitux> http://b.pkh.me/out-dither-bayer-scale-0.gif http://b.pkh.me/out-dither-bayer-scale-1.gif http://b.pkh.me/out-dither-bayer-scale-2.gif http://b.pkh.me/out-dither-bayer-scale-3.gif  scale=1 looks best, right? [12:02] <ubitux> http://pastie.org/pastes/9873593/text  i'm using this [12:03] <ubitux> erm scaled twice, i'm an idiot [12:03] <ubitux> let me fix that.. [12:04] <ubitux> file updated, scale=2 looks the best to me [12:04] <ubitux> code now being http://pastie.org/pastes/9873596/text [12:05] <ubitux> i need that minus to avoid too much luma [12:05] <ubitux> but i'm also uncomfortable about scaling down the dither value directly, i should probably upscale the source, add the dither, and then scale down the whole thing i suppose? [12:10] <nevcairiel> ubitux: 2 and 3 have banding, 3 more so than 2, but 2 still shows it [12:11] <nevcairiel> dunno if a little less pattern is worth the banding :d [12:24] <ubitux> nevcairiel: should i make it configurable? [12:24] <ubitux> so you would prefer scale=1? [12:25] <ubitux> the pattern looks more ugly than the banding to me [12:26] <durandal_1707> imho why not allow all of them? [12:26] <ubitux> yeah i guess i'll add an option [12:26] <ubitux> i'm just wondering if i'm really implementing bayer here [12:26] <ubitux> since apparently the scale=0 is kind of the "reference" [12:28] <wm4> huh, stream_codec_tag got deprecated? [12:29] <wm4> and no decoders use it anymore... [12:30] <durandal_1707> you need it? [12:31] <nevcairiel> nah, he is just confused that its useless now [12:45] <saste> JoshX, you the guy of the %t patch, right? [12:58] <Diego___> Hello! [13:59] <JoshX> oh yes i am but saste is gone :-/ [14:04] <michaelni> kierank, welcome back, and sorry for myself being grumpy&unfriendly yesterday [14:09] <iive> durandal_1707: are you still looking for soft telecine samples? [14:28] <durandal_1707> iive: i already got one from michaelni [14:29] <iive> ok. sorry i could help you at the time. btw, i guess you've figured out why mplayer says the filter is functional only with mencoder. (because mplayer changes fps when it detect soft telecine) [14:58] <cone-864> ffmpeg.git 03Christophe Gisquet 07master:1fa637d2ef00: ffmpeg: free_input_threads requires HAVE_PTHREADS [16:38] <cone-864> ffmpeg.git 03Paul B Mahol 07master:80cbf1372559: avformat/rtpdec_qdm2: change assert to av_assert0() [16:38] <cone-864> ffmpeg.git 03Paul B Mahol 07master:5274860fe275: ffmpeg: remove unused header [16:38] <cone-864> ffmpeg.git 03Paul B Mahol 07master:3db9960e0aa9: avcodec/qdm2: remove unneeded #include, there are no assert() [16:38] <cone-864> ffmpeg.git 03Paul B Mahol 07master:be128c1e3426: avcodec/videodsp_template: remove unneeded #include, there are no assert() only av_assert* [16:44] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:3531594017bd: ppc/mpegvideo_altivec: Change assert to av_assert2() [16:45] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:d0f315ab6c7d: avcodec/ppc/h264qpel_template: Change if DEBUG assert() to av_assert2() [17:12] <durandal_1707> michaelni, saste: is it ok if i remove libmpcodecs? [17:13] <saste> durandal_1707, no objections from me [17:14] <michaelni> durandal_1707, no objections from me [17:16] <cone-864> ffmpeg.git 03Paul B Mahol 07master:9fd925dee58d: lavfi: remove mp=softpulldown [17:17] <arwa> I have to write process_command to change which settings of eq filter? [17:18] <durandal_1707> arwa: all: gamma, contrast, brightness, saturation [17:19] <arwa> Okay. [17:30] <wm4> it would be better if instead of a process_command, we had a function to change the avoptions of a filter [17:57] <akira4> ubitux, Could you have a look at this diff? http://pastebin.com/fGGvLL8M. [17:57] <ubitux> akira4: sure :) [17:58] <ubitux> akira4: does it work? [17:58] <akira4> No. Its giving me a segfault when I try to access the ASS_style struct [17:59] <akira4> I just wanted to make sure I'm working in the right direction :-/ [18:01] <ubitux> let me check the api [18:02] <ubitux> akira4: try to allocate a new style [18:03] <ubitux> in the track [18:03] <akira4> hmm. Okay. I'll try that. [18:03] <ubitux> in which you will force a few settings [18:03] <akira4> Do I need to set the values for all the style parameters? [18:04] <ubitux> what the doc api says? [18:06] <akira4> Uhm there are many parameters. The doc just mentions what they do. [18:07] <ubitux> just alloc a new style in the track [18:07] <ubitux> and set style->FontName = something [18:07] <ubitux> (you might to strdup or something, not sure) [18:07] <ubitux> then call the force style thing [18:07] <akira4> Yes.Also, when I try to give more than one parameter in the commandline it just takes the first one. [18:08] <akira4> Am I doing something wrong in the taking input part? [18:08] <akira4> as in it doesnt take the string after a comma. [18:09] <ubitux> mmh wait, i see there is ass_set_style_overrides() too [18:09] <ubitux> akira4: what exactly are you trying to do? [18:09] <akira4> something like ./ffmpeg -i ~/test.avi -vf subtitles=~/testing.srt:force_style=FontName=Arial,Outline=2 ~/out.avi [18:11] <ubitux> yes, the comma is the filter separator for successive filters [18:11] <ubitux> try -vf "subtitles=$HOME/testing.srt:force_style='FontName=Arial,Outline=2'" [18:12] <ubitux> look at ass_set_style_overrides(), you probably want to use that [18:13] <akira4> right. Thanks. [18:18] <ubitux> akira4: you might just need a call to ass_set_style_overrides() actually [18:18] <ubitux> try this before trying someting more complex like allocating a new style etc [18:19] <akira4> Oh.Okay. I'll try working with that then. [18:24] <ramiro> is anyone from here going to attend FOSDEM? [18:24] <ramiro> I know kierank is going as a speaker [19:15] <cone-864> ffmpeg.git 03Carl Eugen Hoyos 07master:50144b91ea50: Respect horizontal differencing predictor for 16bit gray tiff images. [19:15] <cone-864> ffmpeg.git 03Michael Niedermayer 07master:dffc16d52314: Merge remote-tracking branch 'cehoyos/master' [20:16] <cone-864> ffmpeg.git 03Paul B Mahol 07master:2ff7e81b3c5e: avcodec/vp3: use init_get_bits8() [21:41] <kurosu_> jamrial, looking at the sao patches, I have several comments, one is a big conceptual one [21:41] <kurosu_> but I'll first look at benchmark values [21:42] <jamrial> sure [21:54] <jamrial> btw, alignment is not important for offset_val, but you just made me realize that (assuming it works) a single movq + SPLATW [0123] may be better for the sse2 version [21:54] <jamrial> one load from memory instead of four [21:59] <jamrial> kurosu_: works. will have to benchmark it and see if there's any gain [21:59] <jamrial> probably nothing substantial. it's outside of the loop after all [22:00] <kurosu_> yes, and at several thousands cycles, that's noise [22:22] <kurosu_> jamrial, well my time is over for tonight [22:22] <kurosu_> so just a summary of things [22:23] <kurosu_> your assembly is around 8-10% faster than the intrinsic one - too bad it's not that heavy in the decoding [22:23] <kurosu_> as for the implementation, it's going to be cumbersome, but here's an idea: [22:23] <kurosu_> you actually have only 4 values [22:24] <kurosu_> the issue is that they apply to just a range of pixels value [22:24] <kurosu_> it's probably possible to add/subtract an offset to the pixels values and shift [22:25] <kurosu_> or to shift the pixel values and offset the table [22:25] <kurosu_> but loading the 4 values into a xmm reg, and using pshufb looks possible for 8 bits [22:25] <kurosu_> (not sure if you extend to 16 bits and if it is needed) [22:26] <kurosu_> for 10+ bit cases, yes, it's troublesome, because pshufb works on bytes [23:28] <jamrial> kurosu_: i think see what you mean [23:29] <jamrial> and extending to 16 bits is probably necessary. there are no byte shift instructions outside of the amd xop one afaik [00:00] --- Sat Jan 31 2015