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

[burek]

[00:11] <cone-868> ffmpeg.git 03Michael Niedermayer 07master:804c7b2c62a6: udp: Fix receiving large udp packets
[00:12] <michaelni> superware, please try if the issue is fixed
[00:29] <superware> michaelni: ok, but I need a win32 build
[00:31] <michaelni> no hurry, if you cant build one yourself you can wait for a new zeranoe build to appear
[00:32] <superware> daily?
[00:33] <michaelni> i think so
[00:35] <superware> ok great Michael, thank you very much for the great help (and project)
[00:35] <superware> I'll report here, tomorrow I guess
[00:36] <superware> bye
[00:51] <cone-868> ffmpeg.git 03Michael Chinen 07master:fc736a99eae1: flac_parser.c: fix case when final frame is a false positive
[00:53] <kierank> wow flac parser
[00:53] <kierank> that takes me back
[00:54] <Daemon404> kierank, not in a good way, i assume
[00:54] <kierank> i remember a huge ffmpeg bikeshed
[00:54] <kierank> of historic proportions
[00:55] <Daemon404> i must have been absent for that
[00:55] <Daemon404> or mentally blocked it out
[00:59] <Compn> i dont remember it but sometimes i ignore epic bikesheds
[00:59] <Compn> or webvtt stuff
[00:59] <Compn> >400 emails
[01:07] <saste> michaelni, do you mind to comment on the bitstream API doxy?
[01:07] <saste> and weird enough, it seems I'll have to work even more with that stuff
[01:12] <wm4> anyone knows how close the next major release is?
[01:13] <michaelni> saste, it would be better if a native english speaker would review it
[01:15] <saste> michaelni, you're the one who knows the code better
[01:15] <saste> but no hurry, indeed the doxy is not yet complete/correct, with regards with in-place filtering
[01:15] <saste> for which I'll need to reverse-engineer the code
[01:16] <llogan> saste: s/appliclation/application
[01:16] <saste> llogan, irc-review?
[01:17] <llogan> i can look at it later tonight if you like if you don't mind my API ignorance.
[01:22] <michaelni> saste, ok then ill wait for the next iteration
[01:23] <saste> llogan, yes I need both language review and API-wise review
[01:23] <saste> they must not necessarily be done by the same person
[01:23] <michaelni> ubitux, theres a ping in "WebM muxer writes WebVTT"
[01:23] <saste> but my remark still apply, I plan to write a second iteration so no hurry to review it
[01:23] <llogan> saste: ok. i'll give you the native american native english speaker review when i get back.
[02:18] <BBB-work_> Daemon404, http://arstechnica.com/information-technology/2013/06/c99-acknowledged-at-last-as-microsoft-lays-out-its-path-to-c14/
[02:19] <Daemon404> i saw
[02:19] <BBB-work_> they mentioned ffmpeg :)
[02:19] <Daemon404> been discussing it with wbs and nevcairiel in libav-devel
[02:19] <BBB-work_> ah
[02:19] <BBB-work_> cool
[02:19] <Daemon404> im rewriting makedef and c99wrap as bourne shell this weekend
[02:20] <Daemon404> so perhaps we can keep them i nthe source tree
[02:20] <BBB-work_> that sounds useful ues
[02:20] <BBB-work_> yes
[02:30] <kierank> 01:19:55 <"Daemon404> im rewriting makedef and c99wrap as bourne shell this weekend --> explain for the msvc-layman
[02:30] <kierank> ?
[02:37] <cone-868> ffmpeg.git 03Timothy Gu 07master:a9bbf59be732: cosmetics: Fix "dont" "wont" "doesnt" typos
[02:39] <Daemon404> kierank, c99wrap is C, makedef is perl
[02:39] <Daemon404> they are part of c99-to-c89 currently
[02:39] <Daemon404> but they'd do betetr to be in the src tree 
[02:39] <Daemon404> as shell scripts
[03:36] <cone-868> ffmpeg.git 03Michael Niedermayer 07master:8738d94274ba: avcodec: Make av_register_hwaccel() and avcodec_register() thread safe
[03:36] <cone-868> ffmpeg.git 03Michael Niedermayer 07master:08f6fdc3e4bb: avcodec/parser: Make av_register_codec_parser() thread safe
[03:53] <cone-868> ffmpeg.git 03Michael Niedermayer 07master:b36b5edb8fea: avcodec/bitstream_filter: make av_register_bitstream_filter() thread safe
[03:53] <cone-868> ffmpeg.git 03Michael Niedermayer 07master:53fd1ab26bec: avformat: make av_register_*put_format() thread safe
[03:59] <Daemon404> BBB-work_, http://pastebin.com/BtRbWVLb
[11:12] <cone-1> ffmpeg.git 03Luca Barbato 07master:afe03092dd69: lavc: move put_bits_left in put_bits.h
[11:12] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:c1343897c3c8: Merge commit 'afe03092dd693d025d43e1620283d8d285c92772'
[11:38] <cone-1> ffmpeg.git 03Luca Barbato 07master:e30b068ef79f: wmapro: make sure there is room to store the current packet
[11:38] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:3e33db3f652e: Merge commit 'e30b068ef79f604ff439418da07f7e2efd01d4ea'
[11:48] <cone-1> ffmpeg.git 03Luca Barbato 07master:6652338f43ef: wmapro: return early on unsupported condition
[11:48] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:562e8d019ba2: Merge commit '6652338f43ef623045912d7f28b61adea05d27ae'
[12:24] <cone-1> ffmpeg.git 03Luca Barbato 07master:38229362529e: wmapro: check num_vec_coeffs against the actual available buffer
[12:24] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:a3e9f4c32a92: Merge remote-tracking branch 'qatar/master'
[13:04] <ubitux> michaelni: ok gonna review it
[13:04] <ubitux> give me a day or two
[13:06] <michaelni> ubitux, thanks
[13:07] <ubitux> gonna review libgme now
[13:18] <ubitux> saste: what's the state of the delogo patches?
[13:18] <ubitux> need any review?
[13:18] <saste> ubitux, i'll push it the first one
[13:18] <saste> the other one needs to be updated
[13:19] <ubitux> ok
[13:20] <wm4> ubitux: thanks
[13:32] <ubitux> ok what can i review now..
[13:37] <wm4> should I attempt to run fate with my libgme patch?
[13:38] <ubitux> wm4: it might be relevant for probing
[13:39] <wm4> yes I was thinking that
[14:15] <cone-1> ffmpeg.git 03Stefano Sabatini 07master:f150db096d9d: doc/muxers: sort muxers by name
[14:15] <cone-1> ffmpeg.git 03Stefano Sabatini 07master:d47168e729d6: doc/muxers: apply various minor fixes to segment documentation
[15:09] <kwizart> Hello, can we assume neon to be runtime detected on arm nowadays (with current ffmpeg)
[15:09] <kwizart> ?
[15:21] <BBB> on systems that support it
[15:21] <BBB> iirc on android yes, else no
[15:21] <BBB> or something like that
[15:26] <kwizart> I had linux in mind
[15:42] <Compn> then just force detection on it
[15:42] <Compn> :P
[15:44] <kwizart> I depends on the case, I have both
[15:45] <kwizart> it depend on
[15:46] <cone-1> ffmpeg.git 03Carl Eugen Hoyos 07master:ac83d621363c: Avoid a null pointer dereference on oom when decoding vc1.
[15:47] <kwizart> but I'm building with -mfpu=vfpv3-d16 so neon seems to be miss-detected by ./configure when using this CFLAGS
[17:45] <cone-1> ffmpeg.git 03Carl Eugen Hoyos 07master:a1dbe49d02e9: Propagate error return values from the smacker decoder.
[17:45] <cone-1> ffmpeg.git 03Carl Eugen Hoyos 07master:90bd75e6eb78: Avoid a null pointer dereference on oom when decoding smacker.
[18:09] <xlinkz0> why aren't all the headers in the libs installed? for example ffmpeg.c uses libavutil/colorspace.h but it it not installed
[18:11] <Compn> xlinkz0 : its a private header ?
[18:11] <Compn> i mean, what else would use it ?
[18:11] <xlinkz0> a modified ffmpeg.c :D
[18:12] <Compn> pfft 
[18:12] <xlinkz0> i must make ffmpeg useable from android
[18:13] <wm4> yeah, that header is probably private
[18:13] <wm4> so why does ffmpeg.c use it?
[18:13] <wm4> seems... inconsistent
[18:13] <wm4> almost hypocritical
[18:14] <Compn> it maybe shared in other parts of the code
[18:14] <Compn> like say ffplay 
[18:14] <Compn> or probably swscale that everyone hates
[18:14] <Compn> :P
[18:23] <cone-1> ffmpeg.git 03Reuben Martin 07master:2fa89b27365b: Added codec ID to playback DNxHD
[18:24] <Compn> oh man
[18:24] <Compn> another fourcc/isom
[18:25] <Compn> oh gxf
[18:25] <Compn> yay
[19:02] <Daemon404> [12:13] <+wm4> almost hypocritical
[19:02] <Daemon404> almost?
[19:02] <Daemon404> no
[19:02] <Daemon404> it i.
[19:02] <Daemon404> is*
[19:03] Action: durandal_1707 those kids today....
[19:09] <durandal_1707> i made pcx to use bytestream2 and libav folk decided that not using bytestream2 is better solution
[19:17] <cone-1> ffmpeg.git 03Carl Eugen Hoyos 07master:225f78b7ef58: Avoid a null pointer dereference on clean-up after oom in ac3 encoder.
[19:18] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:a2e50fa068dc: Merge remote-tracking branch 'cehoyos/master'
[19:37] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:7f866c14ba3d: update all trac links to use the trac subdomain
[19:51] <wm4> is there anything definitive whether accessors "must" or "should" be used?
[19:51] <wm4> e.g. one place says:
[19:51] <wm4>      * Code outside libavcodec should access this field using:
[19:51] <wm4>      * av_codec_{get,set}_pkt_timebase(avctx)
[19:52] <wm4> so "should" means -> you don't have to?
[19:53] <wm4> it would be a bit troubling because Libav apparently doesn't have these (at least not all of them)
[19:55] <michaelni> wm4, if a application wants to link to shared avcodec/avformat and wants to work still when these libs are replaced by newer versions then it needs to use the accessors
[19:56] <wm4> what if an application wants to be compatible with Libav
[19:56] <michaelni> Libav doesnt have these fields
[19:56] <wm4> eh
[19:56] <michaelni> Such application can use the more generic AVOption code
[19:57] <michaelni> to acces the fields
[19:57] <michaelni> which would fail with error code 
[19:57] <michaelni> if the field isnt available
[19:59] <wm4> awesome, more hacks
[21:03] <nevcairiel> Daemon404: so afterall still only "almost hypocritical" since it apparently wasn't required :p
[21:04] <Daemon404> ;p
[21:04] <Daemon404> man
[21:04] <nevcairiel> although i'm quite sure the .v files have exceptions for the ff* tools
[21:04] <wm4> I think this was needed before the subtitle changes
[21:04] <Daemon404> writing bourne shell scripts is hard (tm)
[21:04] <nevcairiel> or was that only ffserver anymore?
[21:04] <Daemon404> every single post ever about anything
[21:04] <Daemon404> is for bash
[21:04] <Daemon404> how useless.
[21:05] <nevcairiel> how different is the syntax?
[21:05] <nevcairiel> or rather, how limited is sh ?
[21:05] <nevcairiel> :D
[21:05] <Daemon404> well im having a ard time figuring out how to skip the first argument
[21:05] <Daemon404> 'shift' is a bashism
[21:05] <Daemon404> so is ${var:2}
[21:05] <Daemon404> im trying something like ${@:$1} but it leaves whitespace
[21:05] <Daemon404> er
[21:05] <Daemon404> ${@#$1}
[21:06] <Daemon404> hmm....
[21:08] <Daemon404> well i figured it out... but it only works if arguments have no spaces
[21:08] <Daemon404> \o/
[21:08] <nevcairiel> are you sure that shift is bash?
[21:08] <mark4o> shift is not bash-specific
[21:08] <Daemon404> http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
[21:08] <nevcairiel> that doc has shift
[21:08] <Daemon404> i can find nothing regarding shift in the POSIX docs
[21:08] <nevcairiel> i'm looking at it
[21:08] <Daemon404> ctrl-f -> "shift"
[21:08] <Daemon404> nothing
[21:08] <nevcairiel> http://pubs.opengroup.org/onlinepubs/009695399/idx/sbi.html
[21:09] <nevcairiel> you need to follow a link
[21:09] <nevcairiel> :D
[21:09] <nevcairiel> about "special built-ins"
[21:09] <Daemon404> -_-
[21:09] <Daemon404> thats annoying
[21:17] <Daemon404> ah lovely. mktemp is not POSIX.
[21:17] Action: Daemon404 steals configure's
[22:38] <cone-1> ffmpeg.git 03Michael Niedermayer 07master:a2802d3cd496: get_pix_fmt_score: favor equal formats if all else equal
[22:44] <cone-1> ffmpeg.git 03Derek Buitenhuis 07master:58950ca0df67: ffmpeg: Don't include colorspace.h
[00:00] --- Sun Jun 30 2013