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

Fri Feb 5 01:00:42 CET 2010

[00:00:38] <CIA-17> ffmpeg: michael * r21633 /trunk/libavformat/utils.c:
[00:00:38] <CIA-17> ffmpeg: Dont try generic seek if seek request before first index entry and backward.
[00:00:38] <CIA-17> ffmpeg: Fixes issue1275
[00:25:07] <saste> kovensky: yes that's an option
[00:25:22] <saste> they're function are mainly useful for testing
[00:25:41] <saste> not that there is a real performance need for keeping them inline
[00:26:16] <saste> anyway I remember that iirc michael and mans say something about to make intreadwrite public
[00:26:25] <saste> or maybe it was another file...
[00:28:34] * Kovensky pokes mru with ^
[01:55:13] <CIA-17> ffmpeg: michael * r21634 /trunk/ffplay.c:
[01:55:13] <CIA-17> ffmpeg: autoexit
[01:55:13] <CIA-17> ffmpeg: implements issue1019
[07:31:37] <Dark_Shikari> hah at michael
[07:31:38] <Dark_Shikari> ENoTimeForReviewingFuckingCosmeticBikeshedPatches
[07:32:16] <kshishkov> why, good error code
[07:43:36] <benoit-> dobroe utro
[07:43:47] <kshishkov> shalom
[07:43:58] <Dark_Shikari> guten tag
[07:46:09] <kshishkov> FFmpegãƒãƒ£ãƒ³ã‚¨ãƒ«ã‘ã©ã€ãŠæ—©ã†
[07:46:57] * elenril wonders since when kshishkov knows moonspeak
[07:47:17] <kshishkov> uhm, three years maybe
[07:47:24] <elenril> o_0
[07:47:47] <kshishkov> I know even more exotic language - Ukrainian. It's so rare even in Ukraine.
[07:48:39] * elenril thought ukrainian was getting more popular lately
[07:48:48] <kshishkov> where?
[07:48:55] <elenril> in ukraine?
[07:49:27] <thresh> no, not choosing between stupid politicians is popular there
[07:49:29] <kshishkov> with one of major political parties being people who loathe Ukrainian and can't speak even proper Russian?
[07:49:44] <kshishkov> thresh: at least it's choosing
[07:49:49] <astrange> ah, that's ãŠã¯ã‚ˆã† not ãŠã¯ã‚„ã†
[07:50:41] <kshishkov> yep, a bit ambiguous
[07:51:27] <kshishkov> like ã“ã‚“ã«ã¡ã¯ and ä»Šæ—¥ã¯
[08:48:57] <elenril> siretart: ping
[09:46:09] <kshishkov> mate!
[09:47:31] <pross-au> Evening
[09:53:33] <kierank> are there any formats which pass a lot of metadata back?
[09:53:54] <kshishkov> a lot?
[09:54:21] <kshishkov> probably any format with not-so-bounded metadata
[09:54:33] <kshishkov> i.e. anything with ID3 or APE tags
[09:54:56] <kshishkov> RIFF, Matroska, MOV/MP4
[09:55:39] <kierank> ...because in dolby e the metadata is as important as the audio because it tells the final ac3 encoder how to encode
[09:56:04] <kshishkov> sounds dubious
[09:58:54] <superdump> seems to be the way dolby work
[09:59:36] <superdump> but then dolby E is about distribution of multi-channel audio in two channels
[09:59:37] <pross-au> .nfo?
[10:00:03] <kierank> some nice ascii-art to go with it
[10:00:42] <superdump> kierank: what information is in this metadata exactly?
[10:01:05] <superdump> i mean, why doesn't it just decode 2 channels and spit out N channels?
[10:01:17] <superdump> what more is needed to be passed to the encoder?
[10:01:18] <Dark_Shikari> because it's dolby
[10:02:19] <kierank> stuff like dialogue normalisation and dynamic range compression
[10:02:31] <kierank> and dolby surround flags
[10:03:05] <iive> kierank: this doesn't sound like metadata...
[10:03:35] <Yuvi> how / where is this stored?
[10:03:37] <kierank> it's not metadata like artist/album if that's what you mean iive
[10:03:48] <kierank> Yuvi, in a header before the audio
[10:04:05] <Yuvi> container header or codec stream header?
[10:04:20] <kierank> codec stream
[10:04:24] <jez9999> if i want to pass a list of variable size into ffmpeg via the public API, what's the standard way you guys do things?  a linked list?
[10:04:32] <jez9999> are there any examples?
[10:04:42] <Yuvi> isn't it just part of the codec data then?
[10:04:55] <kierank> Yuvi: the idea being you can move from a playout server in mxf to a satellite stream etc
[10:05:16] <iive> kierank: meta data, is data about the data. while the stuff you pointed out, is part of the decoding, that could be skipped, ignored or exported.
[10:05:40] <kierank> nope: that is data about how the encoder at the end of the chain can choose to encode it
[10:06:06] <kierank> that stuff is data about the data
[10:06:44] <kierank> anyways I can use AVmetadata but just store things as chars
[10:06:53] <iive> oh, you don't have ac3 yet.
[10:07:21] <iive> no, it's more like 1'st pass log file.
[10:25:45] <iive> i think that the right term is hint data.
[10:35:22] <jez9999> if i want to pass a list of variable size into ffmpeg via the public API, what's the standard way you guys do things?  a linked list?
[10:35:23] <jez9999> are there any examples?
[10:35:47] <kshishkov> array + length?
[10:36:22] <kshishkov> it mostly depends on what and where you intend to feed
[10:36:35] <jez9999> a list of sockaddr's
[10:37:41] <jez9999> ie. structs
[10:38:09] <pross-au> i hope you mean sockaddr_storage
[10:38:28] <av500> in xml char string?
[10:38:31] <av500> :)
[10:40:55] <jez9999> pross-au: ... which is ffmpeg's non-POSIX sort of hacky way of storing a sockaddr?
[10:41:18] <pross-au> sockaddr_storage is the POSIX way
[10:41:27] <pross-au> for ipv4 and ipv6 (and others)
[10:42:05] <pross-au> i am not sure we expose any of the POSIX data structures in the public libav API though
[10:42:43] <jez9999> hmm
[10:42:48] <jez9999> i thought that was what sockaddr was for
[10:43:02] <jez9999> so that _in and _in6 could fit into it
[10:43:35] <twnqx> load really
[10:44:39] <jez9999> load?
[10:45:19] <twnqx> gah... "not really"
[10:45:33] <pross-au> sockaddr isn't guaranteed to be big enough for ipv6
[10:45:40] <pross-au> hence sockaddr_storage
[10:45:54] <twnqx> sockaddr is guaranteed to be big enough to identify the protocol, right?
[10:46:08] <twnqx> so you can then cast it to the appropiate type
[10:46:19] <pross-au> yep
[10:46:48] <pross-au> read application usage here... http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/socket.h.html
[10:47:06] <jez9999> struct sockaddr { ushort sa_family; char sa_data[14]; };
[10:47:35] <pross-au> jez9999: that might be true on your operating system
[10:48:09] <kierank> Is it possible to pass an AVMetadata with each packet?
[10:48:14] <kierank> AVMetadata struct*
[10:48:51] <kshishkov> kierank: probably not
[10:49:03] <kshishkov> it's all muxer stuff, not codec
[10:49:45] <jez9999> sockaddr is variable length?  sheesh
[10:49:52] <twnqx>     printf ("%d %d %d\n", sizeof (struct sockaddr), sizeof (struct sockaddr_in), sizeof (struct sockaddr_in6));
[10:49:57] <twnqx> 16 16 28
[10:50:15] <jez9999> what's its purpose then?
[10:50:26] <twnqx> to have generic access to the protocol
[10:50:32] <twnqx> aka sa_family
[10:51:35] <pross-au> jez9999: yes, the length of an address varies depending on the protocol being used
[10:51:46] <pross-au> ipv4 addresses are much smaller then ipv6 addresses
[10:52:02] <jez9999> 'generic access'?
[10:52:12] <jez9999> what does that mean
[10:52:15] <pross-au> socket.h has always been generic access
[10:52:41] <pross-au> it means the API is defined largely indepenant of the protocol
[10:53:12] <jez9999> yeah.... that's sockaddr_storage, as far as i can see
[10:53:18] <jez9999> so the purpose of sockaddr?
[10:53:56] <pross-au> jez9999: its a legacy datastruture
[10:54:10] <pross-au> they cant remove it from the standard, doing so will break stuff :D
[10:54:18] <jez9999> *shrug*
[10:54:40] <jez9999> so i want to pass a list of sockaddr_storage's into ffmpeg
[10:54:52] <jez9999> what's the standard way
[10:55:14] <pross-au> sockaddr_storage list[NB_LIST];
[10:56:51] <pross-au> if you were to provide a function, av_do_somthing(void *list, int items, int size_of_sockaddr); might be a more portable alternative
[10:57:26] <pross-au> that way there is no need to put sockaddr_storage in avformat.h or whatever
[10:57:36] <pross-au> (as not all platforms support it. e.g. windows)
[10:57:42] <jez9999> a function?
[10:57:43] <jez9999> hmm
[10:58:03] <jez9999> oh i dont expect sockaddr_storage to be accepted by ffmpeg
[10:58:18] <pross-au> ok
[10:58:22] <jez9999> that's for testing purposes.  the devs will probably want me to roll my own version (if it hasnt been done already)
[10:59:11] <jez9999> i dont know of a better non-POSIX way of passing a network address through the API
[10:59:22] <jez9999> although i heard that windows could be made POSIX-compliant now.
[10:59:24] <pross-au> char*
[10:59:44] <jez9999> you mean a string representation of the address?
[10:59:57] <pross-au> yep
[11:00:10] <jez9999> then some nasty code on the other side to parse it?
[11:00:23] <pross-au> yep
[11:00:30] <jez9999> how would it even know the address family?
[11:00:31] <pross-au> well, what if you want to pass hostnames?
[11:00:46] <jez9999> i wouldn't.  recvfrom() doesnt do hostnames
[11:00:54] <pross-au> oh
[11:00:58] <jez9999> they should be resolved beforehand
[11:02:15] <pross-au> is the user app sending the list to ffmpeg, or is ffmpeg returning a list of addresses?
[11:02:29] <jez9999> the former
[11:03:25] <pross-au> maybe then add these fields to the format context:   void* address_list;  int nb_addresses;  int sizeof_sockaddr;
[11:04:34] <jez9999> what about an opaque field?
[11:04:56] <pross-au> to avoid having to include sockaddr_storage in the public api.
[11:05:46] <jez9999> sizeof_sockaddr... didn't you say sockaddr was a legacy data structure?
[11:06:07] <pross-au> hah. well call it 'sizeof_sockaddr_storage' then.
[11:06:14] <jez9999> i can't find any definition of NB_LIST, by the way, in the ffmpeg codebase or in my /usr/include...
[11:06:30] <pross-au> jez9999: NB_LIST would be a number you decide on
[11:06:47] <jez9999> it's be variable though
[11:06:49] <jez9999> *it;d
[11:06:51] <jez9999> it'd
[11:07:07] <pross-au> okay then :  sockaddr_storage *addresses; int nb_addresses;
[11:07:35] <jez9999> sockaddr_storage *?
[11:07:44] <jez9999> a pointer to a single sockaddr_storage ?
[11:07:59] <pross-au> jez9999: it could be one, it could be many...
[11:08:21] <jez9999> ah, concatenated in memory
[11:08:55] <jez9999> yeah im preferring the void *address_list
[11:08:58] <pross-au> I prefer to call them arrays.
[11:09:04] <jez9999> the devs would never approve sockaddr_storage in AVFormatContext
[11:09:10] <pross-au> Yep
[11:09:32] <jez9999> again, though, what about an opaque field?
[11:09:37] <pross-au> opaque?
[11:10:38] <pross-au> void *address_list; <-- would be a pointer to an array of socket addresses
[11:13:38] <jez9999> opaque, like in ByteIOContext, or AVCodecContext
[11:17:28] <jez9999> ?
[11:18:36] <pross-au> as i said, it just saves having to specific sockaddr_storage in the API
[11:19:01] <jez9999> what are you referring to now?
[11:19:10] <jez9999> with 'it'? :-)
[11:19:22] <pross-au> void *address_list;
[11:19:26] <jez9999> ah right
[11:19:34] <jez9999> so you're unaware of the usage of the opaque field
[11:19:50] <pross-au> I dont even know what that means.
[11:20:08] <jez9999> well it exists in the structs i mentioned above
[11:20:21] <pross-au> void *
[11:20:34] <jez9999> for 'Private data of the user'
[11:20:41] <jez9999> yeah it is a void *
[11:20:41] <pross-au> priv_data
[11:20:56] <pross-au> yeah, but you dont want this list of ip addresses to be private
[11:21:03] <pross-au> you want other people to be able to use them
[11:21:16] <jez9999> other people?
[11:21:25] <pross-au> 'users of libavformat'
[11:21:35] <jez9999> oh, you mean that the intention of opaque is that ffmpeg never reads it.
[11:21:42] <jez9999> only ever the calling code
[11:21:45] <pross-au> correct
[11:21:49] <pross-au> thats what opaque means.
[11:21:53] <jez9999> yeah, i see
[11:22:05] <pross-au> got to go.
[11:22:10] <pross-au> hope ya work it out
[11:22:14] <jez9999> AVFormatContext probabyl ought to have an opaque anyway though, for good measure
[11:22:26] <jez9999> ....... bye
[11:22:26] <jez9999> lol
[11:23:54] <siretart`> elenril: pong?
[11:25:25] <elenril> siretart`: is there a git repo for x264 in ubuntu?
[11:26:28] <siretart`> elenril: yes, it is maintained by the pkg-multimedia team on git.debian.org
[11:26:45] <siretart`> ubuntu favors bzr, so we use debian ressources for that
[11:27:51] <elenril> good, i feared it was bzr only :)
[11:30:17] <siretart`> I guess there is an bzr package import as well, if interested, try 'bzr get lp:ubuntu/x264'
[11:32:59] * elenril would prefer to keep the number of vcses on his system as low as possible
[13:26:16] <superdump> http://gunshotfx.com/libavcodec/
[13:26:18] <superdump> hmmmmm
[13:26:44] <superdump> maybe the file has some 'aperture' colour profile thing in it that ffmpeg is ignoring?
[13:32:51] <kierank> does he provide the source?
[13:35:17] <superdump> no
[13:35:55] <superdump> but iirc Dark_Shikari said something about HD using a different pixel format standard to SD in many/all cases but they don't signal it in the bitstream as they're supposed to
[13:36:30] <superdump> so FFmpeg by default chooses a default pixel format that differs to what is commonly used and assumed by other programs for HD content
[13:36:39] <superdump> maybe we can provide a patch for this for them to test
[13:37:18] <kierank> you mean bt. 609 and bt 709?
[13:37:32] <superdump> something like that
[13:37:42] <superdump> http://tomvision.blogspot.com/2010/01/i-think-i-found-flaw-in.html
[13:37:48] <superdump> that's the author's blog post about it
[13:50:54] <J_Darnley> Those two images were converted to or from RGB using different matricies.
[13:51:28] <J_Darnley> Loading them into avisynth and then using ConvertToYV12() and manually setting the matrix fixes the colour differences
[13:55:20] <J_Darnley> using 709 for the QT image and 601 for the lavc image almost completely removes the differences
[14:00:51] <superdump> then it is indeed as we suspected
[14:00:53] <superdump> still
[14:00:58] <superdump> _almost_ completely?
[14:01:13] <superdump> i guess there might be rounding errors going forward and bad
[14:01:15] <superdump> back*
[14:17:34] <merbzt> yuv2rgb
[14:27:55] <CIA-17> ffmpeg: michael * r21635 /trunk/libavcodec/msmpeg4.c:
[14:27:55] <CIA-17> ffmpeg: Implement cool new vlc code.
[14:27:55] <CIA-17> ffmpeg: Fixes issue1637
[14:43:47] <CIA-17> libswscale: stefano * r30501 /trunk/libswscale/ (rgb2rgb.c rgb2rgb.h swscale.c):
[14:43:47] <CIA-17> libswscale: Implement shuffle_bytes_abcd() functions and use them for shuffling
[14:43:47] <CIA-17> libswscale: bytes when converting between RGB32 variants.
[14:43:47] <CIA-17> libswscale: In particular fix the argb -> rgba and abgr -> bgra conversions.
[14:43:47] <CIA-17> libswscale: See the thread:
[14:43:48] <CIA-17> libswscale: Subject: [FFmpeg-devel] [RFC] RGB32 / BGR32 ethernal bug
[14:43:48] <CIA-17> libswscale: Date: Tue, 26 Jan 2010 01:06:18 +0100
[14:45:19] <kshishkov> hmm, thatimages look like somebody (not) applying loop filter in some places
[14:46:08] <superdump> kshishkov: even the difference in the red?
[14:46:29] <kshishkov> no, those look more like colourspace conversion differences
[14:47:30] <superdump> can we choose between rec 601 and rec 709 in libavcodec somehow?
[14:47:55] <kshishkov> not yet, but codec telling which colourspace to use would be a nice feature
[14:49:14] <superdump> codecs can set PIX_FMT
[14:49:27] <superdump> and i assumed there would be some PIX_FMT for 601 and another for 709
[14:49:31] <kshishkov> too many pix_fmts, Michael does not like that already
[14:50:06] <superdump> meh
[14:50:08] <superdump> whatever
[14:56:07] <superdump> aha
[14:56:11] <superdump> found it
[14:56:40] <superdump> http://git.ffmpeg.org/?p=libswscale;a=blob;f=swscale.h;h=9e14262d30f4311ef7fbc419cf1515a57b292d0b;hb=HEAD#l98
[14:57:51] <superdump> merbzt: so that's what you were trying to say
[14:58:00] <superdump> libswscale/yuv2rgb.c
[14:58:06] <superdump> has the coefficients
[14:58:17] <superdump> iirc, you rewrote that didn't you kshishkov ?
[15:16:30] <superdump> maybe we can do it at the swscale level then
[15:28:55] <superdump> is h.264 deblocking standardised?
[15:29:17] <superdump> i.e. any coefficients used and so on
[15:30:08] <andoma> superdump: are you attending fosdem?
[15:30:22] <superdump> not this year, no
[15:30:27] <superdump> mebbe next
[15:30:32] <andoma> kay.. yeah me too
[15:30:44] <andoma> 4 guys from Spotify are going this year
[15:30:48] <superdump> :)
[15:30:50] <andoma> i should've joined them
[15:31:26] <CIA-17> ffmpeg: michael * r21636 /trunk/libavcodec/ (h264.c h264_ps.c):
[15:31:26] <CIA-17> ffmpeg: Fix large timebases.
[15:31:26] <CIA-17> ffmpeg: Fixed issue1633
[15:32:52] <kshishkov> superdump: I haven't touched coeffs
[15:34:48] <superdump> hmm
[16:13:27] <superdump> reynaldo: qcelp is always mono, right?
[16:22:19] <CIA-17> ffmpeg: jai_menon * r21637 /trunk/libavcodec/alac.c: Add ALAC 24 bps decoding support.
[17:20:12] <Compn> intel emailed me
[17:20:18] <kshishkov> and?
[17:20:22] <kshishkov> are you sued?
[17:20:39] <av500> the offered a refund for the pentium bug?
[17:22:09] <Compn> heh
[17:22:23] <Compn> it was a note about va-api
[17:23:22] <Compn> Hi,
[17:23:22] <Compn> I didn’t see the support for VAAPI listed on the Mplayer website where you talk about hw acceleration (section on the main page).
[17:23:22] <Compn> As you’re aware, Gwenole is doing excellent work by patching Mplayer for VAAPI available at: http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/
[17:23:22] <Compn> For the embedded customers, we’re looking at supporting Mplayer with the embedded graphics driver for the Atom platforms.
[17:23:22] <Compn> Please let me know if you’ve any questions. Thanks.
[17:23:23] <Compn> Regards,
[17:25:28] <av500> Compn: GMA500?
[17:25:32] <kierank> Conpn: was that from eric?
[17:26:16] <Compn> Ishu Verma
[17:26:16] <Compn> Software Technical Marketing Engineer
[17:26:17] <Compn> Digital Enterprise Group - ECG
[17:26:17] <Compn> ishu.verma at intel.com
[17:26:42] <Compn> so... no
[17:26:54] <Compn> i sent a reply asking which cards are supported
[17:26:56] <kierank> k, so wasn't the guy that did the dxva stuff
[17:32:43] <kierank> i wonder if slices will work through vaapi because through dxva they don't
[17:34:48] <Compn> kierank : got a list of intel or ati cards that are supported by vaapi ?
[17:34:52] <Compn> or anyone /
[17:37:23] <kierank> no idea
[18:23:48] <Kovensky> isn't there a vaapi->vdpau driver?
[18:23:51] <Kovensky> or is it still WIP?
[18:29:28] <Anssi> http://www.splitted-desktop.com/~gbeauchesne/vdpau-video/
[19:33:38] <Compn> arg
[19:33:55] <Compn> intel guy didnt like that i wrote ati works with vaapi :D
[19:35:56] <kshishkov> mention nvidia next time
[19:35:59] <Compn> lol
[19:39:06] <carignanboy> Where can I find the *-dev library that contains the avcodec_decode_audio3 symbol?
[19:39:24] <kshishkov> not here, I think
[19:39:34] <kshishkov> try newest version
[19:39:54] <carignanboy> FFmpeg version git-91be88c
[19:40:35] <kshishkov> main FFmpeg still does not use Git
[19:40:43] <kshishkov> ask at #ffmpeg channel
[19:41:03] <carignanboy> thanks :)
[19:46:03] <_av500_> decode_audio3? that still exists? :)
[19:46:51] <kshishkov> yes
[19:47:11] <kshishkov> it's default in current FFmpeg
[19:47:20] <kshishkov> IIRC, for about a year
[19:48:07] <_av500_> kshishkov: I know :)
[19:48:54] <kshishkov> maybe you can also sort git commit IDs chronologically without git log?
[19:49:12] * _av500_ had to make up packets on the fly to satisfy it
[20:08:08] <twnqx> symbian becomes open source?
[20:08:15] <twnqx> do want ffmpeg on my e65!
[20:09:42] <_av500_> patches welcome I guess
[21:01:26] <ShadowJK> do want libc
[21:02:00] <_av500_> it has libnokla
[21:08:37] <twnqx> i guess a libc would exceed the storage capacity of the mobile >_>
[21:08:58] <_av500_> uclibc
[21:09:22] <ShadowJK> it probably has 128 or 256 meg storage
[21:09:54] <ShadowJK> there is a libc for symbian, I think they call it OpenC or something
[21:10:02] <_av500_> 128mb is ok
[21:10:06] <drv> even glibc is not that big...
[23:44:50] <kierank> Is there a better way of handling the situation where an audio codec has more channels than the container is aware of than making the demuxer parse the codec's header?