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

[burek]

[00:03] <michaelni> doxygens output is big with many warnings ...
[00:04] <michaelni> the doxygen stuff needs a maintainer
[00:09] <jojva> As a newbie with FFmpeg I can tell documentation is lacking indeed, many important functions aren't documented, which makes it hard to understandtheir purpose :\
[00:11] <michaelni> yes
[00:12] <michaelni> also if you spot something specific that you think needs docs AND you know what the function does then please submit a patch
[00:13] <michaelni> if everyone did that docs would improve more or less quickly
[00:17] <jojva> yes
[00:18] <wm4> Assertion out->ch_count == av_get_channel_layout_nb_channels(s->out_ch_layout) failed at libswresample/rematrix.c:433
[00:18] <wm4> wut
[00:22] <cone-205> ffmpeg.git 03Derek Buitenhuis 07master:1fb8ecb498da: doc: Remove list of format fields
[00:22] <cone-205> ffmpeg.git 03Derek Buitenhuis 07master:4c79367e9b2e: doc: Explain the various logevel settings
[00:22] <cone-205> ffmpeg.git 03Derek Buitenhuis 07master:e54a15b681dc: doc: Document which cpuflags exist
[00:22] <cone-205> ffmpeg.git 03Derek Buitenhuis 07master:876fe11e32bf: doc: Small grammar fix in -f description
[00:22] <cone-205> ffmpeg.git 03Derek Buitenhuis 07master:9f597052d460: doc: Fix grammar in -n description
[00:22] <cone-205> ffmpeg.git 03Derek Buitenhuis 07master:91b5ee66998e: doc: Grammar fixes for FFmpeg description
[00:22] <cone-205> ffmpeg.git 03Derek Buitenhuis 07master:fe64b88950d4: doc: Consistently use 'frame rate' everywhere
[00:22] <cone-205> ffmpeg.git 03Derek Buitenhuis 07master:9249b28e799c: doc: Grammar fixes for FFmpeg's detailed description
[00:22] <cone-205> ffmpeg.git 03Derek Buitenhuis 07master:9db706206d1e: doc: Consistently use 'filtergraph'
[00:22] <cone-205> ffmpeg.git 03Derek Buitenhuis 07master:a034cdf49d1a: doc: Grammar fixes for stream selection
[00:22] <cone-205> ffmpeg.git 03Derek Buitenhuis 07master:0cb2d32453ed: doc: Fix broken English in the common options description
[00:22] <cone-205> ffmpeg.git 03Derek Buitenhuis 07master:7d057515818d: doc: Grammar fixes for strem specifiers section
[00:29] <saste> jojva, which important functions?
[00:37] <jojva> saste: http://ffmpeg.org/doxygen/trunk/h264_8c.html
[00:37] <jojva> for example field_end(..)
[00:39] <jojva> I understand this is h264-specific, still this is a little confusing
[00:40] <saste> jojva, internal functions don't need to be documented
[00:40] <saste> the important part is the public API, which is used by applications
[00:43] <jojva> why doesn't it need to be documented ? yeah the API is the most important, but getting to understand h264 is tricky and some documentation would only help
[00:44] <jojva> with the soec aside
[00:44] <jojva> spec*
[00:45] <michaelni> wm4, how can i reproduce the assert failure ?
[00:48] <wm4> michaelni: happens with some older git snapshot of ffmpeg only (a debian/dmo version), can't reproduce with recent git
[00:50] <wm4> happens when passing 6 channel audio through libswresample (using default layouts for in/ou)
[00:50] <wm4> *out
[00:51] <wm4> not sure what version of ffmpeg this is, swresample.h has 0.15.100 as version
[01:12] <michaelni> could be some 0.11.* or 1.0.*
[12:39] <burek> hi all :)
[12:40] <burek> this might be an interesting feature (if not implemented): http://ffmpeg.gusari.org/viewtopic.php?f=12&t=876
[12:40] <burek> in short, the possibility to switch the order of the streams in the overlay filter, without restarting ffmpeg process
[12:53] <cone-981> ffmpeg.git 03Luca Barbato 07master:0933fd153356: oma: Validate sample rates
[12:53] <cone-981> ffmpeg.git 03Michael Niedermayer 07master:24f822c3ab99: Merge remote-tracking branch 'qatar/master'
[13:24] <saste> burek: changing position of an overlay on the fly is already implemented in an experimental patchset i implemented
[13:25] <saste> changing overlay size will imply dynamic filtergraph reconfiguration, which is not yet implemented
[13:38] <cone-981> ffmpeg.git 03highgod0401 07master:189cbc1a0357: opencl wrapper based on comments on 20130401
[13:38] <cone-981> ffmpeg.git 03Michael Niedermayer 07master:76071322a32e: opencl: fix double ;
[13:38] <cone-981> ffmpeg.git 03Michael Niedermayer 07master:ce841bc03263: Changelog: add entry for OpenCL
[13:44] <burek> saste, that's great :)
[13:46] <burek> saste, do you have any url to ml or something for more info?
[13:49] <saste> burek: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/159441
[13:50] <burek> thank you :)
[15:19] <cone-981> ffmpeg.git 03Nicolas George 07master:f810ca63f804: lavfi: detect merge failure for unknown layouts.
[15:19] <cone-981> ffmpeg.git 03Nicolas George 07master:9dd54d74226e: lavd/v4l2: fully init an ioctl argument.
[15:19] <cone-981> ffmpeg.git 03Nicolas George 07master:983d04dd40a4: lavu/opt: make sure av_opt_set_bin() handles NULL/0.
[15:19] <cone-981> ffmpeg.git 03Nicolas George 07master:52853077ee49: lavfi/af_asetnsamples: fix EOF handling.
[15:19] <cone-981> ffmpeg.git 03Michael Niedermayer 07master:599866f5d5e6: Merge remote-tracking branch 'cigaes/master'
[16:53] <neXyon> hi, is there somewhere an example on how to encode planar audio formats? I tried deinterleaving my samples and using avcodec_fill_audio_frame and avcodec_encode_audio2 but it doesn't work :-/
[17:19] <jojva> is it described somewhere in mpegts spec that when demuxing h264 packets, 1 packet = 1 h264 picture ? because when i use it with h264 mvc packets, the packets are like : 1 packet = 2 pictures
[17:23] <neXyon> why does this function: http://ffmpeg.org/doxygen/trunk/samplefmt_8c_source.html#l00125 return 128 with the parameters NULL, 1, 1, AV_SAMPLE_FMT_FLTP, 0? I don't get it
[17:25] <neXyon> ah, I saw it
[17:26] <nevcairiel> number of samples was aligned to 32
[17:26] <nevcairiel> 32 * 4 bytes ..
[17:27] <neXyon> yeah, thanks :D
[17:27] <neXyon> just found it out ^^
[17:28] <neXyon> so better just use av_get_bytes_per_sample(c->sample_fmt) instead :D
[17:28] <nevcairiel> if thats all you want
[17:28] <kierank> jojva: you can have as many pictures as you like in a ts packet
[17:29] <kierank> some people put a whole GOP in
[17:29] <nevcairiel> thats why we have the h264 parser to split it again
[17:30] <jojva> nevcairiel: ooh that explains a lot, it's the h264 parser that splits the packets into 1 picture packets ?
[17:30] <nevcairiel> pretty much, yes
[17:30] <jojva> the it must be the responsible for the bad splitting of mvc packets
[17:30] <jojva> then*
[17:31] <nevcairiel> it probably has no clue what to do with those NALUs
[17:31] <kierank> jojva: why not start with the reference samples
[17:31] <jojva> kierank: start again ?
[17:31] <kierank> why not try decoding the mvc reference clips first
[17:31] <kierank> instead of going straight to ts
[17:32] <jojva> i don't understand
[17:32] <kierank> there are clips designed to test mvc decoders on the itu website
[17:33] <kierank> which are raw h264
[17:33] <kierank> why don't you start with those first
[17:33] <kierank> otherwise you have to fix all the ts stuff and then work on the decoder
[17:36] <jojva> ok, much clearer now, i didn't know there were reference clips. the problem is I have to decode .MTS files (using MVC), and up until now i just hacked stuff, reorganizing MVC packets. it's quite working. damn i'd have gone faster if i knew about these clips
[17:37] <jojva> but now that the decoder is working a little it's time to think about mpegts, and why these packets aren't right..
[17:37] <kierank> you are going to have huge problems with ts
[17:38] <jojva> kierank: why
[17:38] <kierank> ffmpeg decodes packets as they appear in a ts
[17:38] <kierank> not as per dts
[17:39] <kierank> ts allows you to write some left views and then some right views
[17:39] <kierank> as long as dts is followed
[17:39] <nevcairiel> so they have to be interleaved properly back before the decoder
[17:39] <kierank> so you're going to have to reorder a ton of packets
[17:39] <kierank> in a realtime ts demux you'd use pcr and know when to stop
[17:40] <kierank> but in ffmpeg you can't
[17:40] <kierank> and in the lavf/lavc api, where do you do the reordering
[17:40] <jojva> well i don't know if it's luck but what i've been doing is reordering the packet like this : left - left - right - right - left... in the order they come
[17:40] <kierank> surely it's L,R,L,R
[17:41] <kierank> since LR have the same dts
[17:41] <jojva> (the samples i have contain field)
[17:41] <kierank> oh
[17:41] <kierank> yeah field is another annoyance
[17:41] <jojva> but still, i'm not sure LLRR is the right thing
[17:42] <kierank> but afaik a central premise of  lavf is that you can intersperse packets in an order as you please as long as dts is monotonic
[17:42] <kierank> ts is totally different
[17:43] <jojva> so bascially, it's the whole mpegts demuxer that should be rewritten ?
[17:43] <kierank> no, you just have to hope the reordering is not too complex
[17:43] <kierank> the chances are the mux will write them sequentially
[17:44] <kierank> you may even have to assume that
[17:45] <jojva> ok thx
[17:45] <kierank> it should be quite simple to make a decoder that does the frame mvc samples
[17:45] <kierank> from itu
[17:45] <kierank> because progressive reference list is simple
[17:45] <kierank> fields, i don't know how lavf treats them
[17:46] <kierank> lavc*, because it outputs everything as a frame
[17:46] <jojva> it's already implemented
[17:47] <kierank> you'll have to modify the reference list for mvc
[17:47] <jojva> h264 just waits for the second field before outputting it
[17:47] <nevcairiel> how would the decoder output the frames? L/R alternating?
[17:47] <kierank> yes
[17:47] <kierank> that's inherently how the frames are in mvc
[17:47] <jojva> nevcairiel: it shall be an API discussion, but I guess yes L-R
[17:48] <kierank> or you could use bufref to do it side by side
[17:48] <kierank> with edge emu
[17:49] <jojva> kierank: i'm not used to ffmpeg, i don't know what edge emu or bufref are
[17:49] <nevcairiel> SBS would be bad for people that want to have them any other way, the real options i see are either L/R, or somehow allow outputting multiple "views" in one AVFrame
[17:50] <jojva> nevcairiel: it could be problematic since MVC is not only 3D but any number of views (1024)
[17:54] <jojva> and yep, SBS doesn't seem like an option, they'd have to be independant frames
[18:37] <iive> jojva: edge emu is easy. if you want to hear a lecture from me :)
[18:39] <iive> simples prediction mode is when you take 16x16 from any position in the previous image. the motion vector points to the starting edge of this square. in mpeg2 you cannot point outside the image area.
[18:40] <iive> somewhere in h263+ they allow this, by virtually extending the pixels of the edge of the image.
[18:42] <iive> in practice there are 2 ways to do that. add padding to the image buffer from all sides, so you have 16pixels more around every frame. in that case the visible image won't start at the allocated memory and you will have linesize/stride wider than width.
[18:42] <jojva> (i'm reading)
[18:43] <iive> the second way is to detect such vectors and copy the image pixels into small temporal buffer and do the extension inside it. This is what emu_edge does, it emulates edge pixels.
[18:48] <iive> since padding (#1) needs to be updated every frame for the whole frame, no matter if we have 0 or more out-of-bound vectors, it may be significantly slower. But if we have e.g. h264 where each 4x4 block can have its own motion vector, the emulation may not be exactly optimal.
[18:50] <iive> emu-edge is generally preferred, as it allows smaller image buffers and is usually faster. Still if some codecs works better with padding then it is set to use it.
[18:51] <iive> not long ago BBB tested h264 and found that emu-edge works better with it, so now h264 is using emu-edge.
[18:54] <iive> hehe, information overload :)
[19:07] <BBB-work> the reason it's faster is b/c you do the same operations, but on-demand, and thus "only when there are MVs that extend beyond the border"
[19:07] <BBB-work> in many clips, this goes either in only one direction, or not at all
[19:08] <BBB-work> thus doing it on-demand is faster than doing it always on all edges
[19:08] <BBB-work> it can be done faster by doing it on-demand on full edges but we're too lazy to do that and test if it's faster
[19:45] <michaelni> btw ive fixed the doxygen issues yesterday, if someone spots more issues please report them!
[19:52] <durandal_1707> how added those nonsense images to ffmpeg summer of code 2013 page?
[19:57] <michaelni> all the wiki pages should have a history
[20:01] <cone-981> ffmpeg.git 03Clément BSsch 07master:2208a46f8f27: cmdutils: fix build with --disable-avfilter.
[20:01] <ubitux> durandal_1707: what's wrong with the pictures? :)
[20:02] <durandal_1707> 1st look unprofessional and childish
[20:25] <saste> durandal_1707, that's why we are unprofessional and childish ;-)
[20:35] <ubitux> michaelni: looks like mandelbrot (or ffplay) became slower
[20:35] <ubitux> i can't do ffplay -f lavfi mandelbrot without -noframedrop anymore
[20:36] <michaelni> do you know which commit caused it ?
[20:36] <ubitux> nope, no idea
[20:41] <cone-981> ffmpeg.git 03Clément BSsch 07master:6278bc8a6c27: lavfi/curves: make use of options to store the preset names.
[20:52] <cone-981> ffmpeg.git 03Michael Niedermayer 07master:f7a02d5d694b: ffmpeg: initialize got_output, this silences a compiler warning from icc
[20:52] <cone-981> ffmpeg.git 03Michael Niedermayer 07master:4394528d2d2f: cavsdsp: fix "warning: initialization discards const qualifier from pointer target type"
[20:55] <michaelni> ubitux, first 80sec no framedrop here
[20:56] <ubitux> after 1 or 2 seconds i get framedrop
[20:56] <ubitux> but i only have a i7 920 :(
[21:01] <ubitux> actually, it's < 1 sec
[21:02] <michaelni> i get framedrops begining at about 100sec
[21:03] <michaelni> and it stops ffplay HEAD but ffplay.c checked out from 13march continues with framedrops
[21:03] <michaelni> so its ffplay it seems
[21:04] <ubitux> ok
[21:04] <michaelni> i wont bisect as it takes 100sec for each run to find out if its affected, others can do quciker
[21:04] <michaelni> also should be reported to marton
[21:19] <durandal_1707> saste: have some unanswered questions about sox?
[21:20] <saste> yes, this question ^
[21:20] <saste> now that i think at it, it is not anymore unanswered
[21:20] <durandal_1707> so you understand everything?
[21:21] <saste> about sox... just need to find some quality time
[21:21] <saste> main problem seems related to configuration, since some sox effects only supports a limited set of samplerates/formats/channel layouts
[21:21] <saste> so i need to extract that information, and adapt query_formats accordingly
[21:53] <ubitux> would be nice if our gif encoder was able to generate such things: http://i.imgur.com/WTauw87.gif :)
[21:54] <durandal11707> SSzcrt vf nirfbzr
[21:56] <durandal11707> jr unir gjb njshyy tvs rapbqref
[21:56] <ubitux> yes
[21:57] <ubitux> durandal11707: gjb?
[21:58] Action: gnafu believes in utmost security, which is why he encodes all his messages with rot13 /twice/.
[21:58] <durandal11707> lrf, bar va tvs zhkre naq bar va tvs rapbqre
[21:59] <ubitux> durandal11707: bx; ogj, jul ner lbh hfvat ebg13?
[22:01] <gnafu> hovghk: Cebonoyl whfg yrnearq nobhg vg gbqnl nsgre ybbxvat ng Fynfuqbg.
[22:02] <ubitux> ok :p
[22:06] <durandal11707> zdpajolk jopwly iljhbzl vm nuhbm
[22:21] <gnafu> Oh, hey.  Is this you? --> http://www.okcupid.com/profile/Durandal_1707/photos
[22:23] <durandal_1707> gnafu: i don't have profile on okcupid
[22:24] <gnafu> So someone else with same username, or someone made you a profile on there?
[22:24] <durandal_1707> why are you so interested?
[22:25] <gnafu> I just felt like googling your username to see what came up :-P.
[22:25] <gnafu> Sometimes I get curious like that.
[22:25] <gnafu> And since I'm not a cat, it usually turns out alright.
[22:25] <gnafu> I find it fun to know what people look like :-).
[22:26] <llogan> gnafu: other people have played Marathon
[22:28] <durandal_1707> whole trilogy and beyond
[22:29] <gnafu> Aah, see, I didn't know where your username came from, and so it seemed fairly unique (especially with the number) :-P.
[22:29] Action: gnafu reads up on Marathon...
[22:32] <gnafu> Is 1707 something from the games?
[22:34] <durandal_1707> http://farm4.static.flickr.com/3225/2659535429_342f1520e5_o.jpg
[22:52] <durandal_1707> is there function that returns size of single sample from sample format?
[23:00] <durandal_1707> llogan: you made that ffmpeg gsoc logo?
[23:00] <saste> durandal_1707,  av_get_bytes_per_sample?
[23:01] <durandal_1707> saste: yes, i found it already
[23:06] <llogan> durandal_1707: yes
[23:07] <llogan> i thought it would be a good google attractant.
[23:08] <durandal_1707> looks like engines of airplane are turned off
[23:09] <llogan> it's ecofriendly
[23:10] <llogan> or a model plane
[23:24] <llogan> durandal_1707: now look. somewhat better.
[23:25] <llogan> exhaust is a bitch to add so i didn't add it
[23:27] <durandal_1707> llogan: what changed?
[23:35] <llogan> the propeller. you may need to force refresh
[23:57] <cone-981> ffmpeg.git 03Stefano Sabatini 07master:57d77b3963ce: lavu/opencl: apply misc cosmetics fixes
[23:57] <cone-981> ffmpeg.git 03Stefano Sabatini 07master:064acc9743ed: lavu/opencl: use consistent inclusion header guard name
[00:00] --- Tue Apr  2 2013