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

[burek]

[00:00] <BBB> if its stack it should be LOCAL
[00:00] <BBB> and why does vp8 go there?
[00:01] <durandal_1707> well i need to double check (enabling symbols, etc...)
[00:05] <durandal_1707> i just looked at x86/h264_qpel and it use DECLARE_ALIGNED for stack
[00:11] <durandal_1707> actually crash is in ff_vp8_v_loop_filter16y_inner_sse2
[00:13] <durandal_1707> which doesn't make sense as that is covered by yasm
[00:20] <BBB> -eneedmoreinfo
[00:57] <cone-52> ffmpeg.git 03Paul B Mahol 07master:79b70e47a463: w64dec: fix skipping of unknown guids
[00:58] <saste> did someone compare deshake and libvidstab?
[00:59] <durandal_1707> deshake is awfull, libvidstab is little better
[01:00] <durandal_1707> (from other people experience - not me)
[01:01] <saste> durandal_1707, thanks
[01:02] <saste> durandal_1707, is phase supposed to fix the same problem as fieldorder (but in a different way)?
[01:02] <durandal_1707> i think you could search & read older irc logs...
[01:03] <saste> what about the old transcode stabilizer?
[01:03] <saste> i'm asking because i had a discussion with a guy about that
[01:03] <durandal_1707> not at all
[01:03] <durandal_1707> what guy?
[01:03] <saste> i was convinced that deshake used the same algorithm
[01:04] <saste> (as the transcode stabilizer)
[01:05] <saste> the guy - a vlc dev
[01:05] <durandal_1707> fieldorder filter changes top to bottom or vice versa (for same frame)
[01:06] <saste> durandal_1707, yes
[01:06] <durandal_1707> what algorithm?
[01:08] <saste> durandal_1707, same algorithm == equivalent implementation/port
[01:09] <durandal_1707> but what/where in codebase (i'm not on simple english class)
[01:09] <durandal_1707> you mean deshake use same code as phase?
[01:11] <saste> durandal_1707, what a confusion, no
[01:11] <saste> i was asking if there is any relation between the transcode project stabilizer and deshake
[01:12] <saste> fieldorder/phase is a separate topic
[01:13] <durandal_1707> saste: i didn't looked closely at deshake/stabilizer/whatever
[01:13] <GoaLitiuM> btw, any plans on supporting intel quick sync encoding?
[01:15] <durandal_1707> i don't think it is on TODO list
[01:15] <durandal_1707> but we do not have TODO list at all
[01:19] <Compn> GoaLitiuM : someone was talking about that on the list
[01:19] <GoaLitiuM> recently?
[01:19] <Compn> no
[01:19] <Compn> probably when it was announced
[01:19] <Compn> at least that , or my memory is making up timestamps again
[01:21] <durandal_1707> if it is on bug tracker, at least someone could see it have been at least requested
[01:22] <durandal_1707> ah here it is: http://trac.ffmpeg.org/ticket/2591
[01:24] <durandal_1707> and there are some patches floating on fork side
[03:06] <cone-52> ffmpeg.git 03Paul B Mahol 07master:3e36dc8626f4: w64dec: fix end position of summarylist guid
[03:29] <cone-52> ffmpeg.git 03Michael Niedermayer 07master:cc84f3040261: avutil/fifo: assert that theres enough data in the fifo on drain calls.
[05:16] <cone-52> ffmpeg.git 03Michael Niedermayer 07master:92b7e7b31817: avfilter/vf_yadif: reallocate frames if strides differ
[11:08] <ubitux> ffmpeg -f lavfi -i testsrc -t 5 -pix_fmt yuva420p -c:v libopenjpeg -y test.avi
[11:08] <ubitux> funny output ^
[11:26] <ubitux> anyone has interesting samples with alpha layer?
[11:27] <Compn> i only know of that one lara shadow one 
[11:28] <Compn> vp6a
[11:44] <ubitux> Compn: can you share? i'm interested
[11:53] <ubitux> btw, don't we have a public function for:
[11:53] <ubitux> int has_alpha = desc ? desc->nb_components % 2 == 0 : 0;
[11:53] <ubitux> ?
[13:49] <Compn> ubitux : larashadow_dl.flv
[13:49] <Compn> ubitux  http://samples.ffmpeg.org/FLV/flash_with_alpha/
[13:50] <ubitux> Compn: thanks
[13:50] <Compn> i think someone made a command line to get it to display, using ffmpeg filter
[13:50] <Compn> but i forgot the command line
[13:50] <Compn> it should be in irc log
[13:50] <Compn> http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2013-June/001425.html
[13:51] <Compn> you were there even :)
[13:51] <ubitux> it's fine
[13:51] <ubitux> im using mpv -vo opengl:alpha 
[13:51] <Compn> what kind of samples did you want ?
[13:51] <ubitux> (+xcompmgr)
[13:51] <ubitux> that kind of sample :)
[13:51] <ubitux> that one is fine thx
[13:51] <Compn> oh ok
[13:52] <Compn> ah
[13:52] <cone-105> ffmpeg.git 03Anton Khirnov 07master:8aba7968dd60: vcr1: add sanity checks
[13:52] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:8ba683e629bd: Merge commit '8aba7968dd604aae91ee42cbce0be3dad7dceb30'
[13:52] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:164b67ca281f: avcodec/vcr1: replace redundant checks from libav (8aba7968dd604aae91ee42cbce0be3dad7dceb30)  by asserts
[13:52] <Compn> hows mpv going ? some people asked me about mplayer forks :)
[13:52] <ubitux> it's going pretty well so far afaict
[13:54] <durandal_1707> unlike mplayer it supports lavfi
[13:55] <ubitux> and it's usable to watch animes too
[13:56] <Compn> oooo, lavfi support
[13:56] <Compn> well it was suggested to add it to mplayer, but the api was changing 
[14:13] <cone-105> ffmpeg.git 03Anton Khirnov 07master:5f7aecde02a9: pictordec: break out of both decoding loops when y drops below 0
[14:13] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:efb21b0a8fbc: Merge commit '5f7aecde02a95451e514c809f2794c1deba80695'
[14:16] <cone-105> ffmpeg.git 03Anton Khirnov 07master:fe9bb61f9a16: pictordec: pass correct context to avpriv_request_sample
[14:16] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:1eb151c501ec: Merge commit 'fe9bb61f9a16be19ad91875632c39e44b7a99a8a'
[14:18] <cone-105> ffmpeg.git 03Compn 07master:8d14596bc241: riff: add 0x64 to g726 works on g726-test1.wav
[14:29] <cone-105> ffmpeg.git 03Anton Khirnov 07master:fab694dd3931: lavf: move a variable declaration to the block where it's used
[14:29] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:b0ba2bf8c66f: Merge commit 'fab694dd3931b1c0bc3c598c3f88b1902c14a303'
[14:38] <durandal_1707> what does MP_IMGFIELD_ORDERED means?
[14:47] <Daemon404> google says if MP_IMGFIELD_ORDERED is set, then teh field order is known
[14:47] <Daemon404> and you can check for TFF or BFF
[14:47] <Daemon404> i dont know why you would do it this way
[14:47] <Daemon404> but it's shitty mplayer code... unsurprising
[14:48] <nevcairiel> i would like such a flag in ffmpeg, tbh. You never know if it just defaults to bff or if the bitstream actually said so
[14:48] <Daemon404> how would that make a difference?
[14:48] <Daemon404> if you dont know, you have to guess anywa
[14:48] <Daemon404> y
[14:49] <nevcairiel> sure, but ffmpeg doesnt guess, it just defaults to tff=0
[14:49] <Daemon404> well ideally you would have two flags: one for bff, one for tff
[14:49] <Daemon404> if neither is set, then you dont know
[14:49] <Daemon404> a third flag is redundant
[14:49] <durandal_1707> and what if both are set?
[14:50] <nevcairiel> implementation is irrelevant, i just would like to identify the "unknown" case
[14:50] <Daemon404> indeed
[14:50] <Daemon404> durandal_1707, http://mplayerhq.hu/pipermail/mplayer-dev-eng/2004-March/024931.html
[14:50] <Daemon404> this should contain all the info you need
[14:50] <cone-105> ffmpeg.git 03Anton Khirnov 07master:df33a58e5311: lavf: avoid integer overflow when estimating bitrate
[14:50] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:d07d54fd5603: Merge commit 'df33a58e5311ee9a64a573889b883a80e981af7b'
[14:50] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:a5d67bc796e1: avformat/utils: Fix bitrate overflow check
[14:51] <Daemon404> yay, the fix wasnt in the merge commit!
[14:51] <Daemon404> and it has an explaation
[14:51] Action: Daemon404 cheers
[14:52] <nevcairiel> the original check did indeed look a bit funky
[14:58] <cone-105> ffmpeg.git 03Anton Khirnov 07master:a7c1689dedd1: 4xm: check that bits per sample is strictly positive
[14:58] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:bdb4ed963f7e: Merge commit 'a7c1689dedd11689edb30088d467ac03f9b8d1cf'
[15:05] <cone-105> ffmpeg.git 03Anton Khirnov 07master:488b2984fece: ape demuxer: check for EOF in potentially long loops
[15:05] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:50fd98b7ac4c: Merge commit '488b2984fece7ad0c2596826fee18e74aa904667'
[15:07] <durandal_1707> michaelni: please, please, please stop adding your changes into merges
[15:08] <nevcairiel> didnt we just discuss how he didn't?
[15:09] <durandal_1707> look at last one
[15:10] <nevcairiel> i see no extra changes
[15:12] <Daemon404> i do
[15:12] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=50fd98b7ac4c410f4413d382eecb415011b37920
[15:12] <nevcairiel> click on the diff below the 1 for the actual changes in that merge
[15:13] <Daemon404> yes but the ones shown tehre are the extra ones
[15:13] <Daemon404> that are in the merge itself
[15:13] <nevcairiel> nope
[15:13] <Daemon404> they do not match the merge
[15:13] <durandal_1707> stupid git
[15:13] <Daemon404> nevcairiel, then what ARE they
[15:13] <cone-105> ffmpeg.git 03Diego Biurrun 07master:7df9e693a34c: cosmetics: Fix ATRAC codec name spelling
[15:13] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:4cfe3b740543: Merge commit '7df9e693a34c84c698da60426c78140c950f95ed'
[15:13] <nevcairiel> no idea how it decides what to show there
[15:13] <Daemon404> its changes made in the merge >.>
[15:14] <Daemon404> i dont know how you can see it any other way
[15:15] <Daemon404> hmmm or it might be existing things?
[15:15] <Daemon404> this is why i hate git's way of merging
[15:15] <Daemon404> its impossible to follow
[15:16] <nevcairiel> quite simply because the warning about the missing seektable was in there before the merge
[15:16] <Daemon404> yes i just realized that
[15:16] <Daemon404> but my point stands about git merges being a crapshoot
[15:16] <nevcairiel> click the diff below the 1
[15:16] <nevcairiel> it shows the actual diff against ffmpegs parent
[15:17] <nevcairiel> while 2 shows the diff against libavs parent
[15:17] <Daemon404> diff1 is the diff against libav
[15:17] <Daemon404> iirc
[15:17] <Daemon404> diff2 is ffmpeg's diff against libav
[15:17] <Daemon404> diff1 is not against ffmpeg.
[15:17] <nevcairiel> diff 1 is the diff of the current version against the ffmpeg parent, diff 2 is the diff of the current version against libavs parent
[15:17] <nevcairiel> the second contains all ffmpeg changes, of course
[15:18] <nevcairiel> so its a "diff against libav" if you want
[15:19] <nevcairiel> find a commit with clear signs of in-merge changes and confirm diff 1 behaviour, if you insist :)
[15:19] <Daemon404> hmm yorue right
[15:19] <nevcairiel> now what the web thing shows in the merge overview page completely escapes me
[15:19] <Daemon404> "clear signs of in-merge" is an oxymoron btw
[15:19] <nevcairiel> you know what i mean :P
[15:20] <Daemon404> nevcairiel, my main issue is that merges make finding things in git history very hard
[15:20] <Daemon404> especially bisects
[15:20] <nevcairiel> yeah bisecting sucks
[15:20] <Daemon404> its weird that it was designed i na way which breaks git's other features
[15:20] <nevcairiel> browsing a single files history is ok'ish
[15:20] <Daemon404> but it was probably only meant for the subset that the kernel uses it for
[15:21] <nevcairiel> yeah two completely different branches co-existing is a odd use case
[15:21] <Daemon404> not really
[15:21] <Daemon404> when you consider teh pre-git definition of fork
[15:21] <Daemon404> git changed that word to have different connotations
[15:22] <Daemon404> as a side note: sometimes i have to fall back to good old patch/diff, because git hasb een too throroughly derped up
[15:22] <Daemon404> manual patches ftw
[15:23] <nevcairiel> never had that happen
[15:23] <nevcairiel> usually gits 3 way merge managed to fix it, unless it was really not automatically fixable (code modified on both ends)
[15:23] <pippin> I prefer rebase based workflows, leading to a linear commit history
[15:24] <Daemon404> everybody does
[15:24] <Daemon404> thats not suitable for this use case though
[15:24] <cone-105> ffmpeg.git 03Martin Storsjö 07master:0fbda03e5cfc: movenc: Don't flush after each written packet
[15:24] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:40bb950385a4: Merge remote-tracking branch 'qatar/master'
[15:33] <ubitux> can avcodec_decode_video2() return EAGAIN?
[15:37] <durandal_1707> aac_latm does
[15:38] <av500> aac does video now?
[15:38] <durandal_1707> no... but it returns
[15:38] <durandal_1707> that is only EAGAIN in lavc
[15:39] <durandal_1707> and i see no reason for it...
[15:41] <ubitux> mmh interesting
[15:41] <ubitux> well if that's for audio i don't care in my case but that's good to know
[15:42] <durandal_1707> when would you use it?
[15:44] <ubitux> i'm just wondering if i can error out in case of ret < 0
[15:44] <ubitux> or if i need to add a EAGAIN check
[15:44] <ubitux> (in addition)
[15:45] <nevcairiel> i just error out on < 0
[15:45] <nevcairiel> never found something where this doesnt work
[15:45] <ubitux> yeah actually i just realize there is the got_frame thing
[15:45] <ubitux> so eagain should not happen
[15:47] <Daemon404> yes
[15:49] <ubitux> what about the read frame?
[15:49] <nevcairiel> there i handle it
[15:49] <nevcairiel> not sure if it really happens
[15:49] <ubitux> i remember a lot of weird cases
[15:49] <nevcairiel> i think it can, depending on the underlying protocol
[15:49] <ubitux> like packets of size 0
[15:49] <ubitux> and stuff like that
[15:50] <Daemon404> multi-packet frames are common
[15:50] <Daemon404> so are multi-frame packets
[15:50] <Daemon404> ive written the The Decode Loop too many times...
[15:50] <Daemon404> low level api os low level
[15:50] <Daemon404> is*
[15:50] <nevcairiel> i kinda like it, gives me a lot of control :p
[15:50] <durandal_1707> huh?
[16:00] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:a4e70918316c: avcodec/vcr1: return the actual number of consumed bytes
[16:00] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:84b6451d29ec: avcodec/vcr1: simplify code, drop buf_size
[16:00] <cone-105> ffmpeg.git 03Michael Niedermayer 07master:f4e9c768d102: avcodec/vcr1: simplify code drop buf variable
[16:08] <Compn> michaelni : there were some talks about moving vcr1 and other codecs out of the main mpeg code
[16:08] <Compn> possibly theres some colorspace code still stuck in there as well
[16:08] <Compn> maybe you know about this already
[16:09] <durandal_1707> vcr1 have nothing to do with mpeg
[16:10] <cone-105> ffmpeg.git 03Paul B Mahol 07master:3dd4b6ea417a: lavfi: port phase filter from libmpcodecs
[16:10] <cone-105> ffmpeg.git 03Paul B Mahol 07master:916549cb1e73: lavfi/mp: remove mp=phase
[16:11] <Compn> oop, i mean vcr2 :)
[16:15] <Compn> only a hundred lines? blah
[18:03] <soul-d> probably  not entirely ffmpeg question  but still since they are  "lowlevel"  my questions  http://pastebin.com/YEv5gwg3 + current wip chart http://i.imgur.com/2IioCPk.png 
[18:03] <soul-d> did only get as fas  finding the yuyv marker if vieuwed as  hex 
[18:04] <soul-d> simply said i need info on fileformats to be able to actualy write  that files decoder 
[19:03] <cone-105> ffmpeg.git 03Paul B Mahol 07master:605381281405: x86/simple_idct: use LOCAL_ALIGNED instead of DECLARE_ALIGNED
[19:10] <durandal_1707> how "Relicensed to LGPL with permission by all contributors." sounds like?
[19:22] <cone-105> ffmpeg.git 03Paul B Mahol 07master:771e2e59e2af: lavfi/hue: relicense to LGPL with permission by all contributors
[19:26] <durandal_1707> michaelni: can you kindly give permission to relicense mptestsrc to lgpl?
[19:28] <llogan> how was VDD?
[19:30] <llogan> durandal_1707: why do you want to relicense?
[19:31] <durandal_1707> to amuse rms
[19:32] <ubitux> :D
[19:32] <llogan> i don't know what rms means
[19:32] <ubitux> richard stallman
[19:32] <llogan> oh
[19:34] Action: michaelni politely refuses to annoy anyone
[19:34] <durandal_1707> :)
[19:35] <llogan> i'm surprised nobody asked why before giving permission
[19:35] <ubitux> lgpl is preferred
[19:35] <ubitux> overall codebase is lgpl
[19:35] <durandal_1707> we want to swith to AGPL
[19:36] <mateo`> :D
[19:38] <llogan> another "
[19:38] <llogan> Is this a family-friendly mailing list?"
[19:38] <llogan> in the queue from another chinese guy...
[19:38] <llogan> delete
[19:39] <Compn> hey llogan :)
[19:39] <Compn> vdd was fun
[19:40] <llogan> did you vandalize asterix statue with a ffmpeg sticker?
[19:40] <cone-105> ffmpeg.git 03Dirk Farin 07master:902a5fa7228d: avformat: H265 demuxer
[19:41] <llogan> oh, it's the same chinese guy.
[19:41] <michaelni> i hope you didnt forget giving asterix an umbrella in that case ;)
[19:42] <llogan> i was going to say since they are rain temporary then it won't cause permanent damage
[19:44] <nevcairiel> michaelni: since its rather likely that the fork will also get a H265 codec id, how do you plan on handling the change in numeric id?
[19:45] <ubitux> duplicate
[19:45] <michaelni> yes and remap_deprecated_codec_id()
[19:51] <Daemon404> what was the point of pushing that?
[19:53] <durandal_1707> of hevc raw demuxer?
[19:53] <Daemon404> yes
[19:54] <Daemon404> theres one coming from the actual person who wrote the hevc decoder
[19:54] <durandal_1707> to say: here, see! we have it!
[19:54] <Daemon404> yeah pretty much
[19:54] <Daemon404> seems dumb.
[19:54] <Compn> trolling openhevc to implement it
[19:54] <Compn> is my idea 
[19:55] <kierank> durandal_1707: i thought you were going to be at vdd
[19:56] <Daemon404> he doesnt have a passport
[19:57] <kierank> could have taken the train
[19:57] <kierank> and gone through schengen countries
[19:57] <durandal_1707> yes, i were, big, handsome, strong guy in top left corner
[19:57] <Daemon404> if you mean https://twitter.com/flameeyes/status/374149289510838272/photo/1
[19:57] <Daemon404> then thats JEEB~
[20:02] <durandal_1707> are that all libav devs?
[20:02] <JEEB> nope
[20:39] <Compn> oh no, im in that picture
[20:40] <Compn> durandal_1707 : i'll give you a hint. i have the big beard
[20:42] <j-b> the biggest
[20:43] <Compn> its going to be a challenge to catch up to rms beard
[20:44] <llogan> you should do this: http://laughingsquid.com/wp-content/uploads/beard-20110516-120844.jpg
[20:44] <Compn> yes, the beard championships
[20:45] <cone-105> ffmpeg.git 03wm4 07master:060c6c464753: avformat/mpl2dec: handle files with CRLF linebreaks correctly
[20:45] <cone-105> ffmpeg.git 03Clément BSsch 07master:493ebbd7eb08: Update copyrights where my email appears with the new one.
[20:46] <Daemon404> Compn, you are no rms
[20:46] <Daemon404> at least, i didnt see you eat anything from your foot
[20:46] <JEEB> lol
[21:22] <cone-105> ffmpeg.git 03Clément BSsch 07master:30d40c9e866b: lavfi/drawtext: add generic timeline interface and deprecate "draw".
[21:27] <ubitux> ah shit, i unsubscribed my gmail address from ffmpeg-devel, so one mail from here awaits for moderation 
[21:27] <ubitux> sorry about that
[21:31] <Compn> heh
[21:31] <Compn> no worries
[21:33] <Compn> ubitux: did you resubscribe ?
[21:33] Action: Compn approves ubitux mail
[21:34] <ubitux> i re-subscribed on my new address
[21:35] <ubitux> thx Compn 
[21:57] Action: Compn lols about swear words post
[21:58] <Compn> llogan : why not discard that one ?
[22:05] <ubitux> so swscale has ppc, sparc and bfin asm, but no arm
[22:05] <ubitux> erm.
[22:20] <beastd> ubitux: no no, it is still spelled arm this days not erm  ;)
[22:21] <ubitux> that's what i missed ;)
[22:24] <cone-105> ffmpeg.git 03Paul B Mahol 07master:d21e496cf5ae: lavfi/mptestsrc: use outlink->frame_count
[22:38] <llogan> Compn: because he was subscribed so it went though automatically. i thought it was weird so i added a mod bit to his address.
[22:38] <llogan> then i told him it was off-topic and the ML is not considered to be family friendly because it has nothing to do with families
[22:41] <llogan> Compn: oh...i see he sent another.
[22:43] <durandal_1707> Compn: you modded guy who trolled about swear words?
[22:47] <llogan> no, i did because i didn't know if it was some sort of pre-spam probe or whatever
[22:56] <gnafu> Wait, so did they think that the censorship was automated and not self-induced?
[00:00] --- Wed Sep  4 2013