[00:48] <swone> is there an 8-bit luma maximum in the ffmpeg code? [00:49] <swone> bad question. i suppose i really meant, is there an 8-bit depth limit in the intermediate phases of exporting 12-bit 4:0:0 data? [00:50] <swone> my ultimate goal is 12-bit monochrome output [00:50] <durandal_1707> what? [00:50] <Daemon404> um [00:51] <swone> is there any way to encode/decode 12-bit monochrome data at full fidelity? [00:51] <Daemon404> what part of "12-bit monochrome" makes any sense? [00:51] <durandal_1707> monochrome is 1 or 0 - 1 bit [00:51] <swone> sure [00:51] <swone> grayscale [00:51] <Daemon404> thats a different thing. [00:51] <swone> right [00:52] <swone> i misused the term, but my question is basically the same [00:52] <durandal_1707> there is 8bit and 16bit single plane gray pixel format [00:53] <durandal_1707> actually it is not planar but packed [00:54] <Daemon404> how can something that is one plane be planar or packed [00:54] <durandal_1707> Daemon404: yes, I feel stupid right now [00:54] <Daemon404> :P [00:55] <swone> so would any of the compression codecs (e.g., x264) be able to use at least 12 bits for luma values? [00:55] <Daemon404> no. [00:55] <Daemon404> x264 is 10-bit max [00:55] <swone> or any other codec, really [00:55] <Daemon404> prores might be able to do 12-bit [00:55] <Daemon404> but i think that icnludes alpha [00:56] <swone> i'm not familiar with that one -- i'll have to read up on it [00:56] <swone> my ultimate goal is 12-bit grayscale interframe compression [00:56] <Daemon404> i dont think ffmpeg's implementation supports 12-bit prores anyway [00:56] <Daemon404> prores is intra only [00:56] <durandal_1707> 4:0:0 does not mean much to me [00:56] <Daemon404> iirc [00:57] <Daemon404> durandal_1707, why not? [00:57] <gnafu> Dirac can do at least 10- and 16-bit: http://www.schleef.org/blog/2012/01/23/new-schrodinger-release/ [00:57] <durandal_1707> it can be packed or planar [00:57] <Daemon404> no it cant [00:57] <Daemon404> 4:0:0 only has one plane. [00:57] <swone> daemon404, yep, looks like ProRes is intra-frame only [00:57] <gnafu> Although, I think that is intra-only right now. There may be 12-bit inter someday, but I don't know. [00:57] <durandal_1707> and swone need 12bit gray, 4:0:0 is not good format [00:57] <Daemon404> well no [00:58] <Daemon404> well 4:0:0 is gray [00:58] <Daemon404> so uh [00:58] <Daemon404> <_< [00:58] <Daemon404> same diff [00:58] <durandal_1707> Daemon404: define 4:0:0 [00:59] <Daemon404> do you understand chroma subsampling notation? [00:59] <swone> isn't it just all luma? [00:59] <Daemon404> yes [00:59] <Daemon404> luma with no chroma [00:59] <swone> ok, well that's what i had meant at least [00:59] <durandal_1707> so how many bits 4:0:0 have? [01:00] <Daemon404> durandal_1707, depends on the bit-depth of course [01:00] <Daemon404> in swone's case, 12 per pixel. [01:01] <durandal_1707> swone: only mjpeg supports 16 bit GRAY [01:01] <swone> excuse my ignorance, but isn't mjpeg also just intra-frame? [01:01] <durandal_1707> ignoring image formats and obviously raw [01:01] <durandal_1707> yes it is [01:01] <Daemon404> durandal_1707, ffv1 can essentially [01:01] <Daemon404> interframe even too [01:02] <Daemon404> but lossless, not lossy. [01:02] <durandal_1707> Daemon404: for pix fmt for ffv1? [01:02] <Daemon404> durandal_1707, pass it a null chroma [01:02] <Daemon404> same deal. [01:02] <durandal_1707> ah ane with 16 bits, rest of planes will be empty... [01:02] <Daemon404> so? [01:02] <Daemon404> itll comrpess to nothing [01:02] <Daemon404> if theyre empty [01:03] <Daemon404> and iirc, ffv1 works on a plane-basis [01:03] <Daemon404> so adding gray support is insanely trivial [01:04] <durandal_1707> would need to add new colorspace [01:04] <Daemon404> no? [01:04] <Daemon404> why would you? [01:04] <Daemon404> (assuming you mean in swscale) [01:04] <durandal_1707> how one could differ between yuv and rgb? [01:04] <Daemon404> [19:03] <+Daemon404> and iirc, ffv1 works on a plane-basis [01:04] <Daemon404> you dont. [01:05] <Daemon404> or maybe for rgb you subtract G fro mR and B [01:05] <Daemon404> and then proceed as normal. [01:05] <durandal_1707> ffv1 already can store 16bit gray lossless just fine and sws will handle lossless conversion. [01:06] <Daemon404> then tehre you go. ffv1 works. [01:06] <durandal_1707> Daemon404: i was more talking about adding direct support [01:06] <Daemon404> define "Direct support: [01:06] <Daemon404> " [01:07] <durandal_1707> adding GRAY16 into encoder input formats [01:07] <Daemon404> like i said [01:07] <Daemon404> thats trivial [01:07] <Daemon404> unless ffv1 has a number of planes hardcoded everywhere liek snow [01:07] <Daemon404> -_- [01:07] <durandal_1707> ffv1 colorspace=0 is YUV, 1, is RGB [01:07] <Daemon404> (snow codes "3" everywhere) [01:08] <Daemon404> it should be pretty simple [01:08] <durandal_1707> and there is transparency symbol for extra 4 plane [01:08] <durandal_1707> Daemon404: but would break compatibility with older decoders [01:08] <Daemon404> well yeah [01:09] <durandal_1707> because ffv1 is lazy and have if else check.... [01:09] <Daemon404> i dont see a problem with just passing it GRAY16 as luma [01:09] <Daemon404> youre not going to lose compression [01:09] <durandal_1707> yes that is alternative and "hacky" [01:10] <Daemon404> it's practical enough for me [01:10] <Daemon404> as long as you can output/input with ease [01:10] <Daemon404> and it works [01:10] <Daemon404> sometimes using what already works is a better idea than what is 'technically correct' [01:10] <durandal_1707> it should work because 16 bit YUV planar formats are already supported [01:10] <Daemon404> in terms of effort and time [01:11] <Daemon404> yes [01:16] <ixxvil> hi [01:18] <durandal_1707> so ffv1 is only codec which supports bunch of formats, comparing with ut video and vble? [01:18] <Daemon404> vble is only 4:2:0 8-bit [01:18] <Daemon404> ut video supports a bunch of 8-bit formats [01:18] <Daemon404> ffv1 is slow as hell. [01:18] <Daemon404> so noone uses it. [01:18] <swone> gnafu: thanks for the Dirac link. unfortunately, it doesn't look like any implementations use anything beyond 8-bit luma [01:20] <durandal_1707> hmm, ffv1 support only le? [01:20] <CIA-40> ffmpeg: 03Michael Niedermayer 07master * rf57ab7ed37 10ffmpeg/libavcodec/zmbv.c: [01:20] <CIA-40> ffmpeg: zmbv: remove unused variable [01:20] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [01:20] <CIA-40> ffmpeg: 03Michael Niedermayer 07master * r670229ef43 10ffmpeg/libavcodec/apedec.c: [01:20] <CIA-40> ffmpeg: apedec: remove unused variable [01:20] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [01:22] <pengvado> ffv1 supports only native-endian. like any sane codec. [01:22] <Daemon404> a wild pengvado appears [01:22] <pengvado> translating le<=>be is for swscale to do, not for the codec [01:22] <Daemon404> which reminds me i should go finish that ffv2-replacement with marc fd... [01:23] <Daemon404> btw pengvado, i had a bet going about you -- have you ever heard of teh tunstall transform? [01:25] <durandal_1707> but how decoder will know if pix fmt is le or be? [01:26] <Daemon404> durandal_1707, it outputs whatever teh system has [01:26] <Daemon404> simple. [01:27] <durandal_1707> so file created on le will looks wrong played on be? [01:27] <Daemon404> the bitstream is likely endianless [01:27] <Daemon404> i.e. doesnt matter [01:27] <durandal_1707> whatever [01:28] <durandal_1707> dont blame me if it does not work on big endian [01:28] <Daemon404> :P [01:28] <Daemon404> for all that video encoding one does on mips and ppc of course [01:28] <Daemon404> but it should in any case i thing [01:28] <Daemon404> s/g$/k/ [01:32] <pengvado> Daemon404: no, but now that I've looked it up I see that I have implemented something like that. [01:32] <Daemon404> lol ok [01:32] <Daemon404> we;re planning on using it [01:37] <durandal_1707> heh i would need to feed zeroes [01:38] <swone> thanks! [01:42] <pengvado> oh, but what I did was variable-length on both sides. build two huffman trees and a bijection between their leaves. this ends up with just as good compression as rangecoding even for rather tiny trees. otoh, it wasn't any faster than rangecoding. [01:43] Action: Daemon404 notes speaks and thinks eerily similar to marc... [01:43] <Daemon404> pengvado* [01:44] <ohsix> not [01:51] <durandal_1707> ffv1 encodes at 21fps [01:51] <durandal_1707> on crappy celeron M [01:51] <Daemon404> now try its AC :P [01:52] <durandal_1707> Daemon404: what you need higher that 30fps? [01:52] Action: Daemon404 is an anime pirate [01:53] <Daemon404> (fansubber) [01:53] <Daemon404> 20 fps is slow. [01:53] <Daemon404> its AC is even slower iirc [01:53] <durandal_1707> but this is withn single thread on CPU from previous century [01:54] <Daemon404> the worst bit is teh decoding speed btw [01:54] <Daemon404> with ffv1, decoding is always teh bottleneck for me. [01:56] <durandal_1707> i wrote gray16 hack and it decodes with green tint and blue artifacts [01:56] <Daemon404> sounds like 00 chroma [01:56] <durandal_1707> probably pecause i do not write extra zero stuff [01:56] <Daemon404> (as in all the chroma vals are 00) [01:57] <durandal_1707> there are no chroma vals, i did not encoded chroma samples at all [01:57] <Daemon404> but is it trying to write them? [01:57] <Daemon404> >_>< [01:57] <Daemon404> or read or w/e [01:57] <durandal_1707> I just encoded luma plane [01:58] <Daemon404> is it trying to decode chroma? [01:58] <Daemon404> and getting nothing [01:58] <durandal_1707> yes [01:58] <Daemon404> well there u go [01:58] <durandal_1707> but I cant touch decoder - there is no way for decoder to know that encode is only single plane [01:59] <Daemon404> well yea... [02:00] <Daemon404> anyway... [02:00] Action: Daemon404 boots up steam [02:06] <durandal_1707> tunstall transform? [02:14] Action: durandal_1707 feels stupid [02:19] <Daemon404> its not well known. [02:20] Action: Daemon404 vanishes back to steam [02:20] <durandal_1707> Daemon404: i was wrong, ffv1 decoder checks for colorspace, making gray implementation easy [03:05] <durandal_1707> latest schroedinger, 1.0.11 have 4:4:4 16bit support [03:31] <CIA-40> ffmpeg: 03Justin Ruggles 07master * r22c0babbb2 10ffmpeg/libavcodec/apedec.c: apedec: remove unneeded #include of get_bits.h and associated macro [03:31] <CIA-40> ffmpeg: 03Justin Ruggles 07master * re4169612a1 10ffmpeg/libavcodec/apedec.c: [03:31] <CIA-40> ffmpeg: apedec: av_fast_malloc() instead of av_realloc() [03:31] <CIA-40> ffmpeg: av_realloc() does not guarantee alignment, which is required for [03:31] <CIA-40> ffmpeg: DSPContext.bswap_buf(). [03:31] <CIA-40> ffmpeg: 03Justin Ruggles 07master * r0759c8eb10 10ffmpeg/libavcodec/apedec.c: apedec: fix handling of packet sizes that are not a multiple of 4 bytes [03:31] <CIA-40> ffmpeg: 03Anton Khirnov 07master * r61a099680c 10ffmpeg/avconv.c: avconv: factorize setting stream_index for the output packet. [03:31] <CIA-40> ffmpeg: 03Anton Khirnov 07master * rd2afbd9a56 10ffmpeg/ (398 files in 2 dirs): (log message trimmed) [03:31] <CIA-40> ffmpeg: frame{crc/md5}: set the stream timebase from codec timebase. [03:31] <CIA-40> ffmpeg: Right now those muxers use the default timebase in all cases(1/90000). [03:31] <CIA-40> ffmpeg: This patch avoid unnecessary rescaling and makes the printed timestamps [03:31] <CIA-40> ffmpeg: more readable. [03:31] <CIA-40> ffmpeg: Also, extend the printed information to include the timebases and packet [03:31] <CIA-40> ffmpeg: pts/duration and align the columns. [03:31] <CIA-40> ffmpeg: 03Anton Khirnov 07master * r324fbadff9 10ffmpeg/avconv.c: avconv: remove debugging cruft from do_video_out(). [03:31] <CIA-40> ffmpeg: 03Alex Converse 07master * r29a20ac4a1 10ffmpeg/libavformat/mov.c: [03:32] <CIA-40> ffmpeg: movdec: Avoid av_malloc(0) in stss [03:32] <CIA-40> ffmpeg: * qatar/master: [03:32] <CIA-40> ffmpeg: dsputil: remove debug message in dsputil_init(). [03:32] <CIA-40> ffmpeg: movdec: Avoid av_malloc(0) in stss [03:32] <CIA-40> ffmpeg: build: Drop YASM-OBJS-FFT from SUBDIR_VARS. [03:32] <CIA-40> ffmpeg: build: Drop unused X86-OBJS variable. [03:32] <CIA-40> ffmpeg: 03Diego Biurrun 07master * r7f2885bbb7 10ffmpeg/Makefile: build: Drop unused X86-OBJS variable. [03:32] <CIA-40> ffmpeg: 03Diego Biurrun 07master * r58fc740059 10ffmpeg/Makefile: [03:32] <CIA-40> ffmpeg: build: Drop YASM-OBJS-FFT from SUBDIR_VARS. [03:32] <CIA-40> ffmpeg: FFT code only appears in libavcodec, so there is no need to reset the variable [03:32] <CIA-40> ffmpeg: when the build templates are instantiated for other libraries. [05:31] <durandal_1707> lossless schroedinger is much slower that ffv1 [05:33] <durandal_1707> ^encoding [06:07] <CIA-40> ffmpeg: 03Michael Niedermayer 07master * r25f35df115 10ffmpeg/libavcodec/libxvid_rc.c: [06:07] <CIA-40> ffmpeg: xvid_rc: check that write() succeeded. [06:07] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [06:08] <CIA-40> ffmpeg: 03Michael Niedermayer 07master * r7f8027b76f 10ffmpeg/libavutil/adler32.c: [06:08] <CIA-40> ffmpeg: adler32: avoid "too big" check in the inner loop [06:08] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [09:06] <NapHtaKeRoSene> hi [09:06] <NapHtaKeRoSene> if i do fabs(doublevar) then is it possible doublevar be < 0 ? [09:19] <ohsix> thats basic math [09:27] <NapHtaKeRoSene> sure but i'm getting faulty values at some pixels [09:27] <NapHtaKeRoSene> whiteish, where it should be black [09:27] <NapHtaKeRoSene> even tried clamping 0,1 [19:14] <CIA-40> ffmpeg: 03Reimar Döffinger 07master * rd7b542ae29 10ffmpeg/libavformat/oggdec.c: [19:14] <CIA-40> ffmpeg: Fix potential infinite discard loop. [19:14] <CIA-40> ffmpeg: Fixes trac issue #438. [19:14] <CIA-40> ffmpeg: Seeking in that sample would cause ogg_read_timestamp to fail [19:14] <CIA-40> ffmpeg: because ogg_packet would go into a state where all packets [19:14] <CIA-40> ffmpeg: of stream 1 would be discarded until the end of the stream. [19:14] <CIA-40> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> [20:01] <CIA-40> ffmpeg: 03Clément BSsch 07master * r785d8a3868 10ffmpeg/tests/ (3 files in 3 dirs): [20:01] <CIA-40> ffmpeg: fate: use compression level 0 for flashsv2 tests. [20:01] <CIA-40> ffmpeg: Output sizes mismatch (and thus MD5) between zlib version 1.2.5 and [20:01] <CIA-40> ffmpeg: 1.2.6 if compression level > 0. The issue doesn't affect the intra-only [20:01] <CIA-40> ffmpeg: tests. [20:19] <CIA-40> ffmpeg: 03Reimar Döffinger 07master * r5b0103590c 10ffmpeg/libavformat/oggparseskeleton.c: [20:19] <CIA-40> ffmpeg: Remove warning about Ogg skeleton v4. [20:19] <CIA-40> ffmpeg: We can handle v4 just fine, the parts we currently use [20:19] <CIA-40> ffmpeg: are the same for v3 and v4. [20:19] <CIA-40> ffmpeg: v4 can in addition contain an index which we so far do [20:19] <CIA-40> ffmpeg: not use though. [20:19] <CIA-40> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> [20:26] <CIA-40> ffmpeg: 03Michael Niedermayer 07master * r26585d2a7f 10ffmpeg/libavutil/adler32.c: [20:26] <CIA-40> ffmpeg: adler32: rewrite using integer SIMD. [20:26] <CIA-40> ffmpeg: about twice as fast as before. [20:26] <CIA-40> ffmpeg: the not CONFIG_SMALL case is also droped as it is not faster than the [20:26] <CIA-40> ffmpeg: CONFIG_SMALL case. [20:26] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [20:30] <CIA-40> ffmpeg: 03Michael Niedermayer 07master * rd3f912c1f0 10ffmpeg/libavutil/adler32.c: [20:30] <CIA-40> ffmpeg: adler32: add comment for the SIMD code [20:30] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at> [21:36] <pills> i hope this is the right chan to ask...I notice there is a separate decode path when using video filters (libavfilter/src_movie.c) this path doesn't seem to honor the decode options given on the CLI to the "main" video stream. [21:37] <pills> so I guess my question is there a plan to allow more advanced decode options to "movie" sources when they are not all encoded the same or need special options to decode (despite encoding errors) [21:49] <Compn> yes there may be video filter plan [21:49] <Compn> ask stefano and or michaelni [21:49] <Compn> well, probably stefano [21:53] <Compn> his nick is saste, but hes not here right now [00:00] --- Sun Feb 5 2012