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

[burek]

[00:05] <cehoyos> Compn: Could you test r10k with the directshow filter?
[00:07] <michaelni> kierank, i am not sure because it would lead to interlaced scaling being done on progressive video in many cases. See for example:  -i matrixbench_mpeg2.mpg -vf scale=1920:1024:interl=-1 -qscale 1 test.avi
[00:08] <kierank> michaelni: please read the ticket again
[00:08] <michaelni> kierank, please look at test.avi
[00:08] <iive> isn't there an interlace flag in the frame data?
[00:08] <michaelni> from the example above
[00:09] <kierank> where do I download matrixbench
[00:10] <michaelni> http://samples.mplayerhq.hu/benchmark/testsuite1/matrixbench_mpeg2.mpg
[00:10] <nevcairiel> well the reasoning for default interlace is that interlaced scaling on progressive looks "ok-ish" still, while progressive scaling on interlaced entirely destroys the image
[00:11] <iive> once again, isn't there a interlace flag set in the frame data?
[00:11] <kierank> yes 
[00:11] <michaelni> nevcairiel, i thought so too but the video in the above example doesnt exactly look ok-ish
[00:11] <iive> then why not use it?
[00:11] <kierank> the filter does
[00:12] <michaelni> yes when interl=-1 is set
[00:13] <iive> i don't understand, the best behaviour is to use interlace scaling for interlaced frames and progressive for progressive.
[00:14] <iive> why botch one or the other?
[00:14] <kierank> iive: read the code
[00:14] <iive> which code vf_scale?
[00:14] <kierank> yes
[00:15] <michaelni> iive, lots of videos have the interlaced flags set, even when the content actually is from progressive sources
[00:16] <iive> well, isn't there an interlace detect filter in ffmpeg?
[00:16] <michaelni> yes
[00:16] <nevcairiel> in my experience from real-world content, its usually not that many, and for default behaviour it would be acceptable to use it
[00:16] <iive> so... just put it before scale?
[00:16] <nevcairiel> its slow
[00:16] <cehoyos> nevcairiel:Isn't that a reason to leave the default (that is looks ok-ish)?
[00:16] <nevcairiel> the current default doesnt look ok-ish
[00:16] <cehoyos> If you forgot to use interlaced scaling, you see the issue.
[00:17] <kierank> michaelni: looks ok?
[00:17] <iive> well, for once, I'm absolutely against using interlaced scaling on progressive frames!
[00:17] <cehoyos> That is what I mean: Since you wouldn't immediately see the bad quality, you wouldn't notive that you should have set progressive scaling.
[00:17] <kierank> michaelni: i didn't encode to to avi
[00:17] <ubitux>  "split=2[a][b]; [a]scale=1920:1024:interl=-1[x]; [b]scale=1920:1024[y]; [x][y]blend=difference" yay.
[00:17] <ubitux> (difference128 more relevant maybe)
[00:17] <cehoyos> That is apart from the fact that I thought we all agree interlaced content is a bad thing.
[00:18] <kierank> interlaced *coded* content should be scaled interlaced
[00:18] <kierank> and the user should override it to progressive if they know the underlying content is progressive
[00:18] <kierank> mpeg-2 chroma subsampling was designed to do this
[00:18] <iive> kierank: WRONG!
[00:18] <iive> interlace must die
[00:18] <cehoyos> nevcairiel: All dvb sources are marked as interlaced but are very often progressive
[00:18] <kierank> cehoyos: wrong
[00:18] <nevcairiel> cehoyos: wrong
[00:19] <kierank> I tried to explain this to you in the ticket
[00:19] <cehoyos> What do you mean?
[00:19] <kierank> the coding method and the display method of the material are orthogonal
[00:19] <iive> and we should not cripple our software in order to support it by default.
[00:19] <nevcairiel> we have plenty 720p50 dvb broadcasts in germany, which are actually marked progressive
[00:19] <kierank> iive: when you get a clue, please come back
[00:19] <cehoyos> But only the coding method is written to the stream or do I miss something?
[00:20] <iive> kierank: so you are going into insults, instead of explaining and defending your position.
[00:20] <cehoyos> nevcairiel: Really? They were all marked interlaced when I last checked: Which program should I look at?
[00:20] <kierank> iive: read the ticket and the code
[00:20] <kierank> instead of just crying about interlaced
[00:21] <iive> kierank: no, i want YOU to explain what do YOU want to be done.
[00:21] <nevcairiel> cehoyos: ZDF HD for example
[00:21] <kierank> iive: I want to solve a ticket, therefore you must read the ticket to understand the context
[00:21] <iive> i'll read them, but you should be able to explain your position, without wasting time.
[00:21] <kierank> michaelni: the error is probably because you are encoding
[00:21] <cehoyos> Sorry, of course all 720p is marked as progressive, I meant the (hundreds?) of SD channels.
[00:22] <kierank> the content has been prefiltered for interlaced vieweing
[00:22] <Daemon404> iive, and you should not be able to piss over someone withotu any context
[00:22] <Daemon404> please kindly go forth.
[00:22] <cehoyos> Daemon404: I am sorry that I am currently around, please spare your insults while I am here.
[00:23] <Daemon404> s/please kindly go forth.//
[00:23] <Daemon404> dome
[00:23] <Daemon404> done*
[00:24] <Daemon404> anyway, ive read the ticket and agere with kierank here.
[00:24] <Daemon404> and my real world experience seems to match nevcairiel's wrt the flags
[00:24] <nevcairiel> I would say just to use the frame flags
[00:24] <Daemon404> i'd be inclined to agree
[00:24] <kierank> nevcairiel: yes, that's what setting the interlaced method does in vf_scale
[00:24] <kierank> it uses the frame flags
[00:25] <kierank> at the moment it's hardcoded to progressive
[00:25] <michaelni> there are various flags in mpeg2, we use the one the spec says should be used to determine interlaced/progressive, but maybe something else works better
[00:25] <nevcairiel> I use it to enable deinterlacing, and I very rarely ever encounter a problem where a progressive frame is being deinterlaced wrongly
[00:25] <cehoyos> As I understand, nevcairiel actually confirmed that nearly all dvb content is marked as interlaced
[00:25] <nevcairiel> I confirmed that interlaced content is marked interlaced, and progressive content is not :P
[00:25] <cehoyos> This sounds very unlikely: All SD channels are always marked as interlaced afair
[00:26] <cehoyos> That is not what you wrote above.
[00:26] <kierank> cehoyos: again read the ticket
[00:26] <kierank> PAL is interlaced
[00:26] <kierank> the material is filtered so as to be interlaced
[00:26] <kierank> it is not ffmpeg's job to override the flagging
[00:26] <kierank> the user should do that
[00:26] <nevcairiel> dvb is special, you can have a progressive movie with 2:2 telecine, and a truely interlaced overlay on top from ads or something
[00:26] <cehoyos> I am right now watching a PAL dvb stream with interlaced content
[00:26] <cehoyos> Please epxlain.
[00:27] <kierank> the upscaling will be very similar when doing interlaced upsampling on underlying progressive material
[00:27] <cehoyos> But not correct or am I wrong?
[00:27] <kierank> but interlaced material with an progressive upsample (the default) is totally broken
[00:28] <cehoyos> Yes, luckily you immediately see the issue and can choose the correct flags.
[00:28] <cehoyos> If the default will be changed, it will break typical encodes in a very subtle way.
[00:28] <iive> i could agree that vf_scale been hardcoded to progressive is bad thing. it should be autodetect based on frame flag.
[00:28] <cehoyos> No: That would always lead to bad encodes.
[00:28] <cehoyos> For dvb
[00:28] <cehoyos> And many dvd sources
[00:28] <iive> but if user wants to override the interlace, he can do it in the scale...
[00:29] <kierank> the specs have been designed such that interlace upsampling progressive material is very similar
[00:29] <cehoyos> Yes, luckily the user can choose the correct method.
[00:29] <kierank> cehoyos: so in my batch job encoding 10k files you want me to check them manually?
[00:29] <iive> it is absolutely wrong to set vf_scale to always do interlace scaling.
[00:29] <cehoyos> I thought that Michael showed an example where this is not correct or do I misunderstand?
[00:29] <kierank> cehoyos: looks fine to me?
[00:29] <cehoyos> Does idet not work for you?
[00:29] <iive> just because most dvb encoders doesn't set the flags correctly.
[00:30] <kierank> idet is a heuristic
[00:30] <cehoyos> But why don't you set interlaced encoding if you think this is the right choice?
[00:30] <cehoyos> I don't understand?
[00:30] <kierank> ???
[00:30] <kierank> interlaced encoding?
[00:30] <iive> meaning, the interlace flag is taken from the decoder
[00:30] <cehoyos> interlaced scaling for your 10k encodings...
[00:31] <iive> assuming that interlaced content would not be encoded as progressive, because it is inefficient.
[00:31] <kierank> cehoyos: that's what i am saying should be teh default
[00:31] <iive> you've written mpeg2 encoders, you should be the expert.
[00:31] <kierank> so that most things work
[00:31] <cehoyos> iive: All dvb content (that is: all SD dvb content) is marked as interlaced, including (progressive) movies and series.
[00:31] <kierank> the dvb encoder doesn't know what the underlying format is
[00:32] <kierank> it doesn't care
[00:32] <kierank> the input format is PAL which is defined as interlaced
[00:32] <iive> cehoyos: great, then kierank hacks would be automatically done.
[00:33] <cehoyos> Which is why we can not auto-detect interlaced nor choose interlaced scaling as default: Most users would not realize why their encodings are suddenly of worse quality
[00:34] <iive> cehoyos: that's my point!
[00:34] <kierank> the spec defines upscaling to be performed as interlaced
[00:34] <kierank> it is not ffmpeg's decision to do it otherwise
[00:34] <iive> kierank: what specs?
[00:34] <kierank> mpeg-2 specs for example
[00:34] <kierank> bt 601
[00:34] <kierank> as well
[00:34] <iive> kierank: mpeg-2 specs define progressive frames to be scaled as interlaced?
[00:35] <kierank> iive: probably to you they do since you just complain and don't read the specs
[00:35] Action: kierank adds iive to ignore
[00:35] <iive> kierank: tell me the paper and the title where this is defined.
[00:35] <kierank> michaelni: can you explain to me what is wrong with your clip?
[00:36] <michaelni> kierank, it looks quite bad
[00:36] <kierank> michaelni: can you make a screenshot?
[00:43] <michaelni> kierank,  http://ffmpeg.org/~michael/good.pnm vs. http://ffmpeg.org/~michael/bad.pnm
[00:45] <iive> well, I can't find anything about interlaced scaling in iso13818-2 (video coding).
[00:45] <iive> michaelni: in case kierank have really ignored me, ask him for exact reference to the standard.
[00:49] <kierank> if you really want then you could make it only do an interlaced *chroma* conversion
[00:50] <kierank> so make it follow the frame interlaced flags if the resolution doesn't change 
[00:50] <kierank> I think that's an upscaler bug though
[01:35] <Compn> cehoyos : not sure if i have r10k dshow setup
[01:38] <kierank> cehoyos: http://www.bitjazz.com/en/products/sheervideo/faq/formats/pixel_formats.php#r10k
[01:46] <cehoyos> Compn: https://www.aja.com/en/support/directshow
[01:46] <cehoyos> kierank: This link was already sent today with a remark that it appears they are not sure.
[01:47] <cehoyos> But this is actually irrelevant, I would like to know if somebody has the filter and can test playback.
[01:55] <Compn> downloading filter now
[01:56] <Compn> what sample do you want me to test ?
[01:56] <Compn> i dont have latest ffmpeg 
[01:57] <cehoyos> This has not much to do with FFmpeg.
[01:57] <cehoyos> First the two samples from our repo: 
[01:58] <cehoyos> ./V-codecs/R10k.mov and ./V-codecs/R10g.mov
[01:58] <cehoyos> Then the sample that doesn't work with FFmpeg:https://www.dropbox.com/s/6ugnjlivdhdlixt/10BitRGB444_r10k_2sec.avi
[02:00] <Compn> well not sure if wmp will play .mov
[02:01] <cehoyos> It does here, what version are you testing?
[02:01] <cehoyos> (No chance for current WMP?)
[02:02] <Compn> i have wmp11 
[02:02] <Compn> is it new enough ?
[02:04] <cehoyos> Please test and tell us.
[02:05] <Compn> probably need gabest mp4 demuxer (no , it wont open .mov)
[02:05] <cehoyos> Then please test the avi file
[02:06] <Compn> downloading now
[02:09] <Compn> wmp does not play it with aja installed
[02:10] <cehoyos> Does it play the output of ffmpeg -f lavfi -i testsrc -t 10 -vcodec r10k out.avi ?
[02:10] <cehoyos> Are our files played with a mov filter?
[02:10] <Compn> hmm i'm not sure i installed aja correctly, cant get any 10k to work 
[02:12] <cehoyos> Maybe you could answer on the mailng list that this link does not lead to a filter that helps?
[02:13] <jamrial> doesn't wmp11 use media foundation instead of dshow?
[02:14] <jamrial> wmp11 supports mov, but probably not files like that one that require dshow filters
[02:16] <jamrial> try mpc-hc and force the usage of aja instead of the internal decoder
[02:16] <Compn> downloading mpc-hc
[02:17] <Compn> (testing this on a vista box btw)
[02:22] <Compn> getting nothing with mpc-hc
[02:23] <cehoyos> Nothing?
[02:23] <Compn> mpc-hc could not render some of hte pins in the graph, you may not have the needed codec or filter installed on the system
[02:23] <Compn> for the avi
[02:24] <Compn> for the mov i get nothing.
[02:25] <jamrial> if you forced aja from the external filters menu and it still fails then no idea
[02:26] <Compn> yea external filters aja av render 0 > 3
[02:26] <Compn> graphedit also fails
[02:29] <Compn> course i could be doing something wrong :)
[02:30] <Compn> aja makes a quicktime codec
[02:30] <Compn> or did at one time
[02:30] <Compn> https://static.aja.com/assets/software/AJA_SoftwareCodec.zip
[02:31] <Compn> Install the AJA QuickTime codec on any machine without having to install the complete driver for an AJA hardware device.
[02:32] <cehoyos> The quicktime codec will not help with the avi file I fear.
[02:32] <cehoyos> My issue is that the avi file plays ugly with FFmpeg but I think the ugliness is correct: The user disagrees.
[02:39] <kierank> cehoyos: it breaks because of the 10 to 16-bit upconversion
[02:41] <cehoyos> kierank: How does your poc look that shows this?
[02:41] Action: Compn slinks away
[02:42] <kierank> i just looked at the code
[02:42] <cehoyos> No!
[02:42] <kierank> it's rgb48 so 16-bit rgb
[02:42] <cehoyos> Please test the sample before you comment, thank you!
[02:42] <cehoyos> https://www.dropbox.com/s/6ugnjlivdhdlixt/10BitRGB444_r10k_2sec.avi
[02:43] <cehoyos> And if you have a player that shows pretty colour bars for this file, please tell me how I can reproduce.
[02:51] <Compn> that file was made with lavf :P
[02:51] <Compn> ehe
[02:51] Action: Compn runs
[02:51] <Compn> >sample made with lavf, its invalid
[02:53] <cehoyos> Which file?
[03:11] <Tim_G> michaelni: You need documentation for the mpeg profiles patch
[03:24] <cehoyos> Compn: Which file was made with libavformat?
[03:54] <michaelni> Tim_G, added mpeg4_* to the list in the docs where the others are locally
[04:02] <Tim_G> michaelni: cool thanks
[04:02] <Tim_G> cehoyos: I think he was referring to https://www.dropbox.com/s/6ugnjlivdhdlixt/10BitRGB444_r10k_2sec.avi
[04:09] <cehoyos> I have to go to sleep now but maybe you could ask him how he found out?
[04:35] <Compn> oh i was wrong about it being lavf
[04:35] <Compn> just me being stupid
[04:35] Action: Compn hides under a rock
[04:35] <Compn> sorry carl
[04:35] <Compn> cant even read mplayer output correctly anymore
[04:41] <cone-45> ffmpeg.git 03Michael Niedermayer 07master:ac08c5c0adcb: avformat/mux: 2 subtitle packets could have the same DTS
[07:13] <visiot> can i control udp transmission rate while streaming
[07:32] <visiot> while multicasting using ffmpeg i'm getting a jitter on my HQAM 40 to 60 ms. i'm capturing screen. if i use cvlc on the same i'm getting jitter of 1 to 3 ms only. how can i reduce jitter size on ffmpeg
[07:44] <av500> kierank: yep, saw it
[08:33] <ubitux> --enable-nvenc and --enable-libnvenc enabling 2 different things?
[08:33] <ubitux> that's really what you want nvidia?
[08:33] <ubitux> ;_;
[09:30] <nevcairiel> they just dont think :p
[11:18] <visiot> ubitux : can you tell me how can i slow the udp transmission rate while multicasting 
[11:18] <ubitux> no idea
[14:18] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:748ad112e2c0: avcodec/ffwavesynth: Use av_freep() to avoid leaving stale pointers in memory
[14:42] <ubitux> cehoyos: freedesktop.org?
[14:46] <cehoyos> If we agree that the nvenc header is not free and can only be used in FFmpeg with non-free than nothing changes if a wrapper gets added to FFmpeg.
[14:46] <cehoyos> If the wrapper is a system library like vdpau, that does - imo - change the issue.
[14:47] <cehoyos> Does the xcb-shm patch work on your system?
[14:47] <ubitux> haven't tested
[14:48] <ubitux> cehoyos: the "wrapper" is lgpl so i don't see what's your point
[14:49] <ubitux> the header as well
[14:49] <iive> cehoyos: generally headers are not considered copyrightable
[14:49] <cehoyos> How can it make a difference if a header - if we consider it non-free - is included by a c file inside the FFmpeg sources called libnvenc.c or by a file called libnvwrapper.c?
[14:49] <ubitux> where do you see a non-free header?
[14:49] <cehoyos> My point is just that I like to hear the FSF's opinion on this, and I believe we agreed about this.
[14:50] <ubitux> my main concern with the patch is the duplication of current nvenc
[14:50] <ubitux> which is going to raise a lot of complains if this is merged
[14:50] <cehoyos> We should not allow the second patch we get for the same problem to be allowed something that we did not allow the first patch.
[14:50] <cehoyos> Of course!
[14:50] <cehoyos> Please tell that on the mailing list.
[14:50] <wm4> why don't we tell nvidia that we don't want to promote their shit under these conditions?
[14:51] <cehoyos> We already did...
[14:51] <wm4> good
[14:51] <cehoyos> We already promoted their shit into our codebsae.
[14:51] <cehoyos> codebase
[14:52] <ubitux> cehoyos: will do, but  i still don't get what's the legal problem with the patch
[14:53] <cehoyos> that the header contains a note "do not use this header for anything that looks like open source". Note that I am not saying we shouldn't ignore this but that we should ask somebody who knows better.
[14:53] <ubitux> what header?
[14:53] <cehoyos> We already have enough copyright problems, I would like not to add one more knowingly
[14:54] <cehoyos> The nvidia header, sorry I don't understand your question.
[14:54] <cehoyos> (We had the discussion already before 2a428db5 was committed.)
[14:54] <ubitux> are you talking about "All rights reserved"?
[14:54] <ubitux> or a file?
[14:55] <cehoyos> No, where do you see that?
[14:55] <ubitux> i'm just wondering about what you are talking about
[14:55] <ubitux> what are you refering to by "header"
[14:55] <ubitux> ?
[14:55] <cehoyos> The nvidia header
[14:55] <ubitux> what is that?
[14:55] <cehoyos> nvapienc.h or similar
[14:55] <BtbN> nvEncodeApi.h
[14:56] <ubitux> thank you.
[14:56] <iive> is it installed in the system? or included in the patch/ffmpeg?
[14:56] <BtbN> You need to download it from nvidia
[14:56] <cehoyos> It is included by nvenc.c and the new patch
[14:56] <ubitux> and it's necessary?
[14:56] <ubitux> nvenc seems not to use it
[14:56] <cehoyos> Definitely
[14:56] <BtbN> Of course it uses it
[14:56] <ubitux> ah mmh...
[14:57] <ubitux> my bad
[14:57] <cehoyos> It's the fourth line afaict
[14:58] <ubitux> so we already have the issue
[14:58] <cehoyos> No, the existing encoder is marked non-free
[14:59] <ubitux> alright, so you just need to die_license_disabled nonfree nvenc
[14:59] <ubitux> libnvenc*
[14:59] <cehoyos> I thought we agree that we don't want the patch at all?
[14:59] <ubitux> yes sure
[14:59] <ubitux> but it's better if we explain what is wrong
[14:59] <cehoyos> (But I assumed we would like to see a system librray that allows us to use nvenc without non-free, or am I wrong?)
[15:00] <BtbN> If nvidia itself releases an open source library for nvenc, that would propably circumvent any licensing issues
[15:00] <BtbN> as they can't sue themselves
[15:00] <cehoyos> I don't think we fear to be sued by Nvidia...
[15:00] <cehoyos> (We certainly aren't)
[15:01] <BtbN> nvidia doesn't seem to care at all. There are other projects who just added that header to their own repos.
[15:01] <BtbN> And nvidia even promotes those
[15:02] <BtbN> No idea if they are even aware of the license they put there
[15:04] <wm4> lol
[15:07] <Compn> nvidia wants it in ffmpeg because tools that use nvenc will call in ffmpeg
[15:07] <Compn> otherwise nvidia has to submit it to every stupid distro and have the same 'oh we dont want to promote nvidia' talk that cehoyos is giving 
[15:07] Action: Compn plays devils advocate
[15:08] <Compn> but yeah vdpau reference makes sense
[15:08] <Compn> why dont they just put it in vdpau ?
[15:08] <iive> don't give them ideas!
[15:09] <BtbN> vdpau is a pure _de_coding api
[15:09] <wm4> Compn: that's what intel did (they put encoding into their own hw decoding lib)
[15:09] <Compn> BtbN : so what
[15:09] <BtbN> wm4, did you ever try vaapi based encoding?
[15:09] <iive> hum... actually that kind of makes sense.
[15:09] <BtbN> It's horrible. Worst api i have seen in a while.
[15:09] <wm4> BtbN: fortunately not
[15:09] <wm4> I saw that wayland uses it
[15:09] <wm4> or rather, weston
[15:09] <Compn> BtbN : having another header in vdpau wont change that
[15:09] <BtbN> You have to generate the h264 nal bitstream manualy
[15:10] <BtbN> Compn, well, the main reason propably is that there is no vdpau on windows.
[15:10] <Compn> ah
[15:10] <wm4> BtbN: isn't that somewhat similar to hw decoding? there you also need to decode parts of the bitstream yourself
[15:10] <BtbN> wm4, not the h264 nal
[15:10] <cehoyos> What talk am I giving?
[15:10] <BtbN> you have to do the de-slicing yourself
[15:11] <cehoyos> Can you explain why you believe that the file (which file?) yesterday was written by libavformat?
[15:11] <Compn> cehoyos : i was wrong about the r10k avi sample being lavf
[15:11] <Compn> i was reading mplayer output incorrectly, my bad.
[15:11] <BtbN> wm4, https://github.com/BtbN/vlc-vaapi-enc i wrote that a while ago. It works, but the code is a huge pain.
[15:11] <cehoyos> np, I already sent a patch when the user provided a new ("better") sample.
[15:11] <BtbN> It's such a huge pain that intel itself is writing a wrapper library around libva.
[15:12] <BtbN> so you don't have to deal with libva
[15:12] <Compn> cehoyos : hopefully it works for that user :)
[15:13] <BtbN> https://github.com/01org/libyami is anyone is interested
[15:15] <cehoyos> ubitux: The private options are what makes the patch a good idea...
[15:15] <cehoyos> At least this is how I understand others' comments, I don't care much about h264 encoding.
[15:15] <ubitux> cehoyos: the x264 option mapping ?
[15:15] <cehoyos> Yes, this was welcomed iirc
[15:15] <ubitux> :/
[15:15] <ubitux> my bad then
[15:15] <cehoyos> (And it makes a lot of sense afaict)
[15:15] <Compn> anyone talk to x264 about this patch ?
[15:15] <cehoyos> Why?
[15:16] <Compn> just for fun i guess
[15:16] <ubitux> cehoyos: the fact that some option are compatible with libx264 is a good thing
[15:16] <cehoyos> The easiest and best thing imo would be to port the options from the Nvidia patch to the existing encoder
[15:16] <ubitux> but that 90% of them are unusued...
[15:16] <cehoyos> Sorry, then I misunderstood you
[15:16] <Compn> is timo still around ?
[15:16] <Compn> to maintain his nvenc ?
[15:17] <wm4> BtbN: so why does v4l apparently include encoders and decoders?
[15:17] <cehoyos> I understand your concern, I don't know what's the best solution
[15:18] <Compn> as there is no technical reason to disallow the patch from being merged into the tree... commit it, emotional reasons be damned!
[15:18] Action: Compn runs
[15:19] <cehoyos> I believe a license issue is stronger than a technical issue, don't you agree?
[15:19] <ubitux> there are both Compn 
[15:23] <BtbN> wm4, hm?
[15:24] <BtbN> v4l is yet another api that hw de/encoders can support
[15:26] <wm4> BtbN: that seems odd... well whatever
[15:27] <nevcairiel> video apis on linux is a odd world
[15:31] <BtbN> v4l is common for special hw encoder hardware. Like the encoders in tv tuner cards or capture cards.
[15:31] <Compn> cehoyos : in the file that they arent asking us to distribute ?
[15:31] <ubitux> Tim_G: adding flags to framecrc? i don't think that's a good idea
[15:32] <ubitux> ah, you meant the shell function, meh, my bad
[15:36] <Compn> ubitux : or what license issue ?
[15:36] <Compn> bring it up on the list ?
[15:36] <ubitux> i did
[15:37] <Compn> hmm i maybe missing such email
[15:42] <Compn> oh i see new email from you now
[15:42] <Compn> :)
[15:43] <Compn> that offhanded comment about the license was it ?
[15:43] <Compn> harumph
[15:44] <Compn>  - There are still some license uncertainties about the licensing (see
[15:44] <Compn>    "die_license_disabled nonfree nvenc" in the configure)
[15:44] Action: Compn cant help
[15:44] Action: Compn gone
[16:08] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:db0a52d611d7: avcodec/ituh263enc: Check den==0 in ff_h263_aspect_to_info()
[16:08] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:827af242308e: avutil/rational: Check that av_reduce() returns values within the requested max
[16:12] <aetasx> what was that x264 discussion about?  I tried to go through but I think the point scrolled off the top of my chat buffer
[16:13] <ubitux> all the option from libx264 encoder are copied in the libnvenc patch
[16:13] <ubitux> but most of them are unused/have no effect
[16:14] <aetasx> *shrugs*  frankly if none of you guys know what the hell they do, I'd probably just leave them to x265-options to avoid confusion
[16:14] <aetasx> err 4
[16:15] <aetasx> I mean one thing ffmpeg isn't lacking on is command-line flags
[16:15] <ubitux> are you the author of the patch?
[16:16] <aetasx> nah
[16:17] <ubitux> http://pngmini.com/lossypng.html another filter suggestion
[16:19] <aetasx> how does that have anything to do with png itself?  can't you do that with any image format?
[16:19] <aetasx> well, most
[16:20] <ubitux> you can apply such filter to any image
[16:20] <ubitux> it just make the png compression way more effective
[16:21] <aetasx> yeah, it just reads like its some png-specific behavior though
[16:25] <aetasx> so this is just the gui page for a few different libs?
[16:26] <ubitux> yeah you need to dig a bit more
[16:26] <ubitux> he made a package or something
[16:26] <aetasx> yeah Im looking at https://github.com/pornel/pngquant/
[16:28] <aetasx> the lib code in here looks at least separated off from the png-specific stuff
[16:32] <aetasx> where'd the request come in from?
[16:35] <ubitux> i just came accross this
[16:38] <aetasx> only thing I don't understand is why the lib is framed as being png-specific despite even it being called libimagequant
[16:39] <aetasx> seems like it would just turn people away that might otherwise have a use for it
[16:41] <aetasx> looks like hes got a sponsor for it, maybe you can squeeze some money out of them too ;)
[19:01] <aetasx> Can someone comment on this for me?  https://github.com/lachs0r/mingw-w64-cmake/commit/d3501226937629223d93a73670216931cb161811
[19:01] <wm4> aetasx: why don't you ask lachs0r
[19:03] <aetasx> wm4: I don't need to.  The behavior hes talking about does cause build failures.
[19:03] <wm4> hopefully he reported it somewhere
[19:04] <aetasx> I'm not sure, mingw had removed the requirement of having to have _POSIX defined in order to use localtime_r and gmtime_r a month ago and just recently added it back in so now some things are getting broken including wxWidgets
[19:04] <aetasx> http://sourceforge.net/p/mingw-w64/mailman/message/33167130/
[19:05] <nevcairiel> mingw-w64 is driven by many morons, they do stupid things all the time
[19:05] <wm4> wow that's a bad commit
[19:05] <aetasx> I sort of got that impression when they started pushing out changes like that without any public dialog
[19:05] <nevcairiel> although ffmpeg builds fine with the latest stable release for me, but i dont use their abomination of a pthread clone
[19:06] <aetasx> Are you using a mingw from a release made after it the 19th or so?
[19:07] <nevcairiel> if there was a very recent release, i may be on the previous stable still
[19:07] Action: nevcairiel checks
[19:07] <nevcairiel> 3.3.0 still seems to be the latest stable release, that works fine for me
[19:08] <nevcairiel> but like i said, i dont use their pthreads dealy since in my experience its just broken
[19:08] <wm4> I've written my own win32 pthread impl 2 days ago; unfortunately it just deadlocks
[19:08] Action: wm4 has trouble to debug it
[19:08] <nevcairiel> whats wrong with pthreads-w32
[19:09] <wm4> too GNU
[19:09] <nevcairiel> working fine for me for a long time now
[19:09] <nevcairiel> although i build ffmpeg with w32threads now
[19:09] <aetasx> Im not sure, the change was made in the crt headers though, not in one of the threading implementations
[19:10] <aetasx> you can't tell what the hell is going on considering nothing is documented on it
[19:11] <aetasx> frankly if you're going to commit something that may have breaking-level changes, I would expect more of a commit message than "Adding these checks back in..."
[19:20] <cehoyos> michaelni: There may be a bug in flv demuxer: https://trac.videolan.org/vlc/ticket/12389
[19:23] <aetasx> nevcairiel: Ill check out pthreads-win32.  Still, you would think their own implementation would work with their own builds
[19:27] <aetasx> cehoyos: no clue but I can say that I constantly work with really trashed flv files and a fair amount of them simply crash vlc out
[19:46] <Tim_G> nevcairiel: IIRC pthreads-win32 is dead
[19:46] <nevcairiel> dead or not, it works fine
[19:47] <Daemon404> we could certainly benefit from a modern impl
[19:47] <Daemon404> that doesnt cripple itself for the sake of XP
[20:05] <wm4> most of pthreads maps quite well to vista+ APIs these days
[20:07] <wm4> "someone" should collect all the hacks, and put them under a liberal license into a repo
[20:07] <wm4> so every project can stop NIHing its own pthread wrapper
[20:08] <aetasx> maintaining IE compatibility set internet tech back years on its own
[20:21] <Daemon404> wm4, youd probably want something more like what mingw does
[20:21] <Daemon404> 'public domain'
[20:21] <Daemon404> not a license per se
[20:22] <wm4> yeah
[20:25] <nevcairiel> not every country follows the concept of public domain, so using something very liberal but still license-y like MIT might be clearer
[20:25] <Daemon404> those still require you to reproduce author info 
[20:26] <Daemon404> mingw has some sort of explicit disavowing of all rights
[20:26] <Daemon404> iirc
[20:26] <nevcairiel> like gnu? :p
[20:26] <Daemon404> ?
[20:27] <nevcairiel> dont they make you give up any and all rights as well
[20:28] <Daemon404> thats not what i meant
[20:28] <Daemon404> i meant mingw's headers all say the author gives up all rights and use it however you want
[20:28] <Daemon404> or something like that
[20:29] <nevcairiel> german law makes that impossible, fwiw
[20:29] <nevcairiel> i always retain the most basic rights to everything i create
[20:29] <nevcairiel> unless i do it as part of my job, then the company has this right
[20:29] <aetasx> you apparently don't have the right to give them away :p
[20:30] <nevcairiel> its primarily designed so that artists can still protect their art from being defaced or something like that, even after the work was sold
[20:31] <aetasx> sounds like one hell of an EULA
[20:34] <nevcairiel> many countries seem to have similar provisions in copyright law
[20:36] <aetasx> corporations are generally treated as people over here so they'd have to try and make some sort of exception
[21:40] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:256df8a2fafa: libavformat/cdxl: fix duration in case of overflow
[23:11] <cone-867> ffmpeg.git 03Carl Eugen Hoyos 07master:7905bd555573: Fix decoding for little endian Aja Kona 10-bit RGB.
[00:00] --- Tue Dec 30 2014