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

[burek]

[01:16] <cone-336> ffmpeg.git 03Arwa Arif 07master:100fc395b642: lavfi: USPP Filter
[01:23] <ubitux> michaelni: version bump..
[01:31] <michaelni> ubitux, fixed locally, will be in my next push
[01:31] <ubitux> thanks
[01:57] <cone-336> ffmpeg.git 03Clément BSsch 07master:73d88109c08e: avfilter/uspp: misc style fixes
[01:57] <cone-336> ffmpeg.git 03Clément BSsch 07master:397859c4a830: avfilter/uspp: make src const in store_slice_c()
[01:57] <cone-336> ffmpeg.git 03Clément BSsch 07master:e93abe1f4069: avfilter/uspp: use AVFILTER_DEFINE_CLASS()
[01:57] <cone-336> ffmpeg.git 03Clément BSsch 07master:df307debf274: build: add forgotten avcodec dependency in uspp
[01:57] <cone-336> ffmpeg.git 03Clément BSsch 07master:1a4128c843a0: LICENSE: mention that uspp is GPL
[01:57] <ubitux> anyway, gn
[02:07] <cone-336> ffmpeg.git 03Michael Niedermayer 07master:327c5292f2fe: avfilter/version: bump for uspp
[02:07] <cone-336> ffmpeg.git 03Michael Niedermayer 07master:d2d8ac24b843: avfilter/vf_uspp: Allocate qp storage after qp_stride is known
[02:08] <cone-336> ffmpeg.git 03Michael Niedermayer 07master:517278235211: avfilter/vf_uspp: The qp array width is qp_stride not stride/16
[02:08] <cone-336> ffmpeg.git 03Michael Niedermayer 07master:e1540cdf0703: avfilter/vf_uspp: use the average QP instead of QP[0]
[02:08] <cone-336> ffmpeg.git 03Michael Niedermayer 07master:13c3a97bf118: avfilter/vf_uspp: remove YUV 411/422/440
[04:55] <cone-336> ffmpeg.git 03Michael Niedermayer 07master:e07c82688e81: avfilter/vf_uspp: fix integer overflow in intermediate
[05:19] <Daemon404> that aac bug is insane
[05:31] <rcombs> the bug or the thread
[05:33] <Daemon404> well the thread obc
[05:33] <Daemon404> obv*
[05:43] <michaelni> BtbN, about CONFIG_CYGWIN, it might be better to have something like NVENC_CFLAGS 
[05:45] <michaelni> BtbN, also if theres anything i should push to nvenc to fix/improve this, ping me
[07:12] <arwa> What is meant by "bump lavfi's micro version"?.
[07:17] <jamrial> increase the version number
[07:17] <jamrial> check libavfilter/version.h
[08:46] <ubitux> michaelni: the code you're changing in vf_uspp might be applicable to vf_spp
[08:46] <ubitux> it's copied from there
[09:53] <BtbN> michaelni, that flag still must only be set on cygwin, i'm pretty sure -mwin32 isn't a valid flag anywhere else. The only thing it does is make the cygwin gcc also define _WIN32. What do you mean with NVENC_CFLAGS? Should i set those in configure and use them in the Makefile?
[10:48] <j-b> good morning!
[10:55] <anshul_mahe> gud morning :)
[11:45] <michaelni> ubitux, the int16 ? spp only averages max 8x8 cases so it should make no difference to it
[11:46] <michaelni> but you can change it to uint16 if you like
[11:47] <michaelni> BtbN,  NVENC_CFLAGS was just a suggestion to avoid having a check for a platform in the makefile but rather have configure either set it to mwin32 or nothing, seemed nicer to me but iam fine with either
[11:48] <nevcairiel> seems far easier to just forget about cygwin tbh :p
[11:49] <nevcairiel> it seems somewhat risky to compile one file with this flag and everything else without
[11:52] <ubitux> michaelni: i was just pointing it out since i saw changes in code that was common
[11:52] <ubitux> i don't know if it is relevant
[11:54] <michaelni> ubitux, it doesnt matter in the currecnt code but if you add 10bit support it should matter
[11:54] <ubitux> ok :)
[12:36] <anshul__> If I want to add scte-35 stream type which is 0x86 in mpegts.c, in which section of stream should I add
[12:42] <anshul__> stream type value is mentioned in scte spec, should i add in ISO type
[12:45] <anshul__> prog_reg_desc is CUEI
[14:49] <cone-846> ffmpeg.git 03Michael Niedermayer 07master:30d2ac4bf9b9: avfilter/vf_spp: change temporary to unsigned
[14:49] <cone-846> ffmpeg.git 03Michael Niedermayer 07master:eb725235b03f: avdevice/v4l2: use av_freep() to avoid leaving stale pointers in memory
[17:47] <wm4> m->elems[m->count].key = (char*)(intptr_t)key;
[17:47] <wm4> just to cast const away?
[17:47] <wm4> what
[17:48] <wm4> michaelni: why did you add intptr_t in 8aed90958d8bbf4a0652fdc56b9655ad9962fa50?
[17:48] <wm4> michaelni: if there's no specific reason, I'll submit a patch to remove it
[18:04] <michaelni> wm4, as the commit message says it was to remove the warning (without introducing another warning) 
[18:05] <michaelni> its 3 years ago, so i cant remember which compiler it was but likely some clang or gcc
[18:07] <Daemon404> every line of C causes a warning in some version of gcc
[18:19] <wm4> michaelni: maybe you could request from coverity to check for mallocs
[18:19] <wm4> I think it doesn't currently
[18:19] <Daemon404> 8312 new defects found
[18:21] <rcombs> wm4: plz2review https://ffmpeg.org/pipermail/ffmpeg-devel/2014-December/166559.html from a library consumer standpoint
[18:21] <Daemon404> hell say what i say
[18:21] <Daemon404> "shouldnt be in lavf"
[18:21] <koda> wm4: check for mallocs?
[18:21] <wm4> rcombs: well, it doesn't help with most points I brought up in the past; doing it like Nicolas' initial patch it would actually be simpler and would have the same characteristics
[18:22] <wm4> koda: I think Coverity doesn't care about this: char *x = malloc(1); *x = 1;
[18:22] <rcombs> wm4: where's said patch again?
[18:22] <nevcairiel> koda: check for unchecked mallocs, if you want more verbosity :p
[18:22] <wm4> rcombs: to say it with Nicolas' words, in the mailing list archive
[18:22] <rcombs> \o/
[18:22] <nevcairiel> but his words are usually rude
[18:23] <rcombs> wm4: I did intend for it to be usable by e.g. mpv with a UI
[18:24] <rcombs> like `Multiple possible character encodings were detected. Please choose one: [1. <charenc1>], [2. <charenc2>] `
[18:25] <wm4> in any case I can't seem to find this old patchset again
[18:25] <wm4> rcombs: maybe I misunderstood something
[18:26] <rcombs> the relevant data is exposed in the AVFormatContext, though it should probably be documented better and an example provided
[18:26] <koda> wm4: i think so too, but i am not sure there is an option to turn on or off
[18:26] <wm4> also, btw., I'm offended by the new fields in AVFormatContext, but you probably knew that
[18:26] <wm4> koda: might be that you have to submit a "model"
[18:26] <Daemon404> i sitll maintain it is not the demuxer or parser's job to detect character encodings.
[18:27] <Daemon404> square peg round hole
[18:27] <koda> wm4: btw that set could have had some cc love
[18:27] <wm4> Daemon404: me too, the problem here is that people want such a feature to be available somewhere, but it doesn't fit into the lavc vs. lavf architecture
[18:27] <rcombs> ^ yeah
[18:27] <wm4> koda: cc where
[18:28] <rcombs> also, e.g. UTF-16 handling is already in lavf
[18:28] <Daemon404> wm4, you put it in teh fucking player
[18:28] <koda> wm4: to all ffmpeg forks, ffmbc, bpg and another one iirc :p
[18:28] <Daemon404> the layer ABOVE lavf
[18:28] <Daemon404> why must it fit in ffmpeg's libs?
[18:29] <Daemon404> mind you i also thing subtitle parsing does not belong in lavf
[18:29] <Daemon404> so.
[18:29] <Daemon404> there's that.
[18:29] <wm4> Daemon404: because rewriting that code in every player is kind of stupid, and it would be nice if there was a common lib to handle it
[18:29] <Daemon404> then make a gorram subtitles lib
[18:29] <Daemon404> subtitles != containers
[18:29] <wm4> libavsubtitles?
[18:30] Action: koda +1s Daemon404 
[18:30] <wm4> but some containers have subtitles
[18:30] <Daemon404> demux them. fine. send *packets*
[18:30] <wm4> I see no fucking problem here
[18:30] <Daemon404> yes lavf is the inbred clusterfuck of containers, protocols, subtitles, etc
[18:30] <Daemon404> should merge avdevice too
[18:30] <Daemon404> since it canibalizes it anyway
[18:31] <wm4> having subtitles in lavf is ok ebcause lavf handles file format detection in general
[18:31] <wm4> mixing lavf with various other things that detect file formats is a pain
[18:31] <Daemon404> that's because lavf sucks
[18:31] <Daemon404> nt because it is good design
[18:32] <wm4> can't argue with this
[18:32] Action: Daemon404 thinks wm4 has a bit of stockholm syndrome
[18:32] <koda> lol
[18:32] <wm4> anyway, if someone wants to start a subtitle lib, I'm in
[18:32] <wm4> Daemon404: possible, but are you sure you're safe?
[18:32] <ubitux> what for?
[18:32] <Daemon404> i am not safe
[18:32] <Daemon404> i keep intending to make a subtitle lib, but end up with no time
[18:32] <Daemon404> i would *love* to drop pycaption.
[18:33] <ubitux> i'm going to try to submit the change of text internal this week end
[18:33] <ubitux> and i think we'll be kind of in a good state after this
[18:33] <Daemon404> youre putting makeup on a pig, ubitux 
[18:33] <ubitux> no
[18:33] <Daemon404> you can't be in a good state when teh underlying design choice is retarded
[18:34] <wm4> Daemon404: I think ideally ffmpeg would loosen its library incest a bit and allow for more modular development
[18:34] <wm4> different repos for different libs etc.
[18:34] <koda> libavsubs indeed sounds nice
[18:34] <ubitux> Daemon404: if you want to be able to deal with subtitles that's the only sane way
[18:34] <Daemon404> ubitux, no
[18:34] <wm4> then something like libavsubs could actually make sense
[18:34] <koda> all subitles seem kinda hacked in lavf/lavc
[18:34] <Daemon404> it;s the onyl wya ot hammer it to fit in libav*
[18:34] <Daemon404> in its fucked up model
[18:34] <ubitux> koda: we discussed that years ago already, and it was considered not that good
[18:35] <ubitux> Daemon404: like, you need to think of all the operation you want to do with subtitles, and so far the lavf/lavc model is actually pretty good
[18:35] <ubitux> we almost reach a consistent state with A/V
[18:35] <wm4> that's because libav* is a black hole
[18:36] <ubitux> anyway, i'm not going to argue with this; i'll make sure to submit the patch asap, sorry about the delay so far
[18:36] <ubitux> i got distracted by other shitty subjects
[18:36] <wm4> I bet the discussion went something like this: libavformat already handles format detection! it also handles IO abstraction (AVIO)! thus it'd be best if libavsub would use these! but then why not have it in lavf directly?
[18:36] <ubitux> such as edit lists.
[18:36] <Daemon404> wm4, listening to people who actually use the libraries (and are not inbred like mplayer/ffmpeg) is discouraged.
[18:36] <ubitux> wm4: separating timing & encapsulation from decoding markup makes sense with subtitles
[18:37] <ubitux> except copying that model with a different flavour in a "libavsubtitles" won't help
[18:37] <ubitux> anyway, gtg, cya
[18:37] <wm4> a libavsubtitles could also be used by people who merely want to read subs, not pull in the whole libav* library stack
[18:38] <wm4> it's kind of a basic lesson in modular software
[18:38] <ubitux> so we should separate audio from video?
[18:38] <Daemon404> wm4, my idea was to make a library lossely based off of aegisub's subtitle parsers, which seem to be the best around
[18:38] <ubitux> libacodec and libvcodec?
[18:38] <Daemon404> because aegisub is not very modular rght now due to Bad Decisions From The Past
[18:38] Action: ubitux &
[18:39] <Daemon404> i wouldnt classify subtitles as i would audio for video.
[18:39] <Daemon404> theyre findementally different
[18:39] <koda> audio and video are similar enough to model them together, subtitles seems a different beast
[18:40] <wm4> but hey, lav* even models embedded picture metadata as stream
[18:41] <Daemon404> they ARE streams in almosy every format
[18:41] <Daemon404> except ogg.
[18:41] <wm4> and id3v2
[18:41] <Daemon404> ah right mp3shit
[18:42] <Daemon404> wm4, i think some of the reason we end up like this, btw, is cause nobody thinks "maybe we just shouldn't add X" is a valid answer
[18:42] <Daemon404> because "features"
[18:42] <wm4> also sigh, lavf's format detection not being able to handle mp3s with huge id3 tags
[18:42] Action: Daemon404 runs
[18:42] <wm4> Daemon404: definitely not in ffmpeg
[18:44] <Daemon404> well, my daily rage is done
[18:44] <Daemon404> time to stare at my unmerged patch sets on google/pbs/gnu projects for a while
[18:45] <koda> Daemon404: i tried to +1 those but nothing happened :(
[18:45] <koda> actually I +1d wm4 too, and nothing happened too
[18:45] <Daemon404> some guy pinged too, and no response
[18:45] <wm4> huh
[18:45] <Daemon404> open source just means code dumps to them
[18:45] <wm4> meanwhile, I'm trying to report a bug to ALSA
[18:45] <wm4> yeah...
[18:46] <Daemon404> wm4, i even wen tahead and coded fixes for my bugs.
[18:46] <Daemon404> didnt help
[18:46] <wm4> bug tracker offline (for years), nobody replies on the mailing list
[18:46] <Daemon404> the future is pulse
[18:46] <wm4> it really is
[18:46] <wm4> seems nobody gives a shit about improving ALSA anymore
[18:47] <Daemon404> nobody did, even before PA.
[18:47] <wm4> but PA has a different set of weird bugs and issues
[18:47] <wm4> some of them features
[18:47] <Daemon404> my linux installs dont even have audio enabled
[18:47] <Daemon404> <_<
[18:48] <koda> do you guys remember when we complained about OSS
[18:49] <wm4> lol
[18:49] <BtbN> time for native PA drivers in userspace i guess
[18:51] <cone-846> ffmpeg.git 03Michael Niedermayer 07master:e8dbecb99569: avfilter/vf_spp: Allocate qp storage after qp_stride is known
[18:51] <cone-846> ffmpeg.git 03Michael Niedermayer 07master:2a8eb0d1565a: avfilter/vf_spp: The qp array width is qp_stride not stride/16
[19:30] <cone-846> ffmpeg.git 03Arwa Arif 07master:9f85c273a36d: Delete mp=uspp
[19:32] <Daemon404> wow
[19:32] <Daemon404> people use slackware?
[19:32] Action: Daemon404 checks the year
[19:33] <gnafu> whatyearisit.gif
[19:33] <llogan> i know of exactly one user
[19:33] <llogan> 2002.gif
[19:37] <cone-846> ffmpeg.git 03wm4 07master:ce35a61399cd: lavc/avpacket: check for malloc failure
[19:49] <Plorkyeran> <@Daemon404> wm4, my idea was to make a library lossely based off of aegisub's subtitle parsers, which seem to be the best around <-- that's a depressing thought
[19:51] <Plorkyeran> but it may be true, as every other one I've looked at was far worse...
[19:51] <Plorkyeran> aegisub's at least tries to parse things correctly rather than just throwing regexes at the file
[19:56] <Daemon404> yes
[19:57] <wm4> or scanfs
[19:58] <iive> llogan: now you know two users :P
[21:06] <ubitux> the ffmpeg subtitles parser are not good? :(
[21:06] <ubitux> i put efforts in them :(
[21:14] <iive> you effort good. make them better.  work harder. Bonzai !
[21:20] <beastd> banzai would probably be more cheerful ;-)
[21:20] <Compn> banzai!
[21:22] <iive> i should have copy pasted it...
[00:00] --- Sat Dec 13 2014