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

[burek]

[03:29:57 CEST] <jamrial> michaelni: a couple of your mingw and clang fate clients are complaining about lack of disk space
[03:32:59 CEST] <michaelni> why does my ccache think it has a 16mb sized cache when du thinks its 6gb
[03:35:46 CEST] <michaelni> should be fixed
[10:37:18 CEST] <rcombs> https://gist.github.com/0d5b38b90b2c10805bdde4d877cfbb7a <-- I forget, who was asking for a CUE demuxer + a way to use that with the segment muxer to split cue sheets?
[10:39:14 CEST] <rcombs> ^ that adds a cue demuxer that exports tracks as chapters, a segment.c feature that splits by chapter (and writes chapter metadata to each output file), duplication of attached pictures in each output segment, and attached-pic support in the FLAC muxer
[10:40:46 CEST] <rcombs> still missing: an AVOption for cuedec to read audio from a path other than the one specified in the .cue file, an AVOption to disable the segment.c attached-pic duplication, and support for putting track (chapter) titles or other metadata in segment filenames
[10:41:15 CEST] <rcombs> and then I can stop using XLD over SMB to split these damn cue sheets
[11:36:35 CEST] <atomnuker> was calling put_bits with #bits == 0 not allowed?
[11:36:50 CEST] <atomnuker> or was it not allowed with get_bits?
[11:51:21 CEST] <nevcairiel> its not allowed with get_bits for sure, not sure what happens with put_bits, especially when the value is != 0 that you are writing
[14:31:59 CEST] <ubitux> fyi wrt merge; the latest merge commit attempt is in my merge-libav branch (github). current issue is that it can crash (doesn't with libav). the only fix to the problem so far is to undo most of the change of the commit 
[14:32:08 CEST] <ubitux> which will probably affect further merges
[14:32:29 CEST] <ubitux> i won't have time to work on this in for a little while, so everyone is welcome to take over
[14:33:23 CEST] <ubitux> only crash i known is with a non shareable fuzzed sample but maybe michaelni has some more
[14:34:55 CEST] <nevcairiel> shouldnt the change just move existing code into a new function, mostly?
[14:35:14 CEST] <nevcairiel> i suppose it does it at a different point in time then
[14:35:58 CEST] <ubitux> it does more than that
[14:36:33 CEST] <ubitux> it moves some code into a function, but it also call it in some other place
[14:36:51 CEST] <ubitux> where it can assumes it's always assume setup is not finished
[14:39:27 CEST] <nevcairiel> without having a sample i can't really test anything, but one thing I saw right away is that the check for the sps staying constant between fields has gone away
[14:39:35 CEST] <nevcairiel> (or between slices, to be more precise)
[14:44:51 CEST] <michaelni> i saw more than 1 crash yestarday
[14:45:07 CEST] <michaelni> or the day before when i tested
[14:48:06 CEST] <michaelni> btw, the patch that removed non factorization changes and results is AFAIK working code was: http://pastebin.com/t0D0aZV7
[14:56:25 CEST] <michaelni> the fate failure btw is related to the pps changes not the call point IIRC
[15:12:33 CEST] <michaelni> if someone needs a sample for the crash "./ffmpeg -i corruptfile " will crash (sample from bugzilla.libav.org/attachment.cgi?id=107)
[15:12:55 CEST] <michaelni> or rather for a crash of the merge, didnt check if its the same crash
[15:13:21 CEST] <michaelni> also i suspect its easy to find more crashes with a fuzzer
[15:13:32 CEST] <michaelni> as quite a few random fuzzed files crash
[15:15:39 CEST] <kierank>  I am going to have to spend months fuzzing ffmpeg h264 now :(
[15:15:41 CEST] <kierank> fuck all of this
[15:49:48 CEST] <ubitux> kierank rage quitted again?
[15:50:39 CEST] <mateo`> wow ...
[16:11:31 CEST] <iive> i thought that there are more h264 merges comming
[16:22:03 CEST] <ubitux> yes, at least one more wave after this commit
[16:25:41 CEST] <ayum> hello everyone
[16:26:02 CEST] <ayum> I have a problem when try to save AVFrame to png files
[16:26:09 CEST] <ayum> here is the source code: http://p.fdzh.org/8g8arXRZ
[16:26:41 CEST] <ayum> and here is the result picture: https://s32.postimg.org/ldlw79ct1/222.png
[16:27:49 CEST] <ayum> my original idea is to get the true color png file, but I found the color of picture is very strange, it's gray, and been split to 2 parts
[16:29:06 CEST] <ayum> is it the problem of my code?  please help me
[16:30:16 CEST] <ubitux> wrong channel, see #ffmpeg
[16:31:18 CEST] <ayum> can you give me some example code about set channel?  thanks
[16:34:41 CEST] <ubitux> i meant wrong IRC channel
[16:38:24 CEST] <ayum> oh, sorry
[19:35:13 CEST] <rcombs> https://github.com/FFmpeg/FFmpeg/compare/master...rcombs:cue?expand=1 I don't recall who was asking for this functionality a while back, but I ran into the use-case and ended up implementing it
[19:46:34 CEST] <jamrial> rcombs: i wrote a flacenc picture implementation a few years ago. your patch is almost the same as mine :p
[19:46:52 CEST] <rcombs> mostly copied from mp3enc
[19:46:59 CEST] <jamrial> but mine was blocked because of the whole audio buffer, so maybe yours can get in
[19:47:05 CEST] <jamrial> yeah, i did the same
[19:47:15 CEST] <rcombs> what blocked, then?
[19:48:46 CEST] <jamrial> the part buffering audio until the first image packet was not well received, and the patch was blocked
[19:48:49 CEST] <jamrial> i think because i was asked to make a common implementation for that code for both mp3enc and flacenc
[19:49:17 CEST] <rcombs> probably would be reasonably easy to split out
[19:49:42 CEST] <rcombs> buffer struct + generic handling routines + callback
[19:49:53 CEST] <jamrial> i noticed luca wrote an avpacketlist api for libav so i was waiting for that, but he never commited it and then i lost interest
[19:49:54 CEST] <j-b> This demuxer reads a cue sheet (text file) and exports its track listing in the form of AVChapters.
[19:50:02 CEST] <j-b> Is it actually AVChapters?
[19:50:34 CEST] <rcombs> j-b: huh?
[19:51:07 CEST] <rcombs> jamrial: oh did you do anything about the whole "number of colors used" thing?
[19:51:24 CEST] <jamrial> for gif? nope, just like you i patchwelcome'd it :p
[19:51:37 CEST] <rcombs> just writing 0 all the time?
[19:51:46 CEST] <jamrial> https://ffmpeg.org/pipermail/ffmpeg-devel/2013-August/146869.html
[19:51:51 CEST] <rcombs> I didn't see an easy way to get it and I really doubt anything cares
[19:52:32 CEST] <jamrial> no, just bailed out if gif was requested
[19:52:36 CEST] <rcombs> I should probably set the video_codec field
[19:54:04 CEST] <jamrial> oh, i see you're not checking for gif. in any case i'd say you should return patchwelcome for gif instead of muxing it with that field set to 0
[19:54:19 CEST] <j-b> I mean, it's not really chapters, is it?
[19:54:23 CEST] <rcombs> would that actually break
[19:54:32 CEST] <jamrial> no idea
[19:54:46 CEST] <jamrial> but muxing files not following the spec is not a good practice
[19:54:56 CEST] Action: rcombs shrugs
[19:55:12 CEST] <jamrial> also, the spec mentions jpg and png only if i recall correctly, so don't just mux everything from ff_id3v2_picture_types
[19:55:28 CEST] <rcombs> heh
[19:56:13 CEST] <rcombs> j-b: got a better way to represent them?
[19:56:54 CEST] <rcombs> j-b: I mean, cue files are meant to be the index from a CDDA plus some meta, and CDDA track indexes are conceptually the same as chapter markers
[19:58:34 CEST] <jamrial> a cue sheet may reference more than one input file
[19:58:35 CEST] <j-b> I would say, it's more a playlist of different tracks
[20:01:12 CEST] <rcombs> well we've got no concept of playlists
[20:01:29 CEST] <rcombs> nor of distinct tracks in one file
[20:01:47 CEST] <rcombs> jamrial: I didn't have a sample for that; how does that work?
[20:02:13 CEST] <jamrial> rcombs: nevermind, it supports everything from id3v2
[20:02:20 CEST] <jamrial> and let me check if i can find a sample cue
[20:02:24 CEST] <rcombs> k
[20:04:16 CEST] <rcombs> the end result of this, btw, is: `ffmpeg -i /path/to/whatever.cue -segment_chapters 1 -f segment -c copy -map 0 /path/to/album/'%02d $artist$ - $title$.flac'`
[20:04:34 CEST] <rcombs> (optionally, substitute FLAC with <whatever else>)
[20:05:48 CEST] <jamrial> rcombs: http://pastebin.com/ERu8cwvF
[20:06:11 CEST] <rcombs> ah
[20:06:12 CEST] <rcombs> yuck
[20:08:01 CEST] <rcombs> E_PATCHWELCOME; that'd probably require a bunch of stuff from concat that I'd rather not get into (along with a-priori knowledge of the duration in order to make the chapters for later discs)
[20:08:11 CEST] <rcombs> I guess at that point you'd be better off merging this into concat.c
[20:08:53 CEST] <rcombs> or concatdec or whatever the demuxer is called
[20:27:44 CEST] <BBB> why did kierank get upset btw?
[20:27:49 CEST] <BBB> I totally dont understand his rage
[20:28:27 CEST] <nevcairiel> who knows
[20:28:49 CEST] <nevcairiel> the fun part is that in the same moment he complains about adult behavior
[20:30:08 CEST] <durandal_170> you commit merges which breaks h264 
[20:30:39 CEST] <ubitux> durandal_170: the commit breaking stuff is not yet pushed
[20:30:48 CEST] <ubitux> that's why we were discussing it
[20:30:50 CEST] <BBB> durandal_170: I did not commit anything
[20:31:26 CEST] <ubitux> he's also welcome to help with the merge if he's not happy with the result
[20:32:04 CEST] <ubitux> trying various provocations attempt on regular schedule isn't going to help
[20:32:41 CEST] <durandal_170> whenever you change something, fuzzing would need to rerun
[20:33:21 CEST] <ubitux> these changes are worth integrating
[20:33:35 CEST] <ubitux> sorry for changing the codebase
[20:33:53 CEST] <BBB> lets not rage further
[20:33:57 CEST] <BBB> changes are ok
[20:34:01 CEST] <nevcairiel> so what should we durandal_170, never change anything anymore?
[20:34:03 CEST] <BBB> why did this specifically upset him so much?
[20:34:10 CEST] <BBB> is there a particular reason?
[20:34:18 CEST] <ubitux> he's like that since a few weeks
[20:34:28 CEST] <jamrial> yes, please. lets just stop
[20:34:57 CEST] <durandal_170> nevcairiel: after fuzzing, changes must be careful
[20:35:38 CEST] <ubitux> add fate test if you're afraid or regressions
[20:36:39 CEST] <durandal_170> yes, fate tests
[20:38:10 CEST] <ubitux> s/or/of/
[20:38:52 CEST] <rcombs> jamrial: imo an OOM should fail instead of continuing with unpredictable things left out
[20:39:45 CEST] <jamrial> if you run ouf of memory buffering audio packets, you flush them right then and there and forget about the image packet that is yet to show up
[20:40:00 CEST] <jamrial> once you start flushing them, you're freeing memory
[20:40:41 CEST] <rcombs> you'd also free memory by flushing the cache and erroring to the consumer
[20:41:23 CEST] <jamrial> mp3enc originally bailed out if it ran out of memory buffering the audio packets, but we got an user on trac complaining about it
[20:41:29 CEST] <jamrial> he had an itunes-made file with the first video/image packet at the very end of the file
[20:42:06 CEST] <rcombs> you can easily tell ffmpeg.c not to copy the attached-pic stream
[20:43:01 CEST] <jamrial> yes, i told him that at first
[20:43:14 CEST] <rcombs> I'd rather not have it return a successful status code and write a valid-but-not-what-the-user-requested file
[20:43:21 CEST] <jamrial> but the average user, like this one, isn't aware the oom is because of a video track trying to be muxed as attached pic
[20:43:35 CEST] <jamrial> so he wouldn't think about telling ffmpeg to skip it
[20:43:43 CEST] <jamrial> i sent a patch to make this change to mp3enc, and it was oked
[20:43:53 CEST] <jamrial> so i don't think it's a bad solution
[20:44:57 CEST] Action: rcombs waits for more people to have opinions
[20:46:04 CEST] <jamrial> if you look at mp3enc, it will emit a warning saying it's skipping the picture stream
[20:46:21 CEST] <rcombs> yeah
[20:47:05 CEST] <rcombs> but if this is in a library consumer, or called by a script, or <etc&> then the user's not likely to be made aware of the failure
[20:48:04 CEST] <jamrial> you could always check for explode flag and bail out if it's set
[20:48:34 CEST] <rcombs> hmmm, does that exist for muxers?
[20:48:43 CEST] <jamrial> yeah
[20:48:53 CEST] <bp0> kode54, there is a difference between the hdcd decoder included in fb2k and the one in ffmpeg that I'm curious about. In hdcd_envelope() below the comment /* attenuate slowly */ ...
[20:49:07 CEST] <rcombs> maybe then
[20:49:34 CEST] <bp0> kode54, https://gitlab.kode54.net/kode54/foo_hdcd/blob/master/hdcd_decode.c line 848
[20:49:34 CEST] <jkqxz> Has the general policy on intrinsics been changed?  This powerpc/swscale thing seems to be demonstrating exactly the problems with them...
[20:49:55 CEST] <bp0> kode54, https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/af_hdcd.c line 952
[20:50:56 CEST] <jamrial> jkqxz: don't think so, at least not for x86/arm/aarc64
[20:51:05 CEST] <bp0> kode54, ffmpeg does not appear to be changing the gain at all
[20:53:27 CEST] <kode54> it's not incrementing or decrementing that gain variable
[20:53:41 CEST] <bp0> it should be ++gain then, right?
[20:53:54 CEST] <kode54> with a clip check
[20:54:01 CEST] <kode54> oh
[20:54:07 CEST] <nevcairiel> jkqxz: it has not, but i dont know shit about ppc64 :)
[20:54:09 CEST] <kode54> I see it already does a clip check on the len variable
[20:54:58 CEST] <kode54> attenuate should increment it once per iteration
[20:55:11 CEST] <kode54> amplify should decrement it by 8 each iteration
[20:55:41 CEST] <kode54> oh
[20:55:47 CEST] <kode54> amplify already decrements it
[20:55:55 CEST] <kode54> so attenuate isn't incrementing it
[20:56:16 CEST] <bp0> yeah, it seems
[20:56:39 CEST] <bp0> so making the line in attenuate: APPLY_GAIN(*samples, ++gain);
[20:56:43 CEST] <bp0> should fix it, right?
[20:56:47 CEST] <kode54> yes
[20:56:49 CEST] <bp0> ok
[20:57:04 CEST] <kode54> or  maybe it should be incremented outside the macro
[20:57:14 CEST] <kode54> in case the macro uses the value more than once
[20:57:26 CEST] <kode54> (is the increment calculated before it is passed to the macro?)
[20:58:13 CEST] <bp0> well it is only used once, but it is probably better practice to do as you suggest
[21:00:20 CEST] <bp0> and idk, but I think it is copied into the macro as ++gain
[21:00:31 CEST] <bp0> I'm really not certain about it tho
[21:00:49 CEST] <cone-947> ffmpeg 03Paul B Mahol 07master:de30863fffae: avfilter/vf_rotate: add >8 bit depth support
[21:01:26 CEST] <jkqxz> The quoted speedups are basically zero, and in fact it's a regression in some of them.  Also the submitter has implied that they are only doing it for the bounty, so it will be unmaintained.  How is this useful to anyone?
[21:11:12 CEST] <nevcairiel> feel free to express your thoughts on the ML
[21:13:27 CEST] <jamrial> so arch is trying to upgrade to 3.1 and thus recompiled mpv and mpd
[21:13:33 CEST] <jamrial> they didn't notice 3.1.1 is out
[21:13:41 CEST] <jamrial> all that effort to undo the abi changes for nothing :p
[21:16:25 CEST] <durandal_170> jkqxz: if speedups are none, it can not be accepted
[21:19:44 CEST] <bp0> kode54, http://ffmpeg.org/pipermail/ffmpeg-devel/2016-July/196268.html
[21:30:30 CEST] <kode54> looks good
[22:44:25 CEST] <bp0> kode54, foo_hdcd doesn't do anything with transient filter, right?
[00:00:00 CEST] --- Tue Jul  5 2016