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

[burek]

[00:00] <bernie_> grrr... I'm a git patch newbie... I have 2 commits ahead of master, but I can only seem to grab each diff for each commit.  I can do git format-patch -1 --stdout > patch, or I can do git format-patch -2 --stdout > patch, but I want to have a combined patch... 
[00:01] <wm4> AFAIK format-patch doesn't combine commits to a single patch
[00:01] <wm4> you _could_ use git diff for that
[00:01] <wm4> you could also just squash the two commits into one
[00:01] <wm4> but I think if they are supposed to be separate commits - just send two patches
[00:02] <bernie_> okay, tell me how to squash (I don't know how)
[00:02] <bernie_> no, it's just fixing the bug I made earlier... no need to have 2 separate ones
[00:02] <bernie_> it's just going to you, so I could just send you the patch for my patch ;)
[00:03] <wm4> you could use "git reset origin/master" to go back to the upstream branch, and turn all commits into local changes
[00:03] <wm4> then you can make a commit with these changes
[00:03] <wm4> a patch on top of the previous patch would be ok
[00:04] <bernie_> bombs away
[00:05] <bernie_> I do have to say that I'm sorry to be chewing up your time with testing...
[00:05] <wm4> no problem
[00:05] <wm4> I (probably) want to implement this feature too
[00:05] <wm4> for my own demuxer
[00:05] <wm4> so some testing is good
[00:05] <wm4> we already found a mkvmerge bug
[00:06] <bernie_> hopefully I won't have to make a patch for a patch for a patch ;)
[00:06] <bernie_> yes, you did!  Thank you!
[00:13] <wm4> bernie_: I think it's correct now
[00:13] <bernie_> wm4: wooot!
[00:13] <wm4> I can't guarantee it's correct though, it's just my wacky code which is riddled with debug-printfs
[00:14] <wm4> and which seems to give the same result with ffmpeg-remuxed and mkvmerge-remuxed
[00:14] <bernie_> Now alls we got to do is figure out how to change the fate test!
[00:14] <bernie_> Well, I'm implementing code that relies on it right now
[00:20] <bernie_> it's fate!
[00:26] <llogan> durandal_1707: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/vf_separatefields.c;hb=HEAD#l36
[00:27] <durandal_1707> llogan: ????
[00:27] <llogan> shouldn't the ;; be ;?
[00:28] <durandal_1707> ahh, you stopped my p0rn watching because of ;; ?
[00:28] <llogan> carry on.
[00:29] Action: llogan is procrastinating
[00:42] <bernie_> wm4: if I also wanted to implement the other way of fast seeking (ie: force Cluster start on keyframes, and controlling keyframe placement to where I need them), I'd need to augment ffmpeg.  If I implemented this feature (it's quite trivial), would it be allowed into ffmpeg?  It's obviously a pretty specialized use-case, and while I could always have a locally patched binary available, it would be better if I knew it was in the pu
[00:43] <wm4> bernie_: your line was cut off at ..."it would be better if I knew it was in the pu"
[00:43] <wm4> well, it might be accepted if it's an option, I don't know
[00:43] <bernie_> that's terrible!
[00:43] <bernie_> :) (that my line was cutt off)
[00:43] <wm4> you should ask whoever maintains the ffmpeg matroska stuff (I don't know who)
[00:44] <bernie_> "it would be better if I knew it was in the public version" 
[00:44] <bernie_> Hmm. David Conrad (according to the matroskaenc.c file)
[00:47] <bernie_> aka yuvi
[00:49] <bernie_> got his email.  Nice.
[00:50] <cone-261> ffmpeg.git 03Michael Niedermayer 07master:74561680cd01: avfilter/vf_separatefields: fix ;;
[01:12] <bernie_> wonder if I should email David directly, or post to ffmpeg-devel mailing list
[01:21] <b_jonas> argh! I accidentally got a segmentation fault from ffmpeg when playing with parameters. Now I'll have to examine this with the lastest version and report it.
[01:21] <b_jonas> Not now though. I'll write it up to myself.
[01:21] <b_jonas> ffmpeg -filter_complex "testsrc=s=100x80,split[o1][o2]" -frames 200 -map "[o1]" -y a.mkv -map "[o2]" -y a2.mkv
[01:22] <b_jonas> In fact, this already segfaults: ffmpeg -map "[o1]" a.mkv
[01:31] <Compn> bernie_ : best to post to list with sample that causes problem hosted on other site, trac or file locker
[01:42] <llogan> Compn: testsrc is the sample
[01:43] Action: Compn wasnt paying attention
[01:43] <Compn> llogan : did you email mike ?
[01:44] <llogan> no. i wrote a message and then deleted it. i haven't seen him around in ages.
[01:44] <bernie_> Compn: this is an optimization question, not so much something that does not work, etc.
[01:46] <bernie_> I'll pose the question to the list and see what happens... ;)
[03:03] <wm4> bernie_: btw. I think you could submit your CueRelativePosition patch too
[03:17] <bernie_> wm4: yes -- that would be good.  But I still must learn about how to teach fate about the change in file
[03:18] <bernie_> wm4: change in the produced mkv file.  I believe it is unhappy that the output changed.
[03:19] <bernie_> wm4: but have not probed too deeply on that just yet.  Need to figure it out. 
[03:29] <cone-261> ffmpeg.git 03Marton Balint 07master:782e06e292c5: ffplay: simplify audio decoding
[03:29] <cone-261> ffmpeg.git 03Marton Balint 07master:b383498ea8b8: ffplay: estimate audio frame pts from the previous frame pts values
[03:29] <cone-261> ffmpeg.git 03Marton Balint 07master:73b2043d7270: ffplay: use start_time as next audio pts on flush when seeking is not supported
[10:48] <cone-577> ffmpeg.git 03Ed Torbett 07master:336353deaad6: rtpproto: Support IGMPv3 source specific multicast inclusion
[10:48] <cone-577> ffmpeg.git 03Martin Storsjö 07master:4d97ca040b40: rtpproto: Check the source IP if one single source has been specified
[10:48] <cone-577> ffmpeg.git 03Ed Torbett 07master:36fb0d02a1fa: rtsp: Support multicast source filters (RFC 4570)
[10:48] <cone-577> ffmpeg.git 03Michael Niedermayer 07master:48353325372a: Merge commit '36fb0d02a1faa11eaee51de01fb4061ad6092af9'
[12:12] <cone-166> ffmpeg.git 03Nicolas George 07master:c25d1ba55636: lavu/log: print prefix after \r.
[15:11] <JEEB> btw, nevcairiel -- finally got some data off of the Panasonic crapdisc out, and it seems those bastards used some custom encryption scheme in there
[15:11] <JEEB> so no simply available "12bit" data
[15:11] <JEEB> lul
[15:11] <Daemon404> wut
[15:12] <Daemon404> how do you even play it back then
[15:12] <Daemon404> on a regular bd player
[15:12] <Daemon404> or is it BD+ javashit
[15:12] <JEEB> the base layer is backwards compatible
[15:12] <saste> what's the difference between -x264opts and x264-params?
[15:12] <JEEB> only the second layer seems to be bullshit
[15:12] <Daemon404> i see... so... how to do you play it at all
[15:12] <Daemon404> saste, one is ffmpeg, one is libav iirc
[15:12] <Daemon404> is all
[15:12] <Daemon404> ive always used x264opts
[15:12] <saste> Daemon404, semantically... are they the same?
[15:12] <saste> so I can avoid some doc duplication
[15:12] <Daemon404> no idea. ive never used x264-params
[15:14] <saste> so no they are slightly different
[15:14] <saste> stupidity is awesome
[15:30] <Daemon404> saste, how so?
[15:30] <Daemon404> i know x264opts just takes param=val:param2=val2
[15:30] <Daemon404> with x264's names
[15:30] <Daemon404> anything else seems silly
[15:31] <saste> Daemon404, actually, x264-params mat be even saner
[15:31] <Daemon404> o?
[15:31] <saste> x264-params performs escaping
[15:31] <saste> x264opts doesn't, but it interprets opt: as opt=1
[15:32] <saste> in case the value is omitted
[15:32] <saste> i'll send a patch to document the differences
[15:32] <Daemon404> ah
[15:32] <Daemon404> what x264 ops even need to be escaped?
[15:33] <saste> Daemon404, in case you have a ":" in the value, for example
[16:05] <Daemon404> i guess for e.g. deblock=-1:-2
[16:18] <wm4> awesome magic numbers
[16:22] <Daemon404> its an example, why do i need to justify a random choice of numbers
[16:23] <wm4> if the actual options are not full of magic numbers, that is good
[16:30] <JEEB> wm4, or even better
[16:30] <JEEB> a magical string of a GUID
[16:30] <wm4> fortunately this is not windows programming
[16:31] <nevcairiel> GUIDs are usually inside some header so you just use a define name for them. :p
[16:41] <JEEB> nevcairiel, yet there are some within code without a name :D
[16:41] <JEEB> I'm lovin' it
[16:41] <wm4> "let's use random numbers to name things! no clashes anymore!"
[16:42] <wm4> genius
[16:42] <wm4> but extremely clunky
[16:42] <nevcairiel> well you complain about everything, so i stopped listening anyhow
[16:43] <wm4> I can't help that most computer technology is pure crap
[16:43] <nevcairiel> complaining wont change that
[16:43] <nevcairiel> changing that will change that
[16:48] <Kovensky> <+nevcairiel> GUIDs are usually inside some header so you just use a define name for them. :p <-- *usually*
[16:48] <Kovensky> and it's harder to map it the other wayaround :P
[16:48] <Kovensky> +\ 
[16:49] <nevcairiel> well sure, but we can't complain about everything or we'll just get bitter and grow neckbeards, so instead focus on the important things :p
[16:49] <Kovensky> dem neckbeards
[16:49] <wm4> well, if I complained about _everything_, I'd spam this IRC channel 24/7
[16:50] <saste> the important question if why IT technology tends to be crap
[16:50] <nevcairiel> because developers dont get enough time to do it properly
[16:50] <Kovensky> "I'll just make this quick hack, I'll fix it later, I swear"
[16:50] <wm4> often they don't care enough and just want get stuff done
[16:50] <Kovensky> there's also the problem that most programmers in the world are just in for the paycheck and don't actually care about the quality of their output
[16:50] <saste> nevcairiel, how is that different from architecture or mechanical engineering?
[16:51] <nevcairiel> who says thats much better?
[16:51] <wm4> collapsing bridges D:
[16:51] <nevcairiel> many devices and buildings tend to be assembled rather flimsy :p
[16:51] <Kovensky> flimsly?
[16:52] <nevcairiel> no idea if that word can even be an adverb
[16:53] <saste>  Kovensky about the paycheck thing, well free software is mostly done by volunteers, and still it is mostly crap (ffmpeg is no difference)
[16:54] <nevcairiel> usually too many people and their own ideas of "good" colliding giving you a common denominator that is below good
[16:55] <nevcairiel> or like wm4 said, people that are after results instead of style
[16:55] <saste> well but at the end saying that "everything is crap" is not useful, since everyone has a different definition of quality and of focus
[16:55] <wm4> also, many don't even know the value of simplicity
[16:55] <Kovensky> <@saste>  Kovensky about the paycheck thing, well free software is mostly done by volunteers, and still it is mostly crap (ffmpeg is no difference) <-- that falls under the <Kovensky> "I'll just make this quick hack, I'll fix it later, I swear"
[16:56] <nevcairiel> plenty code monkeys, not enough actual program designers
[16:58] <Daemon404> [10:55] <+wm4> also, many don't even know the value of simplicity <-- git commit -a -m "fix a bug"
[16:58] <Daemon404> cant get a simpler message
[16:58] <Daemon404> ;)
[16:59] <Kovensky> Daemon404: git commit -a -m '.*'
[16:59] <Kovensky> Daemon404: the reader can fill in his own commit message; it'll match the regexp ;)
[17:00] <Daemon404> ffmpeg has a one character commit message somewhere
[17:00] <Kovensky> (I guess that's less simple in some ways, but simpler in others)
[17:00] <wm4> wat
[17:00] <wm4> must be from ffmpeg's dark cvs and svn past
[17:01] <Daemon404> svn
[17:01] <Daemon404> the commit message was a single semicolon
[17:06] <saste> everyone has a different focus on "quality"
[17:06] <saste> some people are obsessed by commit messages or code reindent
[17:07] <saste> other focus on performance, on security, on usability, consistency etc etc
[17:08] <saste> so the code will be always considered as "crap" in a way or another
[17:09] <BBB> I think that era used "10l" a lot as commit message
[17:14] <wm4> it has something to do with cola I heard?
[17:16] <Daemon404> yes
[17:16] <Daemon404> google yields intresting uses
[17:16] <Daemon404> "DonDiego, you are honored by 10l cola per day for deliberately
[17:16] <Daemon404> breaking MPlayer CVS.
[17:16] <wm4> ah, mplayer cvs
[17:16] <wm4> the ring of it
[17:19] <JEEB> :D
[17:19] <BBB> my preciousss
[17:37] <bernie_> Hmmm kvminfo reports # of frames on a simple block, but I fail to see how the spec for SimpleBlock contains a frame count info
[17:37] <bernie_> as in: | + SimpleBlock (key, track number 1, 1 frame(s), timecode 0.064s = 00:00:00.064) at 1423 size 19435
[17:38] <bernie_> oh never mind
[17:38] <nevcairiel> simpleblock is always one frame, isnt it
[17:38] <wm4> matroska blocks can be "laced", which means they contain multiple packets
[17:38] <bernie_> If Lace is set
[17:38] <bernie_> yep
[17:38] <bernie_> :)
[17:38] <wm4> but these are not organized as ebml elements
[17:39] <nevcairiel> i dont think simpleblock allows lacing
[17:39] <bernie_> it does allow it from the spec, I think
[17:39] <bernie_> in the flags section
[17:39] <bernie_> I was just not expecting to see reference to frame count... but all is well.
[17:40] <wm4> yeah seems allowed
[19:09] <saste> ffplay -i test.ogg -af "atrim=duration=2"  -autoexit
[19:09] <saste> doesn't exit and spam the log
[19:09] <saste> is this known?
[20:11] <saste> how do you convert stereo to mono?
[20:11] <Daemon404> -ac 1 ?
[20:12] <saste> I'm doing ffmpeg -i test.ogg -ac 1 test1.ogg
[20:12] <saste> but then test1.ogg just contains random noise...
[20:13] <Daemon404> ... does that use our WMD of a vorbis encoder?
[20:14] <Daemon404> something's funky if you cant even dump pcm
[20:20] <saste> uh cool... it's averaging the two channels, which are almost opposite
[22:21] <cone-196> ffmpeg.git 03Michael Niedermayer 07master:bbf6cb754cc8: avfilter/vf_scale: Add in/out yuv color matrix option
[22:21] <cone-196> ffmpeg.git 03Michael Niedermayer 07master:835eee88ec4c: avfilter/vf_scale: add in/out color range option
[00:00] --- Sun Jul 21 2013