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

burek burek021 at gmail.com
Fri Jan 25 02:05:03 CET 2013


[00:44] <cone-16> ffmpeg.git 03Michael Niedermayer 07master:7357ca900efc: sanm: Check decoded_size.
[00:55] <llogan> anyone care or not if i get ffmpeg listed here? http://linuxaudio.org/members it would show that we support other (audio)/media related projects
[00:55] <cone-16> ffmpeg.git 03Michael Niedermayer 07master:9d6e0ac6737f: floatdsp: restrict->av_restrict
[00:55] <llogan> http://linuxaudio.org/policy
[00:57] <Compn> looks like another worthless thing , go for it :P
[00:57] <Compn> ehe
[00:58] <llogan> they has a lenghty (a lot of OT) thread on their user ML about ffmpeg vs libav.
[00:58] <Compn> lol
[00:58] <llogan> the OT involved monkeys.
[00:58] <llogan> which i support.
[01:02] <llogan> at most, if their foundation gets formed eventually, they could help sponsor trips to conferences, etc if we lack donation monies.
[01:05] <llogan> not that any of us actually attend much social stuff (hissss!) AFAIK
[01:19] <saste> https://ffmpeg.org/ffmpeg-filters.html#concat: There are nÃ(v+a)
[01:19] <saste> i am the only one seeing that?
[01:20] <Daemon404> no
[01:21] <saste> ok, so no UTF-8 support in texi2html, shame
[01:21] <saste> or we're doing it wrong
[01:21] <saste> and same in the manual
[01:26] <cone-16> ffmpeg.git 03Carl Eugen Hoyos 07master:f8b6d4818e1d: Only try to auto-detect LATM in mpegts if the LOAS demuxer was configured.
[01:26] <cone-16> ffmpeg.git 03Carl Eugen Hoyos 07master:df39c3ce385c: matroskaenc: add codec_tag lists back.
[01:34] <michaelni> saste, it displays correctly if you force utf8
[01:35] <saste> michaelni, man/html?
[01:35] <michaelni> html
[01:35] <michaelni> with firefox
[01:35] <saste> we need to set the encoding in the generated page then
[01:35] <saste> as for the man output i can't say...
[01:35] <michaelni> i think so
[01:47] <teratorn> anyone a gdb expert I could bother?? :) how can values in an expression be optimized out, and also at the same time cause a SIGSEGV? http://hastebin.com/maciwiyide.txt
[01:48] <teratorn> (that's from a core file, if it matters)
[01:49] <cone-16> ffmpeg.git 03Michael Niedermayer 07master:ee9151b616fa: ff_mss12_decode_init: check dimensions
[01:50] <michaelni> teratorn, i suggest that if possible you recompile without optimizations and get a better core file
[01:51] <teratorn> michaelni: thank you, that's a good suggestion. I'm suspect of the data I'm passing in to the codec.
[01:53] <saste> ^ i suspect this is a form of "silly" encryption
[01:56] <saste> michaelni: ping on doc/eval: fix/extend documentation for taylor() function
[01:57] <saste> no hurry since i'll work on it tomorrow evening, but i'd like to push the whole patchset
[02:49] <cone-16> ffmpeg.git 03Carl Eugen Hoyos 07release/0.10:4e869e7a5f14: matroskaenc: add codec_tag lists back.
[02:49] <cone-16> ffmpeg.git 03Carl Eugen Hoyos 07release/0.11:ebb3a5974fe3: matroskaenc: add codec_tag lists back.
[02:49] <cone-16> ffmpeg.git 03Carl Eugen Hoyos 07release/0.9:9103d77ffc0e: matroskaenc: add codec_tag lists back.
[02:49] <cone-16> ffmpeg.git 03Carl Eugen Hoyos 07release/1.0:d80702228320: matroskaenc: add codec_tag lists back.
[02:49] <cone-16> ffmpeg.git 03Carl Eugen Hoyos 07release/1.1:33769e908dac: matroskaenc: add codec_tag lists back.
[03:45] <burek> if anyone is skilled in ProRes, please tell me what to answer to this guy: http://ffmpeg.gusari.org/viewtopic.php?f=16&t=802
[03:48] <Compn> he just wants that other color profile
[03:48] <Compn> not a matrix
[03:49] <Compn> burek : http://ffmpeg.org/pipermail/ffmpeg-user/2013-January/012378.html
[03:49] <Compn> ;)
[03:50] <llogan> I do so hate mediainfo...
[03:50] <burek> :)
[03:50] <burek> yes, i see
[03:50] <burek> so does he need some color conversion or something
[03:51] <llogan> burek: talking about beer, someone is bringing over a 5 gallon keg in an hour...
[03:51] <burek> horror...
[03:51] <Compn> burek : no, his problem is that hes believing mediainfo is correct :)
[03:51] <Compn> when in fact, its not at all :)
[03:51] <burek> oh I see
[03:51] <burek> so, his problem is not a problem at all? :D
[03:51] <burek> I like those kinds of posts :D
[03:52] <Compn> note that he never specifies what his true problem is
[03:52] <Compn> his problem is that mediainfo reports something ? does it cause any actual problems or is he just crazy ?
[03:52] <burek> :)))
[03:52] <Compn> ask him, because honestly i cant tell from his post
[03:53] <burek> so, his mediainfo shows 601 because ffmpeg didn't write that info in the atom
[03:53] <burek> if i understand correctly
[03:53] <burek> I mean, i dont want to ask him if he is crazy
[03:54] <burek> he did help other guy in the forum while waiting for his answer :)
[03:54] <burek> the least i could be is to be polite :)
[03:54] <Compn> yes, i think your answer correct
[03:54] <Compn> but ask him if that ffmpeg non-atom is causing real problems
[03:54] <burek> ok, I will, thanks a lot for the explanation
[04:12] <Compn> well , probably i am wrong
[04:13] <Compn> most of these people that talk about bt709 and such are ... like the audiophile people
[04:13] <Compn> they have no clue what they need, but they saw it on a box once so now thats the most important feature for thier cat videos
[04:14] <Compn> and obviously, they want the bt709 instead of the bt 601 because ... 709 is a higher number.
[04:46] <cone-16> ffmpeg.git 03Michael Niedermayer 07master:69fb605ad5e0: mpc8: check stream count before accessing stream 1.
[04:46] <cone-16> ffmpeg.git 03Michael Niedermayer 07master:b53ed19aa74c: lcldec: Check length before unsigned subtraction.
[04:46] <cone-16> ffmpeg.git 03Michael Niedermayer 07master:46cb61819d86: gifdec: check that the last keyframe exists and has been successfully parsed.
[04:46] <cone-16> ffmpeg.git 03Michael Niedermayer 07master:7e059c9c5d78: mpeg4videoenc: check w,h to be within the supported range.
[09:01] <burek> Compn lol :D
[09:32] <EricAhn> I'm going to test from HLS to RTp stream.
[09:33] <EricAhn> But, I got an error, "AAC with no global headers is currently not supported.", more details at http://pastebin.com/EajeP5bQ 
[09:33] <EricAhn> did not supported ffmpeg/ffserver HLS(H.264/aac) => H.264/aac  ?
[09:34] <EricAhn> I found old irc log, ( http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2010-May/000107.html )
[09:36] <EricAhn> also, http://web.archiveorange.com/archive/v/yR2T4ccIkwqdDXgCRZm0 read, but I'm not sure how much related about this
[10:23] <cone-871> ffmpeg.git 03Carl Eugen Hoyos 07master:fc50175ba21f: Refuse to mux tta into matroska, the output file is broken.
[11:40] <cone-871> ffmpeg.git 03Paul B Mahol 07master:e65046bf836b: lavfi/earwax: remove config_input()
[11:58] <cone-871> ffmpeg.git 03Paul B Mahol 07master:056664ff25c6: lavc/tta: remove nonsense s->avctx indirection, use avctx directly
[12:11] <durandal_1707> michaelni: why matroska muxer writes not matroska tags?
[12:14] <durandal_1707> instead it writed riff/wav ones I do not think this is valid
[12:28] <cone-871> ffmpeg.git 03Stefano Sabatini 07master:2ed0803c6c99: lavu/eval: extend if/ifnot functions to accept a third parameter
[12:28] <cone-871> ffmpeg.git 03Stefano Sabatini 07master:2b207bab196d: doc/eval: substitute if/then/else construct with an example making use of boolean expression composition
[12:28] <cone-871> ffmpeg.git 03Stefano Sabatini 07master:ca1bc188f4e7: doc/eval: fix documentation for time() function
[12:28] <cone-871> ffmpeg.git 03Stefano Sabatini 07master:c89a8ee23d7c: doc/eval: fix/review the section about SI prefixes and usage
[13:01] <wm4> why is the max_analyze_duration message printed as warning?
[13:01] <wm4> how is that a warning?
[13:02] <cone-871> ffmpeg.git 03Paul B Mahol 07master:9ddf5631e319: matroskaenc: support TTA muxing
[13:02] <cone-871> ffmpeg.git 03Paul B Mahol 07master:ee8d4a414288: matroskaenc: fix -codec copy with TTA
[13:03] <wm4> durandal_1707: have you found out how the length of the last sample for tta in mkv is calculated?
[13:03] <durandal_1707> wm4: nope, ask matroska creators
[13:17] <wm4> avio_open2() sure is a wtf
[13:18] <wm4> so I can't use av_opt directly in the context
[13:18] <wm4> but I have to create an AVDictionary first?
[13:18] <cone-871> ffmpeg.git 03Paul B Mahol 07master:dd5689a3bdaa: matroskadec: export codec bits_per_coded_sample
[13:20] <wm4> and it mutates the AVDictionary you pass... wat
[13:22] <saste> wm4, about the AVDict change, anton insisted with that design because it considered that "simpler" for the user
[13:23] <wm4> sigh
[13:23] <saste> but again we are not the authors of that API, ask/complain to libav
[13:24] <wm4> anton = elenril, right?
[13:24] <durandal_1707> whois is your friend
[13:39] <saste> wm4, and i think you *can* use av_opt in the AVIO context, once it was created
[13:40] <wm4> but then it already has connected
[13:43] <saste> wm4, what's the problem with specifying options in the dictionary?
[13:43] <wm4> it's suddenly a different API, and different memory management
[13:44] <wm4> also it always forces you to use strings
[13:44] <saste> wm4, i see
[13:45] <saste> i can't remember (or never knew) why a more avcodec_open()-like API was choosen
[13:45] <saste> *was not choosen
[13:45] <saste> i assume there were good reasons for that
[13:45] <wm4> <wbs> but you can't easily pass parameters before the file/stream is opened
[13:45] <wm4> <wbs> otherwise you'd need to split it into a "parse url, allocate contexts but don't actually open it" step
[13:45] <wm4> <wbs> after which the caller could set options
[13:45] <wm4> <wbs> and then tell it to actually start the connection
[13:46] <wm4> so at least it's easier to implement
[13:48] <saste> yes
[14:18] <cone-871> ffmpeg.git 03Martin Storsjö 07master:e90820d4f815: rtp: Make sure priv_data is set before reading it
[14:18] <cone-871> ffmpeg.git 03Martin Storsjö 07master:57ed8debb9b9: wmv2: Propagate the wmv2 idct permutation type to the dsputils context
[14:18] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:40c27504a5fd: Merge commit '57ed8debb9b9cc565cc6e9f98c5b5cbb9f69097c'
[14:18] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:1d2abca7e1f0: wmv2enc: drop setting of idct_algo
[14:27] <cone-871> ffmpeg.git 03Martin Storsjö 07master:932117171f32: rtp: Make sure the output format pointer is set
[14:27] <cone-871> ffmpeg.git 03Martin Storsjö 07master:4a4a7e138c92: rtpenc_chain: Use the original AVFormatContext for getting payload type
[14:27] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:b4581e9394c9: Merge commit '4a4a7e138c92901e04db46a6b05cc6948023e5f5'
[14:34] <cone-871> ffmpeg.git 03Diego Biurrun 07master:528878ee7b37: openbsd: configure: Stop enabling PIC by default
[14:34] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:9c555bca68cf: Merge commit '528878ee7b377e23a194d7c801571d97793047e0'
[14:39] <cone-871> ffmpeg.git 03Luca Barbato 07master:7a95afe433b2: doc: fix dependencies in pod generation
[14:39] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:70b0aeba001c: Merge commit '7a95afe433b2a692f490b98948c082e62ffc1d27'
[14:45] <TimNich> use hit a make issue using my usual build set up with b4581e939
[14:58] <TimNich> OK so it was a one off hiccup! Sorry for the noise.
[15:20] <EricAhn> did ffserver support from HLS(means that using ffmpeg input) to rtp(H264/AAC)?
[15:54] <cone-871> ffmpeg.git 03Mans Rullgard 07master:e9d817351b28: dsputil: Separate h264 qpel
[15:54] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:fc13a89654b5: Merge remote-tracking branch 'qatar/master'
[15:56] <durandal_1707> when will this nonsense stop?
[15:57] <j-b> mever
[15:58] <durandal_1707> all the time something is renamed/moved around/etc ...
[15:58] <durandal_1707> i just want to see end of tunel
[15:58] <Compn> well
[15:58] <nevcairiel> when everything is neatly seperated in small reusable chunks
[15:58] <nevcairiel> instead of one big hunk of everything
[15:59] <Compn> i think dark_shikari mentioned that our h264 decoder was not as fast as other software h264 decoders
[15:59] <durandal_1707> what, every test on web show it is fastest
[15:59] <Compn> so maybe a huge cleanup, and shuffle out bits, then merge x264 optimizaitons back , then tweak the decoder ...
[16:00] <durandal_1707> hello it is 2013! too late
[16:00] <Compn> for single core decoding ?
[16:01] Action: Compn tries to find benchmarks
[16:01] <wm4> who cares about single core?
[16:01] <wm4> even phones have multicores these days
[16:02] <nevcairiel> more single core speed = less power used
[16:02] <nevcairiel> even translates to multicore
[16:05] <cone-871> ffmpeg.git 03Paul B Mahol 07master:7b007a7c1fad: flic: do not set sample_fmt
[16:05] <cone-871> ffmpeg.git 03Paul B Mahol 07master:eb567a79990b: eacdata: do not set sample_fmt
[16:05] <wm4> sure, but a fast single core decoder probably still won't compete against ffmpeg, even if ffmpeg single-core is slower
[16:05] <Compn> look i'm just coming up with one guess as to the h264 split
[16:06] <Compn> :P
[16:06] <Compn> it was always a hope that x264 would be merged
[16:06] <Compn> i know x264 guys dont want to hear that :P
[16:06] <wm4> why would you merge it
[16:06] <Compn> since its kind of hard to mix gpl and lgpl code in one file , making you use a ton of ifdefs ...
[16:07] <wm4> just to increase the amount of code the decoder depends on?
[16:07] <nevcairiel> x264 is an encoder
[16:07] <wm4> *encoder
[16:07] <nevcairiel> it wouldnt help the decoder much
[16:07] <wm4> if it works fine stand-alone, leave it be
[16:07] <wm4> better fight NIH inside of ffmpeg
[16:07] <Compn> nevcairiel : you got the latest coreavc v libavcodec benchmarks ?
[16:07] <durandal_1707> wm4: like what?
[16:07] <Compn> searching doom9 is giving me a headache
[16:07] <nevcairiel> i agree, putting such a big encoder project into ffmpeg just for the sake of doing it doesnt help :p
[16:08] <nevcairiel> Compn: no
[16:08] <wm4> durandal_1707: TS demuxer
[16:08] Action: durandal_1707 still confused
[16:10] <Compn> nevcairiel : true, there might be one or two things. maybe they already got ported
[16:11] <Compn> do a search for loren in git log ... 
[16:12] <durandal_1707> there are matroska samples with DTS/EXPRESS and/or DTS/LOSSLESS?
[16:12] <nevcairiel> i have never seen one with dts express in it, but lossless is common enough
[16:13] <durandal_1707> nevcairiel: have link to sample?
[16:13] <nevcairiel> no
[16:28] <michaelni> when everything is split up in small parts they will make a party and then start merging it all back together and 5-10years later the cycle repeats
[16:29] <michaelni> split up related parts so they become inconsistent, then merge back to make it consistent
[16:30] <michaelni> then again split up because its again too much 
[16:34] <Compn> lol
[16:35] <nevcairiel> if the only relation is that its for video decoding, its not a very strong relation =p
[16:35] <Compn> i'm surprised there isnt a /h264/ yet
[16:35] <Compn> it has more than a dozen files already :P
[16:36] <Compn> two dozen...
[16:36] Action: durandal_1707 still confused
[16:36] <nevcairiel> counting all the arch specific ones?
[16:37] <Compn> no, i'd rather not
[16:37] <Compn> lots of code in ffmpeg
[16:37] <Compn> to be sure
[16:38] <Compn> so when are we going to merge into the linux kernel ?
[16:38] <michaelni> nevcairiel, example 1 from "yesterday": change the array used for B frame MC functions to a different type than the one used for P frames
[16:38] <nevcairiel> i would ask why they have to be of the same type?
[16:39] <Compn> consistency
[16:39] <michaelni> consistency & ease of use
[16:39] <Compn> maybe optimization too...
[16:39] <durandal_1707> nobody measured performance implications?
[16:39] <michaelni> you wouldnt want to mistakely mix the types
[16:39] <Compn> and performance, plus compiler optimization, plus platform might have problems with different pieces of code ...
[16:40] <durandal_1707> they usually only measure micro optimizations ....
[16:40] <michaelni> nevcairiel, example 2 from "yesterday": the wmv2 idct (which is identical to the mpeg2 reference idct) was split out of the framework for mpeg idcts
[16:41] <Compn> and then if you are doing find + replace grep bugs ... it wont show up :)
[16:41] <nevcairiel> if its identical, why does it exist? there must be some differences =p
[16:41] <michaelni> nevcairiel, ?
[16:41] <Compn> michaelni : nevcairiel means duplicate code 
[16:41] <Compn> "why arent they merged if they are so similar"
[16:41] <nevcairiel> if you say its identical to the mpeg2 idct
[16:41] <nevcairiel> why isnt the mpeg2 idct used
[16:41] <michaelni> nevcairiel, theres only one integer "reference" idct
[16:42] <michaelni> and thats not part of the mpeg/jpeg  idct framework anymore now
[16:42] <nevcairiel> if its called wmv2 idct and only used for wmv2, its hardly something thats reused
[16:43] <michaelni> yes, split up for one reason, tomorrow merge for another like consistency
[16:44] <av500> you can always not merge it :)
[16:44] <michaelni> and it was usefull for debuging / testing non wmv2 files that is if they decode correctly/better with it or any other of the idcts
[16:44] <michaelni> av500, yes but that makes future merges harder
[16:45] <michaelni> iam lazy
[16:45] <michaelni> less work is better
[16:45] <nevcairiel> maybe i'm not around long enough, but i havent seen stuff moving from a to b and then back from b to a all that often
[16:45] <nevcairiel> and to me, splitting up big blobs into small pieces is always good in any software
[16:46] <michaelni> nevcairiel, spliting the idct in a seperate file: good
[16:46] <michaelni> using a seprate incompatible framework for it: bad
[16:46] <michaelni> thats IMHO
[16:49] <durandal_1707> are they comitting without running fate test before ?
[16:49] <nevcairiel> you mean like you did? :P
[16:51] <durandal_1707> nevcairiel: my commits where small and trivial...
[16:51] <nevcairiel> still broke fate :)
[16:52] <durandal_1707> yes, but small < big
[16:54] <durandal_1707> i think BBB is pushing some very old commits that where previoulsy rejected in days before split
[16:55] <EricAhn>  I'm going to test from HLS to RTp stream.  But, I got an error, "AAC with no global headers is currently not supported.", more details at http://pastebin.com/EajeP5bQ   did not supported ffmpeg/ffserver HLS(H.264/aac) => H.264/aac  ?
[17:15] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:c071b006436d: mpeg12demux: Fallback to startcode for stream type identification.
[17:25] <wm4> does avio have anything to reconnect a broken network connection?
[17:25] <wm4> or do you have to recreate the avio?
[17:47] <EricAhn> wm4 : ping
[17:47] <wm4> did you want wbs?
[17:47] <EricAhn> wbs means?
[17:48] <wm4> I thought you typoed my nick
[17:48] <wm4> or his
[17:49] <EricAhn> wm4 : I have a question about ffserver.
[17:49] <wm4> I'm not an expert in ffserver
[17:49] <EricAhn> If i explain something, May u look into?
[17:50] <EricAhn> related rtp protocol
[17:50] <wm4> as much as anyone on this channel might or might not
[17:57] <Compn> ironically, wbs is the guy to ask about rtp :P
[17:58] <Compn> EricAhn : did you ask on ffserver-user mailing list? thats the proper place for your question
[17:58] <Compn> this channel is more for development of the programs, not user questions :)
[17:58] <EricAhn> I found "http://ffmpeg.org/pipermail/ffmpeg-devel/2010-May/096088.html" in ffmpeg-devel 
[17:58] <durandal_1707> that is 3 years old
[17:58] <EricAhn> Compn : I have no idea.
[17:59] <EricAhn> Compn : I want to know if that feature didn't implement .
[18:00] <EricAhn> Compn : and going to implement that feature.
[18:00] <durandal_1707> wtf i did
[18:00] <EricAhn> duradal_1707  : ?
[18:01] <wm4> wut
[18:01] <wm4> you cleared the banlist
[18:01] <durandal_1707> omg
[18:01] <wm4> now all these trolls will flood this channel!
[18:02] <Compn> durandal_1707 : are you not good with computer ?
[18:02] <Compn> hehe
[18:03] <Compn> EricAhn : ah.
[18:03] <EricAhn> durandal_1707 : In my test ffserver.conf, I success only video channel. 
[18:03] <Compn> EricAhn : i'm not sure who maintains ffserver right now. maybe michael knows 
[18:03] <Compn> or maybe its in maintainers file
[18:05] <EricAhn> if it have a video/audio configuration,  H.264/AAC in ffserver.conf, failed play.
[18:05] <EricAhn> wbs : ping 
[18:09] <saste> Compn, bcoudurier is the nominal maintainer for ffserver, but in truth nobody is maintaining it for real
[18:11] <michaelni> if someone wants to work on ffserver that person should probably become maintainer of ffserver
[18:12] <durandal_1707> .nobody wants.
[18:13] <saste> durandal_1707, i wonder why
[18:13] <michaelni> its simple people prefer if the code they need working doesnt work
[18:14] <durandal_1707> ENODEVS
[18:15] <saste> that would explain why ffmpeg has so many bugs :)
[18:15] <saste> still there is some traffic going on on ffserver-user
[18:15] <saste> i was against the ffmpeg-user -> ffserver-user split
[18:15] <Compn> michaelni : should we send eric to ask libav then ? :P
[18:17] <saste> what about merging again ffserver-user -> ffmpeg-user?
[18:17] <saste> i find a bit silly to have a separate ML for each tool
[18:17] <michaelni> libav can maintain ffserver for me, yes, sadly they dont either
[18:17] <saste> and most issues are shared amongst tools
[18:18] <durandal_1707> saste: i agree, split between tools is little silly, where is ffplay and ffprobe?
[18:18] <saste> llogan, ^^
[18:20] <Compn> i think EricAhn is just asking of hyc's patch was ever committed
[18:20] <Compn> have to read gitlog for that
[18:21] <michaelni> if theres a good patch that wasnt commited ping it and we can review and or comit it
[18:21] <EricAhn> Compn : hm okay, will review it
[18:22] <michaelni> EricAhn, are you a developer ? do you want to maintain ffserver ? (there are MANY users who would love you then)
[18:22] <EricAhn> michaelni : Yeah, I'm developer, 
[18:23] <michaelni> good and you want to try to maintain or work on ffserver ?
[18:23] <EricAhn> michaelni : ^^ ffserver hm, It's awesome
[18:24] <michaelni> great \o/
[18:24] <michaelni> send a patch that adds you to MAINTAINERS
[18:24] <durandal_1707> michaelni: dont be silly
[18:24] <EricAhn> ^^;
[18:24] <EricAhn> MAINTAINERS?
[18:24] <michaelni> the file in git
[18:26] <durandal_1707> EricAhn: are you from uk?
[18:27] <EricAhn> Who should i send the patch?
[18:27] <michaelni> ffmpeg-devel 
[18:27] <EricAhn> durandal_1707 : this is south of korea
[18:27] <EricAhn> ffmpeg-devel mailing list?
[18:27] <durandal_1707> yup
[18:28] <EricAhn> oh I got
[18:28] <EricAhn> it
[18:28] <saste> EricAhn, alternatively you may create a github repo
[18:28] <saste> work there, and send patches for review
[18:29] <saste> or ask us to pull changes
[18:29] <EricAhn> saste : oh, It's good idea.
[18:29] <saste> you may need to get used to the ffmpeg development workflow
[18:31] <EricAhn> okay I found https://github.com/FFmpeg/FFmpeg
[18:46] <wm4> "Please provide a failing command line including complete, uncut console output."
[18:47] <wm4> I wish cehoyos would stop this bullshit
[18:53] <Compn> wm4 : why dont you volunteer some time to clear bug reports instead of complaining how others do it ?
[18:53] <wm4> Compn: it was a bug reported by me
[18:54] <durandal_1707> wm4: ignore him, he have list of text he copy paste all the time
[18:57] <saste> wm4, the bug should be easy to fix, do you want to try it?
[18:57] <saste> basically you need to add a few missing checks and do some string bokkeeping
[18:58] <saste> i'll try to have a look at the issue since i'm partially responsible for that code, but i have a lot more work to do atm
[19:08] <saste> ^^ the right question is: why the options are still documented if they have been removed?
[19:11] <wm4> old version?
[19:12] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:b75ac7c71cc8: lavc: include timebase in avcodec string at debug level.
[19:12] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:bee044d7c261: ffmpeg: copy tmcd track timebase parameters
[19:12] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:9362f31b5551: movenc: Calculate fps for tmcd without intermediate step.
[19:12] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:55d66b27902d: movenc: check that fps for tmcd is within encodable range.
[19:25] <wm4> hm wget actually accepts both blank domain name, and domain name + ":" + port
[21:12] <cone-871> ffmpeg.git 03Jason 07master:a717fa84ede9: lavu/timecode: Allow drop frame mode for 60000/1001 fps
[21:12] <cone-871> ffmpeg.git 03Jason 07master:77b740ac0ac4: lavu/timecode: fix time code calculation for 60000/1001 drop frame
[21:56] <michaelni> Daemon404, i see IOC failures without linenumbers (or iam blind)
[22:00] <Daemon404> weird
[22:01] <Daemon404> let me manually test
[22:01] <Daemon404> oh rsync mess up
[22:01] <Daemon404> files were missing
[22:02] <Daemon404> itll be fixed next run
[22:02] <Daemon404> ignore it
[22:02] <michaelni> ok
[22:05] <durandal_1707> michaelni: i see same gmc_mmx in libavcodec/x86/dsputil_mmx.c
[22:13] <durandal_1707> michaelni: how to get rid of av_reverse warning in lavu?
[22:13] <durandal_1707> where ff_reverse should be put?
[22:16] <michaelni> durandal_1707, what warning ?
[22:17] <durandal_1707> av_reverse in lavu/eval
[22:17] <durandal_1707> well array is not really mandatory ...
[22:17] <durandal_1707> i doubt it is big performance drop
[22:21] <michaelni> the attribute deprecate could be droped
[22:23] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:cf48b006400e: cavsdec: check for value in get_ue_code()
[22:23] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:fc8e8e5bef32: h264_qpel: put cpuflags checks back.
[23:18] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:c10350358da5: gifdec: gif_copy_img_rect: Fix end pointer
[00:00] --- Fri Jan 25 2013


More information about the Ffmpeg-devel-irc mailing list