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

[burek]

[00:13] Action: Compn has idea for ffmpeg website banner with drone flying in the sky
[00:14] <Compn> http://farm9.staticflickr.com/8150/7318030594_62ec2381cf_z.jpg
[00:14] <Compn> possibly with droney
[01:00] <llogan> i suppose i could have reverted instead...
[06:22] <Zeranoe1> Can FFmpeg with with reentrant?
[07:26] <ubitux> huh audio example doesn't reconstruct packets either
[07:26] <ubitux> broken examples finally reported
[09:22] <ubitux> kierank: i don't understand what you suggest in the vp9 4x4
[09:23] <ubitux> m4 is 64 bits
[09:25] <kierank> It's 128 bits, no?
[09:25] <nevcairiel> if its sse, it should be
[09:26] <ubitux> mmh i assumed it was 64 because all my ops rely on this being 64
[09:26] <nevcairiel> in sse those names map to the xmm registers
[09:27] <ubitux> mmh
[09:27] <ubitux> i guess i could do simplify that then
[09:27] <ubitux> since this code does not work with mmx anyway
[09:28] <ubitux> but then the number of xmm registers is wrong in the prototype
[10:01] <saste> how is -faststart still relevant nowadays?
[10:01] <saste> which players are affected by that?
[10:01] <saste> at least with ffplay/vlc i see no difference in playback startup time
[10:01] <ubitux> some flash players and httpd with no range request
[10:01] <ubitux> i guess
[10:02] <saste> thanks
[10:17] <durandal_1707> remove unused function from vp8 ? when ?
[10:19] <ubitux> ?
[10:28] <saste>  Doom9 Forums Compromised
[10:28] <saste> why do we have such a news on our page??
[10:28] <durandal_1707> because of Compn 
[10:28] <durandal_1707> Compn: you did not sent it for review
[10:29] <durandal_1707> i'm for removing that
[10:30] <durandal_1707> ah it is already done
[10:32] <cone-828> ffmpeg.git 03Anton Khirnov 07master:c9a13a289d0e: lavc: remove old unused audio conversion functions.
[10:32] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:6bf4edec27de: Merge commit 'c9a13a289d0e1607387854127476813a1ee3d34b'
[10:33] <nevcairiel> michaelni: the old audio api was not part of the public API, its header not installed .. do things really use that?
[10:33] <durandal_1707> michaelni just have nostalgia for that code
[10:34] <durandal_1707> same for libmpcodecs
[10:35] <saste> why wasn't it ifdeffed?
[10:35] <durandal_1707> it is awkward to support old stuff when even examples do not work with current code
[10:35] <durandal_1707> examples should be part of fate
[10:38] <cone-828> ffmpeg.git 03Paul B Mahol 07master:66518f6feb95: avcodec/cook: use av_freep()
[10:38] <durandal_1707> afaik applications already need to be updated...
[10:41] <saste> but yes it was not even public API
[10:41] <saste> and i doubt it is much tested
[10:41] <durandal_1707> but people use it like mplayer
[10:42] <saste> michaelni, when do you schedule to drop that API?
[10:42] <saste> keeping all APIs indefinitively is not realistic
[10:43] <saste> anyway keeping it for the new release is senseful
[10:43] <nevcairiel> we just had a new release :D
[10:43] <michaelni> nevcairiel, i dunno, there are some hits by google to some random pieces of code using it
[10:44] <nevcairiel> should at least put a deprecation tag on it so people know to migrate
[10:44] <michaelni> yes
[10:45] <michaelni> saste, i dunno, i guess we can remove it when someone posts a patch that removes it and there is consensus on its removial on ffmpeg-devel
[10:45] <saste> or drop it at the next bump
[10:45] <durandal_1707> michaelni: you ever had contact with people that actually tried to use new release with old api stuff?
[10:45] <michaelni> or there is some strong technical need to remove it 
[10:45] <saste> if we want to help projects misusing internal API
[10:46] <durandal_1707> technical need: it doesnt help anyone at all
[10:47] <saste> but i don't mind, i'll probably send a drop-at-the-next-bump patch later
[10:47] <durandal_1707> if you do not forget
[10:47] <saste> what should i forget?
[10:47] <durandal_1707> to drop it at next bump
[10:48] <saste> you missed the cheesy humor in my reply
[10:50] <michaelni> durandal_1707, yes i got mails from people who tried to build olf code with new ffmpeg
[10:58] <durandal_1707> michaelni: me too, and does keeping above help them?
[11:05] <saste> talking about serious stuff, what's the name of the new release?
[11:05] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:e36231969af5: avcodec/audioconvert: deprecate API
[11:07] <durandal_1707> saste: the 2.2 one?
[11:09] <saste> no the 2.1 one
[11:12] <durandal_1707> saste: isn't in on web?
[11:13] <saste> ah ok
[11:13] <saste> "Fourier", cool
[11:14] <cone-828> ffmpeg.git 03Anton Khirnov 07master:feeafb4adabd: lavf: do not export av_register_{rtp,rdt}_dynamic_payload_handlers from shared objects
[11:14] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:d3e13250a030: Merge commit 'feeafb4adabd5c17de1738ed9962e40892b20edb'
[11:28] <ubitux> http://pastie.org/pastes/8439685/text
[11:28] <ubitux> is it me or the installed libs are extremely weird?
[11:28] <ubitux> +sizes
[11:39] <saste> what's so weird?
[11:40] <saste> encoder options are arcane...
[11:41] <ubitux> saste: .a is 116M, .so 7M for libavcodec
[11:41] <Daemon404> saste, only only in the src =p
[11:41] <ubitux> similar for the others
[11:42] <Daemon404> those all look correct
[11:42] <ubitux> ok
[11:44] <saste> Daemon404, how do you explain that?
[11:45] <Daemon404> expain what?
[11:45] <saste> the difference in size
[11:45] <Daemon404> debug info, actually linking it
[11:45] <Daemon404> etc
[11:45] <saste> isn't debug info contained in .so files as well?
[11:46] <ubitux> also it seems to be grabbing the lib installed on my system somehow
[11:46] <ubitux> something is fishy :(
[11:47] <saste> for example b_strategy
[11:48] <saste> it is used only by the mpeg encoders, with values (0, 1, 2) which are not documented anywhere
[11:48] <Daemon404> saste, just symbols afaik
[11:48] <saste> and used by other libs (libxvas and libx264) to bind wildly related stuff
[11:50] <saste> and the git blame for that code obviously shows K&R cosmetics
[11:51] <durandal_1707> what K&R did?
[11:52] <saste> the revision before was a split
[11:52] <ubitux> try with -w, but in case of line breaks you're doomed
[11:53] <durandal_1707> Kidnap & Ransom
[12:06] <cone-828> ffmpeg.git 03Anton Khirnov 07master:cd43ca0443a2: lavfi: do not export the filters from shared objects
[12:06] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:325f6e0a97c9: Merge remote-tracking branch 'qatar/master'
[12:07] <saste> michaelni, any hope to have an explanation of b_strategy and b_sensitivity?
[12:13] <michaelni> b _strategy is used by 3 different encoders 
[12:18] <michaelni> you could use the description from x264 --b-adapt probably
[12:18] <michaelni> 0:disabled, 1:fast, 2:optimal
[12:19] <saste> michaelni, libx264, libxavs, mpegvideo encoders
[12:19] <saste> ok, will see what i manage to do
[12:23] <ubitux> BBB: any reason we should prefer the mmx registers over the xmm ones since we are using ssse3?
[12:24] <nevcairiel> sometimes it makes sense to use mmx when your data is too small for xmm
[12:24] <nevcairiel> no idea if thats the case here
[12:37] <durandal_1707> nice, now i can not call filters directly
[12:39] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:069ceea7da66: timefilter: Fix typo in allocation failure message
[12:48] <BBB> ubitux: usually mmx instructions are slightly faster than xmm, so if you don't use the space, mmx is better
[12:49] <ubitux> i see, ok
[12:49] <BBB> ubitux: see http://www.agner.org/optimize/instruction_tables.pdf
[12:50] <BBB> but usually best to just try and see
[12:50] <BBB> if it can be done in xmm using full register width, that's usually better, unless it involves tons of shuffling and moving data around
[12:51] <saste> mateo`, can you have a look at some of these: http://ffmpeg.org/trac/ffmpeg/tags?q=%27osx%27&ticket=on
[12:51] <Daemon404> it's too bad pengvado's brain was never dumped to a pdf (re: asm)
[12:53] <BBB> yeah that would be useful sometimes
[12:53] <BBB> I'm still wondering why I'm pretentious
[12:53] <BBB> but I'll worry about that later
[12:54] <mateo`> saste: i don't have time at the moment, but i'll take a look at it after doing a proper review of the iSight patch
[13:03] <ubitux> so, libvpx still has no threaded encoding?
[13:04] <ubitux> mmh... how long did it take last time i encoded 40 sec of video?
[13:04] <ubitux> 7-8 hours?
[13:05] <durandal_1707> in perfect scenario you would with threading lower that to 1 hour
[13:09] <saste> mateo`, sure
[13:09] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:a483aae7d8bc: h264: Check all allocations
[13:12] <BBB> ubitux: someone needs to send them a patch I think
[13:12] <BBB> I'll add frame-mt sometime soon to ffvp9
[13:15] <durandal_1707> what about slice-mt?
[13:15] <durandal_1707> 'slice'
[13:15] <BBB> tile
[13:15] <BBB> I'll do that too, but later
[13:15] <BBB> frame-mt is more important
[13:15] <BBB> as long as we don't support effective er, we're useless for realtime purposes
[13:15] <BBB> and then tile-mt isn't very useful
[13:30] <ubitux> BBB: they don't plan to make a decent encoder?
[13:30] <ubitux> because, isn't it the only one encoder available?
[13:31] <durandal_1707> writing anything decent is hard
[13:31] <ubitux> well, i mean usable
[13:32] <ubitux> if it takes days to make a few minutes encode, no one is going to use it
[13:33] <durandal_1707> writting usable lossy encoder is much harder
[13:34] <ubitux> oh i didn't say it was easy ofc
[13:35] <durandal_1707> i could speculate more about reasons, but i find that ugly
[13:55] <ubitux> do we have a hwaccel doing encoding?
[13:56] <nevcairiel> no(t yet)
[14:00] <ubitux> anyone working on such thing?
[14:00] <ubitux> or interested to?
[14:02] <nevcairiel> i might, and luca expressed some interest as well
[14:03] <nevcairiel> but for myself, it'll be next year
[15:26] <durandal11707> K&R needs concentration
[15:29] <durandal11707> huh isn't code in lavc/mdec doing simply swap with loop, instead of using dsp
[15:29] <saste> wm4: do you want to review my sws filter patch?
[15:29] <saste> otherwise i think i'll commit it, if i don't change mind
[15:33] <durandal11707> Don is reseting the history
[15:42] <saste> michaelni, if I set bf=-1 it will crash the mpeg4 encoder
[15:42] <saste> bf=-1 is actually useful only to let libx264 to leave the default value
[15:44] <saste> ffmpeg -i matrixbench_mpeg2.mpg  -codec:v mpeg4 -an  -bf -1  -y out.mp4
[16:07] <saste> bb73cda2 => fix libx264, breaks everything else
[16:07] <ubitux> yes but who cares about other codecs anyway?
[16:20] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:6103faaa51d2: matroskaenc: fixed display width / height calculation for stereo mode
[16:20] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:ce55e667facb: avcodec/mpegvideo_enc: check that max_b_frames is not negative
[16:30] <saste> michaelni, thanks
[16:45] <wm4> saste: where is it?
[17:27] <wm4> are there any webm vp9 samples around?
[17:40] <Daemon404> wm4, in FATE
[17:40] <Daemon404> in the wild? havent seen any
[17:43] <wm4> I see
[17:43] <kierank> Daemon404: yotube
[17:43] <kierank> youtube*
[17:43] <Daemon404> iirc youtube wasnt doing vp9?
[17:44] <kierank> yes they were
[17:44] <Daemon404> 'were'?
[17:44] <Daemon404> as in they stopped?
[17:46] <wm4> vp9 over dash, it's like a dream come true
[17:47] <Daemon404> does this dream involve whips and leather
[17:48] <wm4> and lawyers, yes
[17:56] <ubitux> wm4: i generated one with libvpx
[17:56] <ubitux> do you want it?
[17:56] <wm4> ubitux: sure
[17:56] <wm4> I actually just want to test demuxing
[17:56] <ubitux> http://lucy.pkh.me/samples/vp9/
[17:57] <wm4> and the fate samples are naturally extremely short
[17:57] <ubitux> this one is 40 sec
[17:58] <ubitux> i'm currently generating a slighty longer one
[17:58] <ubitux> but it will take a few days
[17:58] <ubitux> :)
[17:59] <wm4> this one worked nicely
[18:01] <wm4> which surprises me, because my demuxer accidentally doesn't pass extradata to the decoder
[18:01] <nevcairiel> vp9 has extradata?
[18:01] <wm4> apparently not :)
[18:03] <Daemon404> 'a few days'
[18:03] <Daemon404> sounds usable
[18:03] <ubitux> well
[18:03] <ubitux> it's 5k frames after all
[18:03] <ubitux> :D
[18:04] <ubitux> 5k frames, 5 days
[18:04] <Daemon404> [17:03] <@Daemon404> sounds usable
[18:04] <ubitux> ;))
[18:04] <wm4> and I can't find the webm/vp9 spec
[18:04] <Daemon404> ahahahahahahahahaHAHAHAHAH
[18:04] <JEEB> > vp9 > spec
[18:04] <JEEB> ahoy!
[18:04] <wm4> I expected this reaction
[18:04] Action: JEEB gives wm4 a friendly hug
[18:05] <ubitux> well you've become pretty demanding
[18:05] <ubitux> remember when all codecs needed to be reversed?
[18:05] <ubitux> @_@
[18:05] <wm4> lol
[18:05] <Daemon404> sure
[18:05] <Daemon404> just dont have google sell it to me as 'open'
[18:06] <nevcairiel> its only not open if such a document exists, but is not published
[18:06] <nevcairiel> if it doesnt exist, you have no reason to complain
[18:06] <nevcairiel> you get the same info they work off =P
[18:07] <Daemon404> http://guru.multimedia.cx/chrome-droppings/
[18:09] <Compn> wm4 : i think BBB didnt write a spec. there is only code
[18:09] <Compn> not that it was his codec in the first place :)
[18:09] <Compn> ehe
[18:09] <wm4> at least webvtt in webm had some specs
[18:10] <wm4> and webvtt is a google thing too
[18:10] <nevcairiel> its a trivial format, not sure what webm specs it needs
[18:10] <nevcairiel> no extradata, no nothin'
[18:10] <Daemon404> [17:10] <+wm4> and webvtt is an abomination
[18:10] <Daemon404> ftfy
[18:11] <wm4> well I'm sure surprised how little hevc and vp9 need from the demuxer
[18:11] <wm4> webvtt and opus are so complicated in this respect
[18:12] <nevcairiel> hevc will need dealing with extradata,  although if everything is muxed sanely you just need to copy it 1:1
[18:12] <Daemon404> thats not a safe assumption
[18:12] <Daemon404> esecially for 'pro' stuff
[18:12] <nevcairiel> and of course there is the open intra refresh problem and seeking, but that was never solved for h264, so doubtful thats going to change much :P
[18:13] <nevcairiel> of course there will be some oddball format that invents their own extradata
[18:13] <nevcairiel> but for the mainstream things, ts/mkv/mp4, its easy
[18:13] <Daemon404> nut!
[18:14] <Daemon404> ubitux, does vp9 actually have a real release yet
[18:14] <Daemon404> because they fucked that up and changed stuff due to bugs
[18:14] <wm4> isn't nut = "use ffmpeg internals lol"
[18:20] <smarter> Daemon404: the closest thing to a release is http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=shortlog;h=refs/heads/stable-vp9-decoder
[18:20] <Daemon404> we all saw how that turned out...
[18:20] <smarter> if you care about encoding, you should use master for now
[18:21] <Daemon404> well i was going to run it on a more powerful box
[18:21] <Daemon404> because 1k frames per day is insane
[18:25] <smarter> use --cpu-used=1 if you don't already
[18:25] <Daemon404> what exactly does that o
[18:25] <Daemon404> do
[18:25] <smarter> it's the speed setting
[18:25] <Daemon404> ive never touched vp9 before this very instant
[18:25] <smarter> 0 is the slowest/best
[18:25] <smarter> 5 is the fastest/worst quality
[18:25] <Daemon404> right im more interested in 0
[18:26] <Daemon404> all the current hevc encoders are crap, may as well add vp9 into the mix
[18:26] <smarter> 1 should be ~5% worse than 0 and much faster
[18:27] <smarter> I use this command-line, but I think some flags are now no longer needed because the default became more sane: "./vpxenc ~/samples/parkjoy.y4m -o /dev/null --good --cpu-used=1 --target-bitrate=16000 --end-usage=vbr --auto-alt-ref=1 --fps=30000/1001 -v --minsection-pct=5 --maxsection-pct=800 --lag-in-frames=16 --kf-min-dist=0 --kf-max-dist=360 --min-q=4 --max-q=60 --arnr-maxframes=5 --arnr-strength=3 -p 2 --codec=vp9"
[18:29] <Daemon404> i was going to test with a bunch of real world sources
[18:29] <Daemon404> broadcasts, masters, etc
[18:30] <smarter> have fun :p
[18:31] <Daemon404> side note: this is for personal curiosity, not profession
[18:31] <Daemon404> al
[18:31] <Daemon404> 301KB/s
[18:31] <Daemon404> woooo fast
[18:40] <cone-828> ffmpeg.git 03Stefano Sabatini 07master:61c1f2cb1e7e: doc/muxers: add definitory line for the MOV/MP4/ISMV muxer
[18:40] <cone-828> ffmpeg.git 03Stefano Sabatini 07master:9fa0dccca649: lavc: extend documentation for the "bf" option
[18:40] <cone-828> ffmpeg.git 03Stefano Sabatini 07master:d4ac3e593481: lavc/mpegvideo_enc: fix typo
[18:51] <saste> what's the status of the internal aac encoder?
[18:52] <saste> do you support the claim in https://trac.ffmpeg.org/wiki/AACEncodingGuide
[18:52] <saste> fdk_aac > libfaac > aacenc?
[18:52] <Daemon404> saste, that is correct
[18:52] <Daemon404> right now
[18:52] <Daemon404> that epic bug tracker thread i still ongoing
[18:52] <Daemon404> and nothing has been pushed
[18:52] <Daemon404> is*
[18:52] <saste> so it seems
[18:55] <wm4> saste: can you hint me where the swscale filter posts are?
[18:56] <saste> wm4: [FFmpeg-devel] [PATCH] swscale: Support setting filters through AVOptions
[19:11] <nevcairiel> anyone know how well ffmpeg interleaves ts streams?
[19:16] <burek> llogan, im not sure, i'll check.. probably the devel machine ran out of electr. power
[19:18] <burek> it's highly unreliable :( i need to migrate it to another, but i need to find some spare time to do so..
[19:21] <llogan> burek: convert it to gasoline/petrol
[19:24] <burek> +1 :)
[19:37] <ubitux> did something happen with the consulting page or whatever?
[19:37] <ubitux> i had 4 consulting requests in 4 days
[19:37] <ubitux> first time i see this
[19:38] <ubitux> <@Daemon404> ubitux, does vp9 actually have a real release yet // i'm not following libvpx development at all 
[19:42] <cone-828> ffmpeg.git 03Clément BSsch 07master:8d55362fd0d4: avformat/avisynth: re-add trailing \n.
[19:48] <cone-828> ffmpeg.git 03Luca Barbato 07master:dcd3eda6cb88: configure: Move gcc-only -W option where it belongs
[19:48] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:df69af4ee1bc: Merge commit 'dcd3eda6cb8884beeb67ef5eb61b4bb6b01d29ea'
[19:56] <cone-828> ffmpeg.git 03Luca Barbato 07master:e78913052263: configure: Provide an hardened toolchain option
[19:56] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:6c5f17e738a5: Merge commit 'e78913052263af80855590659fb0f705e8f13c8a'
[19:58] <saste> ubitux: same happened to me
[19:58] <ubitux> saste: ok :)
[19:58] <saste> it is called the autumn wakeup
[19:59] Action: saste saste is doing (very little) boring paid work
[19:59] <kierank> because it's the end of DST?
[20:01] <saste> kierank, probable, less time to do outdoor fun stuff
[20:03] <nevcairiel> nonsense, just gotta start earlier!
[20:06] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:327c439f811a: timefilter: Handle memory allocation failure
[20:06] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:42bf156e132b: Merge commit '327c439f811a89d774db9a86f72951d295193e5f'
[20:08] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:25c7db7cc99d: avio: Check for memory allocation failure of private data
[20:08] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:e166b82dd483: Merge commit '25c7db7cc99d74fe6fb56a6fd52c9b5f1591e448'
[20:21] <wm4> saste: I hope my "review" isn't too negative...
[20:23] Action: saste is used to too negative review
[20:24] <wm4> btw. what is eval.h included for?
[20:25] <saste> wm4, av_strtod
[20:25] <wm4> ok
[20:26] <wm4> why is that needed instead of just strtod()?
[20:32] <saste> indeed it is probably unneeded
[20:33] <saste> but it was in michael's patch, and I didn't think about it
[20:36] <wm4> depends on michael's reply then
[20:37] <cone-828> ffmpeg.git 03Anton Khirnov 07master:4eb49fdde8f8: lavf: remove unreliable timestamp guessing heuristic
[20:40] <ubitux> BBB: i'd like to work on 8x8 before applying 4x4
[20:41] <ubitux> we can probably factor some things, and it's easier to move things around randomly when it's still not upstream
[20:41] <ubitux> the optim is not worth being pushed right now for overall decode anyway
[20:41] <wm4> huh, that commit has no merge record?
[20:42] <ubitux> wm4: it's re-applied
[20:42] <wm4> oh
[20:42] <ubitux> wm4: it wasn't merge (see merge commit message)
[20:42] <ubitux> now that the abi is solved, i guess it can be applied
[20:43] <michaelni> wm4, my reply ? where what ?
[20:43] <michaelni> wm4, yes, nevcairiel sugested id just apply and wait
[20:44] <michaelni> IIRC
[20:45] <wm4> michaelni: about the swscale filter as avoption patch
[20:46] <michaelni> iam fine with any form of *strtod for it
[20:46] <ubitux> http://pastie.org/8440873 lol
[20:46] <saste> wm4, yes there is no point into using av_strtod I think
[20:47] <wm4> michaelni: well, about more general issues too
[20:48] <michaelni> what issues ?
[20:49] <wm4> well, read my mail...
[20:53] <michaelni> ok read it, what should i do now ?
[20:53] <wm4> well, do we really need the change?
[20:53] <michaelni> iam not sure
[20:54] <wm4> or maybe at least the syntax should be extended to support common cases?
[20:54] <wm4> *use cases
[20:54] <michaelni> there could be support for things like gauss(1.2)
[20:55] <michaelni> there could be support for things like combining vectors per convolution gauss(1.2)|shift(123), shouldnt be hard to implement but iam also dont want to overdesign this
[20:57] <michaelni> sws_convVec() <-- for convolution 
[20:59] <cone-828> ffmpeg.git 03Anton Khirnov 07master:8b64c2ba0382: lavc: add a dummy field to AVStream to preserve ABI compatibility for avconv
[20:59] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:249cc58c3ada: Merge commit '8b64c2ba0382892cad9e1a5ba601696d4cbb4d04'
[21:11] <saste> wbs, willing to review libfdk_aac docs?
[21:37] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:15b1b0887466: avutil/opt: fix flags check on non x86
[21:45] <cone-828> ffmpeg.git 03Anton Khirnov 07master:c872d310cd9c: avconv: stop accessing AVStream.parser
[21:45] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:0460b9bb3e34: Merge commit 'c872d310cd9c605e5f994ad8ac79dc72303c0d29'
[21:50] <Zeranoe1> Can FFmpeg be run with reentrant?
[21:58] <michaelni> what do you mean by "with reentrant" ?
[22:00] <Zeranoe1> I guess is it possible to do re entrance with FFmpeg?
[22:01] <michaelni> you can call a decoder while another decoder works yes
[22:02] <cone-828> ffmpeg.git 03Diego Biurrun 07master:9510d7689e23: fate.sh: Allow non-fast-forwards when updating sources
[22:03] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:a8fe8d4fe986: Merge commit '9510d7689e236f6a4748795604fba427c130d0ad'
[22:03] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:0999b1db3c1a: tests/fate.sh: run git reset only when fetch succeded
[22:03] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:7f4fd72f81b7: tests/fate: fix fate on branches different from origin/master
[22:12] <saste> cc1: warning: unrecognized command line option "-Wno-maybe-uninitialized"
[22:12] <saste> uh?
[22:14] <ubitux> this was moved to gcc specific case today iirc
[22:14] <ubitux> so if you don't have gcc that's normal i'd say
[22:15] <ubitux> or maybe that's a really old gcc?
[22:15] <nevcairiel> the option is pretty new in gcc, too
[22:15] <nevcairiel> 4.7 i think
[22:15] <ubitux> ah? ok
[22:15] <ubitux> well the warning shouldn't be disabled anyway
[22:15] <nevcairiel> imho its more wrong then right
[22:16] <nevcairiel> gcc doesnt do a very good job tracking that
[22:16] <ubitux> better have 9 false positive and 1 true match, than no issue found
[22:16] <ubitux> also as you said it's recent, and meant to be improved i suppose
[22:16] <nevcairiel> since we need the off option, it must be default enabled in some way
[22:23] <ubitux> nevcairiel: looking at your benchmark, it's fun how vc1 is so slow
[22:24] <ubitux> even though there are quite some optim available
[22:24] <nevcairiel> well, its not threaded
[22:24] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:58d13cea307e: h264: Check all allocations
[22:24] <ubitux> aah, that's it then
[22:24] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:845086149b15: Merge commit '58d13cea307e776664dae711608b358dd4b84fff'
[22:25] <nevcairiel> although i disabled mt for mpeg4 as well
[22:25] <nevcairiel> still does 400 fps
[22:26] <ubitux> maybe a scale filter comes into play or sth?
[22:26] <nevcairiel> nah its just that slow
[22:26] <ubitux> ok, fun :p
[22:26] <nevcairiel> was tested with my own software, it doesnt auto-insert stuff
[22:26] <ubitux> ok :)
[22:28] <nevcairiel> i dont usually use the vc1 decoder, i use microsofts binary decoder because its 5x faster
[22:28] <nevcairiel> but i thought for the benchmark it wouldnt hurt
[22:42] <cone-828> ffmpeg.git 03Ingo Brückl 07master:8fbb0979da8e: build: remove pointless condition
[22:42] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:6b312143793b: Merge remote-tracking branch 'qatar/master'
[22:51] <cone-828> ffmpeg.git 03Anssi Hannula 07master:f86387b6c2b1: lavf/spdifdec: fix demuxing of AAC in IEC 61937
[23:09] <Compn> nevcairiel : vc1 binary 5x faster than ffvc1 ?
[23:09] <Compn> is the binary threaded ?
[23:09] <nevcairiel> among other things, yes
[23:10] <Compn> comparing threaded binary to threaded ffvc1 wonder what speed diff is
[23:10] <nevcairiel> there is no threaded ffvc1
[23:10] <Compn> ah
[23:10] <Compn> one of the codecs that wasnt threaded ?
[23:12] <Compn> http://trac.ffmpeg.org/ticket/1885
[23:12] <Compn> i see
[23:12] <kierank> oh ffv1 isn't intra
[23:32] <michaelni> what is preferred for iSight, autodetect or disabled by default ?
[00:00] --- Wed Oct 30 2013