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

[burek]

[00:05] <michaelni> ubitux, yes, it was my intend to wait for saste
[01:43] <cone-470> ffmpeg.git 03Timo Rothenpieler 07master:2a428db5e2c1: avcodec: Add NVENC encoder
[01:49] <Compn> its in! :)
[01:49] <Compn> ehe
[01:49] <j-b> how can you commit such crap?
[01:49] <j-b> seriously?
[01:49] <j-b> +#if defined(__CYGWIN__) && !defined(_WIN32)
[01:49] <j-b> +#define _WIN32
[01:49] <j-b> +#define TEMP_WIN32
[01:49] <j-b> +#endif
[01:50] <Compn> iirc he said it didnt work on windows
[01:50] <Compn> but nvidia's did 
[01:50] <iive> this is ffmpeg, we take crap and turn it into fruit.
[01:50] <j-b> very clever
[01:51] <Compn> in the past ffmpeg had trouble when it worked on things in seperate repos for too many years
[01:51] <j-b> In C, symbols starting with an underscore followed by either an upper-case letter or another underscore are reserved for the implementation. Y
[01:51] <Compn> the current idea is to merge things and work on them in the same repo
[01:53] <j-b> so?
[01:53] <j-b> violating C standard?
[01:55] <j-b> incredible
[01:55] <j-b> either CYGWIN is Windows, or it's not
[01:55] <cone-470> ffmpeg.git 03Martin Storsjö 07master:c7921a480467: libfdk-aacdec: Fix a boundary check
[01:55] <j-b> but you cannot do #undef _WIN32 #define _WIN32
[01:56] <cone-470> ffmpeg.git 03Michael Niedermayer 07master:66daf3b81154: Merge commit 'c7921a480467876ece06566e0efd8f6bce9d1903'
[01:56] <j-b> I really need a new fork
[01:56] <iive> relax...
[01:56] <j-b> sorry, but no.
[01:56] <Compn> iive : no, you cannot tell people to relax , it never works :P
[01:56] <j-b> adding a hack for a file, why not
[01:56] <Compn> its nonfree, you cant use it anyhow :P
[01:56] <iive> maybe there is a reason for that. try to ask first.
[01:56] <iive> then try to fix it.
[01:57] <j-b> no, it should not be merged
[01:57] <j-b> it's not like a small mistake
[01:57] <j-b> something forgotten or a weird case
[01:57] <iive> what is the worst thing that could happen?
[01:57] <Compn> iive : universe explodes
[01:57] <Compn> (starting with france)
[01:57] <j-b> it's #undef compiler defined symbols.
[01:58] <j-b> The only define that is stable on Windows
[01:58] <j-b> _WIN32
[01:58] <iive> at least in the above snippet I don't see undef, 
[01:59] <j-b> +#if defined(TEMP_WIN32)
[01:59] <j-b> +#undef _WIN32
[01:59] <j-b> +#endif
[01:59] <j-b> +
[01:59] <iive> and the patch seems to have been discussed quite a lot in the mail list
[02:00] <Compn> oh , i was wrong, it works on windows too , according to timo
[02:00] <Compn> https://github.com/BtbN/FFmpeg/tree/nvenc
[02:01] <iive> well. it looks this is indeed a hack, to workaround something in the nvEncodeAPI.h
[02:02] <j-b> no, it's not
[02:02] <j-b> it's to support some crazy Cygwin retardation
[02:02] <j-b> that refuses to use Windows standard functions
[02:02] <j-b> but needs to open the nvidia dll
[02:06] <iive> so, do you have idea how to implement the same thing properly? and still support cygwin?
[02:07] <Compn> more ifdefs :)
[02:08] <j-b> yes
[02:08] <j-b> just remove all CYGWIN specific code
[02:08] <j-b> and just let it use the normal Windows code.
[02:10] Action: koda chuckles at I really need a new fork
[02:11] <iive> there are plenty of forks, but there is no spoon
[02:11] <iive> sorry, i'll be leaving you.
[02:11] <iive> have fun.
[02:18] <michaelni> j-b, ive forwarded the nvenc related discussion above to timo
[02:20] <cone-470> ffmpeg.git 03Martin Storsjö 07master:e737a4aaafcb: dashenc: Change the duration fields to 64 bit
[02:20] <cone-470> ffmpeg.git 03Michael Niedermayer 07master:7ee5f764ee6c: Merge commit 'e737a4aaafcb1d761b7f96043c2f83ce742c64ae'
[02:20] <Compn> michaelni : it sounds like j-b has lost his trust in you for committing the patch
[02:21] <michaelni> its code thats disabled and separate
[02:22] <Compn> michaelni : maybe its time to make the unwritten policy , written, so people arent confused on whats going on? the policy that ffmpeg tries to get patches applied instead of letting them rot in mailing lists or external repos ?
[02:22] <Compn> i'm not sure where that kind of policy should be written down, and if it shouldnt have any hard rules ... 
[02:23] <Compn> maybe that upsets people, ffmpeg not having hard rules and policy violations ? i dunno. i am just trying to help
[02:23] <Compn> also i'm not a fan of rulemaking. i just want to avoid drama really
[02:27] <Compn> i guess you cant please everyone. i know people are still upset at mpcodecs
[02:27] <Compn> but maybe i'll write something up and rfc , project can vote on a patch to add some info to devel policy
[02:29] <michaelni> well, the last nvenc patch was posted about 2 weeks ago and only philip commented on that and philip said "... but I'm ok with dealing with that after committing the initial implementation."
[02:30] <Compn> i understood that to mean 'OK' as well.
[02:31] <michaelni> if theres a problem with nvenc, i sure can revert it., j-b should i revert it ?
[02:34] <Compn> i'm guessing some devs want you not to commit patches with such "glaring violations of the c standard" in the first place.
[02:34] <Compn> its hard being a committer in open source software, no one is ever happy with your work.
[02:36] <Compn> i'm happy with you michaelni :)
[02:37] <jamrial> instead of reverting, we could instead just temporarily disable this encoder on cygwin until a non-hacky solution is committed
[02:37] <Compn> it requires a file from nvidia sdk , so probably 100% of people do not have it installed
[02:38] <Compn> it = the encoder
[02:43] <michaelni> jamrial, posted a patch to do that, please review
[02:46] <cone-470> ffmpeg.git 03Lou Logan 07master:55c5a38369c1: doc: add loglevel numerical values
[03:01] <koda> Compn: try setting the policy that every single patch has to be reviewed, and lets see where it goes :D
[03:24] <llogan_> how would i adjust midtones using pauls colorlevels filter?
[03:24] <Compn> by asking in #ffmpeg ? :P
[03:24] <Compn> ehe
[03:25] <llogan_> i'm trying to come up with additional examples
[03:25] <Compn> oh ok :)
[03:25] <llogan_> got contrast, darken, lighten, etc, but not lighten shadows
[03:26] <llogan_> i've always been somewhat retarded when it comes to numbers.
[03:27] <llogan_> ah well, i'll probably just submit my "review" as is.
[04:18] <cone-470> ffmpeg.git 03Michael Niedermayer 07master:ef23bd939d95: avcodec/hevc: Silence "warning: ref0/1 may be used uninitialized in this function"
[05:02] <cone-470> ffmpeg.git 03Michael Niedermayer 07master:dbdc6e554e48: configure: do not allow nvenc to be build on cygwin to avoid _WIN32 definition hack
[09:56] <BtbN> michaelni, j-b: Yeah, that's indeed a hack to make the nvenc header work in cygwin. It checks the _WIN32 macro to decide which calling convention to use(stdcall on windows, cdecl on linux). So as cygwin obviously still uses the windows dll with the stdcall functions, the header allways needs the _WIN32 macro defined on windows.
[10:00] <BtbN> It only undefines the _WIN32 macro if it wasn't defined before. It's definitly not pretty, but the only way i see to support cygwin.
[10:04] <BtbN> https://bpaste.net/show/123d9ecbcf2b that's the relevant part from the nvenc header
[10:04] <k_sze[work]> Hello. To build ffmpeg on Windows using MinGW, should I choose to install MinGW-win64 with posix threads or win32 threads?
[10:15] <BtbN> Is there a way to add a compiler flag only for the nvenc.c file?
[11:17] <j-b> BtbN: then, if cygwin, use all win32 code. Aka LoadLibrary, not dl_open and remove this hack
[11:17] <BtbN> j-b, the problem is, cygwin doesn't define _WIN32
[11:17] <BtbN> Wouldn't be a problem if the -mwin32 compiler flag was specified
[11:20] <nevcairiel> cygwin shouldnt really be used for anything anymore
[11:22] <BtbN> Well, if adding support is easy enough, i don't see why not.
[11:23] <BtbN> https://github.com/BtbN/FFmpeg/commit/aaacc24105ba04ca740fd8b228f26234317131f3 would be a possible fix. But i haven't been able to test it yet. It very likely breaks other stuff.
[11:30] <j-b> BtbN: if, it does not define _WIN32, it should not use a Windows dll
[11:30] <j-b> You cannot have both.
[11:30] <j-b> Either you define _WIN32 and you can use Windows dlls and APIs, or you don't.
[11:30] <j-b> Cygwin people are stupid anyway.
[12:01] <michaelni> BtbN, something like "$(SUBDIR)nvenc.o: CFLAGS += -mabc" should work for adding a flag to one file
[12:17] <BtbN> michaelni, i wonder if it's an option to add that flag on cygwin globaly
[12:21] <michaelni> BtbN, i cant awnser that question, i dont know enough about win32 & cygwin
[12:28] <BtbN> michaelni, so for adding -mwin32 on cygwin only, i'd have to do something like this: https://gist.github.com/BtbN/b0e7a6fbc5e8189cf694 ?
[12:29] <michaelni> BtbN, have tested this on cygwin ? (fate passes, no new build warnings ?)
[12:30] <BtbN> No, i'm not near my windows machines currently, just asking if the general idea is right
[12:33] <BtbN> Is fate even regularily tested in cygwin?
[12:46] <michaelni> BtbN, we do have a cygwin fate client it doesnt run every day though
[13:49] <cone-859> ffmpeg.git 03Michael Niedermayer 07master:a03f72e7447b: avcodec/x86/hevc_mc: fix sse register counts
[13:49] <cone-859> ffmpeg.git 03Michael Niedermayer 07master:27dfe54eb765: avcodec/libxavs: fix division by 0 bitrate
[15:17] <cone-859> ffmpeg.git 03Gabor Nagy 07master:28fc31d78da9: avformat/avidec: Do not fail for crazy start times
[16:24] <cone-859> ffmpeg.git 03Michael Niedermayer 07master:ff0a0b62f3d3: compat/avisynth/avxsynth_c: Clear all unused fields in returned structs
[17:40] <wm4> ubitux: btw. doesn't vlc support mp4 edit lists? how do they do it?
[17:43] <j-b> why would we support athta?
[17:44] <Daemon404> wm4, by not using lavf for info
[17:44] <Daemon404> afaik
[17:44] <wm4> Daemon404: the problems are a bit deeper
[17:44] Action: Daemon404 managed to implement it fine on "presentation" level?
[17:45] <wm4> unless vlc happens to have an architecture that just matches what edit lists require
[17:45] <j-b> what does it require that MKV does not?
[17:45] <nevcairiel> I bet its modeled for QuickTime or something and nothing else. :P
[17:45] <wm4> j-b: at the same presentation time, you may need to refer data from different tracks at different times
[17:46] <wm4> which is kind of bad if the demuxer API was designed for interleaved access (like lavf's)
[17:46] <wm4> unless you just open separate demuxers for each track
[17:46] <j-b> wm4: how is that different from MKV linked chapters?
[17:46] <Daemon404> mkv must have matching tracks
[17:46] <wm4> mkv linked chapters use the same times for audio and video
[17:47] <nevcairiel> MKVs seem to generally work by splitting at transport time as well, since the implicit spec from Haalis implementation only worker like that
[17:47] <Daemon404> but anyway
[17:47] <Daemon404> it's not hard if you *do not* do it at demuxer level
[17:47] <wm4> I just explained why it's hard
[17:47] <j-b> wm4: I think I got it.
[17:47] <j-b> wm4: brr, that smells horrible.
[17:47] <j-b> wm4: who supports that beside QT?
[17:48] <wm4> Daemon404: maybe you have it easier because you do offline processing
[17:48] <wm4> j-b: dunno
[17:48] <wm4> probably nothing
[17:48] <wm4> we're wondering whether we can just ignore this part
[17:48] <Daemon404> wm4, i used a design siminal to trim(a,b)++trim(c,d) in avisynth
[17:48] <Daemon404> not avisynth, i mean
[17:48] <Daemon404> the idea.
[17:48] <wm4> Daemon404: yeah, similar to ubitux' idea to export a lavfi graph
[17:48] <Daemon404> lavfi is crippled
[17:49] <Daemon404> it cant seek.
[17:49] <wm4> well, you just decode everything from start
[17:49] <wm4> and then select what you need
[17:49] <Daemon404> yeah no
[17:49] <Daemon404> thats retarded
[17:49] <wm4> it certainly won't sit well with api users
[17:50] <Daemon404> i also had the benefit of knowing i can seek
[17:50] <Daemon404> since
[17:50] <Daemon404> well
[17:50] <Daemon404> mp4
[17:51] <wm4> so how exactly do you do it? what happens if referenced audio and video at the same presentation time are far away in the source file?
[17:51] <Daemon404> i do it offline, so it's not so bad
[17:52] <Daemon404> if i were to do it for playback i'd try and decode/buffer a bit of audio first
[17:52] <Daemon404> or easier: use 2 threads
[17:52] <j-b> 17:49 <@Daemon404> it cant seek.
[17:52] <j-b> oh yes
[17:52] <j-b> And the fact that it cannot play a growing file...
[17:53] <wm4> I see 3 fundamental solutions: 1. open a separate demuxer for each track, 2. have a demuxer that can seek tracks independently, or 3. seek around all the time, with some buffering to reduce the bad effects
[17:53] <Daemon404> 1 or 3 sound sanest
[17:53] <kierank> or just concede it doesn't fit within the lavf model
[17:53] <Daemon404> that too
[17:53] <kierank> as if that's going to happen
[17:54] <kierank> hmmm never thought about lavfi seeking
[17:54] <wm4> well, ubitux is looking for a working solution, so you can influence the result
[17:54] Action: kierank doesn't seek
[17:54] Action: kierank uses lavfi a lot now
[17:54] <j-b> wm4:  "open a separate demuxer for each track" is doable from VLC
[17:54] <j-b> calling a demuxer from a demuxer
[17:55] <Daemon404> uh
[17:55] <wm4> j-b: well, in my own code (mpv), it'd be most convenient to just open a demuxer per track
[17:55] <Daemon404> yeah you wouldnt do it in lavf
[17:55] <wm4> because a single demuxer expects that data is reasonably interleaved (for buffering etc.)
[17:56] <wm4> you can't adjust the packet timestamps timestamps either
[17:56] <wm4> because then dts could go backwards sometimes
[17:56] <Daemon404> [16:54] <+kierank> hmmm never thought about lavfi seeking <-- comign originally form avisynth-land, and later vapoursynth land
[17:56] <Daemon404> it's jarring to not be able to seek
[17:56] <nevcairiel> Do users actually request this for MPV? I don't think I've had one, and I get all the crazy requests usually
[17:56] <Daemon404> like going back 20 years
[17:56] <wm4> nevcairiel: no
[17:56] <j-b> I had 2 requests
[17:57] <wm4> still, it would be nice if ordered chapters could just work in lavf
[17:57] <wm4> and this seems like an opportunity to get this fixed
[17:57] <j-b> Digimetrics...
[17:58] <kierank> j-b: good, bad?
[17:58] <kierank> I decided that every single one of those companies who spams me by email or in a meeting gets gpl violation checked
[17:58] <j-b> kierank: isn't that used a LOT for broadcasterS?
[17:58] <kierank> I think 90% have been violating
[17:59] <kierank> j-b: I basically have concluded that all low to mid end stuff is gpl violating
[17:59] <kierank> because the team in india/ukraine are clueless
[17:59] <kierank> the high end stuff written in the west at least people are nont clueless
[17:59] <Daemon404> i wouldnt call elemental low to mid
[18:00] <kierank> i think they gave us all their non-dolby lavf patches
[18:00] <ubitux> wm4: j-b: it does
[18:01] <ubitux> but as i said it's kind of broken; i'm not sure it's because of the edit list
[18:01] <ubitux> but the playback had weird artefacts, like missing kf or something
[18:01] <ubitux> as if it was as i said just dropping packets
[18:02] <ubitux> wm4: btw, my filtergraph version works locally
[18:02] <ubitux> but i'm wondering about just exporting the timeline api wise
[18:02] <ubitux> and construct the filtergraph with ffmpeg.c+ffplay.c code
[18:03] <ubitux> (or export that api as well)
[18:03] <ubitux> other solution was to export a "timeline" parameter for a specific filter
[18:03] <ubitux> to simplify the filtergraph
[18:03] <ubitux> anyway... still undecided
[18:04] <ubitux> Daemon404: i could seek without any problem
[18:04] <wm4> maybe that's the sanest idea after all
[18:04] <ubitux> with the filtergraph
[18:04] <ubitux> because it's based on timestamps
[18:04] <wm4> (exporting the metadata, optional lavfi support)
[18:04] <ubitux> so after seeking in ffplay it was just working fine
[18:04] <ubitux> wm4: yeah but it requires exposing everything
[18:04] <wm4> wait what kind of graph is this
[18:04] <ubitux> i can't make it opaque
[18:04] <wm4> not -vf/-af, but complex_filter, right?
[18:04] <ubitux> wm4: the one you saw the other day
[18:04] <ubitux> -vf and -af
[18:05] <wm4> huh
[18:05] <ubitux> i mean, it's actually 2 filters
[18:05] <ubitux> so i had to export 2 meta, but i won't be like this at the end
[18:05] <ubitux> let me show you
[18:05] <wm4> either there's excessive buffering/decoding, or seeking only worked by coindidence
[18:05] <ubitux> well i guess it reconfigures the filtergraph on seeking
[18:05] <ubitux> ffplay already insert a bunch of filters
[18:06] <ubitux> wm4: https://github.com/ubitux/FFmpeg/commit/f77c882f3ac1d3c597a177308da0135f784d5ac4
[18:07] <wm4> j-b: is this the mailing list where all new libdvd* development happens: libdvdnav-devel at videolan.org ?
[18:07] <j-b> yes
[18:07] <wm4> thanks
[18:07] <j-b> wm4: de facto, yes.
[18:08] <ubitux> Daemon404: i can seek with this without any problem
[18:08] <wm4> j-b: is the dead former project still around separately?
[18:08] <ubitux> at least if it's not too badly interleaved
[18:08] <ubitux> but seeking with lavfi is not a problem here
[18:09] <wm4> ubitux: where's the audio part?
[18:09] <ubitux> wm4: not completely done yet
[18:09] <ubitux> i had only video segmentation for now
[18:09] <ubitux> (and start time for audio)
[18:09] <wm4> then this doesn't prove much
[18:09] <j-b> wm4: I don't think so
[18:10] <ubitux> i just use aselect and asetpts
[18:10] <j-b> wm4: the plan is to continue cleaning all this shit up
[18:10] <j-b> wm4: libdvcss 1.4.0 will come soon
[18:10] <ubitux> j-b: is there some doc planed or something?
[18:10] <ubitux> j-b: my opw student is going to use these libs; what resources do you recommend? (ml, irc, doc, ...)?
[18:12] <j-b> ubitux: which lib?
[18:12] <j-b> ubitux: the API of dvdread is too large
[18:13] <ubitux> i don't even know; dvdnav i suppose?
[18:13] <ubitux> the aim is to have an input device (same as format in ffmpeg context but in libavdevice)
[18:13] <ubitux> so we can ffmpeg -f dvd -i /foo/bar/bla.iso ...
[18:13] <j-b> menus?
[18:13] <ubitux> no
[18:13] <wm4> j-b: lol
[18:14] <ubitux> we don't care about the menu
[18:14] <j-b> ubitux: then, you want dvdread
[18:14] <j-b> ubitux: send her to #libdvd*
[18:14] <ubitux> you have a channel per lib?
[18:14] <wm4> is dvdread really usable for this purpose?
[18:14] <ubitux> i can't use dvdnav simple api without querying the menu?
[18:14] <wm4> the mplayer code which uses libdvdread code basically does everything manually
[18:15] <wm4> I think it should be possible to use dvdnav without menus
[18:15] <ubitux> iirc saste patch actually used dvdnav
[18:17] <Compn> kierank : wow the digi metrics guys replied quickly to your gpl violation bug ;p
[18:18] Action: Compn chuckles at mplayer dvdread ;P
[18:18] <Compn> didnt xbmc write their own dvd menu code ?
[18:19] <j-b> of course they did
[18:19] <j-b> ubitux: yes, why not?
[18:19] <Compn> was it any good 
[18:19] <ubitux> j-b: just curious
[18:20] <ubitux> a bit annoying though ;)
[18:20] <ubitux> i see no one in these channels though
[18:21] <j-b> well, some people, from MPlayer or XBMC might prefer a different channel than the vlc one
[18:21] <j-b> which I understand
[18:21] <ubitux> j-b: where are the "#libdvd* channels"?
[18:21] <wm4> Compn> didnt xbmc write their own dvd menu code ? <- what do you mean by this?
[18:21] <wm4> don'T they use libdvdnav?
[18:22] <wm4> and undocumented libdvdnav functions at that
[18:22] <wm4> like the function that actually allows you to seek correctly
[18:22] <wm4> (and I've actually got user complaints)
[18:22] <wm4> because normal libdvdnav seeking seeks by bitrate
[18:22] <Compn> wm4 : i think i got mixed up, they use libdvd* but wrote their own player ?
[18:23] <wm4> of course they have their own player
[18:23] <Compn> j-b : ubitux just wants to know if theres a mailing list or irc channel where his student can talk api questions and get help from others who know the dvd* code
[18:23] <j-b> Compn: yes, "#libdvd*"
[18:23] <j-b> aka, /j #libdvd*
[18:23] <ubitux> oh the '*' is actually the char, by bad
[18:24] <Compn> ehe
[18:24] <j-b> ubitux: I invited  you
[18:24] Action: Compn clears it up for ubitux :)
[18:24] <j-b> ubitux: one chan for lidvdcss, dvdread, dvdnav each would be crazy.
[18:24] <Compn> (i was also not thinking of using * in the name of the channel)
[18:24] <funman> /j #libavformat-devel
[18:24] <ubitux> j-b: yeah but that's how i interpreted your "<@j-b> ubitux: yes, why not?"
[18:24] <wm4> I didn't even know * was allowed in channel names
[18:24] <ubitux> j-b: and since you like to remind us that libav* should be separated...
[18:24] <ubitux> :P
[18:25] <wm4> funman: #libav*-devel?
[18:25] <cone-859> ffmpeg.git 03Michael Niedermayer 07master:086e29a01119: avcodec/libutvideoenc: fix leak of info array on error
[18:25] <cone-859> ffmpeg.git 03Michael Niedermayer 07master:f96fcba1e3bc: avcodec/libutvideoenc: Check avpicture_get_size() return code
[18:25] <funman> wm4: :)
[18:26] <Compn> j-b : thank you ,we were all confused about the * char :)
[18:27] <j-b> why would a * be forbidden?
[18:27] <wm4> it's forbidden in identifiers in most programming languages
[18:27] <wm4> clearly irc should follow these rules
[18:27] Action: wm4 ignores the use of "-"
[18:27] <j-b> IRC is a programming langauge?
[18:28] <wm4> it isn't? that would explain some things...
[18:28] <ubitux> i'd like spaces and utf-8
[18:28] <Compn> did you know having a domain name with - at the end is illegal ? so you cant have videlan-.org ? 
[18:28] <wm4> but you have to admit most found it unexpected
[18:28] <ubitux> and backslashes
[18:28] Action: koda wonders about $names
[18:29] <funman> Apart from the the requirement that the first character being either '&' or '#'; the only restriction on a channel name is that it may not contain any spaces (' '), a control G (^G or ASCII 7), or a comma (',' which is used as a list item separator by the protocol).
[18:29] <funman> name length up to 200 characters
[18:30] <ubitux> ok so we can actually have utf-8
[22:13] <cone-909> ffmpeg.git 03Michael Niedermayer 07master:e2829a8175de: avformat/mov: Disable XMP metadata by default
[00:00] --- Fri Dec 12 2014