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

[burek]

[00:31:44 CEST] <Compn> i've moderated that mmx guy btw
[00:31:47 CEST] <Compn> llogan ^^
[00:32:11 CEST] <Compn> if he has a patch, ok. otherwise he needs to move to ffmpeg-user
[00:32:33 CEST] <Compn> our developers are too easily distracted by other software projects to deal with bugreports :D
[00:33:00 CEST] <Compn> so we need to keep em seperated to ensure more work on ffmpeg and less 'your software sucks' 'nuh uh' type threads
[00:34:16 CEST] <Compn> guess i should send him a mail... no one likes silent moderation
[00:43:47 CEST] <cone-172> ffmpeg 03Steven Liu 07master:be1d32492e58: avformat/hlsenc: support multi level path in m3u8 with filename
[00:51:56 CEST] <Chloe> Compn: aha, I think there were actually a few other devs looking into fixing musl as well. 
[00:52:20 CEST] <Chloe> well, 'fixing'.
[00:56:24 CEST] <Compn> i talked to dalias (musl creator) , he said it was ffmpeg bug 
[00:56:37 CEST] <llogan> Compn: i wasn't really following that discussion. you moderated the aetey.se guy?
[00:56:47 CEST] <Compn> there might be something that can be done in musl to make it fail better, but ...
[00:56:48 CEST] <Compn> llogan : ya
[00:57:00 CEST] <llogan> did you simply set the mod flag on his account?
[00:57:03 CEST] <Compn> yes
[00:57:13 CEST] <Compn> is that what i should do ?
[00:58:00 CEST] <Compn> Chloe : feel free to join #musl and learn through osmosis :P
[00:58:10 CEST] <llogan> Compn: sure, if you think there is sufficient reason to do so and if you are willing to moderate each message from him in the queue
[00:58:33 CEST] <Compn> posting off topic on devel list, yep
[00:58:50 CEST] <Chloe> Compn: I know it's an ffmpeg bug. It's even in the sysv spec. 
[00:58:53 CEST] <Chloe> and I'm already in #musl
[00:58:56 CEST] <Compn> :)
[00:59:12 CEST] <Chloe> their bin_index function is funky, now that I actually understand it
[00:59:37 CEST] <Compn> submit patch if you want :P
[00:59:53 CEST] <Chloe> (not that I can think of a better way to do it)
[01:03:44 CEST] <Compn> entirely too much time spent on this already :E
[01:03:45 CEST] <Compn> ehe
[01:04:22 CEST] <Compn> we might need to scan the rest of the codebase for similar spec violations
[01:04:33 CEST] <Compn> i wonder if we could script it or what we would need to do.
[01:04:54 CEST] <Compn> Chloe : any ideas? 
[01:05:17 CEST] <Compn> where there is one bug... there are duplicate bugs :D
[01:05:48 CEST] <Chloe> we could make sure the standard library uses floats in every function
[01:05:51 CEST] <Chloe> and then run fate
[01:06:18 CEST] <Chloe> that's just one violation though, but it'd cover it across the codebase
[01:06:20 CEST] <Compn> hmmmmmm sounds like a plan
[01:06:35 CEST] <Compn> or just run fate with musl
[01:06:50 CEST] <Chloe> but not every musl standard library function uses floats
[01:06:55 CEST] <Compn> ah
[01:07:14 CEST] <Chloe> this was you'd be able to check everywhere, but then again idk the benefit of that
[01:07:17 CEST] <Chloe> way*
[01:08:58 CEST] <Chloe> (I don't seriously suggest doing this, it sounds like more effort than it's worth)
[01:11:48 CEST] <iive> Compn:  the thing is that musl is using a lame hack
[01:12:13 CEST] <atomnuker> rcombs: PCE patch for the aac encoder's on the ML, which layouts do you need support for?
[01:12:33 CEST] <iive> it might be clever, but it is quite hard to figure out what it does and on top of that - it is probably a lot slower than doing an naive implementation.
[01:12:49 CEST] <Chloe> iive: the offer to replace it with something faster is there
[01:13:06 CEST] <iive> Chloe: i didn't see the patch.
[01:13:45 CEST] <Chloe> iive: I mean, the musl people said they would replace it if someone write something faster
[01:13:51 CEST] <Chloe> wrote*
[01:14:03 CEST] <rcombs> atomnuker: BD-style 7.1, primarily
[01:14:36 CEST] <atomnuker> what's different in the bd 7.1?
[01:14:50 CEST] <iive> Chloe: i think there is gcc built-in that actually turns into single asm op on 686+
[01:14:51 CEST] <Compn> rcombs : do you have the bd 7.1 spec for atomnuker to map ?
[01:15:24 CEST] <Chloe> iive: I dont think that function does what you think it does
[01:15:58 CEST] <rcombs> atomnuker: AV_CH_LAYOUT_7POINT1 vs AV_CH_LAYOUT_7POINT1_WIDE_BACK
[01:17:39 CEST] <atomnuker> oh, ok
[01:18:50 CEST] <iive> Chloe: log2? Nicolas mentions that. And there is asm op that returns the location of first bit or something....
[01:19:37 CEST] <rcombs> atomnuker: also, would be nice to distinguish between 5POINT1 and 5POINT1_BACK
[01:19:39 CEST] <Chloe> iive: it's similar to a log2. It's actually a log2()*4 where it's linear in-between the powers of two
[01:26:05 CEST] <iive> yeh, that would need like 2 more asm ops 
[01:32:38 CEST] <microchip_> rcombs: is BD 7.1 wide_back ?
[01:32:53 CEST] <rcombs> no, AAC's native 7.1 layout is
[01:32:59 CEST] <microchip_> oh ic
[01:33:09 CEST] <rcombs> for ~some reason~
[01:33:35 CEST] <rcombs> though some decoders treat the AAC layout like regular 7.1 because nobody actually uses wide_back
[01:33:55 CEST] <rcombs> so if you want reliable wide_back you need PCE and if you want reliable regular 7.1 you need PCE
[01:34:11 CEST] <rcombs> if you use the native layout, it depends what the decoder's assumptions are
[01:40:48 CEST] <JEEB> oh yes, the case of 7.1 AAC
[01:40:54 CEST] <JEEB> always the fun one
[01:44:43 CEST] <atomnuker> I don't think PCEs can help you here
[01:45:21 CEST] <atomnuker> or wait, maybe they can
[01:45:39 CEST] <atomnuker> if the wide channels are still considered back channels
[01:46:14 CEST] <atomnuker> so if you have "LB WLB CB WRB RB" in the back row and you signal 2 CPEs and once SCE
[01:46:36 CEST] <atomnuker> but the thing is the decoder will still have to somehow map that arrangement to wide back
[01:46:59 CEST] <atomnuker> so really, nothing's changed in terms of the decoder having to guess
[02:06:06 CEST] <Chloe> if anyone wants to optimise a non-float bin_index, http://sprunge.us/MTAJ
[02:06:42 CEST] <Chloe> oops missing the macro, http://sprunge.us/EgQM
[02:42:55 CEST] <rcombs> is upload.ffmpeg.org down?
[02:44:02 CEST] <rcombs> I'd like to get https://puu.sh/rsOdK/e9eca8a945.ts placed somewhere less ephemeral; filename could be e.g. "long-incorrect-duration.ts"
[05:21:27 CEST] <Compn> rcombs : yes down. waiting on j-b
[05:34:39 CEST] <rcombs> thanks
[08:17:33 CEST] <rcombs> michaelni: do you have that file you mentioned in https://patchwork.ffmpeg.org/patch/507/?
[08:18:55 CEST] <cone-296> ffmpeg 03Rodger Combs 07master:63fbeebf6ecb: configure: add linker export script support on Darwin
[08:20:39 CEST] <cone-296> ffmpeg 03Rodger Combs 07master:14fe54bbfb98: lavf/mpegtsenc: fix autobsf when the first NAL is 0x1<XX> bytes
[08:25:42 CEST] <rcombs> ubitux: re: https://patchwork.ffmpeg.org/patch/524/ , ASS text between {}s that doesn't match a tag is treated as a "comment" (not displayed), but { and everything after it is displayed normally if there's no matching }
[08:25:52 CEST] <rcombs> so the test is wrong
[08:27:43 CEST] <ubitux> but this is textenc from srt
[08:28:08 CEST] <ubitux> if you have {foo} in a srt, you don't want to drop it
[08:28:37 CEST] <ubitux> (especially not in a text export)
[08:29:16 CEST] <rcombs> SubRip_capability_tester.srt is super wacky
[08:29:27 CEST] <rcombs> it's got a bunch of ASS syntax that's clearly targeting libass or VSFilter
[08:31:14 CEST] <ubitux> what happens to {{{ hello }}}?
[08:31:21 CEST] <rcombs> I don't know what would display it as the text implies (with e.g. {foo} displayed)
[08:31:26 CEST] <rcombs> ubitux: that would render as }}
[08:31:58 CEST] <rcombs> there's no nesting
[08:32:03 CEST] <rcombs> you can pull up Aegisub and try it
[08:32:52 CEST] <rcombs> there's also no escaping mechanism, so there's no way to display e.g. "{}" in a single event without a custom font or fullwidth characters or rendering the characters out to vector drawings
[08:33:00 CEST] <ubitux> OK so; do we really want to honor ASS comments in SRT? or do we prefer to honor random patterns by user (that also means following the specs)
[08:33:22 CEST] <ubitux> that is, do you think there is more ppl using {foo} as a comment mechanism in srt, or as a fancy ascii styling
[08:33:44 CEST] <rcombs> so, the question there is what renderer they're targeting
[08:33:56 CEST] <ubitux> ah; you can't escape {}?
[08:33:58 CEST] <rcombs> what do people use to display subtitles other than VSFilter and libass
[08:34:08 CEST] <rcombs> (both of which have identical behavior around this)
[08:34:19 CEST] <rcombs> (VSFilter came first and libass mimics it very carefully)
[08:35:31 CEST] <rcombs> there are also MicroDVD-style tags in this, which VSFilter handles (i.e. the style they indicate is applied) but libass does not (neither executed nor displayed as text)
[08:35:31 CEST] <JEEB> I still remember the stories of VSFilter coming to life
[08:35:58 CEST] <JEEB> or actually I might only remember ASS, VSFilter might be even older
[08:36:34 CEST] <rcombs> and then there are HTML-style tags, which are all well and good in SRT since the parser is expected to handle them, but if you put them in ASS then VSFilter will handle them (though I don't know what it does about unrecognized ones) and libass will display them as text
[08:37:10 CEST] <JEEB> :D
[08:37:22 CEST] <rcombs> ubitux: my point with that patch was that if you have {}-style comments in ASS and you convert to SRT, the comments should be dropped
[08:38:47 CEST] <ubitux> yes i understand
[08:38:49 CEST] <rcombs> it only affects SRT since we use ASS as an intermediate
[08:39:01 CEST] <rcombs> (SRT input, that is)
[08:39:58 CEST] <rcombs> maybe the intermediate should be an alternate form of ASS that has backslash escapes for \ and {}, which we drop on ASS output
[08:40:19 CEST] <ubitux> yeah sure; i still think they should be displayed verbatim, as it's more likely to have them used that way
[08:40:27 CEST] <ubitux> (IMO)
[08:40:57 CEST] <rcombs> that would imply that there's a SRT renderer somewhere that handles {\an8} but also displays {foo}
[08:41:19 CEST] <rcombs> or that the test sample has mutually incompatible expectations
[08:41:42 CEST] <ubitux> i thought it was a good trade of
[08:42:03 CEST] <ubitux> because writing "{\an8}" in a srt is very unlikely to mean something else than ass markup
[08:42:17 CEST] <ubitux> but writing {foo} could really meant displaying it as such in a srt
[08:42:34 CEST] <rcombs> so it's the latter (mutually incompatible expectations)?
[08:42:49 CEST] <rcombs> (I guess that'd be pretty ~subtitles~)
[08:42:51 CEST] <ubitux> we're punishing users writing valid srt here
[08:43:17 CEST] <rcombs> SRT or whatever other input format that happens to have ASS-like markup
[08:52:01 CEST] <rcombs> ubitux: so, seems like our best route is probably to add functions for handling input that "might contain ASS tags but also might contain {}s expected to be treated as plaintext", and convert that to a backslash-escaped internal form, and then handle the backslashes in ass_split
[11:56:47 CEST] <jdskcn> compn: you there ?
[12:18:00 CEST] <michaelni> rcombs, i think it was this: http://samples.ffmpeg.org/mov/c3226e01-83b5-49a2-4279-14ac6e9a9ac3
[13:06:39 CEST] <cone-587> ffmpeg 03Timo Rothenpieler 07master:5d4fea88d485: avcodec/cuvid: don't align frame size
[13:09:06 CEST] <wm4> libavutil.pc has completely broken library deps if hwcontext impls are enabled
[13:10:20 CEST] <BtbN> in what way broken?
[13:14:29 CEST] <jkqxz> Yes, they are.
[13:16:35 CEST] <jkqxz> There was resistance to the obvious fix (just change to "$extralibs"), so it stayed like that.
[13:17:01 CEST] <BtbN> what exactly is broken in there? It looks fine to me.
[13:18:04 CEST] <jkqxz> The package config files don't give you a dependency on libva*, libvdpau, etc.
[13:19:02 CEST] <BtbN> hm
[13:19:25 CEST] <jkqxz> ("$extralibs" includes everything, so it would make lavu depend on things like libx264, hence the resistance to that answer.)
[13:28:35 CEST] <BtbN> Anyone happens to know where in ffmpeg*.c the InputStream framerate is set?
[13:28:43 CEST] <BtbN> I can't find it anywhere, is it set at all?
[13:33:26 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg_opt.c;hb=HEAD#l740> ?
[13:33:53 CEST] <BtbN> hm, so the input stream framerate is completely unset unless parsed from cli
[13:36:11 CEST] <BtbN> that even seems to work...
[13:38:04 CEST] <ubitux> https://ispc.github.io/ispc.html
[13:38:06 CEST] <ubitux> opinions?
[13:46:02 CEST] <BtbN> Yes, it does work. So explicitly setting the doubles input framerate makes the cuvid deinterlacer work with the ffmpeg cli.
[13:46:24 CEST] <BtbN> So, "./ffmpeg -r 50 -deint adaptive -c:v h264_cuvid -i /mnt/union/videos/whatislife-creditroll.mkv ...", with the video being 25 fps.
[13:48:54 CEST] <dskjb> \msg
[13:50:24 CEST] <BtbN> philipl, ^
[13:54:08 CEST] <nevcairiel> ubitux: the entire concept behind that is not entirely well suited for traditional cpus, so probably targeted at high-core co-processors
[14:27:33 CEST] <BtbN> Isn't there also some gcc project that create OpenCL kernels automatically, and runs normal code on the GPU whenever it makes sense?
[15:28:33 CEST] <dskjb> what does ticket closed means ? what more info is required regarding #5875 ? whole story is written there
[15:33:33 CEST] <BtbN> The actual video files.
[15:38:55 CEST] <dskjb> BtbN: they can be downloaded. links are listed
[15:39:02 CEST] <BtbN> where?
[15:40:10 CEST] <dskjb> whole page starts with original page video link
[15:40:26 CEST] <BtbN> that's some website which asks me to install Flash
[15:40:27 CEST] <nevcairiel> there is no video link in there, just flash links
[15:40:36 CEST] <BtbN> And then a deeplink to the swp object
[15:41:00 CEST] <dskjb> yea, original page link and video playing link
[15:41:14 CEST] <dskjb> a person needs to download from there
[15:41:28 CEST] <dskjb> steps to download are also listed
[15:41:46 CEST] <BtbN> For the ticket to be valid it needs all the input files used
[15:41:57 CEST] <dskjb> video file is big
[15:42:19 CEST] <dskjb> are video files kept along with bug reports ?
[15:42:38 CEST] <BtbN> If they are smaller than 5MB, trac accepts them
[15:42:50 CEST] <BtbN> If not, some persistent file hoster or upload.ffmpeg.org has to be used
[15:43:31 CEST] <dskjb> combined size 153 MB
[15:43:49 CEST] <BtbN> that's not what I'd call big, but it's too big for trac.
[15:44:22 CEST] <dskjb> files can be downloaded very easily from deep link
[15:46:53 CEST] <dskjb> BtbN: upload.ffmpeg.org is not opening
[15:46:59 CEST] <dskjb> some problem
[15:47:21 CEST] <BtbN> It's an FTP server
[15:47:53 CEST] <BtbN> which does seem to be down...
[16:18:24 CEST] <wm4> wow google devs messing again with gapless stuff
[16:20:13 CEST] <atomnuker> google encode mp3 stuff?
[16:20:14 CEST] <wm4> and at this point I have no idea what their changes do, and they keep changing the FATE tests which were supposed to make verifying simple in the first place
[18:45:48 CEST] <Compn> wm4 : are you talking about chromium google changes ? or a different repo?
[18:46:12 CEST] <wm4> patches
[18:46:18 CEST] <wm4> on ffmpeg-devel
[18:46:42 CEST] <wm4> I feel like nobody has an idea how gapless works in ffmpeg (including possibly myself)
[19:00:08 CEST] <philipl> BtbN: yay
[19:01:24 CEST] <BtbN> well, he got his answers twice I'd say
[19:03:40 CEST] <BtbN> philipl, did you start any work regarding CUDA SDK independence, btw.?
[19:43:45 CEST] <cone-587> ffmpeg 03Adriano Pallavicino 07master:21d3f0c0201a: lavc/ivi_dsp.c: fix warnings due to indentation
[19:43:46 CEST] <cone-587> ffmpeg 03Josh de Kock 07master:36fa3d880717: doc/developer: reword some of the policies
[19:43:47 CEST] <cone-587> ffmpeg 03Josh de Kock 07master:ee72b6d1874d: doc/developer: add sections for policies
[19:49:18 CEST] <Chloe> Why is SCTE still happening, didn't we establish that libav* wasn't the correct place for it?
[19:50:24 CEST] <nevcairiel> try to tell that to this guy
[19:51:14 CEST] <Chloe> err, I'll dig through the masses of SCTE threads tonight. plsdunmerge before I can commet
[19:54:21 CEST] <wm4> > +    AV_CODEC_ID_SCTE_35,/**< Contain no valid time stamp in DTS PTS of avpacket, avpacket data contain time stamp
[19:54:21 CEST] <wm4> > +                              in scte-35 format which is relative to DTS/PTS of video stream */  
[19:54:22 CEST] <wm4> lolwut
[19:56:18 CEST] <ubitux> no please no
[19:56:22 CEST] <ubitux> no timestamp in payload
[19:56:44 CEST] <wm4> it says "relative"
[19:56:49 CEST] <wm4> but relative to what, where?
[19:57:10 CEST] <wm4> unless it somehow contains the full video timestamp too...
[19:57:37 CEST] <wm4> anyway, the post I'm copied this from questioned whether this is still accurate
[20:02:39 CEST] <philipl> BtbN: not yet.
[20:03:10 CEST] <philipl> I've been chasing this "save a copy in mpv" thing down.
[20:03:20 CEST] <philipl> I know how to do it now, but I'm pretty sure it's too complicated to worth it.
[20:03:38 CEST] <BtbN> Is one VRAM copy really that bad?
[20:06:33 CEST] <philipl> BtbN: Almost certainly not :-)
[20:06:59 CEST] <philipl> I'd need to add a new hwcontext for cuda arrays - then define a custom pool in mpv.
[20:07:16 CEST] <philipl> I think it saves 1-2% CPU based on my proof-of-concept
[20:07:38 CEST] <nevcairiel> not worth it, then
[20:07:39 CEST] <nevcairiel> :D
[20:07:58 CEST] <philipl> Yes, but I'm far enough down this hole that I think I'll finish it and see what it looks like.
[20:08:09 CEST] <philipl> BtbN: You want me to work on the dynlink cuda stuff?
[20:08:41 CEST] <BtbN> I'd like to leave that out for now. As CUDA is the problematic part of that.
[20:09:26 CEST] <philipl> K. dynlink nvcuvid?
[20:09:46 CEST] <philipl> There's a small advantage there compiling on Ubuntu where they don't put the library in a place the linker will find it by default.
[20:10:10 CEST] <BtbN> Yeah. So basically, revert the non-dynlink changes to the header, and load the functions.
[20:10:21 CEST] <philipl> Pretty much
[21:27:32 CEST] <Chloe> nevcairiel: well... It could have gone better.
[21:35:22 CEST] <Chloe> Anyone going to 33c3?
[22:24:30 CEST] <kierank> I want to go but it's over christmas
[22:31:41 CEST] <Chloe> kierank: it's after christmas
[22:32:04 CEST] <kierank> Like 2 days
[22:32:22 CEST] <Chloe> yes :) Flights are still cheap now as well
[23:00:03 CEST] <Chloe> michaelni: wasnt the correct output for the vf_fps change to drop a frame?
[23:02:40 CEST] <michaelni> Chloe, why would it be correct to drop a frame when converting 30fps to 30fps as in thr fate test ?
[23:03:43 CEST] <Chloe> From what dwbuiten is saying it looks like before it was outputting one too many frames. (maybe I misunderstand)
[23:05:59 CEST] <michaelni> the fate sample has a timebase of 1/3000 all timestamps are multiplies of 100 so its basically 30fps and vf fps=30 is whats used
[23:06:06 CEST] <michaelni> why should it drop a frame ?
[23:07:46 CEST] <nevcairiel> the fate samples has 5 frames
[23:09:44 CEST] <Chloe> oh right ok, yeah, I misunderstood :)
[23:21:58 CEST] <Chloe> michaelni: this is the sample derek used: http://chromashift.org/60fps.mp4 (command being: ffmpeg -i 60fps.mp4 -vf fps=30 out.avi)
[00:00:00 CEST] --- Wed Oct  5 2016