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

[burek]

[00:44] <llogan> Daemon404: care to write a news entry that ffmpeg can be compiled now with MSVC? or if you give me the text I'll update the site.
[00:47] <llogan> (or anyone else who isn't MSVC ignorant like me)
[01:00] <RT|AO> 20:33 <@ubitux> http://www.flickr.com/photos/flameeyes/7906103846/lightbox/ VDD12
[01:00] <RT|AO> 20:34 <@ubitux> Daemon404: where are you btw? :)
[01:00] <RT|AO> 20:35 <@ubitux> since i "missed" you then :p
[01:00] <RT|AO> 20:39 < KGB> [FFmpeg] michaelni pushed 25 new commits to master: http://git.io/3-62Aw
[01:00] <RT|AO> 20:39 < KGB> [FFmpeg/master] blowfish: Factorize testing into a separate function - Martin Storsjö
[01:00] <RT|AO> 20:39 < KGB> [FFmpeg/master] blowfish: Fix CBC decryption with dst==src - Martin Storsjö
[01:00] <RT|AO> 20:39 < KGB> [FFmpeg/master] blowfish: Add more tests - Martin Storsjö
[01:00] <RT|AO> 21:00 <@j-b> thresh: cone?
[01:00] <RT|AO> 21:00 <+thresh> j-b: it will join once there is a commit to show
[01:00] <RT|AO> 21:01 <+thresh> you provide a channel to spam to in a hook, not in a daemon instance
[01:00] <RT|AO> 21:01 <@j-b> oh, nice
[01:00] <RT|AO> 21:12 < fflogger> [newticket] eric@&: Ticket #1787 (Losing Silent Audio When Converting From Nellymoser Produced By Flash ...) created https://ffmpeg.org/trac/ffmpeg/ticket/1787
[01:00] <burek> RT|AO ?
[01:01] <RT|AO> 21:14 < fflogger> [attachment] eric@&: 1_1349110964561.flv attached to Ticket #1787 https://ffmpeg.org/trac/ffmpeg/attachment/ticket/1787/1_1349110964561.flv
[01:01] <RT|AO> 21:32 <@michaelni> j-b, thresh http://pastebin.com/gimSnw4T
[01:01] <RT|AO> 21:32 <+thresh> oups..
[01:01] <RT|AO> 21:32 <@j-b> michaelni: well, well well
[01:01] <RT|AO> 21:33 <+thresh> michaelni: re-push, please
[01:01] <RT|AO> 21:33 < cone-205> ffmpeg.git Michael Niedermayer libavcodec/mpeg12enc.c libavcodec/mpegvideo.h: mpeg2enc: support and use frame_rate_ext when needed
[01:01] <RT|AO> 21:35 <@michaelni> done, thx
[01:01] <RT|AO> 21:36 <@michaelni> ive also disabled the github KGB
[01:01] <RT|AO> 21:59 < fflogger> [editedticket] saste: Ticket #1783 (libavutil contains file with the same name as a system header) updated https://ffmpeg.org/trac/ffmpeg/ticket/1783#comment:10
[01:01] <RT|AO> 22:00 -!- mode/#ffmpeg-devel [+o durandal_1707] by ChanServ
[01:01] <RT|AO> 22:01 <@durandal_1707> michaelni: frame.data[X] for planar format seems to not come one after another
[01:01] <RT|AO> 22:03 <@durandal_1707> so instead of using single malloc function i need to use each one per channel
[01:01] <RT|AO> 22:03 <@durandal_1707> issue doesn't seem to happen with 16bit but does for 24(32)
[01:01] <RT|AO> 22:04 < nevcairiel> why would you malloc the channels manually, there is get_buffer to do that
[01:01] <RT|AO> 22:05 <@durandal_1707> i need that for < 24 bits per sample
[01:01] <RT|AO> 22:12 <+kierank> huh
[01:01] <RT|AO> 22:12 <+kierank> why does that make a difference
[01:01] <RT|AO> 22:13 <@durandal_1707> in > 16 bit case i do not need extra buffer, i just use frame
[01:01] <burek> llogan could you +mute RT|AO for a while
[01:01] <RT|AO> 22:47 <@saste> michaelni: where can I find a file with repeat_pict != 0?
[01:01] <RT|AO> 22:48 <@michaelni> saste, some telecine stuff should use it
[01:01] <RT|AO> 22:49 <@Daemon404> ubitux, you can only see my head
[01:01] <burek> until it empties its buffer
[01:02] <RT|AO> 22:49 <@Daemon404> middle-ish...
[01:02] <RT|AO> 22:49 <@saste> michaelni, so the question turns to: where can I find some telecine stuff? ;-)
[01:02] <RT|AO> 22:51 <@michaelni> samples archive probably, i dont know a specific file ATM either :(
[01:02] <RT|AO> 22:51 <@saste> uhm... well I'll have to do a brute force scan
[01:02] <RT|AO> 22:51 <@saste> something in fate samples?
[01:02] <RT|AO> 22:52 < divVerent> sawe can narrow it down a little
[01:02] <RT|AO> 22:52 < divVerent> it's mostly used on DVDs
[01:02] <RT|AO> 22:52 < divVerent> and very unlikely in TS streams
[01:02] <ubitux> &
[01:02] <RT|AO> 22:52 < divVerent> as these tend to be real interlaced norally ;)
[01:02] <ubitux> burek: you can mute the channel, not a single person
[01:02] <ubitux> it woul require to voice everyone else
[01:03] <burek> usually +b does mute also
[01:03] <ubitux> ah right :)
[01:03] <burek> but yes, +m is for channel :)
[01:04] <RT|AO> oops, wrong mouse button is pressed. ;(
[01:05] <burek> *it happens :))
[01:08] <RT|AO> "Irssi: Pasting 5 lines to #ffmpeg-devel. Press Ctrl-K if you wish to do this or Ctrl-C to cancel." # Irssi pasted and showing this. WTF
[01:10] <Skyler_> that's to stop you from accidentally flooding channels with large pastes.
[01:11] <Skyler_> quite useful.
[01:11] <ubitux> :)
[01:13] <cone-205> ffmpeg.git 3Michael Niedermayer 7libavcodec/aacenc.c: aacenc: fix out of array writes
[01:13] <cone-205> ffmpeg.git 3Dmitry Samonenko 7libavcodec/libspeexenc.c: libspeexenc: Add an option for enabling DTX
[01:13] <cone-205> ffmpeg.git 3Dmitry Samonenko 7libavcodec/libspeexenc.c: libspeexenc: Updated commentary to reflect recent changes
[01:28] <Daemon404> llogan, im currently working on shared lib support
[01:28] Action: Daemon404 wrote a proper script to generate a def file
[01:28] <Daemon404> rather than hack it into the converter
[01:38] <JEEB> yeah, scripts make more sense for stuff like that
[01:38] <Daemon404> my intention is to treat it like gas-preproc
[01:43] <llogan> burek: heh, sorry. i was afk.
[03:17] <cone-205> ffmpeg.git 3Michael Niedermayer 7libavcodec/mpeg12data.c libavcodec/mpeg12data.h libavcodec/mpeg12enc.c: mpeg2videodec: fix list of supported frame rates to include sane ext rates.
[03:28] <RT|AO> "< Skyler_> that's to stop you from accidentally flooding channels with large pastes." # but it actually pasted to channel, then showing it afterwards, which make it useless. :(
[04:03] <Compn> Kim Dotcom’s Gaming Lag Hints at New Spying Controversy
[04:03] <Compn> hah! 
[04:03] <Compn> thats awesome
[04:04] <Compn> lag, the government is stealing my packets
[04:16] <Daemon404> Compn, every comcast connection ever must be bugged then
[05:57] <cone-205> ffmpeg.git 3Duncan Salerno 7libavformat/http.c: http: add option to prevent probing for HTTP seekability
[05:57] <cone-205> ffmpeg.git 3Duncan Salerno 7libavformat/http.c: http: prevent the Range header being sent when seekability probing isnt used
[05:57] <cone-205> ffmpeg.git 3Duncan Salerno 7libavformat/hls.c: hls: Disable http seekability probing
[07:37] <cone-205> ffmpeg.git 3Ronald S. Bultje 7libavcodec/h264_cabac.c libavcodec/h264_cavlc.c: lavc/h264: don't touch H264Context->ref_count[] during MB decoding.
[09:36] <durandal_1707> michaelni: i want to write scalarproduct_in16 for SSSE3
[10:08] <burek> <Compn> Kim Dotcom’s Gaming Lag Hints at New Spying Controversy <- Compn, that's actually a common thing :)
[10:09] <burek> I've found a numerous cases where people are being "proxied" through the systems intended to log/analyze all the traffic of the given isp
[10:09] <burek> the easiest case to test for the most widely used "tool" is to try to connect to a bogus ip, using telnet, and if the connection succeeds, well, you know what it is :)
[10:14] <divVerent> burek: hehe
[10:14] <divVerent> in my company WLAN here, all FTP is intercepted
[10:14] <divVerent> I can ftp to 1.1.1.1
[10:14] <divVerent> SUPPOSEDLY they do this as a crappy implementation of active-FTP-through-NAT
[10:15] <burek> well, ftp is rarely monitored, mostly http and irc is of interest
[10:15] <burek> that might be just some kind of (reverse) proxy
[10:15] <burek> or something
[10:15] <divVerent> right... but why would they monotr in that way
[10:15] <divVerent> and not on IP packet level
[10:15] <divVerent> that wouldn't be so easily detectable
[10:16] <burek> well, mikrotik routers have that functionality to proxy at tcp level
[10:16] <divVerent> and also, I once did monitor FTP ;)
[10:16] <divVerent> when at the Chaos Communication Congress a few years ago
[10:16] <divVerent> they had many FTPs with interesting... stuff on them
[10:16] <divVerent> but it's so tedious to ask everyone...
[10:16] <divVerent> so I sniffed for USER, PASS and CWD requests
[10:16] <divVerent> problem: apparently, even CCC members are stupid enough to do POP3 from an open WLAN
[10:17] <divVerent> which also uses USER and PASS...
[10:17] <burek> mikrotik routers, for example, they fake syn/syn-ack/ack with you and buffer some amount of bytes to figure out what are you trying to do and then redirect all the traffic for that connection to a configured route or so
[10:17] <burek> so that you can configure one route just for p2p, which might be useful :)
[10:18] <burek> :)
[10:19] <burek> also, just to mention, since I work for one isp, the internal affairs bureau, or how is it called world-wide - police? :) they officially asked all the isps in the country to provide a way for them to be able to remotely sniff all the traffic without being noticed
[10:19] <divVerent> yes... but I hope no ISP dares to do such things
[10:19] <burek> i mean, wtf..
[10:19] <divVerent> faking a SYN-ACK is highly problematic for many software
[10:19] <divVerent> yes, let's say I am working externally for an ISP too
[10:20] <divVerent> and our company actually did a part of the "lawful interception" (or was it lawless?) solution
[10:20] <divVerent> but that one sure doesn't fake SYNs
[10:20] <divVerent> it is connected via a "monitor port" (receive only) to the customer
[10:20] <divVerent> so it can't even "accidentally" forge packets/replies
[10:21] <burek> that's the cisco way I guess
[10:21] <divVerent> yes, we actually don't do this on cisco
[10:21] <divVerent> cisco's name is monitor port though
[10:21] <divVerent> but this interfaces to some weird ADSL hardware
[10:21] <divVerent> main reason is for doing it this way is BTW
[10:22] <divVerent> that in Germany, the ISP only does part of the interception
[10:22] <divVerent> the interception device is a blackbox that the government places in the datacenters, roughly spoken
[10:22] <divVerent> and we have to provide for ways to route the correct customer's traffic to the boxes
[10:22] <divVerent> so obviously we don't trust these boxes, and that's why they are connected receive-only
[10:22] <burek> yeah
[10:22] <burek> you are lucky they provide you with such hardware
[10:22] <divVerent> they'r even on separate electrical circuits with lesser SLAs ;)
[10:23] <divVerent> so in case they short out, nothing else breaks
[10:23] <burek> here, they accepted a law that legally binds you to provide them with the hardware too
[10:23] <burek> and also you are obligated to log all traffic for 6 months..
[10:23] <burek> and we say china is doing something bad.. :)
[10:23] <burek> they just block what they dont like and dont bother investigating :)))
[10:24] <divVerent> 6 months... not sure, may be 3 here
[10:24] <divVerent> but same thing
[10:24] <divVerent> but well
[10:24] <divVerent> why is Germany using it? because USA pressured them to do it
[10:24] <burek> long live ssl :)
[10:24] <divVerent> it's all kissing ass of the RIAA/MPAA
[10:25] <mateo`> hi, i'd like to understand the difference between strict gop vs closed gop. For both mode, the gop size is fixed and if i understand well in strict gop mode, a picture from another gop could be referenced in the current gop ?
[10:25] <divVerent> and MAYBE a bit of anti terrorism
[10:25] <burek> well, people that govern the EU and federal reserves are the same people, so it's no wonder
[10:25] <burek> mateo` http://forum.doom9.org/archive/index.php/t-105129.html
[10:26] <burek> brb
[10:28] <mateo`> burek: thx :), so strict gop = gop size fixed + open gop
[11:38] <RT|Chatzilla> michaelni: I wonder if you can tune cone-205's output format. The git rev is missing, and missing separator between fields which is hard to view in colorless situations.
[11:42] <mateo`> can one of our mpegtsenc expert give a look at this trac issue ? http://ffmpeg.org/trac/ffmpeg/ticket/1673
[11:51] <durandal_1707> j-b: what i can find DTS-HD-MA encoder?
[11:51] <j-b> what?
[11:57] <durandal_1707> or wav file of any DTS-MA sample so i can get bitexact decoder?
[11:58] <nevcairiel> search the usual shady places for DTS-HD Master Audio Suite 2.0 :P
[12:06] <Compn> burek : interpol ?
[12:13] <Compn> burek / divVerent : do your govt catch any 'bad guys' or is it all political / riaa-mpaa 'bad guys' ?
[12:13] <Compn> that they sniff on
[12:16] <divVerent> good question... they didn't admit to catch anyone, IIRC
[12:16] <divVerent> because doing that would make people learn to encrypt their data, or the like
[13:00] <burek> Compn, well we did have one raid on child porn guys
[13:00] <burek> that were imposing on social networks as teens
[13:00] <burek> they were all like 40-50 yrs old and stuff
[13:00] <burek> really sick..
[13:01] <burek> but, divVerent has made a good point, which reminds me why I didn't read anything about it in news
[13:02] <av500> usually its in the news to prove the system is working
[13:02] <av500> at least for childprn
[13:03] <av500> what is not in the news is that they caught them via their facebook updates and not extensive data tapping....
[13:07] <divVerent> 13:02:31         +av500 | usually its in the news to prove the system is working                          
[13:07] <divVerent> right, which is why I suppose that the tapping hasn't found anyone yet
[13:07] <divVerent> but, looking through facebook did
[13:08] <divVerent> probably quite simple to explain: those dumb enough to not even try to encrypt such data are dumb enough to talk about it everywhere
[13:10] <burek> what's really ironic is that we've been running a lot of dc++ hubs (file sharing) on our servers and I regularly scanned through the shares of all the people connected, reporting people who shared child porn to the interpol just to find out
[13:11] <burek> that the interpol contacted our upstream isp, asking about my private data, like name, address and stuff..
[13:11] <burek> instead of replying to at least one of my emails, directed to them, they decided that I was the cause of all those issues.. geez..
[13:11] <av500> who is "our"?
[13:12] <burek> so I really doubt interpol has any interest in chasing those kind of people, unless someone influential tells them to do so
[13:12] <burek> our server's upstream isp
[13:12] <av500> no, you said "our servers"
[13:12] <av500> what "entity" is that?
[13:13] <ohsix> finding out if your credible is just due diligence
[13:13] <ohsix> and the most likely narc is kin ...
[13:13] <burek> we have a lot of rented servers throughout the world and on one of those servers I received the notification of our hosters to provide them with my full details and stuff
[13:14] <burek> so I asked them just to give me their phone number so I can call them and let them know whatever they need to know, but they refused that
[13:14] <burek> they were just interested in my identity, don't know why and honestly don't care
[13:14] <burek> but I stopped sending any reports from that moment on
[13:14] <burek> I realized they don't really care that much
[13:32] <Compn> burek : interpol is for stuff like catching dangerous criminal anakata or julian assange
[13:32] <Compn> not your petty crime nonsense!
[13:32] <burek> right
[13:32] Action: Compn curious why burek is hosting dc++ hubs tho
[13:32] <Compn> why are you honeypotting ?
[13:32] <burek> like William Wallace would like to say: freedom :)
[13:39] <Compn> the thing is
[13:39] <Compn> the dc++ clients you reported
[13:39] <Compn> are probably ran by interpol
[13:39] <Compn> catching the downloaders :P
[13:39] <ubitux> siretart: "Version 4:0.5.9-1 uploaded on 2012-09-29" // you're still maintaining an old 0.5 release? (https://launchpad.net/ffmpeg)
[13:39] <Compn> well, thats how it would work
[13:39] <ubitux> or that's libav?
[13:39] <ubitux> or something else?
[13:41] <nevcairiel> ffmpeg in buntu is libav
[13:41] <burek> Compn, probably you're right
[13:42] <ubitux> nevcairiel: yes i know but i'm not sure in this case since the latest release is 0.6
[13:42] <ubitux> it looked like to me like an old ffmpeg or something
[13:43] <Compn> libav didnt exist in .5 /me ducks
[13:43] <Compn> hehe
[13:53] <ubitux> saste: i'll review your -select_streams patch tonight :)
[13:53] <saste> ubitux, thanks
[13:53] <saste> it's very simple, the only thing i'm not really sure is the option name
[13:53] <saste> otherwise i'd have already pushed it ;-)
[13:54] <ubitux> hehe well i like select
[13:54] <ubitux> i thought about "filter" as well
[13:54] <ubitux> or "pick"
[13:54] <ubitux> but select is file
[13:54] <ubitux> fine*
[13:54] <ubitux> specify sounds wrong: you're not asking ffprobe to specify anything
[13:55] <ubitux> you *are* specifying things :P
[13:55] <burek> is there a video filter/source that can create a test video, containing timestamps in the video, so I can use it for some testing?
[13:55] <ubitux> -f lavfi -i testsrc
[13:55] <burek> that simple? :)
[13:55] <ubitux> yep
[13:55] <burek> cool
[13:55] <burek> thx :)
[13:55] <ubitux> that's a pretty great source btw
[13:59] <saste> ubitux: yes, "select" sounds better than "specify", i did the same reasoning
[13:59] <saste> i'll wait you to review anyway, if you want to do some comment
[13:59] <saste> or i'll push tomorrow
[13:59] <ubitux> yes please wait a bit
[14:00] <ubitux> 6 hours of waiting maximum ;)
[14:03] <durandal_1707> is there any paper that describe dtshd format (.dtshd extension) ?
[14:03] <burek> ubitux, ok, I don't want to bug you right now, I know you're busy, just to say that the examples that I put on wiki do work, but for some reasons ffmpeg always fails at first 3 frames, the rest of frames are exactly as expected
[14:04] <ubitux> burek: fill a bug then; and btw, if you're filling a bug, you can use -f lavfi -i testsrc source, so it's easy to reproduce :)
[14:04] <burek> ok :)
[14:06] <ubitux> burek: hey btw, about the thumbnail wiki page, i'd quote various other things like :
[14:06] <ubitux> - the tile filter to make a galery
[14:06] <ubitux> - the scene detection
[14:06] <ubitux> - some vf select + scale in the same filtergraph
[14:06] <burek> durandal_1707, can this help http://www.dts.com/professionals/sound-technologies/codecs/dts-hd-high-resolution-audio.aspx
[14:07] <ubitux> and even better, some images with testsrc so output is shown etc
[14:08] <burek> I see, well tile filter has got its own page I think.. yes http://ffmpeg.org/trac/ffmpeg/wiki/How%20to%20take%20multiple%20screenshots%20to%20an%20image%20(tile%2C%20mosaic)
[14:10] <burek> multimedia.cx is back :)
[14:10] <durandal_1707> i found some draft
[14:10] <ubitux> are you sure it's right to split so much? :)
[14:10] <burek> durandal_1707, wrong link before, did you try http://wiki.multimedia.cx/index.php?title=DTS-HD
[14:11] <burek> ubitux, if you are talking to me, well I've based the wiki articles on people's search queries and questions on the forums and such
[14:11] <durandal_1707> burek: that is for codec......
[14:12] <burek> adapting it for them to easily find what they are looking for, didn't look too much to organize things into bigger pages :)
[14:12] <burek> but you can rearrange if you like :)
[14:12] <burek> durandal_1707 you need it for the format only?
[14:13] <durandal_1707>  /mute burek 
[14:14] <burek> ok :)
[14:14] <ubitux> burek: well at some point it might be good to not split too much and try to give some hints about more things
[14:15] <ubitux> burek: ah also, there is a vf thumbnail filter you might want to quote
[14:15] <burek> ubitux, I've used links to docs wherever I use some filters, specific options and such
[14:15] <ubitux> anyway, one page talking about tile, scene detection, select and thumbnail filter is IMO a good one to have
[14:15] <burek> ok
[14:15] <ubitux> but you're the master there
[14:15] <burek> master of disaster :)
[14:16] <ubitux> just my opinion; but as you just saw on #ffmpeg, the user wasn't aware at all about all these other solutions
[14:16] <ubitux> and he was kind of interested by them
[14:16] <ubitux> having them pointed out in the wiki would have prevent this i believe
[14:16] <burek> i agree
[14:16] <ubitux> anyway, just my remark of the day :)
[14:17] <burek> :beer: :)
[14:17] <ubitux> (ah also, these info are already split into the official documentation, the wiki is here to link all of these to various user needs)
[14:17] Action: ubitux mute himself for now
[14:36] <kierank> durandal_1707: the spec
[14:37] <durandal_1707> kierank: yes?
[14:38] <kierank> i have linked you to it before no?
[14:38] <durandal_1707> i found that ffmpeg chokes on it just recently, so i found it by accidend
[14:51] <ubitux> arh i think i understand why ffserver is broken
[14:52] <ubitux> looks like it's one of the consequence of yet another purification :(
[14:54] <saste> what should be do with ffserver, anyway?
[14:54] <saste> nobody is maintaining it, and "avserv" looks a bit like vaporware
[14:54] <ubitux> well the regression i have seems related to the fact that avformatctx->timestamp was removed
[14:54] <ubitux> (and it seems to break the date= seek system)
[14:55] <ubitux> saste: about avserv i dunno, and avserver is broken out of the box in libav
[14:55] <saste> given that nobody does active development on it, i'm surprised it even works
[14:55] <ubitux> it doesn't
[14:55] <saste> i actively tried not to do development over it, due to the socis task
[14:55] <ubitux> ffserver kind of works though
[14:56] <ubitux> yes, it might be worth trying to get something out of it now
[14:56] <ubitux> i believe it's a pretty nice tool :)
[14:56] <ubitux> and needs way more love
[14:57] <saste> all we need is more love
[14:58] <saste> money is a good surrogate (just put devs at fixing bugs for money) and we lack that as well ;-)
[15:01] <ubitux> :)
[15:06] <cone-429> ffmpeg.git 3Martin Storsjö 7libavformat/segment.c: segment: Add a missing space
[15:06] <cone-429> ffmpeg.git 3Martin Storsjö 7libavformat/segment.c: segment: Properly create new AVStreams for the chained muxer
[15:06] <cone-429> ffmpeg.git 3Michael Niedermayer 7: Merge commit '0edae4e6286096023cdd6adea74722fa06029867'
[15:07] <michaelni> j-b, btw, cone could also display the short git hash of each commit
[15:08] <michaelni> and RT|Chatzilla asked about a seperator between the fields
[15:17] <cone-429> ffmpeg.git 3Martin Storsjö 7libavformat/segment.c: segment: Use the public av_write_header/av_write_trailer functions
[15:17] <cone-429> ffmpeg.git 3Michael Niedermayer 7: Merge commit '73871dc96ff78053b9dcd0eb259b7f5a5308ec87'
[15:31] <nevcairiel> its separated by color =P
[15:51] <cone-429> ffmpeg.git 3Martin Storsjö 7libavformat/segment.c: segment: Free and reinit the muxer before calling avformat_write_header
[15:51] <cone-429> ffmpeg.git 3Michael Niedermayer 7: Merge commit 'eb447d515956b3ce182d9750083131735f00324c'
[16:02] <j-b> michaelni: for the bot?
[16:03] <Compn> j-b : can you remove the 'merge commit' notifications ?
[16:03] <Compn> theres going to be lots of those
[16:04] <saste> Compn: why?, they are regulat commits
[16:04] <saste> *regular
[16:05] <Compn> yeah but its just michael : 'merge commit' : big useless hash number
[16:14] <maker> why don't rebase on merge commits?
[16:15] <michaelni> j-b, yes, short hashes for the bot would allow one to simply copy and paste the hash to the terminal and look at the diff
[16:17] <nevcairiel> in a perfect world, it would spit out a url to the diff :D
[16:18] <nevcairiel> shortened url, that is
[16:19] <maker> ffmp.eg
[16:21] <j-b> michaelni: very well
[16:23] <ubitux> yepee i fixed ffserver
[16:24] <microchip_> \o/
[16:24] <cone-429> ffmpeg.git 3Martin Storsjö 7libavformat/segment.c: segment: Add an option for disabling writing of a header/trailer to each segment
[16:24] <cone-429> ffmpeg.git 3Michael Niedermayer 7: Merge commit '378a6315b7c48195ffd94e6aa9aa6d663d42b35e'
[16:34] <Daemon404> wonder if the bot can ignore merge commits
[16:37] <cone-429> ffmpeg.git 3Martin Storsjö 7libavformat/segment.c: segment: Set the resend_headers flag for each segment
[16:37] <cone-429> ffmpeg.git 3Michael Niedermayer 7: Merge commit 'f7b240434c015056bc6319ddbdb8483757cc13e2'
[16:41] <RT|Chatzilla> nevcairiel: it looks worse in colorless situation (says logs)
[16:42] <cone-429> ffmpeg.git 3Martin Storsjö 7libavformat/segment.c: segment: Flush buffered data before finishing a segment
[16:42] <cone-429> ffmpeg.git 3Michael Niedermayer 7: Merge commit 'a854362b40f0e458db5a1fb0d2612a5702ee0ace'
[16:43] <RT|Chatzilla> I'd say the old CIA, or libav's ICIA format is better.
[16:46] <ubitux> and now fixed properly \o/
[16:47] <microchip_> commit!
[16:49] <ubitux> no, i'll first show the world my awesome patch
[16:49] <ubitux> and now the world is aware.
[16:50] <mateo`> beware !
[16:55] <ubitux> :)
[16:57] <cone-429> ffmpeg.git 3Martin Storsjö 7libavformat/segment.c: segment: Add an option for omitting the first header and final trailer
[16:57] <cone-429> ffmpeg.git 3Martin Storsjö 7libavformat/segment.c: segment: Add comments about calls that only are relevant for some muxers
[16:57] <cone-429> ffmpeg.git 3Diego Biurrun 7configure libavcodec/Makefile: build: Factor out mpegaudio dependencies to CONFIG_MPEGAUDIO
[16:57] <cone-429> ffmpeg.git 3Diego Biurrun 7libavutil/x86/cpu.c: x86: ff_get_cpu_flags_x86(): Avoid a pointless variable indirection
[16:57] <cone-429> ffmpeg.git 3Diego Biurrun 7libavutil/x86/cpu.c: x86: cpu: Break out test for cpuid capabilities into separate function
[16:57] <cone-429> ffmpeg.git 3Mans Rullgard 7configure: configure: add --enable-lto option
[16:57] <cone-429> ffmpeg.git 3Michael Niedermayer 7: Merge commit '65d12900432ac880d764edbbd36818431484a76e'
[17:08] <cone-429> ffmpeg.git 3Diego Biurrun 7libavutil/x86/Makefile libavutil/x86/cpu.c libavutil/x86/cpu.h libavutil/x86/cpuid.asm: x86: Add YASM implementations of cpuid and xgetbv from x264
[17:08] <cone-429> ffmpeg.git 3Diego Biurrun 7configure libavutil/x86/cpu.c: x86: Drop CPU detection intrinsics
[17:08] <cone-429> ffmpeg.git 3Diego Biurrun 7libavutil/x86/cpu.c: x86: get_cpu_flags: add necessary ifdefs around function body
[17:08] <cone-429> ffmpeg.git 3Ronald S. Bultje 7libavcodec/h264_cabac.c libavcodec/h264_cavlc.c: h264: don't touch H264Context->ref_count[] during MB decoding
[17:08] <cone-429> ffmpeg.git 3Michael Niedermayer 7: Merge remote-tracking branch 'qatar/master'
[17:13] <Daemon404> michaelni, whats with all the merge commit <hash> lately
[17:13] <Daemon404> instead of a branch
[17:14] <ubitux> maybe they are left over commits
[17:14] <ubitux> which are hard to merge, or delayed for various reasons
[17:14] <RT|Chatzilla> Daemon404: it shows repo, not branch ;)
[17:14] <Daemon404> but theyre not
[17:14] <Daemon404> technically, i dont think git cares which it is
[17:15] <Daemon404> functionally
[17:31] <nevcairiel> RT|Chatzilla: it really shows both, repo/branch :P
[17:32] <RT|Chatzilla> nevcairiel: but I didn't see "master" string in its lines ...?
[17:33] <nevcairiel> ffmpeg.git Michael Niedermayer : Merge remote-tracking branch 'qatar/master'
[17:33] <nevcairiel> i see it!
[17:34] <RT|Chatzilla> oops ;)
[17:54] <gix> Daemon404: c99conv doesn't pull variables up to the beginning of the enclosing block, does it?
[17:55] <Daemon404> no it doesnt
[17:55] <Daemon404> because libav doesnt used mix code / var decls
[17:55] <Daemon404> nor does ffmpeg
[17:56] <Daemon404> it's a Future (TM) item
[17:56] <Daemon404> (and i personally think it is bad software dev practice)
[17:56] <gix> well, rmdec.c doesn't compile here because of that (lines 372+)
[17:56] <Daemon404> is this a new change?
[17:56] <Daemon404> fate should have caught it if so
[17:57] <Daemon404> last msvc build was 94 min ago
[17:59] <gix> let me check
[18:03] <Daemon404> gix, 
[18:03] <Daemon404>         if ((ret = rm_read_extradata(pb, st->codec, codec_data_size - (avio_tell(pb) - codec_pos))) < 0)
[18:04] <Daemon404> ^ line 372
[18:04] <Daemon404> i dont see mixed code/vardecl
[18:06] <gix> Daemon404: yeah, false alarm. was in another branch.
[18:10] <Daemon404> ah
[18:11] <cone-429> ffmpeg.git 3Giorgio Vazzana 7libavformat/oggparsetheora.c: oggparsetheora: fix comment header parsing
[18:21] Action: TimNich off for the weekend ...............
[18:22] <Daemon404> s/ \.+$/./
[18:31] <ubitux> saste: btw, forgot to ask in the mail, what happens if you try to filter non-existing things? (like filtering only video in an audio file)
[18:33] <saste> ubitux: nothing
[18:33] <ubitux> will the output always make sense?
[18:34] <saste> you could have empty output
[18:34] <saste> for example -select_streams v in only audio, will result in no output
[18:34] <saste> which is expected
[18:35] <ubitux> as long as it's not broken.. :)
[18:35] <ubitux> such as stuff like {"streams": {, }} or stuff like that
[18:51] <saste> lemme try
[18:51] <saste> in that case it would be an unrelated bug
[19:10] <saste> ubitux: looks correct
[19:10] <saste> you have an empty array, as expected
[19:11] <ubitux> ok ok great :)
[19:11] <ubitux> sorry for the bother then ;)
[19:12] <saste> http://paste.org/55070
[19:14] <ubitux> looks fine; it's funny how the output are mixed
[19:22] <saste> ubitux: how?
[19:23] <ubitux> opening '{', then the av_dump_info thing, then the rest :p
[19:23] <ubitux> mixed stderr/stdout i guess
[19:24] <saste> ah yes, nothing i can do about it
[19:24] <ubitux> sure :)
[19:24] <saste> that's because we open the container before to open the file
[19:24] <saste> in case we need to print versioning info
[19:24] <ubitux> yup ok :)
[19:25] <cone-429> ffmpeg.git 3Paul B Mahol 7configure: configure: dts demuxer needs dca_parser
[19:26] <ubitux> saste: btw, when will we have meta info communication between filters?
[19:27] <saste> well i'm slacking off
[19:27] <ubitux> i'd like to work on a beat and pitch audio detection filter, but i think it will make sense only with this
[19:27] <saste> did i already point you to the thomas repo?
[19:27] <ubitux> it's kind of frustrating to have to print stuff in detect-like filters :p
[19:27] <saste> he already implemented that (and it is pretty simple)
[19:27] <ubitux> mmh possibly, but i don't remember
[19:47] <ubitux> hey nyuhu, how is eq filter going on? :)
[20:13] <cone-429> ffmpeg.git 3Carl Eugen Hoyos 7configure: Fix showspectrum dependencies: Add rdft.
[21:04] <cone-429> ffmpeg.git 3Carl Eugen Hoyos 7libavfilter/libmpcodecs/vf_pullup.c: Do not print debug output for the (MPlayer) pullup filter.
[21:45] <cone-429> ffmpeg.git 3Carl Eugen Hoyos 7configure: Fix libcdio detection.
[22:35] <Daemon404> arg
[22:35] <Daemon404> ffplay -> plays in sync
[22:35] <Daemon404> ffmpeg -i input.mp4 out.avi
[22:35] <Daemon404> ffplay out.avi
[22:35] <Daemon404> 20 seconds off
[22:35] <Daemon404> no warnings, no errors
[22:38] <llogan> Daemon404: any info with increased verbosity?
[22:40] <Daemon404> no.
[22:40] <Daemon404> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x1e88340] multiple edit list entries, a/v desync might occur, patch welcome
[22:40] <Daemon404> fuck yeah
[23:12] <ubitux> yay vobsub demuxer starts to work.
[00:00] --- Sat Oct  6 2012