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

[burek]

[00:42] <cone-301> ffmpeg.git 03Thilo Borgmann 07master:b7ba7cbd6e5a: avcodec/tiff: Refactor TIFF tag related functions to share the code.
[00:42] <cone-301> ffmpeg.git 03Thilo Borgmann 07master:ad0f7574effe: avcodec: Add EXIF metadata parser to libavcodec.
[00:43] <cone-301> ffmpeg.git 03Thilo Borgmann 07master:bb4e1b4cf910: avcodec/mjpegdec: Read EXIF metadata in JPEG input.
[01:17] <ubitux> llogan: "avilable"
[01:24] <llogan> shit
[01:25] <llogan> i'll fix that
[01:25] <llogan> i must have read it 3 times
[02:30] <bernie_> it appears that iOS would like to have more than a few sound samples at a time for reading into its memory queue.  Is there a way to control the interleaving of the audio / video samples, so that the sound data precedes the video data in bigger chunks?  (like a second of audio data, followed by a second of video data), etc?
[02:30] <bernie_> (using matroska, vp8 and AAC)
[02:44] <wm4> bernie_: no, you have to do proper buffering
[02:45] <wm4> so you might have to read some packets ahead in general
[02:45] <wm4> in the end, your playback chain should look at the timestamps of the _decoded_ data, and play them in sync
[03:39] <cone-301> ffmpeg.git 03Alexis Ballier 07master:ca2378ad04e1: libavformat/version.h: Drop FF_API_OLD_AVIO (unused and undefined since libavformat 55)
[04:11] <bernie_> wm4: thanks.  Indeed, I intent to keep things in sync.  Though for audio, it should be true that the samples pile up nicely.  iOS has a way of querying the audio queue timeline, which I was planning to use to sync to the video.  Sometimes the audio channel gets a hiccup, and so it's good to query the audio buffer timeline, and use that for syncing to the video.  I assume that will work.  But it does sound like I'll have to first r
[04:12] <bernie_> so that got me thinking... if I really want a "chunk" of audio, and then a "chunk" of video data, why not have the muxer do that for me?  Seems more efficient than to do that on the player side.
[04:13] <bernie_> But I'm still debugging stuff.  Still not hearing anything for AAC on iOS via matroska.  There is plenty of magic in AAC I wasn't aware of.
[04:19] <bernie_> I have a hard time matching the AAC Audio Object Types here (http://wiki.multimedia.cx/index.php?title=MPEG-4_Audio) with what iOS has (ie: kAudioFormatMPEG4AAC and kAudioFormatMPEG4AAC_* on this page here: http://developer.apple.com/library/ios/documentation/MusicAudio/Reference/CoreAudioDataTypesRef/Reference/reference.html)
[04:20] <bernie_> Never mind, if I and how I would have to set a magic cookie... kAudioQueueProperty_MagicCookie  SIGH.
[04:20] <bernie_> but now I must pickup pizza...
[04:27] <cone-301> ffmpeg.git 03Alexis Ballier 07master:7a48b1c49282: Remove FF_API_PKT_DUMP cruft. Not compiled since libavformat 54.
[05:35] <BBB> ubitux: ok I think loopfilter is correct now (not 100% sure, but mostly looks ok)
[05:56] <BBB> ubitux: so while you finish 32x32 intra pred modes (they're triggered by various vp90-2-00-quantizer-*.webm files, e.g. 55, 23, 01), I'll work on basic inter bitstream parsing
[05:56] <BBB> then once that's done, we'll do various pieces of inter reconstruction
[06:26] <BBB> Daemon404: I'll assume you're busy moving until you mention otherwise?
[06:27] <Daemon404> ragemoving
[06:27] <BBB> lol
[06:27] <Daemon404> i have to tether my phone for my first two weeks in the UK for internet (outside of work)
[06:27] <Daemon404> because the isp cant send anyone until after vdd
[06:27] <Daemon404> (sep 2nd)
[06:27] <Daemon404> miserable.
[06:28] <BBB> omg
[06:29] <BBB> is the whole company on strike or so?
[06:29] <Daemon404> it's some fun involving openreach, and a giant monopoly in the UK
[06:29] <Daemon404> either way im not very pleased
[06:30] <Daemon404> (what that means is every company uses the same installation service)
[06:35] <BBB> that sounds like a problem that is easily solved by adding a second installation service to the country
[06:36] <Daemon404> how un-British!
[06:39] <BBB> it's british to suffer needlessly?
[06:39] <Daemon404> stiff upper lip and all that
[06:39] <BBB> how odd </brit>
[10:01] <j-b> morning
[10:32] <michaelni> morning
[10:47] <cone-855> ffmpeg.git 03Ian Taylor 07master:46dee21a3238: png: allow encoding 16-bit grayscale
[10:47] <cone-855> ffmpeg.git 03Michael Niedermayer 07master:1057390d916e: Merge remote-tracking branch 'qatar/master'
[11:38] <cone-855> ffmpeg.git 03Piotr Bandurski 07master:e87fcaa8d5cc: avformat/riff: treat msn audio like gsm_ms
[11:46] <kierank> Daemon404: LAND OF HOPE AND GLORY
[11:46] <kierank> MOTHER OF THE FREEEEEE
[11:47] <kierank> I expect you to be singing along 
[11:47] <kierank> during last night of the proms
[11:47] <durandal_1707> you drinked too much?
[11:48] <kierank> see the part above about britain
[11:48] <kierank> it is a british joke
[12:04] <ubitux> BBB: what is the step following intra pred, for error adjustment? (if any)
[12:05] <ubitux> the block being intra pred (assuming !dc) will not have any dct/ast run, right?
[12:06] <ubitux> i mean it's either dct/adst or intra pred, right? but is intra pred working as a full replacement for that dct/adst?
[12:22] <BBB> ubitux: error adjustment?
[12:22] <BBB> ubitux: what does that mean?
[12:23] <BBB> ubitux: oh I see, no, the intra pred in all cases precedes a full inverse 2d transform
[12:23] <BBB> ubitux: the type of transform is mode-dependent (always 2d dct for inter modes, and adst/dct combinations for intra pred), and all that logic works already
[12:23] <cone-855> ffmpeg.git 03Nedeljko Babic 07master:7b71feabfb31: MAINTAINERS: add myself as maintainer for MIPS and Zeljko Lukac as maintainer for new fixed point FFT
[12:23] <BBB> ubitux: plus for 32x32 it's always dct
[12:24] <ubitux> i don't understand sth: isn't the intra pred some spacial/pixel prediction?
[12:24] <BBB> spatial
[12:24] <BBB> yes
[12:24] <ubitux> how can you run a adst/dct after this step?
[12:24] <ubitux> ah it's not pixel then
[12:25] <BBB> no it is pixel
[12:25] <BBB> you're predicting the contents of a 4x4 block (or 32x32 in your case)
[12:25] <BBB> then you code a residual, which you add/subtract to/from it
[12:25] <ubitux> aaah
[12:25] <BBB> so final reconstructed pixel array is pred + residual
[12:25] <ubitux> ok
[12:25] <ubitux> now it makes sense
[12:25] <ubitux> thx
[12:26] <BBB> the spatial prediction just makes the residual smaller (thus more efficient to code)
[12:26] <ubitux> right ok
[12:49] <BBB> I'm relatively halfway doing the block parsing for inter frames
[12:49] <BBB> (although I still have to do the hard part, which is the motion vector coding, that'll take me a while)
[14:15] <ubitux> BBB: btw, av_assert* are prefered (and use with --assert-level=...)
[14:15] <BBB> what is av_assert()?
[14:16] <ubitux> more controllable asserts
[14:16] <ubitux> see libavutil/avassert.h
[14:16] <ubitux> av_assert0()  all the time, and 1 & 2 for speed relevant code
[14:17] <BBB> uh ok
[14:18] <BBB> how's the intra pred code progressing?
[14:18] <ubitux> well i'm still trying to understand some things
[14:19] <ubitux> for example, trying to explain why the apparent inconsistency in the logic between the 4, 8 and 16
[14:20] <BBB> ?
[14:20] <BBB> you mean the use of upperright?
[14:20] <BBB> (that's the only thing that's inconsistent I think)
[14:22] <ubitux> if you take downleft for instance, 4 and 8 are using the same number of input (in comparison to 16), and 4 has not the "stairway form"
[14:22] <ubitux> that kind of stuff
[14:22] <ubitux> so i'm not sure what the "top" represent in those case
[14:22] <ubitux> (and what form it will follow in 32)
[14:23] <BBB> 32 will be the same as 8/16
[14:23] <BBB> so the amount of input is the size of the predictor
[14:23] <BBB> 4 is a specialcase, it uses 8 top pixels
[14:23] <BBB> 4 is top, the other 4 is topright
[14:23] <ubitux> so for 32, a top 32 input, stairway form?
[14:23] <BBB> like this: 0 1 2 3 4 5 6 7 8 (above)
[14:24] <BBB> L x x x x
[14:24] Last message repeated 3 time(s).
[14:24] <BBB> L is left
[14:24] <BBB> 0-8 is topleft, topx4 and toprightx4
[14:24] <BBB> x is the predicted pixels
[14:24] <BBB> 8x8 and 16x16 only use left, topleft and top (not topright)
[14:24] <BBB> 32x32 follows that design also
[14:25] <BBB> yes
[14:25] <BBB> (sorry ignored your question)
[14:25] <ubitux> why the special case for 4?
[14:25] <BBB> I think you're asking "why not the special case for the others (8, 16, 32) also?"
[14:25] <BBB> and the answer is "I don't know", it's probably a bug or not-enough-time
[14:26] <ubitux> ah
[14:26] <ubitux> ok
[14:26] <BBB> more pixels = more precise predictor
[14:26] <BBB> so using topright improves the predictor
[14:26] <BBB> not using it is thus silly if it's available
[14:26] <BBB> you'll notice it's also not used in all cases where it is available
[14:26] <BBB> another shortcoming
[14:26] <BBB> e.g. if you have a 8x8 block with 4 4x4 blocks in it (2x2)
[14:27] <ubitux> are you talking about a bug in the original implementation, or ffvp9?
[14:27] <BBB> if the complete row above us has finished decoding, topright is available for 3 of 4 blocks
[14:27] <BBB> bug in original
[14:27] <BBB> so ffvp9 is required to follow it
[14:27] <ubitux> ok
[14:27] <BBB> topright is available for topleft, topright and bottomleft 4x4 block in 8x8 block
[14:27] <BBB> but not for bottomright
[14:27] <BBB> yet vp9 dictates we cannot use it for topright and bottomright, oddly
[14:28] <ubitux> ok
[14:28] <ubitux> thx
[14:28] <BBB> I should go to bed, flying off to thailand tomorrow
[14:28] <BBB> ask more questions, I'l lcheck email at the airport
[14:28] <BBB> or chat :)
[14:29] <BBB> bbl
[14:29] <BBB> gnight
[14:29] <ubitux> 'night, hf :)
[14:44] <cone-855> ffmpeg.git 03Paul B Mahol 07master:11afe28b9a56: lavfi/ebur128: fix typo: s/negociation/negotiation
[15:29] <cone-855> ffmpeg.git 03Michael Niedermayer 07master:ef36ba5e088e: avcodec: clarify documentation of avcodec_copy_context()
[15:29] <cone-855> ffmpeg.git 03Michael Niedermayer 07master:e85771f26814: ffserver: allocate rc_eq, prevent freeing invalid pointer
[15:29] <cone-855> ffmpeg.git 03Michael Niedermayer 07master:cba9a40d47ae: avcodec: free priv_data in avcodec_copy_context()
[15:37] <cone-855> ffmpeg.git 03Compn 07master:8e0b6d82b3dd: riff: add msn audio comment
[15:38] <Compn> been a while. usually i like to sit back and make others do the hard work :)
[15:39] <durandal_1707> Compn: you did not send this on ml for a review
[15:42] <durandal_1707> and there are other msn audio codecs
[15:42] <durandal_1707> like this siren7 thing from aMSN that got posted on ml
[16:36] <cone-855> ffmpeg.git 03Thilo Borgmann 07master:6a64b23d93d0: Update my email address.
[16:51] <durandal_1707> hmm  i guess i should use fmax and not FFMAX
[19:53] <cone-855> ffmpeg.git 03Michael Niedermayer 07master:97064019279d: avcodec/mpeg12dec: check slice size before trying to decode it
[21:23] <durandal11707> michaelni: but did you see anything obviously wrong in output?
[21:31] <michaelni> durandal11707, there are some artifacts vissible on diagonal edges, i guess they are at slice borders
[21:32] <michaelni> that is from looking at it again, i didnt originally spot them when i quickly looked
[21:34] <durandal11707> and tiff does not crash any more? so i can apply it and stare at helgrind report growing
[21:57] <michaelni> durandal11707, tiff didnt crash anymore
[22:01] <pippin> what would be the best strategy for adding an additional dithering method? add another sws_flag in addition to error_diffusion?
[22:02] <durandal11707> if there is enought flags left, sure why not...
[22:02] <pippin> finished off tuning my dither, http://pippin.gimp.org/a_dither/
[22:03] <pippin> the formulas used are devilishly simple
[22:06] <durandal11707> how it behave on bigger image sizes?
[22:06] <durandal11707> because there was already attempt to make pal8 output looks better
[22:07] <Daemon404> ... thats the most useless use case
[22:07] <durandal11707> the current one (afaik) is just 8bit with dithering
[22:07] <pippin> so is this one
[22:07] <Daemon404> i would think the most used case would be dithering 10-bit yuv to 8bit
[22:07] <Daemon404> for playback
[22:07] <Daemon404> that is by far te most used dither branch in swscale
[22:07] <durandal11707> yes, sure... who use pal8 those days....
[22:08] <pippin> in GIMP it will probably end up being used for 16bpc / 32bit single precision float -> 8bpc dithering
[22:08] <kierank> Daemon404: except it doesn't work
[22:08] <kierank> only works when doing dither with the same colourspace in and out
[22:09] <Daemon404> it cant dither between the same colorspace at a different bit depth?
[22:12] <pippin> durandal11707: the rightmost GIF is the "current one", and the middle one "a dither"
[22:17] <durandal11707> well it looks better than middle one for sure, and maybe even little better than bayer (this is just personal mumbo-jubmo)
[22:17] <pippin> durandal11707: I dislike the strobing blinking it has; very apparent on dark parts
[22:17] <durandal11707> but i guess optimizes pallete+dithering if necessary would beat all of them
[22:19] <pippin> there are also other more pathological videos one can create which would make error diffusion look a lot worse
[22:19] <durandal11707> its very little image and i'm on 1920x1080
[22:20] <pippin> then listening to you is quite meaningless ;)
[22:20] <Daemon404> i personally have found the most consistently "same" dither is random dither
[22:20] <Daemon404> in fact i think lav filters uses this
[22:21] <pippin> you can replace the formulas in the bototm of this with a Math.random()
[22:21] <Daemon404> also, are you a gimp dev?
[22:21] <pippin> due to hte frequency distribution in the noise; it looks much clumpier and thus worse
[22:21] <Daemon404> i thought gimp had it's own (never update) colorspace lib
[22:21] <pippin> "a dither" is closer to a o a "blue noise" or "green noise" based mask
[22:22] <pippin> Daemon404: mhm, I'm a gimp dev, and also the author of http://gegl.org/babl/ as well as the maintainer of GEGL ;)
[22:22] <Daemon404> yes babl
[22:22] <Daemon404> last i checked it was basically dead...
[22:23] <pippin> your methods of life assesment are severely lacking
[22:23] <durandal11707> pippin: so you gonna work on libswscale now?
[22:24] <Daemon404> pippin, perhaps blame the site. it lists 0.1.3 as the newest
[22:24] <Daemon404> and only release in the last 3 years
[22:24] <Daemon404> sorry 0.1.2
[22:24] <pippin> 0.1.2 is likely latest stable, but gimp dev depends on 0.1.3
[22:25] <pippin> I'm not exzpecting any lecturing on API/ABI stability from here :p
[22:25] <Daemon404> no
[22:25] <Daemon404> i mean i see up to 0.1.8 in the dir
[22:25] <Daemon404> but the site only lists up to 0.1.2
[22:25] <Daemon404> leading one to believe no new release have occurred since 2010
[22:25] <pippin> and development vesions of GIMP likely depends on the unstable version in git
[22:26] <Daemon404> http://gegl.org/babl/ <-- this page
[22:28] <pippin> durandal11707: the only work I might end up doing on libswsale is hacking up a proper patch enabling that dithering metod for animated GIFs
[22:28] <cone-855> ffmpeg.git 03Paul B Mahol 07master:8a7295beeb09: tiff: frame multithreading support
[22:30] <durandal11707> i think there is already tools that make much better quality-wise gifs than ffmpeg
[22:31] <durandal11707> where dithering is far less obvious
[22:32] <durandal11707> its ok though to add more generic dithering methods to libswscale, i think there is much missing there
[22:33] <pippin> "a dither" (I'm going to get fed up with that name) is a very simple approximation of http://white.stanford.edu/~brian/psy221/reader/Ulichney.Dithering.pdf
[22:34] <durandal11707> michaelni: SWResamples options are mentioned twice in 'ffmpeg -h full'
[22:35] <ubitux> pippin: are you trying to patch swscale to improve the gif encoding support in ffmpeg?
[22:36] <durandal11707> hmm but michaelni already added some kind of error_diffusion dither...
[22:37] <pippin> durandal11707: the three big buck bunnies, are 1) bayer dithering from ffmpeg, 2) my hacked version of libswscale 3) michaelni's already added error_diffusion
[22:39] <Daemon404> woo... power outtage
[22:40] <durandal11707> ohh, imho swscale is one big mess, there is lot of thing to clean up
[22:41] <durandal11707> i wanted to do bunch of various ditherings but than abandoned idea when looked at code
[22:43] <wm4> AFAIK reasonable gif conversion requires knowing a large number of frames in advance
[22:43] <wm4> so this can't be in libswscale or just in a single-frame dither algorithm?
[22:43] <Daemon404> also everyone just uses imagemagick to make gifs anywa
[22:43] <durandal11707> it does not need to be large
[22:43] <Daemon404> which has pretty goos dithering
[22:44] <Daemon404> good*
[22:44] <wm4> durandal11707: yes it has to
[22:44] <Daemon404> imagemagick uses all frames
[22:44] <Daemon404> fyi
[22:44] <nevcairiel> you need to pick a good palette, and palette choices are always hard
[22:44] <durandal11707> i thought you use graphicsmagick
[22:45] <Daemon404> you mean the fork of imagemagick that nobody gives a shit about?
[22:45] <Daemon404> no i dont use that.
[22:45] <pippin> *magick has mostly different error diffusion weights IIRC
[22:45] <durandal11707> Daemon404: imagemagick use so much memory, so maybe i will switch
[22:46] <Daemon404> i think you will be disappointed
[22:46] <pippin> though, doing that in combination with median cut for generating an optimal palette based on all colors surely will get you better looking things than using an 332 rgb palette
[22:47] <pippin> compared to "a dither" though,. any error diffusion based method will give you the problem that a lot more pixel change between frames in the resulting GIF - doubling it's size
[22:47] <Daemon404> more than anything
[22:47] <Daemon404> im impressed animated gifs have made such a comeback
[22:47] <wm4> gif conversion also needs to do other processing than just palette selection and color conversion
[22:47] <nevcairiel> yeah error diffusion does indeed produce giant images
[22:47] <Daemon404> nevcairiel, yes
[22:48] <nevcairiel> also, noone managed to implement a replacement for animated gifs that got adopted by enough things
[22:48] <Daemon404> APNG duh
[22:48] <Daemon404> /troll
[22:48] <pippin> I have tested "a dither" on quite extensive color testing charts, and I am very happy with it overall as a "pal8" converter, that can even be used on the fly inside a "pset"
[22:48] Action: durandal11707 cries for apng gsoc
[22:48] <gnafu> http://www.kickstarter.com/projects/374397522/apngasm-foss-animated-png-tools-and-apng-standardi
[22:48] <wm4> lol trying to start normal OSS projects on kickstarter
[22:49] <michaelni> durandal11707, -h full prints swr twice because its once from the aresample filter and once swresample itself
[22:49] <Daemon404> gnafu, doesnt mean jack unless you can travel through time and make old browsers support it
[22:49] <nevcairiel> gnafu: you know whats the biggest issue with apng, for example on its demo page .. it doesn't fucking animate :P
[22:49] <durandal11707> michaelni: ahh
[22:49] <durandal11707> nevcairiel: perhaps you use ie
[22:49] <nevcairiel> no, chrome
[22:50] <gnafu> It animates in the only browser that matters to me ;D.
[22:50] <durandal11707> and it removed it (if it ever had it)
[22:50] <nevcairiel> firefix is probably the only browser that supports it then :p
[22:50] <nevcairiel> firefox*
[22:50] <pippin> I think opera used to, but they've moved to webkit now
[22:50] <Daemon404> does firefox not have The Worst Image Downscaling In Existence yet?
[22:51] <Daemon404> did the yfix that?
[22:52] <gnafu> Oh, and: https://chrome.google.com/webstore/detail/apng/ehkepjiconegkhpodgoaeamnpckdbblp
[22:53] <pippin> wm4: what other processing does GIF conversion need to do?
[22:54] <pippin> an unacceptable patch, in case someone just wants to test it: http://pippin.gimp.org/tmp/0001-swscale-hack-up-error-diffusion-to-be-a-dither.patch
[22:56] <wm4> pippin: I don't know, but for example stabilizing parts of the gif that don't move much can be important (since even static parts of a TV capture etc. can be noisy)
[22:56] <wm4> I just know that even naive imagemagick conversion doesn't give very good results
[22:56] <pippin> wm4: you would normally scale it down first; and scaling down with a sane resampler would cancel out that noise
[22:57] <pippin> wm4: at least beyond the level of noise neccesary to add for dithering
[22:58] <pippin> I've seen a lot of GIFs lately worse than what ffmpeg produces with that hack
[22:58] <durandal_1707> i think those are from older ffmpeg version
[22:59] <durandal_1707> *sarcasm*
[23:53] <cone-855> ffmpeg.git 03Timothy Gu 07master:bbbd9596ad8f: doc/filters: reformat scale filter doc
[00:00] --- Wed Aug 14 2013