[FFmpeg-devel-irc] IRC log for 2010-04-15

irc at mansr.com irc at mansr.com
Fri Apr 16 02:00:12 CEST 2010

[00:00:53] <BastyCDGS> anyway, even if not, if we're using sse then we should also use march=pentium3 since pentium 3 is required as mininum anyway
[00:01:12] <BastyCDGS> and thus allows gcc to use other stuff which is non-sse specific in the p3
[00:06:55] <BastyCDGS> lol
[00:06:58] <BastyCDGS> according to:
[00:07:01] <BastyCDGS> http://gcc.gnu.org/ml/gcc/2002-12/msg00235.html
[00:07:18] <BastyCDGS> -march=pentium3 equals exactly -mcpu=i686 -msse
[00:07:44] <BastyCDGS> mcpu == march
[00:08:42] <BastyCDGS> although the reply post states it isn't the same, more like that what I stated above
[00:09:11] <BastyCDGS> i.e. msse just enables sse instruction set and doesn't force normal p3 instruction set automatically
[03:36:09] <ramiro> j-b: my fault, patch awaiting at "[PATCH] Fix function parameters for rgb48 to YV12 functions."
[03:36:27] <ramiro> too busy/lazy to do anything about it. I'm currently patching my 64-bit builds for this.
[05:45:35] <_av500_> http://newteevee.com/2010/04/14/did-google-just-kill-ogg-theora/
[05:45:56] <_av500_> kshishkov: SCNR
[05:46:45] <kshishkov> that site seeks dubious fame
[05:47:05] <kshishkov> please tell me when they post something about DN Forever
[05:53:21] <superdump> mornin
[05:53:24] <superdump> g
[06:48:18] <KotH> salut mes enfants
[06:48:46] <kshishkov> shalom, goyim
[07:00:44] <Tjoppen> hej barn
[07:01:43] <kshishkov> hej hej
[07:02:26] * kshishkov kan få ungdombiljett
[07:02:59] <scaphilo> good morning
[07:03:06] <kshishkov> if you say so
[07:03:16] <thresh> well it is simply not true.
[07:03:34] <scaphilo> my openloop transcoder works quite fine now :-)
[07:03:38] <jai> thresh: fell of the bike again? ;)
[07:03:43] <scaphilo> not perfect yet
[07:04:02] <scaphilo> :-) what bike
[07:04:09] <thresh> jai: no. no morning can be good.
[07:04:31] <thresh> though i'm still in pain
[07:04:34] <scaphilo> anyway good (GMT)morning
[07:07:08] <KotH> thresh: pain?
[07:07:24] <thresh> KotH: http://fear999.users.photofile.ru/photo/fear999/150396127/159361076.jpg
[07:07:28] <KotH> scaphilo: good (CEST) morning to you too
[07:07:30] <thresh> that's me.
[07:08:05] <kshishkov> at least bike seems to be not harmed
[07:08:10] <KotH> someone is throwing a bike at you, while you're sleeping on the ground?
[07:08:15] <KotH> how mean!
[07:08:20] <thresh> i stopped there to pick up a coin.
[07:08:22] <scaphilo> :-)
[07:08:27] <jai> thresh: ah :|
[07:08:45] <thresh> and what more cool is I have a video of that accident from my helmet cam :)
[07:08:49] <KotH> thresh: i hope no major injuries?
[07:08:54] <jai> that's the one i saw
[07:08:57] <jai> epic
[07:09:34] <jai> meh
[07:09:39] <thresh> KotH: just a tension in a wrist plus some abrasions on my knees.
[07:09:56] <thresh> and a broken helmet visor
[07:10:16] <KotH> hmm.. the visor is the only thing that wont fully heal...
[07:10:26] <scaphilo> may i transcode you video plz
[07:10:42] <kshishkov> KotH: in Russia people can be replaced
[07:10:51] <kshishkov> visors can't though
[07:12:20] <scaphilo> http://www.hirnfick.to/Videos/2135/schlag_den_raab__mountainbike_unfall.html
[07:12:28] <KotH> be glad that you're not in china, where people are expendable materials
[07:12:50] <kshishkov> KotH: no big difference
[07:17:10] <scaphilo> is there a good video analysing tool? where i can step thorugh the vidio frame by frame?
[07:17:24] <scaphilo> not i frame by i frame
[07:17:50] <KotH> yes, mplayer
[07:17:53] <kshishkov> xanim could
[07:18:03] <jai> scaphilo: ffplay, s
[07:18:10] <thresh> vlc also can do that
[07:18:39] <scaphilo> oh ok thx
[07:18:49] <KotH> alternatively, you can decode the video into raw bitmap pics, and step trough these
[07:29:12] <scaphilo> thresh: how would you do that with vlc?
[07:58:19] <j-b> ramiro: bad ramiro :)
[08:27:56] <CIA-81> ffmpeg: gb * r22883 /trunk/libavcodec/h264.c: H.264: move avctx->refs init before AVCodecContext.get_format().
[08:31:36] <CIA-81> ffmpeg: gb * r22884 /trunk/libavcodec/h264.c: H.264: move avctx->{profile,level} init before AVCodecContext.get_format().
[08:47:26] <j-b> scaphilo: 'e' hotkey
[08:48:18] <scaphilo> j-b:thx very much :-)
[09:18:57] <lu_zero> wbs: ping
[09:19:11] <wbs> lu_zero: pong
[09:32:18] <lu_zero> wbs: diego couldn't reproduce your issue with quicktime
[09:33:03] <wbs> lu_zero: hmm, the tcp interleaving thing? sure that his quicktime actually tried the interleaved mode?
[09:33:25] <lu_zero> he put it in http tunnel mode
[09:33:34] <lu_zero> at least he's quite sure about it
[09:34:17] <wbs> ok... it would be interesting to get a packet capture of that one, to see whether the qt player manually specified the interleaving channel ids in that case
[09:35:23] <lu_zero> once he got his house wired back hopefully we could ask directly to him ^^
[09:37:06] <lu_zero> btw, do you have knowledge of the dss sources?
[09:37:24] <lu_zero> I'm trying to fix the rtp_port naivety but I'm out of sane ideas
[09:37:33] <wbs> what naivety is that?
[09:42:57] <lu_zero> wbs: basically it does some kind if bookkeeping but assumes all the ports are dedicated to the application
[09:43:10] <lu_zero> thing that could be far from true
[09:44:18] <lu_zero> the simplest way to solve that case is to preallocate them and do actual bookkeeping on that
[09:45:39] <wbs> ok, so what's the actual problem scenario?
[09:46:23] <lu_zero> thing about somebody using the streaming server and other servers
[09:46:53] <lu_zero> both servers bind with reuse the same udp port and you get a clash
[09:47:17] <wbs> ah, I see..
[09:48:25] <lu_zero> so I'm trying to figure out what the others were doing to address that issue
[09:48:57] <wbs> on that note, btw, it would be good to make lavf/rtsp start from some random port, since it otherwise uses the same client port each time. and if repeatedly connecting to dss to watch something, then stopping, and starting a new stream, dss might not have noticed that the old stream has stopped
[09:49:13] <wbs> so the client receives rtp packets from both the old and the new stream at once, which doesn't work too well
[09:50:06] <lu_zero> that is a similar issue
[09:50:15] <wbs> yeah
[09:50:36] <wbs> but as an answer to your question, no, i'm not familiar with the dss code at that level so I can't really say what they do or don't do
[09:51:17] <lu_zero> you'd be more annoyed to have a pool of udp ports allocated for future usage
[09:51:35] <wbs> yeah, that's no good solution either
[09:53:50] * lu_zero is thinking about binding at will and just hope the clients support rfc3605 ...
[09:53:57] <lu_zero> that is the cleanest solution
[09:55:41] <wbs> so you'd try to bind one port for each of rtp and rtcp, but disregard the normal assumption that they should be consecutive and the rtp one be even?
[09:57:00] <lu_zero> that would make the server simpler but requires the client to support it
[09:57:12] <lu_zero> yet that rfc seems quite sip oriented
[09:58:38] <lu_zero> I'm quite out of sane ideas on how to fix sanely this issue
[09:59:45] <wbs> would it be possible to first try the whole range for available rtp+rtcp ports in the normal fashion, and only revert to mismatched ports requiring that rfc if there are no free n,n+1 ports available?
[10:00:17] <wbs> that is, if some odd port happens to be in use, you'd still get normal port numbers for everything else, as long as they're not totally exhausted?
[10:06:33] <lu_zero> uhmmm
[10:20:26] <lu_zero> rfc3550 chapter 11 frees me =E
[10:24:26] * lu_zero now changes ffmpeg and feng accordingly
[10:51:32] <wbs> what conclusion did you get from that chapter, and what are you going to do?
[10:53:39] <lu_zero> rtpproto will have rtp and rtcp local port as parameters
[10:54:07] <lu_zero> if you set none two random port will be bound
[10:54:53] <lu_zero> if you set rtp alone it will try to bind that port and port+1 as now
[10:55:08] <lu_zero> if you set both it will try to bind accordingly
[10:55:24] <wbs> ah, that sounds reasonable
[10:57:04] <lu_zero> yup
[10:57:29] <lu_zero> hopefully
[12:36:35] <j-b> lu_zero: if I pass "rtsp://" to url_open, it doesn't seem to open it. Any idea why?
[12:43:29] <wbs> j-b: rtsp is a muxer/demuxer, not an urlprotocol, so you need to open a full demuxer with av_open_input_file
[12:43:58] <wbs> and since it has the AVFMT_NOFILE, you're not supposed to open the ByteIOContext yourself, since the muxer does that itself internally
[12:45:18] <j-b> hmm, that might explain :)
[12:46:16] <j-b> wbs: thanks.
[13:13:56] <bilboed-pi> __gb__, ping
[13:17:30] <__gb__> pong bilboed-pi
[13:17:42] <CIA-81> ffmpeg: gb * r22885 /trunk/libavcodec/h264.c: H.264: cosmetics (vertical align).
[13:17:55] <bilboed-pi> __gb__, is there a software-only backend for vaapi ?
[13:19:06] <bilboed-pi> __gb__, so one can test vaapi frontends without having a compatible card (or driver)
[13:19:07] <__gb__> bilboed-pi, no, but this is something I would liked to have (at least for testing the encoding stuff without HW)
[13:19:20] <bilboed-pi> ok
[13:19:45] <__gb__> someone could write it thoug, something like what bellagio is for openmax
[13:19:57] * bilboed-pi pukes at mention of bellagio
[13:20:00] <bilboed-pi> thx
[13:22:36] <__gb__> on the other hand, VA-API normally supports a large set of desktop GPUs nowadays :)
[13:23:44] <bilboed-pi> is there a document/site listing all supported backends/gpus ?
[13:24:56] <__gb__> http://www.freedesktop.org/wiki/Software/vaapi -- the SW users list is not up-to-date though
[13:25:34] <__gb__> if you think it needs more details, just tell, thanks
[13:26:35] <__gb__> hopefully, 3 more drivers would come in a few months
[13:29:15] <Compn> http://samples.mplayerhq.hu/V-codecs/mj2c.avi
[13:29:27] <Compn> there, an avi jpeg2000 sample :P
[13:31:03] <CIA-81> ffmpeg: rbultje * r22886 /trunk/libavformat/rtpdec_xiph.c:
[13:31:03] <CIA-81> ffmpeg: Remove useless assert(), since this can (in theora) be used for any Xiph
[13:31:03] <CIA-81> ffmpeg: codec, so there's no reason to (invalidly) limit it to only Theora.
[13:31:03] <CIA-81> ffmpeg: Also fixes issue 1880 (assert triggers on -DDEBUG + Vorbis).
[13:36:45] <bilboed-pi> __gb__, ok, thx
[13:48:50] <lu_zero> wbs: how did you manage to have dss get confused about opened rtp ports?
[13:50:37] <wbs> lu_zero: it doesn't always notice that the client has disconnecting, so it keeps sending rtp packets to the port pairs for some time afterwards... so if I connect to the same server from the same client again, and the client uses the same port numbers as the previous attempt, I get the packets belonging to the previous session, too
[13:50:55] <lu_zero> uhmm
[13:51:09] <lu_zero> I'm not sure how I could fix that
[13:51:39] <lu_zero> and after I'm finished with this probably we'll need to check how many incompatible server would break
[13:51:52] <wbs> no, neither do i :-) one band-aid fix would be to make lavf choose a start port randomly, so it doesn't always start using the same port
[13:52:52] <lu_zero> as standard rtsp server I'm considering dss feng google and gst
[13:53:07] <lu_zero> I'm missing others?
[13:53:35] <wbs> what's the google rtsp server based on? weren't they using dss/qtss earlier? or is it derived from that one?
[13:55:26] <lu_zero> wbs: did not investigate much
[13:55:31] <lu_zero> it seems quite standard
[14:45:24] <lu_zero> wbs: ok, now I need some public servers =}
[14:46:17] <lu_zero> dss pukes on rfc3550 =_=
[14:47:47] <lu_zero> or not?
[14:50:57] <lu_zero> http://pastie.org/921333 pukes indeed...
[16:34:17] * elenril facepalms
[16:34:26] <kshishkov> good greeting
[16:34:36] <elenril> hey kshishkov
[16:34:55] <elenril> answer me - why are people putting config files under /usr/
[16:35:14] <kshishkov> it's user data?
[16:35:15] <elenril> and where can i get some of the stuff they're smoking
[16:35:42] <kshishkov> some people thought that --enable-shared was to compile _redistributable_ version of FFmpeg
[16:36:48] <elenril> non sequitur?
[16:37:45] <kshishkov> RTFM
[16:41:57] <Kovensky> <+elenril> answer me - why are people putting config files under /usr/ <-- kdm does it, it must be good rite
[16:42:05] <elenril> wut
[16:42:14] <elenril> it didn't last time i used it
[16:42:38] <elenril> srsly what's WRONG with freedesktop people
[16:43:18] <kshishkov> ask gb
[16:44:23] <Kovensky> elenril: /usr/share/config/kdm/kdmrc
[16:44:42] <elenril> o_0
[16:46:25] <Kovensky> there are a lot of kde files there actually
[16:46:47] <Kovensky> @ /usr/share/config
[16:47:58] * kshishkov checks his notes for "KDE sucks" entry and finds a lot of duplicates
[16:48:02] * elenril doesn't even have a /usr/share/config
[16:49:56] * Kovensky wonders how many "Gnome sucks" entries are in those notes
[16:50:22] <kshishkov> maybe 1/4th of "KDE sucks" notes
[16:50:45] <kshishkov> Motif in Ubuntu sucks too
[16:51:38] <pJok> /etc wasn't good enough for some people
[16:52:12] <thresh> well you can put read-only 'default' stuff into usr
[16:52:15] <pJok> /opt was also silly
[16:53:00] <pJok> oh and /usr/local/etc
[16:53:59] <elenril> thresh: yeah, they say those aren't really config files
[16:54:22] <elenril> for some reason i think it's BS
[16:54:26] <thresh> you may as well say ffpresets are configs :-)
[16:54:33] <thresh> as they really are
[16:55:20] <elenril> no they're not?
[17:18:00] <BBB> dgt84: do you want to do another blind test, same as last time?
[17:18:53] <dgt84> BBB, sure, though I'm not sure how Michael played both files at the same time, one in each ear to hear differences between the two
[17:19:02] <BBB> I'd like to know that also
[17:23:39] <Kovensky> o_O
[17:34:53] <dgt84> BBB, you can load both files into Audacity and then set one to be 100% left and the other to be 100% right
[17:35:02] <DonDiego> elenril: /usr/local/etc/ is a standard location for config files
[17:37:22] <elenril> DonDiego: i was talking about /usr/lib/X11/xorg.conf.d/
[17:37:51] * elenril wonders where to get docs for quartz.dll
[17:38:43] <kshishkov> sounds like VfW API
[17:38:52] <elenril> yeah
[17:38:59] <BBB> dgt84: ok, so what's your impression?
[17:39:02] <kshishkov> I use mplayer/loader/vfw for it :)
[17:39:15] <elenril> kshishkov: i'm hacking wine
[17:39:31] <elenril> want to get videos to work in R11
[17:39:46] <kierank> no
[17:43:31] <BBB> dgt84: I don't hear much of a difference tbh
[17:45:09] <dgt84> BBB, yeah I'm trying really hard here but am having a lot of trouble hearing much difference between any of the files...
[17:46:03] <BBB> ok, well, at least my patch doesn't make it worse anymore then
[17:46:07] <BBB> maybe the input quality is too good
[17:46:08] <dgt84> If I had to guess I'd say r3 sounds worst to me
[17:46:11] <BBB> it's postfilter after all
[17:46:49] <BBB> 3 is the one without postfilter, so now the result becomes good then...
[17:46:50] * BBB happy
[17:47:15] <dgt84> yeah that's about the best I can say at this point - will mail the list
[17:47:59] <dgt84> I should note the office is quite noisy here and I have fairly cheap headphones, so maybe a real audiophile is what you need ;-)
[17:48:13] <kshishkov> noooooo
[17:48:32] * Kovensky queries one of the audiofags he knows
[17:48:35] <BBB> well there is one
[17:48:39] <BBB> kshishkov: go go go!
[17:48:41] <BBB> test please
[17:48:41] <BBB> thanks
[17:48:48] <BBB> kthx!!1one
[17:49:16] <kshishkov> well, my current DSP is too noisy by itself
[17:49:20] <elenril> anyone got directx sdk installed?
[17:50:01] <BBB> kshishkov: oh ome on you've gotten lazy ;)
[17:50:38] <kshishkov> BBB: I'm also original ffaacenc author, so I refrain from testing audio quality now
[17:50:50] <kshishkov> and I'm always lazy
[17:50:53] <BBB> haha that explains
[17:51:03] * pJok blames kshishkov for all the bad in the world
[17:51:23] <pJok> you can take it, its less than you are used to seeing you live in ukraine ;)
[17:51:28] * kshishkov balmes Denmark
[17:52:01] <kshishkov> good typo
[18:18:19] <BBB> ** Unknown command `@headitem' (left as is) (l. 225)
[18:18:32] <BBB> is that normal? or is my htmlgen thing too old?
[18:18:49] <kshishkov> look at the output
[18:18:55] <kshishkov> probably it's too old
[18:23:02] * BBB wants his qcelp postfilter patch in
[18:23:03] <BBB> htmnl
[18:23:15] <BBB> that was an interesting typo
[18:23:26] * kshishkov wants WVP2 support patch in
[18:23:44] * mru wants a pony
[18:24:18] * kshishkov has Dalahärs
[18:27:13] <mru> häst
[18:27:25] <kshishkov> sorry
[18:27:43] <kshishkov> still better than a pony
[18:28:27] <CIA-81> ffmpeg: rbultje * r22887 /trunk/libavformat/ (rtsp.c network.h):
[18:28:27] <CIA-81> ffmpeg: Fix compile error on cygwin where ETIME is missing (because it's a WSA error).
[18:28:27] <CIA-81> ffmpeg: This patch also changes FF_NETERROR() to be an AVERROR(), i.e. it is always
[18:28:27] <CIA-81> ffmpeg: negative, whereas it was previously positive.
[18:47:17] <BBB> kshishkov: did you contact sumit regarding his soc project?
[18:47:28] <kshishkov> no
[18:47:39] <BBB> could you please? otherwise I'll move him to the "no" part of the list
[18:47:51] <kshishkov> why can't you do that?
[18:47:55] <BBB> I already did
[18:47:58] <BBB> he didn't respond ;)
[18:48:06] <BBB> I was hoping he'd listen to you since he wants you to be his mentor
[18:48:14] <kshishkov> unlikely
[18:48:19] <mru> then he's out imo
[18:48:21] <BBB> ok, so no then?
[18:48:26] <kshishkov> anyway, I'll be offline till Tuesday
[18:49:25] <Kovensky> kshishkov: what happen
[18:49:40] <kshishkov> Kovensky: countryside
[18:49:49] <Kovensky> oic
[18:50:04] <Kovensky> have fun :>
[18:50:12] <kshishkov> I definitely won't
[18:50:19] <Kovensky> lol
[18:50:24] <Kovensky> then why are you doing this :P
[18:50:52] * mru is reminded of torchwood episode titled "countrycide"
[18:50:52] <kshishkov> some things are done without consent of all people involved
[18:51:35] <kshishkov> mru: wanna compare Swedish and Ukrainian countryside?
[18:52:03] <mru> no
[18:52:13] <kshishkov> neither do I
[18:52:30] <mru> but you're in a position to do so
[18:52:39] <mru> you've at least traveled through some swedish countryside
[18:52:47] <kshishkov> it was even worse last year when I got there one day after I just returned from Stockholm
[19:00:10] <thresh> yeah ukrainian countryside is even worser than russian one
[19:00:26] <kshishkov> at least some people are working there
[19:01:35] <thresh> i would enjoy living outside a big city oh wait i already do
[19:02:02] <mru> living _in_ a small city is much better than living _outside_ a big one
[19:02:26] <mru> I've never lived in a big city so I can't compare that
[19:02:31] <kshishkov> what about living in rather rural area _inside_ big city?
[19:02:41] <mru> we don't have that over here
[19:02:44] <thresh> guess it really depends on a country
[19:02:47] <mru> well, there's Hyde park
[19:03:11] <thresh> there's no life outside Moscow here
[19:03:26] <kshishkov> and St. Putinsburg
[19:03:27] <thresh> only forests, oil and snow.
[19:04:26] <kshishkov> and undead villages where people drink samogon
[19:04:36] <kshishkov> and vote for Edinaya Rossiya
[19:05:10] <thresh> yes, villages nearby oil rigs.
[19:05:37] <mru> are those the lone lights you see if you fly over siberia at night?
[19:06:30] <thresh> those could also be fires from GULAG burning dissidents.
[19:06:51] <kshishkov> or villas of oil rig owners
[19:08:47] <kshishkov> but some Moscow scientists believe that there's some life outside MKAD
[19:09:39] <thresh> i've heard british scientists are helping them, too.
[19:09:39] <kshishkov> maybe even intelligent life
[19:15:50] <Kovensky> http://feedproxy.google.com/~r/ConfusedOfCalcutta/~3/Hg9qIrc9whA/ lolcopyright
[20:56:26] <ubitux> hi
[20:57:34] <BBB> hi
[21:00:21] <merbanan> hi
[21:01:51] <Kovensky> lo
[22:53:50] <j-b> ramiro :         cmp        %r8d, %rax
[22:53:55] <j-b> this is what fails
[23:02:02] <Compn> `-absf bitstream_filter'
[23:02:03] <Compn> Bitstream filters available are "dump_extra", "remove_extra", "noise", "mp3comp", "mp3decomp".
[23:02:16] <Compn> are those the only bsfs available?
[23:06:26] <bcoudurier> hey
[23:06:45] <Compn> a non automated greeting from bcoudurier, nice
[23:06:47] <Compn> :)
[23:08:39] <janneg> or he just changed the greeting in the script
[23:11:05] <Dark_Shikari> could be, we'll figure out soon enough
[23:11:07] <Dark_Shikari> or he made it rotating

More information about the FFmpeg-devel-irc mailing list