Ffmpeg-devel-irc
Threads by month
- ----- 2026 -----
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
February 2015
- 1 participants
- 56 discussions
[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=sha…
[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/91329b755a02675f730a0d5ce0b329df2… <- 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/7cf6a67ef9c9ac95e57867c753f38104f48… 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
1
0
[03:49] <pentanol> hello,
[03:50] <pentanol> I need help with encoding third audio encoding in avi file
[03:50] <pentanol> for instance first 600 seconds I have nice syncronisation with video, but after that I got unsinc video and audio
[03:51] <pentanol> I use ac3 128Kb/s
[03:51] <pentanol> why that could be?
[03:51] <pentanol> that avi fave has third different languages with audio encoding and one of them fail
[03:52] <pentanol> fave=file*
[05:12] <ac_slater_> hey all, where are the public logs kept?
[05:12] <ac_slater_> (for this channel)
[05:12] <c_14> http://ffmpeg.gusari.org/irclogs/
[05:13] <ac_slater_> c_14: nice, just saw the link on the ffmpeg site. Thanks mate
[08:29] <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
[08:42] <pentanol> filterSAC you must start from drawbox filter
[09:21] <filterSAC> :pantanol can you please explain how may i start from Drawbox filter
[09:22] <relaxed> filterSAC: it might be easier to use ffmpeg with the opengl output
[09:22] <relaxed> since you already have it working with ffmpeg, I assume
[09:23] <keestu> dear all, sorry to ask very basic question. when i dont need any kind of a playback operations like fast forwarding, rewinding, will RTP protocol suffice for live video streaming over wifi ?
[11:05] <UVV> Hi guys
[11:05] <durandal_1707> hi
[11:05] <UVV> I have a broken mp4 file, which was recorded with ffmpeg -f x11grab -r 2 -s 1600x1200 -i :0.0 -t 00:14:59 -qscale 1 file.mp4
[11:06] <UVV> Now the X11 was killed with Ctrl+Alt+Backspace.
[11:06] <UVV> Is there any clue how could I recover this file.
[11:06] <UVV> I've been searching the Internet for a couple of days already and finally came here :)
[11:07] <UVV> Would appreciate any help
[11:08] <UVV> I tried also this project https://github.com/ponchio/untrunc , but to no avail :(
[12:28] <ManDay> Hello, can I use ffmpeg to stream video from a webcam on an android device into the ethernet?
[12:28] <Mavrik> Ugh
[12:29] <Mavrik> "Yes."
[12:29] <ManDay> Can you expand the quotes?
[12:29] <Mavrik> Depends on how do you think you'll pull that off.
[12:29] <ManDay> I have absolutely no idea about Android, whatsoever
[12:29] <Mavrik> Since Android devices don't have ethernet.
[12:29] <Mavrik> Or webcams.
[12:29] <ManDay> Mavrik: Huh?
[12:29] <Mavrik> Or support arbitrary binaries.
[12:29] <Mavrik> FFmpeg isn't an Andoird app, but FFmpeg libraries do work for usage inside Android apps.
[12:29] <ManDay> Well, I have a Samsung Galaxy Pad here - I'd like to use that as a "walking cam"
[12:30] <ManDay> I'm open for any suggestion that would work, of course
[12:33] <Mavrik> Hmm, check for any existing apps on Play store first :)
[13:31] <ManDay> Mavrik: "IP Webcam" is pretty much what I need
[13:31] <ManDay> It works
[14:06] <ManDay> Mavrik: Juswt curious: What did you mean by "Android has no webcam and no ethernet"?
[14:07] <ManDay> I can use ffmpeg easily to stream video in form of a webcam stream (don't ask me what it is, I just call it that - the protocol for net webcams) from linux, rihgt?
[14:20] <dhead666_> hi, is ffmpeg is the best tool to capture http mpegts stream without a change? for sharing a sample so developers could debug an issue ("non-existing PPS 0 referenced" ends with black screen in player) I need to capture an http mpegts stream from a DVB to IP box, ATM I'm using the following to save the stream, but if I input the create sample.ts back to ffmpeg then the error will not appea
[14:20] <dhead666_> r again : "# ffmpeg -i LINK_TO_STREAM -codec copy -f mpegts sample.ts"
[14:21] <dhead666_> *create -> created
[14:23] <Mavrik> dhead666_, honestly, using curl/tcpdump/etc is way better
[14:23] <Mavrik> since ffmpeg will remux it anyway
[14:24] <dhead666_> Mavrik: thanks, I'll do just that.
[14:24] <Mavrik> I know that I prefer the raw dumped stuff, since VLC and ffmpeg tend to try to "repair" and retimestamp streams and thus usually hide issues :)
[14:31] <dhead666_> Mavrik: alright, thanks, this is actually a sort of a bandage solution for me, I can pipe the stream to ffmpeg before sending to the player :) (though it won't help much with channels switching delay)
[15:03] <RobertNagy> If I'm able to encode 50 fps content in 50 fps without the -re option but it runs slower (~42fps) with the -re option what might be wrong?
[15:05] <Mavrik> hmm
[15:05] <Mavrik> your CPU is too slow?
[15:31] <RobertNagy> well, it can encode it in 50fps...
[15:31] <RobertNagy> if I don't provide -re
[15:31] <RobertNagy> and I've tried lusing faster presets to get cpu at 30-40%
[15:31] <RobertNagy> it seems to be realted to that fact that I'm doing multiple encoding simulatanously in some wierd way.
[16:30] <wiretap1> hi there, i got a bunch of ogg files i want to concat to a file called all_sounds.ogg & the catch is that I need to keep the durations of each ogg file in a txt file in order to know when the next sound will start. can anyone suggest a way to do it?
[16:31] <wiretap1> e.g file1.ogg starts at 00:00:00
[16:31] <wiretap1> file2.ogg starts at 00:01:23
[16:31] <wiretap1> meaning file1 is 1:23 duration
[16:31] <wiretap1> and so on
[16:31] <wiretap1> the last file wont have duration
[18:06] <m-r-r> Hello
[18:07] <m-r-r> When ffmpeg loads an input file, how does it detects the input codecs ? Does it use the file extension or does it looks directely at the file content ? Maybe it uses the MIME database ?!
[18:08] <ramiro> m-r-r: it looks at the file content
[18:10] <bigeast> is the information of the codec signalled in the container, or the codec type can be derived from the bitstream in the container?
[18:10] <m-r-r> ramiro: Okay, thanks :-)
[18:14] <kepstin-laptop> bigeast: to be more accurate, ffmpeg does a bit of all of the above for detecting; the file extension is used for guessing, and it does more advanced probes looking at the contents. For formats it recognizes, it reads information about the codecs from the container.
[18:14] <kepstin-laptop> er, m-r-r ^^
[18:14] <Zerowalker> how do you set what mapping a stream should have when being encoded/muxed into a file with ffmpeg (C++) ?
[18:17] <m-r-r> kepstin-laptop: So, if my extension is missing or invalid, Ffmpeg can still read my file ?
[18:18] <Zerowalker> yeah
[18:18] <kepstin-laptop> m-r-r: in most cases, yes, but in a few tricky cases it might be less accurate at guessing. (for common formats like avi, mkv, mp4, etc. it'll almost always be right)
[18:18] <bigeast> It seems ffmpeg can detect raw bitstream, even without a container like mkv,mp4, etc.
[18:18] <Zerowalker> file extension is just a quicky
[18:19] <kepstin-laptop> bigeast: depends on the format; some bitstreams have identifying characteristics, others don't.
[18:24] <bigeast> kepstin: right, I think it's better to review the source code, and hope I can understand the mechanism better :-D
[18:26] <kepstin-laptop> (mpeg-ts is perhaps one of the more ... interesting ... containers to detect, give that you can start at an arbitrary cut point in the stream and might have to read quite a while before getting a header you can sync on.
[18:26] <kepstin-laptop> )
[18:29] <bigeast> if it's so, just decode it! The only reason we want to know the stream format is to decode it, isn't it?
[18:29] <angrybb> is ffmpeg able to output to http like vlc does? for example ffmpeg -re -i /path/to/video.file -vcodec copy -acodec copy -f mpegts http://127.0.0.1:8080/ ?
[18:32] <c_14> angrybb: you can do that and it should post/put the data (not sure which)
[18:34] <bigeast> angrybb: Maybe ffserver is what you need. But I don't know the exact parameters either
[18:54] <Tr4sK> Hi ther
[18:54] <Tr4sK> e
[18:54] <Tr4sK> I'm trying to build ffmpeg througt rmpbuild.
[18:55] <Tr4sK> I got a complain from ./configure
[18:55] <Tr4sK> Unknown option "--host=x86_64-redhat-linux-gnu".
[18:55] <Tr4sK> I saw that the option --host isn't in ./configure --help
[18:56] <JEEB> that's an autoconf setting
[18:56] <JEEB> if you want to use specific tools with specific cross-prefixes you use...
[18:57] <Tr4sK> ok
[18:58] <Tr4sK> JEEB: thanks, that's my second build, worked out of the box on my first test ./configure; make
[18:58] <JEEB> --cross-prefix=x86_64-redhat-linux-
[18:58] <JEEB> that will use specifically x86_64-redhat-linux-*
[18:58] <JEEB> oh wait
[18:58] <JEEB> gnu there too :P
[18:58] <JEEB> but yeah, you get the gist
[18:59] <JEEB> it will then append gcc/ld/g++/whatever after the dash
[18:59] <JEEB> --cross-prefix=x86_64-redhat-linux-gnu-
[18:59] <JEEB> you will have to set --arch and --target-os as well if you start using that of course
[19:00] <bigeast> q
[19:05] <Tr4sK> JEEB: Ok I got it. Do you know how can I tell that to my SPEC file ?
[19:06] <JEEB> no, I have no idea of the variable for that :P
[19:06] <Tr4sK> JEEB: the issue is that I don't know how to tell autoconf to remove the --host option
[19:07] <Tr4sK> through the SPECS file
[19:07] <JEEB> you don't fucking use the thing that automagically tries to use autoconf shit
[19:07] <JEEB> rather call the configure script as usual
[19:07] <JEEB> and maybe set prefix and other things
[19:07] <JEEB> so it installs to the correct spot
[19:14] <angrybb> ok, thanks for info. I have one more question. Is ffserver safe to use or is it obsolete?
[20:03] <witheld> I'm on Ubuntu and trying to configure with ./configure --disable-ffplay --disable-ffprobe --disable-ffserver --enable-libfaac --enable-libmp3lame --enable-libv4l2 --enable-libx264 --enable-x11grab --enable-libpulse --enable-librtmp --enable-gpl --enable-nonfree --disable-yasm --extra-libs="-lasound"
[20:04] <witheld> But I'm getting "ERROR: librtmp not found using pkg-config" even though that package is installed, and pkg-config is aware of it
[20:04] <JEEB> time to look at config.log :P (pastebin it)
[20:05] <llogan> witheld: or just remove --enable-librtmp. ffmpeg has native support, but i'm not sure if librtmp is better or not
[20:05] <JEEB> the libavformat support should generally be better or on par
[20:06] <llogan> witheld: why --disable-yasm?
[20:06] <JEEB> unless you have built a version with protocol 10 support yourself from DMCA'd sources
[20:06] <JEEB> because he has no idea what that does, most probably
[20:06] <JEEB> :P
[20:06] <witheld> Solved it by looking at that log, thanks
[20:06] <witheld> gnutls wasn't installed
[20:09] <witheld> And building, awesome
[20:10] <JEEB> are you building for something not x86?
[20:10] <JEEB> also let me remind you that if you want to use an aac encoder that requires enable-nonfree I recommend fdk-aac
[20:10] <JEEB> https://github.com/mstorsjo/fdk-aac
[20:10] <JEEB> better than faac and similarly not compatible with (L)GPL as faac :P
[20:11] <Tr4sK> JEEB: thx, it worked :D
[20:11] <JEEB> witheld, basically you should only be using disable-yasm if you are building for something that isn't intel based
[20:12] <Tr4sK> witheld: apt-get install yasm
[20:12] <JEEB> otherwise you will be getting a really high speed penalty
[20:12] <JEEB> because you're effectively disabling most of the handwritten optimizations
[20:38] <MvL> Hi, I'm trying to copy a dts stream and encode the dts stream to ac3 of a mkv file. How do I combine this?
[20:38] <MvL> i can do -c:a ac3 -b:a 640k for converting
[20:49] <MvL> i think i have it!
[20:49] <MvL> with the -map option...
[22:36] <nomnomdeguerre> Hey there. I'm having some trouble streaming a video using ffmpeg and ffserver
[22:36] <nomnomdeguerre> segmentation fault ffmpeg -i movie.mp4 http://localhost:8090/feed1.ffm
[22:37] <nomnomdeguerre> ffserver is up and running
[22:37] <nomnomdeguerre> and I can play movie.mp4 just fine
[22:38] <klaxa> maybe also include your ffserver.conf
[22:41] <nomnomdeguerre> http://pastebin.com/vjBHahvE
[22:45] <DeadSix27> for a never-before ffmpeg on linux user, are there prebuild ffmpeg binaries of the git?
[22:45] <DeadSix27> (like Zeranoe does on windows)
[22:46] <Mavrik> yep
[22:46] <Mavrik> see topic.
[22:46] <Mavrik> uh
[22:46] <Mavrik> or not.
[22:46] <Mavrik> DeadSix27, ffmpeg homepage, download -> linux -> static builds
[22:47] <klaxa> nomnomdeguerre: wow i don't think that should happen
[22:48] <klaxa> nomnomdeguerre: can you try it again with the latest git?
[22:48] <DeadSix27> :p thx
[22:49] <nomnomdeguerre> I tried it with 2.5.3, and it didn't work, so I'm using 2.5.2 that can be installed with brew (on a mac)
[22:49] <nomnomdeguerre> is there another way I can try to find the issue besides using another version of ffmpeg? perhaps streaming it in another version, or converting it to some other video encoding?
[22:51] <Mavrik> a segfault message really isn't enough to tell you what's wrong
[23:37] <errnick> Hi! Please someome tell me how I can convert videos with the same quality
[23:37] <errnick> I usually first exiftool the source and -b:v #
[23:38] <errnick> but this looks rather awkward
[23:41] <hetii> Ho
[23:41] <hetii> hi :)
[23:42] <hetii> I try play with some mp4 frame player.
[23:43] <hetii> Original file that is stored is in such format: http://pastebin.com/cpZ7dzip
[23:43] <klaxa> errnick: "same quality" is very subjective
[23:43] <hetii> based on it i build second file: http://pastebin.com/DtQ8qetr
[23:44] <hetii> by command ffmpeg -i a.avi -s 320x240 -vcodec mjpeg -acodec adpcm_ima_wav -ab 192k -ar 22050 output.avi
[23:44] <klaxa> it also depends on what codec you want to use
[23:44] <errnick> klaxa: same video bitrate would be enough :)
[23:44] <hetii> And then my device show that file format is wrong
[23:44] <hetii> any clue how to decode it to the same format
[23:44] <hetii> and then from other video formats?
[23:44] <constantineI> Hello, does anyone have experience converting WTV (Windows Media Center) container format to mpg, etc???
[23:45] <constantineI> I converted it but the audio didn't work
[23:45] <errnick> klaxa: if the bitrate is similar then it can't be much worse - I guess
[23:45] <klaxa> depends on the codec
[23:45] <errnick> klaxa: I'm thinking about theora
[23:46] <klaxa> err... i think theora is pretty obsolete
[23:46] <errnick> GNU team really advertise it
[23:46] <klaxa> hetii: can you explain what exactly you are trying to do?
[23:47] <klaxa> vp8 and vp9 are both open-source now
[23:47] <errnick> klaxa: now they are in h264
[23:47] <klaxa> if you want a royalty-free video codec those are probably the more sane choices
[23:47] <errnick> royalty-free without messing up the quality :)
[23:48] <hetii> klaxa: I have some player from card like in this site http://www.alternatasha.com/2012/07/hacking-a-video-greeting-card/
[23:48] <hetii> and I try put some youtube movie on it
[23:48] <klaxa> oh that's pretty neat
[23:49] <hetii> for beggining I try reconvert original file that was there to the same file
[23:49] <hetii> to see if ffmpeg are able to genereate the same type of file
[23:49] <hetii> if this success then I will try convert from other type of input
[23:50] <hetii> but as I said currently device show format error on any other file that I put
[23:50] <hetii> expect original one
[23:50] <errnick> klaxa: can I add multiple files to the ffmpeg or I have to use FOR?
[23:51] <klaxa> errnick: what do you want to do? encode multiple vidoes independently? using a loop would probably be easier (so yes, use for)
[23:52] <errnick> I have lots of .MTS files, I'd like to make lots of OGV files
[23:52] <errnick> with the ~same quality
[23:53] <klaxa> hetii: >Duration: 00:00:00.09, start: 0.000000, bitrate: 1284364 kb/s
[23:53] <klaxa> this looks like it's non-standard
[23:53] <klaxa> or not supported or something
[23:53] <klaxa> that's from the original file
[23:53] <hetii> yep
[23:53] <hetii> how to produce such file?
[23:54] <hetii> btw vlc generate segmentation fault when I try play this file by it
[23:54] <klaxa> haha what
[23:54] <hetii> in tomtom its played ok
[23:54] <klaxa> i don't think it will be possible (without a patch) to produce a (seemingly) broken file
[23:55] <hetii> maybe its some way how they protect to put other file types
[23:55] <klaxa> i think the easiest way would probably be to try out that third-party windows tool and see if it runs with wine
[23:55] <klaxa> probably
[00:00] --- Tue Feb 3 2015
1
0
[03:46] <jamrial> 158730 decicycles in sao_edge_filter_8, 32768 runs, 0 skips
[03:46] <jamrial> 6422 decicycles in ff_hevc_sao_edge_filter_32_8_ssse3, 32764 runs, 4 skips
[04:08] <cone-465> ffmpeg.git 03Christophe Gisquet 07master:cb335b3af202: dvenc: fix 2x4x8 (interlaced) weight table
[05:47] <Timothy_1u> jamrial: WTF gcc
[12:33] <cone-594> ffmpeg.git 03Paul B Mahol 07master:01a3c5dae0e0: avcodec/put_bits: remove unneeded #include, there are no assert()
[12:33] <cone-594> ffmpeg.git 03Paul B Mahol 07master:021c0c5f5246: avcodec/motion_est: remove unneeded #include, there are no assert() only av_assert*
[13:34] <cone-594> ffmpeg.git 03Luca Barbato 07master:f726fc21ef76: ogg: Provide an option to offset the serial number
[13:34] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:9bacb576bcdf: Merge commit 'f726fc21ef76a8ba3445448066f7b2a687fbca16'
[13:57] <JEEB> ubitux, I guess those dithering algos could be of use with this kind of stuff as well https://twitter.com/marcan42/status/561736363259600896
[14:24] <wm4> weeaboos everywhere
[14:34] <cone-594> ffmpeg.git 03Rémi Denis-Courmont 07master:60392480181f: mem: fix pointer pointer aliasing violations
[14:34] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:fa73358c9bfd: Merge commit '60392480181f24ebf3ab48d8ac3614705de90152'
[14:56] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:e912f45b8165: avformat/oggenc: Simplify by using OFFSET and PARAM
[14:59] <dhead666_> hi, I'm trying to add to support to set the service type of mpegts, and was asked to use consts, what do you think about this? https://github.com/dhead666/FFmpeg/commit/048fb759cee70783d5e69f58df7d092a2…
[15:00] <dhead666_> p.s. I'm not sure how to add the list properly to doc/muxers.texi
[15:42] <ubitux> JEEB: maybe :)
[15:42] <ubitux> dhead666_: you can use an enum
[15:42] <ubitux> so that specs only define 3>
[15:42] <ubitux> ?
[15:43] <ubitux> "Set service_type field." you might want a better description for each field
[15:43] <ubitux> the limits are not correct anymore
[15:44] <dhead666_> ubitux: no the specs defines too many, but I think these are the most useful, the rest can still be send by just using the hex value
[15:44] <ubitux> "too many"? how much exactly? 20, 30?
[15:45] <wm4> it's fine, ffmpeg produces broken and invalid files all the time anyway
[15:45] <dhead666_> this is my updated commit https://github.com/dhead666/FFmpeg/commit/1f56b68bf6d808eaabd798d5b2d7dd519…
[15:45] <ubitux> dhead666_: you can remove the "Set service_type field as " for values
[15:46] <ubitux> "digital_radio", "Digital Radio" is fine for these constants
[15:46] <ubitux> dhead666_: you can check output with ./ffmpeg -h muxer=mpegts
[15:48] <ubitux> dhead666_: if you want an example for the documentation, look for "The following values are recognized" into that doc file
[15:49] <dhead666_> ubitux: :)
[17:06] <dhead666_> ubitux: how about this? https://github.com/dhead666/FFmpeg/commit/f07eee96c076c1f13d081e91d49c00445…
[17:10] <ubitux> dhead666_: s/default 0x01, max 0xff/default @var{digital_tv}/
[17:10] <ubitux> no more comment from me
[17:12] <dhead666_> ubitux: what is this, sed notation ?
[17:13] <ubitux> yes
[17:13] <ubitux> replace "default 0x01, max 0xff" with "default @var{digital_tv}"
[17:15] <dhead666_> haha, I can't believe I knew that, linux truely affects me, I should have said that I'm not really a developer ;)
[17:15] <ubitux> sorry
[17:16] <dhead666_> ubitux: no biggy, thank you very much for all your help :)
[17:31] <cone-594> ffmpeg.git 03Carl Eugen Hoyos 07master:f018b1f3a0f1: Support YA16 in jpeg 2000.
[17:39] <durandal_1707> so ffmpeg was not present on this year fosdem?
[17:48] <cone-594> ffmpeg.git 03Paul B Mahol 07master:d0045312c345: avfilter/vf_dctdnoiz: Use av_malloc_array()
[18:03] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:0182e5a740ff: avcodec/nellymoserenc: replace assert by av_assert1()
[19:25] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:61aca123fb30: avcodec/h261dec: Fix exported MVs for skipped MBs
[19:25] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:0ff8fe10f2c3: avcodec/h261enc: Fix number suffix
[19:25] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:4b15bba2aec9: avformat/utils: Fix number suffixes in tb_unreliable()
[19:46] <cone-594> ffmpeg.git 03James Almer 07master:65e6ab0c5a9f: hevcdsp: remove unused parameter from sao_band_filter
[19:46] <cone-594> ffmpeg.git 03James Almer 07master:2929e5600613: hevcdsp: replace the SAOParams struct parameter from sao_band_filter
[20:12] <wm4> is there a way to stop libavformat doing "approximate" seeks in raw files, like estimating time by bitrate?
[20:13] <wm4> I'm seriously thinking about working around the shit seek API by doing my own incremental indexing on top of it and then using byte seeks, but that would suck
[20:13] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:c77cc2c17666: swresample/dither: Cleanup number suffixes
[20:14] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:b4ad2853c50d: avcodec/dxtory: Use LL instead of L number suffix
[20:14] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:fc3cdb00d084: avformat/matroskadec: Fix number suffixes
[20:14] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:465f3705b1ef: avformat/smacker: Fix number suffix
[20:14] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:f1f7f5903ab4: avformat/omadec: fix number suffix
[20:14] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:592ba6ec1062: avcodec/h264_cabac: use int instead of long for mbb_xy
[20:14] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:4531e2c489d2: avcodec/mpegvideo_enc: Fix number suffixes in rc_buffer_size calculation
[20:23] <akira4> ubitux, could you have a look at this diff? http://pastebin.com/Liwdzp3K.
[20:25] <ubitux> does it work?
[20:28] <ubitux> did you try hardcoding a style first? something like char **list[] = {"FontName=Times","FontSize=70",NULL} to see if at least this part behaves correctly?
[20:28] <ubitux> make a loop to print your list
[20:28] <ubitux> to make sure it's constructed correctly
[20:28] <ubitux> (assuming it doesn't work)
[20:28] <akira4> it works.
[20:28] <akira4> but the font color doesnt change
[20:29] <akira4> for eg if Itry ./ffmpeg -i test.avi -vf "subtitles=testing.srt:force_style='FontName=Arial,Underline=-1,Italic=-1,FontSize=29,PrimaryColor=255'" out.avi
[20:29] <akira4> I don't see any change in the font color but the other things are implemented.
[20:30] <ubitux> what's 255?
[20:30] <ubitux> look at the ASS on how to specify a color
[20:30] <ubitux> it's something like &Hsomething
[20:30] <ubitux> iirc
[20:31] <ubitux> http://docs.aegisub.org/manual/ASS_Tags
[20:33] <akira4> I've tried it. Doesnt work.
[20:33] <ubitux> does it make a difference if it's not the last entry?
[20:34] <ubitux> what did you try exactly?
[20:34] <akira4> ./ffmpeg -i ~/test.avi -vf "subtitles=$HOME/testing.srt:force_style='PrimaryColor=&HFF000000'" ~/out.avi
[20:34] <ubitux> ah btw, it's Colour, not Color
[20:34] <akira4> :'(
[20:34] <ubitux> ;)
[20:34] <akira4> my bad. Thanks
[20:35] <ubitux> can't you have only 1 call to av_strtok?
[20:36] <ubitux> same question for realloc (if you always have 1+x)
[20:37] <akira4> hmm.
[20:37] <akira4> yeah. I'll try using one. Its better that way.
[20:37] <ubitux> btw, we have av_dynarray* functions
[20:38] <ubitux> which might simplify this
[20:38] <akira4> Oh. I'll check them out.The font color changes now :D
[20:38] <ubitux> :)
[20:39] <akira4> I'll try making the code more optimized then. Thanks :)
[22:45] <ubitux> we don't have any ktree implementation in ffmpeg, right?
[22:47] <cone-594> ffmpeg.git 03Michael Niedermayer 07master:36adfa32748f: tests/utils: Remove unneeded L suffix
[22:49] <ubitux> kdtree* sorry
[22:49] <ubitux> (for k=3 in particular... :P)
[23:34] <kurosu__> michaelni, jamrial: Fabrice Bellard's patch for sao buffers that I adapted: https://github.com/kurosu/ffmpeg/commit/717da8896deccf163a8428c6684b5f6c5b7…
[23:34] <kurosu__> the only noteworthy change is adapting it to our sao dsp and abusing an already existing buffer
[23:38] <jamrial> regarding the "XXX" comment in sao_edge, that's already taken care of in the sao_edge asm patchset i'm going to send later
[23:38] <kurosu__> I could rewrite the commit message to actually explain what it does, seeing how it is already a hotchpotch
[23:38] <kurosu__> ok
[23:39] <kurosu__> I'll submit the above when the patchset you sent is applied, as it depends on it
[23:48] <jamrial> michaelni: is the patchet in the ml ok to apply?
[23:54] <kurosu__> good night
[23:56] <michaelni> jamrial, should be ok
[00:00] --- Mon Feb 2 2015
1
0
[01:21] <grepper> anyone have experience in reading mpv's y4m output from a pipe? I get black video, though ffmpeg doesn't complain using -f yuv4mpegpipe -i video.y4m (named pipe)
[01:45] <grepper> if it helps, the header reads: YUV4MPEG2 W720 H480 F24000:1 Ip A853:720 C420jpeg XYSCSS=420JPEG
[01:45] <grepper> -f yuv4mpegpipe should handle this , no?
[08:02] <relaxed> grepper: this works, mpv input.mkv --end 10 --of=yuv4mpegpipe -o - --no-audio --oautofps --oneverdrop 2>/dev/null | ffmpeg -f yuv4mpegpipe -i - -y out.avi
[08:05] <grepper> relaxed: ah, thanks! I was just in the midst of doing a case statement converting integer/float fps numbers to ratios for yuvfps (for mpeg2enc)
[08:05] <grepper> if it works for ffmpeg, avconv, mpeg2enc that is awesome
[08:06] <grepper> I'll test tomorrow
[08:06] <grepper> strange and too bad the y4m output doesnt work, -o foo.y4m would be simple
[08:07] <relaxed> why doesn't it work?
[08:07] <grepper> comes out black video, but no complaints from ffmpeg or avconv
[08:07] <grepper> same for mpeg2enc actually
[08:07] <grepper> perhaps the header is non-standard
[08:07] <relaxed> you mean straight y4m from mpv?
[08:08] <grepper> yep
[08:08] <grepper> mplayer2 header "YUV4MPEG2 W640 H360 F25:1 Ip A1:1" ( this one works fine)
[08:08] <grepper> mpv header: "YUV4MPEG2 W720 H480 F2997:100 Ip A853:720 C420jpeg
[08:10] <grepper> I would assume that --of=yuv4mpegpipe gives the same output as -vo yuv4mpeg:file=out.yuv
[08:10] <grepper> in mplayer
[08:48] <emilsedgh> I use ffmpeg to stream an mp4 file to a server. The problem is, in ffmpeg's output, the 'time' parameter passes too fast.
[08:48] <emilsedgh> fps=203 q=28.0 size= 30154kB time=00:04:26.51 bitrate= 926.8kbits/s
[08:49] <emilsedgh> the time parameter goes like twice or 3x the speed
[08:49] <emilsedgh> anyone has any ideas?
[08:49] <pzich> You might want to try the -re flag
[08:49] <emilsedgh> thanks pzich
[08:50] <pzich> I've not actually done any streaming with ffmpeg, but that's what I've heard about before, read more at https://trac.ffmpeg.org/wiki/StreamingGuide
[08:51] <emilsedgh> thanks pzich.
[09:00] <emilsedgh> pzich: that totally fixed my issue. thank you again.
[09:00] <pzich> no problem, glad I could help
[12:49] <Zerowalker> I need help with compiling ffmpeg for 64bit
[12:49] <Zerowalker> Is this the right place?
[18:06] <yrc> Hi, I have a mp4 file that is about 2 hours long, but ffmpeg reports it to be 3:47 long! The file plays fine in video players though... Do you have an idea of what ffmpeg command could fix the file? I tried -map_metadata -1 -c copy, but the resulting file still has the same problem.
[18:07] <yrc> (3:47 : 3h47m)
[20:49] <Youssarian> Does anyone know the current repository for ffmpeg so I can get installed into Linux Mint 17.1 ?
[20:51] <c_14> If you can pull from sid, it's in there.
[20:53] <ac_slater_> hey all. I'm working with libavformat, not really with the ffmpeg binary. What does the `start_pts` of a frame really represent? In a specific mpegts container I'm looking at, all streams have a non-zero start_pts. Any help?
[21:03] <Youssarian> c_14: Yeah, I don't have sid added. Do you know the correct ppa address?
[21:12] <c_14> Youssarian: try this one https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media
[21:13] <Mavrik> ac_slater_, of a frame or of a packet?
[21:18] <ac_slater_> Mavrik: good question. When I run `ffprobe -i vid.mts -show_streams` I see that field. I realized there isnt a field called that in AVPacket or AVFrame
[21:19] <ac_slater_> Mavrik: in ffprobe.c , I see it links to AVStream::start_time
[21:19] <Mavrik> ah
[21:19] <Mavrik> that's probably the PTS of the first packet in stream
[21:19] <ac_slater_> yea that makes sense now
[21:20] <Mavrik> mostly relevant for players so they can offset playback timer to 0
[21:20] <Mavrik> e.g. you're playing a dumped stream that starts with timer at 2:33:38.000
[21:20] <Mavrik> and you want to still start counting at 0:00:00 in user interface
[21:20] <ac_slater_> I see. Why would a stream ever not have 0.0 start time?
[21:20] <ac_slater_> in a container, I mean
[21:21] <Mavrik> ac_slater_, as I said
[21:21] <Mavrik> you're receiving a live TV stream
[21:21] <Mavrik> and you grab a piece of it :)
[21:21] <ac_slater_> that good thing is Im working with live, so this is really helpful for me ;)
[21:21] <Mavrik> anything streaming really, most containers don't really care where PTS starts
[21:21] <Mavrik> it's the difference that counts ;)
[21:21] <Mavrik> remember, PTS/DTS can wrap around too :)
[21:21] <ac_slater_> oh god haha
[21:22] <Mavrik> if you have MPEG-TS streams, they're 33bit
[21:22] <Mavrik> and will wrap around at exactly 26 hours and some change
[21:22] <ac_slater_> I'm having a REALLY hard time wrapping my head around muxing a new stream from a live stream ... ie - live transcoding
[21:22] <ac_slater_> that's REALLY helpful, thanks mate
[21:22] <BtbN> It doesn't realy make a difference if it's live or a recording.
[21:22] <BtbN> It's just a realy slow source
[21:23] <Mavrik> yeah, but there are some funny cases you rarely meet in files
[21:23] <Mavrik> like wrong order, packet jitter
[21:23] <Mavrik> and of course, PTS wraparound
[21:23] <ac_slater_> interesting.
[21:23] <Mavrik> I still have to keep a patched version of ffmpeg around because default FLV muxer just stops writing data when PTS wraps :P
[21:24] <ac_slater_> ;)
[21:25] <ac_slater_> so, muxer question. say I have a live source of some video and I want to start muxing it into a mpegts stream for example. Should I start the destination PTS/DTS at 0.0 or some intelligent value from the input?
[21:26] <BtbN> doesn't matter at all.
[21:26] <ac_slater_> BtbN: interesting.
[21:27] <Mavrik> yep
[21:27] <Mavrik> doesn't matter
[21:28] <ac_slater_> next thing. I have a data format (KLV) in which ffmpeg doesnt have an associated encoder/decoder. I really dont care, since I can handle the data myself on the demuxing side. But, when muxing a format that ffmpeg doesnt have a muxer for, how does one handle that.
[21:28] <Mavrik> uh
[21:28] <Mavrik> you basically just don't use ffmpeg then
[21:28] <Mavrik> since it can't help you
[21:29] <ac_slater_> well, I have some containers that have this format, and reading AVPackets from the stream gives me real data
[21:29] <ac_slater_> and ffmpeg have a codec_type and codec_id for it
[21:29] <ac_slater_> it just doesnt have a codec for it
[21:31] <ac_slater_> my real goal is to contribute the encoder/decoder to ffmpeg once I figure out what else I need to do (write a muxer?)
[21:31] <Mavrik> uh
[21:31] <Mavrik> do you have a video format
[21:31] <Mavrik> or actual container?
[21:31] <ac_slater_> container, MPEGTS with h264 and KLV
[21:32] <Mavrik> Muxers are pieces that mux/demux streams into containers and out, you seem to be talking about a codec
[21:32] <ac_slater_> Mavrik: right, just codec, my mistake. MPEGTS is my muxer
[21:34] <ac_slater_> so I guess the question is, say I create a stream with the KLV tags/Ids that ffmpeg has, and start filling AVPackets with some data and do av_write_packet() to my mpegts output format. Does that sound sane?
[21:35] <Mavrik> yes
[21:36] <Mavrik> you'll probably have to check the TS muxer code to see if it properly sets format metadata in stream
[21:36] <Mavrik> since IIRC there are stream type tags in there
[21:36] <ac_slater_> Mavrik: interesting I havent done that yet.
[21:36] <ac_slater_> thanks!
[21:37] <ac_slater_> av_write_* also complains that there is not increasing PTS/DTS.. so I gotta figure that out.
[21:37] <ac_slater_> I guess I could just generate them from my time_base.
[21:39] <Mavrik> yes, pts and dts have to be set properly
[21:39] <Mavrik> you should probably use the same ones as on your input ;_
[21:41] <ac_slater_> I agree. I'm actually taking a live video stream and adding this other stream along with it. When dealing with multiple streams in a single format, do the time_base's have to relate? I wouldnt think so.
[21:58] <gcl5cp> encoding a mkv multi audio tracks, i want to loud first track
[21:58] <gcl5cp> -map 0:1 -map 0:2 -c:a ... -af volume=5dB -c:a ...
[21:59] <gcl5cp> but both are amplificated
[21:59] <gcl5cp> mean_volume: -33.1 dB
[21:59] <gcl5cp> max_volume: -3.0 dB
[21:59] <gcl5cp> mean_volume: -26.4 dB
[21:59] <gcl5cp> max_volume: -1.8 dB
[21:59] <gcl5cp> original are
[21:59] <gcl5cp> mean_volume: -36.1 dB
[21:59] <gcl5cp> max_volume: -5.4 dB
[21:59] <gcl5cp> mean_volume: -29.4 dB
[21:59] <gcl5cp> max_volume: -4.7 dB
[21:59] <c_14> Use a pastebin service.
[22:00] <c_14> try giving it an actual track to work on
[22:00] <c_14> -filter_complex '[0:1]volume=5dB[a]' -map '[a]' -map 0:2
[22:02] <gcl5cp> thank c_14
[22:03] <c_14> np, and just for future reference, if you're going to be pasting more than 3 lines, use a pastebin service and paste the link
[22:13] <gcl5cp> sorry, i should format before paste like
[22:13] <gcl5cp> before= mean: -36.1, max: -5.4, mean: -29.4, max: -4.7
[22:13] <gcl5cp> after = mean: -33.1, max: -3.0, mean: -26.4, max: -1.8
[22:17] <yarekt> Hi. Could someone help me convert a flac audio file to something that my TV will play, please?
[22:18] <yarekt> It can play AC3 and DTS, but I can't find a way to encode things into DTS (decode only codec)
[22:19] <c_14> ffmpeg -i flac -c:a ac3 out.ac3
[22:20] <yarekt> -c:a ?
[22:21] <c_14> Sets the codec for the audio streams
[22:21] <yarekt> Unrecognized option 'c:a' =(
[22:21] <yarekt> says ffmpeg is deprecated as well
[22:22] <yarekt> I'm using ffmpeg version 0.8.13-4:0.8.13-0ubuntu0.12.04.1
[22:22] <c_14> You can grab a static build of ffmpeg from FFmpeg at:
[22:22] <c_14> http://johnvansickle.com/ffmpeg/
[22:23] <yarekt> hmm, is ffmpeg better than avconv then?
[22:23] <c_14> Let's not go into that argument.
[22:24] <yarekt> Hah, no, i don't mean it like that
[22:24] <c_14> This channel supports ffmpeg from FFmpeg only, if you want support for avconv #libav is your friend.
[22:24] <yarekt> Thanks c_14
[22:25] <yarekt> Thats a very bad move from ubuntu, providing that compabibility binary =(
[22:26] <c_14> Recent versions of libav don't have that binary anymore, so it's mainly just with ancient versions of libav.
[22:27] <grepper> thanks c_14
[22:45] <grepper> er, sorry, wrong nick and channel, but thanks just the same :)
[22:56] <gcl5cp> yarekt: for ubuntu i recommend ppa:djcj/hybrid
[22:57] <gcl5cp> and ppa:djcj/vlc-stable
[22:58] <gcl5cp> then install ffmpeg vlc. Note: audacity has problems with libaac inside that repo.
[23:23] <Youssarian> c_14: Thanks for the help. I figured it out by copying code from the description at: https://www.youtube.com/watch?v=7OI86rSyEuY
[23:23] <Youssarian> https://pastee.org/ebtm7
[23:23] <Youssarian> Thanks again. :)
[00:00] --- Mon Feb 2 2015
1
0
[01:27] <jamrial> not sure if i want to try it, to be honest. this function as you said is not that heavy in the decoding, so a potentially more efficient approach will probably not matter enough to be worth figuring it out
[01:28] <jamrial> and i'm more interested in trying to port sao_edge_filter
[02:06] <cone-65> ffmpeg.git 03Michael Niedermayer 07master:be2ebc723d1f: avcodec/ratecontrol: replace asserts by av_asserts
[02:46] <cone-65> ffmpeg.git 03Michael Niedermayer 07master:f5722ba276e5: libavcodec/h264: replace assert() by av_assert0()
[05:13] <cone-65> ffmpeg.git 03Michael Niedermayer 07master:9f73b88c624a: avcodec/h261enc: fix dquant encoding
[10:34] <cone-104> ffmpeg.git 03Paul B Mahol 07master:335c150ba1d2: avcodec/svq1dec: remove unneeded #include, there are no assert()
[10:34] <cone-104> ffmpeg.git 03Paul B Mahol 07master:bc74f946bc94: avcodec/vc1: remove unneeded #includes, there are no assert() only av_assert*
[10:34] <cone-104> ffmpeg.git 03Paul B Mahol 07master:43630c82f1b0: avformat/utils: remove unneeded #include, there are no assert() only av_assert*
[10:35] <cone-104> ffmpeg.git 03Paul B Mahol 07master:ca8617a04d32: avformat/mpeg: remove unneeded #include, there are no assert() only av_assert*
[10:35] <cone-104> ffmpeg.git 03Paul B Mahol 07master:12c5addebc66: avformat/asfenc: remove unneeded #include, there are no assert() only av_assert*
[10:35] <cone-104> ffmpeg.git 03Paul B Mahol 07master:41456c7d159d: avformat/mux: remove unneeded #include, there are no assert() only av_assert*
[10:35] <cone-104> ffmpeg.git 03Paul B Mahol 07master:cc1357a17313: avformat/mov: remove unneeded #include, there are no assert()
[10:35] <cone-104> ffmpeg.git 03Paul B Mahol 07master:f705b1287bbd: avformat/movenc: remove unneeded #include, there are no assert() only av_assert*
[11:36] <cone-104> ffmpeg.git 03Stefano Sabatini 07master:fbccbd68325a: lavd/libcdio: apply minor fixes to options documentation
[11:37] <cone-104> ffmpeg.git 03Stefano Sabatini 07master:c8bec255eff3: lavd/libcdio: add more paranoia mode constants
[11:37] <cone-104> ffmpeg.git 03Stefano Sabatini 07master:f422f474dfa7: doc/indevs/libcdio: apply minor spell fixes, extend documentation
[13:26] <cone-104> ffmpeg.git 03Paul B Mahol 07master:e7e0005cc6c7: remove libmpcodecs
[13:29] <wm4> this calls for a celebration!
[13:45] <cone-104> ffmpeg.git 03Paul B Mahol 07master:a34f4e2fd2e0: avfilter: remove vf_mp.c
[13:52] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:b288f67434db: avfilter/avfilter: Remove CONFIG_MP_FILTER case
[13:56] <ubitux> durandal_1707: configure:enabled mp_filter && prepend avfilter_deps "avcodec"
[13:59] <cone-104> ffmpeg.git 03Paul B Mahol 07master:b47ab04c40ab: configure: remove mp_filter leftover
[14:04] <ubitux> thx
[14:35] <cone-104> ffmpeg.git 03Carl Eugen Hoyos 07master:4faea46bd906: lavc/aarch64: Do not use the neon horizontal chroma loop filter for H.264 4:2:2.
[14:35] <cone-104> ffmpeg.git 03Carl Eugen Hoyos 07master:f9f9ae1b77e4: lavc/arm: Use the neon vertical chroma loop filter also for H.264 4:2:2.
[14:35] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:958836f8c519: Merge remote-tracking branch 'cehoyos/master'
[16:13] <ubitux> TIL tweaking just a bit the palette can change everything http://b.pkh.me/out-dither-sierra2-old.gif http://b.pkh.me/out-dither-sierra2-new.gif
[17:05] <durandal_1707> so how many dithering modes there will be?
[17:29] <ubitux> durandal_1707: for now just 6
[17:29] <ubitux> 1 deterministic (bayer) and 5 misc. error diffusal
[17:30] <ubitux> bayer scale being customizable
[17:30] <ubitux> i'd like to add another deterministic one
[17:30] <nevcairiel> how large of a matrix for bayer do you use?
[17:30] <ubitux> maybe by implementing a void & cluster algorith to make a table of the size of the image itself (assuming that's indeed what it's about)
[17:30] <ubitux> 8x8
[17:31] <ubitux> also there are the other dither which was mentioned by the guy on the mailing-list, which i looked at for a while but haven't in details
[17:32] <ubitux> which might be worth looking at
[17:32] <nevcairiel> there were some good results in the still images on that website at least
[17:32] <nevcairiel> i looked over it some time ago
[17:33] <ubitux> for still image it's really not important, because error diffusal is always better anyway
[17:33] <ubitux> but for animation, your really need a deterministic dithering, otherwise you're doomed (with gif that is)
[17:34] <nevcairiel> well, even for error diffusal there is multiple ways to go about it .. just spread the error perfectly mathematically, or account for visual attributes, gamme weighted color comparisons etc
[17:35] <ubitux> yeah i need to look deeper at what he did
[17:35] <ubitux> right now i'm back to trying to improve the palette
[17:35] <ubitux> because the implementation i use has many flaws/limitations
[17:36] <ubitux> it's interesting, i'm looking at a paper which is basically presenting itself like an improvement of the original algorithm i implemented
[17:36] <ubitux> so the original algorithm is saying "we need to make an histogram of the 24-bit rgb colors"
[17:36] <ubitux> "but it's too much so we're going to make a 5:5:5 histograms (16-bits)"
[17:36] <ubitux> and so the new paper comes with a brillant idea
[17:36] <ubitux> "hey let's use 6:6:6, it's really way better"
[17:37] <ubitux> "well it takes a lot more memory but hey, who cares"
[17:37] <ubitux> "also 18-bit is not easy to deal with so we'll actually store them on 16-bit memory and make them overlap"
[17:38] <ubitux> i wonder why the hell they didn't just suggest a simple hash table to use as histograms
[17:38] <ubitux> (which i'm currently trying to implement)
[17:39] <iive> 18 bits is just 262144 combinations, so with 32bit int it would take 1MB ram
[17:40] <ubitux> how do you make a 18-bit values histogram without having to use a 32-bit type?
[17:41] <iive> you use the r6g6b6 as index in a simple array
[17:41] <iive> the array would contain how many times the color is used.
[17:41] <ubitux> ah yeah my bad, misread
[17:41] <iive> that's histogram, isn't it?
[17:42] <ubitux> they were talking about the counter
[17:42] <iive> yeh, mybad
[17:42] <ubitux> so int16_t hist[1<<18]
[17:42] <ubitux> crossing fingers that it will be enough
[17:44] <ubitux> anyway, so basically the revolutionary idea of the paper is to do int32_t hist[1<<15] int16_t hist[1<<18];
[17:44] <iive> you may want to try giving one more bit to the green. or doing something in other colorspace... e.g. histogram for luma...
[17:44] <iive> ^_^
[17:45] <ubitux> yes i thought about that
[17:45] <ubitux> doing a 565
[17:45] <ubitux> but... it's starting to be slightly annoying for the algorithm to have mismatching scales
[17:45] <iive> rgb24 is 16M combinations, so it would take an array of 64MB. it's not much memory for modern computer, even a pocket one.
[17:46] <ubitux> i don't like the idea of allocating that much memory
[17:46] <ubitux> for... gif generation? really? :P
[17:46] <ubitux> anyway, the hash table with full resolution and less memory will do
[17:47] <iive> well, some people take their gifs very seriously! ;)
[17:47] <iive> but i'm more afraid that 64MB may slow down the algorithm.
[17:47] <wm4> <ubitux> i don't like the idea of allocating that much memory <- merely loading ffmpeg into the address space allocates that much dirty pages
[17:47] <wm4> at least if you enable all deps
[17:47] <wm4> fucking bloat everywhere
[17:48] <wm4> so don't waste braincell on mircooptimizing memory usage for gif generation
[17:48] <wm4> it's just absurd
[17:48] <BtbN> Shouldn't it delay load the unused ones?
[17:48] <wm4> BtbN: C++ constructors, dude
[17:48] <wm4> at least that's my bet
[17:48] <wm4> you can have lib ctors in C too, but these are obscure enough that libs normally avoid them
[17:49] <BtbN> Yes, those run when the library is loaded, which shouldn't happen before the first function call into them. At least i think so.
[17:49] <wm4> doesn't stop shitlibs like gnutls (or whatever it waS) of course
[17:49] <wm4> BtbN: I don't think so
[17:49] <ubitux> wm4: except that... the histogram is for several frame, so i might want to go up to int64_t for the histogram count
[17:49] <ubitux> and then i need a second index of all the colors
[17:50] <ubitux> if they're all different, i need a 1<<24 tabs again, and not 64 bits again
[17:50] <ubitux> so well, it's starting to be a lot
[17:50] <ubitux> the hash table model really isn't complicated for this case
[17:50] <ubitux> i just use a downsampled color as the hash key, then have a simple list
[17:51] <ubitux> that doesn't require much code
[18:48] <compn> mpcodecs is gone? can we merge ffmpeg and libav back together again? :P
[18:51] Action: funman approves
[18:52] <jamrial> there's still the swr and avr deathmatch :p
[18:52] <ubitux> then let's do the same as libmpcodecs
[18:52] <ubitux> let's drop avr
[18:54] <jamrial> that means ffmpeg will not work as a drop in replacement for libav anymore
[18:54] <jamrial> and distros that ship both projects will hate us
[18:55] <ubitux> :)
[18:55] <compn> is it not possible to make some kind of interoperability wrapper ?
[18:55] <compn> to have both api at once
[18:55] <compn> nevermind i think we have that already
[18:55] Action: compn stops caring about this
[18:56] <iive> jamrial: you can have ffmpeg and libav installed at the same time...
[18:57] <ubitux> iive: not easily
[18:57] <iive> i even proposed a patch to allow moving include files too.
[18:57] <jamrial> the distros i remember checking don't do that. they install one or the other, using the same library names
[18:57] <BtbN> The new debian approach allows to install both at the same time.
[18:57] <iive> well, we do that for debian.
[18:58] <BtbN> But only the runtime files. Only one -dev package can be installed at a time.
[18:58] <BtbN> It does that by simply renaming the libraries.
[19:05] <cone-73> ffmpeg.git 03Zhang Rui 07master:ca2e3e47fc6f: avformat/cache: pass options to the underlying protocol via the url_open2
[19:15] <wm4> <jamrial> that means ffmpeg will not work as a drop in replacement for libav anymore
[19:15] <wm4> jamrial: as a big FUCK YOU from the ffmpeg developers to the user, lavr is already not built by default
[19:16] <wm4> so if you want to write code that works out of the box, you need to support both lavr and lswr
[19:18] <iive> wm4: why the strong language? just an hour ago you were complaining about all the bloat in ffmpeg... a duplicate library built by default...
[19:19] <wm4> iive: I always use strong language, don't read too much into it
[20:00] <cone-73> ffmpeg.git 03Michael Niedermayer 07master:b9c3f041e029: avcodec/h261enc: Avoid casts, Simplify code
[20:00] <cone-73> ffmpeg.git 03Michael Niedermayer 07master:3aefa1eb69c4: avcodec/h261enc: More specific return code
[21:27] <ubitux> ok, moving to full resolution histograms definitely helped getting better palettes
[21:27] <ubitux> damn, it's almost looking good now
[21:27] <ubitux> let's improve even more..
[21:30] <cone-73> ffmpeg.git 03Michael Niedermayer 07master:b80106169ab1: avcodec/motion_est: Set subcmp consistently for H261
[21:31] <iive> ubitux: ENHANCE!
[21:31] <ubitux> ;)
[21:31] <iive> :)
[22:05] <cone-73> ffmpeg.git 03Andreas Cadhalpun 07master:2a3b7a55b511: examples/demuxing_decoding: set stream_idx in open_codec_context only if no error occured
[22:28] <wm4> can lavf/lavc encode video with parameter changes yet?
[22:29] <nevcairiel> some encoders can
[22:30] <nevcairiel> x264 can to some degree afaik
[22:32] <wm4> so there's an API for this?
[22:35] <nevcairiel> you just change what you want to change, and send the next frame, although the things it can change on the fly seems limited to aspect ratio, bitrate/crf/..., interlaced flags, everythign else you need to re-open the encoder apparently
[22:36] <nevcairiel> not sure if those were just added because someone wanted them, or because the others are not supported
[22:37] <nevcairiel> but only re-opening the encoder isnt that much trouble either really, as long as you output into a format that likes inline sps/pps changes..
[22:39] <wm4> hm
[00:00] --- Sun Feb 1 2015
1
0
[01:31] <fahadash> hello
[01:32] <fahadash> I have learned to concatenate multiple MP3 files in a series and save it as 1 mp3 using FFMPEG... but I also found out that if I use a simple copy command to concatenate the binary contents of the file and string them together into one file, they still work just as well. What does FFMPEG do different and what is recommended ?
[01:34] <pzich> fahadash: it probably cleans up whatever messed up headers you get by concatenating as binary files
[01:35] <pzich> also, just because *something* can play the concatenated files doesn't mean any player can
[01:35] <fahadash> so you recommend concatenation using ffmpeg as opposed to copying ?
[01:36] <pzich> absolutely
[01:36] <fahadash> Thank you
[12:38] <blade152> Hi everyone !
[12:38] <blade152> 1st i'm sry for my english, i'm french ^^
[12:39] <blade152> i try to convert mov to mp4 file, but it doesnt work, each commands i find on forums failed
[12:39] <__jack__> paste it
[12:40] <blade152> ffmpeg -i myfile copy myfile.mp4
[12:40] <__jack__> something like that may work: ffmpeg -i source.mov -c copy dest.mp4
[12:41] <blade152> Unrecognized option 'c'
[12:41] <blade152> Failed to set value 'copy' for option 'c'
[12:41] <blade152> i'm a novice ^^
[12:44] <__jack__> hum, are you really using ffmpeg ? seems to be avconv
[12:44] <__jack__> you're using ubuntu ?
[12:45] <blade152> i'm using debian 7
[12:45] <blade152> on a dedicated server
[12:45] <__jack__> ok, same issue : the ffmpeg package is a lie, avconv lives there
[12:45] <__jack__> ok
[12:46] <blade152> ups fail i left the chat
[12:46] <__jack__> you may compile ffmpeg from source, or use the ffmpeg from sid/unstable (better solution)
[12:47] <__jack__> add deb http://ftp.fr.debian.org/debian/ unstable main to /etc/apt/sources.list
[12:47] <__jack__> add APT::Default-Release "wheezy"; (if it is not already done) to /etc/apt/apt.conf
[12:47] <__jack__> then aptitude update, aptitude install -t unstable ffmpeg, and there you are
[12:55] <blade152> i hope it will work
[12:55] <blade152> nopw install done, i try the same command for convert ?
[12:56] <__jack__> yes
[12:58] <blade152> it seems ffmepg not install thats weird
[13:01] <relaxed> blade152: http://johnvansickle.com/ffmpeg/
[13:03] <blade152> thank's relaxed and __jack__ i will try this soon
[13:03] <blade152> have a nice day
[14:12] <blade152> i have download the file from git and extract it, but there is no informations about installation in the readme. Where did i need to put the directory ?
[14:27] <relaxed> blade152: you can run ffmpeg from the directory, ./ffmpeg
[14:28] <relaxed> or move it to your shell's path
[14:32] <blade152> Wooow it works :D thank's man !
[14:33] <relaxed> you're welcome
[19:01] <zap0> how do you rotate a video 90º ?
[19:01] <c_14> -vf transpose=1
[19:03] <zap0> i've tried that. it did not rotate
[19:04] <zap0> ffmpeg.exe -i in.mp4 -vf "transpose=1" out.mp4
[19:05] <c_14> It works for me.
[19:06] <c_14> Pastebin the command output?
[21:06] <kriegerod> hi! i want to make ffmpeg to dump the data stream from MPEG TS. Ffmpeg shows that stream as "unknown" and refuses to "map" it to output, see https://gist.github.com/krieger-od/f9fac489d04463e36ea2
[21:06] <kriegerod> any hints how to do it without patching or coding an app?
[21:09] <c_14> -c:d copy -f data
[21:11] <kriegerod> c_14: thanks for attention, i've tried it, but still it doesn't work. Please check, did i get you right? https://gist.github.com/krieger-od/60e453038f4ecc5f7866
[21:12] <ScottSteiner> Is it possible to burn a subtitle stream into a video using a font attached in the file?
[21:13] <c_14> yes, use the subtitles=file.mkv filter
[21:15] <c_14> kriegerod: hmm
[21:16] <kriegerod> is there an option to treat unknown streams as of data type?
[21:16] <kriegerod> maybe we should add such option
[21:17] <kriegerod> i can share this sample file
[21:17] <kriegerod> it must be just a sample garbage in that stream
[21:19] <kriegerod> c_14: http://whdd.org/test.ts
[21:23] Action: c_14 is going to try locally patching that code path out
[21:23] <c_14> Let's see what happens
[21:31] <ScottSteiner> thanks c_14; is it possible to select which subtitle it is using in that situation?
[21:33] <c_14> :si=
[21:33] <c_14> subtitles=video.mkv:si=1
[21:33] <c_14> for the 1st (second) subtitle stream (probably)
[21:38] <kriegerod> is there a conventional way to mux in a particular binary data stream into MPEG TS to make it appear as "data"-typed stream, available for output with "-c:d copy"
[21:40] <kriegerod> in command line
[21:40] <kriegerod> if possible
[21:51] <c_14> There might be, but I can't seem to find it.
[21:52] <c_14> I can add an arbitrary data stream and mux it to mpegts, but whin I try demuxing it ffmpeg seems to think it's an audio stream and then fails because it isn't.
[21:54] <kriegerod> c_14: i think it's worth a post in ffmpeg-devel, describing my initial issue and your comments
[21:54] <kriegerod> i hope some cool guys come up with easy resolution
[22:59] <kriegerod> c_14: "I can add an arbitrary data stream and mux it to mpegts" - how do you do that in CLI?
[23:00] <kriegerod> c_14: "but whin I try demuxing it ffmpeg seems to think it's an audio" - in my case, with a little patch over ffmpeg_opt.c, it crashes strangely in the place which is actually intended for video streams processing... very strange
[23:13] <kriegerod> uh, updated from upstream git repo and now it crashed for clearer reason
[23:15] <c_14> kriegerod: ffmpeg -i thing.ts -f data -i data -map 0 -map 1 -c copy out.ts
[23:15] <kriegerod> thanks!
[23:17] <kriegerod> indeed, it pretends it's audio
[00:00] --- Sun Feb 1 2015
1
0