Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

April 2016

1 participants
60 discussions

ffmpeg-devel.log.20160404
by burek 05 Apr '16

05 Apr '16

[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@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).… 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… [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.… [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/1f4d7122a9249b081bf826fa26479ea02e1… [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.… [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

1 0

ffmpeg.log.20160404
by burek 05 Apr '16

05 Apr '16

[04:36:49 CEST] <tester> Hi. I'm working on an image processing project, and am new to ffmpeg. I'm decoding an MPEG-4 video file and I need to access the frames in RGB format. My question is: which type of decoding result will be fastest, planar or packed pixel? Thanks. [04:51:42 CEST] <TD-Linux> generally planar [04:53:31 CEST] <kepstin> hmm, to decode mpeg-4 to rgb, you need to do a format conversion from yuv to rgb [04:53:47 CEST] <kepstin> i think they'll probably both be about the same, really. [04:54:06 CEST] <kepstin> and packed rgb is usually better-supported than planar by other software [05:08:22 CEST] <tester> Alright, thanks [09:33:06 CEST] <xxzzxx> hi [09:33:19 CEST] <xxzzxx> anyone here ? [15:42:46 CEST] <thunfisch> hi, can anyone point me to some information on how to compile ffmpeg with decklink support for ubuntu 16.04? right now it's complaining about the missing sdk-headers of course, but i don't know where to put those. [16:15:35 CEST] <xochilpili> hi all [16:16:34 CEST] <Elgu> hi [16:17:04 CEST] <xochilpili> i have in my library a lot of movies and series, but they're in different format, mp4, avi, mkv mostly, i have installed plex in the server in order to watch them, but im experiencing some troubles with plex, and i think about to make my own "plex" [16:17:44 CEST] <xochilpili> but as far i understand, <video> tags in html5 can only reproduce ogg, mp4 files but not mkv [16:18:10 CEST] <tp_> the mkv container works in chrome [16:18:28 CEST] <xochilpili> is there a way to transcode the selected file using ffmpeg in realtime ? i mean, i click on a video that i want to watch, then transcode the mkv into a mp4 in order to watch it [16:18:31 CEST] <kepstin> it's up to the browser, but vp8/vp8 in webm and h.264 in mp4 are the most widely supported [16:18:34 CEST] <xochilpili> is that possible? [16:18:48 CEST] <kepstin> into mp4? no. But you could do webm maybe [16:18:58 CEST] <xochilpili> webm ? [16:19:44 CEST] <kepstin> you could also look at doing HLS or DASH streaming [16:20:58 CEST] <xochilpili> thanks ! [16:21:32 CEST] <Filarius> Hell, how to make ffmpeg take source in "player mode". I record livestreams and they often have A/V sync issue (non-monotonous DTS) on start, and this also make re-encoded record also have A/V sync issue, and even appears in video editing in Sony Vegas [16:21:36 CEST] <Filarius> *Hello [16:22:22 CEST] <Filarius> this issue looks like lag, freeze, or repeating video in first 3 seconds [16:22:56 CEST] <Filarius> http://pastebin.com/jtYnTB58 [16:24:24 CEST] <xochilpili> kepstin, using HLS i need to convert all files into a mp4 or m3u8 ?? [16:25:37 CEST] <kepstin> xochilpili: you'd probably want to use ffmpeg's hls muxer, which generates the playlist and segment files. [16:25:43 CEST] <Filarius> and also issue is not "works" at Web players like in Dropbox, Youtube also somehow fix it, but I have too many videos [16:27:23 CEST] <xochilpili> kepstin, im lost [16:27:39 CEST] <furq> xochilpili: i'd expect most of your mkv files will be h.264 and aac or mp3, in which case you can remux them to mp4 and they'll play in a browser [16:28:35 CEST] <kepstin> as long as there's no subtitles, yeah :) [16:28:44 CEST] <furq> srt subtitles will be fine [16:29:19 CEST] <kepstin> well, most browsers only play external webvtt subs right now :/ [16:29:24 CEST] <kepstin> but I guess that's doable [16:29:26 CEST] <furq> oh, browsers [16:29:33 CEST] <furq> i forgot that quickly [16:29:38 CEST] <xochilpili> im really lost, i dont know how to start [16:29:51 CEST] <xochilpili> i found this: http://ffmpeg.gusari.org/viewtopic.php?f=12&t=914 [16:30:16 CEST] <xochilpili> but i think this guy is capture from a device with video2linux /dev/vide0 [16:30:25 CEST] <xochilpili> which is not my case [16:30:36 CEST] <furq> isn't this the exact problem which plex is supposed to solve [16:30:40 CEST] <furq> i don't see what else it does [16:31:26 CEST] <momomo> furq, i switched to using your suggested version of ffmpeg, static build .. but now I am getting: Decoder (codec dvb_teletext) not found for input stream #0:2 [16:31:37 CEST] <xochilpili> plex remux files? [16:31:47 CEST] <momomo> i think its not able to parse subtitles files or something [16:32:05 CEST] <furq> is there a teletext stream [16:32:13 CEST] <furq> i would have thought that would be ignored [16:32:17 CEST] <momomo> furg, maybe yes .. is there a way to ignore it ? [16:32:44 CEST] <furq> i guess that's a video stream, so just use -map if you don't care about it [16:33:13 CEST] <furq> https://ffmpeg.org/ffmpeg.html#Advanced-options [16:35:03 CEST] <furq> oh maybe it is a subtitle stream [16:35:20 CEST] <furq> try -map -0:s [16:37:24 CEST] <momomo> furq, Stream map '0:s' matches no streams. [16:37:42 CEST] <momomo> it might be that i don't have one now [16:38:19 CEST] <momomo> To ignore this, add a trailing '?' to the map. [16:38:30 CEST] <momomo> -map? -0:s [16:38:33 CEST] <momomo> didn't work [16:38:59 CEST] <momomo> neither did -map -0:s ? [16:40:34 CEST] <momomo> now, it seems i have the same error ( program switched maybe ) Decoder (codec dvb_teletext) not found for input stream #0:2 [16:40:43 CEST] <momomo> even with -map -0:s [16:42:19 CEST] <furq> if it's always stream 0:2 then use -map -0:2 [16:42:25 CEST] <momomo> output http://hastebin.com/ijewetoyon.md [16:42:31 CEST] <momomo> i tried that [16:42:43 CEST] <momomo> that did not work .. doesn't match [16:43:17 CEST] <thunfisch> okay, got my ffmpeg to compile (decklink-sdk headers had to go to /usr/include), but now it's missing the -c, -acopy, -vcopy commands etc. used this config: https://paste.xinu.at/aps/ could it be, that I left too many flags out? [16:43:43 CEST] <furq> momomo: paste the command [16:44:22 CEST] <momomo> here is the command: http://hastebin.com/emusehahox.mel [16:44:23 CEST] <furq> thunfisch: there is no such flag as -acopy or -vcopy [16:44:32 CEST] <furq> it's -c:a copy and -c:v copy [16:44:43 CEST] <thunfisch> oh, okay [16:44:48 CEST] <xochilpili> found this: http://dash-mse-test.appspot.com/dash-player.html [16:44:49 CEST] <furq> and -c copy to copy all streams [16:45:07 CEST] <xochilpili> but how to they create the mpd ? [16:45:09 CEST] <thunfisch> furq: if i use -c, it says command not found [16:45:20 CEST] <xochilpili> how's the server side? [16:45:27 CEST] <furq> command not found is a shell error message, not ffmpeg [16:46:55 CEST] <momomo> furq, me ? [16:47:11 CEST] <furq> i have no idea what's going on with yours [16:47:49 CEST] <furq> 0:s and 0:2 should both work [16:47:52 CEST] <momomo> seems like something has happened in the latter builds .. or maybe this static build is using a different configuration ? [16:48:45 CEST] <furq> i think you need to link with libzvbi to enable dvb_teletext [16:48:47 CEST] <momomo> furq, here is the configuration http://hastebin.com/uroxavijic.mel [16:48:50 CEST] <furq> i guess the static builds don't do that [16:49:04 CEST] <momomo> furq, is it easy to build ffmpeg manually ? [16:49:14 CEST] <momomo> or will i have to spend like a day on that ? [16:49:22 CEST] <furq> it's pretty easy [16:49:40 CEST] <furq> i don't think you should have to, though [16:49:50 CEST] <momomo> the build in ubuntu now uses some libsass that I have too old for .. and I am not sure how to update that [16:49:52 CEST] <furq> you should be able to ignore that stream regardless [16:50:00 CEST] <momomo> there is probably other dependencies [16:50:16 CEST] <momomo> ook .. does the map command look right thouhg ? the location of it ? [16:50:22 CEST] <momomo> or should it be before the input ? [16:50:25 CEST] <momomo> or after [16:50:31 CEST] <furq> it's an output option [16:50:48 CEST] <furq> you could try -map 0:0 -map 0:1 [16:51:00 CEST] <furq> or -map 0:v -map 0:a [16:51:37 CEST] <furq> maybe there's some bug related to ignoring undecodable streams [16:52:06 CEST] <furq> but there should be no need to build your own ffmpeg unless you actually want to decode the subtitles [16:52:40 CEST] <momomo> i couldn't find any new references to it [16:52:42 CEST] <momomo> online [16:53:07 CEST] <furq> references to what [16:53:16 CEST] <momomo> to a bug of that nature [16:53:21 CEST] <furq> oh [16:53:26 CEST] <furq> yeah that's a weird one [16:53:50 CEST] <momomo> even this causes error [16:53:51 CEST] <momomo> Stream map '0:0' matches no streams. [16:54:01 CEST] <momomo> probably not using hte map function properly [16:55:38 CEST] <momomo> ah [16:55:46 CEST] <momomo> i was using -map -0:1 [16:55:51 CEST] <furq> oh right [16:55:57 CEST] <furq> yeah - is to exclude [16:58:04 CEST] <momomo> -map 0:v -map 0:a is correct ? [16:58:10 CEST] <furq> should be [16:58:12 CEST] <momomo> or -map 0:a:2 ? [16:58:15 CEST] <momomo> -sn (output) [16:58:15 CEST] <momomo> Disable subtitle recording. [16:58:20 CEST] <furq> -sn should also work [16:58:49 CEST] <furq> that probably makes more sense actually [16:59:16 CEST] <momomo> thanks dude! i spent like 4 hours on this yesterday [16:59:23 CEST] <momomo> you need to come in on sundays too :P [16:59:24 CEST] <momomo> haha [16:59:30 CEST] <momomo> -sn worked [17:00:20 CEST] <momomo> yesterday i also found these options : [17:00:50 CEST] <momomo> -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 2 -i but they are unrecogninzed ... [17:01:24 CEST] <momomo> i've noticed that sometimes a process can die ( if I pull the ethernet cable for like a minute ) but I would like it to resume when it can .. [17:01:37 CEST] <momomo> these options are noted under protocol ( http ) [17:01:54 CEST] <momomo> https://ffmpeg.org/ffmpeg-protocols.html [17:02:06 CEST] <momomo> but I seem to be using them wrong [17:02:23 CEST] <furq> i have those in a recent build [17:02:26 CEST] <furq> they're new in 3.x [17:03:56 CEST] <momomo> oh maybe I should try again .. i tried before i think ( couldnt get this verion to work ) [17:04:51 CEST] <momomo> yeah, they worked [17:14:54 CEST] <Carl_> Could anyone help me out please? I am streaming H264 video to media server. Everything works as expected but the video delay is the problem. After a few seconds the delay get bigger. I'm using these parameters for encoding http://pastebin.com/v0N78k3r [17:24:38 CEST] <xochilpili> how can i convert srt into vtt files? [17:25:15 CEST] <Elgu> I compiled ffmpeg on centos and when I try to use vp9 it gives me following message [17:25:17 CEST] <Elgu> [libvpx-vp9 @ 0x2684ae0] The encoder 'libvpx-vp9' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it. [17:25:35 CEST] <Elgu> is there a way to accept vp9 always? [17:25:42 CEST] <Elgu> without -strict -2 [17:28:22 CEST] <Carl_> How could i reduce packet size without losing much quality ? [17:28:42 CEST] <Elgu> Carl_: vp9 [17:29:54 CEST] <satinder___> hi , I am using drawtext filter with updated text file every time but I am getting following error [17:30:11 CEST] <satinder___> [Parsed_drawtext_0 @ 0x7f17ec005720] [FILE @ 0x7f17fc000180] Error occurred in mmap(): Invalid argument [17:30:11 CEST] <satinder___> [Parsed_drawtext_0 @ 0x7f17ec005720] The text file 'OverlayInfo' could not be read or is empty [17:30:11 CEST] <satinder___> Failed to inject frame into filter network: Invalid argument [17:30:11 CEST] <satinder___> [video4linux2,v4l2 @ 0x7f17ec000c20] Some buffers are still owned by the caller on close. [17:30:11 CEST] <satinder___> open: No such file or directory [17:30:28 CEST] Last message repeated 1 time(s). [17:30:28 CEST] <satinder___> [Parsed_drawtext_0 @ 0x7f17ec005720] [FILE @ 0x7f17fc000180] Error occurred in mmap(): Invalid argument [17:30:28 CEST] <satinder___> [Parsed_drawtext_0 @ 0x7f17ec005720] The text file 'OverlayInfo' could not be read or is empty [17:30:28 CEST] <satinder___> Failed to inject frame into filter network: Invalid argument [17:30:28 CEST] <satinder___> [video4linux2,v4l2 @ 0x7f17ec000c20] Some buffers are still owned by the caller on close. [17:30:28 CEST] <satinder___> open: No such file or directory [17:30:45 CEST] Last message repeated 1 time(s). [17:30:45 CEST] <satinder___> sorry for mistake [17:31:12 CEST] <satinder___> Some body give my suggestion about rename the file I did it [17:31:25 CEST] <Carl_> Elgu, is it good for video streaming? [17:31:35 CEST] <furq> Carl_: if you're streaming mpegts over tcp/udp then append ?pkt_size=1316 (or whatever) to the url [17:31:41 CEST] <Elgu> I don't know that, but it's good for videos [17:31:44 CEST] <satinder___> rename(temfile ,/home/Overlayfile ) [17:31:46 CEST] <furq> that's how you do it with the ffmpeg cli, idk if it works the same with the api [17:32:02 CEST] <furq> that should also have no effect on quality [17:32:03 CEST] <satinder___> but the error is same [17:32:21 CEST] <satinder___> for 2 mins that is working after that i am getting error [17:32:31 CEST] <Carl_> furq, i'm streaming over rtsp [17:34:02 CEST] <satinder___> please any one can help me ?? [17:34:32 CEST] <Carl_> the video quality is excellent, but the delay is horrible [17:34:39 CEST] <furq> oh [17:34:48 CEST] <furq> i doubt that has anything to do with packet size [17:35:02 CEST] <Elgu> no one any idea? [17:35:05 CEST] <Elgu> [libvpx-vp9 @ 0x2684ae0] The encoder 'libvpx-vp9' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it. [17:35:15 CEST] <furq> Elgu: what's wrong with adding -strict -2 [17:35:27 CEST] <Elgu> I use a python tool to encode videos [17:35:31 CEST] <Carl_> i thought reducing packets , sending them to server might reduce the delay [17:35:37 CEST] <Elgu> and on my pc it's working finde, but on my server it isn't [17:35:44 CEST] <Elgu> so I was wondering. [17:36:00 CEST] <furq> probably different ffmpeg versions [17:36:11 CEST] <furq> afaik libvpx-vp9 was only marked as experimental recently [17:36:36 CEST] <furq> -strict -2 should make no difference if you're not using any marked-as-experimental codecs [17:36:55 CEST] <Elgu> yeah could be [17:37:04 CEST] <Elgu> my pc is running the one from the arch reo [17:37:13 CEST] <Elgu> my server is using the latest I guess [17:37:15 CEST] <Elgu> I compiled it [17:37:57 CEST] <Carl_> Even reducing bitrate wont help me [17:38:32 CEST] <furq> Carl_: you could try whatever the api equivalent of -tune zerolatency is [17:38:41 CEST] <Elgu> Carl_: https://pypi.python.org/pypi/webm [17:38:49 CEST] <Elgu> try this out, it's awesome [17:39:20 CEST] <furq> that doesn't have anything to do with what he's asking [17:39:55 CEST] <Elgu> yeah but anyways [17:39:56 CEST] <Elgu> good tool [17:41:27 CEST] <Carl_> i'm using c++ for ffmpeg [17:42:02 CEST] <xochilpili> does anyone know how to convert subtitles in srt into vtt ? [17:42:46 CEST] <furq> xochilpili: -c:s webvtt [17:43:12 CEST] <Carl_> furq, -tune zerolatency is reducing unreadable quality lol [17:43:18 CEST] <xochilpili> furq, ffmpeg -i source.srt -c:s webvtt output.vtt? [17:43:34 CEST] <furq> xochilpili: if you're converting srt to vtt then you don't even need the -c:s webvtt [17:44:34 CEST] <xochilpili> i have done this : ffmpeg -i source.srt out.vtt and i got this > Unable to find a suitable output format for out.vtt [17:44:41 CEST] <furq> Carl_: increase the bitrate? [17:44:54 CEST] <furq> or the gop size, although that might cause more latency issues depending on your streaming setup [17:46:57 CEST] <satinder___> furq : what I can do for atomic writing of a textfile for drawtext filter , Currently I am using rename(oldpath , newpath) , but I getting still error after 2 mins of video playing [17:55:24 CEST] <satinder___> hi there are any one ?? [17:59:14 CEST] <Carl_> the delay is like 20sec and getting worse by the time [18:03:14 CEST] <Guest78901> Hey! [18:03:46 CEST] <Guest78901> I'm having trouble running frei0r filters with ffmpeg, would appreciate any help... [18:03:59 CEST] <Guest78901> I posted an SO q with all the details here http://stackoverflow.com/questions/36398469/running-frei0r-filters-with-ffm… [18:04:25 CEST] <Guest78901> but basically, I installed frei0r with homebrew [18:04:40 CEST] <Guest78901> and I can't figure out how to tell ffmpeg where the filters are [18:14:30 CEST] <entdark> hello, guys [18:14:51 CEST] <entdark> I have a problem writing default mp4 files [18:15:37 CEST] <entdark> the problem is when the file reaches 2 GB size, it stops encoding [18:15:59 CEST] <entdark> the command is "ffmpeg -f avi -i - -threads 0 -preset ultrafast -y -pix_fmt yuv444p -crf 23 %o.mp4 2> ffmpeglog.txt" [18:16:05 CEST] <kepstin> what os, filesystem? [18:16:20 CEST] <entdark> windows 7 x64, ntfs [18:16:33 CEST] <entdark> writing into ffmpeg stdin [18:16:49 CEST] <entdark> Stream #0:0: Video: rawvideo, bgr24, 1280x720, 60 fps, 60 tbr, 60 tbn, 60 tbc [18:16:49 CEST] <entdark> Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, 2 channels, s16, 1411 kb/s [18:22:45 CEST] <entdark> it also happens on mac [18:23:00 CEST] <entdark> unable to check its filesystem now [18:32:37 CEST] <entdark> alright, it stops at 1.56 GB [18:39:10 CEST] <entdark> also, I just found out it's not file size limit issue, because with "-crf 0", I am currently getting the file over 2 GB [18:39:25 CEST] <furq> at a guess, your input file is broken [18:40:17 CEST] <entdark> well it is raw bgr24 data and raw pcm data [18:40:24 CEST] <entdark> as I showed above [19:55:55 CEST] <Filarius> hello, I need help in fixing video. Problem is what all PC players have various issue related to A/V sync, even after editors live Sony Vegas or Adobe Premier but looks okay in webplayers http://pastebin.com/jtYnTB58 https://www.dropbox.com/s/yrvlvy2nry1izwk/record.flv [19:56:22 CEST] <Filarius> video made by recording HLS stream [20:03:56 CEST] <furq> Filarius: does the source video play correctly [20:06:21 CEST] <Carl_> I can connect to both media servers. To localhost:1935 and also to my friends computer. But if i'm connecting to my friends computer then the data aren't going through. Server says that somekind of connection is available. [20:06:33 CEST] <Carl_> If i'm connecting to localhost, then everythings works fine [20:06:41 CEST] <Carl_> server i'm using is wowza media server [20:06:48 CEST] <Carl_> i thought mby someone here can help me [20:06:56 CEST] <furq> paste the non-working command [20:07:08 CEST] <Carl_> unfortunately ther aren't non-working command [20:07:14 CEST] <Carl_> just data doesn't go through [20:07:24 CEST] <Carl_> maybe somekind of firewall which is blocking ? [20:07:28 CEST] <Carl_> i'm out of ideas [20:15:14 CEST] <c_14> What's the command? [20:20:14 CEST] <entdark> so any idea on my issue? [20:37:20 CEST] <momomo> what would be the reason -preset ultrafast lags a hls generated stream? cpu is around 2% [20:39:51 CEST] <furq> lags? [20:46:50 CEST] <entdark> alright, resolved the problem: it was in my code, so nvm [20:55:45 CEST] <momomo> furq, yes, more frequent hickups near each ts segment ends in the player [20:58:07 CEST] <momomo> -preset ultrafast goes down to 1-2 % for a stream .. while without I am hitting 6% - 15% .. which is unstainable .. I could not run more than 5-10 streams per server like that [20:58:57 CEST] <momomo> question is what makes ultrafast or even veryfast lag [20:59:03 CEST] <momomo> since cpu usage is lower [20:59:09 CEST] <furq> does it happen with other presets [20:59:18 CEST] <momomo> from doc: Try -preset veryfast if you are unsure of what to choose, then watch the console output or the video to see if the encoder is keeping up with your desired output frame rate: if it is not then use a faster preset and/or reduce your -video_size. [20:59:40 CEST] <momomo> https://trac.ffmpeg.org/wiki/EncodingForStreamingSites [20:59:49 CEST] <furq> the wiki isn't really documentation [20:59:55 CEST] <furq> a lot of it is outdated or anecdotal [21:00:10 CEST] <furq> especially the streaming stuff which is about one step removed from folklore [21:00:52 CEST] <momomo> yes, but maybe still relevant .. what do they mean .. watch the console if computer is keeping up .. the cpu usage is lower, it should be able to .. right? [21:01:04 CEST] <furq> i assume it just means cpu usage [21:01:13 CEST] <furq> or the framerate, rather [21:01:56 CEST] <furq> like i said, check if it happens with other presets [21:03:39 CEST] <momomo> i lowered the framerate to 10 but it still occurs ... [21:03:48 CEST] <momomo> tried veryfast .. also [21:03:54 CEST] <momomo> trying fast now [21:04:06 CEST] <pa> do you guys have idea why hevc is getting spread, while vp9 is not? [21:04:18 CEST] <pa> i read that performance-wise vp9 is the same is not better [21:04:20 CEST] <furq> spread across cores? [21:04:23 CEST] <pa> if [21:04:30 CEST] <momomo> furq, maybe ultrafast requires a faster processor than about cpu usage [21:04:31 CEST] <furq> i've never been able to make libvpx's multithreading work properly [21:04:37 CEST] <momomo> althouhg mine is quite fast [21:04:43 CEST] <momomo> but a laptop [21:04:48 CEST] <TD-Linux> pa, what do you mean VP9 is not being spread? [21:04:52 CEST] <momomo> i7 768m [21:05:01 CEST] <pa> TD-Linux, i mean is not being used [21:05:01 CEST] <furq> i don't see how the preset would cause this, especially if it still happens with veryfast [21:05:09 CEST] <furq> i'd be more inclined to believe some other setting is causing it [21:05:09 CEST] <TD-Linux> pa, but it is, Youtube and Steam use it [21:05:20 CEST] <pa> i see a lot of videos appearing in x265 or hevc [21:05:21 CEST] <furq> i noticed earlier that your command was missing -g and -keyint_min [21:05:22 CEST] <TD-Linux> HEVC is practically nonexistent for internet streaming [21:05:27 CEST] <pa> but nothing is vp9 [21:05:37 CEST] <furq> which could explain it [21:05:50 CEST] <furq> pa: all youtube videos from the past year or so are vp9 [21:06:00 CEST] <furq> vp9 is supported in most browsers, h265 isn't [21:06:20 CEST] <pa> well but then why people don't use it, only google? [21:06:28 CEST] <pa> no good free encoder? [21:06:31 CEST] <pa> or easy to use? [21:06:32 CEST] <furq> well it's google's codec so obviously they use it [21:06:41 CEST] <kepstin> google uses the same encoder as everyone else (libvpx) [21:06:46 CEST] <TD-Linux> pa, they do use it, your premise is wrong :) [21:07:00 CEST] <kepstin> (google wrote the encoder) [21:07:01 CEST] <furq> but it's not supported everywhere and will never be supported on iOS, which means every big video streaming service needs an mpeg-la licence for h.264 anyway [21:07:05 CEST] <iive> i think he ask, why pirates don't use vp9 [21:07:22 CEST] <furq> so vp9 only makes sense if they're more bandwidth-constrained than cpu-constrained [21:07:25 CEST] <furq> which i guess nobody is [21:07:54 CEST] <furq> and pirates don't use vp9 because h.265 is probably a better codec [21:08:03 CEST] <kepstin> why pirates don't use it? It's really slow to encode (multithreading issues too), and if you're pirating video you obviously don't care about licensing your encoder anyways :) [21:08:04 CEST] <furq> and they don't care about the licensing fees [21:08:31 CEST] <TD-Linux> x265 is not exactly speedy either [21:08:32 CEST] <momomo> furq, yes, i removed those .. as I am experimenting ... and didn't see that they were neccesaary ... i've tried adding those too though .. i was thinking that -g and -keymin might increase cpu usage since they might possibly have to conform to more ruls [21:08:39 CEST] <furq> x265 is a lot faster than vp9 in my experience [21:08:44 CEST] <furq> libvpx-vp9 that is [21:09:03 CEST] <furq> momomo: afaik you will run into problems with hls if your gops aren't fixed size [21:09:07 CEST] <TD-Linux> furq, at what speed setting? [21:09:26 CEST] <furq> the defaults iirc [21:09:29 CEST] <TD-Linux> x265 can operate a lot faster than vp9 but you start losing significant quality at presets faster than veryslow [21:09:58 CEST] <furq> i heard from unreliable internet sources that x265 medium is roughly equivalent to x264 veryslow [21:10:00 CEST] <momomo> furq, using -x264-params scenecut=0 results in 10s segments [21:10:05 CEST] <momomo> so not sure what g does [21:10:11 CEST] <momomo> i've trying to figure that out [21:10:19 CEST] <furq> -g is the maximum gop size [21:10:26 CEST] <momomo> what is gop ? [21:10:29 CEST] <furq> group of pictures [21:10:48 CEST] <kepstin> approximately equivalent to keyframe interval, basically [21:10:58 CEST] <kepstin> and every hls segment has to start with a keyframe [21:10:59 CEST] <TD-Linux> furq, yeah that sounds about right [21:11:13 CEST] <momomo> i am guessing -x264-params scenecut=0 applies something like that though ? [21:11:15 CEST] <furq> momomo: the default for -g is 250, so 25fps video will give you 10-second gops if scenecut is off [21:11:35 CEST] <iive> scenecut probably disables the scene change detection [21:11:37 CEST] <furq> if your hls segment size isn't the same as the gop length then you're going to have a bad time [21:11:47 CEST] <iive> that could insert additional keyframes at scene change [21:11:50 CEST] <furq> segments have to start on an idr frame [21:12:49 CEST] <kepstin> I think the way the HLS muxer in ffmpeg works, if there isn't an IDR frame in the right spot, it'll keep outputting to the current segment until it hits an IDR frame, then it switches [21:13:00 CEST] <kepstin> so you'll get segments with really variable size and length [21:13:20 CEST] <furq> well not if scenecut is off [21:13:56 CEST] <pa> i havent seen many vp9 vids, but the hevc ones i found online aren't exactly high quality [21:14:08 CEST] <furq> pa: most people who encode x265 don't know how to use it [21:14:24 CEST] <furq> they read "50% smaller than x264!!" and encode at a really low bitrate at medium [21:14:27 CEST] <TD-Linux> pa, keep in mind "quality" is a function of how many bits they put in [21:14:31 CEST] <kepstin> well, if you're doing 30fps video, -g is 250, and you want 10 second segments - the end result is you're gonna get 16.6 second segments instead :/ [21:14:34 CEST] <momomo> i've haven't really exprienced any major issues with using just scenecut until i added preset ultrafast [21:14:50 CEST] <furq> even though medium is barely more efficient than x264 [21:14:51 CEST] <momomo> i will try now agian with the other options .. although I already have [21:15:42 CEST] <momomo> yes, same issues [21:15:52 CEST] <furq> paste the full command [21:16:01 CEST] <furq> also did you say it was still happening with preset fast [21:17:01 CEST] <momomo> furq, http://hastebin.com/paladuvaju.md [21:17:07 CEST] <momomo> furq, no, i think fast was good [21:17:53 CEST] <furq> weird [21:18:31 CEST] <momomo> but i can't really get my head around it .. ultrafast is supposed to lead to lower cpu usage [21:18:48 CEST] <momomo> so it has to be about cpu speed ultimately [21:19:16 CEST] <momomo> or a bug [21:19:43 CEST] <momomo> but the commend in the old doc seems to suggest that something can make this lag [21:19:53 CEST] <momomo> but it is not clear what [21:20:10 CEST] <kepstin> momomo: I'm still not clear on exactly what you're seeing as "lag" [21:20:37 CEST] <momomo> kepstin, at the end of each segment .. the player will request a new segment .. with no preset or preset fast i am getting those in time [21:20:48 CEST] <momomo> with ultrafast it appears as if they don't get created in time [21:21:06 CEST] <kepstin> momomo: so the new segment is in the playlist, but isn't on disk? [21:21:13 CEST] <furq> oh weird [21:21:33 CEST] <furq> i take it you're testing on localhost or lan so it's not a network issue [21:21:38 CEST] <kepstin> ... the segments shouldn't be added to the playlist until they're completely written, iirc [21:21:42 CEST] <kepstin> so that doesn't make sense [21:21:53 CEST] <momomo> kepstin, not neccesary .. the playlist might still be outdated .. but the player will ask for a playlist again .. it's a bout 0.1 seconds lag [21:22:07 CEST] <momomo> "outdated" -> not ready [21:22:32 CEST] <momomo> it appears as if the segments are not done as quickly as with other presets [21:22:32 CEST] <furq> yeah if the player hits the end of the playlist it'll start buffering iirc [21:22:35 CEST] <furq> rather than stopping [21:22:52 CEST] <momomo> yes, and ask for the playlist again until there is a new file [21:23:07 CEST] <momomo> i can double check [21:23:22 CEST] <furq> try it with a bunch of different presets [21:23:42 CEST] <furq> i can't imagine why the preset would cause that, especially not if it's faster presets which don't work [21:23:49 CEST] <kepstin> in the command you pasted, you're using -g 125 and -r 25, and want 10s segments [21:23:53 CEST] <kepstin> that's not gonna work... [21:24:03 CEST] <furq> 10 seconds is 125*2 [21:24:07 CEST] <furq> that should work fine [21:24:14 CEST] <kepstin> oh, wait, i just can't math [21:24:23 CEST] <kepstin> for some reason, 125/25=3 in my head ;) [21:25:24 CEST] <momomo> i just noticed #EXTINF:10.021333, [21:25:30 CEST] <momomo> in some playlist files [21:25:39 CEST] <momomo> #EXTINF:10.000000, in others [21:26:00 CEST] <momomo> ultrafast maybe does not confirm strictly to the segment length [21:26:10 CEST] <furq> that's less than one frame [21:27:25 CEST] <momomo> yes, not much [21:28:38 CEST] <kepstin> you don't have '-re' on your command-line, right? [21:28:49 CEST] <momomo> i tried it .. but that didn't help [21:28:59 CEST] <furq> i'd have thought you'd need it for http streaming [21:28:59 CEST] <kepstin> well, that should make it worse :) [21:29:01 CEST] <momomo> kepstin, it's an input option right? [21:29:21 CEST] <furq> yeah [21:29:24 CEST] <kepstin> if it's a live input, you do *not* want -re [21:29:31 CEST] <momomo> furq, the documentation is really confusing on that one [21:29:41 CEST] <furq> it's normally used for streaming from files [21:29:41 CEST] <kepstin> if it's a pre-recorded input that streams at faster than realtime, you want -re to slow it down [21:30:13 CEST] <momomo> "Should not be used with actual grab devices or live input streams (where it can cause packet loss)." ... It is useful for real-time output (e.g. live streaming). [21:30:37 CEST] <momomo> i guess i have a live input stream .. but also a live output stream [21:30:48 CEST] <kepstin> if you have a live input stream, you do not want -re. [21:30:56 CEST] <momomo> ok [21:30:59 CEST] <furq> if it works at all without -re then don't use it [21:31:00 CEST] <kepstin> without -re, it'll encode as fast as it can read frames from the input [21:31:11 CEST] <furq> it'll be very apparent whether or not you should use it [21:31:21 CEST] <kepstin> which, at that preset, means that it'll be waiting on the input to provide more frames [21:31:27 CEST] <momomo> i think i will just set a larger timeout after the playlist is ready [21:31:29 CEST] <kepstin> what type of stream is the input, exactly? [21:31:37 CEST] <momomo> it seems to be more ok later on. [21:31:45 CEST] <momomo> after a couple of lags [21:31:56 CEST] <kepstin> yeah, once the player has buffered a couple of segments behind, it'll be fine [21:31:56 CEST] <furq> you could try a larger segment size [21:32:06 CEST] <furq> that'll increase latency but it should reduce buffering [21:32:12 CEST] <kepstin> momomo: what type of stream is the input? [21:32:18 CEST] <momomo> tvheadend [21:32:26 CEST] <kepstin> no, what protocol? [21:32:29 CEST] <momomo> http [21:32:32 CEST] <kepstin> what video container? [21:32:41 CEST] <kepstin> is it hls? mpeg-ts? [21:32:57 CEST] <fritsch> most likely broken - if it comes from tvhs demuxer ... [21:33:11 CEST] <kepstin> how about you just paste your ffmpeg output? [21:33:19 CEST] <momomo> mpeg2video [21:35:10 CEST] <momomo> furq, the problem is that most often on a live stream you will always be close to the end ... the only way is to wait x seconds after playlist is ready to start 3 seconds after or something [21:37:21 CEST] <kepstin> momomo: usually, the player is expected to prebuffer some amount of video before it starts playing, which will put enough delay in that the next segment will be ready in time. [21:37:49 CEST] <furq> you can configure the buffer length with hls.js [21:38:36 CEST] <momomo> kepstin, the player will ask for the manifest file first .. and soon as it gets it starts playing [21:38:40 CEST] <momomo> at least hls.js does [21:39:02 CEST] <momomo> i have a timeout functionality on the server [21:39:04 CEST] <momomo> side [21:40:31 CEST] <momomo> furq, i have played with those and using: http://hastebin.com/ilogocopah.cpp [21:40:46 CEST] <momomo> timeout is 60000 [21:42:33 CEST] <momomo> i think a larger server timeout after playlist is working fine now .. although it might catch up eventually .. [21:42:40 CEST] <momomo> but I think it's fine [21:43:30 CEST] <momomo> i have also turned of crf so maybe the stream can be copied faster without any processing [21:43:43 CEST] <momomo> or the cpu usage doesn't jump up [21:44:04 CEST] <momomo> 1-2 % now [21:44:12 CEST] <momomo> which is pretty much the same as crf 23 [21:45:26 CEST] <kepstin> momomo: the default is to do a crf encode at something around 22-24ish (i forget the exact default) [21:45:40 CEST] <furq> 23 [21:45:48 CEST] <furq> if you don't specify -b:v then it'll be running at crf 23 [21:45:54 CEST] <furq> or -q:v [21:46:52 CEST] <kepstin> that said, crf encode is an odd choice for a live stream, since the bitrate's gonna be very unpredictable. I suppose it's ok for a lan, tho, where you know you have 100mbit+ available. [21:47:54 CEST] <furq> i'd assume it's fine if you have maxrate set [21:48:21 CEST] <furq> emphasis on assume because the vbv is an enigma wrapped in a riddle wrapped in several contradictory wiki articles and forum posts [21:49:18 CEST] <TD-Linux> the only way to know for sure is to read the code [21:49:28 CEST] <momomo> fuck .. i have increaed it from 2000 to 5000 and it still occurs .. maybe it's something in hls.js [21:50:19 CEST] <furq> TD-Linux: if i read the code am i then bound by the covenant of blood to never explain it to anyone clearly [21:50:30 CEST] <furq> or will that just come naturally [21:50:54 CEST] <TD-Linux> no, likely you will get angry, attempt to rewrite it, give up halfway through and retire to a small cottage in the woods [21:52:32 CEST] <momomo> let me try with 10s timeout after playlist is generated .. although that is too much since next segment will overwrite it [21:54:43 CEST] <momomo> still happened .. lowering to 7500 [21:56:08 CEST] <momomo> still happening [21:56:18 CEST] <momomo> this is wierd [21:56:21 CEST] <momomo> have to try in vlc [21:57:21 CEST] <momomo> happens in vlc too .. it seems the cutting might make a few frames disappear at times [21:57:30 CEST] <TD-Linux> fyi I don't think maxrate works with crf looking at the code [21:57:32 CEST] <momomo> it goes blank and audio disappears [21:58:27 CEST] <momomo> i am talking about a timeout [21:58:40 CEST] <momomo> but it appears as if it is something else [21:59:16 CEST] <momomo> i am going to try increassing list_size and remove hls_delete_segments [21:59:20 CEST] <momomo> and try to play it afterwards [22:03:14 CEST] <momomo> is there a way to get hls.js to ask for the next file much earlier or more aggressively ? [22:04:03 CEST] <momomo> maxBufferLength [22:04:18 CEST] <momomo> but mine is already 60 [22:04:49 CEST] <furq> maybe manifestLoadingRetryDelay [22:05:03 CEST] <furq> that defaults to 1s though [22:07:43 CEST] <momomo> i am exploring wether the transfer of files due to possibly being bigger because of preset ultrafast is causing hte lag .. the file is not served quickly enough from when it is asked for .. even though the initial timeout is large ... the asking for ts files is happening to late [22:10:10 CEST] <furq> i can't imagine that would cause a noticeable difference on a lan [22:11:26 CEST] <momomo> i need to continue with this tomorrow [22:13:39 CEST] <momomo> it's a strange problem though .. but vlc seems fine .. so it's possibly a hls.js issue but i can't understand what would be the difference between the presets for it [22:14:24 CEST] <momomo> i will play with some options tomorrow, thanks for your help today :) [22:19:24 CEST] <momomo> what is up with targetduration? http://hastebin.com/oducomemid.vala [22:19:28 CEST] <momomo> 11 [22:20:42 CEST] <momomo> for no preset i get #EXTM3U [22:20:42 CEST] <momomo> #EXT-X-VERSION:3 [22:20:42 CEST] <momomo> #EXT-X-TARGETDURATION:10 [22:20:42 CEST] <momomo> #EXT-X-MEDIA-SEQUENCE:0 [22:20:42 CEST] <momomo> #EXTINF:10.000000, [22:20:43 CEST] <momomo> a0.ts [22:20:46 CEST] <momomo> 10 [22:25:57 CEST] <momomo> sometimes i get 10 .. sometimes i get 11 [22:26:10 CEST] <momomo> but when I get 10 nothing happens [22:26:16 CEST] <momomo> so this might be the issue [22:26:39 CEST] <momomo> if segment length is 10 and it targets 11 for reload then obviously its going to lag [22:36:50 CEST] <momomo> i programmatically alter this now on the fly and it appears to be working .. replacing 11 with 10 [22:36:55 CEST] <momomo> no lag [22:37:01 CEST] <momomo> it appears as if its a bug in ffmpeg [22:37:05 CEST] <momomo> output of playlist file [22:37:46 CEST] <momomo> i'd prefer if I didn't have to read the text and replace it .. althouhg it works, it is potentially slower than my otherwise super optimized code :P [22:38:06 CEST] <momomo> the targetduration must be the same as hls_time [22:39:06 CEST] <momomo> yes, lag gone [22:39:38 CEST] <momomo> i will post a bug report tomorrow [23:13:06 CEST] <momomo> by manipulating ext_targetduration and even putting it at 1 i can force hls.js to load playlists every second [23:13:19 CEST] <momomo> there should be such an option to manipulate this using ffmpeg [23:14:47 CEST] <kepstin> I guess it must be automatically generating the targetduration by rounding up the length of the first segment. I think passing through the value of the -hls_time parameter untouched might be better. [23:15:15 CEST] <kepstin> since it's the *target* duration not the arbitrarily guessed from first segment duration :) [23:22:50 CEST] <kepstin> hmm, nope, the behaviour is correct: https://tools.ietf.org/html/draft-pantos-http-live-streaming-18#section-4.3… [23:23:16 CEST] <kepstin> hmm. close to being correct [23:23:41 CEST] <kepstin> the lengths should be rounded to the nearest integer, not done with a ceiling function [23:23:57 CEST] <kepstin> so in this case, it should be 10 not 11. [23:24:08 CEST] <kepstin> but 11 is still acceptable. [23:37:55 CEST] <kepstin> momomo: if you feel like building your own ffmpeg, you could give https://www.kepstin.ca/dump/0001-hlsenc-Round-segment-lengths-when-calculat… a try [23:38:07 CEST] <kepstin> I think that'll make it slightly more spec compliant [23:39:27 CEST] Action: kepstin should doublecheck that he has the right ffmpeg rev checked out there, that From date in 2001 is a bit odd. [23:40:23 CEST] <kepstin> huh, dunno what's up with that. patch is fine [00:00:00 CEST] --- Tue Apr 5 2016

1 0

ffmpeg-devel.log.20160403
by burek 04 Apr '16

04 Apr '16

[00:08:11 CEST] <Daemon404> michaelni, i am going to change the codec par repo to have an issue tracker [00:08:17 CEST] <Daemon404> can you file any new stuff there [00:10:04 CEST] <michaelni> Daemon404, i can do "anything" that helps you :) [00:10:23 CEST] <michaelni> well not anything ;) but alot [00:10:44 CEST] <Daemon404> i moved the 3 from today to new issues there: https://github.com/dwbuiten/FFmpeg/issues [00:11:05 CEST] <Daemon404> wm4, ubitux, nevcairiel, jamrial ^ [00:13:15 CEST] <Daemon404> hmm michaelni, i tested an unpatched version of ffmpeg that is at teh same revision as when i started the codedpar merge [00:13:18 CEST] <Daemon404> and Starship_Troopers.vob just segfaults it [00:13:22 CEST] <Daemon404> was there some recent fix [00:18:39 CEST] <michaelni> hmm, thats odd, ive used that file alot for testing, i dont remember a segfault [00:19:58 CEST] <jamrial> the opus regression is because it detects stereo instead of 7.1 [00:21:12 CEST] <nevcairiel> its probably another case of detecting stream first, filling in data later [00:21:15 CEST] <nevcairiel> mpegts is annoying like that [00:22:50 CEST] <michaelni> Daemon404, how can i make Starship_Troopers.vob segfault ? [00:30:39 CEST] <michaelni> Daemon404, good news, i just tested some basic rtp stuff and its still working, ill try to test more cases [00:32:58 CEST] <Daemon404> nevcairiel, im going to need help on teh flv one [00:33:06 CEST] <Daemon404> i didnt touch any of the flv code thus far [00:33:41 CEST] <Daemon404> michaelni, nevermind, the segfaulty was my fault [00:35:32 CEST] <Daemon404> wm4, or was it you who knows the flc stuff [00:40:33 CEST] <wm4> nevcairiel seems to know most about it, but I can try to look at it tomorrow [00:44:03 CEST] <Daemon404> ok i figured out the opus in ts sample [00:45:42 CEST] <michaelni> rtmp seems also to still work, i have seen one parser codec id assertion in rtp, i think ill wait till issue #3 is fixed before creating a potential dulpciate [00:46:25 CEST] <Daemon404> michaelni, i am about to push a fix for #3 [00:46:29 CEST] <Daemon404> is it opus in ts too? [00:47:13 CEST] <nevcairiel> what was wrong with opus? I would figure its mpegts filling in data late, but maybe its somethiung else? [00:47:58 CEST] <michaelni> iam not sure if iam mixing issues up but think i saw a missing extradata in one of the issues [00:48:17 CEST] <Daemon404> nah [00:48:19 CEST] <Daemon404> i pushed a fix [00:48:25 CEST] <Daemon404> it was setting the opus extradata in read_packet [00:48:28 CEST] <Daemon404> a mpegts.c does. [00:48:36 CEST] <nevcairiel> so, like i said [00:48:44 CEST] <nevcairiel> this piece of code is getting uglier by the minute [00:48:52 CEST] <Daemon404> sure is [00:48:55 CEST] <nevcairiel> imho, not acceptable [00:49:02 CEST] <nevcairiel> should find a proper solution or dont do it [00:49:03 CEST] <Daemon404> i dont see you suggesting anything [00:49:42 CEST] <Daemon404> nor definign what proper is [00:50:10 CEST] <nevcairiel> proper would be something that doesnt need random field additions for every other bug we find =p [00:51:11 CEST] <nevcairiel> i assume opus is broken in libav? [00:51:21 CEST] <Daemon404> i dont see how to avoid that other than modifying mpegts.c to also set internal avctx in addition to codecpar [00:51:24 CEST] <Daemon404> which is not much better [00:51:35 CEST] <Daemon404> and then hope no otehr format needs it [00:51:46 CEST] <nevcairiel> hence, design failure, and needs an addition to the design to somehow do this [00:52:04 CEST] <Daemon404> all youve said is: it's broken, i have no better ideas [00:52:12 CEST] <Daemon404> solution is to what? hold of mege indefinitely? [00:52:16 CEST] <Daemon404> off* [00:53:18 CEST] <jamrial_> nevcairiel: sure is [00:53:22 CEST] <jamrial_> detected as stereo [00:53:27 CEST] <jamrial_> by avconv [00:53:34 CEST] <nevcairiel> supposedly this merge cleans up code, well thats going down the drain fast, so if we can't fix that, might as well wait until we can, because for every problem we find there is 4 we didnt find [00:54:15 CEST] <Daemon404> then why the fuck did i dump a shitload of hours int ogetting this done sooner rather than later [00:54:18 CEST] <nevcairiel> one solution would be to add a field to allow a demuxer to say find_stream_info "i updated something, go re-start your probing and re-sync iinternal avctx" [00:54:29 CEST] <nevcairiel> Daemon404: i told you that rushing this would not be a good idea [00:54:30 CEST] <Daemon404> other than to make sure i dont have a metric fuckshit-ton of merges in backlog [00:54:33 CEST] <Daemon404> (which noone will help with) [00:55:35 CEST] <Daemon404> yes you said it wont be done fast, and proceeded to not make any progress at all for 2 weeks [00:55:43 CEST] <Daemon404> so i stepped up to handle it [00:56:30 CEST] <Daemon404> because i dont feel liek having 500 commit backlogs to merge [00:59:31 CEST] <Daemon404> so if we're gonna hold off inddefinitely whiel buildign a hige backlog of merges noone will help me with, i am simpyl going to absolve myself and step down from helping with merges [00:59:47 CEST] <jamrial_> does reporting bugs to libav usually get somewhere? [00:59:56 CEST] <Daemon404> jamrial_, give it a few years [01:00:00 CEST] <jamrial_> this is a general design problem from codecpar after all [01:00:03 CEST] <jamrial_> ah well [01:02:18 CEST] Action: michaelni is too dumb to use github [01:02:24 CEST] <nevcairiel> could try to talk to elenril directly, maybe he cares [01:04:47 CEST] <jamrial_> that'd be great [01:08:10 CEST] <jamrial_> oh, lol [01:08:30 CEST] <jamrial_> the sample is broken with avconv even before codecpar was implemented [01:09:16 CEST] <wm4> jamrial_: of course [01:09:20 CEST] <jamrial_> no wonder they didn't take this into consideration while designing codecpar :p [01:09:34 CEST] <nevcairiel> well they still have the code to set the extradata [01:09:38 CEST] <kierank> jamrial_: is this my fault perhaps? [01:09:42 CEST] <wm4> many ffmpeg specific things are shitty hacks that make "something" work [01:09:45 CEST] <kierank> since it's opus in ts [01:09:48 CEST] <wm4> it's a common pattern [01:10:02 CEST] <jamrial_> kierank: it's working in ffmpeg pre codecpar, so no idea [01:10:18 CEST] <jamrial_> unless it was broken when you first wrote it then someone fixed it [01:10:20 CEST] <wm4> (and also things which don't enter elenril's consideration, so no concept for them) [01:10:41 CEST] <Daemon404> so what's the concensus [01:10:48 CEST] <Daemon404> should be hold off and rethinkign design or what [01:11:08 CEST] <jamrial_> does this only happen with mpegts? [01:11:16 CEST] <wm4> many things are "late" updates to codec params, right [01:11:24 CEST] <nevcairiel> for now, possible other formats as well [01:11:44 CEST] <wm4> so, why not provide an internal function to update it "late" [01:11:47 CEST] <kierank> it should in principle happen with ogg and opus as well [01:12:03 CEST] <wm4> (this would also confine such late changes) [01:16:36 CEST] <nevcairiel> i posted a sort of suggestion into https://github.com/dwbuiten/FFmpeg/commit/d40f238e79a8eb5515c6de8c14eb10612… [01:18:04 CEST] <Daemon404> nevcairiel, i did try callign avcodec_parameters_tocontext and it blew up some tests [01:18:34 CEST] <Daemon404> namely latm [01:19:17 CEST] <Daemon404> it might be due to the way i called it. [01:19:23 CEST] <nevcairiel> well like I said, it should not be called all the time because that causes issues and overwrites data, but only when the demuxer specifically says it updated something, and then also doing it "right" by closing the probing decoder first [01:19:38 CEST] <Daemon404> well ok [01:19:46 CEST] <Daemon404> what demuxers can do this besides mpegts [01:19:58 CEST] <Daemon404> and xmv if i revert that change [01:20:02 CEST] <nevcairiel> not sure, but shouldnt be *that* many that have the noheader flag to read [01:20:19 CEST] <Daemon404> that is assuming it had it set properly at all [01:20:21 CEST] <Daemon404> look at wavdec [01:20:49 CEST] <nevcairiel> well ok we can fix those as we find them then, but we have a somewhat clean approach for formats that mandate this kind of behavior [01:21:14 CEST] <Daemon404> i dont think it is too much effort to implement and i am willing to do this tomorrow [01:21:23 CEST] <Daemon404> but i would really, really liek some help with the otehr unrelated bus [01:21:26 CEST] <Daemon404> bugs* [01:21:36 CEST] <Daemon404> there's one flv one and one vob one [01:21:41 CEST] <michaelni> ill fix issue4 i _think_ its a bug in the mjpeg decoder [01:21:52 CEST] <Daemon404> michaelni, ok [01:22:48 CEST] <Daemon404> i dont know wtf is up with the vob or flv bugs [01:23:22 CEST] <Daemon404> (nor am i keen on digging in for 4 hours again in unfamiliar code) [01:25:20 CEST] <Daemon404> all i know is that flv *unsets* NOHEADER for some reason, at some point, so the codec id is never updated [01:25:27 CEST] <Daemon404> but if i remove that code i get a ton of h264 errors [01:25:32 CEST] <Daemon404> thats as far as i got [01:26:03 CEST] <michaelni> it unsets noheader to stop find_stream_info aka (i got all data you dont need to search for more streams) IIRC [01:26:11 CEST] <nevcairiel> it unsets noheader when its done finding its streams [01:26:17 CEST] <nevcairiel> what michaelni s aid [01:26:21 CEST] <Daemon404> i see [01:26:22 CEST] <Daemon404> ok [01:26:46 CEST] <nevcairiel> parsers are entirely screwed up in this api model right now [01:27:28 CEST] <Daemon404> other than closing/only setting once, the proposed new model is not hugely differenty [01:28:53 CEST] <Daemon404> anyway, by the time it gits the check for NOEHADER< it is unset [01:28:56 CEST] <Daemon404> and nothing gets copied [01:29:33 CEST] <nevcairiel> well if you add the new proposed change for late changes, flv can set that flag and the code would update it [01:29:48 CEST] <nevcairiel> wouldnt it [01:30:08 CEST] <nevcairiel> I can also write that tomorrow, but right now its like 1:30am [01:30:44 CEST] <Daemon404> well yea [01:31:06 CEST] <michaelni> will push a fix to master for issue 4 soon (after testing) [01:31:43 CEST] <Daemon404> michaelni, ok [01:32:07 CEST] <Daemon404> nevcairiel, if you write it tomorrow, i will triage/fix any remaining bugs [01:32:12 CEST] <Daemon404> but not both [01:32:45 CEST] <Daemon404> im currently in GMT-5, so ill let you write it [01:32:48 CEST] <Daemon404> as i will be asleep. [01:38:00 CEST] <Daemon404> sorry... GMT-4. DST. [01:45:22 CEST] <Daemon404> nevcairiel, i hacked togetehr a crappy version of your idea [01:45:24 CEST] <Daemon404> and it fixed flv [01:45:43 CEST] <Daemon404> but its not usable (it was a global constant) [01:45:54 CEST] <Daemon404> so the one in #3 i mean. [01:46:03 CEST] <Daemon404> so please do implement it tomorrow. [01:46:28 CEST] <Daemon404> need to go out now, sleep well. [01:46:40 CEST] <nevcairiel> about to head in as well [01:47:08 CEST] <Daemon404> talk tomorrow [01:47:19 CEST] <Daemon404> g'night [01:53:06 CEST] <Daemon404> right. too much codecpar lately. beer time. [01:53:10 CEST] Action: Daemon404 & [01:55:53 CEST] <cone-393> ffmpeg 03Marios Titas 07master:c1f9734f977f: avfilter/src_movie: fix how we check for overflows with seek_point [01:55:54 CEST] <cone-393> ffmpeg 03Michael Niedermayer 07master:de0bcea664c8: avcodec/mjpegdec: Do not permute quantization tables [03:51:36 CEST] <cone-393> ffmpeg 03Derek Buitenhuis 07master:fcbdc44f4e0c: wavdec: Only set the codec ID in read_header [03:51:37 CEST] <cone-393> ffmpeg 03Michael Niedermayer 07master:cf4d050b7231: avformat/wavdec: Remove direct s->pb->buffer access [04:19:40 CEST] <cone-393> ffmpeg 03Martin Vignali 07master:4f682318fb80: fate/exr : add test for b44/b44a compression [05:37:42 CEST] <Daemon404> for some reason i thought michaelni started actually sleeping... i must have been mistaken [10:29:02 CEST] <nevcairiel> Daemon404: pushed the change, passes fate with assert-level=2 (sans the vp6a things that lack the sample still) [11:15:54 CEST] <durandal_1707> Compn: do you have samples with fourcc TR20? [12:14:51 CEST] <michaelni> nevcairiel, "avformat: allow demuxers to signal late stream changes" causes: https://github.com/dwbuiten/FFmpeg/issues/11 [12:41:45 CEST] <nevcairiel> michaelni: fixed [13:08:46 CEST] <michaelni> nevcairiel, thx [13:34:10 CEST] <Compn> durandal_1707 : [13:35:19 CEST] <Compn> durandal_1707 : looks like final fantasy 7 pc game used tr20 for its fmv [13:35:26 CEST] <Compn> i dont know if we have any samples [13:38:34 CEST] <Compn> durandal_1707 : https://samples.ffmpeg.org/V-codecs/TM20/ [13:38:45 CEST] Action: Compn wonders why he went to google instead of checking samples repo [13:38:56 CEST] <durandal_1707> m is not r [13:39:13 CEST] <Compn> oh woops [13:41:09 CEST] <Compn> ask kostya, he wrote the wiki entry on it http://wiki.multimedia.cx/index.php?title=Duck_TrueMotion_2_Realtime [13:43:23 CEST] <Compn> i could probably make a sample if i can find an installer [13:47:29 CEST] <Compn> durandal_1707 : https://samples.ffmpeg.org/drivers32/!OLD/tr2032.dll is the binary codec for tr20, but looks decode only [14:49:43 CEST] <wm4> michaelni: seriously, just start fixing all those issues yourself [16:37:08 CEST] <wm4> where do we shuffle parser parameters to the codecpar? [16:47:28 CEST] <nevcairiel> there really isnt a good place [16:47:35 CEST] <nevcairiel> like i said, parsers dont fit the flow anymore [16:49:38 CEST] Action: Daemon404 sees tons of new issues :( [16:50:29 CEST] <wm4> nevcairiel: yeah, seems like we have a place now where we add hacks for parser updates [16:51:04 CEST] <wm4> Daemon404: many michaelni reported ones seem just due to av_dump_format being dumb [16:52:02 CEST] <Daemon404> i see at least two vob things [16:52:33 CEST] <nevcairiel> no clue how the mpegps demuxer works internally [16:52:38 CEST] <Daemon404> ill look [16:52:39 CEST] <nevcairiel> maybe it needs the new update flag somewhere [16:52:43 CEST] <Daemon404> whats up with this mkv thing? [16:52:59 CEST] <nevcairiel> as i understand, it had a hack for such files before, and the hack broke? [16:53:15 CEST] <Daemon404> i assume one of you located the hack then [16:53:21 CEST] <wm4> I can look at it [16:53:24 CEST] <wm4> I had fun with it before [16:53:35 CEST] <wm4> it's a "let's fix a single sample with some hack" fix [16:53:47 CEST] <wm4> and it has to do with timestamps [16:53:59 CEST] <Daemon404> ok [16:54:05 CEST] <Daemon404> i will poke vob right now then [16:54:24 CEST] <Daemon404> although i assume closed captions in vob will be pain [16:54:35 CEST] <Daemon404> (in an mpeg2 stream) [16:54:37 CEST] <nevcairiel> the CC one is probably irrelevant [16:54:40 CEST] <nevcairiel> its just display [16:55:00 CEST] <nevcairiel> unless you want codecpar to have such a field to inform the user about the presence, ie. keeping the hack alive [16:55:07 CEST] <Daemon404> ah ok [16:55:15 CEST] <Daemon404> yeah i looked it and it was checkign avcyx->properties [16:55:20 CEST] <Daemon404> but i didnt see it set anywhere in lavf [16:55:26 CEST] <nevcairiel> its not [16:55:32 CEST] <nevcairiel> its filled by the mpeg2 decoder during probing [16:55:48 CEST] <wm4> Daemon404: av_dump-format creates a temporary avctx [16:55:57 CEST] <Daemon404> ah... [16:56:47 CEST] <Daemon404> the sample in the bug still has some ac3 issues [16:56:52 CEST] <Daemon404> [ac3 @ 0x3743080] frame sync error [16:56:57 CEST] <Daemon404> whatever that is [16:56:59 CEST] <Daemon404> probably parsers [16:57:30 CEST] <Daemon404> hmm yep [16:57:35 CEST] <Daemon404> it needs to set the update falg [16:57:37 CEST] <Daemon404> flag* [16:59:16 CEST] <Daemon404> michaelni, since you asked, i added a way to mark issues unimportant [16:59:28 CEST] <Daemon404> click add label -> unimportant [17:01:57 CEST] <wm4> does anyone know how to select only 1 stream with ffprobe? [17:02:44 CEST] <Daemon404> there's -select_stream or something iirc [17:03:54 CEST] <Daemon404> oh good... i marked context neding update in vob and segfauly [17:05:18 CEST] <Daemon404> oh. im just retarded. carry on. [17:11:27 CEST] <cone-212> ffmpeg 03Martin Vignali 07master:d2ed3391fbfe: libavcodec/exr: fix PRX24 Float decompression [17:11:27 CEST] <cone-212> ffmpeg 03Martin Vignali 07master:25a01c52b889: libavcodec/exr: add tile support [17:12:46 CEST] <wm4> the mkv issue somehow has wrong timestamps in the first 6 packets or so [17:13:01 CEST] <wm4> I bet it's a parser issue [17:14:50 CEST] <Daemon404> wm4, there are no less than 3 issues open about ac3 [17:14:56 CEST] <Daemon404> theyre probably all the same issue [17:17:11 CEST] <wm4> which ones? [17:17:52 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/issues/16 (ignore the cpations, look at the ac3 warnings) [17:18:14 CEST] <nevcairiel> try setting frame_size from the parser [17:18:16 CEST] <nevcairiel> or something [17:18:26 CEST] <Daemon404> ok [17:18:31 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/issues/2 [17:18:37 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/issues/8 [17:19:44 CEST] <Daemon404> nevcairiel, no dice, doesnt fix it [17:20:09 CEST] <wm4> durandal_1707: you pushed code that can crash on unexpected input? [17:21:07 CEST] <Daemon404> although i see a ton of stuff [17:21:08 CEST] <durandal_1707> wm4: nope, I manually changed his code... [17:21:31 CEST] <Daemon404> although i see a ton of stuff [17:21:34 CEST] <Daemon404> woops [17:21:39 CEST] <Daemon404> ... what the hell [17:21:47 CEST] <Daemon404> the parser can update the codec id [17:22:05 CEST] <Daemon404> because its used for multiple codecs (aac and ac3 and eac3) [17:22:33 CEST] <wm4> how wonderful [17:22:41 CEST] <nevcairiel> it can, but it doesnt really matter, as the decoder can handle both without problems [17:22:53 CEST] <Daemon404> it lso updates channel layout and count [17:22:56 CEST] <Daemon404> which currently isnt copied [17:23:22 CEST] <nevcairiel> the decoder should be able to determine that without the parser either way [17:23:52 CEST] <Daemon404> you would think so [17:23:54 CEST] <Daemon404> but you would be wrong [17:24:03 CEST] <Daemon404> copying those fixes those warnings/errors [17:30:50 CEST] <Daemon404> wm4, it did not fix mkv [17:30:55 CEST] <Daemon404> that seems to be separate [17:40:01 CEST] <wm4> it has something to do with making up timestamps, I think [17:40:22 CEST] <wm4> which is broken probably during find_stream_info [17:42:14 CEST] <Daemon404> i see [17:49:14 CEST] Action: Daemon404 installs libxvid to test [17:51:54 CEST] <Daemon404> wm4, i assume you know where the offending code is [17:52:05 CEST] <wm4> I have no idea what's going on [17:52:13 CEST] <Daemon404> oh. [17:57:08 CEST] <cone-212> ffmpeg 03Michael Niedermayer 07master:06c4ed0c0e34: avformat/wavdec: fix typo with len [18:00:58 CEST] <wm4> or rather, I have no idea why this ever worked [18:01:40 CEST] <Daemon404> lol i see [18:02:06 CEST] <Daemon404> only two non-dump-related things left are this xvid thign im looking into and mkv, then [18:02:50 CEST] <jfmcarreira> heyy guys [18:02:59 CEST] <jfmcarreira> are the application for GSoC closed? [18:04:30 CEST] <kierank> yes [18:05:07 CEST] <Daemon404> hey kierank do you know the teletext code? [18:05:27 CEST] <wm4> hm shaping up to by my own fault [18:05:33 CEST] <Daemon404> wm4, lol? [18:05:54 CEST] <jfmcarreira> kierank: is it possible to still contribute to some of the task? [18:06:18 CEST] <Daemon404> jfmcarreira, it's always possible to contribute, but you wont be paid by google, since yo uarent in gsoc [18:06:40 CEST] <jfmcarreira> Daemon404: yeah that makes sense [18:06:48 CEST] <kierank> Daemon404: no but I can help with teletext in general [18:07:03 CEST] <jfmcarreira> there are some very interesting projects for me: the FFv1 and H.264 MVC decoder [18:07:37 CEST] <Daemon404> kierank, im just trying to find where the teletex width and height are set [18:07:55 CEST] <Daemon404> context: https://github.com/dwbuiten/FFmpeg/issues/15 [18:08:05 CEST] <Daemon404> it might just be dump.c being crap, though [18:08:17 CEST] <kierank> meaningless number afaik [18:08:22 CEST] <kierank> it changes depending on the width of the data [18:08:42 CEST] <nevcairiel> probably determined by the decoder [18:08:47 CEST] <nevcairiel> now figure out why its no longer decoded [18:09:24 CEST] <Daemon404> i love the two schools of taught [18:09:30 CEST] <Daemon404> "it's meaningless" vs " better fix it" [18:10:02 CEST] <kierank> it sets avctx->width and height to the maximum it's going to be [18:10:09 CEST] <kierank> but then per frame it sets it to the actual [18:10:29 CEST] <Daemon404> kierank, i see [18:10:33 CEST] <Daemon404> i get what you mean. [18:10:44 CEST] <wm4> Daemon404: fixed the mkv thing [18:10:52 CEST] <Daemon404> cool [18:11:00 CEST] <Daemon404> ive found whats going wrong with the libxvid one [18:11:30 CEST] <wm4> (quite questionable: the frame_size check, which I readded, disables sub-packet timestamps for the first block...) [18:11:37 CEST] <Daemon404> (also in the last 2 years ive learned far too much about mov/mp4 for my own liking... such that it all makes sense to me in movenc.c) [18:12:31 CEST] <wm4> I'm sorry [18:13:11 CEST] <Daemon404> it looks like vos_len is being written wrong in the esds box [18:13:39 CEST] <Daemon404> trk->vos_len = par->extradata_size; [18:13:45 CEST] <Daemon404> yep. [18:14:51 CEST] <Daemon404> it's global extradata related [18:15:04 CEST] <Daemon404> encode_frame is setting the global extradata [18:15:15 CEST] <Daemon404> im guessing that isnt copied to codecpar [18:16:55 CEST] <nevcairiel> setting it where? [18:17:08 CEST] <Daemon404> libxvid.c sets it in encode_frame [18:17:11 CEST] <Daemon404> after encoding every keyframe [18:17:21 CEST] <Daemon404> (its only used once in movenc.c obviously) [18:17:54 CEST] <Daemon404> er, it ses it on the first keyframe. [18:18:10 CEST] <nevcairiel> same problem as in demuxers, i guess, producing extradata after init is not supported [18:18:28 CEST] <nevcairiel> in this case, its practically unfixable [18:18:31 CEST] <Daemon404> libx264 and libx265 both set it in _init [18:18:33 CEST] <Daemon404> which is proper [18:18:53 CEST] <nevcairiel> unless with a bunch of mov-specific hacks [18:18:57 CEST] <nevcairiel> that just happen to work because [18:19:09 CEST] <Daemon404> lol well [18:19:30 CEST] <Daemon404> libxvid.c literally checks: [18:19:30 CEST] <Daemon404> int quicktime_format; /**< Are we in a QT-based format? */ [18:20:00 CEST] <nevcairiel> its controlled by AV_CODEC_FLAG_GLOBAL_HEADER [18:20:00 CEST] <Daemon404> which is set during init based off GLOBAL_HEADER [18:20:02 CEST] <nevcairiel> like the others [18:20:03 CEST] <Daemon404> yes [18:20:09 CEST] <nevcairiel> but it needs to generate the header earlier [18:20:15 CEST] <nevcairiel> otherwise it might be screwed [18:20:25 CEST] <Daemon404> i think the lib can [18:20:29 CEST] <Daemon404> but i may be wrong [18:20:32 CEST] <Daemon404> the api is pretty shitty [18:21:10 CEST] <nevcairiel> most of the demux shit we could fix because there is find_stream_info that runs the demuxer and decoder for a few frames to gather info [18:21:15 CEST] <nevcairiel> but in encoding, there is no such thing [18:21:35 CEST] <nevcairiel> its either present right away, or not at all [18:21:40 CEST] <Daemon404> the only reason it works for mov is because the header is written at the end of the file [18:21:44 CEST] <Daemon404> it *happens* to work [18:22:06 CEST] <nevcairiel> yeah, except that now at the beginning the codecpar is created from the avctx just once [18:22:28 CEST] <nevcairiel> no matter how late mov reads it [18:24:26 CEST] <Daemon404> https://ffmpeg.org/pipermail/ffmpeg-devel/2012-April/122894.html [18:24:35 CEST] <Daemon404> it looks like nicholas attempted to fix this once [18:26:22 CEST] <Daemon404> it looks like it never went anywhere [18:27:07 CEST] <Daemon404> in fact that is the first google result for the API... [18:28:59 CEST] <wm4> Daemon404: anything else I could briefly look into? [18:29:25 CEST] <Daemon404> teletext [18:30:23 CEST] <wm4> I bet this is also a display issue [18:30:37 CEST] <wm4> I'll make sure whether it is [18:33:47 CEST] <wm4> even on master I get: [18:33:48 CEST] <wm4> Stream #0:2[0x240](eng): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006), 492x250 [18:33:48 CEST] <wm4> Stream #0:6[0x247](eng): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006) [18:33:56 CEST] <wm4> err that's 2.8, but still [18:39:28 CEST] <wm4> is .ts really fixed? [18:41:00 CEST] <wm4> uh, this might depend on whether you have compiled with libzvbi [18:41:11 CEST] <JEEB> o_O [18:46:50 CEST] <michaelni> codecpar: libavformat/xmv.c: if (avio_read(pb, data, 4) != 4) { printf("WUT\n"); [18:49:02 CEST] <wm4> michaelni: removed that [18:49:20 CEST] <michaelni> thx [18:50:03 CEST] <rcombs> wut [18:51:22 CEST] <nevcairiel> code should wut more [18:51:26 CEST] <Daemon404> lol shit [18:51:33 CEST] <Daemon404> sorry, i left in a debug printf [18:51:47 CEST] <nevcairiel> didnt we have some evil crap somewhere to make printf error [18:51:53 CEST] <nevcairiel> or was that removed [18:51:54 CEST] <Daemon404> that got removed [18:53:05 CEST] <Daemon404> cool... fixed libxvid.c [18:53:15 CEST] <Daemon404> will send patch to ML [18:57:34 CEST] <rcombs> Daemon404: *points at av_log* [18:58:17 CEST] <Daemon404> rcombs, i am not going to debug with avlog [18:58:23 CEST] <Daemon404> its like 10x the typing [18:58:41 CEST] <nevcairiel> av_log(0,0, "message") isnt that long =p [18:59:22 CEST] <Daemon404> ;p [18:59:35 CEST] Action: Compn wonders how many people use 'yadif' now vs other filters [19:00:16 CEST] <rcombs> PMS uses yadif [19:00:41 CEST] <jamrial> i'm going to guess yadif is still used the most because why switch? [19:01:22 CEST] <Daemon404> wm4, can you look at pulse... i dont think nev or i even have somethign capable of testing it [19:02:19 CEST] <wm4> what's wrong with pulse? didn't it get converted? [19:02:39 CEST] <Daemon404> michael just filed a bug [19:05:30 CEST] <cone-212> ffmpeg 03Hendrik Leppkes 07master:6518cbc52a8c: lavc/utils: Introduce ff_bprint_to_codecpar_extradata for avformat [19:15:27 CEST] <Daemon404> hmmm [19:15:34 CEST] <Daemon404> seems avg_frame_rate is not copied over when doing -c opy? [19:15:38 CEST] <Daemon404> -c copy* [19:18:12 CEST] <Daemon404> ok i see what to do... [19:18:13 CEST] <Daemon404> barf [19:22:33 CEST] <cone-212> ffmpeg 03Paul B Mahol 07master:76466ab214ef: avformat/brstm: lower magic number, fixes decoding of some files [19:34:33 CEST] <durandal_1707> how many unresolved codecpar issues remain? [20:04:01 CEST] <cone-212> ffmpeg 03Claudio Freire 07master:bad41d372422: AAC encoder: fix initialization of minsf [20:22:29 CEST] <Daemon404> durandal_1707, as of right now: all related to dump.c, none of which are breaking files afaik [20:22:36 CEST] <Daemon404> also wm4 nevcairiel ^ [20:24:23 CEST] <wm4> CLOSED WONTFIX [20:24:49 CEST] <Daemon404> there's one at least i think merits a look [20:24:52 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/issues/9 [20:25:51 CEST] <nevcairiel> i didnt find where it sets that on a cursory look [20:28:40 CEST] <Daemon404> - if (st->sample_aspect_ratio.num && // default [20:28:40 CEST] <Daemon404> - av_cmp_q(st->sample_aspect_ratio, st->codec->sample_aspect_ratio)) { [20:28:43 CEST] <Daemon404> + if (st->sample_aspect_ratio.num) { [20:28:43 CEST] <Daemon404> related? [20:28:45 CEST] <Daemon404> in dump.c [20:28:51 CEST] <cone-212> ffmpeg 03Claudio Freire 07master:52562503d524: AAC encoder: new regression test [20:29:02 CEST] <nevcairiel> so you think its just dump.c doing that? [20:29:21 CEST] <nevcairiel> if anything it should compare codecpar AR instead of just removing the compare [20:29:45 CEST] <Daemon404> let me check if that is it [20:29:49 CEST] <Daemon404> and add it back if so [20:29:51 CEST] <Daemon404> with par [20:30:13 CEST] <Daemon404> (btw found via : git diff b044dd37445d50420fa6929a43de7733fa93bee3^..HEAD | grep st->sample_aspect) [20:35:09 CEST] <Guest50893> Hi Guys [20:35:45 CEST] <Guest50893> Any one has a working SCTE 35 decoder? [20:39:14 CEST] <Daemon404> hmm [20:39:15 CEST] <Daemon404> michaelni, ping [20:39:35 CEST] <Daemon404> mpeg2_field_encoding.ts from FATE doesnt match what you filed in the bug [20:40:14 CEST] <Daemon404> OH, its output dump [20:40:50 CEST] <Daemon404> ok [20:40:54 CEST] <Daemon404> nevcairiel, adding back that check with codecpar fixes the double AR issue. pushed it. [20:48:15 CEST] <Daemon404> ok... no other regressions left at the moment except some dump.c stuff which seems pretty iffy [20:48:55 CEST] <jamrial> time to rebase and see it explode? :p [20:50:01 CEST] <Daemon404> jamrial, depends [20:50:10 CEST] <Daemon404> i want wanna start that and then michael files 90 more bugs midway [20:52:06 CEST] <Daemon404> jamrial, the merge diff is 1.4mb [20:52:10 CEST] <Daemon404> the size of a goddam floppy [20:55:24 CEST] <Daemon404> hmm [20:55:32 CEST] <Daemon404> looks like rebaseing was pretty painless [20:55:37 CEST] <Daemon404> only a few conflicts [20:56:07 CEST] <Daemon404> nevcairiel, is there other stuff you want to break out and send to the ML separately before i rebase [20:56:34 CEST] <nevcairiel> i didnt see an ything obvious [20:56:44 CEST] <Daemon404> is that a go-ahead? :) [20:56:55 CEST] <wm4> do it [20:57:20 CEST] <Daemon404> even if there are more bugs... its a step closer to master. [20:57:52 CEST] <nevcairiel> go-ahead for what [20:58:08 CEST] <Daemon404> rebasing / squashing onto master [20:58:10 CEST] <Daemon404> in a branch [20:58:43 CEST] <durandal_1707> Push upstream [20:59:39 CEST] <jamrial> i'd say yes, any further testing should be done post rebase [20:59:57 CEST] <Daemon404> cool [20:59:59 CEST] <jamrial> the branch is like 300 commits behind master [21:00:02 CEST] <Daemon404> yea [21:04:48 CEST] <nevcairiel> sure, can start reviewing as well t hen [21:06:25 CEST] <Daemon404> nevcairiel, i was planning on squashing it into the merge commit, but im open to other methods [21:16:30 CEST] <Daemon404> thanks for review michaelni, will update once im done rebasing [21:23:31 CEST] <Daemon404> wm4, looks like more matroska hacks were added recently [21:23:39 CEST] <wm4> lol [21:23:48 CEST] <Daemon404> if (codec->bits_per_raw_sample) [21:23:48 CEST] <Daemon404> bit_depth = codec->bits_per_raw_sample; [21:23:48 CEST] <Daemon404> else [21:23:48 CEST] <Daemon404> bit_depth = av_get_bytes_per_sample(codec->sample_fmt) << 3; [21:23:54 CEST] <wm4> oh that [21:24:08 CEST] <Daemon404> not sure how to fis that conflict [21:24:43 CEST] <wm4> nevcairiel did that [21:24:47 CEST] <wm4> it's of course for FLAC [21:25:03 CEST] <wm4> but codec params has only bits_per_codec_sample right? [21:25:12 CEST] <Daemon404> coded [21:25:12 CEST] <Daemon404> but yes [21:25:37 CEST] <wm4> let me check the ML [21:26:38 CEST] <wm4> I wish I had a better mail client [21:26:56 CEST] <nevcairiel> its just annoying that we dont have a 24-bit sample format, it makes carrying around bitdepth mandatory [21:27:05 CEST] <fritsch> :-) [21:27:11 CEST] <Daemon404> nevcairiel, yes [21:27:12 CEST] <Daemon404> also [21:27:13 CEST] <Daemon404> mkv_write_video_color exists now [21:27:21 CEST] <Daemon404> which for somer eason uses codec context AND side data> [21:27:22 CEST] <Daemon404> wtf? [21:27:46 CEST] <Daemon404> it's also unofficial / not spec [21:28:20 CEST] <nevcairiel> the color info it wants should be in codecpar [21:28:23 CEST] <Daemon404> ah ok it can use codecpar [21:28:28 CEST] <Daemon404> for some reason i thought par ddint have it [21:29:01 CEST] <wm4> me too [21:29:04 CEST] <nevcairiel> i dont know why that guy pushed for these patches already being included before the spec was actually finally [21:29:14 CEST] <nevcairiel> even if its under a experimental flag [21:30:18 CEST] <Daemon404> me neither [21:30:31 CEST] <Daemon404> ok matroskadec conflicts done except for the raw_sample stuff [21:30:34 CEST] <Daemon404> what do? [21:31:06 CEST] <wm4> this was the ticket it was supposed to solve https://trac.ffmpeg.org/ticket/5332 [21:32:26 CEST] <Daemon404> lovely [21:32:59 CEST] <wm4> maybe bits_per_codec_sample can be used? [21:33:22 CEST] <wm4> isn't that what we want anyway (but I have no clue) [21:45:38 CEST] <Daemon404> ok [21:45:42 CEST] <Daemon404> that is the last remaining conflict now nevcairiel [21:45:46 CEST] <Daemon404> not sure what to do [21:57:22 CEST] <Daemon404> nevcairiel, no ideas? [22:03:51 CEST] <jamrial> Daemon404: reading bits_per_raw_sample from st->internal->avctx is not possible? or it is, but too hacky? [22:04:18 CEST] <nevcairiel> muxers dont have any values in there [22:04:48 CEST] <nevcairiel> and no, no ideas, bits_per_coded might work [22:05:32 CEST] <wm4> nevcairiel: it probably will for flac, but I'm worried about it writing nonsense for other cases [22:05:50 CEST] <wm4> jamrial: it's broken due to the API [22:06:06 CEST] <wm4> so either bits_per_coded works, or codecpar needs to be extended [22:09:10 CEST] <Daemon404> what exactly is the difference between bits_per_coded and bits_per_raw [22:11:23 CEST] <Daemon404> wm4, if(flac)? i dunno. seems shitty. [22:11:32 CEST] <Daemon404> i currently just commented that bit out so i could run fate [22:15:09 CEST] <wm4> good question [22:15:36 CEST] <Daemon404> running fate right now, then i will push the rebased branch [22:15:43 CEST] <Daemon404> with a list of any failures [22:19:00 CEST] <Daemon404> only 1 failure [22:25:14 CEST] <Daemon404> seems tests/ref/fate/rv20-1239 fails [22:25:26 CEST] <Daemon404> starts at 1 now instead of 0 [22:27:32 CEST] <Daemon404> nevcairiel, wm4, michaelni, ubitux - https://github.com/dwbuiten/FFmpeg/tree/codecpar_rebase [22:29:12 CEST] <ubitux> oh nice [22:29:17 CEST] <ubitux> i'm sorry i wasn't of very much help [22:29:34 CEST] <Daemon404> theres one new fate failure from a test michaelni added on friday [22:30:21 CEST] <ubitux> when is the push due? (or said differently: how long do we have for the review?) [22:30:52 CEST] <Daemon404> michaelni suggested 48h with no breaking regressions before push [22:30:58 CEST] <ubitux> (Daemon404: nit: you used my old mail i'm not watching anymore :P) [22:31:12 CEST] <Daemon404> ubitux, sure ill ammend it when i next squash [22:34:21 CEST] <wm4> <Daemon404> michaelni suggested 48h with no breaking regressions before push <- so never? [22:34:40 CEST] <wm4> I suggest we suggest something else [22:37:39 CEST] <Daemon404> heh [22:37:46 CEST] <Daemon404> up to you guys [22:38:19 CEST] <Daemon404> i would like it sooner rather than later of course [22:48:21 CEST] <Daemon404> ughhhhh [22:48:25 CEST] <Daemon404> wm4, i think this is lowres [22:48:38 CEST] <Daemon404> michaelni, that rv20 sample is lowres right? [22:49:26 CEST] <Daemon404> +fate-rv20-1239: CMD = framecrc -flags +bitexact -idct simple -lowres 1 -i $(TARGET_SAMPLES)/real/G2_with_SVT_320_240.rm [22:49:29 CEST] <Daemon404> yep [22:49:34 CEST] <Daemon404> nevcairiel, too ^ [22:51:47 CEST] <Daemon404> ubitux, this answers your question btw [22:52:19 CEST] <ubitux> it was also because of lowres in dv, i'm just wondering where in the code [22:54:41 CEST] <jamrial> are fate-vp6a and fate-vp6a-skip_alpha really going to be declared "fixed" by changing the sample from flv to mov? [22:55:03 CEST] <Daemon404> jamrial, the problem is in ffmpeg.c [22:55:06 CEST] <Daemon404> it uses the api wrong [22:55:25 CEST] <wm4> not "wrong", just in a less than ideal way [22:55:43 CEST] <wm4> which happens to make it very hard to actually test what the test is supposed to test [22:56:02 CEST] <Daemon404> mostly it was coincidence it worked before [22:56:06 CEST] <Daemon404> afaict [22:56:44 CEST] <wm4> yeah, basically [22:57:56 CEST] <Daemon404> ubitux, i dont know [22:58:15 CEST] <Daemon404> ls [22:58:17 CEST] <Daemon404> woops [23:05:11 CEST] <Daemon404> so the only outstanding issue: lowres [23:07:02 CEST] <Daemon404> ubitux, look in rv10_decode_init [23:07:10 CEST] <Daemon404> maybe you can shed some light [23:07:38 CEST] <wm4> isn't it because the demuxer will export the reduced resolution [23:07:46 CEST] <wm4> which makes the decoder fail init [23:07:48 CEST] <wm4> i.e. dumb shit [23:08:08 CEST] <Daemon404> i dont understand lowres very well [23:08:13 CEST] <Daemon404> in fact i was in favour or removing it [23:08:15 CEST] <Daemon404> o* [23:08:16 CEST] <Daemon404> of* [23:08:34 CEST] <BBB> I dont see why a demuxer would care at all about lowres being enabled or not [23:08:50 CEST] <BBB> just like a muxer should typically not care about crf vs. vbr [23:09:09 CEST] <BBB> (except broken microsoft formats that store vbr in the stream header) [23:09:14 CEST] <BBB> (bitrate) [23:09:22 CEST] <Daemon404> wm4, i dont see lowres checked anywhere [23:09:24 CEST] <Daemon404> in lavf [23:09:34 CEST] <Daemon404> or is it some find_stream_info crap again [23:09:39 CEST] <wm4> maybe [23:09:59 CEST] <wm4> BBB: well I don't know the details either [23:10:12 CEST] <wm4> BBB: but if it's the demuxer... the demuxer can open a decoder [23:10:16 CEST] <wm4> to detect stream infos [23:10:34 CEST] <wm4> so if lowres is somehow passed down to the decoder [23:10:56 CEST] <wm4> and AFAIK git master avoids this by passing coded_width instead, which is not changed by lowres? [23:11:07 CEST] <wm4> anyway I'm off [23:11:10 CEST] <Daemon404> cya [23:11:55 CEST] <Daemon404> well people are gonna have to agree on some solution [23:12:07 CEST] <Daemon404> merge waiting on lowres is just depressing [23:12:30 CEST] <Compn> lowres is useful in some cases :P [23:12:36 CEST] Action: Compn runs [23:12:39 CEST] <Daemon404> michaelni's patch on the ML fixes it, but i know people dont like it [23:12:43 CEST] <JEEB> very limited by now though [23:12:46 CEST] <Daemon404> so... :psyduck: [23:12:51 CEST] <Compn> it would be great for 4k [23:12:59 CEST] <JEEB> since most low-power devices have HW decoders [23:13:11 CEST] <JEEB> and those formats used for high-res/high frame rate content usually dont support lowres [23:13:12 CEST] <Daemon404> no codec people use for 4k has lowres support [23:13:17 CEST] <Daemon404> unless you want MPEG-2 4k [23:14:10 CEST] <BBB> find_stream_info needs to be fixed to not apply lowres twice then [23:14:14 CEST] <BBB> I mean this is all so basic [23:14:24 CEST] <BBB> you guys are applying hacks to hacks to hack your hack around hacks that are hacky and broken [23:14:27 CEST] <BBB> dont do that [23:14:49 CEST] <BBB> why do you think people hate lowres? [23:14:58 CEST] <BBB> dont make that sentiment worse [23:15:27 CEST] <Compn> stop the rumor mill ? [23:15:55 CEST] <michaelni> unless iam missing something its easy to fix lowres if you are willing to break API/ABI if you want to keep API its hacky [23:18:03 CEST] <michaelni> the thing is API "requires" the demuxer to give width/height in AVCodecContext dependant on lowres, it was the decoders presentation width/height [23:19:14 CEST] <michaelni> and with that things get hacky, either you have a 2nd set of width & height as in my patch or you become creative how to hack around that [23:21:17 CEST] <michaelni> IMHO the 2nd set is not that bad as one would be coded and one displayed (aka crop) and crop can be stored in the demuxer layer [23:22:37 CEST] <michaelni> anyway iam happy about any other solution as well [23:23:24 CEST] Action: Daemon404 has no opinion or idea to fix [23:25:03 CEST] <Daemon404> it's the only breakage (discovered) left in codecpar atm though [23:25:06 CEST] <Daemon404> so me = sad [23:25:46 CEST] <durandal_1707> why, lowers shouldn't change w/h [23:25:56 CEST] <durandal_1707> seems fishy [23:26:09 CEST] <durandal_1707> It's just decoder option [23:26:12 CEST] <Daemon404> it's been explained above [23:26:29 CEST] <jamrial> disable the test, push upstream, wait for people that actually use lowres to complain if they exist :p [23:26:47 CEST] <Daemon404> those people are Compn, michaelni, and ami_stuff, maybe carl [23:26:53 CEST] <Daemon404> for non-dev users... who knows [23:27:04 CEST] <durandal_1707> break lowered api its hacky anyway [23:27:16 CEST] <durandal_1707> lowres* [23:27:25 CEST] <Daemon404> yeah im sure that will go over well [23:27:35 CEST] <Daemon404> and is not at all controversial or likely to cause glames [23:28:50 CEST] <Daemon404> flames* [23:38:42 CEST] <Daemon404> michaelni, assuming nothing fundementally broken pops up (and lowres gets fixed), tentatively i want to push the merge some time this week [23:58:00 CEST] <michaelni> Daemon404, this week (that is within the next 7 days) sounds realistic/doable to me [23:58:11 CEST] <Daemon404> yes, to me too [23:58:27 CEST] <Daemon404> i would prefer before the end of friday, personally though [23:58:36 CEST] <Daemon404> since i am flying back to europe friday night [23:58:41 CEST] <Daemon404> and saturday will be jetlagged [00:00:00 CEST] --- Mon Apr 4 2016

1 0

ffmpeg.log.20160403
by burek 04 Apr '16

04 Apr '16

[01:34:07 CEST] <varu-> having an interesting issue with processing an mpegts stream with ffmpeg [01:35:08 CEST] <varu-> the source is an rtp udp stream & i get a ton of "max delay reached. need to consume packet" and RTP: missed packets [01:35:29 CEST] <varu-> as well as constant reference errors, [h264 @ 0x55775b23cc20] Reference 2 >= 2 [01:35:29 CEST] <varu-> [h264 @ 0x55775b23cc20] error while decoding MB 37 2, bytestream 2127 [01:36:12 CEST] <varu-> this is with -vcodec libx264; if i do -vcodec copy, i only get the rtp missed packets [01:36:58 CEST] <varu-> the result is a stream whose audio is fine, but video cycles 2-3 corruptly-decoded frames for a few seconds until a few new ones are captured, then the cycle repeats [01:37:14 CEST] <varu-> packetloss is not an issue, this is on the same vlan [01:38:50 CEST] <Ben321> I need some help with the msvideo1 encoder in FFMPEG. [01:39:31 CEST] <Ben321> How do I set the quality to maximum. It uses minimum quality by default. -q:v 100 has no effect. -q:v 1 has no effect. [01:39:46 CEST] <JEEB> see if it uses quantizer for anything [01:40:05 CEST] <JEEB> libavcodec/encodername_enc.c [01:40:28 CEST] <JEEB> libavcodec/msvideo1enc.c to be exact [01:41:02 CEST] <Ben321> I don't think msvideo1 encoder uses quantizer, but it does have the ability to set quality, I just don't know how to do it in FFMPEG. [01:41:19 CEST] <JEEB> well -q is not quality, it's quantizer :P [01:41:45 CEST] <JEEB> and quality variable in the encoder seems to be internal [01:42:28 CEST] <JEEB> ok, as far as I quickly could see [01:42:33 CEST] <JEEB> it's pretty uncontrollable :P [01:42:34 CEST] <Ben321_> But yes, the official Microsoft msvideo1 codec most certainly supports manual setting of quality. I know, because I've used it a number of times in Windows video software (not FFMPEG) for encoding video in an AVI file. [01:42:55 CEST] <TD-Linux> now THAT's an encoder [01:43:14 CEST] <TD-Linux> it even has rdo! [01:43:33 CEST] <Ben321_> So hopefully FFMPEG will support (if not now, then at some point in the future) the ability to set the quality, just like the official Microsoft msvideo1 codec does. [01:43:46 CEST] <TD-Linux> I doubt anyone will write it unless you do [01:43:51 CEST] <J_Darnley> A separate piece of software has different settings? I am Socked(!) [01:44:50 CEST] <furq> out of interest, what terrible crime did you commit which has resulted in you being forced to use msvideo1 [01:44:52 CEST] <JEEB> also whatever "quality" means in MS's encoder can mean something completely different than in libavcodec's internal "quality" variable in the encoder [01:45:11 CEST] <JEEB> and yes, you can make a feature request to be able to set something [01:45:22 CEST] <Ben321_> Well, msvideo1 is supposed to have the ability to set quality. I know it does, because the official codec for it from Microsoft has this ability. If FFMPEG were to correctly implement an msvideo1 encoder, then it would most certainly support a quality setting. [01:45:25 CEST] <JEEB> but unfortunately I think nobody cares about the encoder [01:46:14 CEST] <JEEB> you are still missing the point of definition of "quality". given a quick guess for the encoder it probably is something like the quantizer :P [01:46:23 CEST] <JEEB> but in any case, you can make a feature request on trac [01:46:42 CEST] <JEEB> but unless you either pay someone or do it yourself, I don't see anyone caring enough [01:48:22 CEST] <Ben321> I didn't get forced to use it, I just wanted to use it for making some nostalgic video files, that would have all the artifacts of this codec (but not to the degree it does on low-quality settings) just like I used to do years ago. It has decent compression, and on highest quality setting (in the official MS codec) decodes to a decent quality image. [01:49:42 CEST] <Ben321_> Why did I get spontaneously disconnected just now? [01:49:56 CEST] <scoofy> why not [01:50:00 CEST] <J_Darnley> Blame your ISP [01:50:03 CEST] <scoofy> the funz of the internet [01:50:13 CEST] <scoofy> or your wifi rooter is too far [01:50:21 CEST] <Ben321_> And just in case my last post didn't make it onto the IRC, here it is again: [01:50:24 CEST] <Ben321_> I didn't get forced to use it, I just wanted to use it for making some nostalgic video files, that would have all the artifacts of this codec (but not to the degree it does on low-quality settings) just like I used to do years ago. It has decent compression, and on highest quality setting (in the official MS codec) decodes to a decent quality image. [01:50:54 CEST] <TD-Linux> Ben321_, if you can compile ffmpeg yourself, you can just twiddle the quality number in the code [01:51:21 CEST] <TD-Linux> maybe you can even make improvements to make ffmpeg the best msvideo1 encoder ever :^) [01:51:32 CEST] <varu-> http://ffmpeg.gusari.org/viewtopic.php?f=11&t=2746 is very similar to what i'm seeing, as the ts stream renders perfectly fine in vlc [01:54:49 CEST] <varu-> https://trac.ffmpeg.org/ticket/3405 this is basically what i'm seeing [01:55:40 CEST] <Ben321> Connection just reset again, so I'm not sure if the last thing I typed actually got posted, so here it is again: [01:55:44 CEST] <Ben321> According to this webpage https://ffmpeg.org/pipermail/ffmpeg-devel/2009-March/072802.html (which is titled "[FFmpeg-devel] [PATCH] MS Video 1 encoder, take 2") the feature I'm now suggesting already was patched into FFMPEG, and that post was back in 2009. The part of the title of that post "[FFmpeg-devel] [PATCH]" indicates that a developer patched this feature into the official FFMPEG... [01:55:45 CEST] <Ben321> ...release. But now that feature isn't present, so I assume another developer got the bright idea to REMOVE that feature. [01:56:40 CEST] <Ben321> Can you still read what I'm posting? Or are all my posts disappearing? [01:57:03 CEST] <furq> it could just mean that the patch never made it into ffmpeg [01:57:22 CEST] <furq> judging by the rest of that thread, it didn't [01:57:58 CEST] <Ben321> I thought that that thread was a developer's own blog, where he stated what he was adding into FFMPEG. So it should be in there. [01:58:37 CEST] <Ben321> Hello? [01:58:52 CEST] <J_Darnley> Huh? It is the ffmpeg devel mailing list. You send patches there to be discussed and reviewed by others. [01:59:09 CEST] <furq> https://ffmpeg.org/pipermail/ffmpeg-devel/2009-March/072861.html [01:59:09 CEST] <J_Darnley> When they are approved they get commited. [01:59:43 CEST] <J_Darnley> The thread: https://ffmpeg.org/pipermail/ffmpeg-devel/2009-March/thread.html#72802 [02:01:04 CEST] <Ben321_> J_Darnley, could you repeat everything up to your last post? My connection dropped again. [02:01:19 CEST] <Ben321_> So I may have missed a BIG chunk of this conversation. [02:01:19 CEST] <J_Darnley> Huh? It is the ffmpeg devel mailing list. You send patches there to be discussed and reviewed by others. [02:01:29 CEST] <J_Darnley> When they are approved they get commited. [02:01:36 CEST] <J_Darnley> EOF [02:03:04 CEST] <Ben321_> Is their a source distribution of FFMPEG that is designed to be compiled in Microsoft Visual C++ 20xx? [02:03:47 CEST] <Ben321> I have Visual Studio 2010 on my PC, and would be able to compile, if there's a distribution of the source code that includes the required project file for Visual Studio 2010. [02:04:14 CEST] <J_Darnley> AFAIK the official source works with some MSVCs [02:04:32 CEST] <furq> https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC [02:04:36 CEST] <furq> that's as close as you'll get [02:04:51 CEST] <furq> you still need to use msys [02:05:28 CEST] <Ben321> What's msys? [02:05:56 CEST] <furq> it looks like the zeranoe dev builds include msvc static libraries, so you could use those [02:07:30 CEST] <furq> or the import libraries, rather [02:08:12 CEST] <furq> actually nvm i forgot what you were asking. you just want to compile ffmpeg don't you [02:09:10 CEST] <Ben321> Unfortunately, it also looks like a crapload of external libraries are required (such as bzip2), and these aren't included in the source distribution, but rather are linked to separately on the zeranoe website. [02:09:22 CEST] <furq> you don't need any of those libraries [02:12:05 CEST] <Ben321> Of the prebuilt copies on the zeranoe website, there's Static, Shared, and Dev. I assume Static means it doesn't require any additional DLL files, while shared does require additional DLLs. But what's in the Dev version? I assume it has something for developers. But just what is the difference? [02:12:26 CEST] <furq> the dev version contains the import libraries so you can link against the dlls [02:12:52 CEST] <furq> those are no use if you want to compile a patched ffmpeg, though [09:33:31 CEST] <zzz> I'm trying to decide what deinterlacing filter to use for video playback. I'm seeing bwdif, kerndeint, mcdeint, w3fdif, and yadif. Is there one of these generally regarded as highest quality? [10:06:51 CEST] <hanshenrik> in files containing video and audio [10:07:02 CEST] <hanshenrik> should stream 0:0 always video and 0:1 always be audio [10:07:06 CEST] <hanshenrik> or do i have to check first? [10:07:19 CEST] <hanshenrik> if i want to only select the video stream, eg -map 0:0 [10:10:36 CEST] <wiistriker> Hello! [10:11:18 CEST] <wiistriker> trying to implement such thing: get stream from IP cam (rtp), get audio from microphone on local machine and send stream to rtmp [10:12:25 CEST] <wiistriker> http://pastebin.com/qi1HQigP [10:13:11 CEST] <wiistriker> it actually works, but i need to scale video stream from rtp [10:13:13 CEST] <wiistriker> -vf scale=640x360 [10:14:02 CEST] <hanshenrik> yup, scaling dont work? [10:15:04 CEST] <wiistriker> Option vf (set video filters) cannot be applied to input file audio=@device_cm_{33 [10:15:18 CEST] <wiistriker> it try to apply scale for audio stream [10:23:10 CEST] <wiistriker> should i run two ffmpeg process? [10:58:03 CEST] <c_14> hanshenrik: -map 0:a:0 -map 0:v:0 etc. 0:0 does not have to always be video [10:58:19 CEST] <hanshenrik> oh thanks! [10:58:36 CEST] <c_14> wiistriker: can you pastebin the command and output with the vf as well? [11:01:30 CEST] <wiistriker> i just move -vf option after -f dhow - auido="..." [11:01:32 CEST] <wiistriker> and it works [11:02:13 CEST] <wiistriker> bad thing that my rtsp stream delay for about 3 sec but i get audio in realtime [11:50:10 CEST] <momomo> anyone here today? [11:58:42 CEST] <momomo> -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 2 -i url is not working [11:58:47 CEST] <momomo> not recognized options [11:58:49 CEST] <momomo> why ? [12:01:12 CEST] <nichego> hello. i have dvd content with soft telecine. is it possible to produce a hard telecine video from this using ffmpeg? [12:18:57 CEST] <durandal_1707> no [12:19:24 CEST] <nichego> so no equivalent to mencoder's softpulldown filter? [12:21:21 CEST] <durandal_1707> repeatfields maybe [12:21:59 CEST] <nichego> good pointer. i'll test now [12:25:23 CEST] <nichego> that seems to be doing the job, durandal_1707. many thanks! [12:34:03 CEST] <nichego> goodbye [13:40:00 CEST] <momomo> furq, i switched to using your suggested version of ffmpeg, static build .. but now I am getting: Decoder (codec dvb_teletext) not found for input stream #0:2 [13:40:13 CEST] <momomo> what could that be due to ? [14:36:44 CEST] <Fyr> guys, is there a C(++) library for simple FFT? I need simple include to my project, just like: #include "fft.h" and usage like double * fft(double *) [14:46:05 CEST] <J_Darnley> FFmpeg has a "simple" fft interface [14:46:17 CEST] <J_Darnley> Other than that the common one people suggest is fftw [14:46:46 CEST] <J_Darnley> And you need more than "double * fft(double *)" for a good fft [14:47:06 CEST] <J_Darnley> (for starters you need a size argument) [15:06:40 CEST] <effractur> Fyr: fftw [15:06:47 CEST] <effractur> Fyr: http://www.fftw.org [16:05:34 CEST] <karab_44> hello! [16:06:06 CEST] <karab_44> How can I vspipe frames with ffmpeg to png? [16:06:26 CEST] <karab_44> I'd like to keep as much original png properties as possible [16:07:11 CEST] <karab_44> All I want to do is to process some png sequence and save as png sequence [16:59:29 CEST] <squack998> hello [16:59:41 CEST] <squack998> i would like to know how to stack commands [17:00:04 CEST] <squack998> for example [17:00:12 CEST] <squack998> ffmpeg -i "http://l3md.shahid.net/media/l3/2fda1d3fd7ab453cad983544e8ed70e4/a86fcc92c9…" -c copy nawaya_s01_e14.ts [17:00:33 CEST] <squack998> then it runs this ffmpeg -i "http://l3md.shahid.net/media/l3/2fda1d3fd7ab453cad983544e8ed70e4/560305293d…" -c copy nawaya_s01_e15.ts [17:00:49 CEST] <squack998> how do i stack them? [17:04:11 CEST] <bencoh> what do you mean by "stack"? [17:04:45 CEST] <bencoh> it sounds like a shell script question [17:09:43 CEST] <squack998> i mean do the first then followed by the second [17:09:48 CEST] <squack998> and so on [17:10:29 CEST] <squack998> is it possible [17:10:32 CEST] <squack998> ? [17:11:08 CEST] <squack998> cause right now i open several ffmpeg and paste same commands of each episode [17:11:38 CEST] <squack998> if i can just run one command to grab ep 1 ep2 and so on easier [17:59:49 CEST] <jfmcarreira> hey guys [17:59:59 CEST] <jfmcarreira> are the GSoC application finished? [18:11:10 CEST] <Filarius> hello, I need to fix issue with A/V sync on livestream recording [18:11:41 CEST] <Filarius> Where is errors for recording, and or re-encoding what I recorded http://pastebin.com/jtYnTB58 [18:12:07 CEST] <flargon> Hi, I have a question about https://trac.ffmpeg.org/wiki/Encode/AAC#NativeFFmpegAACencoder [18:12:40 CEST] <flargon> For AAC (vbr) it says "Effective range for -q:a is around 0.1-2." [18:12:57 CEST] <Filarius> Sample of recoded https://www.dropbox.com/s/yrvlvy2nry1izwk/record.flv (issue at first 6 seconds. Webplayer do not show this issue, try PC player) [18:13:00 CEST] <flargon> But each value gives the same bitrate [20:33:43 CEST] <karab_44> guys I combined some vapoursynth on png 32bit RGBA image sequence and and I have output 64bit RGBA [20:34:08 CEST] <karab_44> how to do that correctly? I want to keep original bitdepth [20:42:10 CEST] <pzich> you want a 64bit video? [20:44:12 CEST] <pzich> by 64bit do you mean 64 bits per channel, or 16 bits per channel, 64 bits per pixel? [20:50:42 CEST] <scoofy> per pixel i guess [20:50:53 CEST] <karab_44> pzich I have originally RGBA 32bit PNG [20:51:11 CEST] <karab_44> after vapoursynth this PNG is RGBA 64bit [20:51:28 CEST] <karab_44> and if I don't include alpha channel it's like RGB 48bit [20:52:05 CEST] <karab_44> and it's originally around 1MB big and after processing it's like quadroople it's size [20:52:23 CEST] <scoofy> definitely. [20:53:26 CEST] <karab_44> why it's 16bit per channel? [20:54:57 CEST] <scoofy> why not [20:55:09 CEST] <karab_44> I want it to keep original preferences because there is no gain or loss on quality I want to keep 32bit RGBA [20:55:22 CEST] <scoofy> sure converting it to 64 bit would mean no improvement [20:55:30 CEST] <karab_44> there is no any [20:57:01 CEST] <karab_44> what can impact on these settings? [20:57:54 CEST] <karab_44> fft = core.fmtc.bitdepth(src, flt=True).fmtc.matrix(mat="601", col_fam=vs.YUV).fmtc.bitdepth(bits=8) [20:57:54 CEST] <karab_44> input = core.fmtc.bitdepth(src, flt=True).fmtc.matrix(mat="601", col_fam=vs.YUV).fmtc.bitdepth(bits=16) [20:58:31 CEST] <karab_44> this is first conversion to YUV css [20:58:58 CEST] <karab_44> then I do some processing and after that I revert the conversion [20:58:59 CEST] <karab_44> ret = core.fmtc.matrix (clip=ret, mat="601", col_fam=vs.RGB) [20:58:59 CEST] <karab_44> ret = core.fmtc.bitdepth (clip=ret,flt=1, dmode=7) [22:10:51 CEST] <dexikiix> Hi all. I have a video file that was corrupted, ran it through "video repair tool" and got an output of good video, but the audio cuts out every second or so, and runs longer than the video and timecode... I'm looking for a way to fix the corrupted bit of the audio, and bring it all in sync with the video, if possible. Any tips? [22:11:11 CEST] <scoofy> extract original video from original file? [22:11:16 CEST] <dexikiix> its an mov and im on win 7 if that helps/matters [22:11:17 CEST] <scoofy> i mean, original audio [22:11:30 CEST] <scoofy> and combine with new video [22:11:47 CEST] <dexikiix> from the corrupted one that wouldn't play? [22:11:52 CEST] <scoofy> yes. [22:11:55 CEST] <dexikiix> ok let me try that [22:11:59 CEST] <scoofy> why not [22:12:10 CEST] <scoofy> at worst, you get an error [22:12:15 CEST] <dexikiix> i tried to extract audio from the newer one, but got a 0kb file, let me grab my command and see what i'm doing wrong [22:14:48 CEST] <dexikiix> ok so i did ffmpeg -i broken.mov -acodec copy fixed.mov and I get "moov atom not found broken.mov: Invalid data found when processing input" [22:15:11 CEST] <scoofy> sounds fux0red [22:15:18 CEST] <dexikiix> prob want an mp3 file anyway, do I need to adjust the command for that or just the filename? [22:15:25 CEST] <scoofy> yet that program could restore it, somehow [22:15:38 CEST] <scoofy> with errors [22:16:12 CEST] <dexikiix> yeah... if only i could get the audio out I could even go into audacity and cut it myselfg [22:16:22 CEST] <scoofy> what format was the audio in? [22:16:24 CEST] <dexikiix> myself* if that was possible [22:16:33 CEST] <scoofy> probably [22:16:35 CEST] <dexikiix> the original file is from a dashcam that saves in mov [22:16:41 CEST] <scoofy> audio codec? [22:16:44 CEST] <dexikiix> hmm [22:16:47 CEST] <dexikiix> let me see if i can find that [22:16:50 CEST] <scoofy> maybe you gotta find out [22:17:00 CEST] <scoofy> and i'll tell you what you might do [22:17:25 CEST] <dexikiix> is that what the probe is for? [22:17:36 CEST] <scoofy> i think that can tell you, yes. [22:18:43 CEST] <dexikiix> pcm_s16le ? [22:19:19 CEST] <dexikiix> 32000 hz 1 channel s16, 512 kb/s (default) [22:19:55 CEST] <dexikiix> that's what I get from the probe... [22:20:50 CEST] <dexikiix> a bit of googling says pcm is "traditional wave format" [22:20:59 CEST] <scoofy> yep. sounds like a format you can read with Audacity! [22:21:08 CEST] <scoofy> maybe you can just open the raw file in audacity [22:21:12 CEST] <scoofy> and try to locate the audio part [22:21:16 CEST] <furq> dexikiix: if you have a working video from the same source you can try using untrunc [22:21:28 CEST] <scoofy> you need to open it as signed, 16 bits - you can try offset 0 or 1 [22:21:31 CEST] <furq> https://github.com/ponchio/untrunc [22:21:35 CEST] <scoofy> set sampling rate to 32 kHz [22:21:40 CEST] <dexikiix> furq, i do, and I will thanks. scoofy, i never even considered that, that could work too [22:22:03 CEST] <scoofy> dexikiix: there may be an 1 byte offset, so you may need to offset the file when opening it as raw audio [22:22:20 CEST] <scoofy> make sure you open it as signed, 16 bit integer. one program that can surely do this, is an old audio editor called 'cool edit'. [22:22:52 CEST] <scoofy> s16 pcm just means raw 16 bit audio. [22:22:59 CEST] <dexikiix> thanks [22:23:06 CEST] <bencoh> furq: it tries to rebuild moov/atom? [22:23:23 CEST] <furq> looks like it [22:23:25 CEST] <furq> i've never had to use it [22:23:37 CEST] <dexikiix> ah crap furq ... hate to be this guy but im not on linux... >.> [22:23:49 CEST] <bencoh> I like the idea behind it (similar working file + broken file) [22:24:10 CEST] <scoofy> dexikiix: in case you open the file in audacity, anything resembling like an audio signal would look not like a block from top to bottom. so look for something that looks different from the rest. [22:24:28 CEST] <furq> you might be able to compile it under msys if you're lucky [22:24:30 CEST] <dexikiix> checking it out now, will do, thanks [22:24:36 CEST] <furq> but it'd probably be quicker to just install linux in a vm or something [22:24:41 CEST] <dexikiix> furq, never tried but i'm willing :) [22:24:47 CEST] <dexikiix> haha fair point [22:24:58 CEST] <dexikiix> can I run something like that through a usb version? [22:25:21 CEST] <furq> if you mean a bootable linux usb stick then sure [22:25:34 CEST] <furq> there's no good reason to not do it in a vm though [22:25:34 CEST] <bencoh> but the debian in virtualbox way is probably simpler [22:25:37 CEST] <furq> yeah [22:26:53 CEST] <furq> compiling linux stuff with msys/cygwin is a bit of a crapshoot [22:27:05 CEST] <dexikiix> alright i' [22:27:17 CEST] <dexikiix> i'll look into that after audacity here. I just got some static from the import [22:27:51 CEST] <furq> i take it your dashcam can't save to a better format which isn't useless if it gets truncated [22:27:58 CEST] <furq> for the future, obviously [22:28:15 CEST] <dexikiix> yeah its a pretty cheap piece of junk [22:28:26 CEST] <dexikiix> but it works [22:28:43 CEST] <dexikiix> does endianness matter? [22:28:48 CEST] <scoofy> yes! [22:28:58 CEST] <scoofy> endianndess and offset both matter. you can try 1 byte offset. [22:29:04 CEST] <scoofy> try all the combinations. [22:29:07 CEST] <dexikiix> ok [22:32:30 CEST] <karab_44> OK I happily found the solution! Thanks guys! [22:33:01 CEST] <dexikiix> dangit, everythings coming out static in audacity [22:33:55 CEST] <dexikiix> ok next step is a vm [22:34:05 CEST] <scoofy> how big is the file? [22:34:26 CEST] <dexikiix> 502 megsd [22:34:27 CEST] <dexikiix> megs* [22:35:16 CEST] <scoofy> i wonder where .mov puts the audio in the file [22:35:26 CEST] <furq> it looks like the arch package builds against ffmpeg 2.8, so a recent debian should work fine [22:35:35 CEST] <furq> i was a bit concerned that the github readme says you need libav [22:36:29 CEST] <furq> https://www.debian.org/devel/debian-installer/ [22:37:14 CEST] <nadermx> is there a config option I have to compile with for ffmpeg to have http_proxy option? [22:37:35 CEST] <c_14> probably just don't disable http [22:39:24 CEST] <furq> nadermx: what ffmpeg version [22:39:29 CEST] <furq> that option was only added in december [22:40:10 CEST] <nadermx> I'm running the most recent version of ffmpeg [22:40:25 CEST] <nadermx> git version 03-01 [22:41:10 CEST] <nadermx> yeah i figure it must be calling a older version so removing and re installing to see why it wasn'tw orking [22:46:16 CEST] <nadermx> its kind of weird, i compiled and ran ffmpeg but when i try to use the proxy its not using it [22:46:19 CEST] <nadermx> ffmpeg version git-2016-03-01-c3bb616 Copyright (c) 2000-2016 the FFmpeg developers [22:47:30 CEST] <nadermx> when i run ffmpeg -protocols shows 'httpproxy' [00:00:00 CEST] --- Mon Apr 4 2016

1 0

ffmpeg-devel.log.20160402
by burek 03 Apr '16

03 Apr '16

[00:21:39 CEST] <Daemon404> michaelni, likely related to the parser change [00:21:51 CEST] <Daemon404> since ac3 and aac share a parser [00:49:31 CEST] <michaelni> ubitux, is ticket 2397 worth a regression test (the sample is 2.5mb) codecpar makes that segfault (as i posted to ML already) while nothing in fate cought that [01:04:50 CEST] <jamrial> michaelni: can't it be cut down a bit? it was created with ffmpeg after all [01:06:56 CEST] <jamrial> use the same command used to create this 4 second sample (first comment in ticket) and make it 1 second or less, for example [01:07:38 CEST] <jamrial> and see if it still segfaults with the current codecpar branch [01:32:25 CEST] <ubitux> michaelni: since it's at least the 2nd time the regression happened, i'd say yes to some test for this [01:55:48 CEST] <michaelni> jamrial, the subtitle display is close to the end of the file so just cutting its duration down wont result in a file with equal coverage [01:56:12 CEST] <michaelni> also the previous problem with the file wasnt a segfault [01:59:34 CEST] <michaelni> i think its no problem to upload the 2.5mb file we have quite a few files that are larger in there, i just always try to keep things small as it adds up [03:25:54 CEST] <jamrial> lol, pastebin is using comic sans [05:10:39 CEST] <Zeranoe> Anyone have a vector (SVG preferably) of the current FFmpeg logo? [06:24:48 CEST] <Daemon404> michaelni, figured thsoe fate failures out. all of fate passes again, with assert-level=2,with your extra check for AV_CODEC_ID_NONE. [06:31:08 CEST] <Daemon404> exit [06:31:10 CEST] <Daemon404> woops [06:31:33 CEST] <Daemon404> ubitux, can you look at that one remaining open problem? (the segfault michael showed you) tomorrow [06:31:42 CEST] Action: Daemon404 sleep [10:39:30 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:d38fe9f4930c: lavf/segment: support automatic bitstream filtering [10:39:30 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:7524b678175e: lavc/audiotoolboxenc: remove unneeded packet metadata [10:39:30 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:c820e600eac4: lavc/audiotoolboxenc: fix a number of config issues [10:39:30 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:0667327f3fc7: lavc/audiotoolboxenc: fix iOS build [10:39:30 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:36770d876937: lavc/audiotoolboxenc: allow setting maxrate with pre-10.9 deployment targets [10:39:31 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:59a44923711b: lavc/audiotoolboxdec: support ADTS AAC input [10:39:31 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:1b9e90ee80be: lavc/audiotoolboxdec: fix a number of config and timestamp issues [10:39:32 CEST] <cone-208> ffmpeg 03Rodger Combs 07master:b4daa2c40fb7: lavc/audiotoolboxdec: add eac3 decoder [14:05:15 CEST] <kierank> I wonder how hard it is to write a simd crc [14:07:58 CEST] <fritsch> kierank: http://www.drdobbs.com/parallel/fast-parallelized-crc-computation-using/229… <- that you already googled, right? [14:08:23 CEST] <kierank> yeah but that's only a special crc [14:08:27 CEST] <kierank> I was thinking more https://www-ssl.intel.com/content/dam/www/public/us/en/documents/white-pape… [14:11:07 CEST] <kierank> ah linux has one as well [14:14:21 CEST] <kierank> probably a lut is faster [16:24:45 CEST] <cone-609> ffmpeg 03Stefano Sabatini 07master:e8a9b644107a: lavu/base64: add AV_BASE64_DECODE_SIZE() macro [17:05:32 CEST] <Daemon404> this parser stuff is pissing me off [17:05:42 CEST] <Daemon404> or rather, ff_read_frame is [17:05:58 CEST] <Daemon404> it changes codecpar info but only wants it carried over sometimes [17:06:04 CEST] <Daemon404> what a piece of shit [17:06:15 CEST] Action: Daemon404 may be getting a little grumpy/burnt out [17:10:04 CEST] <Daemon404> michaelni, if you post regression can you please actually tell me where the sampels are [17:10:13 CEST] <Daemon404> its a little tedious to have to hunt them down [17:14:34 CEST] <wm4> pkt_timebase got to be one of the most broken shit things in libavcodec [17:14:46 CEST] <wm4> setting it randomly messes with timestamps all over the place [17:14:58 CEST] <wm4> but not setting it also means some required features are inaccessible [17:15:21 CEST] <Daemon404> ... ac3-in-wav updates teh coded_id in read_packet [17:15:27 CEST] <Daemon404> sigh [17:15:32 CEST] <Daemon404> wav is not a NOHEADER format [17:16:06 CEST] <wm4> PS: Libav does not have pkt_timebase! what a surprise! [17:16:32 CEST] <wm4> why is everything so broken in ffmpeg [17:17:19 CEST] <nevcairiel> pkt_timebase is actually useful [17:17:30 CEST] <wm4> no it's not [17:17:44 CEST] <nevcairiel> you have a bunch of pkt_ fields that carry timestamps, but no information what they actually are [17:18:15 CEST] <wm4> timestamps are meant to be passed through, and libavcodec can't reasonably "fix" or determine timestamps anyway [17:19:00 CEST] <nevcairiel> watch libav implement something similar, under a different name of course, when they start to care about preskip or tail padding [17:19:19 CEST] <wm4> you don't need pkt_timebase to handle those [17:19:38 CEST] <wm4> (I made sure of it) [17:19:42 CEST] <Daemon404> ah.... fucking spdif [17:25:44 CEST] <Daemon404> michaelni, fixed your sample, sendign a patch to master, since it was a bug in master. [17:26:05 CEST] <Daemon404> p. sure [17:26:28 CEST] <wm4> fixing FATE is often about bug compatibility with ffmpeg itself [17:29:03 CEST] <durandal_170> source without copyright/license is unrelicensable? [17:29:24 CEST] <wm4> durandal_170: no, source without information who wrote it is unlicensable [17:29:27 CEST] <wm4> +re [17:30:09 CEST] <durandal_170> you sure? [17:31:03 CEST] <wm4> unless the author died over 70 years ago [17:31:08 CEST] <Daemon404> (except in the USA) [17:34:37 CEST] <durandal_170> so it can't be open sourced even its source code is available? [17:35:05 CEST] <Daemon404> you cant legally use the code, indeed [17:35:07 CEST] <Daemon404> technically. [17:40:17 CEST] <Daemon404> nevcairiel, mind applying your two OK'd patches, or shall I? [17:42:53 CEST] <wm4> ubitux: do you have a checklist for subtitle API changes somewhere? I'd like to add pts timebase handling to it [17:47:05 CEST] <Daemon404> wm4, do you have time to look at the one outstanding regression (atm) with teh codecpar branch? [17:47:08 CEST] <Daemon404> it's a segfault [17:47:18 CEST] Action: Daemon404 actually has to be somewhere today unfortunately [17:48:38 CEST] <wm4> I can try [17:51:12 CEST] <Daemon404> thanks [17:51:21 CEST] <Daemon404> i think i need a break today or im gonna burn out [17:51:34 CEST] <Daemon404> but it still haunts me to leave it a day with no progress [17:51:39 CEST] Action: Daemon404 is surely in a healthy mindset [17:55:43 CEST] <wm4> time for me to get frustrated lol [17:56:17 CEST] <nevcairiel> time for me to cook lasagna [17:58:10 CEST] <nevcairiel> this whole codecpar concept is extremely fragile, previously it was easy, everything used the same context, and everything was working on the same data. now demuxers write into one struct, parsers read and write from another, and not even to speak of from the decoding during find_stream_info [17:58:35 CEST] <wm4> Daemon404: what is failing? fate appears to pass [17:58:53 CEST] <wm4> nevcairiel: you mean the old code was fragile, and now the shit is even more fragile [17:59:06 CEST] <wm4> (because it needs to be compatible) [17:59:12 CEST] <nevcairiel> right now its extreme shit because parsers dont fit into the design *at all* anymore [17:59:21 CEST] <nevcairiel> this has shit to do with compatibility [17:59:55 CEST] <Daemon404> wm4, look at the 2nd mail to the ML [17:59:58 CEST] <Daemon404> from michael [18:00:11 CEST] <Daemon404> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192439.html [18:00:16 CEST] <wm4> nevcairiel: parsers will be rewritten and everything will be bright and beautiful [18:00:28 CEST] <wm4> except the parser API needs to be compatible too lol [18:00:44 CEST] <wm4> ~/tickets/2397/242_4.mkv [18:00:56 CEST] <wm4> michaelni: direct download http url for this? [18:00:56 CEST] <Daemon404> http://trac.ffmpeg.org/raw-attachment/ticket/2397/242_4.mkv [18:01:04 CEST] <Daemon404> i already hunted it donwq [18:01:04 CEST] <wm4> thanks [18:01:24 CEST] <wm4> can reproduce [18:02:05 CEST] <Daemon404> anyway i have a lunch to get to [18:02:09 CEST] <Daemon404> bbl [18:02:16 CEST] <Daemon404> patch for wav is on the ML [18:04:15 CEST] <nevcairiel> strictly speaking, mpegts is violating the API by changing the codecid there, so maybe we should go all the way and just make mpegts also change it in the internal avctx? =p [18:04:52 CEST] <nevcairiel> no funky random code in read_packet [18:05:26 CEST] <Daemon404> up to yuo :P [18:05:32 CEST] <Daemon404> code / patches welcome [18:05:34 CEST] Action: Daemon404 brb [18:06:53 CEST] <nevcairiel> i need to make myself a diagram how find_stream_infos dataflow actually works [18:09:23 CEST] <wm4> it would be nice if we could somehow hide streams which are incomplete, but can become complete? [18:09:31 CEST] <michaelni> Daemon404, do you still need some files ? i can upload any that arent online/easy findable ? [18:09:32 CEST] <wm4> because that would actually fix the API [18:10:08 CEST] <wm4> (and I don't just mean during find_stream_info) [18:10:53 CEST] <nevcairiel> wm4: in mpegts case, its not clear when its considered "complete" [18:11:12 CEST] <nevcairiel> which is why its annoying [18:11:24 CEST] <wm4> outside of find_stream_info, until all information that can be determined from the .ts is available [18:11:32 CEST] <nevcairiel> in this case, we have st->request_probe, as long as thats positive, it could still change [18:11:37 CEST] <wm4> I'm not sure how much that includes, maybe only codec_id? [18:13:14 CEST] <nevcairiel> the problem cases are not streams which can be unquestionably identified, ie through a pmt mapping or such, but those streams that can't, say because we don't have their stream type in our mapping, or they are designed to use probing because they dont have an "official" stream type [18:13:24 CEST] <wm4> request_probe is documented as "NOT PART OF PUBLIC API" [18:13:38 CEST] <nevcairiel> i'm not concerned with public api at this point =p [18:13:48 CEST] <wm4> true [18:14:09 CEST] <ubitux> hi [18:14:09 CEST] <wm4> a bit over that I see interleaver_chunk_size and interleaver_chunk_duration [18:14:16 CEST] <wm4> not even a doxygen comment... [18:14:45 CEST] <nevcairiel> with any luck there is a big banner somewhere that says that anything below is private [18:14:46 CEST] <ubitux> Daemon404: mmh yeah i could have a look i guess [18:15:11 CEST] <wm4> ubitux: AVSubtitle.pts is in AV_TIME_BASE, and pkt_timebase is used to convert the AVPacket.pts to it, all while the PGS decoder merely reorders pts (and not interpret it) [18:15:13 CEST] <ubitux> wm4: no, no such list, but i think i mentioned it last time on the ml where there is some kind of rfc [18:15:24 CEST] <wm4> nevcairiel: not for these fields [18:15:57 CEST] <wm4> and if pkt_timebase is set, utils.c will make up a value for end_display_time [18:16:03 CEST] <ubitux> wm4: pgs really reorder them? [18:16:12 CEST] <wm4> yes [18:16:14 CEST] <ubitux> i made ccaption dec do something similar iirc [18:16:15 CEST] <nevcairiel> wm4: * All fields below this line are not part of the public API. They [18:16:16 CEST] <wm4> sometimes, rarely [18:16:17 CEST] <nevcairiel> i see the banner [18:16:26 CEST] <ubitux> (no reordering, just delay) [18:16:30 CEST] <ubitux> need to push that patch btw [18:16:34 CEST] <wm4> nevcairiel: oh ok, I got confused then [18:16:41 CEST] <ubitux> wm4: you could make it compute the end duration in such case maybe? [18:17:04 CEST] <wm4> ubitux: it tries to determine end_display_time from the packet duration [18:17:07 CEST] <wm4> which is bogus [18:18:45 CEST] <ubitux> wm4: before i look at this, any additional comment on the ccaption-dec patch and the pkt_timebase fallback for deprecated ass with timing thing? [18:19:27 CEST] <ubitux> wm4: btw, you have a beginning of list/rfc at the end of this mail: http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/191059.html [18:19:34 CEST] <ubitux> if you want to create a wiki page or whatever [18:22:41 CEST] <wm4> ubitux: which captions patch? [18:22:52 CEST] <ubitux> the one you tested the other day [18:23:05 CEST] <wm4> ah [18:23:15 CEST] <wm4> well that's a transition hack anyway? [18:23:17 CEST] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/192260.html [18:23:56 CEST] <ubitux> wm4: let's say it's a consistency correction and simplification instead :) [18:34:32 CEST] <ubitux> anyway, going to push soon [18:56:51 CEST] <wm4> Daemon404: fixed that crash, it was very lame [18:57:16 CEST] <wm4> maybe something to look out for in other code when adding those anti deprecation guards [19:12:26 CEST] <cone-609> ffmpeg 03Clément BSsch 07master:d8620158c7ec: lavc/ccaption_dec: remove usage of avctx->time_base [19:12:27 CEST] <cone-609> ffmpeg 03Clément BSsch 07master:ffd1c3eeb704: lavc/utils: use pkt_timebase for legacy subtitles timing code [19:16:48 CEST] <cone-609> ffmpeg 03Rick Kern 07master:780166947067: lavc/videotoolboxenc: Fix crash when closing codec after error [19:16:49 CEST] <cone-609> ffmpeg 03Rick Kern 07master:c9ad357aeb6a: lavc/videotoolboxenc: Workaround encoder error [20:36:35 CEST] <ubitux> wm4: so is there sth to fix in pgs? [20:37:03 CEST] <wm4> no, with pgs I merely hit this awkward API artifact [20:37:40 CEST] <wm4> see mpv commit 7089175d8d for all the cursing [20:39:38 CEST] <ubitux> aren't you supposed to use av_codec_set_pkt_timebase()? [20:40:12 CEST] <ubitux> btw, you have AV_TIME_BASE_Q [20:42:02 CEST] <ubitux> anyway, what's left in codecpar? [20:44:14 CEST] <JEEB> I think that one thing that michaelni found with ac3-in-wav [20:44:31 CEST] <JEEB> oh, d404 did that already [20:45:39 CEST] <ubitux> fate-vp6a-skip_alpha is failing for me [20:45:55 CEST] <ubitux> fate-samples/flash-vp6/300x180-Scr-f8-056alpha.mov: No such file or directory [20:46:07 CEST] <ubitux> my samples are rsync-ed thoug [20:46:09 CEST] <ubitux> +h [20:46:21 CEST] <wm4> oh, I thought it was uploaded? [20:47:07 CEST] <ubitux> the flv is present [20:47:13 CEST] <wm4> yeah, apparently it wasn't [20:47:13 CEST] <JEEB> vp6 in mov o_O [20:47:40 CEST] <wm4> for now you can: ffmpeg -i fate//flash-vp6/300x180-Scr-f8-056alpha.flv -c copy -flags +bitexact fate/flash-vp6/300x180-Scr-f8-056alpha.mov [21:01:25 CEST] <ubitux> ok so with this codecpar fate passes [21:04:22 CEST] <nevcairiel> the whole codec id/parser topic is still rather ugly, i've been thinking about a cleaner solution but its all iffy [22:27:07 CEST] <jamrial> michaelni: if you haven't made one already, i have an oggopus fate test [22:29:22 CEST] <cone-393> ffmpeg 03Rodger Combs 07master:44a9395b5acf: lavf/segment: style nit [22:29:22 CEST] <cone-393> ffmpeg 03Rodger Combs 07master:5b4f44f66ae3: lavf/segment: slight refactor to seg_write_packet [22:29:22 CEST] <cone-393> ffmpeg 03Rodger Combs 07master:4b150fbe1f39: lavf/segment: add option to write empty filler segments as needed [22:48:26 CEST] <michaelni> jamrial, great, can you post a patch ? ill test on a few platforms [22:50:00 CEST] <jamrial> michaelni: sure [22:55:17 CEST] <jamrial> michaelni: http://pastebin.com/raw/Y6vCbCzR the sample in base64 since it's small [23:04:35 CEST] <jamrial> anyone else getting delivery error emails in korean about some nate.com address every time you send an email to ffmpeg-devel? [23:07:26 CEST] <J_Darnley> No but then I haven't sent one in quite some time. [23:26:20 CEST] <Daemon404> oh good i am tasked with fixing carl broken code for wav [23:26:26 CEST] <Daemon404> even though i only want to move it [23:26:33 CEST] <Daemon404> why was it let in in the first place then [23:26:51 CEST] <Daemon404> and why does it fall on my plate, in order to "fix" codecpar (even though it just happens to kinda work in master) [23:28:21 CEST] <michaelni> Daemon404, moving the ff_spdif_probe() to header is probably fine [23:29:00 CEST] <Daemon404> which header? [23:29:32 CEST] <michaelni> what your patch did mostly, just think it should be a function and not a macro [23:29:49 CEST] <Daemon404> ok [23:29:55 CEST] <Daemon404> that is fine [23:30:10 CEST] <Daemon404> im running low on steam after soloing codecpar for week(s) [23:32:32 CEST] <michaelni> could people please help Daemon404 with codecpar [23:32:46 CEST] <Daemon404> i saw wm4 and ubitux pushed some fixes oday [23:44:02 CEST] <Daemon404> michaelni, new patch on ML. [23:48:36 CEST] <cone-393> ffmpeg 03Hendrik Leppkes 07master:994412fb9b07: avcodec: properly initialize AVCodecParameters profile/level [23:48:37 CEST] <cone-393> ffmpeg 03Hendrik Leppkes 07master:ce87711df563: exif: take a generic log context [00:00:00 CEST] --- Sun Apr 3 2016

1 0

ffmpeg.log.20160402
by burek 03 Apr '16

03 Apr '16

[00:01:13 CEST] <AleXoundOS> I have several tmux panes with ffmpeg running in each. And these additional several characters from new ffmpeg version make "info" line printing new lines, because it doesn't fit inside tmux pane anymore. [00:01:38 CEST] <JEEB> and if you are a carebear enough, feel free to add an option or whatever for it if you really, really want to limit what ffmpeg.c's print_report() does, but as far as I know the output of ffmpeg.c onto the terminal has never been exactly stable [00:02:49 CEST] <AleXoundOS> ok, I understand, thank you for the info [00:04:01 CEST] <llogan> -nostats will omit that last line, but not what you want as far as i can tell [00:05:09 CEST] <AleXoundOS> yeah, -nostats removes the "info" line completely [00:05:27 CEST] <AleXoundOS> I need "info" line, but without "speed" field [00:40:06 CEST] <explodes> av_probe_input_format fails from time to time, has anyone seen this? [00:43:14 CEST] <explodes> It does work sometimes, but other times it causes a SIGSEGV [00:43:23 CEST] <explodes> ..which is bad for us [00:44:07 CEST] <pzich> do you have an error message or stack or something? [00:47:13 CEST] <explodes> :/ I really wish I did [00:47:29 CEST] <explodes> Just a libvsp.so+399 [00:49:40 CEST] <J_Darnley> If you have the input as a file then what does ffmpeg manage to do with it? [00:50:34 CEST] <explodes> I think the problem was that I was omitting AVPROBE_PADDING_SIZE bytes at the end of the buffer .. [00:50:54 CEST] <explodes> Tests are running to completion now, so far.. knockonwood [00:51:03 CEST] <J_Darnley> ah, yes an overread could cause that [04:13:26 CEST] <spiritbro> hi all [04:13:44 CEST] <spiritbro> i want to ask about rtsp streaming in ffserver [04:19:15 CEST] <J_Darnley> My answer to all streaming questions: don't do it. [04:22:17 CEST] <J_Darnley> Damn, missed him. [05:17:58 CEST] <gusto> hey, does here anyone know how to tell ffmpeg with its x11grab which password it should take for a vnc session? I want to open that VNC viewer output [05:36:01 CEST] <DHE> x11grab doesn't use VNC [05:36:08 CEST] <gusto> yes [05:36:17 CEST] <gusto> but it works, I want to grab from another computer [05:36:30 CEST] <gusto> locally it does work, when I start a vncserver, it connects [05:36:31 CEST] <DHE> otherwise it would be called vncgrab [05:41:53 CEST] <gusto> or I could try xnest [05:41:57 CEST] <gusto> maybe a better idea [05:42:36 CEST] <gusto> I mean more like XDMCP, that should work, or not? [05:46:38 CEST] <DHE> for optimal performance you really need ffmpeg running on the same host as the X server to make use of the shared memory extension [05:46:53 CEST] <DHE> if you're doing remote VNC, you might as well use a VNC viewer locally and have ffmpeg record the VNC viewer window [05:47:08 CEST] <DHE> in either case, ffmpeg doesn't get involved in the VNC password [05:47:11 CEST] <gusto> well [05:47:36 CEST] <gusto> ok, that one with the window is not a bad idea, but how do I tell ffmpeg to record a window? VLC can do it, but ffmpeg? [05:49:30 CEST] <DHE> yeah the manual doesn't suggest how you would do it without specifying exact pixel offsets [05:50:09 CEST] <gusto> pixel offsets are not useful, because when you draw another window over it or you change the virtual desktops, it goes somewhere else [09:36:36 CEST] <AleXoundOS> Hi. I user several instances of ffmpeg running at the same time. Which type of build will use less RAM in my case: static or shared? Maybe with shared type shared libraries will be loaded in memory only once? Or it doesn't matter? [09:36:40 CEST] <AleXoundOS> use* [09:37:04 CEST] <scoofy> probably [09:37:08 CEST] <AleXoundOS> (I use linux) [09:38:14 CEST] <scoofy> in static, each instance would load its copy of the libs [09:38:20 CEST] <scoofy> try dinamic / shared lib [09:38:32 CEST] <AleXoundOS> ok, thank you [12:25:13 CEST] <Gegsite> hello [12:25:22 CEST] <Gegsite> would like to convert an mkv to avi [12:26:03 CEST] <Gegsite> ffmpeg did it with -i input.mkv output.avi but the quality is pretty bad [12:26:32 CEST] <Gegsite> it made 300 Mb avi from an 1,5 GB mkv [12:32:48 CEST] <Gegsite> it say bitrate= 226 kbits/s [12:32:57 CEST] <Gegsite> should be 1500.... how? [12:33:41 CEST] <Mavrik> pass the video bitrate parameter :) [12:34:30 CEST] <Gegsite> -b:v 2000 does nothing [12:34:53 CEST] <Mavrik> 2000k [12:34:58 CEST] <Mavrik> It's in bits/s [12:35:10 CEST] <Mavrik> So if you want 2000kbits/s you need to set -b:v 2000k [12:35:20 CEST] <Gegsite> oh.. :P thanks Mavrik [13:09:07 CEST] <VVelox> -threads 0 is the same as -threads auto? [13:10:01 CEST] <J_Darnley> No. [13:10:21 CEST] <J_Darnley> 0 is used by libx264 to mean "auto" [13:10:33 CEST] <J_Darnley> other codecs may not autodetect [13:11:06 CEST] <VVelox> So if I want to use auto there, I would need to specify auto? [13:11:11 CEST] <J_Darnley> no [13:11:19 CEST] <furq> is there even an auto option [13:11:21 CEST] <J_Darnley> it has an integer argument [13:11:43 CEST] <VVelox> furq: If I am reading -h full right there seems to be [13:11:58 CEST] <furq> -threads <int> ED.VA... (from 0 to INT_MAX) (default 1) [13:11:58 CEST] <furq> auto ED.V.... autodetect a suitable number of threads to use [13:12:01 CEST] <furq> so there is [13:12:40 CEST] <J_Darnley> Nice, "just" a special case in option parsing [13:13:24 CEST] <furq> i don't know whether that works anywhere that 0 doesn't [13:13:34 CEST] <furq> i assume it must do [14:29:36 CEST] <satinder___> Hi , my question is very simple , Can we integrate complete ffmpeg with our C program I mean can we create single binary of my C program with including ffmpeg source [14:29:37 CEST] <satinder___> any can please help [14:33:12 CEST] <VVelox> Sounds like you are looking for info on libav. [14:34:37 CEST] <c_14> satinder___: so long as you follow the requirements set by the (L)GPL and don't link against a non-free build of FFmpeg it should be fine. (note, I am not a lawyer) [14:35:25 CEST] <ln-> my crystall ball tells me following the requirements of (L)GPL is not an option in satinder___'s case [14:36:26 CEST] <Mavrik> It's possible to statically link LGPL with non-GPL code, but it's fun to keep compliant :) [14:40:27 CEST] <JEEB> Mavrik: you usually say it the other way :D you're opening a can of worms with saying it that way [14:40:38 CEST] <JEEB> you have a closed source thing and you link LGPL to it [14:40:48 CEST] <Mavrik> Oh yes, that's what I meant :) [14:41:35 CEST] <JEEB> basically there was a discussion about linking against nonfree libs for an LGPL configuration but I don't think we got j-b or his lawyer army to comment [14:45:36 CEST] <Mavrik> Mhm, last time I checked you'd have to provide object files so people could relink the binary with another set of libav libs. [14:47:19 CEST] <JEEB> yes, that is how it goes with a closed source thing linking LGPL statically [14:47:37 CEST] <JEEB> this is regarding LGPL libav* linking against closed source stuff [14:47:47 CEST] <JEEB> which comes from f.ex. drivers [14:55:05 CEST] <satinder___> ok [15:01:57 CEST] <satinder___> Actually I am trying but there is some api issues undefined errors [15:02:29 CEST] <satinder___> I change ffmpeg main function to ffmpeg_emb_main and call it from my c program [15:02:47 CEST] <satinder___> so I what I am doing wrong [15:14:35 CEST] <BtbN> ffmpeg.c is not designed to work as a library, because it isn't one. [15:20:40 CEST] <satinder___> ok [15:21:14 CEST] <satinder___> BtbN : then how I can use ffmpeg in my c program [15:21:30 CEST] <JEEB> use the actual public APIs [15:21:49 CEST] <JEEB> libavformat|libavcodec etc [15:21:58 CEST] <JEEB> or you just call the ffmpeg application itself :P [15:22:11 CEST] <JEEB> if you want all the quirks and ugh related to ffmpeg.c [15:22:30 CEST] <BtbN> also avoids a lot of licensing issues if you just ship a ffmpeg executable binary. [15:22:41 CEST] <BtbN> If that's enough for your usecase [15:29:42 CEST] <satinder___> BtbN : no sir I want single binary of my program including ffmpeg [15:30:20 CEST] <BtbN> use the official APIs then, and link staticaly. [15:32:21 CEST] <satinder___> BtbN : but their have not ffmpeg functionality [15:32:36 CEST] <satinder___> I want add whole ffmpeg [15:32:52 CEST] <BtbN> Good luck with turning ffmpeg.c in a library then. [15:33:26 CEST] <satinder___> ok [15:33:30 CEST] <satinder___> sir [15:33:36 CEST] <satinder___> thanks [15:36:52 CEST] <J_Darnley> Oh I forgot I had that guy on my ignore list. Suddenly this sequence of messages makes a little more sense. [16:32:50 CEST] <satinder___> how we can pass command line arguments to ffmpeg.c [16:32:55 CEST] <satinder___> from c program [16:33:37 CEST] <J_Darnley> system() [16:33:47 CEST] <satinder___> I change the name of ffmpeg.c main function main to emb_main [16:33:57 CEST] <JEEB> J_Darnley: put him back on your ignore list, simpler that way :P [16:34:01 CEST] <satinder___> and calling it from my c program [16:34:12 CEST] <JEEB> if he wants to do this and it doesn't work, it is not our responsibility to help [16:34:18 CEST] <JEEB> he can keep both sides [16:34:21 CEST] <TD-Linux> satinder___, it's not a supported way of using ffmpeg. you won't get any help with that method here [16:34:30 CEST] <satinder___> ok sir [16:34:43 CEST] <satinder___> thanks [19:36:05 CEST] <agrathwohl> Hello, I am testing out the 3.0 release of FFmpeg and am interested in trying out the Common Encryption MP4 support. However, when looking over the manual on ffmpeg.org I was unable to find any documentation on how to get started. Is there any resource out there that shows how to encode MP4s with CENC? Thank you! [19:36:38 CEST] <JEEB> there are movenc options for that [19:37:22 CEST] <JEEB> hmm [19:37:30 CEST] <JEEB> wonder why it's not listed in ffmpeg-all.html [19:38:00 CEST] <JEEB> I have tried using it through the API earlier, and it seemed to succeed [19:38:27 CEST] <c_14> Probably nobody wrote docs for it, they're listed in ffmpeg -h muxer=mov though (-encryption_scheme etc) [19:38:41 CEST] <JEEB> right [19:39:10 CEST] <JEEB> I would have thought the doc creation thing looks at all of the defined options :) [19:39:22 CEST] <c_14> It doesn't, only the internal help does [19:39:31 CEST] <JEEB> aye [19:42:20 CEST] <agrathwohl> Oh, I see now. Thank you for the help c_14 and JEEB [00:00:00 CEST] --- Sun Apr 3 2016

1 0

ffmpeg-devel.log.20160401
by burek 02 Apr '16

02 Apr '16

[00:00:04 CEST] <Daemon404> michaelni, if im not around mail me them, or putthem on github or something [00:01:11 CEST] <michaelni> ok, i probably wont have time tomorrow for testing but ill try to test more after that [00:01:34 CEST] <Daemon404> its not going to be ready to merge tomorrow lol. [00:02:04 CEST] <Daemon404> i was aiming for sunday or monday next week. [00:02:14 CEST] Action: michaelni is afraid that it gets pushed without more testing, i think there are quite a few issues left in it [00:02:43 CEST] <Daemon404> i need to put it over git master before anything else [00:03:40 CEST] <Daemon404> then ti can be tested, but at some point it should be merged [00:03:51 CEST] Action: Daemon404 is not a fan of infinite testing [00:04:09 CEST] <Daemon404> and im not sure users will spend much time testing non-master [00:06:57 CEST] <michaelni> btw was the assertion failure fixed ? [00:07:07 CEST] <Daemon404> no its on my todo [00:07:13 CEST] <michaelni> ahh k [00:07:15 CEST] <Daemon404> see: [22:56] <@Daemon404> im not doing any fixes today though, im beat. [00:54:40 CEST] <Timothy_Gu> anybody actually at MS Build? [00:58:23 CEST] <kierank> some vlc guys are [00:58:29 CEST] <kierank> so j-b I guess [02:07:43 CEST] <kierank> dammit work assembly [02:09:40 CEST] <j-b> Timothy_Gu: I am there, yes. [02:14:36 CEST] <kierank> Gramner: have I got the semantics of palignr wrong? [02:14:37 CEST] <kierank> palignr m2, m0, m4, 6 [02:14:53 CEST] <kierank> it does m4 concated witht m0 [02:14:57 CEST] <kierank> shifts 6 bytes right [02:14:58 CEST] <kierank> and stores in m2 [02:15:18 CEST] <kierank> it doesn't do the same as the equivalent movu from memory [02:18:44 CEST] <kierank> i.e [02:18:51 CEST] <kierank> mova m0, [r0] [02:18:51 CEST] <kierank> mova m4, [r0+mmsize] [02:18:51 CEST] <kierank> palignr m2, m0, m4, 6 [02:19:01 CEST] <kierank> I expect m2 to be the same as movu [r0+10] [02:31:36 CEST] <BBB> kierank: I believe its the other way around [02:31:45 CEST] <BBB> kierank: so palignr m2, m4, m0, 6 [02:31:57 CEST] <BBB> it makes more sense in the inverse at&t syntax [02:32:24 CEST] <kierank> m2, m4, m0, 10 works for me [02:32:29 CEST] <kierank> which I don't understand at all [02:32:45 CEST] <kierank> but thanks [02:32:57 CEST] <BBB> oh, maybe it was 10, yes [02:33:07 CEST] <BBB> anyway, yes palignr is very confusing [02:33:12 CEST] <BBB> I always get it wrong the first time [02:33:19 CEST] <BBB> which isw hy I dont use it very much :-p [02:41:27 CEST] <kierank> I don't understand why the c is of a similar speed still though [02:41:30 CEST] <kierank> perhaps a problem for tomorrow [02:44:45 CEST] <kierank> hmm perf says all the time is spent in vpalig [02:46:36 CEST] <jamrial> what's your cpu? palignr is slow in some arches and relatively fast in others [02:46:47 CEST] <kierank> haswell [02:47:02 CEST] <kierank> on my sandy bridge laptop the function is about twice as fast [02:47:09 CEST] <kierank> on haswell it's about the same as the c [02:47:23 CEST] <jamrial> yeah, palignr is slower on haswell than sandy/ivy [02:47:39 CEST] <jamrial> shouldn't be that bad, though [02:48:59 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/n5KCHRE5/ [02:49:02 CEST] <kierank> looks like that [02:58:08 CEST] <kierank> a shuffle and blend might be better [02:58:15 CEST] <kierank> but I will find out at a sane hour [03:02:57 CEST] <rcombs> is that a CPU instruction or a dance move [03:14:22 CEST] <kierank> probably better to do a single shuffle for luma and chroma and mask after [03:17:45 CEST] <jamrial> why not just do an unaligned load instead of aligned load + palignr? [03:18:32 CEST] <jamrial> alternatively shift + or to emulate palignr [04:21:37 CEST] <BBB> emulate palignr is terrible, but movu should be ok, yes [05:24:34 CEST] <Daemon404> oh good, im sure no trolls will respond to the codecpar mail with a link to a WIP tree on the ML [05:24:38 CEST] <Daemon404> especially not carl [05:24:58 CEST] <Daemon404> this cant possibly backfire. [08:11:08 CEST] <wm4> lol 48h wait? [08:11:16 CEST] <wm4> we've waited for weeks [08:11:38 CEST] <wm4> at this rate it'll never get merged [09:02:33 CEST] <durandal_1707> no need to wait [09:45:40 CEST] <Gramner> kierank: you should store constants in registers instead of using memory operands in every instruction. it will make things faster on many cpu:s and reduces code size. weird that palignr is slow on haswell though, I know it's garbage on some older amd µarchs but it has the same latency/throughput as any other shuffle instruction on haswell [09:45:50 CEST] <Gramner> 1/1 [09:46:26 CEST] <kierank> It doesn't seem to be palignr actually because when I removed it, the function was slow still [09:47:10 CEST] <Gramner> start with avoiding memory operands everywhere then and see what happens [09:48:09 CEST] <Gramner> modern intel µarchs is generall ok with tons of memory loads though, but some other µarchs not so much. [10:16:06 CEST] <Gramner> here's a more sensible palignr visualization btw https://i.imgur.com/35VrZ8C.png [10:38:50 CEST] <kierank> Gramner: putting the masks in registers seems to make it faster but loading too much stuff makes it slow [10:39:22 CEST] <kierank> oh wait [10:39:23 CEST] <kierank> ignore me [10:40:00 CEST] <funman> /ignore kierank [10:40:33 CEST] <Gramner> also, that functions only does one line right? changing it to process one frame at a time would make stuff faster since you'd avoid the overhead of the function call + function prologue for each input line [10:41:25 CEST] <kierank> that's not trivial because of the edge cases [10:41:40 CEST] <kierank> and also because I process 3 v210 "blocks" at a time currently [10:42:51 CEST] <kierank> Gramner: http://pastebin.com/qPk9rTRX [10:43:00 CEST] <kierank> (lol gone comic sans) [10:43:40 CEST] <kierank> the multiplies are permutations of each other but not simple ones [10:45:37 CEST] <Gramner> luma/chroma masks seems indentical except inverted. you could simply use only the chroma mask and go with pandn instead of pand for luma (this is what x264 does iirc) [10:45:56 CEST] <kierank> they aren't quite inverted actually [10:49:34 CEST] <kierank> technically the x264 code is wrong [10:50:31 CEST] <Gramner> it is? [10:51:30 CEST] <kierank> the masks aren't the exact inverse of each other [10:51:47 CEST] <kierank> because you need to mask out the two unused bits per uint32_t for both components [10:52:06 CEST] <kierank> those bits are undefined so they could be set and then break your pmulhrsw [10:53:37 CEST] <Gramner> the checkasm test in x264 uses completely random data as input, and it passes [10:54:07 CEST] <Gramner> no bits in the input that are explicitly set to zero beforehand [10:55:39 CEST] <kierank> I see [10:55:39 CEST] <Gramner> those bits are shuffled out by pshufb i think [11:01:42 CEST] <kierank> no much change still [11:05:10 CEST] <Gramner> the code is quite shuffle-heavy (and unavoidably so). sandy/ivy has 3 scalar execution units and 2 shuffle ones. haswell has 4 scalar and 1 shuffle [11:05:31 CEST] <Gramner> it's going to perform worse compared to c on haswell than on sandy/ivy [11:05:52 CEST] <Gramner> i think it should still be faster than scalar though [11:05:59 CEST] <Gramner> what are the numbers? [11:07:18 CEST] <Gramner> I don't know why Intel decidec to murder shuffle performance on haswell. and it's the same on skylake [11:15:11 CEST] <dinux5> What is "validating a bitstream" ? [11:19:33 CEST] <Gramner> kierank: oh, and there's no point in having an "aligned" avx version since movdqu when used on aligned data has the same performance as movdqa on all cpus with avx. might even be that case with ssse3 but I don't know for sure [11:21:47 CEST] <kierank> asm 56991880 decicycles in abcd, 2048 runs, 0 skips [11:21:48 CEST] <kierank> c 52278297 decicycles in abcd, 2048 runs, 0 skips [11:24:09 CEST] <Gramner> with what width (e.g. how many loop iterations in the asm)? [11:25:13 CEST] <kierank> that's per frame [11:32:35 CEST] <ubitux> kierank: isn't the c simdified by gcc? [11:33:50 CEST] <ubitux> mmh apparently not [11:41:29 CEST] <Gramner> weird that it's so slow compared to c. compare it to the v210 asm in x264 which is quite similar (load, pand, pshufb, pmulhrsw) [11:41:34 CEST] <Gramner> plane_copy_deinterleave_v210_c: 20550 [11:41:34 CEST] <Gramner> plane_copy_deinterleave_v210_ssse3: 4672 [11:41:34 CEST] <Gramner> plane_copy_deinterleave_v210_avx2: 3373 [11:42:37 CEST] <kierank> http://paste.ubuntu.com/15575417/ [11:42:46 CEST] <kierank> on top of https://github.com/kierank/ffmpeg-sdi [11:43:04 CEST] <kierank> yes it's so slow for some reason [11:43:30 CEST] <kierank> ./ffmpeg_g -f v210 -s 1920x1080 -i /dev/zero -f rawvideo -y /dev/null [11:47:18 CEST] <ubitux> you should try something different than zero, maybe it's affecting the prediction somehow [11:47:59 CEST] <ubitux> there is no branching though [11:54:55 CEST] <Gramner> put the timer around just the function pointer call to get rid of the overhead/noise of all the other code [12:00:35 CEST] <kierank> asm 56479 decicycles in abcd, 2047 runs, 1 skips [12:00:49 CEST] <kierank> actually [12:00:51 CEST] <kierank> asm 50214 decicycles in abcd, 65526 runs, 10 skips [12:01:01 CEST] <kierank> c 48170 decicycles in abcd, 65524 runs, 12 skips [12:51:58 CEST] <kierank> There must be something I can do to make it faster [12:58:33 CEST] <cone-543> ffmpeg 03wm4 07master:f099cb2f8a51: lavu: improve documentation of some AVFrame functions [12:58:33 CEST] <cone-543> ffmpeg 03wm4 07master:a5f5b8b96a97: lavc: factor apply_param_change() AV_EF_EXPLODE handling [13:24:12 CEST] <Gramner> kierank: the asm is faster for me on haswell (pulled from your github + applied the patch you linked). [13:24:16 CEST] <Gramner> 53030040 decicycles in abcd, 256 runs, 0 skips (c) [13:24:16 CEST] <Gramner> 36980280 decicycles in abcd, 2048 runs, 0 skips (asm) [13:24:54 CEST] <Gramner> oh, copied the 256 runs for c, but it's consistently the same anyway [13:29:41 CEST] <kierank> Gramner: what command are you using [13:29:52 CEST] <kierank> I guess I could be getting burnt by cpu throttling or something [13:30:10 CEST] <Gramner> the same as you used [13:32:00 CEST] <kierank> very strange [13:32:11 CEST] <kierank> I am on Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz [13:32:45 CEST] <Gramner> "Genuine Intel(R) CPU 0000 @ 2.80GHz" <- them ES naming schemes [13:38:13 CEST] <kierank> Gramner: so strange [13:38:44 CEST] <kierank> but thanks [13:39:59 CEST] <Gramner> 50k vs 33k cycles with just the function pointer call [13:40:18 CEST] <Gramner> decicycles* [13:46:16 CEST] <Gramner> or did the compiler you used auto-vectorize the c? [13:46:25 CEST] <Gramner> i have a somewhat older gcc on this machine [13:47:23 CEST] <Gramner> 4.8.4 to be precise [13:47:53 CEST] <kierank> not vectorised on my machine [13:48:32 CEST] <kierank> ah is it running the uyvy code? [13:48:49 CEST] <kierank> i.e is the output uyvy42210? [13:49:01 CEST] <kierank> it might be using the planar code [13:50:16 CEST] <kierank> hmm on another haswell I can replicate your results [13:50:17 CEST] <kierank> wtf [13:51:26 CEST] <Gramner> oh wait didn't you have some super weird performance issues before with one of your machines? i vaguely remember discussing that. it's not _that_ machine is it? [13:52:51 CEST] <kierank> Ah, no that was a machine which had two PSUs and if one of them was disconnected, the CPU silently downclocked unbeknownst to the OS [13:53:15 CEST] <Gramner> ah ok [13:56:21 CEST] <Gramner> you didn't accidentally make some change in the asm on the machine that it's slow on compared to the other one? [13:59:56 CEST] <kierank> I will try with a clean clean build [14:03:23 CEST] <kierank> let me try on a xeon e5 [14:04:13 CEST] <Gramner> you can get rid of half of the pmulhrsw instructions btw if you do the or before [14:06:07 CEST] <kierank> yeah faster on the e5 haswell as well [14:07:47 CEST] <kierank> hmm that's a good idea [14:40:48 CEST] <Gramner> kierank: maybe something like this (untested if it's actually correct, but the concept of it) http://pastebin.com/th4twbq1 [14:41:18 CEST] <kierank> thanks, was going to write that later [14:59:19 CEST] <cbsrobot> kierank: on Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz [14:59:31 CEST] <cbsrobot> 25354510 decicycles in abcd, 4096 runs, 0 skips (asm) [14:59:43 CEST] <cbsrobot> 49719353 decicycles in abcd, 4096 runs, 0 skips (c) [14:59:53 CEST] <kierank> thanks, something odd about my e3 haswell it seems [15:00:03 CEST] <Gramner> that's ivy bridge though I assume [15:00:09 CEST] <kierank> yes [15:53:07 CEST] Action: ubitux likes the cbz/cbnz/tbz/tbnz instructions [17:08:20 CEST] <Daemon404> michaelni, [17:08:20 CEST] <Daemon404> [concat @ 0x3b023c0] Unsafe file name '/home/daemon404/dev/f/codecpar/10secMov.mov' [17:08:23 CEST] <Daemon404> concatfile.txt: Operation not permitted [17:08:26 CEST] <Daemon404> ^ git head [17:08:51 CEST] <Daemon404> i suppose it mus tbe relative or something [17:09:35 CEST] <Daemon404> seems so. [17:09:36 CEST] <Daemon404> nvm [17:09:36 CEST] <durandal_1707> why you use concat? [17:10:23 CEST] <Daemon404> because michaelni reported a regression [17:10:30 CEST] <Daemon404> i would not use it myself. [17:14:26 CEST] <Daemon404> nevcairiel, why was it you had concat.c listed at one point on the etherpad? [17:14:38 CEST] <Daemon404> nothing changed in it [17:14:41 CEST] <Daemon404> seems bsf related [17:14:56 CEST] <nevcairiel> the bsf stuff seemed broken in it and failed in tests [17:15:14 CEST] <Daemon404> i left it sitll using st->codec [17:15:14 CEST] <nevcairiel> how it uses bsf seems questionable either way [17:15:26 CEST] <Daemon404> bsf in utils.c uses the deprecated api [17:15:36 CEST] <Daemon404> where does it? [17:15:48 CEST] <Daemon404> concat.c looks incredibly trivial [17:15:55 CEST] <nevcairiel> i wonder if it wont stop working if we change ffmpeg.c to codecpar [17:16:04 CEST] <nevcairiel> because st->codec is literally empty then [17:16:17 CEST] <Daemon404> one solution is to merge the new bsf api first. [17:17:04 CEST] <nevcairiel> concat is a demuxer, so you could use the internal avctx temporarily [17:17:11 CEST] <Daemon404> oh silly me [17:17:12 CEST] <Daemon404> im retarded [17:17:17 CEST] <Daemon404> i was lookign at concat.c [17:17:19 CEST] <Daemon404> not concatdec.c [17:17:22 CEST] <Daemon404> the problem is obvious now. [17:17:39 CEST] <Daemon404> internal avctx is not good enough for the bistream filters [17:17:42 CEST] <Daemon404> thats why i didnt change utils.c [17:17:50 CEST] <Daemon404> waiting on the new bsf api and wil lchange it then [17:19:39 CEST] <JEEB> :) [17:20:43 CEST] <Daemon404> yeah switching back from internal avctx to st->codec fixes it. [17:20:56 CEST] <Daemon404> nevcairiel, are you ok with waiting for the new api to fix the uses? [17:21:00 CEST] <Daemon404> seems like teh sanest thing to do [17:21:32 CEST] <ubitux> Daemon404: yes, relative path or use the -safe option [17:21:34 CEST] <nevcairiel> probably fine [17:21:50 CEST] <Daemon404> ill switch tee.c back too [17:22:28 CEST] <Daemon404> ubitux, it worked when i gave it absolute path that had a file in the same dir as CWD [17:22:33 CEST] <Daemon404> hence my confusio [17:22:34 CEST] <Daemon404> n [17:25:05 CEST] Action: Daemon404 runs fate now with assert-level=2 [17:25:23 CEST] <Daemon404> it's a shame ffmpeg doesnt have somethign similar to libav's oracle [17:25:26 CEST] <Daemon404> would be useful [17:27:17 CEST] <wm4> this fork bullshit is just a huge load of bullshit [17:27:31 CEST] <Daemon404> settle down now [17:28:46 CEST] <Daemon404> it's too early in the day for flames, for me [17:29:22 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:11b4acab8b67: swscale/arm/yuv2rgb: remove 32bit code path [17:29:22 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:466e209e6efb: swscale/arm/yuv2rgb: fix comments in load_args_yuv422p [17:29:22 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:b3ea901945c8: swscale/arm/yuv2rgb: factorize lsl in load_args_yuv422p [17:29:22 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:2aec59c07cec: swscale/arm/yuv2rgb: remove unused store of dst + linesize in load_args_yuv422p [17:29:22 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:0649fe0fae96: swscale/arm/yuv2rgb: factorize lsl in load_args_yuv420p [17:29:22 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:0286b56f2fa5: swscale/arm/yuv2rgb: factorize lsl in load_args_nvx [17:29:22 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:562653b7317d: swscale/arm/yuv2rgb: macro-ify [17:29:23 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:ff4885facee0: swscale/arm/yuv2rgb: rename {process_1l,process_2l,compute}_16px{,_internal} macros [17:29:24 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:339668301e45: swscale/arm/yuv2rgb: re-order compute_rgba macro arguments [17:29:25 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:5629361cc24d: swscale/arm/yuv2rgb: save a few instructions by processing the luma line interleaved [17:29:26 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:58994d7bca27: swscale/arm/yuv2rgb: make the code bitexact with its aarch64 counter part [17:29:54 CEST] <Daemon404> i should remember do disable docs more often [17:30:01 CEST] <Daemon404> it's the longest job of the build process [17:32:26 CEST] <Daemon404> is there something that ffmpeg started doing differently for its cli lately? [17:32:36 CEST] <Daemon404> whenever ffmpeg crashes or asserts i have to reset my terminal [17:32:41 CEST] <Daemon404> or characters i type are invisible [17:33:09 CEST] <nevcairiel> someone tried to "improve" it, probably got worse in the process, you know how it does [17:33:11 CEST] <nevcairiel> goes* [17:33:16 CEST] <cone-283> ffmpeg 03Clément BSsch 07master:eadaef2a63fe: sws/aarch64: disable ff_hscale_8_to_15_neon temporarly [17:33:36 CEST] <nevcairiel> someone argued that it cant be fixed in 100% of the cases anyway, so lets just leave it as broken as possible [17:34:00 CEST] <Daemon404> oh good. [17:34:09 CEST] <Daemon404> and yeah it never used to do this. [17:36:19 CEST] <cone-283> ffmpeg 03Aaron Boxer 07master:b6b4b0a65e02: avcodec/j2kenc: Add attribution to OpenJPEG project: [17:36:28 CEST] <BBB> why would cmp xd, r6m give me error: label or instruction expected at start of line? [17:42:07 CEST] <BBB> whats wrong with the fork tis time? [17:45:07 CEST] <omerjerk> hey can anyone help me with some doubt regarding ALS decoder ? [17:45:23 CEST] <omerjerk> I'm almost done with the qualification task [17:45:48 CEST] <omerjerk> Just stuck a bit at final reconstruction of the floating point number. [17:46:26 CEST] <omerjerk> So, has anyone dealt with ALS before here ? :) [17:46:30 CEST] <omerjerk> thanks in advance. [17:51:49 CEST] <michaelni> Daemon404, nicolas posted some shell magic to fix the term messups (and i would prefer it wasnt needed but i think no solution was found that everyone liked) [17:52:39 CEST] <wm4> I don't understand why ffmpeg messes with the terminal at all [17:54:03 CEST] <Daemon404> it probably has something to do with printing status [17:54:18 CEST] <Daemon404> michaelni, where can i find this? [17:55:03 CEST] <michaelni> its for handling things like q uit , chaning verbosity, dislpaying qp histograms, sending messages to filters, dumping packets as hex on a keypress cycle through debug modes ... (just press ? to see a list of keys for ffmpeg while it runs) [17:56:17 CEST] <michaelni> i have to find the mail but for bash it was: bash_tty_mode=$(stty -g) \n PROMPT_COMMAND='stty $bash_tty_mode' [17:56:37 CEST] <Daemon404> all right [17:59:40 CEST] <michaelni> not sure theres a mail where its all summarized, there are multiple mails from nicolas where taks about the issue [18:00:15 CEST] <michaelni> easy to find when searching for something like stty in the body and nicolas in from [18:00:54 CEST] <Daemon404> is tehre an easy way to match a codec id to a name? [18:01:01 CEST] <Daemon404> find_decoder and find_encoder fail with 100359 [18:01:50 CEST] <wm4> gdb, print (AVCodecID)100359 [18:01:59 CEST] <Daemon404> ah [18:01:59 CEST] <michaelni> avcodec_get_name() [18:02:50 CEST] <Daemon404> bin_data [18:02:55 CEST] <Daemon404> fun... [18:08:16 CEST] <durandal_1707> omerjerk: what's problem? [18:11:20 CEST] <omerjerk> wait, [18:11:23 CEST] <omerjerk> posting the question [18:13:39 CEST] <omerjerk> http://i.imgur.com/T3pQdUI.png [18:13:56 CEST] <omerjerk> I'm getting confused at the point 11.6.9.3.3.2 [18:14:19 CEST] <omerjerk> I've written rest of the code, which includes decoding of the difference singal. [18:14:42 CEST] <omerjerk> What I'm not getting is, why do we need to multiply truncated integer to 2^-23 [18:15:03 CEST] <omerjerk> I can't see any code like that in the source code of the reference software. [18:16:30 CEST] <omerjerk> Also, I'm maintaining my code here - https://github.com/omerjerk/FFmpeg/commits/float [18:17:33 CEST] <wm4> that's equivalent to shifting, isn't it [18:17:52 CEST] <wm4> to bring something like a [0..2^23] range to [-1..1] or whatever? [18:18:08 CEST] <wm4> well my example is wrong but whatever [18:18:30 CEST] <omerjerk> aah. [18:18:32 CEST] <omerjerk> okay. [18:18:41 CEST] <omerjerk> this makes sense. [18:21:35 CEST] Action: Daemon404 stabs mpegts.c [18:28:12 CEST] <Daemon404> this is so insane [18:28:18 CEST] <Daemon404> how did this ever work [18:31:22 CEST] <Gramner> those code segments are the best. things that are clearly wrong but somehow works anyway and ideally breaks everything or makes things worse when they are fixed [18:32:44 CEST] <Gramner> usually because of 3 other bugs and the combination of those by pure chance makes things work out in the end [18:33:16 CEST] <Daemon404> seems like this, yes [18:34:45 CEST] <ethe> wm4: how would you do that? x-((2^23)/2)/(2^23)? [18:37:44 CEST] <Daemon404> michaelni, ping [18:38:00 CEST] <Daemon404> is dts supposed to be detected as STREAM_TYPE_PRIVATE_DATA (6) [18:38:30 CEST] <Daemon404> it's always setting teh coded_id as bin_data. it only worked before because it was allowed to modify it later back to CODEC_ID_NONE [18:38:33 CEST] <Daemon404> which is all sorts of weird [18:39:25 CEST] <michaelni> the request_probe system is mandatory for mpeg-ts/ps [18:39:42 CEST] <michaelni> i dont know of my head what dts sets [18:39:45 CEST] <Daemon404> trying to figure out how it works [18:39:56 CEST] <Daemon404> it used to call the parser with avctx->codec_id as NONE, and it happened to work since one of the parser coded ids is always NONE [18:40:03 CEST] <Daemon404> (it failed to match it as DCA) [18:40:13 CEST] <Daemon404> im not sure if that is even intended behavior [18:40:34 CEST] <Daemon404> request_probe is working fine [18:40:48 CEST] <michaelni> the parsers should only be run over the data after the codec is identified IIRC [18:40:48 CEST] <Daemon404> it's just the initial call to parser which is triggering that [18:40:59 CEST] <Daemon404> right [18:41:10 CEST] <Daemon404> but even in git master/HEAD it calls it twice with CODEC_ID_NONE [18:41:29 CEST] <Daemon404> which happens to work since parser->coded_id[i] where i > 0 is 0. [18:41:44 CEST] <michaelni> that sounds like a bug [18:41:55 CEST] <Daemon404> thats my thinking too. [18:43:29 CEST] <Daemon404> let me poke it a bit more [18:45:27 CEST] <Daemon404> i might be mistaken [18:49:07 CEST] <michaelni> hmm, av_parser_init checks for AV_CODEC_ID_NONE at the top and fails then (noticed as i just wanted to add exactly such code to see what happens if it fails fr NONE) [18:49:39 CEST] <Daemon404> michaelni, i think i was mistaken about NONE being passed [18:49:50 CEST] <Daemon404> i did noticed the assert didnt trigger if NONE was passed though [18:49:53 CEST] <Daemon404> which still seems wrong [18:51:27 CEST] <Daemon404> i see the problem in codecpar branch, it is unrelated [18:51:35 CEST] <Daemon404> but probably NONE should still be fixed [18:52:06 CEST] Action: michaelni is ust trying to add a assert != none in git master [18:52:27 CEST] <Daemon404> ;) [19:09:28 CEST] <cone-283> ffmpeg 03Michael Niedermayer 07master:9f03b85045fd: avcodec/parser: assert that the codec id is not NONE in av_parser_parse2() [19:43:31 CEST] <Daemon404> just that ac3 regression left right now... [19:43:44 CEST] <Daemon404> i cant figure out where the hell the ac3 packet timestamps come from [19:43:46 CEST] <Daemon404> in framecrc [19:46:12 CEST] <Daemon404> back into the horrible world of muxer timestamp generation... [19:48:08 CEST] <durandal_1707> from demuxer? [19:48:21 CEST] <Daemon404> nope [19:53:03 CEST] <Daemon404> or, it should be [19:53:09 CEST] <Daemon404> but i cannot find where ac3 packet timestamps are ste [19:54:26 CEST] <wm4> you could check with ffprobe whether the demuxer sets them [19:54:39 CEST] <Daemon404> it does [19:54:52 CEST] <Daemon404> i checked what values av_interleaved_fwrite_frame was gettign from ffmpeg.c [19:55:10 CEST] <wm4> then the pts is determined by lavf/utils.c by using the frame duration [19:55:47 CEST] <Daemon404> where [19:56:19 CEST] <Daemon404> because all the packet durations are correct [19:56:35 CEST] <Daemon404> but pts/dts is NOPTS/0 for the first N fames post-merge [19:58:56 CEST] <wm4> I'm not quite sure [20:00:37 CEST] <Daemon404> i never ever want to look at utils.c timestamps again after this merge [20:01:28 CEST] <Daemon404> hmm wtf [20:01:35 CEST] <Daemon404> pkt->pts = -9223372036854775808 pkt->dts = -9223372036854775808 [20:01:35 CEST] <Daemon404> pkt->pts = 9223090561878065151 pkt->dts = 9223090561878065151 [20:01:43 CEST] <Daemon404> at some point this happens in read_frame_internal [20:01:44 CEST] <JEEB> o_O [20:01:48 CEST] <wm4> RELATIVE_TS_BASE? [20:03:20 CEST] <Daemon404> it happens N frames in here [20:03:23 CEST] <Daemon404> instead of 1 frame in [20:03:30 CEST] <Daemon404> where it should [20:03:31 CEST] <Daemon404> hmm. [20:07:17 CEST] <Daemon404> think i found it maybe [20:08:12 CEST] <Daemon404> hmm no. [20:20:52 CEST] <angus> Hey folks [20:21:02 CEST] <angus> can I get a sanity check here? [20:21:14 CEST] <angus> https://ffmpeg.org/doxygen/2.8/avio_8c_source.html#l00098 [20:21:30 CEST] <angus> line 239 static struct URLProtocol *url_find_protocol(const char *filename) [20:22:09 CEST] <angus> how does this funtion work? it seems URLProtocol *up is set to NULL, but never set to anything else [20:22:55 CEST] <ethe> up is set within the while condition [20:23:23 CEST] <angus> shouldn't that segfault? [20:23:45 CEST] <ethe> why would it segfault? [20:23:59 CEST] <angus> while (up = ffurl_protocol_next(up)) { [20:24:13 CEST] <angus> URLProtocol *ffurl_protocol_next(const URLProtocol *prev) 37 { 38 return prev ? prev->next : first_protocol; 39 } [20:24:54 CEST] <nevcairiel> seems fine to me? [20:25:01 CEST] <angus> oh, derp, first_protocol is returned [20:25:08 CEST] <nevcairiel> thats typical linked list traversal [20:29:59 CEST] <kierank> Gramner: works, thanks a lot [20:31:11 CEST] <Gramner> it does? wow, i changed a bunch of stuff without testing it more than just making sure it compiled [20:36:49 CEST] <kierank> Gramner: oddly it looks right but the md5sum doesn't match [20:37:31 CEST] <Gramner> might have messed up a value somewhere in one of the constants [20:38:46 CEST] <cone-283> ffmpeg 03Michael Niedermayer 07master:1d64a9d9f6e1: fate: Add regression test for Ticket 1239 [20:38:47 CEST] <cone-283> ffmpeg 03Michael Niedermayer 07master:7615197b6e8b: fate: Test for Ticket4560 [20:38:48 CEST] <cone-283> ffmpeg 03Michael Niedermayer 07master:0de1c1ab869f: fate: add demux test for TS with AC3 (Ticket 4864) [20:42:53 CEST] <Gramner> kierank: v210_uyvy_chroma_shuf3: db 5, 6,-1,-1, 8, 9, 1,-1,10,11,-1,-1,13,14,-1,-1 <- should be -1, not 1, after 9 [20:43:38 CEST] <kierank> hmm yes [20:44:10 CEST] <Gramner> does that fix it? [20:44:19 CEST] <kierank> checking now [20:44:37 CEST] <kierank> yes [20:44:47 CEST] <Gramner> cool [20:47:09 CEST] <Gramner> the multiple masks and multipliers are also just permutations of each other, could just have store one of each and pshufd the permuted ones in the prologue to save some cache. just need to make sure that the permuted ones are placed in registers for 32-bit [20:48:04 CEST] <kierank> ah I don't care much for 32-bit [20:48:12 CEST] <durandal_1707> so what speedup you get now? [20:51:56 CEST] <kierank> twice as fast as c on non-insane machine [20:53:08 CEST] <kierank> not sure if it's worth upstreaming because it uses a pixel format that doesn't exist in the file world [21:23:13 CEST] <Daemon404> there... ac3 shit fixed [21:23:17 CEST] <Daemon404> have i mentioned i hate utils.c lately [21:25:33 CEST] Action: Daemon404 hates our timestamp code [21:26:31 CEST] Action: jamrial throws INT64_MINs at Daemon404 [21:26:34 CEST] <wm4> not sure if anyone loves it [21:27:31 CEST] <Daemon404> its 3:30pm and i havent eaten a single meal today because i was fixing timestamps [21:27:35 CEST] Action: Daemon404 lives a healthy life [22:09:45 CEST] <cone-283> ffmpeg 03Ronald S. Bultje 07master:98038e2ee0c4: swscale: fix bt709 yuv2rgb coefficients. [22:09:46 CEST] <cone-283> ffmpeg 03Ronald S. Bultje 07master:b3eda69490db: swscale: add bt2020 yuv2rgb coefficients. [23:44:08 CEST] <michaelni> Daemon404, make fate on your codecpar branch fails fate-aac-latm_000000001180bc60, [fate-aac-latm_stereo_to_51, fate-vcr2 [23:49:47 CEST] <michaelni> these passed yesterday [00:00:00 CEST] --- Sat Apr 2 2016

1 0

ffmpeg.log.20160401
by burek 02 Apr '16

02 Apr '16

[00:03:40 CEST] <wiak> stupid question, when i compile ffmpeg with ./configure it will decode most formats/codecs? [00:09:05 CEST] <podman> furq: maybe i'll just get a dell poweredge r930 [00:09:32 CEST] <podman> 72 cores! [00:09:37 CEST] <kepstin> wiak: the default will be to enable pretty much all the built-in decoders, which should give you decent coverage of almost everything. [00:10:17 CEST] <kepstin> (encoders is a different matter; many formats require external encoder libraries, which have to be enabled explicitly) [01:58:49 CEST] <varu-> i ended up using socat to just create duplicates of the ts stream, then processing each with a ffmpeg instance [01:59:03 CEST] <varu-> allows me to modify each stream individually should i choose to, without taking the others down [01:59:11 CEST] <varu-> not the most efficient, but it works [02:18:00 CEST] <DHE> that would work... [04:47:42 CEST] <circ-user-HK0l0> how to set ffmpeg parameter to make it keep a [04:47:53 CEST] <circ-user-HK0l0> persistent connection on hls [04:50:21 CEST] <circ-user-HK0l0> i have try set multiple_requests and http header Connection=keep-alive;but doesn't work :( [07:08:25 CEST] <petecouture> anyone ever get encoding hickups coming from a live rtp going to .ts segments? Like if the bandwidth of the live stream drops and comes back the encoder stalls for 10 segments then processes a ton of data then stalls for 10 segments? [07:13:45 CEST] <momomo> petecouture, i dont [07:14:07 CEST] <momomo> but i am not sure i have experienced such lagging [07:15:49 CEST] <petecouture> I have some data [07:16:08 CEST] <petecouture> In the form of progress and file generation. [07:16:41 CEST] <petecouture> http://pastebin.com/ph3QSW7e [07:17:44 CEST] <petecouture> The first part is the command used. The second is the progress outputted from ffmpeg and the third is the traced out directory. See how the files are good for the first 10 segments then they are empty. It start because of an initial drop in bandwidth but when bandwidth comes back it doesn't recover. [07:28:02 CEST] <barryp123> Any fluent-ffmpeg users in the house? [07:28:15 CEST] <petecouture> Yup [07:28:27 CEST] <petecouture> been using for about 3 weeks now though [07:29:26 CEST] <barryp123> Trying to use takeScreenshots to get 100 screenshots of a video. Works great when I specify timemarks, but without timemarks, and specifiying count, it falls apart [07:30:23 CEST] <petecouture> barryp123: dunno sorry mate. [07:30:28 CEST] <petecouture> doing rtp to hls [07:31:00 CEST] <barryp123> basically, it errors out unless i use timemarks [07:31:07 CEST] <barryp123> ahh nice! [07:31:22 CEST] <petecouture> no royal pain [07:31:41 CEST] <barryp123> hahah everything that is worth it, is always a pain [07:31:44 CEST] <petecouture> like a satalite encoding system [07:31:48 CEST] <petecouture> true [07:32:48 CEST] <petecouture> I'm actually switching gears. This system is actually webrtc -> rtp -> ffmpeg -> hls. But if I can't fix this bandwdith drop I'm just going to build out a client side application do the ffmpeg encoding. [07:32:49 CEST] <barryp123> sounds cool!! Im not there yet& through getting screencaps would be pretty trivial.. tempted to push 100 values to the timemarks array [07:33:04 CEST] <petecouture> Will help offload the encoding cost as well. [07:36:35 CEST] <parrot> is MFXClose() part of ffmpeg or is it part of Intel MediaSDK? [08:11:14 CEST] <momomo> what language do you use for ffmpeg scale ? [08:12:04 CEST] <momomo> i am thinking about floor, min gt functions .. is tehre a reference for these ? [08:13:32 CEST] <momomo> I am getting an error for this scale function: http://hastebin.com/onusazecax.mel [08:13:40 CEST] <momomo> but only if height is too low [08:13:47 CEST] <momomo> at 300 i get an error [08:14:10 CEST] <momomo> for width 50 is ok ... but for height less than 300 i am getting: [08:14:10 CEST] <momomo> 3220225315 : Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [08:14:28 CEST] <momomo> i don't get it .. becasue the min(1, ... ) should return the lowest value .. so what could be wrong [08:18:17 CEST] <momomo> basically height will be: min(1,min(400/iw,300/ih))*ih [08:19:29 CEST] <momomo> is there a way to log the result of this calculation? [08:25:20 CEST] <momomo> I see this error: [libx264 @ 0x17de8e0] width not divisible by 2 (375x300) but it is strange [08:28:16 CEST] <momomo> actually, just using: "scale=375:300" will cause an error so it is not my scale function [08:28:25 CEST] <momomo> the error: [libx264 @ 0x12c1da0] width not divisible by 2 (375x300) [08:28:40 CEST] <momomo> so wierd [08:30:57 CEST] <momomo> seems to be possible error in libx264 ? [09:30:04 CEST] <Abatap> Hey guys! Anyone knows what's the deal with ffmpeg constantly receiving HTTP 403 when feeding it a periscope.tv m3u8 link. ffplay works just fine btw. [10:20:18 CEST] <thebombzen> momomo: it's not an error in libx264. The H.264 standard requires the width and height to be divisible by two. [10:20:38 CEST] <thebombzen> it should be anyway tho because of 4:2:0 chrome subsampling. [10:21:03 CEST] <momomo> thebombzen, so certain values lead to errror .. i am calculating the with and height using iw and ih [10:21:28 CEST] <thebombzen> there's no easy way to check to see if the input is odd and if it is add 1. I mean you could do that but it'd be complicated. [10:21:33 CEST] <momomo> so in this case width 375 is causing an issue [10:21:56 CEST] <thebombzen> Instead, I recommend calculating the output width/height using bash, and then substituting it in [10:22:23 CEST] <momomo> hmm .. isn't there a modulo function perhaps for scale ? [10:22:25 CEST] <momomo> what language is that? [10:22:41 CEST] <momomo> min floor functions are available [10:22:54 CEST] <thebombzen> there is. but you'd have to substitute that entire expression into it. not worth it. [10:22:56 CEST] <thebombzen> check this out: https://www.shell-tips.com/2010/06/14/performing-math-calculation-in-bash/ [10:23:38 CEST] <thebombzen> I'd use a bash script to do the actual calculating, assume you're executing ffmpeg from a bash script. If you're executing ffmpeg from a language like C, then do the math in C. [10:24:01 CEST] <momomo> thebombzen, the thing is that I am not using bash .. plus ffmpeg needs these values before the command is issued .. are you suggesting i do a request first get the width and height of the srouce and then reconnect ? [10:24:46 CEST] <momomo> i do not know the width and height of the source . ffmpeg knows this and places it in ih and iw [10:25:03 CEST] <momomo> so bash, C or java is too early [10:25:18 CEST] <momomo> i think substition is ok for me now [10:25:30 CEST] <momomo> but I can [10:25:40 CEST] <momomo> t find a reeference for finding these functions [10:25:45 CEST] <momomo> is this c functions ? [10:25:57 CEST] <thebombzen> another thing you could do is use something like scale="trunc(3/2*iw/hsub)*hsub:trunc(3/2*ih/vsub)*vsub" [10:26:32 CEST] <thebombzen> trunc truncates an integer. so you could divide it by two, truncate it, then multiply it by 2. [10:26:41 CEST] <thebombzen> that would ensure it's always even [10:26:46 CEST] <momomo> good trick [10:26:53 CEST] <thebombzen> (it's in the documentation) [10:27:15 CEST] <thebombzen> (I suggest you read https://ffmpeg.org/ffmpeg-filters.html#scale-1) in its entirity [10:27:21 CEST] <momomo> this is the command i am using: http://hastebin.com/onusazecax.mel [10:27:30 CEST] <momomo> it chooses either max height or max width [10:27:49 CEST] <momomo> so I will try to trunc it now [10:28:11 CEST] <thebombzen> in particular, read this line [10:28:20 CEST] <thebombzen> "If one of the values is -n with n > 1, the scale filter will also use a value that maintains the aspect ratio of the input image, calculated from the other specified dimension. After that it will, however, make sure that the calculated dimension is divisible by n and adjust the value if necessary." [10:28:54 CEST] <thebombzen> so if you set the width to whatever you are trying to scale, and the height to -2, in scales the height by the same scale factor as the width, and then ensures both are divisible by 2. [10:30:10 CEST] <momomo> so : scale=min(1\,min(400/iw\,300/ih))*iw:-2 [10:30:13 CEST] <momomo> should do the trick [10:30:29 CEST] <thebombzen> also [10:30:32 CEST] <thebombzen> you should consider force_original_aspect_ratio [10:30:40 CEST] <thebombzen> there's a reason the documentation exists [10:30:50 CEST] <thebombzen> because there's all these amazing features that you won't know about until you read up [10:30:52 CEST] <momomo> it's a big documenation [10:31:05 CEST] <thebombzen> which is why you read exactly the -vf scale documentation [10:31:10 CEST] <thebombzen> and not all the other filters [10:31:31 CEST] <momomo> i did [10:31:48 CEST] <thebombzen> did you try force_original_aspect_ratio? [10:31:50 CEST] <momomo> but I am calculating the scale .. i am not sure how this argument would help [10:31:59 CEST] <momomo> for instance i might get [10:32:02 CEST] <momomo> 375:-2 [10:32:19 CEST] <thebombzen> so it appears you're trying to scale it down in a way where it will fit inside a 400x300 frame, right? [10:32:20 CEST] <momomo> your first statement would ensure it is divisible by two [10:32:31 CEST] <momomo> yes.. not bigger either wway [10:32:34 CEST] <thebombzen> okay [10:32:36 CEST] <momomo> can not go outside [10:33:49 CEST] <thebombzen> did you try -vf scale=force_original_aspect_ratio=decrease:s=400x300 [10:33:55 CEST] <thebombzen> cause that does what you're trying to do [10:34:02 CEST] <thebombzen> and it explains it in the documentation [10:36:36 CEST] <momomo> one moment [10:38:37 CEST] <momomo> -vf scale=force_original_aspect_ratio=decrease:s=1024x300 caused an error [10:38:50 CEST] <momomo> but the first one with -2 worked [10:38:53 CEST] <momomo> i think [10:38:56 CEST] <momomo> let me retry [10:39:38 CEST] <momomo> no, also flunked [10:39:40 CEST] <momomo> with 300 [10:39:52 CEST] <momomo> i am going to try trunc [10:43:25 CEST] <momomo> now I get 374x300 [10:43:38 CEST] <momomo> for scale=trunc(iw*min(1\,min(1024/iw\,300/ih))/2)*2:-2 [10:46:45 CEST] <momomo> the problem now is though that the aspect ratio gets a bit flawed [10:46:51 CEST] <momomo> i had 1.25 originall [10:46:52 CEST] <momomo> y [10:46:56 CEST] <momomo> now it's 1.253333 [10:47:39 CEST] <momomo> ideally you'd want to go inside the box until you hit the aspect ratio perfectly [10:49:40 CEST] <rrva> How can I access the POC of a h264 video packet after having decoded it with av_read_frame ? [10:49:59 CEST] <momomo> thebombzen, it appears to me as if -vf scale=force_original_aspect_ratio=decrease:s=400x300 is broken [10:50:08 CEST] <momomo> as it is not safe [10:52:06 CEST] <thebombzen> momomo: are you using the latest ffmpeg? [10:52:10 CEST] <thebombzen> git master? [10:52:35 CEST] <thebombzen> also in general you should post your complete, uncut command and output to a paste website before asking for help [10:53:15 CEST] <momomo> no, it's some ubuntu version [10:56:12 CEST] <momomo> thebombzen, the command http://hastebin.com/hacimegiko.md [10:56:40 CEST] <thebombzen> first of all [10:56:50 CEST] <momomo> thebombzen, Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [10:56:55 CEST] <thebombzen> url.com is fake. which means you edited the line. don't do that [10:56:59 CEST] <thebombzen> second of all... and the output? [10:57:16 CEST] <thebombzen> third of all, you should use the latest git master [10:57:55 CEST] <momomo> thebombzen, http://hastebin.com/ahiqekecof.pas [10:58:12 CEST] <momomo> thebombzen, i will look into that and how to build ffmpeg manually [10:58:33 CEST] <momomo> thebombzen, the reason i did that is to hide what is unprotected server [10:58:34 CEST] <thebombzen> 1. that's an old version. [10:58:57 CEST] <thebombzen> 2. -framerate is an input option. you don't need it. [10:59:07 CEST] <thebombzen> 3. don't use libvo_aacenc [10:59:24 CEST] <thebombzen> it's awful awful awful. if you want a free encoder, use the built-in one. it's actually stable nowadays [11:00:59 CEST] <momomo> ook, do I specify some other option? [11:01:08 CEST] <momomo> or just ignore it ? [11:01:34 CEST] <thebombzen> don't use -r and -framerate. -framerate is used for specifying the framerate of input video [11:01:40 CEST] <momomo> ook [11:01:49 CEST] <momomo> i think -r is needed for keysize and g [11:02:05 CEST] <momomo> someone told me they need to be 5 multiple of -r [11:02:06 CEST] <thebombzen> you should try to avoid x264 options and just pick a preset [11:02:16 CEST] <thebombzen> x264's presets are good [11:02:22 CEST] <momomo> the option i have is crf 23 [11:02:43 CEST] <furq> if you're using libvo-aacenc then you're not using a recent enough ffmpeg build to have the worthwhile builtin encoder [11:02:45 CEST] <momomo> the other ones are neccessary for hls to cut at a fixed time [11:02:48 CEST] <momomo> i believe [11:02:56 CEST] <furq> and yeah you need -g and -keyint_min for hls [11:03:18 CEST] <momomo> do i need -x264-params scenecut=0 [11:03:22 CEST] <furq> no [11:03:22 CEST] <momomo> i am not sure what it does [11:03:26 CEST] <furq> keyint_min will do the same thing [11:03:50 CEST] <furq> or rather, having keyint_min and g be the same value will disable scenecut anyway [11:03:57 CEST] <thebombzen> x264 has a feature called "scenecut detection" where it won't encode an inter-frame if it detects a scenecut and will reencode it as intra-only [11:04:09 CEST] <thebombzen> it's simply the encoder being intelligent and isn't a feature of the bitstream [11:04:18 CEST] <thebombzen> you shouldn't turn it off [11:04:29 CEST] <furq> it makes no difference if you have fixed GOP size [11:04:40 CEST] <momomo> so the values of scenecut seems to do what I am after with -r -g and min [11:04:56 CEST] <momomo> or maybe not [11:05:04 CEST] <furq> also you don't need to care about preserving the aspect ratio because it's anamorphic [11:05:08 CEST] <furq> it'll scale to the correct DAR regardless [11:05:17 CEST] <furq> in the player, that is [11:05:42 CEST] <thebombzen> welp, it appears that someone more knowledgeable than me has arrived. time to peace out [11:07:10 CEST] <furq> also i'm pretty sure that -threads 2 is only applying to the first output file [11:08:09 CEST] <momomo> ook good to know [11:08:53 CEST] <momomo> but there is a bug using -vf scale=force_original_aspect_ratio=decrease:s=1024x300 [11:09:05 CEST] <furq> for the record i think someone suggested scenecut=0 because you can use that instead of keyint_min [11:09:10 CEST] <momomo> so I ended up having to calculate 374:-2 [11:09:32 CEST] <furq> i've not used the scale filter intensively enough to know if that's a bug [11:09:59 CEST] <momomo> furq, it is a bug because the program will fail [11:10:03 CEST] <momomo> and shut down [11:10:14 CEST] <momomo> if values are not perfect and divisible by two [11:10:57 CEST] <furq> that's not a bug, h.264 needs mod2 width [11:11:06 CEST] <furq> and yuv420p needs mod2 height [11:11:16 CEST] <furq> there's nothing that can be done about that [11:12:22 CEST] <momomo> but it makes it pretty unreliable since you can not easily know what source format is .. and you could end up with odd numbers [11:12:36 CEST] <momomo> this works: scale=trunc(iw*min(1\,min(375/iw\,300/ih))/2)*2:-2 [11:12:55 CEST] <momomo> but produces: 374x300 [11:13:00 CEST] <momomo> which is not 1.25 [11:13:12 CEST] <momomo> aspect ratio a little lost [11:13:19 CEST] <momomo> but maybe that is insignificant ? [11:13:31 CEST] <momomo> furq, your email seems broken [11:13:54 CEST] <furq> it doesn't really matter if it's 1.25, you're setting the SAR anyway [11:13:59 CEST] <furq> and yeah i know ;_; [11:14:31 CEST] <furq> i need to go yell at my domain registrar [11:14:43 CEST] <momomo> it must be godaddy because they suck [11:15:43 CEST] <momomo> scale=force_original_aspect_ratio=...:s=1024x300 should have an option fitapspect [11:16:09 CEST] <momomo> which will decrease the size of both height and width until both are whole integers [11:16:17 CEST] <momomo> while maintaining aspect [11:16:37 CEST] <momomo> it might be a bit tricky to find such numbers, but there are probably algoritms [11:17:55 CEST] <furq> it is odd that there isn't some way to get force_original_aspect_ratio to scale to mod2 [11:18:04 CEST] <furq> unless i'm missing something [11:19:59 CEST] <momomo> even scale will fail for odd numbers [11:20:03 CEST] <momomo> scale=trunc(iw*min(1\,min(375/iw\,300/ih))/2)*2:-2 but this works [11:20:10 CEST] <momomo> but i would like to round perhaps [11:20:19 CEST] <momomo> is there a round method ? [11:20:23 CEST] <momomo> rather than trunc [11:20:33 CEST] <momomo> or that might fail [11:20:42 CEST] <momomo> with / 2 * 2 [11:21:08 CEST] <momomo> no that should work [11:21:27 CEST] <furq> https://ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation [11:21:50 CEST] <furq> there's floor and ceil but no round [11:22:31 CEST] <furq> maybe floor(x+0.5) will work [11:23:38 CEST] <momomo> floor and trunc is the same right? [11:23:50 CEST] <furq> for positive values, yes [11:25:19 CEST] <momomo> 3220225315 : [NULL @ 0x14de980] Unable to find a suitable output format for '+' [11:25:28 CEST] <momomo> for scale=floor(iw*min(1\,min(1024/iw\,768/ih))/2 + 0.5)*2:-2 [11:25:31 CEST] <momomo> or wait [11:25:38 CEST] <furq> quote it or get rid of the spaces [11:25:50 CEST] <momomo> scale=floor(iw*min(1\,min(1024/iw\,768/ih))/2+0.5)*2:-2 worked [11:27:16 CEST] <furq> also if you're on *nix you can use the static builds if you want the up-to-date aac encoder [11:27:20 CEST] <furq> http://johnvansickle.com/ffmpeg/ [11:28:19 CEST] <momomo> ooh nice [11:28:23 CEST] <momomo> i ended up using scale=floor(iw*min(1\,min(1024/iw\,300/ih))/2+0.4999999)*2:-2 [11:28:34 CEST] <momomo> to prefer rounding down if they are equal [11:58:05 CEST] <kenny__> Hello, -t (or -to) param should quit/kill ffmpeg with -map 0 param? If i use without -map, ffmpeg will quit, but if i use -map 0, ffmpeg only stops saving to file but still lunched - its normal? [12:14:02 CEST] <momomo> pkill ffmpeg :p [12:41:44 CEST] <kenny__> momomo: i can`t, i have more than one ffmpeg process, other must still running; i can base by PID but this is not the solution ;) [12:42:02 CEST] <momomo> it works fine to kill ffmpeg for me [12:43:25 CEST] <kenny__> "it" mean pkill or with -t param? [15:28:08 CEST] <iticus> hello! I'm trying to re-stream a stream using RTMP but I'm getting an error regarding not being able to connect to the "output" [15:28:32 CEST] <iticus> ffmpeg -re -i input_stream -c copy -f flv rtmp://localhost:10000/live [15:29:04 CEST] <iticus> I'm getting: Connection to tcp://localhost:10000 failed: Connection refused; but shouldn't ffmpeg listen on port 10000 rather than trying to connect to it? [15:29:58 CEST] <furq> no? [15:30:08 CEST] <furq> ffmpeg isn't an rtmp server [15:34:17 CEST] <iticus> furq, what are my options in this case? [15:35:10 CEST] <iticus> I tried to follow some examples from: https://www.wowza.com/forums/content.php?213-How-to-use-FFmpeg-with-Wowza-M… [15:41:55 CEST] <iticus> what other options do I have to re-stream the content so that I could play the stream using something like VLC for example? [15:45:31 CEST] <furq> if you want an rtmp server then https://github.com/arut/nginx-rtmp-module [15:46:41 CEST] <furq> but if you were only listening on localhost then why not just play the stream with vlc/mpv [15:54:49 CEST] <iticus> furq, mpv can play the stream directly but VLC cannot; that is why I tried to re-stream it [15:55:26 CEST] <iticus> I found out that -f mpegts udp://127.0.0.1:10000 will stream it and "vlc udp://@:10000" will play it OK [15:56:56 CEST] <DHE> that would work for real-time live streams [17:34:58 CEST] <Amitari> Does anyone know how to cut the audio from a video from a certain frame, to a certain frame, and have it saved as FLAC? [17:37:07 CEST] <Amitari> I would normally do this in Audacity, but the video has a weird framerate with a bunch of decimals, so I can't really do it. [17:43:14 CEST] <courrier> Amitari: somehting like ffmpeg -i in.mp4 -ss 00:01:00 -t 10 -vn -acodec flac out.flac ? [17:43:46 CEST] <courrier> (extracts t=10 seconds from the ss=1st minute) [17:43:46 CEST] <Amitari> Yeah, but I don't really think I can input it in time because of the odd framerate, the time has a whole bunch of decimals. [17:44:28 CEST] <kepstin> Amitari: the seek values in ffmpeg can have a bunch of decimal places to specify precision, it's not hard to be frame-accurate [17:45:13 CEST] <Amitari> In seconds, it's from "722.240454888" to "730.815517112". [17:45:28 CEST] <Amitari> I just divided the frame numbers by the frame rate [17:45:36 CEST] <Amitari> I just don't know how this works. [17:45:40 CEST] <Amitari> Too many decimals. [17:46:04 CEST] <scoofy> it's likely a floating point approximation of a rational number [17:46:14 CEST] <kepstin> well, the frame rate itself doesn't have any decimals, it's almost certainly a fraction like 24000/1001 [17:46:41 CEST] <kepstin> (ntsc video has this annoying /1001 thing because of a quirk of how they added color to the signal) [17:46:46 CEST] <Amitari> The frame rate is "29.970628". :P [17:46:57 CEST] <kepstin> ok, that's exactly 30000/1001 :) [17:47:12 CEST] <Amitari> wat [17:49:10 CEST] <kepstin> but yeah, there's no real good way in ffmpeg to trim an audio/video stream in ffmpeg using video frame counts [17:49:37 CEST] <kepstin> you can't "seek" to a video frame, only to a time, so the -ss option can't do it - you actually have to decode the video and count frames to know where to start :/ [17:50:29 CEST] <kepstin> one thing you could try is to use the 'ffprobe -show_frames' output to figure out the exact time of the frames you're looking at. [17:51:06 CEST] <Amitari> Should I type "ffprobe -show_frames 21646 21903" then? [17:53:17 CEST] <kepstin> no, 'ffprobe -show_frames video.mkv' - it'll print a chunk of data for each frame including the exact timestamps. Might be hard to fine frames by count in the output, tho. [17:54:23 CEST] <kepstin> if the video is constant fps, tho, just doing "frameno * 1001 / 30000" should do. [17:55:45 CEST] <Amitari> Lemme try. [17:56:58 CEST] <Amitari> [NULL @ 0x557c5b9d4340] Unable to find a suitable output format for 'frameno' [17:56:58 CEST] <Amitari> frameno: Invalid argument [17:57:39 CEST] <sb_> [Is there a && Is this the] channel for people using libav or is the libav-users list the best place to go? [17:58:34 CEST] <kepstin> Amitari: ... you type that into your calculator, replacing 'frameno' with the number of the frame [17:58:50 CEST] <kepstin> Amitari: it gives you the exact time to use in seconds for the -ss [17:59:17 CEST] <kepstin> sb_: well, if you stay here we can help you switch to ffmpeg instead of libav :) [17:59:38 CEST] <Amitari> Alright, lemme try this then. [17:59:49 CEST] <furq> i'm guessing he's on one of the unfortunate debian/ubuntu releases which switched to libav [18:00:08 CEST] <Amitari> That was one of the reasons I switched to Arch. [18:00:20 CEST] <furq> debian is back on ffmpeg now [18:00:20 CEST] <sb_> kepstin: sorry, not the fun little chair switch we all did a few years ago.. I mean writing code against libavformat, libavcodec, etc [18:00:30 CEST] <furq> oh right [18:00:35 CEST] <furq> no this is the channel for that [18:00:48 CEST] <furq> or the ffmpeg-user list [18:01:08 CEST] <Amitari> Where in the command do I write where it should end? [18:01:09 CEST] <kepstin> sb_: that said, a lot of the stuff on this channel is helping people with the ffmpeg command-line tool, there's fewer people here with api experience :/ [18:01:22 CEST] <Amitari> I'm using the "ffmpeg -i in.mp4 -ss 00:01:00 -t 10 -vn -acodec flac out.flac" thing. [18:01:31 CEST] <furq> Amitari: -t is where it ends [18:01:36 CEST] <Amitari> Oh, alright. [18:01:40 CEST] <furq> 10 seconds after -ss [18:01:49 CEST] <Amitari> wat [18:01:58 CEST] <Amitari> Should I write the end time where 10 is? [18:01:59 CEST] <kepstin> Amitari: -t sets the duration of the clip to be output. [18:02:07 CEST] <sb_> kepstin furq thanks, I'll give it a go then [18:02:15 CEST] <furq> if you want the end time then use -to 00:01:10 [18:03:45 CEST] <Amitari> Ah, there! [18:03:47 CEST] <Amitari> Thanks! :D [18:03:56 CEST] <Amitari> This will go in my command collection. :P [18:03:58 CEST] <sb_> I've got a local mp4, trying to examine the atom structure programmatically (looking for a user-data atom sibling of moov.trak). I've looked at how atom/boxes are read in libavformat/mov.c but don't know if there's any api for getting that info [18:05:53 CEST] <kepstin> sb_: as far as I know, there isn't, that sort of thing's all abstracted away behind the libavformat interface. [18:06:57 CEST] <kepstin> sb_: depending what's in the atom you're looking for, it might make sense to extend the mov demuxer to attach it to the stream as metadata [18:07:06 CEST] <kepstin> (or it might already be there, I dunno) [18:07:30 CEST] <sb_> its already supported, its the ISO uuid container [18:08:09 CEST] <sb_> (are you saying it should be injected in AVPacket metadata when I'm in the av_read_frame loop?) [18:14:08 CEST] <kepstin> hmm. the only thing I see the mov atom used for reading stream bitrate from isml, and xmp metadata. It's checking against an explicit list of uuid, and does nothing if it's not one of those two. [18:14:13 CEST] <kepstin> the mov uuid atom* [18:15:36 CEST] <kepstin> so if you're looking for a different type of data than one of those, it'll require extending the demuxer. [18:16:57 CEST] <sb_> kepstin: oh I see, so I can add my own uuid_whatever inside mov_read_uuid and just add another else condition? [18:17:21 CEST] <sb_> (and use av_dict_set to add some metadata of my own) [18:19:17 CEST] <kepstin> sb_: yeah, that's probably the easiest way to do it. [18:19:37 CEST] <kepstin> if it's something generically useful, the patch for that would probably be accepted, too. [18:20:10 CEST] <sb_> yeah I was going to say.. its to add support for spherical video, its currently an RFC draft from google though [18:20:14 CEST] <sb_> https://github.com/google/spatial-media/blob/master/docs/spherical-video-rf… [19:53:34 CEST] <playajames> Anyone here with xuggler knowledge? Their IRC has noone in it :S [19:56:05 CEST] <durandal_1707> what is xuggler? [20:04:51 CEST] <playajames> A java library that allows FFMPEG to be used from java applications. [20:37:28 CEST] <gnome1> ffmpeg picks (for libx264) the "high" profile, is this going to be more demanding to play than "main"? [20:43:46 CEST] <rrva> if I have an AVFrame struct, how do I determine if I have a IDR frame in h264? is this just pict_type=I ? [20:45:05 CEST] <sb_> rrva: do you have a handle on the stream? [20:45:20 CEST] <rrva> yes [20:45:44 CEST] <sb_> av_stream_get_parser will produce an AVCodecParserContext which has a key_frame flag [20:46:14 CEST] <DHE> gnome1: it is more demanding, but unless you're dealing with cell phones, it's not likely to be an issue for playback [20:46:34 CEST] <rrva> sb_: https://gist.github.com/rrva/471a0f106f67e380ca76ce3759b33a18 [20:47:02 CEST] <rrva> there is key_frame on both AVPacket and AVFrame level also [20:47:11 CEST] <DHE> rrva: there should be a key_frame field. that'll be a proper IDR [20:47:23 CEST] <DHE> h264 allows an I-frame which is not IDR [20:48:09 CEST] <furq> gnome1: it's only likely to be an issue if you have a device which can't decode high profile [20:48:21 CEST] <furq> and those are getting rare these days [20:49:00 CEST] <rrva> DHE: key_frame on AVPacket level, that ought to be a an I-Frame (RAI random access indicator), and key_frame on AVFrame level is IDR then? [20:49:28 CEST] <DHE> RAI is an mpegts thing. it's how it indicates clients can start playback from this point [20:49:43 CEST] <rrva> yes, this is h264 in mpegts [20:49:44 CEST] <DHE> but for example, in mpeg2 an I-frame is the same thing [20:50:04 CEST] <DHE> but since h264 can have more than 1 reference frame you can have an I-frame that isn't seek-safe [20:50:43 CEST] <rrva> i was thinking since avpacket level is available without any knowledge of video, it must be just signaling that it's an I-frame [20:51:24 CEST] <rrva> avpacket->flags & AV_PKT_FLAG_KEY [20:52:54 CEST] <rrva> so is there a difference between AVFrame->key_frame and AVCodecParserContext->key_frame ? [20:54:07 CEST] <sb_> You can get the AVCodecParserContext without decoding a frame [20:54:28 CEST] <rrva> aha [20:55:03 CEST] <gnome1> DHE: furq: ok, I just want to avoid making some video that requires a 3GHz cpu just because I didn't pick the right profile :-D [20:55:07 CEST] <rrva> and AVCodecParserContext->key_frame will be 1 iff i have an IDR only? [20:55:20 CEST] <gnome1> but I suppose the bottleneck is going to be the bitrate and frame size [20:55:33 CEST] <gnome1> (it's nice if I can play the videos also on a lower-spec computer (laptop), for example) [20:55:51 CEST] <sb_> rrva I couldn't tell you definitively for IDR but definitely for h.264 i-frames [20:56:28 CEST] <rrva> ok. I need something to tell me if it is IDR or not, maybe I should read more ffmpeg code. [20:57:53 CEST] <rrva> sb_: it's set to 1 for more than IDR [20:57:57 CEST] <rrva> sb_: "recovery_frame_cnt from SEI message [20:59:41 CEST] <DHE> there is an h264 mode which doesn't have keyframes in the traditional sense. periodically a full frame partial refresh will occur such that if you decode the whole refresh sequence you get a working frame for presentation purposes [21:00:07 CEST] <DHE> the main use is so that the I-frames are not so large by stretching them out over multiple frames [21:01:22 CEST] <furq> gnome1: i have a core duo laptop from ~2006 which plays high profile 1080p fine [21:01:56 CEST] <furq> it's really only a concern if you're dealing with hardware decoders which will just refuse to touch certain profiles [21:02:21 CEST] <furq> iirc very old iphones will only play baseline profile [21:05:17 CEST] <rrva> I believe, after reading https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_parser.c that I can access H264ParseContext [21:05:25 CEST] <rrva> and get IDR info from there [21:05:54 CEST] <gnome1> I think I've had some issues with my laptop in the past, but that was probably too large (frame size, and thus bitrate) videos (these days even getting something from a site like youtube in 9000KHD can be easier than getting something more manageable) [23:51:42 CEST] <AleXoundOS> Hi. Is it possible to edit loglevel "info" format? [23:53:02 CEST] <JEEB> please note in more detail. it is possible to control with the API where those messages get pushed and you can create wrappers around that IIRC, but you cannot modify the messages themselves [23:55:27 CEST] <AleXoundOS> I use latest ffmpeg from git. And "info" loglevel contains additional "speed" field that I don't need. Can I suppress it somehow? [23:55:52 CEST] <JEEB> what [23:56:17 CEST] <furq> grep -v speed [23:56:48 CEST] <JEEB> oh [23:56:52 CEST] <JEEB> that one line in ffmpeg.c [23:57:19 CEST] <AleXoundOS> furq, this will suppress the whole line [23:57:46 CEST] <AleXoundOS> JEEB, so there is no option controlling the "info" format, do you suggest to edit ffmpeg.c ? [23:58:55 CEST] <JEEB> as far as I can tell print_report() gives no option for that [23:59:13 CEST] <JEEB> you can probably disable that report printing altogether tho [23:59:40 CEST] <JEEB> not sure why you'd want to completely disable it, though [23:59:57 CEST] <JEEB> even if you are parsing the command line output it should be possible to update your stuff against the new output [00:00:00 CEST] --- Sat Apr 2 2016

1 0

ffmpeg-devel.log.20160331
by burek 01 Apr '16

01 Apr '16

[00:01:45 CEST] <llogan> BBB: do you have an example command I can try with colorspace? i can only get "Failed to inject frame into filter network: Invalid argument" [00:02:23 CEST] <BBB> you didnt set the output colorspace [00:02:44 CEST] <BBB> try ffmpeg -i bt2020_to_bt709.mp4 -vf colorspace=trc=smpte240m:primaries=smpte240m:range=jpeg:space=smpte240m -f null - [00:03:36 CEST] <BBB> you can also try -vf colorspace=format=yuv420p12:trc=bt2020-12:primaries=bt2020:range=jpeg:space=bt2020ncl [00:03:45 CEST] <BBB> I agree the filter isnt terribly user-friendly [00:04:08 CEST] <BBB> like, it would be nice to not have to repeat yourself 4x and so on, thats in the FIXME list on top of vf_colorspace.c [00:04:36 CEST] <nevcairiel> could use a kind of preset for common combinations [00:04:41 CEST] <llogan> by the way applying the patch complained about some whitespace somewhere. [00:04:56 CEST] <llogan> <- Mr. Useful [00:06:14 CEST] <BBB> llogan: thanks, fixed in https://github.com/rbultje/ffmpeg/tree/colorspace [00:06:32 CEST] <BBB> (https://github.com/rbultje/ffmpeg/commit/7e8001142929e8ff39362647dcea011f92…) [00:06:55 CEST] <BBB> nevcairiel: yes thats what colormatrix does (although thats the only way to use it, which is limiting and sometimes wrong) [00:07:26 CEST] <BBB> nevcairiel: Ill try to make it work and have it be correct in the normal cases [00:08:58 CEST] <BBB> I guess some error messages would also help (please set property X) instead of just returning EINVAL [00:09:06 CEST] <BBB> anywya, gotta go home [00:30:54 CEST] <BBB> llogan: Ill add some doxy for the filter if the general idea is ok with people [00:32:40 CEST] <durandal_170> check return of ff_get_video_buffer? [00:40:01 CEST] <nevcairiel> so watching a video about the new windows subsystem for linux, if this stuff actually works properly and clang for windows also starts becoming reliable, i could finally get rid of all this msys and mingw crap, this would be a good day indeed [00:41:14 CEST] <wm4> heh [00:42:40 CEST] <Gramner> GNU/Windows [00:43:04 CEST] <nevcairiel> noone would have ever believed them if the announcement would have been tomorrow [00:43:11 CEST] <nevcairiel> its just too crazy [00:43:15 CEST] <Gramner> yeah [00:43:46 CEST] <nevcairiel> emulating unix syscalls in the windows kernel, running ELF binaries [00:43:56 CEST] <wm4> oh so it uses elf? [00:44:04 CEST] <nevcairiel> its unmodified ubuntu binaries [00:44:07 CEST] <nevcairiel> apt-get and all [00:44:08 CEST] <wm4> does it emulate the linux abi? [00:44:14 CEST] <wm4> woah [00:44:21 CEST] <wm4> the linux abi is pretty crazy [00:44:29 CEST] <wm4> because it used to emulate other commcerical unixes [00:44:34 CEST] <wm4> depending on platform [00:44:35 CEST] <Gramner> i wonder if you can get better performance with that compared to native windows binaries [00:45:06 CEST] <nevcairiel> i would be happy if fork is implemented fully and bash scripts just run fast [00:45:07 CEST] <wm4> but this also definitely means you can't load DLLs into such procsesses [00:45:27 CEST] <nevcairiel> no, loading windows dlls wouldnt work, but I would be happy if it can launch windows processes [00:45:35 CEST] <j-b> it can. [00:45:59 CEST] <nevcairiel> although translating the pathes around again would be a fun thing to do [00:46:00 CEST] <smarter> what if you run windows dlls through wine through windows ? :) [00:46:07 CEST] <wm4> hope will they map the filesysten [00:46:15 CEST] <wm4> might be worse than with msys/cygwin [00:46:16 CEST] <nevcairiel> windows drives are in /mnt/c/ etc [00:46:24 CEST] <Gramner> C: was under /mnt/c/ in the ms demo [00:46:39 CEST] <wm4> smarter: linux binaries can't use wine as a library [00:46:57 CEST] <nevcairiel> wm4: tell that to mplayer using wine to run windows codecs [00:47:12 CEST] <wm4> nevcairiel: mplayer uses a very old hacked wine copy [00:47:27 CEST] <wm4> when coreavc was still the best thing ever this was a problem [00:47:35 CEST] <wm4> someone even wrote some sort of wine codec server [00:47:42 CEST] <wm4> to run coreavc on linux with mplayer [00:47:45 CEST] <nevcairiel> anyway if you limit yourself to relative paths, building with a windows compiler from this linux shell should in theory work [00:47:59 CEST] <nevcairiel> or maybe its super smart and translates paths for you [00:48:02 CEST] <nevcairiel> now that would be amazing [00:48:12 CEST] <nevcairiel> but probably crazy, mingw fails at this badly [00:49:42 CEST] <Gramner> afaik there's no way of doing automatic path translation that works in 100% of cases since there can be ambiguous cases [00:50:52 CEST] <Gramner> here's how it works in msys: http://www.mingw.org/wiki/Posix_path_conversion [00:52:02 CEST] <nevcairiel> yeah its complex and not very reliable, its probably best to stay away from that [00:52:15 CEST] <wm4> yeah, the best I could imagine is mapping paths like /c/... [00:53:16 CEST] <Gramner> the main cause of path conversion frustration in msys is msvs with it's crazy command line syntax [00:53:33 CEST] <nevcairiel> things like /Fo<name> is just silly [00:53:46 CEST] <nevcairiel> no space, no separator [00:53:49 CEST] <nevcairiel> silly msvc [00:53:49 CEST] <Gramner> exactly [02:29:10 CEST] <atomnuker> J_Darnley: do you happen to know how sample_size and sample_w are determined in v210? [02:30:05 CEST] <J_Darnley> If they're what I think then they are just "constants" set along side the DSP functions [02:30:28 CEST] <J_Darnley> but I will go look at the source [02:30:39 CEST] <BBB> michaelni: so, about swscale [02:30:45 CEST] <BBB> michaelni: Im sure you know my objections to it [02:33:32 CEST] <J_Darnley> atomnuker: yes, sample_size is the number of samples the DSP function does per iteration and then ... [02:33:44 CEST] <BBB> nevcairiel: msys is just as stupid to convert paths from c:\ to /c/ [02:33:44 CEST] <J_Darnley> sample_w is the width processed by the dsp function leaving a remainder to be done in C [02:33:50 CEST] <BBB> nevcairiel: that couldve been done much more compatibly [02:59:53 CEST] <cone-752> ffmpeg 03James Almer 07master:9bf3d01d9147: avformat/latmenc: auto-insert aac_adtstoasc bitstream filter when needed [03:48:11 CEST] <cone-752> ffmpeg 03Claudio Freire 07master:be746ae47063: AAC encoder: fix undefined behavior [04:04:29 CEST] <rcombs> so I had audiotoolboxdec set up to take a channel layout struct from AT, convert it to a channel_layout bitmask, sort the layout struct to match lavu's channel order, and then set the output channel layout to the sorted struct [04:04:59 CEST] <rcombs> in the AAC decoder, this resulted in the decoder reordering the channels into the order lav* expects [04:05:10 CEST] <rcombs> turns out in the AC3 decoder, the order is ignored [04:06:03 CEST] <rcombs> the "set output channel layout" API returns success [04:06:13 CEST] <rcombs> and just silently does nothing [04:06:42 CEST] <rcombs> so I figure "OK, let's see if I can use planar audio then" [04:07:20 CEST] <rcombs> nope, there are flags for planar output but the decoders error when you use 'em [04:22:23 CEST] <BBB> rcombs: looks like a ffmpeg developer designed their api and implemented it (for one decoder) [04:22:27 CEST] <BBB> rcombs: :-p [08:07:36 CEST] <mateo`_> Daemon404: hi, only codec_ctx->codec->caps_internal in the test is illegal right ? or is it illegal too to access it from lavf/utils.c ? [10:33:26 CEST] <cone-623> ffmpeg 03Clément BSsch 07master:263eb76bdf5c: sws/aarch64: add ff_hscale_8_to_15_neon [10:57:59 CEST] <ubitux> any idea why on x86 the vscale optimization are only effective for dst format in little-endian? [10:58:28 CEST] <ubitux> oh my bad, that's only for >8-bit [11:18:05 CEST] <cone-623> ffmpeg 03Paul B Mahol 07master:241a3a6ca493: doc/filters: add sofalizer examples [11:18:06 CEST] <cone-623> ffmpeg 03Paul B Mahol 07master:cf925e0ac19d: doc/filters: add stereotools examples [12:05:29 CEST] <ubitux> https://software.intel.com/sites/default/files/managed/a4/ed/palignr_w.png [12:05:34 CEST] <ubitux> my brain just went upside down [12:07:03 CEST] <Gramner> that's quite a horrible image [12:08:03 CEST] <nevcairiel> that image tells me nothing of how the instruction works :D [12:08:12 CEST] <Gramner> more readable to look up a 128-bit palignr instead, the 256-bit is just two separate 128-bit lanes anyway [12:08:37 CEST] <ubitux> http://www.officedaytime.com/tips/simdimg/palignr_1.png [12:08:41 CEST] <ubitux> makes more sense already [12:09:54 CEST] <Gramner> you basically concatenate the registers and pick out a 16-byte section starting at byte imm8 [12:10:05 CEST] <nevcairiel> i like how msdn has C code to explain it, r := (CONCAT(a, b) >> (ralign * 8)) & 0xffffffffffffffff [12:11:15 CEST] <nevcairiel> that still doesnt really explain the original image though [12:12:00 CEST] <nevcairiel> it looks like its done twice [12:12:03 CEST] <benoit-1> the coloring on the first line of the first image is strange [12:13:21 CEST] <benoit-1> (no actually, all this light blue vs. blue makes no sense :)) [12:16:01 CEST] <Gramner> it looks like someone used a 128-bit palignr as a base and extended it to 256-bit when making that image without bother to adjust the colors [12:16:46 CEST] <Gramner> because the colors in the first row makes sense if those were xmm registers. after that it's just a mess [12:17:33 CEST] <JEEB> :D [12:19:40 CEST] <nevcairiel> so vpalignr really just treats ymm like the two ymm regs are 4 xmm regs which it would use palignr on? that sure is confusing [12:20:14 CEST] <Gramner> 256-bit palignr really should've been made cross-lane, because it rarely makes sense to use it anywhere the way it currently is [12:21:06 CEST] <Gramner> blame Intel [12:21:26 CEST] <nevcairiel> avx2 seems like a rather lazy approach [12:21:31 CEST] <nevcairiel> concat two avx units, call it a day [12:21:48 CEST] <Gramner> I'm sure there are reasons [12:21:48 CEST] <nevcairiel> eh two sse units [12:28:56 CEST] <ubitux> what's the usage of palignr actually? doing some kind of ring buffer? [12:29:49 CEST] <wbs> similar to vext? [12:30:13 CEST] <wbs> i.e. shift elements, if I read the pictures right [12:45:54 CEST] <ubitux> in the vscale, offset is always 0 or 3? [13:47:02 CEST] <mateo`> Daemon404: I've probably missed your reply if any (my irc box went down) [14:01:54 CEST] <JEEB> was there a way to increase the verbosity for just a single demuxer? [14:01:58 CEST] <JEEB> or otherwise a single compnent [14:35:15 CEST] <cone-649> ffmpeg 03Alex Smith 07master:a677121cc568: configure: Fix debugging on mingw-w64 with gdb [14:43:08 CEST] <BBB> michaelni: poke [15:02:11 CEST] <michaelni> BBB, pong ? [15:02:39 CEST] <BBB> michaelni: so whos going to work on swscale? [15:03:02 CEST] <BBB> like, you really seem to like swscale. I think it needs tons of love to get that kind of status. who will do that work? [15:03:08 CEST] <BBB> (the loving) [15:03:57 CEST] <michaelni> i had hoped that a GSoC student would move it forward but i think noone submitted a proposal [15:04:28 CEST] <BBB> thats because it needs love [15:04:38 CEST] <wm4> BBB: swscale can't be saved [15:04:40 CEST] <BBB> you cant expect students to give it love; students have no background, they add some new features [15:04:41 CEST] <michaelni> pedro does work slowly on improving it it seems [15:04:52 CEST] <BBB> maintainers need to give it love, ideally the original developer(s) [15:04:58 CEST] <BBB> swscale needs massive amounts of love [15:05:02 CEST] <wm4> because it's not a code problem but a development problem [15:05:10 CEST] <kierank> wm4: ^ [15:05:13 CEST] <kierank> that [15:05:17 CEST] <BBB> wm4: I think it can be salvaged - Im not sure any of the original code will be left at the end [15:05:55 CEST] <michaelni> BBB with comments like wm4&kieranks i will not even think about touching the code, iam not enjoying this environment [15:06:08 CEST] <BBB> michaelni: but youre not talking to them, youre talking to me [15:06:15 CEST] <BBB> michaelni: and I didnt say we should rm -fr swscale [15:06:19 CEST] <BBB> michaelni: I just said it needs love [15:06:25 CEST] <michaelni> yes it does [15:06:34 CEST] <BBB> michaelni: so& who will give it that kind of love? [15:06:42 CEST] <wm4> michaelni: well it's because you actively resists any radical measures which might actually save swscale [15:06:44 CEST] <BBB> we need some maintainers stepping up the love game, otherwise it will go down the drain [15:07:08 CEST] <BBB> michaelni: did you ever read https://wiki.libav.org/Blueprint/AVScale ? (ignore the politics for now, focus on the technical complaints in the document) [15:07:43 CEST] <michaelni> i read it long ago [15:07:52 CEST] <michaelni> not recently if it changed [15:08:14 CEST] <BBB> I dont think it did [15:08:26 CEST] <BBB> so & lets say (hypothetically) that we wanted to salvage swscale [15:08:37 CEST] <BBB> can we totally redesign it? and will you actively help in coding it up? [15:09:35 CEST] <michaelni> iam happy if its totally redesigned, thats not a problem at all [15:10:10 CEST] <michaelni> i want the main practically used codepathes to stay fast though [15:10:40 CEST] <michaelni> a 5% slowdown should not happen [15:10:44 CEST] <BBB> well, theres many dimensions to the total set of problems in swscale& api is one, lack of integration with the rest of ffmpeg is another [15:10:56 CEST] <wm4> the first thing you'd have to accept to make progress at all (instead of burning developer time on all these crazy details every time someone dares to take a look at it) is (temporary) deoptimization [15:11:06 CEST] <nevcairiel> swscale isnt very fast to begin with [15:11:23 CEST] <nevcairiel> all its "fast" optimization are super low quality [15:11:28 CEST] <kierank> not true [15:11:40 CEST] <BBB> the internals are very & unextendable, which isnt necessarily a problem for corner case optimizations, but at this point, xyz support is a total hack, whereas if we are moving from to bt2020 support, we really should start thinking about xyz being a central component of the processing chain [15:12:02 CEST] <BBB> michaelni: obviously one thats skipped if its not necessary, but swscale as it is right now would be merely one of the steps [15:12:20 CEST] <BBB> michaelni: fast paths for direct conversions are obviously ok, but its mostly very static and unpredictable right now [15:12:38 CEST] Action: michaelni need to awnser apoe call iam bac in 5min [15:12:40 CEST] <BBB> michaelni: I still believe we go through a full yuv conversion and scaling path if we convert gbrp14 to gbrp12 [15:12:48 CEST] <BBB> ok [15:13:56 CEST] <kierank> anotherother big question is whether to include the pseudo pixel formats [15:14:06 CEST] <kierank> r210, v210 etc [15:14:16 CEST] <BBB> nevcairiel: most optimizations are from 1985, so theyre mmx (or sometimes mmx2) at best [15:14:46 CEST] <BBB> theres little bits of sse2/avx2 added by various people a few years ago [15:14:49 CEST] <BBB> and now finally some arm [15:14:56 CEST] <BBB> but its mostly still a mess [15:14:59 CEST] <ubitux> optimisation behaves strangely when constraints don't fit btw [15:15:32 CEST] <ubitux> like, it seems x86 yuv2rgb will just ignore the last pixels if linesizes are not enough [15:15:50 CEST] <kierank> the problem I hacked around is when doing chroma conversions swscale does a full luma multiply and shift which ends up being a NOOP [15:15:51 CEST] <ubitux> it would be great to have some kind of automatic c-fallback to fill the padding [15:15:54 CEST] <kierank> but burns an entire cpu core [15:16:01 CEST] <ubitux> and make sure all simd received aligned & padded stuff [15:16:59 CEST] <ubitux> btw, anyone for my vscale question earlier? in yuv2planeX, offset can only be 0 or 3? [15:17:17 CEST] <ubitux> (x86 simd seems to assume so, and it looks like it's the case in practice in my tests so far) [15:18:48 CEST] <BBB> ubitux: let me check [15:20:31 CEST] <ubitux> only one where it could not be 3 or 0 would be where it is use_mmx_vfilter ? (c->uv_offx2 >> 1) : 3 [15:20:31 CEST] <BBB> oh god the dithering [15:20:52 CEST] <ubitux> yes, dithering should be optional btw, it's badly done currently in the options [15:24:43 CEST] <BBB> ubitux: I dont know what uv_offx2 does ... [15:24:54 CEST] <ubitux> libswscale/utils.c: c->uv_offx2 = dst_stride + 16; [15:24:58 CEST] <durandal_1707> pile of hacks upon hacks let it rest in peace [15:25:11 CEST] <ubitux> durandal_1707: please be more constructive [15:25:26 CEST] <ubitux> we're not going to depend on an external lib for converts [15:26:08 CEST] <BBB> where is use_mmx_vfilter set? [15:26:48 CEST] <ubitux> libswscale/x86/swscale_template.c: c->use_mmx_vfilter= 1; [15:27:58 CEST] <ubitux> so, it can only be ` (0, 3) when this special yuv2yuvX function is used [15:28:06 CEST] <ubitux> so it shouldn't matter [15:28:40 CEST] <ubitux> i was surprised the other day when it was triggering this yuv2yuvX instead of the ff_yuv2planeX_{mmx,see,...} [15:28:47 CEST] <ubitux> (which also exists) [15:29:05 CEST] <ubitux> while it is triggering yuv2planeX_8_c when running on arm [15:29:14 CEST] <ubitux> (or basically with no asm) [15:29:51 CEST] <BBB> it seems we dont set the sse2 versions if this was already initialized [15:29:59 CEST] <BBB> that looks like a bug [15:30:06 CEST] <BBB> ../libswscale/x86/swscale.c: case 8: if ((condition_8bit) && !c->use_mmx_vfilter) vscalefn = ff_yuv2planeX_8_ ## opt; break; \ [15:30:18 CEST] <BBB> we should just force c->use_mmx_vfilter to 0? [15:30:21 CEST] <BBB> anyway [15:30:30 CEST] <BBB> yes youre right its only 0 and 3 then, for your use case [15:34:02 CEST] <BBB> ubitux: re simd behaving stragenyl, thats certainly something Id like to discuss with michaelni later on in this conversation [15:34:10 CEST] <BBB> ubitux: but lets start by keeping things simple [15:34:22 CEST] <durandal_1707> ubitux: I'm still waiting for nlmeans [15:34:53 CEST] <ubitux> yeah, i should get done with this one [15:36:13 CEST] <ubitux> BBB: btw, i agree with michaelni about having the colorspace convert in sws [15:36:16 CEST] <ubitux> since it's already there... [15:37:21 CEST] <BBB> what is already there? [15:37:47 CEST] <michaelni> BBB all scaling goes through yuv, unscaled rgb converts might be without yuv [15:38:07 CEST] <ubitux> BBB: SWS_CS_* :p [15:38:09 CEST] <michaelni> theres some avx in swscale [15:38:18 CEST] <BBB> lets do one dimension of this problem set at a time [15:38:56 CEST] <BBB> lets start with api: swscale api is from the 80s. it needs to die and the approach in the avscale blueprint isnt so bad. backwards compatibility to hell, no part of the public api (except maybe the version macros) should stay [15:39:00 CEST] <BBB> do you agree? [15:39:25 CEST] <ubitux> i think wm4 had a patch for that? [15:39:36 CEST] <ubitux> unless you're not talking about the AVFrame wrapping? [15:39:52 CEST] <BBB> the api should integrate with the rest of ffmpeg (e.g. use AVOptions, like swresample does; use AVFrame; etc.), and no context caching, sws_convertPalette8ToPacked24 or vector api [15:39:53 CEST] <michaelni> BBB the old API interface should be provided by using wrapers around the new [15:40:01 CEST] <BBB> no, the old api should just die [15:40:13 CEST] <ubitux> yeah i agree with deprecating the old api [15:40:15 CEST] <BBB> its useless and nobody wants it except mplayer, which is almost actual proof that it should die [15:40:18 CEST] <kierank> no kill the old api [15:40:20 CEST] <kierank> it's horrible [15:40:27 CEST] <kierank> which implies a new lib [15:40:34 CEST] <BBB> michaelni: I think you have pretty much consensus that the old api needs to die here [15:41:01 CEST] <michaelni> sure, if thats what people want [15:41:09 CEST] <BBB> michaelni: so, thats dimension 1. now, dimension 2: scaling stages& [15:41:18 CEST] <BBB> (Ill talk simd/platform ops later) [15:41:36 CEST] <BBB> so, right now, we have two kind of paths: direct conversions like yuv422p_to_yuyv [15:41:56 CEST] <BBB> and we have the scaled path, as invoked (iirc) by gbrp14 to gbrp12 [15:42:12 CEST] <BBB> (fortunately it uses a filter size of 1 so its not that bad, but still) [15:42:24 CEST] <BBB> we need a more generic approach to scaled path [15:42:29 CEST] <michaelni> yes [15:42:32 CEST] <BBB> I think avscale calls this kernels [15:42:56 CEST] <BBB> you can sort of see this in the colorspace thing also, although thats obviously fairly limited (on purpose) [15:43:06 CEST] <BBB> internal format should be dynamic, it cant be only yuv [15:43:12 CEST] <BBB> if input and output is xyz, that should be ok [15:43:30 CEST] <BBB> also, to go from rgb to rgb should not involve a yuv conversion, and xyz to rgb shouldnt either [15:43:36 CEST] <michaelni> it was planed since the 80ties that the internal format should be anything just wasnt ever done [15:43:49 CEST] <BBB> right, but so this is a component of major love" [15:44:02 CEST] <BBB> weve been saying for years that stuff needs to be done and nobody does it [15:44:35 CEST] <BBB> it may well be that a new approach will be so fundamentally different that we need new implementations of every simd function, and that pretty much all existing code will eventually be rewritten [15:44:41 CEST] <michaelni> also you(plural) should talk with pedro arthur he imlemented a more generic filter path last year [15:45:25 CEST] <michaelni> and that code is enabled and works but i think it itself needs cleanup and documentation [15:45:48 CEST] <BBB> a kernel style approach has issues btw, as can be seen in the avscale document [15:45:51 CEST] <ubitux> BBB: small parenthesis about xyz: it appears many people use lut3d to do the convert [15:45:57 CEST] <ubitux> (vf lut3d does that) [15:46:16 CEST] <ubitux> (i had a local patch to support xyz as input, needs to upstream it, but i have some format negociation issues) [15:46:30 CEST] <BBB> I actually wrote avscale years ago, long before libav started caring about it, I tihnk I talked about it on irc back then [15:46:51 CEST] Action: michaelni maybe wasnt on iRC back then :) [15:46:53 CEST] <BBB> the issue with kernels is that you tend to want to design it in such a way (naturally) that the number of memory intermediates goes up a lot compared to swscale [15:47:14 CEST] <BBB> so this needs to be designed by ery knowledgable people who understand performance [15:47:37 CEST] <BBB> and will end up with a lot of functions, some near-duplicates, to do the same thing, if you want the same performance as you have with swscale [15:47:40 CEST] <BBB> (in all cases) [15:47:47 CEST] <michaelni> BBB i think you absolutely must talk with pedro arthur about this [15:47:50 CEST] <BBB> so, lots of code, or slightly slower [15:48:17 CEST] <michaelni> as pedro did alot of work on swscale filter stuff and that is i think very similar to kernels [15:48:18 CEST] <BBB> (and you can see why I eventually threw my avscale out of the window, I just didnt care enough to write so much code) [15:48:58 CEST] <BBB> so, simd is largely a game about assumptions, right? as kierank sayd, we have tons of simd that doesnt work right on odd image sizes or non-multiple-of-4-s etc. [15:49:15 CEST] <BBB> a nice thing of a new api is that we can document assumptions [15:49:24 CEST] <BBB> e.g. buffers should have at least this much padding" [15:49:32 CEST] <BBB> and then just require that to be the case [15:49:47 CEST] <BBB> and then we can just overwrite in our simd instead of underconvert [15:49:59 CEST] <BBB> (or, worst of all, revert to C, which is just so ugly that I dont know what to say) [15:50:06 CEST] <BBB> (swscale does a combination of all 3) [15:50:17 CEST] <michaelni> the lack of SIMD assumtation docs is a real problem, yes [15:50:35 CEST] <michaelni> yes [15:50:38 CEST] <BBB> and about pedro& I can look back at what he did, but you see my point about students, right? this is the job of a maintiner, not a student [15:51:01 CEST] <BBB> if we want pedro to help discussing this, he should be here, or we should get him here. is he on irc? [15:51:10 CEST] <michaelni> pedro is no student anymore in the gsoc sense :) [15:51:22 CEST] <BBB> is he ready to be maintainer? [15:51:30 CEST] <michaelni> i suspect he isnt on irc but yes he should join ideally [15:51:57 CEST] <BBB> in the short term, none of this will happen, which is why I wrote the filter [15:52:11 CEST] <BBB> it fixes my immediate problem and will allow me to move forward with actual things Id like to do [15:52:25 CEST] <michaelni> i think he is ready but maybe he lacks confidence or maybe time i dont know [15:52:55 CEST] <michaelni> pedro agreed to co/backup mentor a swscale task if we had a student (which we dont) [15:53:30 CEST] <wm4> do [15:53:30 CEST] <wm4> *out-- = 0; [15:53:30 CEST] <wm4> while (out >= end && strspn(out, WHITESPACES)); [15:53:32 CEST] <wm4> is this ub? [15:53:44 CEST] <wm4> (end points to start of the memory alloc for out) [15:54:22 CEST] <michaelni> if out is ever pointing to 1 before the array then its UB [15:54:43 CEST] <wm4> this is from av_get_token() [15:56:41 CEST] <BBB> michaelni: is pedros filter chaining work documented anywhere? or where do I find it? [15:58:05 CEST] <BBB> ubitux: for video, I doubt people use xyz much, its primarily an image thing to actually ever want the data in xyz& but xyz is an intermediate useful to convert between various rgb chromaticity primaries (colorspaces) [15:59:59 CEST] <michaelni> BBB iam not sure its documented all that much, pedro last summer ended up doing more than i wanted and possibly good docs where one thing that he forgot [16:00:18 CEST] <BBB> where do I look for the code? [16:00:47 CEST] <BBB> I should make a wiki page out of this discussion so we can refer to it in future continuations [16:01:19 CEST] <michaelni> git log -p --author Arthur [16:02:45 CEST] <durandal_1707> I can help with coding if blueprints are there [16:13:55 CEST] <Shiz> wm4: sounds UB [16:14:21 CEST] <wm4> nothing like taking a superficial look at random C string processing code to find UB on the spot [16:16:10 CEST] <kierank> is it possible to write a decoder that allows a choice of output pixel formats [16:16:59 CEST] <jamrial> isn't that what -pix_fmt for the output stream is for? [16:17:28 CEST] <kierank> no that does a conversion [16:17:39 CEST] <wm4> kierank: get_format [16:17:40 CEST] <michaelni> kierank, from a API point of view the user app can tell the decoder via get_format() callback what format it wants [16:17:56 CEST] <wm4> specifically you pass a list to ff_get_format I think [16:18:46 CEST] <michaelni> the decoder passes a list of formats (possibly bitstream dependant) to the callback and the callback from the user app can then select one [16:19:09 CEST] <michaelni> i think hwaccel stuff is the only code that uses this though [16:19:28 CEST] <michaelni> but it was originally written with other uses in mind [16:19:34 CEST] <ubitux> we don't do this for audio (float vs int?) [16:19:41 CEST] <ubitux> +? [16:20:52 CEST] <michaelni> no but it would be rather simple to change that [16:21:29 CEST] <michaelni> only the argument type would be a annoying thing as get_format uses const enum AVPixelFormat * fmt [16:21:41 CEST] <michaelni> and not int * [16:24:03 CEST] <BBB> https://trac.ffmpeg.org/wiki/swscale ? [16:24:17 CEST] <BBB> please comment and so on [16:24:17 CEST] <michaelni> LGTM [16:24:26 CEST] <BBB> Id like to be able to use that as a reference for future discussions [16:27:41 CEST] <ubitux> BBB: about assembly, the unscaled path is actually very complex to handle [16:27:48 CEST] <ubitux> first, it has way too much arguments [16:28:06 CEST] <ubitux> 2nd, to workaround this, since it's using inline asm in x86, it passes the sws context [16:28:18 CEST] <ubitux> in which the fields are duplicated and directly readable [16:28:49 CEST] <BBB> I think we should add that, I hadnt complained that much about the unscaled optimizations yet, indeed [16:28:50 CEST] <ubitux> (by offsetting the context with some) [16:28:54 CEST] <BBB> but some of that code is hideous also [16:29:02 CEST] <ubitux> (with some +macro) [16:29:07 CEST] <BBB> yeah I remember [16:29:15 CEST] <BBB> the fast bilinear scaler is also very "interesting"" [16:29:21 CEST] <BBB> (its fast, I admit) [16:30:22 CEST] <ubitux> BBB: also slicing [16:30:31 CEST] <BBB> I have surprisingly few opinions on slicing [16:30:36 CEST] <BBB> some people seem to hate it, I dont really care [16:30:44 CEST] <ubitux> do you know how it's done currently? [16:30:55 CEST] <BBB> roughly, yes [16:31:22 CEST] <BBB> I wonder if it isnt easier if slicing was done internally and externally it just had a -threads parameter that users can set [16:31:36 CEST] <ubitux> it's not threadable slicing, it's just for the destination [16:31:53 CEST] <BBB> I always thought it was for threading [16:31:58 CEST] <ubitux> no [16:32:02 CEST] <BBB> :-p [16:32:11 CEST] <BBB> well good thing I had no opinion on it I guess [16:32:38 CEST] <ubitux> apparently it was about some cache locality of some sort [16:32:50 CEST] <michaelni> btw as slicing is mentioned, theres the use case where the whole image doesnt fit in memory (gimp does that) this may be worth a thought in case of a redesign [16:33:37 CEST] <ubitux> michaelni: doesn't work by squares? [16:33:39 CEST] <ubitux> only slices? [16:34:05 CEST] <ubitux> photoshop works by big blocks (call it tiles/squares/bigblocks/whatever) [16:34:06 CEST] <michaelni> to clarify we dont support that currently, gimp uses its own scaler [16:34:29 CEST] <michaelni> i just saw that gimp caching code a long time ago (which used squares) [16:34:43 CEST] <michaelni> or rectangles dont remember [16:36:20 CEST] <michaelni> also some kind of square / slice /tiling for multitreading is probably "important" [16:37:52 CEST] <ubitux> yeah [16:37:59 CEST] <ubitux> BBB: about the poor api, let's talk about the options... [16:38:16 CEST] <ubitux> dithering configuration is broken [16:38:22 CEST] <BBB> hm, dithering [16:38:28 CEST] <ubitux> like, you haven't a dither=none [16:38:33 CEST] <ubitux> it's just enabled, sometimes [16:38:36 CEST] <ubitux> (0=auto) [16:38:43 CEST] <BBB> yeah, nobody knows when its enabled [16:38:44 CEST] <michaelni> btw, iam not sure though how important/usefull such non memory squares are ... [16:38:57 CEST] <ubitux> also the scaler selection mixed within flags [16:39:23 CEST] <BBB> the avscale blueprint is pretty good at explaining that, the filter selection should be an enum [16:39:26 CEST] <BBB> (AVOption) [16:39:35 CEST] <BBB> and the rest of the flags can just be bools or whatevers as separate options [16:39:51 CEST] <BBB> I Guess pre-AVOption extending api was hard so this made sense, but with AVOption we realy dony need it anymore [16:39:57 CEST] <ubitux> small nit: wth are param0 and param1 [16:40:04 CEST] <BBB> hahaha right [16:40:14 CEST] <BBB> they are options for some filters [16:40:20 CEST] <BBB> wasnt it alpha/beta for one of the larger filters? [16:40:25 CEST] <ubitux> error_diffusion belongs to dithering btw [16:40:31 CEST] <ubitux> it's currently a sws falgs [16:40:49 CEST] <ubitux> what are the implication of accurate_rnd too [16:40:50 CEST] Action: michaelni doesnt remember exactly what param0 and 1 did for each filter but yes they where filter params [16:41:08 CEST] <BBB> For SWS_BICUBIC param[0] and [1] tune the shape of the basis function, param[0] tunes f(1) and param[1] fŽ(1) | For SWS_GAUSS param[0] tunes the exponent and thus cutoff frequency | For SWS_LANCZOS param[0] tunes the width of the window function [16:41:35 CEST] <ubitux> no other comment so far [16:41:56 CEST] <michaelni> these all should be AVOptions [16:42:00 CEST] <BBB> theres also SWS_FULL_CHR_H_INT/INP [16:42:19 CEST] <BBB> in fact, I just noticed SWS_DIRECT_BGR, ... [16:43:10 CEST] <BBB> I believe int/inp had to do with non-420p support [16:43:15 CEST] <BBB> (I mean, practically speaking) [16:43:35 CEST] <BBB> doesnt accurate_rnd increase precision of some internal codepath/something? [16:43:43 CEST] <ubitux> small note: there are a few dithering algorithms in vf paletteuse filter [16:43:59 CEST] <michaelni> BBB, yes accuarte_rnd uses more accurate code [16:44:18 CEST] <michaelni> IIRC no pmulhw [16:44:35 CEST] <michaelni> which would loose the lsbs [16:44:35 CEST] <ubitux> it has different meaning depending on the codepath [16:44:40 CEST] <BBB> I think its totally fine to basically eliminate all these flags and go back to lets just make it do the right thing [16:44:43 CEST] <ubitux> it's not well defined [16:44:59 CEST] <BBB> I can see how pmulh(u)w was critically important for performance in the mplayer era [16:45:09 CEST] <BBB> I think its totally fair to say that with axv2, it is not all that relevant anymore [16:45:19 CEST] <ubitux> it's used between 32 vs 16 in some rgb code iirc [16:45:38 CEST] <BBB> I also wonder if half of the filters should be deleted [16:45:53 CEST] <BBB> like sinc, gauss [16:46:01 CEST] <BBB> maybe even fast-bilinear [16:46:09 CEST] <BBB> (that would clean up the code so much) [16:46:27 CEST] <michaelni> the filters like sinc gauss should have nearly no complexity as its just different numbers [16:46:35 CEST] <BBB> its user complexity [16:46:46 CEST] <BBB> we should expose the ideal configuration settings to our user [16:47:01 CEST] <BBB> when to use spline or lanczos: when upscaling [16:47:06 CEST] <BBB> (and caring about quality) [16:47:17 CEST] <BBB> when to use bicublin: when speed is critical and youre downscaling [16:47:21 CEST] <BBB> thats very helpful to end users [16:47:28 CEST] <BBB> when to use gaussian? [16:47:33 CEST] <BBB> I dont know& I dont think anyone knows [16:47:34 CEST] <michaelni> with scalig different people will want different options and some people just like to have the choice [16:47:44 CEST] <ubitux> i'd keep the different filters [16:47:55 CEST] <ubitux> it's useful to make various visual comparison [16:48:22 CEST] <michaelni> sinc is something that some people "know" is best until they try it [16:48:31 CEST] <ubitux> :D [16:48:36 CEST] <BBB> but doesnt that mean we should remove it? [16:48:39 CEST] <BBB> why keep the option there [16:48:54 CEST] <ubitux> people will bug you to implement it because it's the perfect filter [16:48:56 CEST] <nevcairiel> many of the various filters are just different kernels over the same kind of filter, so preserving them costs you practically nothing [16:48:59 CEST] <BBB> do you know how many people thought x264 was the best encoder in the world but they were using it with default ffmpeg parameters (instead of presets)? [16:49:16 CEST] <ubitux> so you have it to show them it's shit, or just as a visual demonstration (educative purpose, experiment, ...) [16:49:24 CEST] <michaelni> its very important that the defaults are good [16:49:36 CEST] <BBB> I guess as long as defaults and documentation is good, I dont mind [16:49:41 CEST] <BBB> but documentation is not good right now :D [16:50:47 CEST] <michaelni> the docs need some love, i could probably help with that if theres a list of what needs new/better docs [16:51:08 CEST] <fritsch> michaelni: "sinc" <- one still learns that in university, that's why [16:51:47 CEST] <av500> avscale [16:52:17 CEST] <av500> /undo [16:52:21 CEST] <Shiz> BBB: alternatively, pseudo-filter names like 'upscale' and 'downscale' that are just aliases for whatever is best [16:52:26 CEST] <nevcairiel> a perfect sinc filter is perfect - a windowed sinc is just an approximation =p [16:52:47 CEST] <BBB> hm, filter presets [16:53:18 CEST] <michaelni> fritsch, yes, its true what one learns but sinc results from some axioms and these dont apply that way to images [16:53:20 CEST] <ubitux> what's the filter window used in sws? is there such concept? [16:55:28 CEST] <fritsch> the raspberry pi people that implemented one from scratch decided to go for a special weighted bicubic filter [16:55:40 CEST] <fritsch> cause of implementation details / performance quality [16:56:11 CEST] <fritsch> kodi's lanczos3 filter needs quite a bit oomph and for example a hsw gpu is too slow to do 50 fps from 1080 to 4k [16:57:14 CEST] <wm4> fritsch: does kodi's scale width and height separately? [16:58:53 CEST] <fritsch> pi uses mitchell-natravali iirc, so the default most likely also ffmpeg uses [16:59:26 CEST] <fritsch> wm4: i need to look in detail, we use a pseudo separated filter [16:59:29 CEST] <fritsch> so most likely no :-) [16:59:34 CEST] <fritsch> but wait a mo [16:59:47 CEST] <fritsch> it's from a time where you did not have a float intermediate buffer in the gpu [16:59:58 CEST] <fritsch> or where that extension was "patented" by someone [17:01:13 CEST] <BBB> so this may just be me, but I tend to think that swscale should be software. Im all for doing things in hardware, but I dont know if we should make swscale more complex for that [17:01:26 CEST] <BBB> or, rather, I wouldnt know how to do it so it makes no sense for me to design it [17:01:33 CEST] <BBB> I dont even know if the concept makes any sense at all [17:01:49 CEST] <fritsch> wm4: it uses a 4x4 convolution shader at the end [17:01:57 CEST] <fritsch> wm4: so "no" to your question [17:02:24 CEST] <fritsch> BBB: shaders are really, really mighty especially for convolution [17:02:31 CEST] <fritsch> i don't see a point doing that on the cpu [17:02:46 CEST] <BBB> I know shaders, I love them [17:03:02 CEST] <BBB> but my point is more about do you want to use the swscale api if youre going to scale stuff in hardware? [17:03:03 CEST] <nevcairiel> shaders work fine if you already have the image on the gpu [17:03:16 CEST] <nevcairiel> if you dont, its a lot of overhead and potentially not worth it [17:03:31 CEST] <BBB> Im not saying you shouldnt scale in hw; you should, totally! [17:03:44 CEST] <BBB> Im just wondering if swscale is the ideal place to serve as an intermediate layer [17:03:46 CEST] <wm4> fritsch: separating them makes it quite a bit faster [17:03:50 CEST] <fritsch> jep [17:04:00 CEST] <fritsch> but you need a float intermediate buffer [17:04:02 CEST] <fritsch> to do so [17:04:24 CEST] <fritsch> which we did not have (on all gpus) at this time [17:04:44 CEST] <fritsch> iirc gwenole also implemented his lanczos3 in libva without separated kernels [17:04:55 CEST] <Daemon404> nevcairiel, do you know what's left to do on codecpar except xmv and converting the few files left to use it? [17:04:57 CEST] <wm4> fritsch: no you don't [17:05:13 CEST] <fritsch> wm4: then you loose information [17:05:22 CEST] <wm4> nonsense [17:05:33 CEST] <nevcairiel> Daemon404: besides careful squashing, separating a bunch of the changes that should remain standalone, and a proper and complete review? :) [17:05:39 CEST] <fritsch> nonsense :-) [17:05:54 CEST] <fritsch> come one doing a float multiplication and storing in non float intermediate buffer [17:05:54 CEST] <Daemon404> nevcairiel, is ffmpeg capable of "proper and complete review" of this if we send it to the ML [17:05:59 CEST] <fritsch> drives the separation nuts [17:06:04 CEST] <Daemon404> or will be it a anti-libav circlejerk [17:06:07 CEST] <wm4> a 16 bit fixed point buffer preserves more information than a 16 bit float buffer [17:06:18 CEST] <ubitux> Daemon404: ml endless review [17:06:20 CEST] <nevcairiel> Daemon404: dont care about the ML, but I want to review myself when its squashed [17:06:21 CEST] <phh> but obviously it's better for your start of day [17:06:23 CEST] <ubitux> or inactivity [17:06:26 CEST] <Daemon404> nevcairiel, ok sure [17:06:37 CEST] <Daemon404> i am happy to do the squashing and conversions of left over files [17:06:48 CEST] <ubitux> Daemon404: pretty sure 3-4 developers on github will be enough of a review [17:06:48 CEST] <Daemon404> im excited it's nearing a "end" [17:07:02 CEST] <Daemon404> ubitux, all righty [17:07:06 CEST] <nevcairiel> should go through the list first, some of those commits should be pulled out first [17:07:19 CEST] <nevcairiel> i did some myself that changed unrelated parts to be compatible with codecpar more easily [17:07:20 CEST] <fritsch> wm4: then you need to scale appropriately twice [17:07:29 CEST] <Daemon404> nevcairiel, those can be sent [17:07:29 CEST] <fritsch> e.g. scale the filter weights [17:07:34 CEST] <fritsch> and inverse at the end [17:07:35 CEST] <Daemon404> but i think sending the whole thing to the list is a death sentence [17:07:47 CEST] <nevcairiel> indeed, just avoid that nightmare [17:08:10 CEST] <wm4> Daemon404: agreed [17:08:43 CEST] <Daemon404> all right [17:08:48 CEST] <Daemon404> i will trudge on converting stuff [17:09:01 CEST] <Daemon404> i tired xmv but didnt get anywhere [17:09:05 CEST] <Daemon404> tried* [17:12:58 CEST] <fritsch> wm4: do you have one separated in mpv? and a link handy for me? [17:13:43 CEST] <wm4> fritsch: yes... well it's a common technique (even libswscale does it), and the code is all there [17:15:28 CEST] <Daemon404> ill do all the suqashing and rebasing this weekend (or tomorrow if ready( if you guys can figure out xmv [17:20:32 CEST] <mateo`> I guess it's not the right time to ping the mediacodec/hwaccel patch ? (and is something that will happen after the codecpar merge ?) [17:21:53 CEST] <Daemon404> mateo`, ping! [17:22:06 CEST] <Daemon404> there's a problem with the api test you added to fate [17:22:14 CEST] <Daemon404> it accesses non-public API and structs [17:22:33 CEST] <Daemon404> (i ran into this curing tep2 merge) [17:24:27 CEST] <mateo`> Daemon404: is that also a problem accessing this field from lavf/utils.c ? [17:24:50 CEST] <Daemon404> i dont think it does post-merge, but i need to check [17:25:02 CEST] <Daemon404> because accessing stream->codec is going away in lavf [17:25:10 CEST] <Daemon404> unless it is the avctx used inside find_stream_info [17:25:13 CEST] <Daemon404> then it is ok [17:25:32 CEST] <Daemon404> but it's definitely not ok to access codec_internal in public api tests [17:25:39 CEST] <Daemon404> "internal" in the name. [17:25:40 CEST] <mateo`> if (st->codec->codec->caps_internal & FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM) { [17:25:46 CEST] <mateo`> I do this in lavf/utils.c [17:25:52 CEST] <ubitux> the purpose of these tests is to make sure the information is filled without decode [17:26:00 CEST] <Daemon404> yeah thats not really ok [17:26:58 CEST] <Daemon404> ubitux, not really an api test then [17:26:59 CEST] <mateo`> Daemon404: there is also another issue in the fate test (this one is documented), i write into st->codec_info_nb_frames [17:27:02 CEST] <Daemon404> because the user cannot access that. [17:27:21 CEST] <ubitux> Daemon404: it's testing find_stream_info api [17:27:33 CEST] <Daemon404> ubitux, thats nice, but it is testing a non-accessible property [17:27:37 CEST] <Daemon404> thats not an *API* test [17:27:40 CEST] <Daemon404> because its not availabel via api [17:28:16 CEST] <mateo`> Daemon404: would it be ok to move the test to another category ? ("internal" tests ?) [17:28:31 CEST] <ubitux> rename it notapi [17:28:32 CEST] <Daemon404> mateo`, can probably move it to utils-test.c or something in lavf [17:28:34 CEST] <Daemon404> we have a lot of those [17:28:48 CEST] <Daemon404> but the issue is still accessing avcodec-internal stuff from not-avcodec [17:28:57 CEST] <Daemon404> it may be worth addign an accessor function? [17:29:04 CEST] <Daemon404> why does avf need to know a codec flag anyway [17:29:31 CEST] <wm4> it checks whether the decoder can act as a parser [17:29:46 CEST] <mateo`> to know if it can tell the decoder to not decode a frame (while the decoder still sets the width/height/pixfmt/sar/...) [17:30:12 CEST] <Daemon404> seems like a hack to me [17:30:15 CEST] <mateo`> it is [17:30:39 CEST] <mateo`> the proper "fix" is relying on parsers to get those info, but that is a lot of work [17:30:41 CEST] <Daemon404> ideas for solution? avpriv_do_i_have_some_flag? [17:30:59 CEST] <Daemon404> theres a few places in lavf flags are checked i need to fix for tep2 [17:31:05 CEST] <Daemon404> but it's all for very.... interesting... uses [17:31:12 CEST] <Daemon404> that i'd rather get rid of, but people would revolt [17:31:15 CEST] <Daemon404> and lynch me [17:32:00 CEST] <BBB> michaelni: and I assume you dont mind the filter as a stopgap solution - given that swscale-style will take a while? [17:34:09 CEST] <mateo`> Daemon404: avpriv_do_i_have_some_flag would require for those flags definition to be public (they are currently included via libavcodec/internal.h) [17:34:29 CEST] <ubitux> BBB: +#include "libavcodec/bit_depth_template.c" [17:34:34 CEST] <ubitux> missing file? [17:34:52 CEST] <Daemon404> mateo`, any ideas then? It's no longer "ok" to access the stream->codec member in lavf soon. [17:34:59 CEST] <ubitux> oh my bad [17:35:02 CEST] <ubitux> it's already upstream [17:35:02 CEST] <Daemon404> i could add a 'flags' member to codecpar [17:35:05 CEST] <Daemon404> but that seems... wrong [17:36:53 CEST] <BBB> ubitux: :D [17:37:26 CEST] <mateo`> Daemon404: it could be a temporary solution but would still require to include libavcodec/internal.h to know those flags [17:37:46 CEST] <Daemon404> mateo`, a temporary solution would also be to just surround it in deprecation guards [17:37:50 CEST] <Daemon404> and pray it can be properly fixed [17:38:27 CEST] <mateo`> but again, it seems wrong in the first place to use a decoder to get codec information (such as width/height/pix_fmt/sar) [17:38:27 CEST] <ubitux> BBB: i think lavfi can have negative stride [17:38:35 CEST] <ubitux> so you might not be able to do stride << x [17:38:48 CEST] <ubitux> (but stride * (1<<x)) [17:38:50 CEST] <BBB> right [17:38:50 CEST] <wm4> mateo`: that's why we have parsers [17:38:56 CEST] <Daemon404> mateo`, the alernative is to write a parser for *every* codec that needs it [17:39:03 CEST] <wm4> and I've mentioned the solution via parser [17:39:06 CEST] <BBB> can you comment on list? Ill fix [17:39:09 CEST] <Daemon404> while nice, i cant see that ever happening [17:39:12 CEST] <ubitux> BBB: you might be able to trigger negative linesizes with hflip [17:39:23 CEST] <ubitux> BBB: yeah i'll do a proper review later [17:39:26 CEST] <mateo`> I know, but this work just need to happen ... [17:39:29 CEST] <BBB> ty [17:39:40 CEST] <mateo`> we already discussed it [17:39:53 CEST] <Daemon404> so what would you suggest we do in the meantime [17:41:35 CEST] <mateo`> I would be OK with an accessor as you mentionned [17:43:32 CEST] <kierank> peloverde: ever tried emailing qticefloe(a)apple.com for old times sake [17:43:46 CEST] <mateo`> I will try to figure out a solution using parsers for avformat_find_stream_info [17:44:26 CEST] <Daemon404> ok [17:44:46 CEST] <Daemon404> nevcairiel / wm4 - xmv may be wasier to fix than we thought [17:44:53 CEST] <Daemon404> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/wmv2dec.c#L125 [17:44:57 CEST] <Daemon404> this is the only place it is used [17:46:03 CEST] <BBB> ubitux: fixed locally [17:51:53 CEST] <michaelni> BBB, sure ok [18:01:49 CEST] <BBB> michaelni: for vector api, can you put the api and implementation under a version macro so they automatically disappear upon next version bump? [18:01:57 CEST] <BBB> (and thanks for patch) [18:04:34 CEST] <wm4> heh I thought mplayer used this [18:04:34 CEST] <Daemon404> wm4, can you upload that mov/vp6 somewhere and push a ref change [18:04:46 CEST] <wm4> Daemon404: give me a moment [18:04:54 CEST] <Daemon404> if there is an api, mplayer uses it [18:05:01 CEST] <Daemon404> even if its not public [18:05:07 CEST] <Daemon404> and the api was probably added just for mplayer [18:06:08 CEST] <wm4> Daemon404: https://0x0.st/PA8.mov [18:06:34 CEST] <Daemon404> thanks [18:07:18 CEST] <Daemon404> also, there's surprisingly little code left unconverted to codecpar [18:07:28 CEST] <Daemon404> but a few wtf things [18:07:52 CEST] <wm4> I'll push the ref change [18:08:44 CEST] <Daemon404> i am hopeful i can start squashing very soon [18:08:52 CEST] <Daemon404> and the worst part of the saga will be over [18:10:06 CEST] <wm4> such a nightmare [18:11:46 CEST] <Daemon404> hence i am keen on finishing it [18:11:58 CEST] <Daemon404> all the changes have been for the better [18:12:15 CEST] <Daemon404> it's been painful because the task was basically "fix a shitload of hacks in ffmpeg in a correct way" [18:13:34 CEST] <wm4> yeah [18:14:07 CEST] <wm4> too bad ffmpeg's style is adding bad hacks to fix single samples... [18:14:18 CEST] <BBB> hey Daemon404 did I mention I went to bathtub gin the other day? [18:14:22 CEST] <BBB> its a really nice place [18:14:23 CEST] <Daemon404> how was it [18:14:26 CEST] <Daemon404> oic [18:14:30 CEST] <wm4> to a degree it's understandable and even wanted, but there's a limit [18:14:31 CEST] <BBB> the food is surprisingly good for a bar [18:14:35 CEST] <Daemon404> and to think i lived accross from it for 9 months [18:14:36 CEST] <BBB> and the drinks are great [18:14:37 CEST] <Daemon404> and never went [18:14:42 CEST] <BBB> boo [18:14:49 CEST] <BBB> well go next time youre here [18:14:56 CEST] <Daemon404> thats soon ;P [18:14:57 CEST] <BBB> like a thanks for merging codecpar [18:14:57 CEST] <BBB> or so [18:15:03 CEST] <BBB> when soon? [18:15:10 CEST] <Daemon404> may 1st until may 13th [18:15:15 CEST] <BBB> oh thats not soon [18:15:17 CEST] <BBB> ok [18:15:22 CEST] <Daemon404> "soon" [18:15:37 CEST] <Daemon404> i'd buy everyone who helped merge a drink or something [18:15:41 CEST] <Daemon404> but a few them dont show up to events [18:15:42 CEST] <Daemon404> :P [18:17:52 CEST] <BBB> thats fine also [18:17:56 CEST] <BBB> do they live nearby? [18:20:05 CEST] <Daemon404> BBB, no [18:20:07 CEST] <Daemon404> i meant in general [18:20:23 CEST] <Daemon404> at VDD or somesuch [18:24:16 CEST] <peloverde> kierank: No I haven't, qticefloe was mostly defunct by the time I started multimedia programming [18:24:43 CEST] <Daemon404> peloverde, thats cant be right... it was useful when i started, and that was later than you [18:24:48 CEST] <Daemon404> mostly for the various pix formats [18:25:47 CEST] <peloverde> The old stuff was still useful for quite a while, but I think the last post was around '01 [18:32:29 CEST] <Daemon404> indeed [18:35:07 CEST] <kierank> peloverde: I want to email it just because [18:36:33 CEST] <peloverde> go for it [18:45:44 CEST] <Daemon404> ... wtf [18:45:56 CEST] <Daemon404> im trying to delay xmv stream creation until a packet is read [18:46:04 CEST] <Daemon404> but xmv_read_packet is *never called* during find_stream_info! [18:46:20 CEST] <wm4> wat [18:46:29 CEST] <Daemon404> ikr [18:46:38 CEST] <wm4> what's the fate test for this again? [18:46:51 CEST] <Daemon404> fate-demux-xmv [18:47:26 CEST] <Daemon404> i added a printf to the read_packet function and it never prints [18:48:04 CEST] <wm4> actually it's fate-xmv-demux [18:48:16 CEST] <Daemon404> (i removed the avformat_new_stream calls in read_header) [18:48:55 CEST] <wm4> did you set the NOHEADEr flag? [18:49:02 CEST] <Daemon404> oh! [18:49:03 CEST] <Daemon404> i didnt know [18:50:37 CEST] <Daemon404> i should be able to fix this now [19:15:03 CEST] <BBB> michaelni: is SwsVector still a header existing in public headers after your change? [19:15:53 CEST] <BBB> I guess it has to be b/c of SwsFilter, right? [19:16:02 CEST] <BBB> michaelni: I think patch is fine then, at least its progress, tnx [19:21:16 CEST] <Daemon404> nevcairiel / wm4 - xmv is fixed [19:21:33 CEST] <Daemon404> fate is all passes now. [19:22:14 CEST] <JEEB> wohoo [19:25:52 CEST] <Daemon404> also ubitux [19:27:54 CEST] <Daemon404> i will convert what i can that is left [19:28:37 CEST] <Daemon404> help sending bits that cant be sent to the ML welcome [19:29:00 CEST] <Daemon404> (although everyone seems stuck permanently in 'no time to do anything' zone :/) [19:31:40 CEST] <Daemon404> ... [19:31:41 CEST] <Daemon404> av_freep(&s->streams[i]->codec->rc_eq); [19:31:45 CEST] <Daemon404> what the hell ffmdec [19:32:28 CEST] <JEEB> lol [19:34:06 CEST] <wm4> Daemon404: awesome [19:34:23 CEST] <wm4> and I don't think there's a single line of ffserver related code that is sane [19:34:32 CEST] <Daemon404> no of course not [19:39:18 CEST] <Daemon404> i think i can maybe have codec use cleaned up by the endo f today [19:39:20 CEST] <Daemon404> pretty excited. [19:46:29 CEST] <Daemon404> only 3 files left [19:46:41 CEST] <Daemon404> ffm, mux, and sdp [19:55:58 CEST] <BBB> ffm \o/ [19:56:12 CEST] <Daemon404> mux is almost fixed [19:56:16 CEST] <Daemon404> now sure wtf to do about ffm [19:56:22 CEST] <Daemon404> nevcairie handled the other ffm thing [19:56:36 CEST] <BBB> I was hoping to help by bringing sanity into sws design [19:56:38 CEST] <BBB> but maybe not [19:56:46 CEST] <BBB> lavf is just not my thing, sorry [19:57:58 CEST] <Daemon404> ffm isnt even lavf IMO [19:58:01 CEST] <Daemon404> it's a shitty ffserver hack [20:00:12 CEST] <wm4> Daemon404: let the maintainer of ffserver handle it [20:00:26 CEST] <wm4> after the merge [20:00:36 CEST] <Daemon404> right [20:00:37 CEST] <Daemon404> ok [20:01:49 CEST] <JEEB> > ffserver > maintainer [20:02:08 CEST] <wm4> and if there's drama this decision has backing by Daemon404 nevcairiel ubitux BBB and me I suppose? [20:02:19 CEST] <BBB> we have logs [20:02:32 CEST] <BBB> oh you mean nobody approved it"? [20:02:42 CEST] <BBB> github link? [20:02:43 CEST] <BBB> Ill review [20:02:50 CEST] <wm4> ffserver: [20:02:50 CEST] <wm4> ffserver.c Reynaldo H. Verdejo Pinochet [20:03:37 CEST] <rcombs> why does ffserver even exist [20:03:49 CEST] <rcombs> or, if it's going to exist, why is it part of the main repo [20:04:37 CEST] <j-b> for the same reason as usual? [20:07:59 CEST] <wm4> it was added, thus it shall not be removed [20:08:06 CEST] <wm4> for every code is holy [20:08:21 CEST] <wm4> every code is sacred [20:09:01 CEST] <BBB> :D [20:10:26 CEST] <fritsch> i know that song [20:10:43 CEST] <fritsch> probably will play it with my new: wireless power plug [20:10:45 CEST] <fritsch> https://scontent-ams3-1.xx.fbcdn.net/hphotos-xpt1/t31.0-8/12901122_10553781… [20:12:16 CEST] <wm4> can't it fry birds? otherwise I don't want it [20:12:20 CEST] <durandal_1707> with what? [20:12:29 CEST] <wm4> with that [20:12:46 CEST] <fritsch> :-) [20:12:56 CEST] <fritsch> it's a fake (of course) but nicely made [20:14:01 CEST] <Daemon404> think i fixed mux.c... fate running [20:14:03 CEST] <Daemon404> home stretch [20:18:05 CEST] <Zeranoe> Does $arch in configure default to x86 if it isn't specified and a native compile is being preformed? I don't see it using uname or anything [20:25:09 CEST] <Daemon404> nevcairiel / wm4 - how well do you understand bitstream filters [20:25:15 CEST] <Daemon404> thats teh only ting left in mux.c to fix [20:25:25 CEST] <Daemon404> i tried two ways that changed output [20:25:29 CEST] <wm4> not too well [20:25:38 CEST] <wm4> what's broken at all? [20:26:05 CEST] <Daemon404> av_apply_bitstream_filters(st->codec, pkt, st->internal->bsfc); [20:26:06 CEST] <Daemon404> in mux.c [20:26:20 CEST] <wm4> is that something ffmpeg-original? [20:26:23 CEST] <Daemon404> if i make a new avctx based on codecpar, or use the internal avctxs it has different output [20:26:30 CEST] <nevcairiel> just do some intermediate fix, new bsf api doesnt need avcodec [20:26:39 CEST] <nevcairiel> +context [20:26:46 CEST] <durandal_1707> Different how? [20:26:56 CEST] <Daemon404> nevcairiel, there is no immediate fix [20:26:56 CEST] <nevcairiel> wm4: and yes, its part of rcombs' auto filtering [20:27:18 CEST] <Daemon404> nevcairiel, should i just leave the warning [20:27:22 CEST] <Daemon404> and fix it when i merge the new bsf api? [20:27:32 CEST] <wm4> that sounds good [20:27:59 CEST] <michaelni> BBB, ive deprecated the functions which are unused outside in that first step. To get rid of the SwsVector and filter structs some suggestion is needed what to do instead. Theres some code that uses these features [20:29:46 CEST] <BBB> you can keep the structs [20:30:06 CEST] <michaelni> ok [20:36:06 CEST] <BBB> I believe that ubitux and a few others here expressed interest in designing a more standard API interface that could replace the current one [20:36:17 CEST] <BBB> Im more interested in the inner guts of things, so Id probably want to do that kind of work [20:37:58 CEST] <Daemon404> wm4 / nevcairiel - just sdp.c left.. any ideas besides "shove it in side data"? [20:38:46 CEST] <wm4> which part of it? [20:38:50 CEST] <wm4> the speex crap? [20:38:53 CEST] <Daemon404> yes [20:39:04 CEST] <wm4> oh god [20:40:50 CEST] <Daemon404> im not even sure i can use side data, since that requires access to either the stream or packets [20:40:56 CEST] <Daemon404> and im not sure it has a packet by then [20:41:07 CEST] <wm4> what does it even _do_ [20:41:27 CEST] <Daemon404> sdp: output speex optional vbr parameter [20:41:27 CEST] <Daemon404> Optional sdp speex payload parameter is outputed only when [20:41:27 CEST] <Daemon404> data is encoded. It's not printed in case of stream copy. [20:41:30 CEST] <Daemon404> according to git. [20:41:38 CEST] <wm4> ah [20:41:47 CEST] <Daemon404> vbr=on/vad/off [20:41:53 CEST] <Daemon404> it looks a bit wtf [20:41:57 CEST] <Daemon404> it is checking options on st->codec [20:42:01 CEST] <Daemon404> but if youre not using that to encode [20:42:04 CEST] <Daemon404> it wont even work. [20:42:07 CEST] <wm4> so it needs to know how it was encoded [20:42:26 CEST] <Daemon404> the code didnt even work with proper api usage [20:42:32 CEST] <Daemon404> in the first place [20:42:33 CEST] <Daemon404> >_> [20:42:43 CEST] <wm4> so awesome [20:42:45 CEST] <cone-919> ffmpeg 03Michael Niedermayer 07master:3b905b9fe611: swscale: Deprecate vector functions which are unused outside swscale [20:43:03 CEST] <Daemon404> what is one to do in such a case [20:43:10 CEST] <wm4> clearly there should be codecpar side data [20:43:52 CEST] <Daemon404> i dont even know how one would fix it [20:44:05 CEST] <Daemon404> considering it was broken to begin with [20:45:23 CEST] <Daemon404> :/ [20:45:46 CEST] <wm4> does it break fate? [20:45:51 CEST] <Daemon404> no [20:46:02 CEST] <wm4> then fuck it and send the author of that patch a mail [20:46:15 CEST] <Daemon404> all right [20:46:22 CEST] <Daemon404> then merge fixup is done. [20:46:31 CEST] <Daemon404> unless i am missing something [20:46:39 CEST] <Daemon404> (and squashign and sending bits can begin) [20:46:42 CEST] <durandal_1707> what's wrong with sdp? [20:46:53 CEST] <wm4> durandal_1707: muxer tries to access encoder options [20:47:28 CEST] <durandal_1707> huh? [20:47:36 CEST] <wm4> what huh [20:51:08 CEST] Action: Daemon404 pings nevcairiel to point out some patches to send (unless you marked them obviously already) [21:03:48 CEST] <michaelni> Daemon404, "Test dca-core failed. Look at tests/data/fate/dca-core.err for details." "Assertion avctx->codec_id == s->parser->codec_ids[0] || avctx->codec_id == s->parser->codec_ids[1] || avctx->codec_id == s->parser->codec_ids[2] || avctx->codec_id == s->parser->codec_ids[3] || avctx->codec_id == s->parser->codec_ids[4] failed at libavcodec/parser.c:149" [21:04:24 CEST] <michaelni> try codecpar with --assert-level=2 [21:08:00 CEST] <Daemon404> michaelni, all right [21:08:13 CEST] <Daemon404> im preparing a small set that is independant right now [21:08:17 CEST] <Daemon404> ill look after [21:08:27 CEST] <Daemon404> jamrial, ping [21:09:28 CEST] <Daemon404> gmm nvm [21:14:40 CEST] <nevcairiel> Daemon404: will look those over tomorrow morning and send them [21:16:03 CEST] <Daemon404> nevcairiel, do you have time tonight to look at a simple branch [21:16:18 CEST] <Daemon404> its just the merge of adding the new api + your and jamrials and my fixes / addtions [21:16:23 CEST] <Daemon404> specifically to the new api funcs [21:16:37 CEST] <Daemon404> i figure that is a good starting place to merge [21:24:43 CEST] <Daemon404> nevcairiel, https://github.com/FFmpeg/FFmpeg/compare/master...dwbuiten:squashwork?expan… [21:24:50 CEST] <michaelni> Daemon404, also before the merge is pushed i think it should be announced so people can test it for crashes and regressions [21:25:06 CEST] <Daemon404> michaelni, ok [21:25:14 CEST] <Daemon404> intiially i'd like just to merge what i linked above [21:25:21 CEST] <Daemon404> it wont break anything, it's only additions [21:28:35 CEST] <wm4> that audio frame duration function is some funky stuff [21:28:45 CEST] <Daemon404> part of it is a fix from jamrial [21:28:55 CEST] <Daemon404> that was squashed [21:30:25 CEST] <Daemon404> er, actually, i need to unsquash that [21:30:33 CEST] <Daemon404> 1 sec [21:31:01 CEST] <jamrial> that was https://github.com/dwbuiten/FFmpeg/commit/7a3ef8ceac73b9077c63126d9c26377d8… [21:31:03 CEST] <Daemon404> yes [21:31:18 CEST] <Daemon404> im pretty sure it should be squashed in [21:31:22 CEST] <Daemon404> but not totally. [21:31:41 CEST] <jamrial> that whole function is kinda crazy [21:31:47 CEST] <Daemon404> yes [21:31:58 CEST] <Daemon404> and yeah it should not be squashed [21:32:08 CEST] <Daemon404> let me review. [21:33:18 CEST] <Daemon404> it was missing a , [21:33:24 CEST] <Daemon404> other than that it is ok [21:33:33 CEST] <Daemon404> i will push that fix and ask michaelni and nevcairiel for review. [21:34:48 CEST] <Daemon404> done [21:34:53 CEST] <Daemon404> nevcairiel / michaelni - please take a look. [21:34:59 CEST] <Daemon404> it should not be much work to review. [21:35:57 CEST] <Daemon404> going to run fate just in case right now [21:36:23 CEST] <kierank> dammit my assembly is the same speed as c [21:41:09 CEST] <kierank> slower actually :( [21:41:33 CEST] <jamrial> Daemon404: the seek_preroll commit in the squashwork branch should ideally include https://github.com/dwbuiten/FFmpeg/commit/10702f91d106b6ee212fce9e8cf29daf6… [21:41:48 CEST] <jamrial> but it can be added post merge anyway if that's easier for you [21:41:59 CEST] <Daemon404> jamrial, ill squash it [21:42:05 CEST] <Daemon404> it wont affect review in any case [21:42:08 CEST] <jamrial> alright [21:44:24 CEST] <Daemon404> michaelni / nevcairiel - fate passes on that branch [21:44:47 CEST] <cone-919> ffmpeg 03Pedro Arthur 07master:6de58b49032a: swscale: cleanup unused code [21:46:21 CEST] <Daemon404> jamrial, squashed [21:46:53 CEST] <Daemon404> it should be good to merge IMO, but i will wait for nevcairiel to OK it for me. [21:47:08 CEST] <Daemon404> and then ill start picking stuff to send to the ML [21:50:26 CEST] <ubitux> so is it ready for the final review? [21:50:42 CEST] <Daemon404> teh entire thing? no i have to pick/squash and send some mails. [21:50:52 CEST] <Daemon404> but the very first bit is ready to merge if i get an OK [21:50:57 CEST] <Daemon404> https://github.com/FFmpeg/FFmpeg/compare/master...dwbuiten:squashwork?expan… [21:51:14 CEST] <ubitux> you can integrate chunks in this one [21:51:23 CEST] <Daemon404> ? [21:51:31 CEST] <ubitux> typically, you can add the AVMEDIA_TYPE_SUBTITLES case in this one [21:51:37 CEST] <ubitux> where width/height are copied [21:51:42 CEST] <Daemon404> right [21:52:00 CEST] <Daemon404> the point of review ;) [21:52:02 CEST] <ubitux> cac9ad979b518e6220626a85a7af86a3071bd867 [21:52:04 CEST] <ubitux> this chunk [21:52:13 CEST] <ubitux> can be part of that merge [21:52:40 CEST] <Daemon404> on it. [21:52:55 CEST] <ubitux> are you going to add the delay/bframes thing and friends as well? [21:53:40 CEST] <Daemon404> theyre already in there separately [21:53:43 CEST] <Daemon404> rather than squashed [21:54:11 CEST] <Daemon404> would people prefer the yare squashed into the merge commit? [21:54:26 CEST] <Daemon404> nevcairiel / wm4 ^ [21:55:23 CEST] <michaelni> atomnuker, theres a randomly occuing crash with "./ffmpeg_g -i ~/tickets/1784/yo.raw.wav -acodec aac -ac 6 -ab 384k -y test.aac" i dont have a backtrace yet [21:56:09 CEST] <wm4> Daemon404: if they can be separate, why not keep it this way? [21:56:11 CEST] <michaelni> but with enabled assertions it fails in av_clip_c() before crashing it only crashes if i comment the amin > amax abort out [21:56:21 CEST] <Daemon404> wm4, i dont care either way [21:56:52 CEST] <michaelni> crash happes in search_for_quantizers_twoloop i dont have line numbers yet [21:57:44 CEST] <Daemon404> ubitux, i have added it as a separate commit for now [21:58:33 CEST] <ubitux> Daemon404: with s/fix/will be needed for/ ? [21:58:52 CEST] <ubitux> (also need for sub2video btw) [21:59:24 CEST] <Daemon404> ubitux, i can add, but i thought it should be self explanatory that subs have a codecpar [21:59:58 CEST] <ubitux> so you dropped the ()? [22:00:08 CEST] <ubitux> (in the commit message) [22:00:10 CEST] <Daemon404> yes [22:00:18 CEST] <ubitux> ok! [22:00:58 CEST] <Daemon404> i'd have liked to merge today, but i think it is too late in EU-time [22:01:04 CEST] <Daemon404> people are starting to vanish [22:01:16 CEST] <Daemon404> by merge i mean these few commits. [22:01:54 CEST] <michaelni> atomnuker, crash doesnt occur if i build with debug symbols so i cant provde a backtrace [22:02:48 CEST] <Daemon404> michaelni, sounds like heap corruptions [22:04:45 CEST] Action: michaelni is tryng under valgrind but its slooow [22:06:20 CEST] <ubitux> michaelni: passive aggressive method: add a fate test with that sample and wait for the fate valgrind instance to run on it [22:08:50 CEST] <michaelni> i could but the sample is 8mb, ill try to find out if a subset of that triggers it [22:10:29 CEST] <michaelni> valgrind output (with no crash occuring) http://pastebin.com/DdmJuvX9 [22:14:11 CEST] <ubitux> nevcairiel we miss you [22:14:16 CEST] <jamrial> Daemon404: those couple commits should be safe to commit. except for the get_audio_frame_duration part, they are not making changes, just additions [22:14:24 CEST] <Daemon404> yes [22:14:27 CEST] <Daemon404> i also ran all of fate [22:14:29 CEST] <Daemon404> twice. [22:15:04 CEST] <jamrial> then go ahead [22:15:20 CEST] <Daemon404> if nev smacks me, the fist is beign redirected to you! [22:15:21 CEST] Action: Daemon404 runs [22:15:45 CEST] <jamrial> haha [22:16:09 CEST] <nevcairiel> did you squash all followup changes to the get audio frame duration thing? [22:17:02 CEST] <jamrial> he's applying the frame_size and seek_preroll additions separately https://github.com/FFmpeg/FFmpeg/compare/master...dwbuiten:squashwork?expan… [22:17:30 CEST] <wm4> btw. why is initial padding and seek preroll separate? aren't they the same concept? [22:17:58 CEST] <Daemon404> nevcairiel, i applied all i found [22:18:02 CEST] <Daemon404> teh followups i mean [22:18:09 CEST] <Daemon404> all of jamrial's [22:18:27 CEST] <Daemon404> i will diff the functions in the branches before i push [22:19:40 CEST] <jamrial> wm4: initial_padding is not separated. and the two i mentioned are our additions. IMO they don't really belong squashed in the merge of libav's commit [22:20:44 CEST] <wm4> I mean, why are they separate fields [22:20:54 CEST] <jamrial> oh [22:21:10 CEST] <Daemon404> nevcairiel, theyre identical [22:21:17 CEST] <Daemon404> md5sum of the file is even the same [22:21:18 CEST] <jamrial> no, they are not the same concept, at least doesn't look like [22:22:18 CEST] <wm4> I mean in both cases initial decoder output is skipped because it's invalid... seek preroll is for adjusting the seek target, but why wouldn't it be the same value as the initial padding [22:22:25 CEST] <nevcairiel> no, its different concepts, the only codec with proper seek preroll i know is opus though [22:22:30 CEST] <nevcairiel> at least the only one that cares to signal it [22:22:47 CEST] <cone-919> ffmpeg 03Anton Khirnov 07master:998e1b8f521b: lavc: add codec parameters API [22:22:48 CEST] <cone-919> ffmpeg 03Anton Khirnov 07master:a8068346e48e: lavc: add a variant of av_get_audio_frame_duration working with AVCodecParameters [22:22:49 CEST] <cone-919> ffmpeg 03Derek Buitenhuis 07master:f9b1cf15c233: Merge commit '998e1b8f521b73e1ed3a13caaabcf79eb401cf0d' [22:22:50 CEST] <cone-919> ffmpeg 03Derek Buitenhuis 07master:e6053b3b19c0: Merge commit 'a8068346e48e123f8d3bdf4d64464d81e53e5fc7' [22:22:51 CEST] <cone-919> ffmpeg 03James Almer 07master:3fafde6cbe34: lavc: Add seek_preroll to AVCodecParameters [22:22:52 CEST] <cone-919> ffmpeg 03Hendrik Leppkes 07master:5b4f8af2f1ac: Add frame_size to AVCodecParameters [22:22:53 CEST] <cone-919> ffmpeg 03Derek Buitenhuis 07master:dd77dad4e6ff: codecpar: Add video delay field [22:22:54 CEST] <cone-919> ffmpeg 03Clément BSsch 07master:be8d98c1ad38: lavc/utils: transfer width/height for subs in codecpar [22:23:02 CEST] <jamrial> \o/ [22:23:03 CEST] Action: Daemon404 puts on bulletproof vets [22:23:07 CEST] <Daemon404> vest* [22:23:24 CEST] <jamrial> keep it for when the actual lavf changes are merged :p [22:23:41 CEST] <Daemon404> indeed [22:24:17 CEST] <JEEB> unts-unts \o/ [22:24:24 CEST] <wm4> suddenly ffserver users, devs, supporters everywhere [22:24:42 CEST] <wm4> and it will be the end of the world [22:24:50 CEST] <Daemon404> i dunno, the "maintainer" has 2 years to fix it [22:24:53 CEST] <Daemon404> that is not unreasonable. [22:25:39 CEST] <ubitux> i'd suggest to make an official post on the ml [22:26:01 CEST] <michaelni> i might work on fixing ffserver if it had some kind of fate tests [22:26:04 CEST] <ubitux> so in 2 years when people will say "just don't drop this deprecate definery" [22:26:18 CEST] <ubitux> you will have a message to refer to [22:26:23 CEST] <Daemon404> ubitux, yes i plan to [22:26:37 CEST] <Daemon404> i will cc reynaldo too. [22:26:43 CEST] <michaelni> but with no real way to test iam afraid changing anything n it could do ore harm than good [22:27:09 CEST] <Daemon404> i'd argue simply keeping ffserver alive does more harm than good. [22:27:10 CEST] <Daemon404> so. [22:27:23 CEST] <JEEB> yeah, so many poor folks trying to use it [22:27:56 CEST] <JEEB> because it's in the code base and becomes available when you install FFmpeg in a distro usually [22:27:56 CEST] <michaelni> it would be nice to have a "ffserver" that supports modern protocols and is easy to use [22:28:08 CEST] <JEEB> well depends on what exactly you need [22:28:16 CEST] <JEEB> a lot of stuff is already possible with ffmpeg itself [22:28:16 CEST] <Daemon404> that wouldnt pretty much necessitate a rewrite [22:28:21 CEST] <Daemon404> also what jeeb said [22:28:37 CEST] <JEEB> and then you have extensions to http servers like nginx-rtmp [22:28:44 CEST] <JEEB> (it just takes in rtmp and serves HLS/DASH) [22:29:08 CEST] <JEEB> or whatever the OSS shoutcast thing was [22:29:11 CEST] <JEEB> icecast? [22:29:39 CEST] <ubitux> there was crtmpserver or sth like this too? [22:30:00 CEST] <JEEB> yeah, I think that was an actual rtmp thing for end users tho [22:30:11 CEST] <JEEB> and flash is becoming less relevant these days [22:30:26 CEST] <wbs> JEEB: crtmpserver does other formats as well, or at least in the commercial version [22:30:29 CEST] <JEEB> ah [22:30:31 CEST] <JEEB> ok [22:31:46 CEST] <ubitux> Daemon404: just realized that code should probably use ff_alloc_extradata [22:32:27 CEST] <kierank> is it possible in yasm to use an offset to a field in RODATA? [22:32:33 CEST] <Daemon404> ubitux, should be easy to fix :P [22:32:54 CEST] <ubitux> ah no, wait, it's in lavf [22:33:11 CEST] <ubitux> why the hell is it there [22:33:51 CEST] <ubitux> well whatever [22:34:34 CEST] <Daemon404> "why the hell <...>" [22:34:39 CEST] <Daemon404> that is me every day for the last two weeks [22:34:41 CEST] <Daemon404> fixing hacks [22:40:13 CEST] <BBB> kierank: what exactly? [22:40:24 CEST] <BBB> kierank: what are you trying to do? [22:40:30 CEST] <kierank> like do pshufb m0, [v210_uyvy_chroma_shuf+10] or whatever [22:41:53 CEST] <BBB> that should work, except it should be 16-byte aligned [22:42:06 CEST] <kierank> ah might as well declare a new one then [22:42:17 CEST] <BBB> oh the align was the problem? sorry about that [22:42:52 CEST] <kierank> yeah I'm writing a v210 -> uyvy422-10bit converter and the masks and shuffles have a repeating pattern [22:43:00 CEST] <BBB> right udnerstood [22:43:06 CEST] <BBB> yeah just make copies [22:43:11 CEST] <BBB> its a little wasteful but its ok [22:43:13 CEST] <BBB> memory is cheap [22:43:18 CEST] <BBB> at this rate, at least [22:43:51 CEST] <Gramner> cache isn't really cheap, but yeah, a few bytes is unlikely to matter [22:45:30 CEST] <kierank> v210 -> uyvy422-10bit is a nightmare, requires palignr [22:49:58 CEST] <Daemon404> nevcairiel, sending one of your patches to the ML. [23:07:04 CEST] <Daemon404> 53 [23:11:09 CEST] <cone-919> ffmpeg 03Derek Buitenhuis 07master:54ccaaeb2b93: psxstr: Remove some commented out code [23:31:27 CEST] <Daemon404> blarg, done for the day. have fun picking some patches tomorrow, nevcairiel. [23:46:28 CEST] <michaelni> Daemon404: ./ffmpeg-codecpar-dooall-2016-0331-21 -f concat -i ~/tickets/3108/concatfile.txt -codec copy out.avi <-- gives 250 frames and error while git master gives 500 and no error [23:54:06 CEST] <Daemon404> michaelni, is that with the branch [23:55:59 CEST] <michaelni> your branch yes [23:56:18 CEST] <Daemon404> all right [23:56:28 CEST] <Daemon404> im not doing any fixes today though, im beat. [23:56:45 CEST] <michaelni> sure, iam just trying to do some random testing [00:00:00 CEST] --- Fri Apr 1 2016

1 0

ffmpeg.log.20160331
by burek 01 Apr '16

01 Apr '16

[00:18:52 CEST] <Taoki> In that case: Is it not possible to define the length of the video in hours:minutes:seconds, instead of the frame rate? So FPS is based on the time you want. [00:19:19 CEST] <Taoki> Actually, I might be able to find a converter for this online if not.... [00:19:31 CEST] <J_Darnley> No [00:19:36 CEST] <explodes> Hello! Can I use libpostproc to skip sws_scale? sws_scale is giving me glorious segfaults, and I have no idea why; [00:19:49 CEST] <J_Darnley> Usually ffmpeg has no clue how many frames a video has nor how long it actually is. [00:20:05 CEST] <Taoki> Online coverter it is then [00:20:12 CEST] <J_Darnley> explodes: to do what exactly? [00:20:14 CEST] <explodes> I've only seen the case where ffmpeg knows exactly how long a video is, in how many frames [00:20:16 CEST] <explodes> BUt that's just me [00:20:30 CEST] <explodes> J_Darnley: to convert YUV420p to BGR32 [00:20:33 CEST] <J_Darnley> no [00:20:40 CEST] <explodes> YUV*something [00:20:45 CEST] <explodes> Dang [00:20:45 CEST] <J_Darnley> still no [00:20:52 CEST] <c_14> explodes: if it's segfaulting, try updating? [00:21:10 CEST] <explodes> Yea, the jump from 2.8 -> 3.0 blow up all of the things [00:21:17 CEST] <fritsch> memory alignment [00:21:24 CEST] <fritsch> does it crash in ASM code? [00:22:25 CEST] <fritsch> a backtrace would be nice to have - even better: part of the code you are using [00:22:34 CEST] <fritsch> context setup + sws_scale [00:23:42 CEST] <fritsch> i had a similar issue after upgrading to 3.0 with yuv402p to rgb32 code with neon asm [00:23:59 CEST] <fritsch> which required 16 byte aligned memory adresses [00:24:03 CEST] <explodes> I'm using asm mode for ARM, not for X86 ; but I have no data on X86 anyways. [00:24:10 CEST] <fritsch> same here [00:24:20 CEST] <explodes> Nice. let me get some snippets [00:24:36 CEST] <fritsch> you got a backtrace? [00:24:50 CEST] <fritsch> you supply the data "from external"? [00:25:02 CEST] <fritsch> e.g.set frame->data[0] manually? [00:26:06 CEST] <fritsch> bool aligned = (((uintptr_t)(const void *)(pixels)) % (16) == 0); if that is false [00:26:13 CEST] <explodes> http://pastebin.com/ZQbUS3Wz [00:26:25 CEST] <explodes> I don't set it manually, no [00:26:42 CEST] <explodes> ALso I have no backtrace, JNI isn't playing very nice for us [00:26:51 CEST] <fritsch> deprecated API [00:26:53 CEST] <fritsch> :-) [00:26:57 CEST] <fritsch> but I see the issue [00:27:10 CEST] <fritsch> avpicture_fill uses av_image_ and only aligns to 1 byte [00:27:17 CEST] <fritsch> replace avpicture_fill with: [00:27:38 CEST] <fritsch> av_image_fill_arrays [00:27:43 CEST] <fritsch> and use 16 alignment [00:27:45 CEST] <explodes> You're awesome [00:27:52 CEST] <explodes> If this works, NOra say she's gonna marry you [00:27:59 CEST] <fritsch> i am already married [00:28:03 CEST] <explodes> double up. [00:28:53 CEST] <explodes> Ah, the problem here is that we need pixels to be written to (at least eventually) [00:29:09 CEST] <explodes> av_image_fill_arrays doesn't take a pixel pointer of sorts, and so nothing in that method would write the data to that block [00:29:29 CEST] <fritsch> av_image_fill_arrays(stream->pFrameOut->data, stream->pFrameOut->linesize, pixels, PIXEL_FORMAT, width ,height, 16) [00:29:57 CEST] <explodes> Ohhh [00:30:11 CEST] <fritsch> https://ffmpeg.org/doxygen/2.4/group__lavu__picture.html#ga5b6ead346a70342a… [00:30:25 CEST] <fritsch> btw. never the less this is an ffmpeg 3.0 bug [00:30:34 CEST] <fritsch> this asm makes assumptions it does not have [00:30:36 CEST] <fritsch> and crashes [00:30:55 CEST] <fritsch> i had to revisit kodi's complete texture memory allocation [00:30:57 CEST] <fritsch> :-) [00:31:00 CEST] <fritsch> cause of that [00:31:06 CEST] <explodes> So if I disable ASM, the issue would be fixed? [00:31:10 CEST] <explodes> Not going to, but [00:31:21 CEST] <fritsch> try the replacement first [00:31:29 CEST] <fritsch> width and height you need to replace with yours [00:31:34 CEST] <fritsch> the rest should work as is [00:31:43 CEST] <explodes> fritsch, I don't know who you are or where you came from, but you've made my day. We've been working hard, fruitlessly, for weeks. [00:31:58 CEST] <fritsch> does it work? [00:32:13 CEST] <fritsch> btw. don't use SWS_FAST_BILINEAR [00:32:24 CEST] <fritsch> it is not really faster than normal bilinear but the quality sucks like hell [00:32:25 CEST] <fritsch> :-) [00:32:40 CEST] <varu-> hi, i'm trying to receive/process an mpts stream from a commercial ird [00:33:18 CEST] <varu-> what it does is fling a ts mux via udp to an IP specified in its interface, in this case a box with ffmpeg [00:33:34 CEST] <varu-> how can i get ffmpeg to 'tune in'? [00:35:45 CEST] <J_Darnley> ffmpeg -i SOME_URL maybe [00:36:03 CEST] <c_14> ffmpeg -i udp://localhost:port probably [00:36:09 CEST] <varu-> tried doing ffmpeg -i udp://@:<porthere> [00:36:24 CEST] <c_14> may need ?listen [00:36:32 CEST] <c_14> ie udp://localhost:port?listen [00:37:01 CEST] <c_14> And you may need to listen on either a broadcast address or the address it's being sent to [00:37:12 CEST] <c_14> So <my ip> instead of localhost [00:37:59 CEST] <varu-> ok, tried all of the above. sits there until i ctrl-c out of it, reporting "could not find codec parameters" [00:38:04 CEST] <explodes> fritsch: P.S. I love you, but we also another segfault happening in yuva2rgba.c, but I have no stack trace or idea about why [00:39:02 CEST] <fritsch> explodes: did it work? [00:39:17 CEST] <fritsch> so - then show me that code, too [00:40:02 CEST] <varu-> running with -v debug now, seems it *is* receiving the stream: Statistics: 36817732 bytes read [00:40:24 CEST] <c_14> Is the server sending plain udp or something like rtp? [00:40:54 CEST] <varu-> the setting in the server is 'mpts', it's sending a mux of several services [00:41:15 CEST] <varu-> [mpegts @ 0x260e600] Format mpegts probed with size=2048 and score=100 [00:41:28 CEST] <explodes> fritsch: yep! it's working, we haven't been able to replicate the segfault reliably, but we will see how it behaves in the wild. [00:41:38 CEST] <varu-> [mpegts @ 0x260e600] Before avformat_find_stream_info() pos: 0 bytes read:5000800 seeks:0 [00:41:58 CEST] <explodes> fritsch: I have no idea which code is causing the yuv2rgb problem; it's either in our decode function or vsp_getFrame [00:42:05 CEST] <varu-> [mpegts @ 0x260e600] After avformat_find_stream_info() pos: 508081280 bytes read:508081280 seeks:0 frames:0 - and couldn't find codec parameters (this is after ctrl-c) [00:42:11 CEST] <c_14> varu-: what codec is the source stream[s]? [00:42:25 CEST] <fritsch> explodes: then that's the first thing to find out :-) [00:42:37 CEST] <fritsch> does that also go through that part of the code you linked? [00:42:59 CEST] <explodes> fritsch: http://pastebin.com/gFRN787i [00:43:01 CEST] <varu-> not entirely sure, most likely mpeg4 avc [00:43:34 CEST] <explodes> nope, the flow of the program is: probe, load, decode, decode, decode... [00:44:39 CEST] <fritsch> explodes: your pts handling is not that smart :-) [00:44:47 CEST] <explodes> lol [00:44:55 CEST] <explodes> What is a better way to handle that? [00:46:19 CEST] <fritsch> is that your code? [00:46:25 CEST] <fritsch> still looking for yuv2rgb [00:46:28 CEST] <fritsch> in that one [00:46:47 CEST] <fritsch> http://dranger.com/ffmpeg/tutorial05.html <- good read [00:46:53 CEST] <explodes> It was a contractors, but we have extensively modified it to fix the bugs that we've found [00:47:11 CEST] <fritsch> it looks like some pimped ffmpeg beginners howto :-) [00:47:13 CEST] <fritsch> hehe [00:47:21 CEST] <explodes> Yea that's where he got most of the code [00:47:28 CEST] <fritsch> oki - so for which company I am currently working? :-) [00:47:45 CEST] <explodes> I've tried to not disturb the code too much, as we're not much of C experts [00:48:11 CEST] <fritsch> yeah ... no problem. see if the other issue comes back [00:48:15 CEST] <zamba> hi guys! i'm digitalizing some old vhs for a friend of mine.. i have a easycap video capture device set up.. and i have the audio routed through my microphone jack (using alsa).. i don't want to encode/transcode on the fly, since my computer can't handle it, so i just need to dumpm the streams as quickly as possible to disk.. what options do you recommend for this? [00:48:57 CEST] <zamba> as a PoC i did: ffmpeg -f video4linux2 -i /dev/video1 -f alsa -i default output.mkv [00:49:13 CEST] <zamba> and i got both video and audio, but with lags here and there - which i suspect is due to the computer not keeping up [01:00:01 CEST] <llogan> zamba: i would be surprised if your computer couldn't keep up encoding SD content. unless it's some ancient jalopy. [01:00:20 CEST] <zamba> it's a P8400 [01:00:36 CEST] <zamba> llogan: but i'd rather just dump with the best quality initially and just worry about the conversion afterwards [01:00:55 CEST] <zamba> but preferably in a container that will keep the a/v in snc [01:00:57 CEST] <llogan> ok. you'll need to show the complete console output from that command. you can use a pastebin site. [01:00:57 CEST] <zamba> sync* [01:01:10 CEST] <zamba> from what command? [01:01:18 CEST] <llogan> the one you just showed here [01:02:29 CEST] <zamba> yeah, but again.. i want to dump in raw format initiall [01:02:33 CEST] <zamba> intially* [01:02:48 CEST] <zamba> and then do the conversion [01:02:52 CEST] <llogan> i know that [01:04:42 CEST] <zamba> but you still want the output of the first command? [01:05:39 CEST] <zamba> http://pastebin.com/1vtL3kty [01:05:40 CEST] <zamba> there you go [01:08:59 CEST] <llogan> the input is rawvideo so if you want to just mux that into the output it will make a huge file [01:09:05 CEST] <zamba> sure [01:10:04 CEST] <zamba> llogan: or do you have some other suggestions? i'm wondering if the "Past duration X too large" messages are the ones that indicate that my computer isn't fast enough? [01:10:46 CEST] <zamba> what about some of the lossless codecs? x264 for instance? [01:11:12 CEST] <zamba> of course the source is crappy to begin with, but i at least want to preserve the "quality" from that [01:14:13 CEST] <llogan> you cna measure encoding speed with "ffmpeg -f video4linux2 -i /dev/video1 -f alsa -i default -c:v libx264 -c:a aac -f null -", but the lags may be coming from v4l2 or alsa instead of any encoding overhead [01:15:25 CEST] <llogan> ...which may be related to the "Thread message queue blocking" warning [01:17:13 CEST] <zamba> i'd rather not experiment too much with the source.. as this is fragile tape.. [01:18:01 CEST] <zamba> you can't provide me with an output format that contains some compression and still is a format that can be easily worked with afterwards if i want to go even smaller in size? [01:18:10 CEST] <zamba> maybe not a -raw- dump, but close enough? [01:19:52 CEST] <llogan> what's the output being used for? just viewing on computer? DVD? etc? [01:20:07 CEST] <zamba> it'll probably end up on a DVD, yeah [01:20:25 CEST] <zamba> but i would still like to keep the source for archiving purposes [01:20:35 CEST] <zamba> as a file [01:21:14 CEST] <zamba> flac for video, basically.. :) [01:21:58 CEST] <furq> huffyuv, ffv1, x264 lossless [01:22:04 CEST] <zamba> furq: now we're talking [01:22:06 CEST] <llogan> add -crf 0 and -c:a copy to your previous command [01:22:22 CEST] <zamba> llogan: that will give me a -raw- dump? [01:22:33 CEST] <furq> -crf 0 is x264 lossless (assuming you're using 8-bit x264) [01:22:59 CEST] <zamba> furq: how much cpu does that need? [01:23:08 CEST] <furq> it depends which preset you're using [01:23:27 CEST] <zamba> well.. eh.. "the best"? :) [01:23:31 CEST] <zamba> i know none of them [01:23:31 CEST] <furq> it should probably be fine with -preset veryfast [01:23:53 CEST] <zamba> and how much cpu does that need? [01:24:36 CEST] <furq> i don't know how to answer that question [01:25:36 CEST] <furq> the only reliable answer you'll get is to try it and find out [01:25:51 CEST] <zamba> will i get any feedback if the computer is not keeping up? [01:25:56 CEST] <zamba> and if so, what kind? [01:26:31 CEST] <furq> the progress report shows the encoding speed in fps [01:26:45 CEST] <furq> if that drops below your target fps then your cpu isn't fast enough [01:27:08 CEST] <furq> recent versions will have "1.000x" (or the current relative speed) at the end of the progressbar as well [01:27:21 CEST] <furq> i'm not sure how accurate that is though [01:29:05 CEST] <petecouture> What is the best practices to restart ffmpeg while it's encoding a live stream? I'm accepting a live RTP stream and encoding to HLS. If the broadcasters bandwidth drops or cuts out for a few seconds, ffmpeg keeps encoding but nothing is processing. The timemark increments but the framenumber doesn't go up. Here's an output of the frame/progress and the file listings at the bottom so you can see how it's chunking. ht [01:29:05 CEST] <petecouture> tp://pastebin.com/vubxsHjd [01:29:33 CEST] <petecouture> The would be to continue the HLS segment and m3u8 generation without the end user having to refresh [01:31:31 CEST] <zamba> furq: 25 fps.. but it dropped down to 20 fps [01:34:38 CEST] <furq> you can try huffyuv, ffvhuff, ffv1 and ut video as well [01:35:12 CEST] <zamba> looks like the problem is the disk write performance [01:35:24 CEST] <zamba> ffmpeg -f video4linux2 -i /dev/video1 -f alsa -ac 2 -i default -c:a copy -crf 0 -preset veryfast -f null - [01:35:34 CEST] <zamba> if i do this, then i'm dead solid on 25 fps and 1x [01:35:49 CEST] <furq> surely the problem isn't the disk then [01:36:01 CEST] <zamba> oh? [01:36:05 CEST] <furq> oh nvm that's going to stdout [01:36:08 CEST] <zamba> yeah [01:36:34 CEST] <furq> that's also rawvideo though [01:36:40 CEST] <zamba> oh? [01:36:55 CEST] <furq> you're not supplying a codec, and it won't default to x264 with no output file extension [01:37:09 CEST] <zamba> ah, ok [01:37:11 CEST] <furq> specify -c:v libx264 [01:37:45 CEST] <zamba> like so: ffmpeg -f video4linux2 -i /dev/video1 -f alsa -ac 2 -i default -c:a copy -crf 0 -c:v libx264 -f null - [01:37:52 CEST] <furq> sure [01:38:05 CEST] <zamba> actually even worse performance then [01:38:06 CEST] <furq> you forgot -preset veryfast [01:38:07 CEST] <zamba> 12 fps [01:38:21 CEST] <zamba> ah, that i did [01:38:28 CEST] <zamba> yeah.. then i'm back to the same speed [01:38:31 CEST] <zamba> so it's not the disk [01:38:45 CEST] <furq> you could maybe try -preset ultrafast but that'll lose a lot of efficiency [01:38:57 CEST] <zamba> measured 66.3 MB/s, so it can't be the disk [01:39:19 CEST] <zamba> 32 MB/s raw write speed (no memory involved) [01:39:21 CEST] <TD-Linux> ffv1 is probably faster (?) [01:39:37 CEST] <furq> yeah one of the other lossless yuv codecs is probably a better bet [01:39:40 CEST] <zamba> -c:v ffv1? [01:39:49 CEST] <furq> yeah, and get rid of -preset and -crf [01:40:04 CEST] <furq> there's also huffyuv, ffvhuff and utvideo [01:40:08 CEST] <zamba> nope [01:40:18 CEST] <zamba> actually worse than libx264 [01:40:21 CEST] <zamba> down to 12 fps [01:41:03 CEST] <furq> you might need to specify -threads with ffv1 [01:41:25 CEST] <zamba> tried -threads 2 [01:41:33 CEST] <zamba> huffyuv looks promising [01:43:00 CEST] <zamba> with huffyuv i'm able to maintain 25 fps [01:43:16 CEST] <furq> iirc huffyuv is pretty fast but not very efficient [01:43:31 CEST] <zamba> .... :) [01:43:38 CEST] <zamba> so which one should i select? :) [01:43:48 CEST] <furq> well for you i guess it's whichever one runs at full speed [01:44:13 CEST] <furq> there are a bunch more options for ffv1 but i've not used it much [01:44:23 CEST] <furq> https://trac.ffmpeg.org/wiki/Encode/FFV1#FFV1version3 [01:44:33 CEST] <furq> maybe -slices will speed it up [01:45:05 CEST] <zamba> i'll have to look at this tomorrow again.. [01:45:18 CEST] <zamba> too many choices [01:45:22 CEST] <zamba> i have no idea what i'm doing :) [01:47:30 CEST] <furq> i would suggest overclocking but that's a mobile cpu isn't it [03:35:13 CEST] <explodes> what is the 'align' argument in av_image_get_buffer_size ? [03:39:34 CEST] <explodes> and av_image_fill_arrays for that matter.. [04:22:38 CEST] <J_Darnley> At a guess: the byte alignment you want arrays to be allocated with [04:22:48 CEST] <J_Darnley> possibly line alignment oo [04:22:51 CEST] <J_Darnley> *too [04:35:01 CEST] <explodes> What if I do not know, I think I can have them aligned any way: alignment of 1 [06:47:40 CEST] <varu-> fyi i figured out what the issue was, ird problem. tcpdump'd the udp stream into a pcap and looked at it with wireshark, all null packets! ffmpeg had nothing to decode [06:48:31 CEST] <varu-> the rest was just trial and error, now works just fine. amazing software! [07:52:37 CEST] <zamba> furq: it's a P8400 CPU, yeah [07:52:42 CEST] <zamba> dunno if it's a mobile one or not [08:43:40 CEST] <rrva> is there anything like http://gopchop.sourceforge.net/ but for h264 ? [10:09:43 CEST] <Keshl> rrva: Tell me if you find out. I've been looking for something like this for /ages/. o_o [10:18:42 CEST] <rrva> Keshl: avidemux or ffmpeg -i ${1} -f segment -reset_timestamps 1 -segment_list out.ffcat -segment_times 172.16,202.56 -c copy -copy_unknown -map 0 ${1}_02%d.ts [10:18:56 CEST] <rrva> Keshl: both of those can cut streams without re-encoding [10:19:11 CEST] <rrva> Keshl: but still not as unmodified as gopchop [10:31:52 CEST] <Keshl> rrva: I think what you just threw at me does what I need it to do. o_o. [10:32:31 CEST] <Keshl> Thank you. o_o. Why won't that work for you, though? oÉo? [10:38:46 CEST] <momomo> how do you create multiple outputs at once using one ffmpeg connection to an input ? [10:38:48 CEST] <GNUbahn> Hi. I'm trying to get ffmpeg to work on my LinuxMint. It seems that I can't add the necessary PPA but instead have to download, extract and execute the linuxbuild from ffmpeg.org. But how and what do I execute? [10:43:54 CEST] <GNUbahn> VB [10:43:56 CEST] <c_14> GNUbahn: do you want the static build or are you trying to build ffmpeg yourself? [10:45:13 CEST] <GNUbahn> c_14: I just need to install the program itself [10:45:41 CEST] <c_14> The just download the static build, extract it and place the "ffmpeg" file in your PATH somewhere (probably /usr/local/bin) [10:47:32 CEST] <GNUbahn> c_14: there is no ffmpeg file. There is ffmpeg.s ffmpeg.h and six ffmpeg.* [10:47:57 CEST] <furq> GNUbahn: http://johnvansickle.com/ffmpeg/ [10:48:06 CEST] <c_14> You downloaded the sources, you want the build from what furq just posted [10:51:36 CEST] <GNUbahn> according to the ffmpeg site I downloaded the program itself [10:54:11 CEST] <c_14> Did you press the big green download button? (ffmpeg-3.0.1.tar.bz2) ? [10:54:28 CEST] <c_14> Because those are the sources [10:54:50 CEST] <c_14> FFmpeg itself doesn't host binary builds, those are hosted by third parties. [10:55:29 CEST] <GNUbahn> c_14: That's what I did, believing it to be the program. Thanks for helping me out of the mess [10:58:43 CEST] <GNUbahn> I was helped to find this page: https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media [11:05:44 CEST] <edkamsalp> I use this command to capture the desktop: [11:05:47 CEST] <edkamsalp> sleep 2s; ffmpeg -video_size 1024x768 -framerate 25 -f x11grab -i :0 -f alsa -ac 2 -i hw:0 output.mkv [11:06:13 CEST] <edkamsalp> to stop, capturing I use: the key q [11:06:30 CEST] <edkamsalp> Is possible to pause/resume? [11:06:52 CEST] <edkamsalp> Is it* [11:09:16 CEST] <edkamsalp> Can ffmpeg be paused and resume during screen capturing? [11:09:37 CEST] <relaxed> edkamsalp: you can try "ctrl z" and then "fg" to resume, but I'm not sure how well it will work. [11:10:07 CEST] <GNUbahn> it still doesn't work though. When I type 'ffmpeg -f concat -i mylist.txt -c copy HTS1.sl1.r.mp4' I'm told the command wasn't found [11:11:34 CEST] <edkamsalp> GNUbahn: ffmpeg -f concat -i input.txt -c copy output.mp4 works for me [11:11:48 CEST] <edkamsalp> How do you right your mylist.txt? [11:11:55 CEST] <edkamsalp> write* [11:13:50 CEST] <GNUbahn> edkamsalp: Thanks, bit it doesn't for me. I'm still told, that the commands can't be found [11:15:21 CEST] <edkamsalp> GNUbahn: type and Enter this: [11:15:24 CEST] <edkamsalp> hgsfyugcbshmgv [11:17:41 CEST] <edkamsalp> relaxed: It does not stop the screen-capturing! Capturing just will be freezed! It stop capturing new activities, but time is going on! [11:22:52 CEST] <GNUbahn> edkamsalp: ? [11:23:47 CEST] <edkamsalp> ffmpeg -f concat -i mylist.txt -c copy HTS1.sl1.r.mp4 | curl -F c=@- https://ptpb.pw [11:24:03 CEST] <edkamsalp> GNUbahn: try it and share the link [11:24:17 CEST] <GNUbahn> c_14 & edkamsalp: I think I solved the issue. It turned out to be me being an idi*t [11:24:32 CEST] <GNUbahn> Not installing correctly [11:24:50 CEST] <GNUbahn> edkamsalp: What does this mean: curl -F c=@- https://ptpb.pw [11:25:01 CEST] <zamba> TD-Linux: lo! do you have more details/suggestions to using the ffv1 codec? [11:25:26 CEST] <edkamsalp> GNUbahn: it's a pastebin [11:26:58 CEST] <GNUbahn> edkamsalp: so if I write that, you'll be able to se the output on https://ptpb.pw? [11:32:17 CEST] <GNUbahn> edkamsalp: I tryed but can't open the link I get i firefox [11:32:59 CEST] <edkamsalp> GNUbahn: [11:33:07 CEST] <edkamsalp> alias ptpb='curl -F c=@- https://ptpb.pw' [11:33:10 CEST] <edkamsalp> then [11:33:23 CEST] <edkamsalp> cat foo.txt | ptpb [11:34:57 CEST] <termos> trying to run the example from https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/transcoding.c using libx264 it fails and tells me that "broken ffmpeg default settings detected"? Is this a known bug? [11:35:06 CEST] <edkamsalp> GNUbahn: it upload the stdout to its servers and returns a link to you. A link like in this format: https://ptpb.pw/9orb [11:35:35 CEST] <GNUbahn> edkamsalp: Yeah I git that working but for some reason firefow won't open that link [11:36:28 CEST] <edkamsalp> The open well here in FF. [11:36:33 CEST] <edkamsalp> they* [11:36:42 CEST] <edkamsalp> are opened* [11:36:56 CEST] <GNUbahn> edkamsalp: try https://ptpb.pw/2AcJ [11:37:14 CEST] <GNUbahn> It's obsolete now though [11:38:04 CEST] <GNUbahn> I got it to work and an now concatenating two files. [11:38:34 CEST] <edkamsalp> GNUbahn: https://ptpb.pw/2AcJ --> it's empty! <command> | ptpb --> the output of your <command> is nothing! [11:39:04 CEST] <GNUbahn> edkamsalp: Yeah really empty. I wonder what went wrong!? [11:40:49 CEST] <furq> if the command was ffmpeg then you didn't redirect stderr to stdout [11:41:29 CEST] <GNUbahn> furq: So what should the command have been? [11:41:48 CEST] <furq> ffmpeg [opts] 2>&1 | ptbp [11:42:27 CEST] <GNUbahn> furq: this was my command: ffmpeg -f concat -i mylist.txt -c copy HTS1.sl1.r.mp4 | curl -F [11:42:27 CEST] <GNUbahn> c=@- https://ptpb.pw [11:42:43 CEST] <furq> yeah that doesn't do anything [11:43:10 CEST] <GNUbahn> furq: because? [11:43:21 CEST] <furq> because it doesn't have 2>&1 after the ffmpeg command [11:43:43 CEST] <GNUbahn> furq: I'm sorry, I don't know what you mean [11:45:00 CEST] <furq> ffmpeg -f concat -i mylist.txt -c copy HTS1.sl1.r.mp4 2>&1 | curl -F c=@- https://ptpb.pw [11:46:07 CEST] <momomo> I am trying to generate multiple outputs, and looking at this: [11:46:07 CEST] <momomo> https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs [11:46:28 CEST] <momomo> should I be using "no filtering" or "filtering for all outputs" ? [11:46:49 CEST] <momomo> what is the diffference? performance benefits ? [11:47:22 CEST] <furq> do you want to apply filters to the outputs [11:48:14 CEST] <GNUbahn> furq & edkamsalp: Now I got the pastebin thing working (though I stille don't know what 2>&1 is good for) What do you get from this: https://ptpb.pw/Rmw- [11:48:22 CEST] <momomo> may I ask what means with filters? if I want to apply an alpha image ? [11:48:26 CEST] <momomo> or something ? [11:48:28 CEST] <momomo> :S [11:48:41 CEST] <momomo> I would like to add an image to the stream ( a logo ) [11:48:49 CEST] <furq> momomo: https://ffmpeg.org/ffmpeg-filters.html#toc-Video-Filters [11:48:55 CEST] <momomo> as well as generate one output for desktop and one for mobile [11:49:08 CEST] <furq> if you want to add an image then you'll need to filter all outputs [11:49:25 CEST] <edkamsalp> GNUbahn: https://en.wikipedia.org/wiki/Standard_streams + http://www.cyberciti.biz/faq/redirecting-stderr-to-stdout/ [11:50:25 CEST] <momomo> furq, thanks, may I ask, I want to apply a logo as well at some corner, would I do that using filters or is that for other things such as manipulating colors and others ? [11:51:48 CEST] <GNUbahn> edkamsalp & furq: I've got to go now, but will probably return with further questions. Thanks a lot for your patience and help. [11:51:57 CEST] <edkamsalp> GNUbahn: didn't you say already your work is done?! [11:52:45 CEST] <furq> momomo: https://ffmpeg.org/ffmpeg-filters.html#overlay-1 [11:53:10 CEST] <momomo> furq, that's one video over the other ? [11:53:20 CEST] <furq> it works just as well with images [11:53:28 CEST] <momomo> ook [11:53:41 CEST] <furq> ffmpeg usually considers an image to be a 1-frame video [11:53:58 CEST] <momomo> furq, this is the best way to do it? [11:54:11 CEST] <furq> probably [11:54:14 CEST] <furq> i've never had to do it [11:54:24 CEST] <momomo> furq, ook, good to know.. learning more :) [11:54:29 CEST] <furq> there's certainly no way which doesn't involve filters [11:55:45 CEST] <momomo> i have another issue that I've been pushing for some time .. and that is ... normally I would have streams generating hls videos ... at some point, I would like to push in an advert into an existing running stream ... is that possible? to manipulate an existing ffmpeg command ? [11:56:05 CEST] <momomo> or pause it [11:56:26 CEST] <momomo> so I can manipualte the playlist.m3u8 file and push my own hls segnment [12:13:57 CEST] <momomo> I am getting invalid for command: [12:14:02 CEST] <momomo> ffmpeg -i http://user:pass@domain.host.ca:9981/play/stream/channel/50690c661e5c524dff… -x264-params scenecut=0 -x264opts keyint_min=125 -g 125 -r 25 -framerate 25 -b:v 1024k -bufsize 1024k -minrate 1024k -maxrate 1024k -c:v libx264 -c:a libvo_aacenc -b:a 64k -ac 2 -f hls -hls_list_size 3 -hls_time 5 -hls_flags delete_segments /momomo/Generated/Tv/2488934447TV4/c -s 736x306 -x264-params scenecut=0 -x264opts keyint_min=125 [12:14:02 CEST] <momomo> -g 125 -r 25 -framerate 25 -b:v 1024k -bufsize 1024k -minrate 1024k -maxrate 1024k -c:v libx264 -c:a libvo_aacenc -b:a 64k -ac 2 -f hls -hls_list_size 3 -hls_time 5 -hls_flags delete_segments /momomo/Generated/Tv/2488934447TV4/m [12:14:19 CEST] <momomo> does this command look right? do I have to repeat both commands like that ? [12:14:27 CEST] <momomo> error: [NULL @ 0x2232600] Unable to find a suitable output format for '' [12:15:21 CEST] <momomo> the command on multiple lines: http://hastebin.com/ceparekuna.sm [12:16:18 CEST] <momomo> should I perhaps be piping the first command to the second to generate the smaller size ? [12:17:24 CEST] <momomo> or the tee pseudo-mixer ? [12:33:13 CEST] <momomo> I am getting the same error when using tee: [12:33:13 CEST] <momomo> http://hastebin.com/gahizareta.sm [12:40:06 CEST] <relaxed> momomo: omit -framerate 25 [12:40:44 CEST] <momomo> maybe, but then it probably doesn't matter .. or do you mean it would resolve my issue ? [12:41:53 CEST] <relaxed> no, but you should still do it [12:42:12 CEST] <momomo> hmm .. there is an error i am unable to spot .. i even reverted to older version and still getting same error [12:42:39 CEST] <momomo> maybe the extra spaces are not allowed ? [12:50:43 CEST] <tommy``> hello [12:51:48 CEST] <tommy``> which is the best gui for ffmpeg? [12:52:44 CEST] <BtbN> I prefer Cygwin MinTTY. [12:53:24 CEST] <ADenizA> Hello, I have an IP camera and I want to create a live-stream from a location inside the video (for example a motion tracked object). How can I create this live-stream using ffmpeg? More detailed: how can I push the frames I crop from the input video into an HLS stream using ffpmeg from code? [12:54:15 CEST] <sagax> hi all! [12:54:38 CEST] <sagax> how to change sample rate for libvorbis codec in ogg format? [12:55:08 CEST] <tommy``> BtbN: how do you do with commands? You remember the syntax every time? [12:55:40 CEST] <BtbN> Well, it doesn't change, so I only remembered it one time. [12:56:51 CEST] <tommy``> for example if i want extract an audio from .avi without knows the audio codec inside of it, what i have to do? [12:57:12 CEST] <sagax> -acode copy [12:57:14 CEST] <sagax> maybe [12:57:22 CEST] <BtbN> -i file.avi -c:a copy -vn -sn out.whatever [13:09:14 CEST] <Thor________> hi. Does anyone know if FFServer supports RTSP or HLS as streaming formats ? [13:11:16 CEST] <Thor________> or is it better to use FFMpeg as a "vod" server ? [13:43:56 CEST] <tommy``> is possible to increase the speed of extraction? actually I've 20-21x [13:44:46 CEST] <c_14> Get a faster hard drive? [13:45:05 CEST] <tommy``> it's 7200rpm [13:45:15 CEST] <c_14> Get an ssd [13:45:24 CEST] <tommy``> i've ssd on C: [13:45:34 CEST] <c_14> But no, there's not really a faster way. [13:45:40 CEST] <c_14> You're most likely IO-limited [13:45:48 CEST] <c_14> Short of getting a faster IO interface, there's not much you can do. [13:46:36 CEST] <tommy``> I think also my cpu/ram are crap for ffmpeg (dual core 2.60 ghz with 6GB ddr2) [13:46:56 CEST] <c_14> Shouldn't be that relevant if you're using -c copy [13:47:09 CEST] <tommy``> the command I'm using is: [13:47:18 CEST] <tommy``> ffmpeg -i file.avi -vn audio.mp3 [13:48:06 CEST] <furq> that's encoding the audio [13:48:17 CEST] <tommy``> not only plain extraction? [13:48:19 CEST] <furq> no [13:48:22 CEST] <tommy``> ah [13:48:24 CEST] <furq> -c:a copy will copy the audio stream [13:49:01 CEST] <tommy``> ok i'll try [13:53:09 CEST] <tommy``> furq: now i launched this: ffmpeg -i file.avi -c:a copy -vn -sn audio.mp3 [13:53:11 CEST] <tommy``> good? [13:53:29 CEST] <furq> sure [13:54:19 CEST] <tommy``> what does -sn means? [13:54:26 CEST] <furq> no subtitles [13:54:35 CEST] <furq> you probably don't need -vn or -sn if the output container is audio-only [13:54:38 CEST] <tommy``> so -vn i suppose "video no" [13:54:52 CEST] <furq> it would be useful if you were extracting to m4a or some other container which is also used for video [13:55:23 CEST] <tommy``> yes the output is only .mp3, i extract .mp3 to mux into a 1080p web-dl [13:58:58 CEST] <tommy``> furq i think i'll enjoy make some .bat for autoextracting audio with this string :D [14:15:12 CEST] <tommy``> something wrong here: ffmpeg -i audio08.mp3 -c:a libfdk_aac -b:a audio08.aac ? [14:29:49 CEST] <J_Darnley> Yes, you are encoding one lossy format to another [14:34:14 CEST] <furq> you didn't give an argument to -b:a [14:34:26 CEST] <furq> also you probably don't have libfdk_aac unless you compiled ffmpeg yourself [14:34:33 CEST] <tommy``> i change the syntax becuase it seems i haven't libfdk_aac on windows [14:34:36 CEST] <tommy``> now i'm using: [14:34:41 CEST] <J_Darnley> and if you want a minor speed up don't read and write to the same disk [14:34:42 CEST] <tommy``> ffmpeg -i audio08.mp3 -c:a copy audio.aac [14:34:49 CEST] <furq> well that's not going to work at all [14:35:14 CEST] <tommy``> ffmpeg -i audio08.mp3 -c:a aac copy audio.aac <<--- sorry [14:35:34 CEST] <furq> i'm going to assume you don't actually have "copy" in there [14:35:45 CEST] <furq> also use audio.m4a, not audio.aac [14:36:35 CEST] <tommy``> furq: "ffmpeg -i audio.mp3 aac audio.m4a" better? [14:37:34 CEST] <J_Darnley> If that is your literal command, no [14:37:45 CEST] <tommy``> yes i suppose yes [14:38:01 CEST] <tommy``> furq says that i don't have "copy" so i removed -c:a [14:38:19 CEST] <J_Darnley> Then what the heck does that "aac" belong to then? [14:40:21 CEST] <tommy``> ah yes: ffmpeg -i audio.mp3 audio.m4a [14:40:28 CEST] <tommy``> this seems working [15:07:01 CEST] <zamba> furq: i'm performing some additional tests with the following command now: ffmpeg -f video4linux2 -i /dev/video1 -f alsa -ac 2 -i default -c:a copy -vcodec ffv1 -level 3 -threads 2 -coder 1 -context 1 -g 1 -slices 24 -slicecrc 1 output.mkv [15:07:17 CEST] <zamba> furq: and that runs at around 25 fps (though, to begin with it's at around 30) [15:09:45 CEST] <zamba> but i'm getting bursts of these: Past duration 0.997215 too large [15:10:02 CEST] <furq> i'd have thought slicecrc would slow it down [15:11:33 CEST] <zamba> furq: so i should omit that? [15:11:41 CEST] <zamba> furq: but what is that "Past duration" message? [15:11:43 CEST] <furq> probably. i've never used ffv1 [15:12:23 CEST] <furq> you can usually ignore that warning [15:13:14 CEST] <zamba> i don't get it if i do '-f null -' instead of 'output.mkv' [15:13:25 CEST] <zamba> but then i instead get [null @ 0x9f152c0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 36 >= 36 [15:13:47 CEST] <zamba> every 70 or so frame [15:14:06 CEST] <zamba> and then the fps is 15 instead of 25.. so this makes no sense [15:18:00 CEST] <zamba> http://pastebin.com/03Gcg4N8 [15:31:11 CEST] <varu-> so i've got one ffmpeg instance listening to a udp stream sent to it by a device, it's an mpegts stream carrying multiple services/PIDs [15:32:06 CEST] <varu-> i'm successfully selecting one, however i'd like to run multiple ffmpeg sessions to be able to capture and decode all of them separately (they're being re-encoded and streamed via rtmp) [15:32:50 CEST] <varu-> when i try, ffmpeg throws a socket binding error, i'm assuming only one app can sit and listen on the udp port the stream is coming in on [15:33:38 CEST] <varu-> is there a way to have multiple ffmpeg sessions 'reading' the same udp port? [15:33:50 CEST] <c_14> varu-: just map separate outputs [15:34:08 CEST] <c_14> i.e. ffmpeg -i udp:// -map 0:1 out.mkv -map 0:2 -map 0:3 out2.mkv [15:34:10 CEST] <c_14> etc [15:34:30 CEST] <c_14> If that doesn't fit your usecase (you don't want them running all at the same time) you're going to have to get some sort of multiplexer in the middle [15:35:04 CEST] <varu-> i can do that, but will it use a separate thread for encoding each? [15:35:22 CEST] <Mavrik> yes [15:35:24 CEST] <c_14> yep [15:35:36 CEST] <c_14> It might even use several threads for each [15:35:48 CEST] <c_14> depending on the threading settings of the encoders used [15:37:06 CEST] <BtbN> isn't the ffmpeg "pipeline" single-threaded? Meaning that it will demux sequentialy, sending each frame/packet to the de/encoder in order, and not in parallel? [15:37:59 CEST] <Mavrik> Um, not sure about the question? [15:38:20 CEST] <Mavrik> Components that can be multithreaded are multithreaded. [15:38:30 CEST] <Mavrik> Ones where it makes no sense (muxers, demuxers) aren't. [15:41:12 CEST] <BtbN> The entire pipeline isn't though. [15:41:23 CEST] <BtbN> So one slow encoder will slow everything down. [15:41:50 CEST] <Mavrik> Uhm, why would it? [15:42:11 CEST] <BtbN> because that's what happens if something is single-threaded and some part of it only handled 5fps. [15:42:19 CEST] <varu-> my only concern with doing this is, should the stream IDs in the mux change (added or removed), i have to take the whole thing down to adjust [15:42:31 CEST] <varu-> running separate sessions would resolve that [15:42:47 CEST] <BtbN> you can't listen on the same port with multiple applications, so you have no other option if you want to use ffmpeg. [15:43:08 CEST] <c_14> Besides hanging some sort of multiplexer in front of ffmpeg [15:43:21 CEST] <BtbN> you could of course start one ffmpeg that just does -c copy to a local http/tcp server [15:43:29 CEST] <BtbN> and then connect multiple other ffmpeg to that. [15:43:47 CEST] <varu-> that's certainly an idea! [15:44:01 CEST] <Mavrik> BtbN, yes, but that's not completely the case with ffmpeg [15:44:07 CEST] <Mavrik> It depends on encoders though. [15:44:26 CEST] <BtbN> As far as I'm aware, ffmpeg is only multithreaded within codecs/filters [15:44:37 CEST] <BtbN> the API itself is strictly single-threaded and synchronous [15:45:06 CEST] <Mavrik> Yes. [15:45:13 CEST] <Mavrik> Hence "depends on encoders" [15:45:28 CEST] <Mavrik> Because some queue input files, dispatch to threads and then give you output on next invocation. [15:45:32 CEST] <Mavrik> Same for filters. [15:45:56 CEST] <BtbN> Yes, but if one encoder in the entire single thread is capped at 5 fps, the entire pipeline can't run faster than that. [15:46:46 CEST] <BtbN> Even if there is an entirele seperate branch of the filter/encode graph that in theory could run faster on its own [15:46:56 CEST] <Mavrik> Yes. That's why it depends on encoders :) [15:47:19 CEST] <BtbN> Uhm, not realy [15:47:21 CEST] <Mavrik> On a decently fast machine encoding x264 isn't problematic [15:47:26 CEST] <Mavrik> It'll saturate cores well. [15:47:35 CEST] <Mavrik> Other encoders are a bit more problematic. [15:47:37 CEST] <BtbN> But encoding with x264 5 times in the same thread could very well be [15:47:51 CEST] <BtbN> even if all 5 of them could still run 30 fps on their own, even in parallel [15:54:36 CEST] <hanshenrik_> how can i ask ffmpeg if the input is a static image or something else? [15:58:29 CEST] <J_Darnley> You want to know if a video is the same frame repeated? Or at least very similar? [15:58:52 CEST] <hanshenrik_> no, i want to know if the input file is a .jpg or a .mp4 [15:58:56 CEST] <hanshenrik_> or something else [15:59:10 CEST] <hanshenrik_> .jpg / .png / .bmp etc are static [15:59:18 CEST] <hanshenrik_> .mp4 would not be [15:59:24 CEST] <hanshenrik_> as for .gif... dunno [15:59:32 CEST] <J_Darnley> Number of video frames then. [15:59:34 CEST] <hanshenrik_> yeah [15:59:37 CEST] <hanshenrik_> that! [15:59:39 CEST] <J_Darnley> Perhaps ffprobe [15:59:59 CEST] <J_Darnley> and its show frames option [16:00:26 CEST] <hanshenrik_> and it has a json output format! fantastic [16:00:43 CEST] <hanshenrik_> thanks [16:20:26 CEST] <varu-> hmm, looking at ffserver, i wonder if theres a way to get it to copy the feed to multiple streams [16:20:49 CEST] <varu-> looking at the stream config parameters, you *have* to do encoding on them, you can't just copy the raw feed... or can you? [16:41:21 CEST] <hanshenrik_> is that correct? [16:41:28 CEST] <hanshenrik_> wrong window [16:43:08 CEST] <hanshenrik_> the -print_format json seems to be bugged [16:43:39 CEST] <hanshenrik_> it printed { [mjpeg @ 0x47d60] changing bps to 8 \n Input #0, image2~~t [16:43:45 CEST] <hanshenrik_> that's not like any json i've ever seen [16:43:49 CEST] <hanshenrik_> ohhh wait [16:43:56 CEST] <hanshenrik_> maybe its just stdout and stderr mixed [16:48:59 CEST] <hanshenrik_> ffprobe -print_format json -count_frames 'jpeg.jpg' [16:49:08 CEST] <hanshenrik_> its returning an empty json [16:49:09 CEST] <hanshenrik_> and -1 [16:49:14 CEST] <hanshenrik_> in a valid .jpeg file [16:49:47 CEST] <hanshenrik_> valid .mp4 file* x.x [16:50:25 CEST] <hanshenrik_> ffprobe -print_format json -count_frames 'mp4.mp4' [16:50:42 CEST] <hanshenrik_> valid mp4 file, i can play it back just fine, [16:50:48 CEST] <hanshenrik_> it gives me empty json and returns -1 [16:50:58 CEST] <hanshenrik_> it does detect video stream and auto stream [16:51:12 CEST] <hanshenrik_> says "video: h264" etc etc [16:51:20 CEST] <hanshenrik_> any idea what im doing wrong? [16:53:53 CEST] <hanshenrik_> json ffprobe -print_format json 'mp420.mp4' also empty json [16:58:46 CEST] <hanshenrik_> apparently i need to add -select_streams v:0 [16:58:56 CEST] <hanshenrik_> then it started giving sensible output ^^ [17:04:33 CEST] <hanshenrik_> .. and -show_streams [17:39:52 CEST] <hanshenrik_> https://trac.ffmpeg.org/wiki/Create%20a%20thumbnail%20image%20every%20X%20s… [17:40:07 CEST] <hanshenrik_> nvm [17:43:32 CEST] <momomo> is this -tee command flawed? [17:43:35 CEST] <momomo> tee -map 0:v -map 0:a /momomo/Generated/Tv/3220225315SVT1/c|[s=480x320]/momomo/Generated/Tv/3220225315SVT1/m [17:43:47 CEST] <momomo> do I need to escape the path ? [17:44:35 CEST] <J_Darnley> | is a special char in most shell so I would expect "yes" [17:58:06 CEST] <momomo> J_Darnley, I am trying to create multiple outputs [17:58:12 CEST] <momomo> here is my full command: [17:58:15 CEST] <momomo> ffmpeg -i http://user:pass@domain.ca:9981/play/stream/channel/9dd70a30d7f544e23950f7e… -x264-params scenecut=0 -x264opts keyint_min=125 -g 125 -r 25 -framerate 25 -b:v 1024k -bufsize 1024k -minrate 1024k -maxrate 1024k -c:v libx264 -c:a libvo_aacenc -b:a 64k -ac 2 -f hls -hls_list_size 3 -hls_time 5 -hls_flags delete_segments -f tee -map 0:v -map 0:a "/momomo/Generated/Tv/3220225315BBB/c|[s=480x320]/momomo/Generated/Tv/3220225315AA [17:58:15 CEST] <momomo> A/m" [17:58:30 CEST] <momomo> http://hastebin.com/etucufutup.sm [17:58:34 CEST] <momomo> but it is not working [17:58:43 CEST] <momomo> not sure what is wrong here [18:02:34 CEST] <momomo> is it possible to generate multiple hls outputs from one command? or is this only for mp4 and others ? [18:08:17 CEST] <explodes> Repeated uses of av_probe_input_format fails with a segfault, I have no idear what could be causing it - none of the data I'm passing in is novel [18:08:23 CEST] <J_Darnley> What does "not working" mean? [18:09:11 CEST] <rrva> how can I get ffprobe to display TS packet number and byte position for each i-frame? [18:09:16 CEST] <J_Darnley> Am I going to have to allow javascrip to read that? [18:09:25 CEST] <J_Darnley> It better contain ffmpeg's output. [18:09:42 CEST] <podman> Are there any benefits to having one ffmpeg process produce multiple outputs vs multiple ffmpeg processes producing a single output running concurrently? [18:09:52 CEST] <J_Darnley> ... it doesn't [18:10:34 CEST] <J_Darnley> podman: reading input once might be better than several times. [18:10:50 CEST] <J_Darnley> perhaps an input device can only be opened once. [18:10:59 CEST] <J_Darnley> perhaps it is a network stream [18:11:20 CEST] <J_Darnley> perhaps it is a collosal uncompressed 4k file so all the time is spent reading it from disk [18:12:01 CEST] <podman> Right now I think memory is a constraint. Testing encoding a 8K file into multiple resolutions. 32GB of ram and it runs out :\ [18:14:47 CEST] <J_Darnley> Well encoding 8k isn't going to be easy on memory [18:15:35 CEST] <J_Darnley> First of all make sure you are using a 64bit binary [18:15:48 CEST] <J_Darnley> Then perhaps look at the encoding settings [18:16:22 CEST] <J_Darnley> If you were using libx264 I would tell you to reduce the lookahead and save some memory [18:16:41 CEST] <J_Darnley> Other encoders, libx265 for instance, may have a similar option. [18:19:40 CEST] <momomo> anyone knows how to create several hls segments files? one for mobile ( smaller size ) and one for computers [18:20:22 CEST] <J_Darnley> Use several outputs, not the tee muxer [18:20:46 CEST] <momomo> I was hoping that I didn't had to [18:21:19 CEST] <J_Darnley> The tee muxer is for writing the same thing to several places (if I understand it correctly) [18:21:51 CEST] <podman> Yeah, I switched the preset from faster to veryfast and at least I didn't run out of memory (i know that reduces lookahead) [18:22:27 CEST] <podman> it'll be interesting to see what kind of gains there may or may not be by using one FFMPEG process instead [18:23:00 CEST] <furq> well you only have to decode it once if you do it all in one process [18:23:03 CEST] <J_Darnley> What format and codec is the input? [18:23:15 CEST] <podman> i think it's just mp4 h264 [18:23:26 CEST] <podman> but ultimately it could be anything [18:23:29 CEST] <furq> with an 8K source i'd imagine that's not insignificant [18:24:06 CEST] <podman> furq: yeah, I'll have to test it out. It would be a major rewrite, but could be worth it in the end [18:24:08 CEST] <furq> i'd be doing that regardless of the source, though [18:24:20 CEST] <furq> there's no point duplicating work even if it's only decoding [18:27:10 CEST] <momomo> furq, is hls segmenting into differnt output formats using tee going to work ? [18:27:26 CEST] <furq> 17:21:19 ( J_Darnley) The tee muxer is for writing the same thing to several places (if I understand it correctly) [18:27:29 CEST] <furq> doesn't look like it [18:27:41 CEST] <momomo> tried this: http://hastebin.com/iyalagogen.sm [18:28:36 CEST] <momomo> but i am getting: Opening an output file: c.m3u8|[s=480x320]m.m3u8. [18:28:51 CEST] <momomo> I also tried to escape that part but the quotes just got included [18:29:00 CEST] <furq> yeah that's not what the tee muxer does [18:29:12 CEST] <furq> it's for writing the same output to multiple files [18:29:18 CEST] <furq> if you want different outputs then use multiple outputs [18:29:32 CEST] <J_Darnley> http://ffmpeg.org/ffmpeg-formats.html#tee [18:29:40 CEST] <furq> https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs#Samefilteringfor… [18:29:44 CEST] <furq> i'm pretty sure you linked that earlier [18:29:46 CEST] <furq> that's what you want [18:29:55 CEST] <momomo> i thought because it could take more options it could do that: -map 0:a "output.mkv|[f=mpegts]udp://10.0.1.255:1234/" [18:29:57 CEST] <momomo> from https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs [18:30:19 CEST] <furq> yes that is what it does [18:30:25 CEST] <furq> but that's not what you said you want to do [18:30:54 CEST] <momomo> well, i though i could pass another size in there [18:31:00 CEST] <furq> oh nvm i see what you mean. no it won't rescale [18:31:11 CEST] <momomo> so should I use filtering or no filtering ? [18:31:20 CEST] <furq> didn't i already answer this [18:31:30 CEST] <momomo> not sure, don't remember [18:31:38 CEST] <momomo> that was regarding the logo i think then [18:31:50 CEST] <furq> 10:49:08 ( furq) if you want to add an image then you'll need to filter all outputs [18:32:22 CEST] <furq> there's not really any clearer way to say it. if you want to apply filters then apply filters, otherwise don't [18:32:58 CEST] <podman> J_Darnley: furq: yeah... so it uses WAY less memory, so that's an improvement. might be way slower though [18:33:09 CEST] <momomo> ook, i will probably but I meant this specific case, generating sizes .. but I guess it doesnt has to do with filter or not [18:42:36 CEST] <momomo> it works now using this huge command, do I have to repeat all of it in the second? [18:42:36 CEST] <momomo> ffmpeg -v 9 -loglevel 99 -re -i http://user:pass@domain.com:9981/play/stream/channel/9dd70a30d7f544e23950f7… -s 1280x720 -x264-params scenecut=0 -x264opts keyint_min=125 -g 125 -r 25 -framerate 25 -b:v 1024k -bufsize 1024k -minrate 1024k -maxrate 1024k -c:v libx264 -c:a libvo_aacenc -b:a 64k -ac 2 -f hls -hls_list_size 3 -hls_time 5 -hls_flags delete_segments /momomo/Generated/Tv/3220225315BBB/c.m3u8 -s 480x320 -x264-params [18:42:36 CEST] <momomo> scenecut=0 -x264opts keyint_min=125 -g 125 -r 25 -framerate 25 -b:v 1024k -bufsize 1024k -minrate 1024k -maxrate 1024k -c:v libx264 -c:a libvo_aacenc -b:a 64k -ac 2 -f hls -hls_list_size 3 -hls_time 5 -hls_flags delete_segments /momomo/Generated/Tv/3220225315AAA/m.m3u8 [18:42:58 CEST] <momomo> the go from -s to -s [18:43:02 CEST] <momomo> they* [18:43:28 CEST] <momomo> more readable format: http://hastebin.com/ujuliyohiv.sm [18:43:35 CEST] <momomo> do you see any potential improvemtns ? [18:44:41 CEST] <momomo> for some reason, my mobile output with a smaller screen resulted in larger ts files [18:44:44 CEST] <momomo> :S [18:47:24 CEST] <momomo> is -re option any good? [18:48:23 CEST] <furq> it makes no difference for your use case [18:48:41 CEST] <momomo> ook good to know [18:48:54 CEST] <furq> also your outputs are different aspect ratios [18:49:52 CEST] <furq> and you're using the same bitrate for both streams, which is probably why the smaller one generated larger outputs [18:50:17 CEST] <momomo> oh, should i perhaps change to crf 23 or simialar ? [18:50:28 CEST] <furq> i thought you wanted a fixed bitrate [18:50:59 CEST] <momomo> i am confused at this point. what i really want is fixed segment length [18:51:15 CEST] <furq> you already have that [18:51:16 CEST] <momomo> i think your keint_min and -r 25 did that [18:51:23 CEST] <furq> i thought you also wanted fixed segment size [18:51:35 CEST] <momomo> no, i had mistakenly imagined that was important [18:51:38 CEST] <furq> oh ok [18:51:46 CEST] <momomo> it was actually the time that is important to avoid lags [18:51:49 CEST] <furq> well yeah crf is much better than b:v [18:51:57 CEST] <furq> you can use the same value for both [18:52:11 CEST] <furq> the same crf value for both output streams, i mean [18:52:12 CEST] <momomo> ooh much prettier picute [18:52:16 CEST] <momomo> picture now [18:52:26 CEST] <furq> 1mbit is very low for 720p [18:52:29 CEST] <momomo> yes, I am repeating the command [18:52:29 CEST] <furq> so i'm not surprised [18:53:32 CEST] <momomo> size on mobile is now around 300 k but the desktop one has grown bigger up to 1.1 mb from around 600 [18:53:48 CEST] <momomo> cpu is way down too [18:54:17 CEST] <momomo> or maybe not.. was a temporary flux [18:59:04 CEST] <momomo> i removed the -s 1280x720 and size got smaller too [18:59:12 CEST] <momomo> maybe the source is not that big [19:02:00 CEST] <momomo> ffmpeg is logging the source format [19:02:02 CEST] <momomo> 720x576 [19:02:28 CEST] <momomo> is there a way to set a max size ? because I think now ffmpeg is upscaling the video [19:02:38 CEST] <momomo> if it is less, then it can leave it as is [19:02:46 CEST] <momomo> no point in upscaling it [19:06:16 CEST] <momomo> is this it: -vf "scale=iw*min(1\,if(gt(iw\,ih)\,640/iw\,(640*sar)/ih)):(floor((ow/dar)/2))*2" ? [19:06:18 CEST] <momomo> from: http://superuser.com/questions/566998/how-can-i-fit-a-video-to-a-certain-si… [19:08:17 CEST] <furq> as long as the aspect ratio remains intact that should be fine [19:09:37 CEST] <momomo> the aspect ratio can vary ? [19:10:18 CEST] <furq> 720*576 is 1.25:1, so it's always anamorphic [19:11:10 CEST] <fatpelt> afternoon all. i've got a command i'm running that opens 16 http streams and then stacks them all up. when i look at the processor utilization i've got one core maxed and 29 others empty. i'm a compile out of current git. is tehre something i'm missing to use all my other cores? [19:11:33 CEST] <furq> if you're downscaling, it'll look nicer if you scale it to the actual AR [19:12:14 CEST] <furq> if you leave it at the native resolution and don't manually set the AR it should get passed through to the player [19:12:28 CEST] <furq> it works with hls.js in firefox if nothing else [19:12:57 CEST] <momomo> furq, yes, i am just worried that the sources might have very high resolution or size and I would like to cap it at the top [19:13:12 CEST] <furq> yeah you have some nontrivial scale command to write [19:13:13 CEST] <momomo> am I scaling it wrong now then ? the 640 here refers to the width ... i am guessiong the height gets the original aspect . [19:13:24 CEST] <momomo> -vf "scale=iw*min(1\,if(gt(iw\,ih)\,640/iw\,(640*sar)/ih)):(floor((ow/dar)/2))*2" ? ? [19:13:28 CEST] <momomo> no goo? [19:13:31 CEST] <momomo> no good? [19:13:38 CEST] <furq> you can just scale it proportionately and keep it anamorphic [19:14:13 CEST] <furq> that's the simplest way to do it [19:14:45 CEST] <momomo> furq, unfortunately i am not sure how to go about writing such a function ... i figured this function already did that .. maybe it does something else [19:15:09 CEST] <furq> i believe that function will do what you want if you want the smaller outputs to be anamorphic [19:15:16 CEST] <furq> or rather if you're happy with that [19:15:59 CEST] <momomo> isn't anamorphic always preferable ? let the device rescale it [19:16:05 CEST] <furq> i'd expect the picture quality to be slightly worse [19:16:13 CEST] <furq> and i'm not totally confident that every player will scale it correctly [19:16:24 CEST] <momomo> furq, i am thinking mobile devices [19:16:31 CEST] <momomo> iphone should be able to .. [19:16:36 CEST] <furq> give it a try [19:16:57 CEST] <furq> it'll probably be fine [19:17:25 CEST] <furq> it might be preferable all round if you want to keep the bandwidth low [19:17:45 CEST] <furq> it's certainly preferable for the native res stream [19:18:33 CEST] <momomo> i am not sure that command does it after all .. it seems 640x640 refers to height and width .. he wanted a squarre ... i would like to specify the width and let the height scale down appropiatelly [19:18:36 CEST] <momomo> 1:1 [19:18:51 CEST] <furq> change the bit after the : to -2 [19:20:04 CEST] <momomo> ill try that [19:20:12 CEST] <momomo> i found this scale=720x406,setsar=1:1 on : http://video.stackexchange.com/questions/9947/how-do-i-change-frame-size-pr… [19:20:40 CEST] <furq> scale=if(gt(iw\,640),640,iw):-2 [19:20:40 CEST] <furq> i think that's all you need? i've not used scale expressions much [19:21:05 CEST] <furq> don't use setsar if you want to keep it anamorphic [19:21:13 CEST] <momomo> ook [19:21:31 CEST] <momomo> so discard: -vf scale=iw*min(1\,if(gt(iw\,ih)\,1280/iw\,(1280*sar)/ih)):-2 [19:22:53 CEST] <momomo> furq, can I donate some money since you have helped me so much ? :D [19:24:11 CEST] <furq> sure [19:25:22 CEST] <momomo> paypal? [19:44:46 CEST] <zamba> furq: are you able to help me out a bit more? [19:45:15 CEST] <furq> i can try [19:45:26 CEST] <furq> i don't think i know any more than you about ffv1 though [19:51:17 CEST] <zamba> yeah, but you know way more about ffmpeg [19:52:13 CEST] <apocalipsis> hi, mi name is ariel and I'm an android developer, anybody works with android and ffmpeg to compress at low level?(without command line, using NDK) [19:57:14 CEST] <Mavrik> you'll get more useful answers if you actually ask the question [19:59:46 CEST] <whald> hi! i'm trying to transcode video segments suitable for http live streaming (HLS) on-demand. i'm currently prototyping that stuff using the ffmpeg commandline tool and a bash script, and this is what I currently have: http://pastebin.com/RidVwtdw [20:00:27 CEST] <whald> to my surprise, this actually plays in firefox and chrome video tags (through the help of hls.js) [20:00:51 CEST] <Mavrik> um [20:01:00 CEST] <Mavrik> Is there a reason why aren't you using ffmpeg's segmenter? [20:01:01 CEST] <whald> yet, the generated segments are still off regarding the contained PTSs. is what I'm trying to do even sensible? [20:01:47 CEST] <whald> Mavrik, yes, because i'd like to provide the capability to do bitrate switching and i have neither the computing nor storage capabilities to create the segments offline. [20:01:59 CEST] <whald> Mavrik, though that would be very nice indeed. [20:02:14 CEST] <Mavrik> I don't understand. [20:02:52 CEST] <Mavrik> Thing is, doing it like you do will have issues with keyframes, PAT/PMT tables and exact PTS limits [20:02:56 CEST] <Mavrik> especially on more broken players [20:03:12 CEST] <zamba> furq: i believe we can forget about the ffv1 codec.. it just doesn't work performance wise [20:03:20 CEST] <Mavrik> That's why you have a segmenter in ffmpeg that does segmenting properly for you and can do it pretty much live if necessary [20:03:24 CEST] <zamba> furq: do you have yet another alternative? [20:04:05 CEST] <whald> Mavrik, to my understanding, the ffmpeg segmenter creates segments 1) in the order they appear in the source file and 2) for a single resolution/bitrate. and i'd really like to be able to adapt bitrate and jump forward to parts not transcoded yet. [20:04:25 CEST] <Mavrik> So? [20:04:39 CEST] <Mavrik> I mean, you can tell ffmpeg when to start :) [20:05:08 CEST] <Mavrik> The way you want to do is... problematic. [20:05:19 CEST] <Mavrik> Since players will expect segments to have synchronized keyframes and PTS. [20:05:28 CEST] <Mavrik> Which may or may not be doable by how you want to do it. [20:05:49 CEST] <JEEB> do note: I have seen services not match up their IRAPs for years [20:05:56 CEST] <JEEB> it's usually third party streaming servers [20:05:59 CEST] <apocalipsis> Mavrik, my question was about if anyone knows a wrapper to make video compression in android, detect video orientation, size, bitrate, to create trim functionality in my app [20:06:03 CEST] <Mavrik> JEEB, yp [20:06:09 CEST] <Mavrik> Most players handle it, but not all. [20:06:10 CEST] <JEEB> and maybe some semi-broken HLS implementations [20:06:22 CEST] <Mavrik> We had bunch of issues with Androids and some STBs [20:06:24 CEST] <JEEB> basically the HLS spec says that you shouldn't depend on the segments for anything [20:06:30 CEST] <JEEB> android has been OK as far as I know [20:06:35 CEST] <JEEB> maybe some older versions [20:06:42 CEST] <Mavrik> Yeah, 4.0 or so [20:06:56 CEST] <JEEB> well the services I can think of started at around 2011 or so... [20:07:13 CEST] <JEEB> STBs and other plastic boxes of course are a completely separate tale [20:07:22 CEST] <Mavrik> apocalipsis, I'd just compile ffmpeg binary and invoke it. [20:07:28 CEST] <Mavrik> Wouldn't even touch NDK. [20:07:45 CEST] <JEEB> NDK isn't too bad, but it requires knowledge of the libav* APIs [20:07:58 CEST] <JEEB> also I don't think libavcodec has encoding yet on android HW [20:08:07 CEST] <JEEB> although not sure [20:08:20 CEST] <Mavrik> MediaCodec patches I've seen were player only. [20:08:25 CEST] <JEEB> yes [20:08:26 CEST] <Mavrik> Encoding with that is hell anyway. [20:08:34 CEST] <whald> Mavrik, to my understanding, each segment must start with a keyframe. this is the case with my script, and the timestamps should be copied from the source. even this is mostly ok, except that the segments i'm generating are a tad too short at times. i feel like this might be a problem with my "select" filter, instead of the 10 seconds i'm going for i always end up the 8.5 seconds for the first segment. i don't understand why. [20:08:36 CEST] <JEEB> I have been dealing with mediacodec with mpv-on-android [20:08:55 CEST] <Mavrik> I've just been dealing with it directly and it was... fun. [20:09:16 CEST] <Mavrik> But for general video processing just doing Runtime.exec() on a ffmpeg binary was way easier [20:09:23 CEST] <JEEB> sure [20:09:24 CEST] <Mavrik> Especially since JNI has a nasty overhead [20:09:35 CEST] <Mavrik> And requires people to learn C which is usually an issue :P [20:09:58 CEST] <JEEB> anyways, re: HLS - unless you are basically having your major client being an STB that you know has issues with mismatching GOPs, that is not a problem as long as your maximum GOP length is properly noted in the playlist [20:10:21 CEST] <JEEB> at least if you're generating the HLS yourself [20:11:00 CEST] <apocalipsis> it's true, I make some tests, but I don't have knowledge about the use of ffmpeg libs low level programming [20:11:17 CEST] <apocalipsis> and it's a hard work [20:11:21 CEST] <JEEB> yes [20:11:49 CEST] <JEEB> I recommend you look for someone to do some consultancy work [20:12:04 CEST] <JEEB> usual prices probably go around $100/h [20:12:59 CEST] <apocalipsis> and make a wrapper, and no broke mi head, sounds good :) [20:14:19 CEST] <apocalipsis> thanks JEEB and Mavrik!! [20:22:02 CEST] <netw1z> is there a way to convert AIFC to wav with ffmpeg? [20:25:43 CEST] <petecouture> netw1z: aiff files? [20:25:48 CEST] <rjp421> is there a way to get the ffmpeg cmd that would output the same codec/bitrate etc of a given file? [20:26:16 CEST] <netw1z> AIFF in general, but I havent been able to convert AIFC files [20:26:51 CEST] <netw1z> soxi and ffmpeg complain about unknown codec in24 for AIFC (compressed AIFF) [20:27:11 CEST] <durandal_1707> sample? [20:27:35 CEST] <durandal_1707> aifc should be supported [20:29:05 CEST] <netw1z> a sample aifc file? i have one [20:29:34 CEST] <durandal_1707> Yes, upload it somewhere [20:30:52 CEST] <netw1z> khttp://mvgen.com/test.aifc [20:30:55 CEST] <netw1z> http://mvgen.com/test.aifc [20:32:23 CEST] <netw1z> the latter one durandal_1707 [20:33:47 CEST] <petecouture> I can hear on the last link [20:34:07 CEST] <petecouture> rjp421: You're looking for ffprobe I think [20:36:07 CEST] <rjp421> petecouture, i can see the details with ffprobe but am unsure on the args to reproduce them sufficiently.. like to output something thats the same as an mp4 from youtube-dl, so i can pipe into castnow [20:36:32 CEST] <durandal_1707> netw1z: works fine here, what ffmpeg version you use? [20:36:54 CEST] <petecouture> what do you meanunsure of arges? [20:36:59 CEST] <petecouture> args* [20:37:29 CEST] <rjp421> petecouture, for the ffmpeg cmd [20:38:00 CEST] <rjp421> im particular bitrate and fps/gop etc [20:39:18 CEST] <rjp421> i assume chromecasts are picky and will expect those particulars [20:40:28 CEST] <netw1z> wow [20:40:40 CEST] <netw1z> 1.0.10 [20:40:53 CEST] <rjp421> hopefully im wrong and can just use defaults? [20:41:24 CEST] <netw1z> duranda1_1707 Ffmpeg version 1.0.10 [20:44:36 CEST] <durandal_1707> netw1z: 3.0.1 is latest release [20:45:03 CEST] <netw1z> yow [20:46:04 CEST] <netw1z> thanks - let me get on that now [20:46:40 CEST] <rjp421> petecouture, "Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 1890 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default)" - other than using x264 with profile high at 720p and 29.97 fps, and the aac 192kb 44100khz 2channel audio, should i further specify bitrate etc? [20:47:25 CEST] <rjp421> to match that ffprobe output [20:56:56 CEST] <rjp421> i just want to output a known clean stream that shouldnt give me any bs further down the line [21:35:58 CEST] <podman> any idea why CBR is so much slower than VBR? I'm trying to start transcoding video for HLS but it seems prohibitively slow. [21:36:38 CEST] <c_14> cbr is vbr... [21:36:41 CEST] <c_14> eh, no [21:36:43 CEST] <c_14> sorry [21:36:45 CEST] <c_14> misread [21:36:47 CEST] <c_14> For what codec? [21:36:53 CEST] <podman> h.264 [21:37:15 CEST] <c_14> hmm, cbr should be faster [21:38:08 CEST] <podman> seems to be much slower [21:38:17 CEST] <furq> what are you calling cbr [21:38:20 CEST] <JEEB> what's your definition of CBR and VBR, first of all [21:38:43 CEST] <c_14> Hmm, -b:v does seem slower than -crf [21:38:44 CEST] <furq> probably just pastebin your "cbr" and "vbr" commands [21:39:12 CEST] <podman> furq: sure, can do [21:39:20 CEST] <c_14> hmm, nvmd might just be slight bitrate differences [21:39:38 CEST] <furq> i don't know why i put "vbr" in quotes when it will definitely be vbr [21:41:08 CEST] <podman> http://pastebin.com/a7wQfEQ6 [21:42:23 CEST] <furq> not that it has anything to do with your issue, but -b:a will be being ignored there [21:42:55 CEST] <podman> furq: ah, true [21:43:10 CEST] <furq> in the first one, that is [21:43:19 CEST] <c_14> podman: is the average bitrate of both commands the same? [21:43:38 CEST] <c_14> rather, is the average bitrate of the first command 2400k [21:43:46 CEST] <podman> c_14: not sure. can check [21:43:53 CEST] <furq> yeah if the average bitrate of the second one is higher then that'd account for the slowdown [21:44:26 CEST] <furq> is there a good explanation of how minrate/maxrate/bufsize work somewhere [21:44:44 CEST] <furq> particularly bufsize [21:44:55 CEST] <podman> overall bitrate, as reported by mediainfo of that one is 2339 Kbps [21:45:04 CEST] <podman> for the first command [21:45:05 CEST] <c_14> bufsize is the number of bites over which the average bitrate is calculated [21:45:18 CEST] <furq> bits or bytes [21:45:37 CEST] <c_14> I think bytes [21:45:43 CEST] <podman> bit rate for the video track, as reported by mediainfo, is 2222 Kbps [21:45:50 CEST] <furq> ...weird [21:46:02 CEST] <c_14> podman: how much faster is the crf one? [21:48:08 CEST] <podman> the crf one took 5:33 for a 4:31 8K video, the other one took...15:55 [21:48:27 CEST] <podman> same hardware, same load [21:48:32 CEST] <furq> that is weird [21:49:06 CEST] <furq> is it that slow with all the vbv stuff disabled [21:49:10 CEST] <c_14> Can you try actually setting a bitrate on the second with -b:v ? [21:49:21 CEST] <furq> oh that's a good point [21:49:58 CEST] <c_14> I also just noticed that the second command has -r and -g while the first doesn't [21:50:04 CEST] <c_14> try removing them or adding them to the first? [21:50:13 CEST] <c_14> ditto sc_threshold [21:50:49 CEST] <podman> kinda need those for HLS [21:51:04 CEST] <podman> doesn't really alter the transcoding speed though [21:52:57 CEST] Action: c_14 is mostly out of ideas. Does removing the audio track on both change anything? [21:53:17 CEST] <podman> that would be interesting [21:59:13 CEST] <podman> doesn't seem to do anything [22:00:33 CEST] <gnome1> can someone hilight me? I'm trying to test one thing here... [22:00:58 CEST] <hurstly> gnome1 [22:01:57 CEST] <gnome1> hurstly: thanks! and it worked! [22:02:59 CEST] <podman> furq: c_14: so nothing I'm doing looks weird? [22:02:59 CEST] <hurstly> no problem :) [22:03:24 CEST] <podman> so, the different machines are using different versions of FFMPEG and possibly libx264 [22:03:39 CEST] <podman> seems unlikely that newer versions would be slower though? [22:04:59 CEST] <podman> need to find a way to make this reasonably fast. trying to do this on elastic transcoder or zencoder would be prohibitively expensive. [22:05:01 CEST] <c_14> Wait, this is running on different machines? [22:05:06 CEST] <c_14> Could be instruction sets [22:05:10 CEST] <c_14> More optimizations on one cpu etc [22:07:21 CEST] <podman> c_14: both jobs are running on the same version of linux on the same hardware (EC2 c4.4xlarge) [22:07:32 CEST] <podman> just different instances [22:08:14 CEST] <c_14> Try using the same version of ffmpeg/libx264 on both? Maybe with a static build. [22:08:59 CEST] <kepstin> podman: hmm, I think c4 machines should all be using the same (or at least similar) cpus. But you might get varying cpu performance based on what other users are sharing the host. [22:13:20 CEST] <podman> kepstin: they're both running on dedicated tenancy [22:14:08 CEST] <podman> and they all are running on Intel Xeon E5-2666 v3 processors [22:16:06 CEST] <kepstin> oh, you're using vbv? [22:16:33 CEST] <kepstin> my impression is that encodes with vbv will be slower than crf or straight vbr, since there's more constraints the encoder has to satisfy. [22:17:12 CEST] <podman> what's vbv? [22:17:36 CEST] <kepstin> the minrate/maxrate/bufsize options [22:18:46 CEST] <podman> ah, well you need to do that to approximate cbr for libx264 [22:18:55 CEST] <kepstin> (they map to a set of options on x264 that start with 'vbv', see https://en.wikipedia.org/wiki/Video_buffering_verifier ) [22:19:12 CEST] <kepstin> yeah, and it makes the stream harder (aka slower) to encode. [22:19:34 CEST] <JEEB> minrate is ffmpeg-specific btw, and I don't recommend using it [22:19:43 CEST] <JEEB> maxrate and bufsize map to libx264's stuff [22:20:16 CEST] <podman> seems like every tutorial recommends it if the output is going to be hls [22:22:51 CEST] <JEEB> not required and possibly harmful [22:23:21 CEST] <JEEB> or well, would make it use more bits so that you have less buffer to use in case the scene suddenly became more demanding [22:23:43 CEST] <JEEB> you only need maxrate and some other rate control mode. [22:23:52 CEST] <JEEB> uhh, maxrate+bufsize I mean of course [22:27:51 CEST] <podman> hmm [22:27:53 CEST] <podman> i'll test [22:28:19 CEST] <hanshenrik__> can i tell ffmpeg to output to a specific file descriptor? 0 is stdin, 1 is stdout, 2 is stderr, and 3 is another pipe opened by the caller process [22:28:27 CEST] <hanshenrik__> i want ffmpeg to output to pipe 3 [22:29:28 CEST] <c_14> pipe:3 [22:29:39 CEST] <hanshenrik__> nice [22:34:08 CEST] <podman> JEEB: made no difference [22:34:24 CEST] <JEEB> no idea what you were comparing, just noted in general [22:41:35 CEST] <podman> is there anything crazy i can do to speed up transcoding? split the file up into little chunks and have lots of servers process them at the same time? [22:42:38 CEST] <c_14> use a faster preset [22:43:15 CEST] <podman> in terms of net gains, that does very litt [22:43:16 CEST] <podman> e [22:43:43 CEST] <J_Darnley> You cannot do that with just ffmpeg. [22:44:16 CEST] <J_Darnley> There are some distributed encoders that come up now and again. [22:44:17 CEST] <netw1z> is there a compiled version of ffmpeg 3.0 for wheezy/debian i can install from somewhere? [22:44:23 CEST] <netw1z> i had an issue on compuile [22:44:25 CEST] <J_Darnley> Or at least there were. [22:45:21 CEST] <c_14> http://johnvansickle.com/ffmpeg/ <- netw1z [22:46:04 CEST] <podman> I'm just trying to find a way to make sure a 4:30 video doesn't take 25 minutes to transcode into all of the formats i need for HLS [22:48:43 CEST] <netw1z> thanks @c_14 [22:48:46 CEST] <netw1z> ccehking now [22:48:58 CEST] <hanshenrik__> when i tell ffmpeg to output to a .jpg file [22:49:09 CEST] <hanshenrik__> and i dont specify a -f format [22:49:14 CEST] <hanshenrik__> it will take a best guess [22:49:21 CEST] <c_14> it uses the file extension [22:49:23 CEST] <hanshenrik__> what format does it default to for out.jpg exactly? [22:49:27 CEST] <hanshenrik__> "mjpeg" ? [22:50:34 CEST] <kepstin> hanshenrik__: probably 'singlejpeg', but I'd have to check to make sure. [22:51:45 CEST] <netw1z> @c_14 do I just overwrite the existing binaries with these from johnvansickle.com [22:52:44 CEST] <kepstin> hanshenrik__: actually, no, it would be 'image2' [22:52:55 CEST] <hanshenrik__> thanks [22:53:03 CEST] <hanshenrik__> best name for a jpg format [22:53:05 CEST] <kepstin> which then internally does some stuff to select the real format for the images. [22:53:05 CEST] <hanshenrik__> "image2" [22:53:09 CEST] <hanshenrik__> oh [22:53:10 CEST] <hanshenrik__> ok [22:53:25 CEST] <kepstin> image2 is the generic format for outputing (sequences of) individual images. [22:53:26 CEST] <c_14> netw1z: put it in your PATH somewhere in front of your current binaries (like /usr/local/bin) [22:54:00 CEST] <c_14> You _can_ replace them, but if the current binaries are provided by your OS then that can create issues [22:54:36 CEST] <netw1z> my current binaries are in /usr/local/bin already [22:54:41 CEST] <c_14> then just replace them [22:54:45 CEST] <netw1z> sweet! [22:57:53 CEST] <netw1z> thanks @c_14 its rocking [23:04:41 CEST] <podman> what provider would you recommend for hardware for FFMPEG? I think we're reaching the limit of what EC2 can do cost effectively [23:06:06 CEST] <podman> i also tried using their GPU instances but it didn't seem to be any faster [23:06:53 CEST] <podman> using NVENC [23:07:40 CEST] <furq> just buy the cheapest dedicated server you can get which isn't an atom [23:12:11 CEST] <sagax_> hi all! [23:12:45 CEST] <sagax_> what about ffmpeg rendering process with network? [23:12:53 CEST] <sagax_> like as render farm [23:34:57 CEST] <VVelox> Is there anything like -s, but will use that as the bounds for scaling, keeping it in the aspect ratio? [23:35:30 CEST] <furq> -s 640:-2 [23:35:34 CEST] <furq> or whatever you want the width to be [23:35:42 CEST] <c_14> eeeh [23:35:47 CEST] <c_14> don't you need to use the scale filter for that? [23:36:00 CEST] <furq> doesn't -s just append the appropriate scale filter [23:36:18 CEST] <c_14> I think it does some strange parsing [23:36:29 CEST] <furq> well yeah either that or -vf scale=640:-1 [23:36:36 CEST] <furq> or -2 if you want it to be mod2 [23:37:01 CEST] <kepstin> if you're using yuv420, you want -2, otherwise you'll just get errors due to the subsampling. [23:37:45 CEST] <VVelox> Nice. Thanks! [23:43:59 CEST] <podman> so, i just tested the same jobs on AWS GPU instances and it was even slower [23:44:05 CEST] <podman> using nvenc [23:44:08 CEST] <podman> ugh [00:00:00 CEST] --- Fri Apr 1 2016

1 0