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

Sun Feb 5 02:05:03 CET 2012

[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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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