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

[burek]

[02:01] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:d7e050b11d90: adts_aac_probe: mark buffer pointers as const
[02:01] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:658bd6db7bd1: ac3_eac3_probe: mark buffer pointers const
[02:01] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:4fcf6aa7a3a2: flac_probe: make buffer pointers const
[02:01] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:23348647b2fa: ipmovie_probe: make buffer pointers const
[02:01] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:29397c99e0a3: lmlm4_probe: make buffer pointers const
[02:01] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:e1f9432644a0: loas_probe: make buffer pointers const
[02:01] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:c3cb338955e7: mpegps_probe: make buffer related pointers const
[02:01] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:9d95deef6128: microdvd_probe: make buffer pointers const
[02:02] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:7a84664ffe54: mp3_read_probe: make buffer related pointers const
[02:02] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:c8e5efb4961e: mpc8_probe: make buffer related pointers and function arguments const
[02:02] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:59693ed96cf8: mxf_probe: make buffer related pointers const
[02:02] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:28b9099ac1be: pva_probe: make buffer related pointers and function arguments const
[02:02] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:f89f3d4a9823: str_probe: make buffer related pointers const
[03:21] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:9cb887ed3773: dsputil_mmx: fix pointer type for emulated_edge_mc_func()
[03:21] <cone-583> ffmpeg.git 03Michael Niedermayer 07master:1be8d0fbda0a: srt_probe: make buffer pointer const
[07:27] <ubitux> does anyone have some soft-telecined material or even just a dvd reference?
[16:43] <cone-710> ffmpeg.git 03Marton Balint 07master:cf0c63d99ae4: ffplay: fix greenish line on the right edge with some xv sizes
[16:43] <cone-710> ffmpeg.git 03Hendrik Leppkes 07master:8b6b3632fea2: vf_pp: add postproc to the library dependencys for avfilter when enabled.
[16:43] <cone-710> ffmpeg.git 03Michael Niedermayer 07master:0b980e57ace0: Merge remote-tracking branch 'cus/stable'
[17:13] <durandal_1707> we do not have any caption decoder?
[17:13] <kierank> no
[17:13] <ubitux> sami!
[17:13] <kierank> subtitles != captions :)
[17:14] <ubitux> sami are captions!
[17:14] <ubitux> text captions, but captions anyway
[17:14] <kierank> really?
[17:14] <kierank> hmmm
[17:14] <kierank> oh i stand corrected
[17:14] <durandal_1707> nobody working on porting isdb captions?
[17:14] Action: ubitux is not
[17:14] Action: ubitux doesn't know what is it and is afraid to look for
[17:14] <kierank> for us captions you'll need to decide on a way to demux first
[17:15] <kierank> because the captions are in the video data#
[17:32] <cone-710> ffmpeg.git 03Michael Niedermayer 07master:f9e55c0fed8c: swr: support -async X as a simple way to do what ffmpeg -async X did
[17:32] <cone-710> ffmpeg.git 03Michael Niedermayer 07master:a752b9b8635a: ffmpeg: use the new swr -async parameter instead of a set of parameters.
[17:55] <cone-710> ffmpeg.git 03Tomas Härdin 07master:928727f951d6: mxfdec: Rescale audio stream duration from EditRate to SampleRate
[18:03] <durandal_1707> ubitux: mp depends on postproc?
[18:06] <ubitux> durandal_1707: not anymore
[18:09] <durandal_1707> i still see it in Makefile
[18:17] <ubitux> yep, and some deps are missing
[18:20] <durandal_1707> this causes failures when building testprogs when postproc is not enabled
[18:24] <ubitux> you can remove it
[18:24] <ubitux> i dropped it from the configure deps
[18:25] <ubitux> concerning missing deps, deshake is missing (avcodec), removelogo is missing swscale, showspectrum is missing avcodec and subtitles is missing avformat and avcodec
[18:25] <ubitux> (i'm talking about makefile fflibs)
[18:26] <durandal_1707> ubitux: why you do not remove it?
[18:27] <Compn> hes busy!
[18:27] <ubitux> i forgot
[18:41] <durandal_1707> ubitux: should some diego commits be reverted because they are not relevant for us?
[18:45] <ubitux> durandal_1707?
[18:45] <ubitux> which one?
[18:47] <durandal_1707> fifo filters
[18:48] <ubitux> i don't know
[18:48] <ubitux> i don't think it really matters
[18:48] <durandal_1707> saste: so you are still against my patch for swapuv?
[19:01] <wm4> I have a sample that works with libfaad2, but not with ffmpeg
[19:01] <wm4> ffplay prints: [aac @ 0x90e1ac0] Audio object type 23 is not supported.
[19:01] <Compn> upload it somewhere ?
[19:01] <wm4> Compn: http://www.mediafire.com/download.php?pbl6epjbklvc0g3
[19:01] <Compn> >mediafire
[19:01] Action: Compn afk
[19:02] <wm4> not my upload
[19:03] <wm4> ah found it: https://ffmpeg.org/trac/ffmpeg/ticket/113
[19:09] <mfg> If I want to add a cookie jar is a static variable in http.c an acceptable way to keep the data persisted across different requests? Otherwise, I'm not really sure how I can get the data set by a previous response into future requests.
[19:15] <ubitux> no, you can't use a static variable
[19:15] <mfg> boo, i saw it in a few other places and though it might be ok
[19:16] <ubitux> where?
[19:16] <mfg> I figured that would be the answer though
[19:16] <ubitux> ffmpeg -i 'http://...' -i 'http://...' would be broken
[19:16] <mfg> avio.c
[19:16] <mfg> there were other spots
[19:17] <ubitux> first_protocol ?
[19:17] <mfg> yeah, i didn't really investigate the use
[19:17] <ubitux> doesn't look like a context-like usage
[19:17] <ubitux> more like the list of all protocol types
[19:19] <mfg> yeah. ok.
[19:21] <ubitux> mfg: i'm afraid you're facing a complicated issue with the options passing thing :p
[19:21] <mfg> oh?
[19:22] <mfg> because I'm not allowed to change AVFormatContext?
[19:22] <wm4> ideally, cookies would be set and read with avoptions or so
[19:23] <mfg> wm4 and stored where?
[19:23] <wm4> ffmpeg.c would have to do that
[19:24] <mfg> Don't think that would really work.
[19:25] <mfg> any http request can respond with a Set-Cookie. So for HLS streams I don't think that would really accomplish anything
[19:25] <mfg> like if the top-level m3u8 responds with a set-cookie, that the later requests need to echo back
[19:28] <mfg> ubitux are the -i ... -i files read in sequecne?
[19:29] <mfg> or is that to for multiplexing?
[19:29] <ubitux> they can be threaded
[19:29] <mfg> right
[19:29] <mfg> so no matter how this is done, access to the jar needs to be synchronized
[19:30] <mfg> no?
[19:34] <ubitux> synchronized?
[19:35] <mfg> yeah, like with a mutex
[19:35] <ubitux> if it's in a context you don't have to care about that
[19:37] <mfg> If it is in the HTTPContext, which is created new for each request the problem is how to get cookie values from prior requests. Does this make sense?
[19:37] <mfg> I'm not the first person to try this (or at least think about it): http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-September/131519.html
[19:38] <ubitux> i should really read properly what you said in the thread..
[19:38] <ubitux> just curious, the avoptions are set for each request?
[19:39] <mfg> ubitux i'm talking about a different issue now
[19:40] <michaelni> if you have a (de)muxer that opens several http connections in sequence its that (de)muxers job to move the cookies over from the last to the next http
[19:41] <wm4> michaelni: can anything be done about that AAC-LD issue? (ticker #113)
[19:41] <wm4> *ticket
[19:42] <michaelni> wm4, from a quick look
[19:42] <michaelni> if XYZ is not supported by the native decoder, someone has to read the spec and add support or support for an external lib that does support it
[19:43] <mfg> michaelni that would either require hls to be http aware, or change the URLProtocol to have some sort of data sharing method? Or am I way off the mark?
[19:43] <wm4> michaelni: libfaad supports it, and it did have a wrapper in ffmpeg, but the wrapper was removed in 2010 (git commit 6a74b1272efda1d85deb9485ca03230293864ec1)
[19:43] <mfg> the data sharing method would allow a new URLProtocol to grab information from a prior URLProtocol
[19:44] <JEEB> fdk-aac also should support a lot of stuff
[19:44] <JEEB> which should be LGPL-compliant
[19:44] <burek> too bad ffmpeg does not implement anything like commercial licenses or something.. that way it would be able to gather funds for paid developers in needed areas, such as ffserver for example
[19:44] <JEEB> (it has both a decoder and encoder)
[19:44] <wm4> JEEB: only has an encoder wrapper in ffmpeg, though, is that right?
[19:44] <JEEB> yup
[19:45] <JEEB> the best thing would be to poke one of the ffaac people from either project and get the stuff implemented, though :3
[19:45] <michaelni> mfg, i dont really see the problems but maybe thats my stupidity
[19:46] <mfg> i'm probably just explaining it poorly.
[19:46] <michaelni> mfg i see 2 solutions, either just add a AVOption to http that specifies a filename for the cookie jar or
[19:46] <michaelni> give http a avoption to read / write a string or something representing all the cookies
[19:46] <michaelni> and then let hls use this to move cookies around between http contexts
[19:47] <michaelni> avoptions have nice functions that fail cleanly when a avoption is not available like if its not http
[19:48] <michaelni> wm4, if theres a usecase & maintainer for a libfaad decoder wraper or fdk, a patch/commit is surely welcome to add such wraper
[19:49] <JEEB> wbs is the fdk-aac library maintainer as far as I can see
[19:50] <ubitux> aac-ld is a long standing issue&
[19:50] <ubitux> is it that hard to support?
[19:50] <JEEB> I haven't seen the specification at least
[19:53] <mfg> michaelni i think I like the AVOption one.  then its just appending/copying strings around
[19:53] <mfg> In most cases appending wouldn't even be necessary since the top-level m3u8 sets the cookie and all the rest just repeat it
[19:55] <mfg> ubitux the options are set for each request
[19:57] <mfg> did anyone make a decision on the patch I already submitted? Last time I checked in it was sounding like a no because of the changes to the format context.
[20:12] <ubitux> mfg: where else (i mean outside the hls demuxer) is it necessary to have the options in the AVFormatContext?
[20:13] <mfg> probably nowhere. otherwise they'd be there already? but, if you put them there, you could stop passing them around explicitly in a bunch of methods.
[20:14] <ubitux> well, then why (for the sake of your patch "Maintain HTTP options across multiple requests in HLS demuxer"), having them in the HLSContext would not work?
[20:14] <ubitux> you said to have "few serious problems" with this
[20:15] <ubitux> what are they? (you seem to talk about avio then, which look somehow related to another problem)
[20:15] <ubitux> what am i missing?
[20:15] <mfg> without putting them in AVFormatContext, how do you get them into the HLSContext.  Its never passed in with any method
[20:15] <ubitux> (are you trying to deal with the probing issue at the same time?)
[20:16] <mfg> no
[20:16] <ubitux> ah wait you don't have access to hlscontext?
[20:16] <mfg> um... from where
[20:17] Action: ubitux is definitely missing an important key
[20:17] <ubitux> give me a few minutes
[20:17] <mfg> yeah, i'm not explaining this right. Can I PM you?
[20:17] <ubitux> no, just give me some little time
[20:18] <mfg> sure, np
[20:22] <ubitux> oh i think i get it
[20:22] <ubitux> mfg: if you add support for options in the hls demuxer, and transmit them, would that work?
[20:23] <ubitux> basically, add a AVClass into HLSContext, and set a few pointers
[20:24] <ubitux> mfg: look a random demuxer with options, such as flv
[20:24] <mfg> I understand how avoptions/avclass wors
[20:24] <mfg> *works
[20:25] <ubitux> if you have a class in the hls demuxer, the options might be accessible
[20:25] <mfg> but only for options I explicitly set
[20:26] <mfg> so I'd have to mirror everything in http? 
[20:26] <mfg> and even then, those are removed from the dictionary initially 
[20:26] <mfg> once we visit an option, its pulled out
[20:27] <ubitux> if you have access to only the subset of options available in the hls demuxer, maybe the http options could just be exported
[20:27] <ubitux> ff_http_options or something; but that might get ugly for the offset etc
[20:27] <mfg> yeah
[20:28] <mfg> well, if I'm going to do this cookie stuff for hls with an avoption, i guess I can grab user-agent too
[20:28] <mfg> and any other ones.
[20:29] <mfg> it just sucks having to hard code option names in HLS that we will pass from one urlcontext to another
[20:32] <ubitux> OTOH, a lot of http options might not be relevant at all when using the hls demuxer
[20:32] <mfg> yeah, thats my hope
[20:33] <mfg> but still, if I  copy the "cookies" and "user-agent" option from AVClass to AVClass in hls, it kind of assumes its http underneath.  Not that its a silly assumption.
[20:38] <cone-710> ffmpeg.git 03XBMC 07master:4c41fc88df5c: mpegts: update AVProgram after pmt change
[20:54] <wm4> Author: XBMC <>  2012-12-16 09:53:18
[20:54] <wm4> what
[20:55] <beastd> michaelni: you forgot to drop the From: line from the mail body like I wrote in my reply
[20:56] <michaelni> Rainer said: "I think XBMC as a whole would be best match because I did this with Joakim."
[20:56] <michaelni> so i picked XBMC as author
[20:56] <michaelni> see the thread
[20:56] <beastd> ah
[20:56] <wm4> well it should have at least an email address (even if it's a dummy one)
[20:57] <michaelni> yes
[20:57] <michaelni> ideally patch submitters should provide Author with email address
[20:58] <beastd> ok i missed those replies. though XBMC seems a bit strange as Author.
[20:58] <beastd> Maybe next time they can just "elect" an Author and mention cooperation in the commit message body
[21:09] <ubitux> beastd: any comment on the pp patch (removing the alt thing)
[21:09] <beastd> ubitux: sent
[21:09] <ubitux> oh wow
[21:09] <ubitux> that was fast
[21:09] <ubitux> :D
[21:09] <beastd> :)
[21:09] <ubitux> who asked you such patch?
[21:12] <beastd> Well trouble with that change kept bubbling up. Someone suggested we could offer compatibility option so packagers can build versions of libpp that do not crash their other apps when asked for help.
[21:12] <ubitux> what change?
[21:12] <beastd> Unfortunately I do not know if it was advertised well enough so somebody actually used it :(
[21:13] <iive> something to do with the different casting of the help string?
[21:13] <ubitux> oh
[21:13] <beastd> yes, definition of the help string
[21:15] <beastd> the symbol is named pp_help
[21:19] <beastd> old definition was as "const char[]" vs new "const char *const"
[23:43] <michaelni> Coverity SCAN will be up in 15 Hours, 31 Minutes, 45 Seconds. 
[23:43] <michaelni> funny like always
[23:44] <michaelni> they should just say coverity is down for a few days
[23:50] <beastd> michaelni: is their estimation usually on spot?
[23:53] <michaelni> no idea
[23:53] <michaelni> but the only way for it to be is if they wait before swithcing it back on
[23:53] <beastd> michaelni: that is what i thought :-)
[00:00] --- Wed Dec 26 2012