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

[burek]

[00:19] <saste> ubitux: what about the reference ffprobe patch?
[00:19] <saste> it's breaking compatibility, but i don't think people will care
[00:19] <ubitux> saste: i'm ok with it
[00:20] <saste> also i see no real sane alternative
[00:20] <saste> going to push then...
[00:20] <ubitux> it's fine, IMO
[00:26] <ubitux> BBB-work: the subtitles dependency was easy to solve
[00:26] <ubitux> do you want to test a patch?
[00:28] <ubitux> patch on ml, in case you're interested
[00:30] <cone-359> ffmpeg.git 03Stefano Sabatini 07master:b2098d2417a0: lavu/eval: add bitor and bitand functions
[00:30] <cone-359> ffmpeg.git 03Stefano Sabatini 07master:356922e23769: doc/filters: add bit-slicing example in lutyuv docs
[00:30] <cone-359> ffmpeg.git 03Stefano Sabatini 07master:0407a79e412e: lavfi/blackframe: add support for named options
[00:30] <cone-359> ffmpeg.git 03Stefano Sabatini 07master:db36ea5b5e62: lavfi/settb: add support for named options
[00:30] <cone-359> ffmpeg.git 03Stefano Sabatini 07master:f7ab23b0d0a8: ffprobe: remove deprecated frame "reference" field
[00:30] <ubitux> oups, forgot one.
[00:32] <ubitux> i guess you'll win about 100K
[00:33] <ubitux> heh no, more like 3K
[00:36] <saste> ouch so many patches...
[00:36] <saste> michaelni, you ok if i push the ffplay patch?
[00:36] <saste> then we can flame about the push policy later ;-)
[00:38] Action: ubitux is waiting for ffplay -af for a long time as well
[00:38] <Daemon404> hey saste 
[00:38] <Daemon404> whatever happned WRT VP6 in ffprobe
[00:39] Action: Daemon404 hasnt been following
[00:39] <saste> Daemon404, i want to push the michaelni oneliner
[00:39] <saste> and find a proper fix later
[00:39] Action: ubitux is also for the oneliner
[00:39] <Daemon404> im not, because anywhere you special-case codec ids is Doing It Even More Wrong
[00:39] <Daemon404> but im outvoted
[00:39] <Daemon404> so ill hsh up
[00:39] <Daemon404> hush*
[00:40] <saste> Daemon404, the alternative is an application level 30-lines hack
[00:40] <saste> so I prefer the 1-line hack
[00:40] <saste> that said, the code in utils should be improved
[00:40] <Daemon404> i prefer to take a generic approach rather than special case ids
[00:40] Action: Daemon404 shrugs
[00:40] <ubitux> it's also in the same place of an already existing hack
[00:40] <saste> so we don't need special case hacks
[00:40] <ubitux> for that same purpose
[00:40] <Daemon404> which also shouldnt exist
[00:41] <ubitux> the oneliner + a FIXME/TODO is IMO the best thing
[00:41] <Daemon404> imo is to remove that hack
[00:41] <Daemon404> and document teh behavir
[00:41] <Daemon404> in teh api docs
[00:41] <ubitux> that's the next step
[00:42] <saste> Daemon404, not an API problem, but I spent some time on the code and couldn't make much sense of it
[00:42] <Daemon404> as it is right now:
[00:42] <Daemon404> 1) remove hacl
[00:42] <saste> that is i can't find a proper fix without spending some significant effort on it, which takes time, which i don't have
[00:42] <Daemon404> 2) document that width/height may be reset
[00:42] <Daemon404> 3) ???
[00:42] <Daemon404> 4) profit
[00:43] <saste> yes, everyone is good at doing lists ;-)
[00:44] <Daemon404> why is a hacky list of IDs preferable to what i listen?
[00:44] <Daemon404> listed*
[00:44] <ubitux> you forgot to s/???/do a 30-lines hack in all apps/
[00:45] <Daemon404> its only 30 lines because ffprobe has so much abstraction
[00:45] <Daemon404> but yes lets just make more shitty codec id special cases
[00:45] <Daemon404> because we dont have enough of the mshat around the code base yet
[00:46] <ubitux> it could be worse if ffprobe was supporting multiple inputs
[00:46] Action: Daemon404 must run off for a st patricks day celebration now
[00:46] <ubitux> happy st shitbricks
[00:46] <michaelni> saste, marton is ffplay maintainer, dont ask me if something should be pushed ...
[00:50] <saste> michaelni, allright going to fix the nits and push the patch then
[00:53] <Daemon404> #
[00:53] <Daemon404> woops
[00:53] Action: Daemon404 gone
[01:03] <saste> what's base field in swapuv good for?
[01:04] Action: saste can't understand all the convolutions in swapuv is_planar_yuv() code
[01:06] <ubitux> saste: we can likely remove it
[01:06] <ubitux> it was added during the port; i was making sure all the necessary fields were swapped
[01:06] <ubitux> the field wasn't deprecated at that time yet
[01:06] <saste> ubitux, yes i think so
[01:09] <Compnn> mplayer's swapuv is just for the red/blue color change innit ?
[01:30] <ubitux> saste: what do you find pointless? the doxy or the fork compat in this case?
[01:30] <saste> the doxy
[01:31] <saste> it's just confusing if we start to distinguish libav and ffmpeg API
[01:31] <saste> and completely irrelevant for the user
[01:31] <ubitux> ok
[01:47] <cone-359> ffmpeg.git 03Clément BSsch 07master:2b27f7fb04c5: lavfi/thumbnail: replace frame unref with free.
[01:49] <ubitux> saste: i think you forgot to update a few fate ref
[01:49] <ubitux> fate is gonna turn yellow soon
[01:50] <ubitux> (filter-metadata-scenedetect is failing here)
[01:50] <saste> damn
[01:57] <ubitux> michaelni: did you see the invalid read in scale filter?
[01:57] <ubitux> (lavfi-scalenorm failure in valgrind instance)
[01:58] <saste> ubitux, is fate-eval failing for you?
[01:58] <saste> i'm sure I tested before pushing...
[01:59] <ubitux> yes
[01:59] <ubitux> maybe you tested before git pull --rebase :p
[02:05] <ubitux> this AVPacket buf ref count is messing quite a bunch of code
[02:06] <cone-359> ffmpeg.git 03Stefano Sabatini 07master:72a1257b5bf9: tests/eval: fix reference after b2098d2417a085d33d99738dd7f963c7b260a0bf
[02:06] <cone-359> ffmpeg.git 03Stefano Sabatini 07master:be5c5c399bac: tests/filter-metadata-scenedetect: update reference
[02:07] <saste> time to sleep or i'll do more damage
[02:07] <ubitux> thx for the fix
[02:08] <ubitux> :)
[02:25] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:f566ac48ce45: avutil/frame: fix video buffer allocation
[02:27] <ubitux> michaelni: is this FF_INPUT_BUFFER_PADDING_SIZE or something else?
[02:29] <wm4> wow magical numbers for padding
[02:30] <wm4> how does this even make sense
[02:33] <wm4> so, what is this... do user created image buffers require this too? what is it for?
[02:33] <wm4> where is it documented?
[02:34] <wm4> and why is the code doing this not fixed instead?
[02:39] <michaelni> some code does overread, if you use that code, yes you have to allocate a few bytes more
[02:39] <michaelni> it should be documented somewhere
[02:41] <ubitux>  * @warning The input buffer must be FF_INPUT_BUFFER_PADDING_SIZE larger than
[02:41] <ubitux>  * the actual read bytes because some optimized bitstream readers read 32 or 64
[02:41] <ubitux>  * bits at once and could read over the end.
[02:41] <ubitux> michaelni: so this +16 is indeed FF_INPUT_BUFFER_PADDING_SIZE?
[02:41] <michaelni> no
[02:43] <michaelni> but you could "extend" its meaning and use it in principle
[02:44] <wm4> so why is the code not fixed to not overread
[02:45] <wm4> and this "documentation" as you like to call it appears 3 times in avcodec.h
[02:45] <wm4> and none of these have to do with AVFrame
[02:48] <michaelni> "so why is the code not fixed to not overread" <--- because noone sent a patch
[02:48] <michaelni> and i did not mean the FF_INPUT_BUFFER_PADDING_SIZE docs, i meant some other but 
[02:48] <michaelni> i dont remember, this is old code
[02:49] <wm4> you don't remember even though you just fixed a problem related to it?
[02:51] <michaelni> i remember that some filters, swscale, possibly others overread and that the extra allocation is thus needed
[02:51] <michaelni> i do not remember where it was documented 5+? years ago
[02:52] <wm4> so the project leader doesn't even know where it's supposedly documented, but users are supposed to know
[02:55] <michaelni> it should be documented at the places where user allocated buffers are documented, iam pretty sure its not documented there, thats bad and we should fix that
[02:57] <michaelni> wm4, if you want to add such a note to where you expected it should be, iam happy to apply a patch or merge a branch with such changes
[02:57] <michaelni> if not ill put it on my todo
[02:58] <ubitux> ok, yet another memleak fixed.
[03:12] <cone-359> ffmpeg.git 03Clément BSsch 07master:286153ea4861: lavfi/alphaextract: fix frame memleak.
[03:17] <ubitux> btw, what's the story about setting avctx avframe?
[03:17] <ubitux> it seems we added some init a while ago
[03:17] <ubitux> libav dropped what they had already in TEP
[03:17] <ubitux> then put some back
[03:18] <ubitux> then we dropped some, and added other
[03:18] <ubitux> what's the conclusion of this?
[03:18] <ubitux> because if they are not necessary (already done at init?), we should drop then
[03:18] <ubitux> otherwise, there are quite a bunch of codecs where they need to be restored
[03:22] <michaelni> codecs should not put a AVFrame in their context (due to sizeof AVFRame dep) but if they do they probably should init it not just leave at 0
[03:24] <ubitux> oh so it's only necessary for the codecs with a AVFrame in there context, ok.
[03:24] <michaelni> wm4, sent patch that documents it, comments welcome
[03:30] <ubitux> michaelni: sent some questions, sorry if some sound stupid
[03:52] <ubitux> michaelni: and is this true for encoders as well?
[03:57] <michaelni> its always a good idea to align linesizes
[03:57] <ubitux> michaelni: no i meant about the frame defaults sorry :p
[03:58] Action: ubitux always thinking everyone is in his context
[03:59] <michaelni> id say that using a struct without correctly initializing it is in general not a good idea
[04:02] <ubitux> michaelni: i was looking at every AVFrame in local context, and asv encoder was the first candidate
[04:03] <ubitux> where no init is done; so i'm wondering about what to do in such situation
[04:03] <ubitux> oh ffplay -af merge request, yay.
[04:41] <cone-359> ffmpeg.git 03Clément BSsch 07master:3313b9cc2d67: lavc: remove unecessary a64enc include.
[05:25] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:0f95534669a1: h264_qpel: fix another forgotten int stride
[05:29] Action: ubitux note that it would be nice to be able to v4l2 push with ffmpeg
[05:31] <cone-359> ffmpeg.git 03Marton Balint 07master:1822519d2a13: ffplay: restructure audio stream opening code
[05:31] <cone-359> ffmpeg.git 03Marton Balint 07master:9eafdd518cc8: ffplay: use frame->pts if available for setting the audio clock
[05:31] <cone-359> ffmpeg.git 03Marton Balint 07master:738487f8db8a: ffplay: use refcounted frames for audio
[05:31] <cone-359> ffmpeg.git 03Marton Balint 07master:e96175ad7b57: ffplay: add -af option
[05:31] <cone-359> ffmpeg.git 03Michael Niedermayer 07master:9f95e355be16: Merge remote-tracking branch 'cus/stable'
[05:32] <ubitux> \o/
[06:16] <BBB> have all simd functions been fixed to not use movsxdifnidn?
[08:03] <ubitux> BBB: that's not what git grep seems to say
[08:03] <ubitux> BBB: btw, did you see the lavf/subtitles.c dep patch?
[08:05] <ubitux> michaelni: btw, i'll commit the subtitles charenc memleak later today
[08:05] <ubitux> unless you have an objection
[08:08] <nevcairiel> michaelni: there is a h264 regression since one of your post-merge fixes, https://ffmpeg.org/trac/ffmpeg/ticket/2371 .. in case you want to look into it
[08:32] <ubitux> is Giorgio Vazzana on IRC?
[12:13] <cone-678> ffmpeg.git 03Paul B Mahol 07master:79b183572694: sndio_dec: add missing #include for av_gettime()
[12:18] <Tjoppen> michaelni: I see that mxf patch. I haven't dived into the file to figure out if the patch is ok though
[12:18] <Tjoppen> it looks a bit stinky
[12:59] <cone-678> ffmpeg.git 03Reinhard Tartler 07master:23f4c5acc438: document the release process
[12:59] <cone-678> ffmpeg.git 03Michael Niedermayer 07master:ac1cea55ad0f: Merge commit '23f4c5acc438366d84cacf49e33b0bcd72f04937'
[13:03] <durandal_1707> saste: why so big delay for report?
[13:04] <saste> durandal_1707, because i'm lazy
[13:04] <cone-678> ffmpeg.git 03Anton Khirnov 07master:6552808014ae: lavc,lavfi: fix calculating the plane size in the AVBufferRef wrappers
[13:04] <cone-678> ffmpeg.git 03Michael Niedermayer 07master:171bd38edad5: Merge remote-tracking branch 'qatar/master'
[13:08] <cone-678> ffmpeg.git 03Stefano Sabatini 07master:f7d1a18c90d1: ffplay: remove unused variable "codec"
[13:08] <cone-678> ffmpeg.git 03Stefano Sabatini 07master:5fe542d7e161: ffplay: remove options skiploop, skipidct, skipframe
[13:08] <cone-678> ffmpeg.git 03Stefano Sabatini 07master:5787a7163735: lavfi/swapuv: remove deprecated base field use
[13:08] <durandal_1707> saste: i noted it on your file :/
[13:09] <saste> durandal_1707, ?
[13:11] <durandal_1707> nvm, ignore
[13:28] <Compnn> saste : i tried getting the projects together just to organize new samples/codecs so we all wouldnt have to reinvent the fourcc maps. but couldnt get anyone involved
[13:28] <Compnn> by projects i mean perian, ffdshow, vlc, ffmpeg, mplayer, xbmc etc
[13:29] <saste> Compnn, during a discussion it was mentioned transmission.cc, which already has an infrastructure
[13:30] <saste> basically we may start with a mailing list, and some developers for the various involved projects joining it
[13:31] <saste> there are a lot of common issues, and not much communication (outside face-to-face events)
[13:31] <Compnn> oo
[13:32] <Compnn> transmission.cc wiki full of spam
[13:32] <Compnn> saste : yes, sounds like a good idea. i still want to do my idea of cherry picking commits to certain fourcc lists from each project and having them sent to one ml
[14:05] <onto> Hi! Is it possible to record audio using libavcodec? I am using OpenCV for video but would like to record audio as well.
[14:07] <durandal_1707> recording is done with libavdevice
[14:07] <onto> durandal_1707: oh
[14:08] <onto> are there any tutorials/sample code regarding libavdevice?
[14:08] <onto> I found one at dranger.com but it seems outdated and has nothing about recording
[14:13] <durandal_1707> libavdevice api is same as libavformat
[14:14] <onto> durandal_1707: ok, I will look into it! Thank you!
[14:14] <durandal_1707> so you would first need libavdevice installed and it should have support for your os
[14:15] <onto> I compiled ffmpeg from source, will that not ensure it's installed (and supported)?
[14:18] <durandal_1707> see ffmpeg -formats output and look for capture/record
[14:19] <durandal_1707> dshow capture is supported
[14:20] <onto> durandal_1707: It seems it isn't supported
[14:20] <durandal_1707> what os are you using?
[14:20] <onto> durandal_1707: ubuntu 12.03
[14:20] <onto> 12.04*
[14:21] <durandal_1707> than you want alsa, dshow is for windows
[14:21] <onto> I only have "ALSA audio output" -- none for capture
[14:22] <durandal_1707> it should have DE at start
[14:22] <onto> durandal_1707: Yes, it does
[14:22] <durandal_1707> D means it have capture
[14:22] <onto> oh
[14:22] <onto> sorry for the stupidity, I'm new :)
[14:23] <durandal_1707> its just silly naming, and nobody care/noticed
[14:23] <durandal_1707> in source code thay are named differently but in output only one wins
[14:23] <Jordan_> is there any way to use the rational parts of SAR or DAR from the scale filter
[14:28] <cone-678> ffmpeg.git 03Michael Niedermayer 07master:fa7031ad3752: h264_refs: fix typo in refs fallback check
[14:35] <cone-678> ffmpeg.git 03Nicolas George 07master:3cd342636fa2: lavfi/buffersrc: set channel layout if it is known.
[14:35] <cone-678> ffmpeg.git 03Nicolas George 07master:f29c28a884c0: lavfi/buffersrc: check channel count changes.
[14:35] <cone-678> ffmpeg.git 03Nicolas George 07master:a5149607df82: lavfi/buffersrc: disable deprecated warnings.
[14:35] <cone-678> ffmpeg.git 03Nicolas George 07master:7e6c67dd24d7: lavfi/buffersink: fix header.
[14:35] <cone-678> ffmpeg.git 03Michael Niedermayer 07master:975fbd43addb: Merge remote-tracking branch 'cigaes/master'
[14:35] <onto> Would it be possible to capture video + audio with libavdevice/libavcodec and stream it "loss-lessly" over a network so that I can access it using opencv and process the frames?
[15:10] <durandal_1707> onto: yes
[15:24] <onto> durandal_1707: Could you give me some pointers?
[15:48] <BBB> ubitux: uhm, didn't check patch, maybe will try over the course of this week
[15:48] <BBB> ubitux: as for movsxdifnidn, it's ok if it's there, but if a function moves from int->ptrdiff_t, for that particular function, it should disappear
[15:48] <BBB> ubitux: but for int-stride functions we should keep it
[15:49] <BBB> ubitux: i.e. this needs some individual checking on each instance of a simd function using it
[15:49] <ubitux> i guess this last step was forgotten
[15:49] <ubitux> ok, thanks for the explanation
[16:17] Action: michaelni notes opensolaris is out of diskspace again
[16:26] <cone-678> ffmpeg.git 03Richard 07master:9cde9f70ab48: mpeg: Add passing DVD navigation packets (startcode 0x1bf) to caller to allow better playback handling of DVDs.
[18:51] <saste> ubitux, news about inverse telecine?
[20:17] <xlinkz0> does av_read_frame align pkt->data ?
[21:06] <michaelni> xlinkz0, pkt->data should normally be aligned, i dont know if there are corner cases where its not
[21:08] <michaelni> wm4, until the writeable issue with the decoders output is fixed you can assume that B frames from mpeg1/2/4/h263 and anything from true intra only codecs is writeable
[21:08] <michaelni> btw for which codecs is the writable thing wrong currently ?
[21:09] <xlinkz0> i just read in the decode_video2 docs that it should be aligned and i didn't know if ffmpeg already took care of it or i need to
[21:09] <wm4> michaelni: I tested with h264 only; but note that anton said he has this issue in his work queue
[21:11] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:e3be7b115929: avutil/get_pool: Remove redundant initial atomic operation
[21:11] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:c603f22683d8: avutil/get_pool: remove dead operations whichs result is never used.
[21:12] <michaelni> wm4, ok then ill leave that to anton and hope it can be merged without problems
[21:13] <wm4> yep
[21:52] <nevcairiel> the writable thing should be fine for the "simpler" codecs, its only wrong for the ones with complex frame mangement
[21:55] <nevcairiel> that reminds me, one more thing to use
[22:00] <cone-204> ffmpeg.git 03Nicolas George 07master:40ea006b766e: ffmpeg: make -lavfi an alias for -filter_complex.
[22:00] <cone-204> ffmpeg.git 03Nicolas George 07master:ec7fc7b7d1f0: fate: add a test for -filter_complex / -lavfi without input.
[22:00] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:36258f982994: Merge remote-tracking branch 'cigaes/master'
[22:55] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:ef3c88838e1a: doc/developer: Add "security fixes" to the release process steps
[00:00] --- Mon Mar 18 2013