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

[burek]

[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