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

[burek]

[01:07] <cone-678> ffmpeg.git 03Michael Niedermayer 07master:02d6d0533966: dcadec: check xch_base_channel against channel_order_tab.
[01:07] <cone-678> ffmpeg.git 03Michael Niedermayer 07master:b6671787db5b: flashsv2_prime: check block before using it.
[01:59] <cone-678> ffmpeg.git 03Jean First 07master:a8b3f0c5cf54: fate: check if rsync has the contimeout option
[11:59] <cone-961> ffmpeg.git 03Stefano Sabatini 07master:96d815fc0c71: lavc: add pkt_size field to AVFrame
[11:59] <cone-961> ffmpeg.git 03Stefano Sabatini 07master:1a490df12fd9: ffprobe: show pkt_size in frame
[11:59] <cone-961> ffmpeg.git 03Stefano Sabatini 07master:33ab9ebd09ba: doc/APIchanges: fill empty git commit hashes and dates
[12:46] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:75b7e543df05: fate: update fate for 1a490df12fd9
[13:48] <cone-961> ffmpeg.git 03Luca Barbato 07master:bb675d3ac6d7: vp56: make parse_header return standard error codes
[13:48] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:f186ecc164e8: Merge commit 'bb675d3ac6d722d5e117ae9042a996b55ca05b1d'
[13:52] <cone-961> ffmpeg.git 03Stefano Sabatini 07master:8f44170d307a: lavfi/avfilter.h: clarify doxy for AVFilterLink.out_buf
[13:52] <cone-961> ffmpeg.git 03Stefano Sabatini 07master:3d1e2ada2574: lavfi/overlay: remove duplicated definition of ff_null_get_video_buffer()
[14:10] <cone-961> ffmpeg.git 03Stefano Sabatini 07master:54b0c04ae3a4: lavfi/overlay: clarify/fix comment, add a few empty lines to ease readability
[14:22] <cone-961> ffmpeg.git 03Luca Barbato 07master:f33b5ba63eee: vp56: release frames on error
[14:22] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:ac6cb666d920: Merge remote-tracking branch 'qatar/master'
[15:49] <cone-961> ffmpeg.git 03rogerdpack 07master:fe3e0e486eb4: lavd/dshow: rename dshow class name
[16:17] <Compn> saste : is it possible to display metadata onscreen or output it to another app ? user is asking me :)
[16:17] <Compn> synched with the video, for gps coordinates
[16:18] <saste> where is the metadata stored?
[16:18] <Compn> guessing in the container
[16:19] <Compn> http://store.contour.com/ae/international/cameras/contour+-2/invt/1700/
[16:19] <Compn> that camera
[16:19] <Compn> Codec - H.264/AAC / File Type - MP4
[16:20] <Compn> from the tech page
[16:20] <Compn> mp4 metadata
[16:20] <saste> i suppose it needs per-frame metadata
[16:20] <saste> right now drawtext doesn't support metadata printing, but that can be easily fixed
[16:20] <Compn> yes i think it would be per-frame
[16:20] <Compn> or whenever it updates anyways
[16:21] <saste> the problem is that we support per-frame metadata only in the tiff decoder
[16:21] <Compn> well i dont think he needs to print it. just send it to another app
[16:21] <Compn> he emailed projects at mphq email
[16:21] <saste> short answer: no
[16:21] <saste> we miss support for per-frame metadata in most encoders
[16:22] <Compn> i'll see if i can get a sample 
[16:23] <saste> *decoders and encoders
[16:23] <Compn> ok thanks. i'll get a sample and we'll go from there 
[16:27] <Compn> i guess he only wanted the time from the gps data hmm
[16:51] <cone-961> ffmpeg.git 03Piotr Bandurski 07master:fef75ef20097: mpegvideo_enc/rv10: width and hieghtmust be multiple of 16
[16:51] <cone-961> ffmpeg.git 03Michael Niedermayer 07master:2b643855e024: dirac_parser: check prev_pu_offset before using it
[20:11] <michaelni> fate-run.sh[170]: tests/data/fate/lavf-png.err: cannot create [No space left on device]
[20:11] <michaelni> :)
[20:51] <cone-961> ffmpeg.git 03Stefano Sabatini 07master:1e5492ffe660: lavfi/crop: add support to option parsing
[20:51] <cone-961> ffmpeg.git 03Stefano Sabatini 07master:55b81528a991: doc/filters: itemize crop examples
[20:51] <cone-961> ffmpeg.git 03Stefano Sabatini 07master:6722f35dd33d: doc/filters: add basic crop examples
[21:00] <cone-961> ffmpeg.git 03Stefano Sabatini 07master:a871b5cc98c2: doc/filters: extend syntax description for transpose, and add examples
[21:03] <cone-961> ffmpeg.git 03Stefano Sabatini 07master:0ebf85774be2: doc/filters: remove @example use for showing syntax
[21:12] <barque> does libavcodec handle multi-threaded decoding internally? or do I have to use certain functions?
[21:13] <nevcairiel> you just have to tell it how many threads you want to use (or set it to automatic, which may be the default these days even), and it does everything for you
[21:14] <barque> ahh, what's the function for that?
[21:14] <barque> av_set_threads or something?
[21:14] <Daemon404> ohhh....
[21:14] <Daemon404> michaelni, i think that arm binutils fix may be what i was hitting
[21:14] <nevcairiel> its not a fix, it just complains when its broken
[21:15] <nevcairiel> barque: the AVCodecContext has a field "threads"
[21:15] <Daemon404> well yeah
[21:15] <barque> So basically I may simply be doing multi-threaded decoding just as it is... as of 0.11 even?
[21:15] <Daemon404> nevcairiel, nope
[21:15] <Daemon404> _count
[21:15] <Daemon404> :P
[21:16] <nevcairiel> barque: i'm not sure what the default is these days, automatic multithreading may be the default
[21:16] <Daemon404> nevcairiel, it's 1 i believe
[21:16] <Daemon404> from my testing
[21:16] <nevcairiel> so no m t
[21:16] <Daemon404> but hey it changes every week...
[21:20] <barque> so I set AVCodecContext::thread_count before the call to avcodec_open() ?
[21:21] <Daemon404> tbh im not sure of the order in which it needs to be set/called
[21:21] <Daemon404> not documented
[21:21] <nevcairiel> before opening
[21:22] <nevcairiel> set anything on the codec context before opening really
[21:22] <Daemon404> unless youre mplayer
[21:22] <Daemon404> then you set teh width and height after opening and make ffmpeg revert thinsg so it sitll works
[21:22] <barque> So that's a good order right?
[21:22] <barque> :P
[21:22] <barque> Just making sure...
[21:22] <nevcairiel> ffmpeg should f'ing stop cater to the horrible mplayer
[21:22] <Daemon404> =1
[21:23] <Daemon404> +1
[21:23] <Daemon404> barque, yeah before
[21:23] <barque> Ok great, thank you.
[21:23] <Daemon404> nevcairiel, the rational was they only wanted to open the png encoder once for all screenshots
[21:23] <Daemon404> for PERFORMANCE
[21:24] <Daemon404> because opening it once per screenshot will had too much time. or something.
[21:24] <nevcairiel> how many screenshots does it do ? :D
[21:24] <Daemon404> i dont kno
[21:24] <Daemon404> i have a hard time thinking of the "performance gains" of taking multiple differently-sized screensots
[21:24] <Daemon404> with the same avctx
[21:24] <nevcairiel> i should disable fate over the holidays, it makes my video streaming lag
[21:24] <Daemon404> or even a real-world use-case in mplayer
[21:25] <Daemon404> you run fate on a box you use to stream?
[21:25] <nevcairiel> usually it only delivers files, which doesnt care, but when i'm at my parents with their slow internet connection, i need to recode before streaming =p
[21:27] <Daemon404> streaming to what?
[21:27] <nevcairiel> to my laptop of course
[21:27] <nevcairiel> or my tablet, whatever i decide to take with me
[21:28] <nevcairiel> or both
[21:28] <Daemon404> ic
[21:28] <Daemon404> must be pretty intensely bad if you cant dl SD files in realtime
[21:29] <wm4> <nevcairiel> ffmpeg should f'ing stop cater to the horrible mplayer
[21:29] <nevcairiel> but my media library is mostly HD files, which is the problem
[21:29] <wm4> in what way is that the case?
[21:29] <wm4> I don't think mplayer2 has any incorrect API usage left
[21:29] <nevcairiel> so i have it recode in realtime to SD
[21:29] <Daemon404> wm4, he meant mplayer
[21:29] <Daemon404> not mplayer2
[21:29] <wm4> isn't mplayer's problem pretty much about the build system
[21:30] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=e8e575633faf19711910cf9caf59f7db300a9ccd
[21:30] <wm4> considering how often ffmpeg breaks it, there don't seem to be many caring about it anymore
[21:30] <wm4> well, that's just michael doing random commits...
[21:30] <Daemon404> grep -r -i mplayer *
[21:31] <Daemon404> lots of the old arcane weirdness in the api is mplayer related...
[21:31] <Daemon404> and "breaks mplayer" is a common respinse to sensible patches
[21:31] <nevcairiel> one that should be ignored
[21:31] <wm4> oh, like porting vdpau to hwaccel
[21:32] <cone-961> ffmpeg.git 03Piotr Bandurski 07master:388241efa2df: mpegvideo_enc/rv20: width and height must be multiple of 4
[21:32] <cone-961> ffmpeg.git 03Harald Axmann 07master:2d74dea84f3d: lavf: Provide a monotonic timestamp to the outside world
[21:32] <wm4> that one is causing me pain, actually
[21:32] <wm4> because vdpau works differently from the rest in weird ways
[21:32] <nevcairiel> did someone actually submit a patch for that?
[21:32] <wm4> yes, in 2009
[21:32] <wm4> beaten down by mplayer devs
[21:33] <nevcairiel> i think someone was talking about that over in the l channel
[21:33] <nevcairiel> about trying again
[21:33] <Daemon404> http://chromashift.org/a.txt <-- anyone see similar crashes to this before (arm) ?
[21:33] <Daemon404> (useless bt is useless.. rebuilding takes a long time)
[21:36] <nevcairiel> hm i'll have to give that mpegts wrap handling a try some time
[21:36] <Daemon404> ;p
[21:36] <Daemon404> the only .ts code i have can ignore timestamps
[21:36] <Daemon404> it's lovely
[21:37] <nevcairiel> i had my own hackery to deal with a single wrap and enable seeking, but it wasnt particularly submit-worthy
[21:37] <Daemon404> hehe
[21:37] <Daemon404> well having a d2v index makes it 1000% easier
[21:37] <nevcairiel> also 1000% slower when opening the file :)
[21:37] <Daemon404> the point isnt playback ;)
[21:38] <Daemon404> anyway, im still failing at leading open gops with b frames
[21:38] <Daemon404> spits out garbage and gets desynced
[21:38] <Daemon404> not sure the correct way to handle it
[21:38] <Daemon404> (mpeg2)
[21:45] <michaelni> Daemon404, about e8e575633, its bad if a library suddenly starts failing hard because parameters it doesnt need arent set. PNG doesnt need the dimensions during init so it should not fail, it also affects mplayer yes
[21:45] <Daemon404> michaelni, ffmpeg needs a clearly defined order of when to set things and call things
[21:45] <michaelni> we did not need the w/h in the past for PNg its kinda API breakage to require it suddenly
[21:46] <Daemon404> not "it may work depending on codec"
[21:46] <Daemon404> in teh future, i mean
[21:46] <michaelni> future sure
[21:46] <michaelni> but suddenly at a random git checkout is not good
[21:46] <Daemon404> why not api bump
[21:46] <Daemon404> or change it for next release
[21:46] <michaelni> possible
[21:48] Action: Daemon404 watched "how to design a good api and why it matters" last night and saw libav* basically violates every single recommendation :>
[21:58] <ubitux> was that video taking into account historical burden, and size of the project? :)
[21:58] <michaelni> also about hwaccel, anyone wants to review "[FFmpeg-devel] [PATCH] add code to make ffmpeg.exe can use dxva2 api" and write a productive review/reply ?
[22:00] <Daemon404> ubitux, im not sure how relevant it is to ffmpeg
[22:00] <Daemon404> that would be libav*'s api was designed
[22:00] <Daemon404> rather than just willedi nto existence
[22:01] <nevcairiel> I don' think i would manage a constructive review for that broken dxva patch
[22:01] <Daemon404> "format your code so it isn't all smashed on the left"
[22:01] <Daemon404> &
[22:01] <Daemon404> "dont add hacks into pthreads.c"
[22:01] <Daemon404> from a very cursory glance
[22:03] <nevcairiel> yeah the thread hackery is rather bad
[22:03] <wm4> apparently it just adds dxva readback; I don't understand why it needs other hacks all over the place
[22:03] <nevcairiel> but i'm also not convinced the whole patch is a good idea
[22:05] <nevcairiel> but yeah, before anyone reviews it, it should be properly formated and not mangled
[22:05] <Daemon404> i think he pasted it into his email client
[22:05] <Daemon404> it has wrappign and stuff
[22:05] <Daemon404> makes it utterly broken
[22:06] <michaelni> nevcairiel & Daemon404 the mail has a attached patch and one inline, the attachment looks better formated
[22:07] <Daemon404> oh
[22:07] <Daemon404> weird redundnacy
[22:11] <michaelni> without reading through the patch, one thing is that it should be split into libavcodec changes and application changes
[22:11] <michaelni> but there likely are more fundamental issues
[23:06] <ubitux> ./ffplay -i tests/lena.pnm -vf 'split[a][b]; [a]pad=iw*2-1[src]; [b]scale=iw-1:ih[filt]; [src][filt]overlay=w'  is it me or something is wrong on the right?
[23:07] <ubitux> it looks like sws is rounding from -1 to -2, and leave the last column to 0
[23:09] <Daemon404> have you tried setting teh accurate roundign flag?
[23:13] <ubitux> doesn't seem to help
[23:14] <wm4> av_pix_fmt_desc_next() returns invalid pixfmt descs
[23:14] <wm4> this is probably somewhat unintended
[23:15] <wm4> there are "holes" in the format list due to Libav compat hacks, and the function doesn't skip them
[23:16] <ubitux> qa
[23:16] <ubitux> oups
[23:17] <ubitux> wm4: it seems we check the name after the function
[23:17] <Compn> are any projects still using the libav compat stuff ?
[23:17] <ubitux> maybe that check should be inside the func
[23:18] <wm4> Compn: are you trolling?
[23:18] <Compn> i'm always trolling
[23:18] Action: Compn also may have forgotten what it was good for
[23:19] <Compn> something something drop in replacement compatability for ffmpeg/libav
[23:19] <Compn> my question, does anyone ever change libs like that ?
[23:20] <Compn> is it even fate tested ? has it ever been tested?
[23:20] <Compn> probably j-b knows about it
[23:21] <ubitux> wm4: http://pastie.org/5536822
[23:21] <ubitux> completely untested
[23:21] <ubitux> but i guess something like this would do?
[23:22] <wm4> perhaps
[23:22] <ubitux> forget the first chunk.
[23:22] <wm4> why?
[23:23] <ubitux> well maybe it's alright, i need to test
[23:25] <wm4> also what is PIX_FMT_PSEUDOPAL? does AVFrame export a palette for it or not?
[23:26] <Daemon404> isnt there a flag for plaetted formats
[23:27] <Daemon404> i.e. you dont need to special case
[23:27] <wm4> there's PIX_FMT_PAL (definitely exports a palette in data[1] as per "documentation")
[23:27] <wm4> but PIX_FMT_PSEUDOPAL, who knows
[23:27] <Daemon404> i thought there were like pix fmt dscriptors
[23:27] <Daemon404> flags
[23:28] <wm4> these are the flags
[23:28] <Daemon404> no theyre not
[23:28] <Daemon404> theyre the pix_fmt enums
[23:28] <wm4> AV_PIX_FMT_PAL8 is the pixfmt enum
[23:29] <wm4> actually the only format that has PIX_FMT_PAL set
[23:29] <Daemon404> ... they reused the PIX_FMT prefix?
[23:29] <Daemon404> thats fucking retarded
[23:29] <wm4> yes "they" did
[23:29] <ubitux> wm4: seems to work, patch sent, thx
[23:33] <pross-au> dae notice the downward trend in libav* mailing lists posts/patches..
[23:33] <Daemon404> pross-au, what context is this in?
[23:34] Action: Daemon404 doesnt know specifically which pross-au is referring to
[23:34] <pross-au> over the past ~three months
[23:34] <pross-au> libav.org posts/patches
[23:34] <Daemon404> libav* != libav
[23:37] <pross-au> http://gmane.org/plot-rate.php?group=gmane.comp.video.libav.devel
[23:38] <ubitux> our has a complete different layout
[23:38] <ubitux> that's pretty fun
[23:38] <wm4> but, the butthurt must go on!?!?
[23:38] <Daemon404> ffmpeg's got way lower than that in some areas
[23:38] <Daemon404> doesn't really seem like there are any conclusions to draw
[23:38] <Daemon404> validly, anyway.
[23:39] <pross-au> k
[23:39] <ubitux> http://gmane.org/plot-rate.php?group=gmane.comp.video.ffmpeg.devel
[23:39] <ubitux> it looks like different kind of mountains
[23:39] <Daemon404> i wonder what those big-ass spikes are
[23:39] <ubitux> 120 messages per day
[23:39] <ubitux> fear, it must be counting spam too
[23:40] <Daemon404> we did get some random chinese spam for a while
[23:40] <ubitux> you mean the dvxa patch?
[23:40] <Daemon404> lawl
[23:40] <Daemon404> no
[23:42] <pross-au> look at commmits/month: http://www.ohloh.net/p/libav
[23:44] <Daemon404> why the sudden fork trolling?
[23:44] <Daemon404> and hilighting me nonetheless
[23:44] <ubitux> hey it's not me this time!
[23:44] <Daemon404> considering i didnt mention libav once today :V
[23:44] <ubitux> we'll say it's wm4 fault for today then
[23:45] <wm4> well, not like I care
[23:45] <pross-au> i want my butthurt to be data driven
[23:45] <Daemon404> pross-au, maybe you should learn proper stats then
[23:45] <Daemon404> and how to analyze :P
[23:45] <wm4> the friction between the two forks is really annoying though
[23:45] <Daemon404> wm4, i get weekly PMs from both projects about beign a spy
[23:45] <Daemon404> it's great
[23:46] <Daemon404> or monthly now that i've slowed down patches latrely
[23:46] <Daemon404> lately*
[23:46] <ubitux> haha
[23:46] <Daemon404> im liek a quintuple agent
[23:46] <wm4> so much fun, huh
[23:46] <Daemon404> generally i'd like people to stfu about forks to me and just take me for what i am
[23:46] <Daemon404> :>
[23:47] <Daemon404> (an asshole)
[23:48] <Daemon404> michaelni, btw i've implemented my own custom avio context in a smaller project of mine
[23:48] <Daemon404> could be easier to point to than mplayer code
[23:50] <Daemon404> with actual comments and stuff
[23:58] <Compn> Daemon404 : people really pm you ? :)
[23:59] <ubitux> Daemon404: what's the real git tag for this?
[23:59] <Daemon404> Compn, yes
[23:59] <Daemon404> poke wm4 or torll mpv's git repo
[00:00] --- Sun Dec 16 2012