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

[burek]

[00:13:02 CEST] <Daemon404> michaelni, these two new issues are tested against teh codedpar_rebase branch right?
[00:14:46 CEST] <michaelni> yes unless i screwed up
[00:15:09 CEST] <Daemon404> ok
[00:15:31 CEST] <nevcairiel> re: lowres, we could do something hacky like is done with threads, and disable the option in the find_stream_info decoder
[00:17:28 CEST] <Daemon404> nevcairiel, hmmm any idea about using bsfs in ffmpeg.c?
[00:17:34 CEST] <Daemon404> it seems extradata is not being recieved
[00:18:17 CEST] <nevcairiel> does it still generate it too late, ie. after opening?
[00:18:22 CEST] <nevcairiel> that never really worked
[00:18:31 CEST] <Daemon404> yes
[00:18:33 CEST] <nevcairiel> and would just work in mov because of mov 
[00:18:39 CEST] <Daemon404> :|
[00:18:50 CEST] <Daemon404> what to do then
[00:19:03 CEST] <nevcairiel> rely on auto bsf from rcombs
[00:19:08 CEST] <nevcairiel> that handles this secretly
[00:19:11 CEST] Action: rcombs looks up
[00:19:26 CEST] <Daemon404> its still going to break some common command lines
[00:19:57 CEST] <rcombs> I was planning on eventually moving ffmpeg.c's bsf stuff to have it just add the filters to the streams, so lavf handles it on output
[00:20:09 CEST] <nevcairiel> only until ffmpeg.c is migrated to codecpar and new bsf
[00:20:27 CEST] <rcombs> but it seemed not worth it until the rest of the API dust settles
[00:20:35 CEST] <rcombs> Daemon404: which case is still breaking for you?
[00:20:36 CEST] <Daemon404> nevcairiel, i somehow dont think certain people will find that acceptable
[00:20:42 CEST] <Daemon404> ./ffmpeg -i *aac -c copy -bsf:a aac_adtstoasc -t 0.1 foo.m4a
[00:20:50 CEST] <Daemon404> it doesnt created extradata in the mp4
[00:20:59 CEST] <rcombs> oh, yeah, I haven't done anything on movenc yet
[00:21:02 CEST] <nevcairiel> if you try to do with mkv today in master, it will already break
[00:21:10 CEST] <Daemon404> nevcairiel, i see
[00:21:15 CEST] <Daemon404> michaelni, ^ opinions
[00:21:16 CEST] <rcombs> nevcairiel: oh, did mkv break?
[00:21:16 CEST] <rcombs> shit
[00:21:34 CEST] <nevcairiel> unless the auto-bsf overrules the explicit bsf somehow?
[00:22:12 CEST] <rcombs> it's applied separately
[00:22:43 CEST] <nevcairiel> like I said, the problem of extradata-generating BSFs is that they generate the extradata after seeing the first packet, the auto-bsf works around that by delaying muxer init until after that point, but ffmpeg.c bsf don't have such a luxury
[00:22:44 CEST] <Daemon404> nevcairiel, cant sue auto-bsf anyway
[00:22:59 CEST] <Daemon404> ./ffmpeg -i *aac -c copy -t 0.1 foo2.m4a
[00:23:01 CEST] <Daemon404> ^ does not work
[00:23:08 CEST] <Daemon404> makes a 200 byte file (should be 2 kb)
[00:23:10 CEST] <Daemon404> that is unusable
[00:23:19 CEST] <rcombs> nevcairiel: seems to me it works fine
[00:23:19 CEST] <nevcairiel> like rcombs said, he didnt add that mechanism to movenc yet
[00:23:29 CEST] <Daemon404> i see
[00:23:37 CEST] <rcombs> with or without the explicit ffmpeg.c bsf
[00:23:48 CEST] <Daemon404> rcombs, youd have to test in the codecpar branch :P
[00:23:50 CEST] <nevcairiel> makes no sense to me why it should work
[00:23:54 CEST] <nevcairiel> even on master
[00:23:55 CEST] <rcombs> if you add it explicitly in ffmpeg.c, lavf won't add it automatically
[00:24:06 CEST] <rcombs> but writing the header is still delayed until the first packet is filtered
[00:24:12 CEST] <nevcairiel> it is?
[00:24:14 CEST] <rcombs> yeah
[00:24:23 CEST] <Daemon404> rcombs, how hard is it to add it for mov
[00:24:29 CEST] <nevcairiel> i thought it doesnt do that with explicit filtering
[00:24:32 CEST] <rcombs> Daemon404: gotta split init from write_header
[00:24:46 CEST] <nevcairiel> mov write header is void anyway
[00:24:51 CEST] <nevcairiel> it writes it in trailer
[00:25:01 CEST] <rcombs> does it actually _never_ write _anything_ to the file?
[00:25:11 CEST] <nevcairiel> probably not quite that strict
[00:25:11 CEST] <rcombs> if so, just rename write_header to init and it'll work fine
[00:25:21 CEST] <rcombs> but the init function isn't allowed to write anything ever
[00:25:39 CEST] <rcombs> it just has to make any adjustments to avstreams that are necessary for bsfs to work
[00:25:54 CEST] <rcombs> and if it wants to make any allocations that might have previously been done in write_header, that's fine too
[00:26:07 CEST] <rcombs> but it shouldn't write to the file
[00:26:22 CEST] <nevcairiel> looks like splitting init from write_header *should* be simple on a quick glance, but i didnt follow it in detail
[00:26:31 CEST] <rcombs> it was easy in mkv and mpegts
[00:26:39 CEST] <rcombs> (mpegts because write_header already didn't write anything)
[00:27:27 CEST] <rcombs> segment was a little trickier because it needed to "dispatch" bitstream checks down to the underlying muxer
[00:27:43 CEST] <rcombs> tee will probably need something similar
[00:27:50 CEST] <nevcairiel> anyway doing that would probably fix it for mov Daemon404
[00:28:04 CEST] <rcombs> you need (1) an init function, and (2) a check_bitstream function
[00:28:11 CEST] <rcombs> can probably copy the latter verbatim from mkv
[00:28:23 CEST] <nevcairiel> (rip out the vp9 stuff)
[00:28:50 CEST] <nevcairiel> hm which isnt actually in there
[00:28:52 CEST] <nevcairiel> i thought it was
[00:28:53 CEST] <rcombs> oh, forgot the vp9 thing
[00:28:55 CEST] <rcombs> nevcairiel: it is here
[00:29:00 CEST] <rcombs> I don't think that was me
[00:29:03 CEST] <nevcairiel> ah my code is still old
[00:29:07 CEST] <nevcairiel> i should rebase on the new branch
[00:29:14 CEST] <nevcairiel> no that was BBB when he wrote the bsf
[00:29:18 CEST] <rcombs> I only haven't done it yet for mov because historically mov writes it later anyway so it doesn't care
[00:29:25 CEST] <rcombs> so you can add it manually and it works
[00:29:32 CEST] <rcombs> still more annoying than auto though
[00:29:48 CEST] <rcombs> kinda curious why adding it manually isn't working for Daemon404
[00:31:08 CEST] <nevcairiel> it only does the delaying if the muxer has a check_bitstream function
[00:31:14 CEST] <rcombs> right
[00:31:23 CEST] <rcombs> but mov usually writes the extradata at the end anyway
[00:31:25 CEST] <nevcairiel> you could probably add an empty check_bitstream to mov for extra magic trickery
[00:31:30 CEST] <rcombs> so the delaying doesn't generally matter
[00:31:47 CEST] <nevcairiel> it does when the codec parameters get frozen on init
[00:31:54 CEST] <nevcairiel> so any "late" changes dont arrive anymore
[00:31:59 CEST] <rcombs> oh, so it's newly broken in codecpar
[00:32:02 CEST] <rcombs> OK, that makes sense
[00:32:19 CEST] <nevcairiel> its actually enforcing an API contract in this particular case that should've been valid all along
[00:32:26 CEST] <nevcairiel> just mov worked differently because its late header
[00:32:36 CEST] <rcombs> so, that might actually be broken for mkv and mpegts then
[00:32:39 CEST] <rcombs> I haven't tested on the branch
[00:32:59 CEST] <rcombs> know if anyone has, or should I give it a go?
[00:33:34 CEST] <nevcairiel> probably is broken indeed
[00:33:40 CEST] <rcombs> where's the branch?
[00:33:42 CEST] <jamrial> L1mb1r1SUm at r4
[00:33:50 CEST] <Daemon404> [matroska @ 0x2040920] Error parsing AAC extradata, unable to determine samplerate.
[00:33:52 CEST] <rcombs> wat
[00:33:53 CEST] <Daemon404> av_interleaved_write_frame(): Invalid argument
[00:33:56 CEST] <Daemon404> [matroska @ 0x2040920] Error parsing AAC extradata, unable to determine samplerate.
[00:34:16 CEST] <rcombs> Daemon404: sounds broken indeed
[00:34:16 CEST] <nevcairiel> its broken until bsfs are updated to work with codecpar in a follow up merge
[00:34:26 CEST] <nevcairiel> i think
[00:34:32 CEST] <Daemon404> rcombs, https://github.com/dwbuiten/FFmpeg/commits/codecpar_rebase
[00:34:35 CEST] <nevcairiel> i wonder how extradata bsfs work after
[00:34:37 CEST] Action: nevcairiel checks
[00:34:47 CEST] <nevcairiel> we could add a hack to make it work in the meantime
[00:34:56 CEST] <Daemon404> what sort of hack
[00:35:12 CEST] <nevcairiel> update codecpar extradata from bsf extradata after it was run
[00:35:28 CEST] <nevcairiel> in av_interleaved_write_frame
[00:36:01 CEST] <Daemon404> right ok...
[00:36:04 CEST] <rcombs> or just immediately before actually calling write_header
[00:36:25 CEST] <Daemon404> rcombs, i dont think that would work
[00:36:39 CEST] <Daemon404> isnt that usually called before any packets are processed
[00:36:48 CEST] <nevcairiel> not with auto-bsf
[00:36:49 CEST] <rcombs> Daemon404: not with auto-bsf
[00:36:56 CEST] <nevcairiel> it delays that until it could process a packet
[00:37:00 CEST] <rcombs> it delays the AVCodec::write_header call
[00:37:05 CEST] <Daemon404> also write_header for mov can sometimes write data
[00:37:08 CEST] <Daemon404> e.g. in DASH mode
[00:37:21 CEST] <nevcairiel> thats why it needs to be split into init + write_header
[00:37:25 CEST] <rcombs> ^
[00:37:28 CEST] <Daemon404> ok
[00:37:33 CEST] <Daemon404> so i dont think hats too hard then is it
[00:37:36 CEST] <Daemon404> to workaround for now
[00:37:39 CEST] <nevcairiel> probably not
[00:37:41 CEST] <rcombs> it shouldn't be
[00:37:53 CEST] <nevcairiel> mov is just in the same boat as any other container with global headers now
[00:37:57 CEST] <rcombs> movenc is just so huge I didn't want to try to split it up
[00:38:08 CEST] <rcombs> at the time
[00:38:13 CEST] <Daemon404> nevcairiel, you want to try 'fixing' lowres tomorrow?
[00:38:17 CEST] <rcombs> wanted to get the easier ones done first
[00:38:21 CEST] <Daemon404> ill do mov
[00:38:23 CEST] <nevcairiel> bsf still uses st->codec, i wonder if thats right
[00:38:23 CEST] <Daemon404> and bsf
[00:38:32 CEST] <nevcairiel> it could be completely empty
[00:38:32 CEST] <Daemon404> nevcairiel, yes i left that on purpose
[00:38:36 CEST] <Daemon404> its broken otherwise
[00:38:58 CEST] <nevcairiel> but what if a caller actually uses codecpar
[00:39:02 CEST] <nevcairiel> then st->codec is empty
[00:39:11 CEST] <Daemon404> we update ->codec im pretty sure
[00:39:14 CEST] <Daemon404> under deprection guards
[00:39:16 CEST] <nevcairiel> for muxing?
[00:39:19 CEST] <nevcairiel> why?
[00:39:26 CEST] <Daemon404> maybe not for muxing
[00:39:43 CEST] <Daemon404> but definitely in concat and tee, using a temp avctx is broken
[00:39:47 CEST] <Daemon404> i tried this
[00:40:06 CEST] <nevcairiel> maybe we should fill internal->avctx from codecpar and use that for bsf then
[00:40:12 CEST] <nevcairiel> its only temporary either way
[00:40:17 CEST] <nevcairiel> new bsf doesnt use avctx
[00:40:29 CEST] <Daemon404> i can try tomorrow
[00:40:59 CEST] <rcombs> nevcairiel: are their options sane now
[00:41:39 CEST] <rcombs> I mean I guess a monolithic string isn't inherently insane if you actually have some parsing infrastructure
[00:42:44 CEST] <nevcairiel> rcombs: their class has AVOptions now
[00:42:46 CEST] <Daemon404> anyway ill fix bsfs tomorrow (busy tonight)
[00:43:01 CEST] <nevcairiel> s/class/context/
[00:43:02 CEST] <Daemon404> or try
[00:43:10 CEST] <rcombs> nevcairiel: yay
[00:43:45 CEST] <Daemon404> michaelni, just an fyi: dont file any more bugs related to bitstream filters, since theyre all the same issue
[00:45:19 CEST] <Daemon404> nevcairiel, setting lowres in utils.c doesnt work
[00:45:24 CEST] <Daemon404> fyi.
[00:46:28 CEST] <Daemon404> unless im doing it wrong
[00:47:29 CEST] <Daemon404> oh i did it wrong!
[00:47:55 CEST] <Daemon404> output is still different
[00:48:03 CEST] <rcombs> ^ 4 lines describing all of development ever
[00:48:07 CEST] <nevcairiel> i'll look at it tomorrow
[00:48:23 CEST] <Daemon404> nevcairiel, ok thank you
[00:48:24 CEST] <nevcairiel> sleep now
[00:48:26 CEST] <Daemon404> ill handle bsfs and mov tomorrow
[00:48:28 CEST] <Daemon404> sleep well.
[00:49:25 CEST] <rcombs> apparently somebody's voiced and/or opped me in here multiple times, but hasn't actually set it in chanserv
[00:50:14 CEST] <Daemon404> voice: the most useful irc power
[00:50:20 CEST] <Daemon404> just incase i +m the channel
[00:50:23 CEST] <rcombs> extremely
[00:50:47 CEST] <nevcairiel> voice is about status, not power!
[00:51:20 CEST] <michaelni> rcombs, can you add yourself to MAINTAINERs for the parts  you maintain ?
[00:51:37 CEST] <Daemon404> seems i had the power to voice rcombs 
[00:51:55 CEST] <rcombs> michaelni: I guess that's audiotoolbox, and& anything else right now?
[00:52:09 CEST] <Daemon404> securetransport?
[00:52:25 CEST] <rcombs> sure
[00:52:34 CEST] <nevcairiel> if you are the author of a file, do you really need to write that down in maintainers as well
[00:52:39 CEST] <nevcairiel> seems kinda redundant
[00:52:50 CEST] <Daemon404> yes because then carl can claim it is maintainer and block removing it
[00:52:54 CEST] <Daemon404> maintained*
[00:53:13 CEST] <Daemon404> maintainers is reall6y a very simple mutex implementation
[00:53:48 CEST] <rcombs> implemented on top of git's lease system?
[00:53:55 CEST] <nevcairiel> i only put my name in there for more generic concepts, like everything dxva2 and windows support =p
[00:54:16 CEST] <nevcairiel> some of those maintainers names i have never heard before
[00:54:21 CEST] <nevcairiel> must be an active bunch
[00:55:26 CEST] <rcombs> it's funny how everyone pokes me about sidx issues
[00:55:33 CEST] <rcombs> as if I know what I was doing in mov at all
[00:55:48 CEST] <nevcairiel> probably works the same way as at $work, you touched it last, its yours now
[00:56:03 CEST] <rcombs> there are so many different index mechanisms in that format
[00:56:34 CEST] <rcombs> all of which work together in different arcane undocumented ways depending on what wrote the file you're looking at
[00:56:54 CEST] <nevcairiel> speaking about sidx, i noticed that st->index is kinda useless on sidx files, since it only contains  the indexes from the first fragment, i used it to suggest smart seeking targets to the player, that didnt work out on such files
[00:57:14 CEST] <nevcairiel> st->index_entries that is
[00:57:29 CEST] <nevcairiel> or whatever its called
[00:57:51 CEST] <rcombs> it contains index entries from fragments you've read from so far
[00:58:14 CEST] <rcombs> not really possible to do better without reading 'em all ahead of time, which is what we used to do and it's slow as shit
[00:59:06 CEST] <nevcairiel> i had to do some evil hackery to ignore the index on such files to avoid claiming I know about index entries but only know about a small fraction =p
[00:59:23 CEST] <nevcairiel> usually st->index_entries on mov are pretty good
[00:59:32 CEST] <rcombs> makes sense
[00:59:53 CEST] <nevcairiel> only use it on filse where i know the index is *usually* sane, say mov and mkv
[00:59:56 CEST] <nevcairiel> and maybe avi
[01:00:10 CEST] <nevcairiel> i forget
[01:00:27 CEST] <rcombs> avi is usually sane?
[01:00:34 CEST] <rcombs> I guess people only send me broken files
[01:00:48 CEST] <rcombs> and the only avis I work with regularly are the broken samples people send me
[01:00:59 CEST] <nevcairiel> the fate of multimedia developers
[01:14:52 CEST] <cone-787> ffmpeg 03James Almer 07master:64b1ec804f54: fate: add demux test for OggOpus
[01:16:59 CEST] <Compn> rcombs : vast majority of avi is sane. ffmpeg deals with everything else :P
[01:18:31 CEST] <Compn> thats why wmp bails on incomplete avi . doesnt want the hassle
[03:13:57 CEST] <cone-787> ffmpeg 03Michael Niedermayer 07master:419cb35e6f7b: fate: Add fate-ts-opus-demux
[03:13:58 CEST] <cone-787> ffmpeg 03Michael Niedermayer 07master:ec7fda2db590: fate: add fate-flv-demux
[03:13:59 CEST] <cone-787> ffmpeg 03Michael Niedermayer 07master:54c914651f16: fate: Add wav-ac3 test
[10:04:56 CEST] <jya> I'm guessing someone here will know... Does AAC have a standard in regards to channel ordering ? where could I find it ? (I'm not quite clear following my read of aacdectab.h
[10:05:44 CEST] <nevcairiel> our decoders should output a consistent channel order no matter which format, that said aac has different ways to signal channel layout, either using a default preset or PCEs
[10:06:49 CEST] <jya> nevcairiel: yes, I understand that ffmpeg output everything in smpte order, but here I'm not dealing with ffmpeg decoder, and I can't find a clear reference about it
[10:07:28 CEST] <jya> (looking at either the Apple CoreMedia decoder or the Windows WMF IMFTransform decoder)
[10:07:49 CEST] <nevcairiel> windows decoders are likely to output in default wave order as well
[10:07:55 CEST] <nevcairiel> no clue what apple does
[10:08:50 CEST] <jya> nevcairiel: are you sure? https://msdn.microsoft.com/en-us/library/windows/desktop/dd742784(v=vs.85).aspx#format_constraints mentioned something about ordering the same way as the input data
[10:10:15 CEST] <jya> specifically: "The same channel configuration as the input type."
[10:10:22 CEST] <jya> that or stereo
[10:10:38 CEST] <nevcairiel> that just means it cant remix for you, other than to stereo
[10:11:11 CEST] <nevcairiel> i would be seriously surprised if the MFT decoder doesnt reorder the channels to its standard
[10:12:27 CEST] <jya> with the mac decoder it seems to output for 5.1 C, L, R, SL, SR, LFE
[10:14:08 CEST] <jya> but don't know if this is always that. just by the sample I have
[10:18:38 CEST] <ubitux> stupid question: what does x&4 means wrt x mathematically? (aside from the 3rd bit being set)
[10:18:51 CEST] <ubitux> would that be an implicit simplification of &7 meaning mod8?
[10:19:05 CEST] <ubitux> context:
[10:19:07 CEST] <ubitux>     default: if (filtersize & 4) ASSIGN_SCALE_FUNC2(hscalefn, X4, opt1, opt2); \
[10:19:09 CEST] <ubitux>              else                ASSIGN_SCALE_FUNC2(hscalefn, X8, opt1, opt2); \
[10:20:22 CEST] <nevcairiel> its probably similar to &7, except someone knew  the first two bits are not important for some reason?
[10:20:39 CEST] <ubitux> yeah that was what i meant by "implicit simplification"
[10:20:48 CEST] <ubitux> but ok
[10:20:57 CEST] Action: ubitux doesn't like this very much :p
[10:23:33 CEST] <wm4> jya: ffmpeg's AT decoder wrapper also has to reorder
[11:09:36 CEST] <ubitux> needs to poke BBB with https://blogs.gentoo.org/lu_zero/2016/04/01/avscale-part1/
[11:11:52 CEST] <jya> wm4: there's a FFmpeg AT decoder??
[11:12:12 CEST] <jya> what for?
[11:14:19 CEST] <wm4> dunno
[11:21:04 CEST] <jya> wm4: are we talking about the same thing? by Apple AT I mean Audio Toolbox. Can't find any code in libavcodec resembling it
[11:23:39 CEST] <wm4> yes... it's a recent addition to git master
[11:26:21 CEST] <jya> ah ok.. let me pull again then
[11:29:46 CEST] <jya> looks complicated just to find out the channel mapping !
[11:32:21 CEST] <nevcairiel> the code looks like the decoder tells you the channel mapping somehow
[11:32:25 CEST] <nevcairiel> but i only glanced over it
[11:33:37 CEST] <jya> nevcairiel: yes.. looking at it.. I wonder where he's found all the docs about the AT decoder. while not as bad as video toolbox documentation, it's pretty obscure API
[11:33:52 CEST] <nevcairiel> just ask rcombs once he wakes up
[12:42:22 CEST] <nevcairiel> Daemon404: you know why lowres doesnt work, because ffmpeg.c does not handle a change in resolution, ie. its fundamentally incapable of lowres decoding in the first place =p
[12:43:18 CEST] <nevcairiel> so right now its decoding in lowres and then scaling back up to original
[12:43:29 CEST] <nevcairiel> (in codecpar right now, not master, mind you)
[12:44:00 CEST] <wm4> nevcairiel: michaelni claims the API is so that the demuxer must indicate the decoded parameters
[12:44:26 CEST] <nevcairiel> the demuxer must indicate the container parameters, ffmpeg.c relying on the demuxer lowres'ing is just stupid
[12:44:31 CEST] <wm4> which of course completely conflicts with the intention of demuxer parameters being the input parameters of the decoder
[12:45:50 CEST] <wm4> if anything, the decoder could probably apply the lowres on decoder init, but then that's _still_ too late for ffmpeg.c
[12:46:05 CEST] <wm4> (same problem as with the vpx alpha test)
[12:47:36 CEST] <nevcairiel> the only way to fix lowres that I see is either to re-write ffmpeg.c's format madness, or export coded w/h, just for freaking lowres
[12:48:04 CEST] <wm4> what if we apply lowres in ffmpeg.c
[12:48:24 CEST] <nevcairiel> not sure it knows if a stream can actually be lowres'ed
[12:48:33 CEST] <nevcairiel> only the decoder likely knows that
[12:49:09 CEST] <wm4> there's AVCodec.max_lowres
[12:49:35 CEST] <nevcairiel> but i would assume it depends on the stream to actually support lowresing?
[12:49:37 CEST] <nevcairiel> or does it not
[12:49:41 CEST] <nevcairiel> i have no clue how it works
[12:51:36 CEST] <wm4> lol, not much to do this, but still, in utils.c: if (s->codec_id == AV_CODEC_ID_H264 || s->lowres) {
[12:51:38 CEST] <wm4> lovely code
[12:52:51 CEST] <wm4> so just looking through the code, max_lowres seems to be the only condition
[12:52:56 CEST] <wm4> but, can't we just remove lowres
[12:53:35 CEST] <nevcairiel> i have no clue who would ever be interested in using it, but for s ome reason michaelni revived it after libav removed it, so ask him
[12:53:53 CEST] <wm4> he might be the only one who wants to keep it
[13:00:27 CEST] <ubitux> BBB: https://blogs.gentoo.org/lu_zero/2016/04/01/avscale-part1/
[13:01:50 CEST] <wm4> that's naive
[13:02:14 CEST] <wm4> no details etc.
[13:03:14 CEST] <nevcairiel> it also contradicts itself a couple times
[13:16:29 CEST] <michaelni> (s->codec_id == V_CODEC_ID_H264 || s->lowres) <-- the comment below that code explains it, lowres uses the H264 MC code, and that code reads a line more thus the special case
[13:18:06 CEST] <wm4> point is, it shouldn't be in utils.c
[13:18:16 CEST] <michaelni> i agree
[13:19:08 CEST] <BBB> ubitux: thats identical to the wiki entry from a few years ago
[13:19:30 CEST] <BBB> ubitux: almost functional requires either a link to a github branch or something that shows test coverage wrt features in swscale/etc
[13:20:03 CEST] <BBB> oh theres a github link at the end
[13:20:40 CEST] <BBB> I dont feel like I have energy to look at this right now
[13:20:45 CEST] <wm4> ah, there was even some code added
[13:21:03 CEST] <BBB> what Ill say is that efficient colorspace conversion is hard
[13:21:29 CEST] <BBB> its eays to write a system that sort of works for most colorspaces, but sometimes inefficiently so
[13:21:53 CEST] <BBB> whats hard is to write something that is relatively efficient with code use but at the same time has a most-optimal case for all common cases and a fairly fast one for pretty much any other one
[13:21:54 CEST] <wm4> int sstrides[AVS_MAX_COMPONENTS],
[13:21:57 CEST] <BBB> even swscale doesnt have that
[13:21:59 CEST] <wm4> also lol repeating old mistakes
[13:22:26 CEST] <michaelni> also if people want me to update lowres, i can do it (probably later today or tomorrow) but its either the patch i posted or breaking API, documenting that break and updating ffmpeg&ffplay.c and i dont like breaking API, its wrong without major bump
[13:23:01 CEST] <wm4> michaelni: what API? you mean the demuxer exporting decoder parameters? I bet only ffmpeg.c relies on this
[13:23:19 CEST] <BBB> I think its fine to break api with the new decoding api
[13:23:20 CEST] <wm4> who else would dare to pass options to av_find_stream_info
[13:23:22 CEST] <BBB> after all, its new
[13:23:33 CEST] <BBB> the old decoding api should probably support it, but its going away
[13:23:47 CEST] <BBB> if you need a new av_find_stream_info(), just call it _2()
[13:23:50 CEST] <wm4> BBB: if you mean mine, it only changes the decode calls itself
[13:24:39 CEST] <BBB> I know, but he calls that a api break
[13:25:03 CEST] <BBB> so maybe only call the new decode api (inside av_find_stream_info) after major bump or if a special property is set in the input dict
[13:25:10 CEST] <BBB> that way youre not breaking api
[13:25:16 CEST] <nevcairiel> its not about the new api
[13:25:44 CEST] <BBB> its about not having access to particular members when interacting between lavf/lavc in new api and av_find_stream_info+lowres breaking for these cases, right?
[13:26:00 CEST] <michaelni> Currently if the user app sete lowres=1/2/3 to the _demuxer_ the AVCodecCntext from the demuer will has lowres adjusted width/height
[13:26:37 CEST] <wm4> which is buttfuck insane
[13:27:47 CEST] <michaelni> the point is if this is changed applications like ffmpeg.c will break unless they are adjusted accordigly
[13:28:52 CEST] <wm4> ho much chaos would it cause to only apply lowres to AVStream->codec, and not codecpar?
[13:29:00 CEST] <wm4> *how
[13:29:03 CEST] <wm4> for the sake of ffmpeg.c
[13:29:12 CEST] <nevcairiel> then it breaks next week when ffmpeg.c is updated to codecpar
[13:29:14 CEST] <nevcairiel> =p
[13:29:23 CEST] <nevcairiel> and thats not really possible
[13:29:28 CEST] <wm4> nevcairiel: no, ffmpeg.c can be updated, it wouldn't "break" the old API
[13:29:33 CEST] <nevcairiel> those two are strictly synced
[13:30:07 CEST] <wm4> I mean, it'd happen as part of changing ffmpeg.c to codecpar
[13:32:18 CEST] <michaelni> i need to go afk, will read the log later
[14:01:14 CEST] <ubitux> is this guy still trying to push his agpl stuff?
[14:04:11 CEST] <durandal_170> yes. Post him C&D
[14:05:30 CEST] <BBB> I agree we should not merge agpl features in our codebase
[14:05:46 CEST] <BBB> if he wants to maintain it privately in his own branch in his own github, he should absolutely do that
[14:05:56 CEST] <BBB> but agpl connectivity when better versions exist should not be encouraged
[14:06:22 CEST] <BBB> before we know it, a lgplv2.1 build is useless and you need all kind of mututally exclusive options to get any sort of complete ffmpeg build, that would be very sad
[14:06:52 CEST] <BBB> (especially if you cant ship binaries that use a combination of these options because all these licenses have evil we can eat your code but you cant eat ours clauses)
[14:20:55 CEST] <BtbN> AGPL in ffmpeg would probably make _a lot_ of major users nervous.
[14:24:56 CEST] <wm4> so openjpeg also requires GPL? and GPL3 at that?
[14:26:27 CEST] <BtbN> The OpenJpeg I found is BSD licensed, so i'm not exactly sure what this is about.
[14:26:46 CEST] <BtbN> Are there multiple OpenJpegs?
[14:27:22 CEST] <ubitux> the guy forked openjpg and changed the license to a nasty one? 
[14:27:28 CEST] <ubitux> or sth like that?
[14:28:39 CEST] <wm4> yeah, openjpeg is definitely still BSD
[14:29:06 CEST] <BtbN> And how does some external fork of a library affect ffmpeg, as long as the code in ffmpeg is (L)GPL licensed?
[14:29:15 CEST] <wm4> "Grok is a high performance open source JPEG 2000 codec, based on the OpenJPEG reference implementation of the standard"
[14:29:33 CEST] <BtbN> So it's an API/ABI compatible drop-in replacement?
[14:29:57 CEST] <wm4> so if this is API-compatible... what we really should do is adding a check whether it's openjpeg or grok, and if it's grok, reject it due to incompatible license
[14:30:35 CEST] <BtbN> Is AGPL really incompatible with GPL? Or would a user who decides to use GROK just have to accept what it being AGPL implies?
[14:32:19 CEST] <wm4> GNU has a compatibility matrix for GPL, but it doesn't mention AGPL (lol)
[14:34:27 CEST] <wm4> https://www.gnu.org/philosophy/license-list.html#AGPL
[14:34:37 CEST] <wm4> so it looks like if ffmpeg is GPLv3, it can link to AGPL libs
[14:36:44 CEST] <BtbN> But not if built in LGPL mode?
[14:36:50 CEST] <wm4> correct
[14:41:24 CEST] <BtbN> It's primarily up to the distributor to do the right thing then, ffmpeg can't take care of every license a possible ABI-Compatible lib might have.
[14:43:09 CEST] <BtbN> I wonder what happens if someone writes a proprietary library that is 100% compatible to some GPL stuff, and can act as a binary drop-in replacement. Does that violate anything?
[14:43:51 CEST] <jkqxz> I think it's reasonable to accept linking to AGPL library code, but it needs an explicit configure option ("--enable-agplblah", probably with a big warning saying that there are onerous constraints you need to be aware of).  Distribution is possible, but it's up to the user to work out what they're allowed to do.  Also, it is likely entirely incompatible with "--enable-nonfree", even without any distri
[14:43:57 CEST] <jkqxz> bution.
[14:44:24 CEST] <BtbN> nonfree makes the binary non-redistributable anyway
[14:44:33 CEST] <BtbN> so if you go non-free, you don't care anyway.
[14:45:15 CEST] <jkqxz> Yes, but AGPL + nonfree may make it entirely unusable, not just unredistributable.
[14:45:50 CEST] <BtbN> AGPL in general renders it unuseable for some people
[14:46:04 CEST] <BtbN> Which is why I wouldn't want any AGPL code in ffmpeg itself
[14:46:22 CEST] <BtbN> But if someone decides to link in a compatible AGPL lib, that's up to him
[14:46:52 CEST] <BtbN> Even if he would link some incompatible lib, it's still his own problem.
[14:46:56 CEST] <nevcairiel> the problem with AGPL is that it opens an entirely new section about licensing
[14:47:06 CEST] <nevcairiel> everything else just cares about you redistributing it
[14:47:13 CEST] <nevcairiel> but AGPL cares about you using it
[14:47:35 CEST] <nevcairiel> so even a nonfree build for your local usage is free from AGPL clauses
[14:49:07 CEST] <flux> ("is not free" you mean?)
[14:49:22 CEST] <nevcairiel> right
[14:52:13 CEST] <ethe> wm4: it is grok. http://webcache.googleusercontent.com/search?q=cache:Vb1zP3orbgEJ:encode.ru/threads/2477-Grok-JPEG-2000-Codec+&cd=2&hl=en&ct=clnk&gl=fr
[14:53:12 CEST] <ethe> oh right. I thought you were wondering if this guy's thing was grok (rather than openjpeg). dont mind me
[14:58:11 CEST] <Gramner> ugh, AGPL seems like such a licensing nightmare
[15:02:16 CEST] <nevcairiel> the guy doesnt seem to get that its not about "is it legally possible", but that we dont want it =p
[15:02:23 CEST] <Gramner> having specific rules and conditions for simply using (and not just distributing) a piece of software may be common in proprietary software, but it dosn't really belong in OSS imo
[15:02:54 CEST] <nevcairiel> most software uses AGPL as a tool to make money via dual licensing
[15:03:31 CEST] <nevcairiel> all in the name of freedom
[15:03:56 CEST] <BtbN> AGPL raises way too many questions
[15:04:24 CEST] <BtbN> if YouTube encodes a file with a AGPL-Build of ffmpeg, would it still have to distribute its ffmpeg sourcecode, even if ffmpeg is not the one communicating over the network?
[15:05:11 CEST] <j-b> yes, they would.
[15:06:33 CEST] <flux> I feel this would be best solved with AV_CODEC_ID_AGPL_COMPLIANT_SOURCE_CODE_DUMP.
[15:07:36 CEST] <flux> just put the sources alongside the videos.
[15:12:12 CEST] <BBB> I feel this is best solved by not accepting agpl code in our codebase
[15:12:21 CEST] <BBB> he can host the agpl code branch himself and find users for it
[15:12:30 CEST] <BBB> users that want it will find it
[15:12:32 CEST] <BtbN> I don't think that's what he wants anyway
[15:12:35 CEST] <BBB> and we can go on our own merry way
[15:12:39 CEST] <BtbN> he "only" wants to link to this AGPL OpenJpeg fork
[15:12:58 CEST] <nevcairiel> if its api compatible then there isnt anything we can do to prevent that anyway
[15:13:12 CEST] <nevcairiel> unless we specifically add a check, but that seems stupid
[15:13:17 CEST] <BtbN> well, it seems to be slightly diffrent, and his patch fixes that
[15:16:33 CEST] <wm4> <BBB> I feel this is best solved by not accepting agpl code in our codebase <- agreed
[16:29:06 CEST] <Gramner> https://www.videolan.org/videolan/events/vdd16/index.html QtCon huh. might be interesting
[16:35:20 CEST] <Daemon404> i wonder if itll end uo with cliques
[16:35:35 CEST] <kierank> I am a one man clique
[16:35:51 CEST] <Gramner> probably
[16:37:41 CEST] <durandal_170> who will come?
[16:38:33 CEST] <Gramner> I mean, I assume most meople here are more into multimedia stuff than desktop interface GUI development. but drinking beer with various random people is usually fun
[16:40:04 CEST] <Daemon404> the vlc guys have some overlap
[16:40:10 CEST] <Daemon404> since vlc has a bunch of qt code
[16:40:25 CEST] <Daemon404> and it is VideoLAN Dev Days ;)
[16:40:46 CEST] <Gramner> true
[16:41:16 CEST] <Daemon404> nevcairiel, ... ugh
[16:41:26 CEST] <Daemon404> so what, we're stuck with "drop lowres" or "rewrite ffmpeg.c"?
[16:41:31 CEST] <Daemon404> what a shitty place to be
[16:41:53 CEST] <nevcairiel> well or  "add two more properties just for lowres"
[16:42:17 CEST] <Daemon404> they all suck
[16:42:36 CEST] <Daemon404> for differenr reasons (technical, politics)
[16:44:50 CEST] <BBB> hm, wait, I need to apply for talks last month?
[16:44:55 CEST] <BBB> thats kinda strange
[16:45:09 CEST] <BBB> like, isnt it april now? it says CfP is in march, and I didnt even know there would _be_ a VDD16
[16:45:17 CEST] <BBB> (and Id like to present some stuff)
[16:45:21 CEST] <BBB> or maybe not
[16:45:28 CEST] <Gramner> "The submission deadline is 15th May, 23:59:59 CEST."
[16:46:05 CEST] <Gramner> https://dot.kde.org/2016/04/04/qtcon-call-papers
[16:47:26 CEST] <BBB> Im not sure any talk I could give would be remotely related to kde or qt
[16:47:42 CEST] <Daemon404> it doesnt have to be, nor should it have to be
[16:47:48 CEST] <Gramner> why would they have to be?
[16:48:10 CEST] <BBB> the cfp list of subjects is mostly kde related
[16:48:31 CEST] <BBB> the term video only ever appears in one of the headings where it mentions the existence of some project known as videolan
[16:48:33 CEST] <Gramner> I interpret that as "including, but not limited to"
[16:48:44 CEST] <BBB> hm, I hope so
[16:54:10 CEST] <Daemon404> rcombs, pok
[16:54:11 CEST] <Daemon404> e
[16:55:08 CEST] <durandal_170> break lowres stupid api
[16:56:29 CEST] <j-b> BBB: it's just co-hosted. CfP is not for us.
[16:57:24 CEST] <BBB> ah I see
[16:57:27 CEST] <BBB> okiedokie
[16:57:34 CEST] <BBB> berlin sounds nice btw, never been there
[17:14:56 CEST] Action: Daemon404 wasi n belrin giving a tal kto a bunch of old SMPTE guys lats year
[17:21:50 CEST] <Compn> neat berlin. havent been there yet :P
[17:22:00 CEST] <ubitux> finally a cool feature with gdb: continue with a numerical argument
[17:25:33 CEST] <Daemon404> me = smart/g 42
[17:25:37 CEST] <Daemon404> ... shit
[17:25:47 CEST] <ubitux> :D
[17:34:08 CEST] <JEEB> :D
[17:36:08 CEST] <Daemon404> ... wtf
[17:36:14 CEST] <Daemon404> im trying to fix concatdec... but like
[17:36:19 CEST] <Daemon404> it NEVER calls filter_close?!
[17:41:40 CEST] <Shiz> Daemon404: the ride
[17:41:41 CEST] <Shiz> never
[17:41:43 CEST] <Shiz> ends
[17:42:14 CEST] <Daemon404> ... yes
[17:42:17 CEST] <Daemon404> even git master leaks
[17:47:27 CEST] <wm4> heh
[17:55:08 CEST] <Daemon404> seems it has multiple leaks all over the place
[17:56:46 CEST] <Daemon404> everything about this file is awful
[18:00:40 CEST] <durandal_170> Don't be evil
[18:19:20 CEST] <nevcairiel> concat is a crappy implementaiton of a questionable feature, you didnt know this before today? =p
[18:25:38 CEST] <durandal_170> bunch of people use it
[18:26:11 CEST] <JEEB> and plenty of people notice it doesn't work on a lot of stuff
[18:26:19 CEST] <JEEB> like mov
[18:26:28 CEST] <JEEB> it probably works on stuff like mpeg-ts, kind of
[18:26:32 CEST] <durandal_170> when leaks happens in filter?
[18:26:49 CEST] <durandal_170> this is filter
[18:26:50 CEST] <JEEB> oh, we're talking of the filter?
[18:26:59 CEST] <JEEB> which seemed less bad than the demuxer
[18:27:10 CEST] <JEEB> "<@Daemon404> im trying to fix concatdec..."
[18:27:15 CEST] <JEEB> concatdec IIRC is the demuxer, no?
[18:27:27 CEST] <durandal_170> hmm?
[18:28:17 CEST] <durandal_170> yeah concatdec shouldnt call filter_close
[18:28:33 CEST] <wm4> libavformat is so batshit
[18:28:39 CEST] <wm4>         (st->codec->codec_id != -st->info->found_decoder || !st->codec->codec_id)) {
[18:28:41 CEST] <wm4> real code
[18:28:53 CEST] <JEEB> > wat
[18:29:19 CEST] <Daemon404> i did fix it in the end
[18:29:48 CEST] <durandal_170> How/what/where?
[18:34:40 CEST] <ubitux> JEEB: we actually use it in production to create mov, it works
[18:34:48 CEST] <ubitux> i think.
[18:35:17 CEST] <nevcairiel> wm4: that code isnt that bad once  you understand the meaning of found_decoder
[18:35:57 CEST] <JEEB> ubitux: I also use the concat filter in production
[18:36:23 CEST] <JEEB> the concat demuxer I don't because my input might not be stuff that works with it
[18:36:37 CEST] <JEEB> and I was talking of mov input of course, not output
[18:36:49 CEST] <JEEB> because concat demuxer IIRC just feeds stuff to the demuxer one after another?
[18:38:08 CEST] <ubitux> yes
[18:38:22 CEST] <ubitux> with some timing adjusts
[18:38:46 CEST] <ubitux> it works fine for our inputs so far, but we control the encode of the inputs
[18:38:59 CEST] <JEEB> yeah, I understand it in that case
[18:40:47 CEST] <nevcairiel> concat filter can work properly because it works on decoded raw data, but concat demuxer tries to work on a packet level, that causes issues all the time
[18:40:55 CEST] <JEEB> yeah
[18:43:36 CEST] <ubitux> i'm very happy to have this tbh
[18:43:47 CEST] <ubitux> pretty useful
[18:44:02 CEST] <JEEB> yeah, if you know the limitations of the concat demuxer it can be of use
[18:44:17 CEST] <JEEB> the problem is when random users try to use it :)
[18:45:09 CEST] <rcombs> Daemon404: hi
[18:50:31 CEST] <wm4> do I see this right that libavformat opens a decoder even if it could get the information from a prser?
[18:50:34 CEST] <wm4> *parser
[18:50:50 CEST] <wm4> or am I just confused
[18:51:44 CEST] <nevcairiel> it always opens a decoder, so it could parse extradata or just init values to defaults
[18:52:01 CEST] <wm4> lame
[18:52:56 CEST] <nevcairiel> parsers dont really provide much info at all to the entire process at all anymore either way, because they still dont fit into the model =p
[18:54:07 CEST] <wm4> yeah, now
[18:54:23 CEST] <wm4> (why am I thinking that elenril should have fixed parsers first)
[18:55:22 CEST] <Daemon404> nevcairiel, i may need some help
[18:55:26 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/issues/20
[19:07:16 CEST] <rcombs> nevcairiel: actually if the parser _does_ provide all the information lavf is looking for, it won't open the decoder
[19:07:23 CEST] <rcombs> nevcairiel: just, parsers don't tend to do that
[19:07:30 CEST] <nevcairiel> rcombs: they also cant anymore =p
[19:07:34 CEST] <rcombs> because one of the things lavf is looking for is a pixel format
[19:07:43 CEST] <rcombs> (or sample format)
[19:08:17 CEST] <wm4> rcombs: where does this happen?
[19:08:30 CEST] <rcombs> wm4: in a patch I tried out a bit ago
[19:08:33 CEST] <wm4> not opening a decoder while the parser is still processing packets, I mean
[19:09:16 CEST] <rcombs> I tweaked parser.c to copy information from the parser context to the stream's codec context (so I guess it'd be codecpar now) if it wasn't already filled
[19:09:31 CEST] <rcombs> lavf responded by not opening the decoder
[19:09:47 CEST] <rcombs> unfortunately, this also meant a bunch of information that the decoder normally filled wouldn't be
[19:10:05 CEST] <rcombs> (stuff that lavf didn't consider a failure if it wasn't present)
[19:16:50 CEST] <Daemon404> rcombs, im trying to make bsfs work.. and i simpyl cant see a way to make teh api work as before
[19:16:59 CEST] <Daemon404> av_apply_bitstream_filters lacks an AVStream
[19:17:19 CEST] <Daemon404> i.e. nowhere to copy extradata to
[19:17:34 CEST] <nevcairiel> it copies it into the avcodeccontext you give it
[19:17:40 CEST] <nevcairiel> you just have to get it out of there
[19:17:47 CEST] <Daemon404> that requries modifing fmpeg.c
[19:18:56 CEST] <Daemon404> which i thought wasa no-no
[19:18:58 CEST] <rcombs> looks like they write into codecpar now?
[19:19:10 CEST] <Daemon404> not at the point where teh merge is
[19:19:14 CEST] <Daemon404> youre thinkign of the new bsfi api
[19:19:21 CEST] <rcombs> yeah, that's what I'm looking at
[19:19:22 CEST] <nevcairiel> new bsf api is independent of all of that
[19:19:27 CEST] <nevcairiel> it doesnt use codecpar either
[19:19:38 CEST] <rcombs> nevcairiel: I'm looking at https://github.com/libav/libav/blob/master/libavcodec/h264_mp4toannexb_bsf.c#L125
[19:19:40 CEST] <nevcairiel> just avpacket
[19:19:55 CEST] <Daemon404> rcombs, we are not at that point yet
[19:20:19 CEST] <nevcairiel> i looked at the aac one yesterday and it did it quite differently
[19:20:20 CEST] <nevcairiel> odd
[19:20:48 CEST] <rcombs> oh, it does AV_PKT_DATA_NEW_EXTRADATA
[19:20:54 CEST] <rcombs> interesting
[19:21:00 CEST] <nevcairiel> no clue why it uses different methods
[19:21:36 CEST] <rcombs> maybe aac is perceived as more likely to change those parameters mid-stream?
[19:21:56 CEST] <nevcairiel> well so could annexb h264
[19:22:07 CEST] <rcombs> &but this only runs on the first frame
[19:22:29 CEST] <rcombs> maybe one was written before one of the methods was available
[19:22:57 CEST] <rcombs> but either way, both are ~future~
[19:23:23 CEST] <rcombs> Daemon404: do you have your existing branch pushed somewhere I can glance at?
[19:24:53 CEST] <Daemon404> barcnh of what?
[19:24:59 CEST] <Daemon404> i havent made any headway on bsfs
[19:25:01 CEST] <Daemon404> nothing to push
[19:25:10 CEST] <Daemon404> or do you just want codecpar
[19:26:13 CEST] <rcombs> if it's even with codecpar, just point me at what branch you're working from
[19:26:15 CEST] <Daemon404> i mamanged to make bsfs work *if i modify ffmpeg.c to copy extradata*
[19:26:19 CEST] <Daemon404> managed*
[19:26:27 CEST] <Daemon404> thats as far as i got
[19:27:04 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/commits/codecpar_rebase
[19:27:06 CEST] <Daemon404> branch is here
[19:29:16 CEST] <Daemon404> http://pastie.org/10785351 <-- hacking this into ffmpeg.c fixes bsfs
[19:29:30 CEST] <Daemon404> but im prtety sure nevcairiel will slap me if i do that ;)
[19:30:08 CEST] <nevcairiel> just fix it in the autobsf and screw ffmpeg, it fixes itself in the commit after anyway
[19:30:47 CEST] <rcombs> that ignores the case where the extradata contents change but not the size ;3
[19:30:57 CEST] <rcombs> (probably not common but possible)
[19:31:02 CEST] <Daemon404> :P
[19:31:07 CEST] <Daemon404> sure, but you get the idea
[19:34:45 CEST] <Daemon404> nevcairiel, splitting mov's write_header looks not entirely trivial
[19:34:48 CEST] <Daemon404> due to multiple mode
[19:35:31 CEST] <Daemon404> i think one call must be done before streams are added
[19:35:32 CEST] <rcombs> Daemon404: seems you did that before the av_apply_bitstream_filters call?
[19:35:52 CEST] <Daemon404> rcombs, did what?
[19:36:21 CEST] <rcombs> oh wait, I'm looking at https://github.com/dwbuiten/FFmpeg/blob/1f4d7122a9249b081bf826fa26479ea02e1cbae6/ffmpeg.c#L641
[19:36:22 CEST] <Daemon404> the pastebin hack i pasted is after the call
[19:36:29 CEST] <Daemon404> i did not push it obv
[19:36:38 CEST] <Daemon404> thats old code
[19:36:46 CEST] <rcombs> there was already a copy there for some reason?
[19:36:58 CEST] <Daemon404> i dont know ffmpeg.c
[19:37:22 CEST] <Daemon404> seems like it should be below, no?
[19:38:00 CEST] <Daemon404> or are the bsfs which need extradata...?
[19:40:33 CEST] <Daemon404> oh its enc_ctx
[19:40:43 CEST] <durandal_170> michaelni: will you comment mestimate patch?
[19:41:12 CEST] <Daemon404> nevcairiel, i dont think we can just fix autobsf
[19:41:17 CEST] <Daemon404> converting mov to work is nontrivial
[19:41:46 CEST] <Daemon404> i think.
[19:51:43 CEST] <nevcairiel> init doesnt have to be that magical
[19:53:21 CEST] <Timothy_Gu> "Grok J2k Codec : now integrated with FFMpeg for high performance J2K streaming http://bit.ly/1ZBbqb2  #opensource #jpeg2000"
[19:53:44 CEST] <JEEB> wut
[19:54:30 CEST] <Timothy_Gu> https://twitter.com/boxerab/status/714645037435498497
[19:54:43 CEST] <ubitux> lol
[19:55:06 CEST] <Daemon404> nevcairiel, i just converted it an fate-movenc passes (it tests DASH)
[19:55:15 CEST] <Daemon404> running full fate now
[19:55:34 CEST] <Daemon404> ... nah
[19:55:37 CEST] <Daemon404> lavf-mov explodes.
[19:56:03 CEST] <Daemon404> nevcairiel, yes but mov's write_header seems to eb very delicate
[19:56:17 CEST] <durandal_1707> what? Grok patches got commtted?
[19:56:18 CEST] <Daemon404> e.g. stuff must be written before some streams are added i thin
[19:56:23 CEST] <Daemon404> which would make init impossible
[19:56:24 CEST] <Daemon404> no?
[20:01:28 CEST] <nevcairiel> write_header is called *after* streams are created
[20:02:11 CEST] <Daemon404> well im not sure whats wrong then.
[20:06:02 CEST] <Daemon404> it does have a lot of timescale code that looks not-so-easy to separate into init
[20:06:25 CEST] Action: Daemon404 may be the wrong person to work on this
[20:08:22 CEST] <rcombs> the timescale stuff is probably the most important stuff to move into init :3
[20:09:58 CEST] <Daemon404> is there a list of stuff init must do
[20:12:05 CEST] <Daemon404> also does init get called before ot after streams are created and filled with info
[20:13:01 CEST] <nevcairiel> init gets called when write_header was previously called, and write_header is delayed
[20:13:14 CEST] <nevcairiel> afaik
[20:14:02 CEST] <Daemon404> i see
[20:14:08 CEST] <Daemon404> so it is ok to access codecpar->sample_rate?
[20:15:12 CEST] <nevcairiel> if write_header did
[20:15:13 CEST] <nevcairiel> then yes
[20:15:28 CEST] <nevcairiel> its literally called right before if no autobsf is used
[20:15:38 CEST] <nevcairiel> only with autobsf write_header is delayed
[20:15:55 CEST] <Daemon404> ok
[20:20:09 CEST] <Daemon404> try 2
[20:22:20 CEST] <Daemon404> crashes
[20:34:24 CEST] <Daemon404> rcombs, assumign i get mov ported, do you think you can make autobsf work in codecpar
[20:34:43 CEST] <rcombs> Daemon404: probably not on that branch without ffmpeg.c modifications
[20:34:56 CEST] <Daemon404> nevcairiel, ^
[20:35:03 CEST] <nevcairiel> that makes no sense
[20:35:08 CEST] <nevcairiel> autobsf is independent of ffmpeg.c
[20:35:18 CEST] <rcombs> sorry, I was unclear
[20:35:32 CEST] <rcombs> might have to deprecate av_apply_bitstream_filters in favor of one that takes an AVStream arg
[20:35:54 CEST] <rcombs> which would require ffmpeg.c to move
[20:36:21 CEST] <nevcairiel> dont do that, that function needs to change with the bsf rework anyway
[20:36:21 CEST] <rcombs> for autobsf it could be done entirely within lavf, sure
[20:36:30 CEST] <nevcairiel> we can just fix it then
[20:36:33 CEST] <rcombs> sure
[20:37:12 CEST] <rcombs> if it's just doing it in mux.c, sure, I can do that
[20:37:16 CEST] <Daemon404> pls do
[20:51:47 CEST] <Angus> Hey guys
[20:52:42 CEST] <Angus> I have a bit of a strange situation here, where I have a pre-existing buffer and max_packet_size for a stream, but no AVFormatContext 
[20:53:19 CEST] <Angus> is there any alternate functions to avformat_open_input, but I might be able to pass a preexisting buffer to?
[20:55:02 CEST] <Angus> (whoever wrote this code before me decided the best way to go about this was to modify FFMpeg source, and compile their own fork of it)
[20:55:54 CEST] <michaelni> durandal_1707, did a quick review/test of mestimate, feel free to do a review as well
[20:56:24 CEST] <JEEB> Angus: you were noted two ways of handling this back when you came here with your citrix thing
[20:56:39 CEST] <JEEB> 1) use a custom avio wrapper and parse the things with AVFormat using it
[20:56:50 CEST] <JEEB> (if I can make a custom AVIO thing then you can as well, I am dumb)
[20:57:31 CEST] <JEEB> 2) IIRC it was just raw AVC, so just use avcodec by itself (harder, less wheels included)
[20:58:17 CEST] <JEEB> you instead chose to go the way that you tried to make that piece of crap work without making it sane. seems like you finally noticed that wasn't going to fly
[20:59:52 CEST] <Angus> I finally figured out what Citrix was doing recently, although still have little idea how AVFormat works; it's a slow learning process
[21:01:40 CEST] <JEEB> http://www.ffmpeg.org/doxygen/trunk/doc_2examples_2avio_reading_8c-example.html
[21:02:03 CEST] <JEEB> it seems like there even is a custom avio read example
[21:02:37 CEST] <JEEB> where you define your own read function and make libavformat use it
[21:03:05 CEST] <Daemon404> rcombs, i got mov ported
[21:03:14 CEST] <rcombs> \o/
[21:03:59 CEST] <Daemon404> hows mux.c comign? :)
[21:07:02 CEST] <Angus> avformat_open_input is also AVIO wrapper?
[21:07:21 CEST] <JEEB> no, that can just take an avio context
[21:07:53 CEST] <JEEB> so you create the avio context and then use it to use avformat :P
[21:09:26 CEST] <Daemon404> nevcairiel, after autobsf is fixed + mov port, it should be considered bsfs = done?
[21:14:38 CEST] <Angus> Once the avio_context is allocated and modified, does avformat_open_input do anything with the URLContext?
[21:15:03 CEST] <JEEB> no
[21:15:16 CEST] <JEEB> since the urlcontext crap in that thing was a horrible hack to do something similar
[21:16:32 CEST] <JEEB> 1) make avio context with a read function that reads from your buffer 2) have avformat use it 3) ??? 4) profit
[21:17:49 CEST] <Daemon404> rcombs, is there something else i need to do to get autobsf to recognize a demuxer
[21:17:52 CEST] <Daemon404> other than add .init?
[21:18:08 CEST] <rcombs> Daemon404: add a .check_bitstream and actually do things in it
[21:18:35 CEST] <rcombs> (probably just copy matroska's and remove the VP9 bit)
[21:19:06 CEST] <Daemon404> ok
[21:19:23 CEST] <Angus> What does URLContext do anyway?
[21:19:25 CEST] <Daemon404> i seem to have 'fixed' mux.c but i probably did it wrong
[21:20:26 CEST] <Angus> seemingly, if I got passed a buffer_read function to AVIO_context, the entire URLProtocol seems no-longer-needed
[21:20:48 CEST] <JEEB> it has also been deprecated for ages as far as I know
[21:21:02 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__old__url__funcs.html#_details
[21:22:02 CEST] <JEEB> also avio has the thing that it's public :P
[21:22:51 CEST] <JEEB> while url.h says "unbuffered *private* I/O API"
[21:23:10 CEST] <Angus> (I'm not horribly worried about using internal functions, I'm just trying to get it to work, without modifying FFMpeg itself)
[21:23:39 CEST] <Daemon404> rcombs, http://pastie.org/private/o6rddloisx8hirxcboyxq
[21:23:40 CEST] <Angus> (once it works without modifying FFMpeg, then perhaps it could use the public functions)
[21:23:41 CEST] <Daemon404> does this look right
[21:23:57 CEST] <Daemon404> it seems to work
[21:24:52 CEST] <rcombs> looks fine
[21:24:56 CEST] <JEEB> well you just said that avio makes the urlprotocol completely useless. that is because it is and I can't fathom why citrix used it instead of avio (or just doing manual parsing and avcodec only if they wanted possibly lower amounts of buffers around things)
[21:26:58 CEST] <Angus> I have no idea. I'll ask tomorrow though.
[21:27:05 CEST] <Daemon404> rcombs, ok
[21:27:12 CEST] <Daemon404> nevcairiel, ping, one last qustion re: bsfs
[21:27:23 CEST] <Daemon404> are you SURE we shouldnt fix ffmpeg.c temporarily
[21:27:40 CEST] <Daemon404> ffmpeg -i *aac -c copy -t 0.1 b.m4a  <-- works
[21:27:44 CEST] <Daemon404> ffmpeg -i *aac -c copy -bsf:a aac_adtstoasc -t 0.1 b.m4a <-- doesnt work
[21:27:51 CEST] <Daemon404> (now with a fixed autobsf)
[21:29:59 CEST] <rcombs> I'd be fine with a temporary fix there if we cleaned it up when the new bsf API merges
[21:30:08 CEST] <Daemon404> thats what i was going to suggest
[21:38:15 CEST] <wm4> is the BSF API even pushed in Libav
[21:39:13 CEST] <jamrial> yes
[21:39:38 CEST] <Daemon404> a logn tiem ago
[21:39:41 CEST] <jamrial> better question would be, was bsf broken post codecpart and pre new bsf for them as well, or not?
[21:39:49 CEST] <Daemon404> of course it was
[21:40:11 CEST] <jamrial> so why should we bother to hack a dirty fix if the real fix is queued?
[21:40:40 CEST] <jamrial> we're doing a release every three to four months. it's not the pre-0.6 era anymore
[21:40:45 CEST] <Daemon404> its a few lines, and who knows how long it will take to merge stuff
[21:40:48 CEST] <jamrial> you shouldn't expect things to work perfectly and regressions to be gone fast if you use master, that's what stable releases are for
[21:40:50 CEST] <Daemon404> libav pushed it all at once
[21:40:53 CEST] <Daemon404> we dont have that luxury
[21:41:14 CEST] <Daemon404> LD      ffserver_g
[21:41:16 CEST] <Daemon404> woops
[21:41:23 CEST] <jamrial> alright, if it's an easy fix then sure. i assumed it would be hard and/or messy
[21:41:29 CEST] <Daemon404> i already pushed it :P
[21:41:34 CEST] <jamrial> oh, haha
[21:41:35 CEST] <Daemon404> yo ucan look if you want
[21:57:25 CEST] <Daemon404> so current otusating issues are lowres and that weird concatdec thing (not that i tell if it even IS an issue(
[22:03:02 CEST] <durandal_1707> ok to push musx and dat4?
[22:56:18 CEST] <cone-639> ffmpeg 03Martin Vignali 07master:062ad63064b5: libavcodec/exr : cosmetic change
[22:56:19 CEST] <cone-639> ffmpeg 03Martin Vignali 07master:832861535a51: libavcodec/exr : add support for compression in tile
[23:00:20 CEST] <Daemon404> michaelni / wm4 / nevcairiel - i think there is nothing else i can do on codecpar right now. im stumped at the concat thing (if it even is an issue), and lowres = you guys deciding.
[23:00:32 CEST] <Daemon404> so uh... k?
[23:02:26 CEST] <wm4> I'm in favor of adding a shitty hack for lowres or blatantly removing it
[23:03:33 CEST] <iive> i've never liked lowres.
[23:03:55 CEST] <iive> at blatant levels of lowres i get the same speedup as using gray only decoding.
[23:04:33 CEST] <iive> and imho, better picture quality.
[23:06:47 CEST] <llogan> i've never used it
[23:07:54 CEST] <Daemon404> iive, not many people like it
[23:08:00 CEST] <Daemon404> i only know 1 or 2 people who do
[23:11:05 CEST] <iive> well, lowres sounds great in theory. producing 2^3 less pixels should give remarkable speed up. but at my tests i got just 30%
[23:11:47 CEST] <Daemon404> also it is not even available on any modern codecs.
[23:12:28 CEST] <iive> not in ff h264?
[23:12:37 CEST] <michaelni> jpeg & j2k support it
[23:13:03 CEST] <michaelni> so image codecs do have some support for it
[23:13:25 CEST] <iive> and they are intra only, so less artifacts.
[23:13:33 CEST] <wm4> we could also just drop the fate test for it
[23:13:41 CEST] <Daemon404> i dont think thats really a solution
[23:14:00 CEST] <wm4> sounds like  good solution to me
[23:14:02 CEST] <Daemon404> may as well stick your fingers in your ears and go lalalalala
[23:14:10 CEST] <michaelni> i think breaking the API is better than removing lowres not that i like breaking the API
[23:14:59 CEST] <iive> what's the issue?
[23:15:44 CEST] <wm4> it's really dumb
[23:16:00 CEST] <wm4> it implies an API user is setting lowres both on the demuxef and the decoder
[23:16:09 CEST] <wm4> just stupid
[23:29:50 CEST] <durandal_1707> I'm for removing stupid API
[23:33:26 CEST] <rcombs> how does lowres make sense on a demuxer?
[23:36:51 CEST] <wm4> rcombs: because these API users (supposedly) rely on the demuxer showing the same parameters as the decoder
[23:37:08 CEST] <wm4> because they e.g. setup a filter chain based on the demuxer params
[23:37:17 CEST] <wm4> ffmpeg.c does this (unfortunately)
[23:37:49 CEST] <Daemon404> we can probably stop explaining why/how its bad over and over again soon
[23:37:55 CEST] <Daemon404> nobody is disagreeing on that point
[23:38:06 CEST] <Daemon404> more interesting is a way forward
[23:39:26 CEST] <Daemon404> ... ugghhhhh ffserver segfault
[23:39:39 CEST] <Daemon404> that is the very last thing i want to look at
[23:39:59 CEST] <wm4> ignore it
[23:40:09 CEST] <Daemon404> im realistic
[23:40:22 CEST] <Daemon404> ffserver segfault will block merge
[23:40:28 CEST] <Daemon404> too many insane people
[23:40:37 CEST] <wm4> if someone complains give them 24h to fix it
[23:41:30 CEST] <Daemon404> ffserver segfaults with near null pointer dereference in av_codec_set_pkt_timebase() 
[23:41:34 CEST] <Daemon404> hey wm4 is yours other best pal
[23:41:37 CEST] <Daemon404> your*
[23:41:37 CEST] <wm4> and I don't appreciate what michaelni is doing here (or rather, how he is doing it)
[23:41:49 CEST] <Daemon404> i appreciate the wide testing
[23:41:57 CEST] <Daemon404> some good stuff was caught
[23:42:17 CEST] <Daemon404> i dont really care much for some of the "bugs", but thats another story
[23:42:27 CEST] <wm4> yes, but he is a dev who knows the code very well, so at least he could fix trivial ones himself, or not report things broken in master
[23:44:00 CEST] <michaelni> i could if i had more time, i need to go to bed soon today and likely wont have time tomorrow before evening or afternoon maybe
[23:45:19 CEST] <wm4> I can try my idea to apply lowres only to AVStream.codec tomorrow
[23:45:40 CEST] <Daemon404> ok
[23:49:21 CEST] <Daemon404> michaelni, how do i test ffserver even
[23:49:27 CEST] <Daemon404> my dev box is headless, i cant use ffplay
[23:50:40 CEST] <Daemon404> nvm got it
[23:55:57 CEST] <Daemon404> ... what thell
[23:55:58 CEST] <Daemon404>     avpriv_set_pts_info(fst, 33, 1, 90000);
[23:56:01 CEST] <Daemon404> ffserver calls this
[23:56:04 CEST] <Daemon404> and it crashes in there
[23:56:43 CEST] <nevcairiel> probably because it creates a fake AVStream without the internal data structures
[23:56:56 CEST] <nevcairiel> if you call private shit, you better do it right
[23:59:32 CEST] <Daemon404>     fst->internal = av_mallocz(sizeof(*fst->internal));
[23:59:35 CEST] <Daemon404> it does do this
[23:59:49 CEST] <cone-639> ffmpeg 03Marton Balint 07master:a07934d51b40: ffplay: fix silence insertion on error or pause
[00:00:00 CEST] --- Tue Apr  5 2016