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

[burek]

[01:25] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:d56c373391d3: avcodec/mjpegdec: fix cmyk 420 with adobe_transform == 2
[02:10] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:678e455f1dc0: dxva2: Directly use AVFrames
[02:10] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:9e3c8f61feb2: Merge commit '678e455f1dc09265464b13d936d9fda62bc2bf43'
[02:52] <Snaggle> I filed trac #3512 yesterday (missing qtkit.o), and see that it's now affecting all darwin FATES.  There was some talk about it on -devel, but no patches that I could see.  Is there anything that I can test?
[02:56] <michaelni> Snaggle, there was a patch from thillo that i applied but he couldnt reproduce it
[02:57] <Snaggle> michaelni: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=d5c0036d4adcec7a38aad6e3aab8792ab9bc074a ?  That had no effect here.  The problem I'm seeing is that qtkit.o is not even trying to be compiled.
[02:59] <michaelni> can you upload config.h/mak somewhere ?
[03:00] <michaelni> and maybe .log
[03:02] <Snaggle> working on it...
[03:04] <BBB> smarter: ping
[03:04] <Snaggle> config.mak: http://paste.lisp.org/display/141878  config.h: http://pastebin.com/BSezLT1X  config.log is big.  I'm trying to trim to the qtkit stuff
[03:06] <BBB> smarter: maybe over the weekend is better, but hum, why does hevc allow crossing pb boundaries for tbs? I mean, that doesn't make any sense, does it? and more specifically, if I have a 8x8 CB with 4x4 PBs (intra) and 4x4 TU, does it do per-4x4-block reconstruction before next-block prediction, or does it do 4x4x4 prediction before 4x4x4 reconstruction?
[03:07] <Snaggle> michaelni: and config.log QTKit parts (too big to paste) http://paste.lisp.org/display/141878#1
[03:08] <smarter> BBB: I think it does reconstruction first
[03:08] <BBB> per-4x4?
[03:08] <BBB> that's good :)
[03:10] <smarter> A TB tree is always part of a PB
[03:10] <smarter> if I'm not mistaken
[03:11] <smarter> In hevc.c, hls_coding_unit calls hls_prediction_unit which does prediction then call hls_transform_tree
[03:11] <BBB> uhm
[03:11] <BBB> this spec I'm reading says otherwise
[03:11] <BBB> I sure hope it's wrong
[03:11] <BBB> http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=06316136
[03:11] CTCP ciency: bene from BBB (BBB!~rbultje at abraxo.bluebottle.net.au) to #ffmpeg-devel
[03:11] <BBB> "In contrast to previous standards, the HEVC design allows a TB to span across multiple PBs for interpicture-predicted CUs to maximize the potential coding efts of the quadtree-structured TB partitioning."
[03:12] <BBB> smarter: page 1656, end of E
[03:12] <michaelni> Snaggle, you tried make distclean ?
[03:12] <Snaggle> michaelni: rm * in my build directory, then fresh ./configure and make
[03:14] <smarter> BBB: that link doesn't seem to work, what's the name of the paper?
[03:16] <smarter> BBB: and it seems I was mistaken, hls_coding_unit does call both hls_prediction_unit and hls_transform_tree, so the two trees are indeed rooted at the CB level
[03:16] <BBB> "Overview of the High Ef
ciency Video Coding (HEVC) Standard"
[03:16] <BBB> by Gary J. Sullivan, Fellow, IEEE, Jens-Rainer Ohm, Member, IEEE, Woo-Jin Han, Member, IEEE, and Thomas Wiegand, Fellow, IEEE
[03:17] <smarter> I did read that a while ago
[03:17] <smarter> so yeah, the coding block prediction is done first, then the transform stuf
[03:18] <BBB> so if I do pb 4x4, I have to do 4 predictions before I can do the tb?
[03:18] <BBB> even if tb is 4x4 also?
[03:18] <smarter> in that case, you should have 4x4 CB I guess
[03:18] <smarter> if that's possible? I don't remember
[03:19] <BBB> no
[03:19] <BBB> cb is 8x8 min.
[03:19] <Snaggle> make that ../configure since I'm inside /src/ffmpeg/mybuilddir
[03:19] <BBB> "The quadtree splitting process can be iterated until the size for a luma CB reaches a minimum allowed luma CB size that is selected by the encoder using syntax in the SPS and is always 8×8 or larger (in units of luma samples)."
[03:20] <smarter> the 4x4 case does sound weird
[03:21] <BBB> the 64x64 is weird also
[03:21] <BBB> so it has 64x64 intra pbs?
[03:22] <BBB> that's massive
[03:22] <cone-739> ffmpeg.git 03Jimmy Christensen 07master:38389058c330: OpenEXR decoder
[03:22] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:95582b5ccc9a: Merge commit '38389058c3308758c6365abd0f6b45c5e62bb90b'
[03:24] <smarter> doesn't seem particularly wrong, especially for large video dimensions
[03:24] <smarter> transform is limited to 32x32 like vp9
[03:26] <smarter> what is more fun I think are the non-square prediction blocks
[03:26] <cone-739> ffmpeg.git 03Paul B Mahol 07master:06688e96fb95: fate: add exr tests
[03:26] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:42138f63574b: Merge commit '06688e96fb9577bc7466a380bf7a14fa745208db'
[03:27] <BBB> non-square is inter-only right?
[03:27] <smarter> yes
[03:28] <BBB> vp9 has non-square also, but just 2wxh or wx2h
[03:28] <cone-739> ffmpeg.git 03Paul B Mahol 07master:ca36aa9e6b8f: codec_desc: set lossless attribute for SGI and DPX
[03:28] <BBB> this 3/4wxh_1/4wxh is... weir dish :)
[03:28] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:0054bbd66483: Merge commit 'ca36aa9e6b8f2fed15478245ad533fc594a35c37'
[03:30] <smarter> ah indeed, forgot about the non-square in vp9 :)
[03:32] <smarter> the overview does mention: "Although the intrapicture prediction mode is established at the PB level, the actual prediction process operates separately for each TB."
[03:32] <smarter> which does indeed sounds like what I implemented
[03:33] <BBB> ok so we do reconstruct each 4x4 completely before continuing to the next, even if they're part of the same TB
[03:33] <BBB> er... CB
[03:33] <smarter> yeah
[03:33] <BBB> weird terms
[03:33] <BBB> cool, thanks
[03:34] <BBB> hm, they removed implicit weighting in hevc?
[03:34] <smarter> weighting based on temporal distance?
[03:36] <cone-739> ffmpeg.git 03Vittorio Giovara 07master:a7dbfcf6cb6a: sgi: K&R formatting cosmetics
[03:36] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:be4ae3f532d1: Merge commit 'a7dbfcf6cb6ab8a8981d74332fd02fb90360d22f'
[03:36] <smarter> yeah, hevc doesn't have that
[03:37] <Skyler_> I'm surprised they removed it
[03:37] <Skyler_> I'm guessing you can at least partially emulate it with explicit weighting but it's not quite equivalent
[03:37] <Skyler_> I guess one answer is "it didn't help that much" but in terms of implementation complexity I don't think it makes things any more complex than regular weighted pred
[03:38] <BBB> right, the implicit weight lookup isn't that hard
[03:42] <BBB> merge mode is interesting
[03:43] <cone-739> ffmpeg.git 03Piotr Bandurski 07master:e7cd53bf662a: sgi: check maximum supported resolution
[03:43] <BBB> that should work better than nearest/near actually
[03:43] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:b3fa78cea14c: Merge commit 'e7cd53bf662a93330810981f1d057bdf2ead669e'
[03:47] <smarter> BBB: herp, actually I think PBs are limited to 32x32
[03:47] <BBB> hm?
[03:47] <smarter> CTB can be 64x64 but CB have to be 32x32
[03:47] <BBB> oh
[03:47] <BBB> that would make sense yes
[03:47] <smarter> (max)
[03:49] <BBB> so "The blocks speci
ed as luma and chroma CTBs can be directly used as CBs or can be further partitioned into multiple CBs." is wrong?
[03:50] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:0279d1d0946a: sgi: fix end of line boundary detection
[03:50] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:013aa222c624: Merge commit '0279d1d0946a854aa08919abd05b7f2da433823e'
[03:53] <BBB> ash they do mv scaling for mv prediction along temporal distance
[03:53] <BBB> wish vp9 had that
[03:54] <smarter> BBB: ah no it's more simple than that, prediction is done per TB, and TB are 32x32 max
[03:54] <smarter> like we said earlier
[03:55] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:6d9ccee4519f: sgi: set the row boundary to the correct value
[03:55] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:5b03caf9491d: Merge commit '6d9ccee4519f41155c88655c77bfb1ef085797fd'
[03:55] <BBB> ok cool
[03:56] <smarter> I get confused between hevc and vp9 nowadays :]
[03:56] <smarter> anyway, I find it funny how they added an optional strong smoothing filter on the pixels used for 32x32 intra predictions to avoid some artefacts: http://phenix.int-evry.fr/jct/doc_end_user/current_document.php?id=6509
[03:56] <smarter> seems hackish
[03:56] <BBB> yeah I saw that
[03:56] <BBB> very hacky
[03:58] <michaelni> Snaggle, what happens with "make V=2 libavdevice/qtkit.o"
[03:58] <BBB> the scan order things is really weird
[03:58] <BBB> so there's no >4x4 scantables?
[03:59] <Snaggle> michaelni: make: Nothing to be done for `libavdevice/qtkit.o'.  But libavdevice/qtkit.o does not exist.
[04:00] <BBB> sign data hiding sounds wacky
[04:00] <smarter> I forgot about that stuff I think :p
[04:00] <smarter> scan order is some kind of recursive thing I think?
[04:01] <BBB> yeah sounds like they recursively apply 4x4 scannable to the larger area
[04:01] <BBB> very odd
[04:01] <BBB> it's adaptive though so I guess that helps
[04:01] <smarter> there is 8x8 too
[04:01] <cone-739> ffmpeg.git 03Paul B Mahol 07master:ab7c64624a12: sgi: remove redundant argument from read_uncompressed_sgi()
[04:01] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:5628b9f5fb92: Merge commit 'ab7c64624a1254d509b71c2a4945336567e93845'
[04:02] <BBB> oh wait adaptive means dependent on intra pb mode
[04:02] <BBB> so not truly adaptive like jpeg
[04:02] <smarter> since with 32x32 transforms, you have 64 4x4 blocks
[04:03] <smarter> I remember reading a JCT-VC paper on the reasons for the scanning scheme but I don't remember
[04:03] <BBB> hm, the doc is vague about that, but ok, 8x8 is useful and h264 had it too so that makes sense
[04:03] <BBB> ok I think I get the main gist of it, I'll go play with this
[04:04] <smarter> hmm, it might be to ease hardware implementations
[04:04] <BBB> yeah
[04:04] <cone-739> ffmpeg.git 03Carl Eugen Hoyos 07master:f8dea10d3f09: sgi: decode images with 4 channels at 8 and 16 bits
[04:04] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:23290c86bfe6: Merge commit 'f8dea10d3f09376894613d0266c34d1a16ac735f'
[04:04] <BBB> they made me cripple the vp9 32x32 scantable for hw
[04:04] <BBB> kinda sucked
[04:05] <smarter> if you look on Google Scholar/IEEEExplore, you'll find some papers explaining a lot of the aspects of hevc
[04:09] <BBB> sleep time also... will probably ask more :)
[04:19] <cone-739> ffmpeg.git 03Vittorio Giovara 07master:6c1df1f22874: sgi: encode images with 4 channels at 8 and 16 bits
[04:19] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:4ebfcd62af11: Merge commit '6c1df1f2287401b6022773e382ebc3a3bfed0b38'
[04:25] <cone-739> ffmpeg.git 03Vittorio Giovara 07master:d613091f8858: sgi: decode 16bit RLE images
[04:25] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:767b1daf4b6a: Merge commit 'd613091f8858d87789916e2bd7a84ea3144077d4'
[04:59] <cone-739> ffmpeg.git 03Vittorio Giovara 07master:55c6e59906ab: fate: add SGI tests
[04:59] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:6537b89843e2: Merge remote-tracking branch 'qatar/master'
[05:18] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:9595f36700a9: Makefile: fix out of tree builds of .m files
[05:50] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:879072018f68: avcodec/exr: use av_freep() for saftey
[10:34] <ubitux> clever: any news on rpi support?
[12:53] <Snaggle> michaelni: thanks for fixing the Darwin qtkit builds.  that out of tree build Makefile patch seems to have done the trick
[13:43] <BBB> smarter: what is the difference between N/R or W/N NAL unit types?
[13:43] <BBB> smarter: I can see the NAL units without N/R and W/N in that doc, why is there 2 for each?
[13:50] <JEEB> BBB, W_SOMETHING usually means "with something", while N_SOMETHING usually means "no something", like leading pictures
[13:51] <JEEB> basically it tells the decoder if it should expect pictures that have a PTS before the random access picture itself, for example, after the random access picture in DTS order
[13:51] <BBB> and R/N?
[13:56] <JEEB> the only thing I could quickly find regarding that is
[13:56] <JEEB> If  a  picture  has  nal_unit_type  equal  to  TRAIL_N,  TSA_N,  STSA_N,  RADL_N,  RASL_N,  RSV_VCL_N10, 
[13:56] <JEEB> RSV_VCL_N12, or RSV_VCL_N14, the picture is a sub-layer non-reference picture. Otherwise, the picture is a sub-
[13:56] <JEEB> layer reference picture. 
[13:56] <JEEB> so _R are "sub-layer reference pictures"?
[13:56] <JEEB> and _N is "sub-layer non-reference picture"
[13:56] <nevcairiel> N for non-ref, R for ref? guess that makes sense
[13:57] <JEEB> yup
[14:06] <cone-340> ffmpeg.git 03Michael Niedermayer 07master:254f653b24cd: avcodec/jpeglsdec: add PAL8 support
[14:17] <smarter> BBB: JEEB is the real expert of what the NAL unit types do :)
[14:17] <smarter> I keep forgetting what the damn acronyms mean
[14:20] <Daemon404> i wonder why BBB is looking at HEVC
[14:20] <JEEB> smarter, I only remembered the W_SHIT/N_SHIT stuff in mind
[14:21] <JEEB> the _N/_R is something I had to scroll through the spec
[14:21] <JEEB> for
[14:30] <kierank> smarter: the complexity keeps people employed
[14:48] <kierank> that timestamp discussion on the ml makes me sad
[14:48] <kierank> there is only one true clock and that is the hardware clock
[14:48] <kierank> but kernel devs don't want to understand that
[15:22] <ubitux> JEEB: "ssshh! don't talk about problems!"
[15:23] <nevcairiel> the dictator has spoken, the topic shall be ignored for all eternity
[15:23] <ubitux> i can't stop laughing i'm sorry :')
[15:23] <JEEB> *spoketh
[15:24] <JEEB> or however you write it in ye olden English
[15:24] <JEEB> ubitux, it's sad as hell so I'm kind of happy you can get fun out of it
[17:42] <ubitux> > code authorship is not all, sometimes the overall design scheme have to prevail
[17:42] <ubitux> wat
[17:43] <nevcairiel> gotta rationalize somehow
[17:58] <Daemon404> i am doing myself a favour and nto reading these stupid fork flames
[18:00] <cone-340> ffmpeg.git 03Nedeljko Babic 07master:284cfc7180cc: libavutil: Add fixed_dsp
[18:00] <cone-340> ffmpeg.git 03Michael Niedermayer 07master:d506deaeaa98: avutil/fixed_dsp: remove redundant cast
[18:46] <kierank> wm4: you got rid of the thing in your wiki about libav review process and the often arbitrary nature
[20:19] <cone-340> ffmpeg.git 03Nedeljko Babic 07master:696e34a6e15d: libavcodec: Implementation of AC3 fixedpoint decoder
[20:19] <cone-340> ffmpeg.git 03Michael Niedermayer 07master:b219142921e9: avcodec/ac3: rename identifier used to select the fixed point variant
[20:19] <cone-340> ffmpeg.git 03Michael Niedermayer 07master:91b105ce5bfb: avcodec/ac3dec: avoid #if, use if() instead, its cleaner and shorter
[20:20] <cone-340> ffmpeg.git 03Michael Niedermayer 07master:3b37f2286199: avcodec/ac3dec_fixed: add missingAVprefix to CODEC_ID
[21:09] <cone-340> ffmpeg.git 03Martin Storsjö 07master:66d04c068a30: fate: Explicitly use gray16le in fate-sgi-gray16
[21:09] <cone-340> ffmpeg.git 03Michael Niedermayer 07master:909757fabdf8: Merge commit '66d04c068a30751750818dcfbb6555ab74eb3f6d'
[22:12] <J_Darnley> A question for those who compile 32-bit on 64-bit linux...
[22:13] <J_Darnley> What configure options do you use to do so?  --cross-prefix?  --cc (and others)?
[22:15] <nevcairiel> i use --cross-prefix for cross builds, and additionally --arch
[00:00] --- Wed Apr  2 2014