Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2016

1 participants
62 discussions

ffmpeg-devel.log.20160320
by burek 21 Mar '16

21 Mar '16

[02:54:39 CET] <atomnuker> what's the point of audio_frame_queue? [02:54:59 CET] <atomnuker> seems to only keep track of samples used for the current frame and just warns if you use less [03:24:54 CET] <rcombs> atomnuker: manages timestamps in output frames for codecs with delay [03:25:17 CET] <rcombs> or, well, packets [07:56:26 CET] <la> http://oortr.com/ZjllYz [10:05:36 CET] <cone-952> ffmpeg 03Paul B Mahol 07master:50f4b64c543d: avfilter/vf_waveform: set color range for output frames [11:24:13 CET] <cone-952> ffmpeg 03Michael Niedermayer 07master:7916f04b89d4: ffplay: Remove "&& 0" from already disabled debug code [11:32:28 CET] <kurosu> TheRyuu, could you provide your opinion on a breakage from a patch of yours: http://mplayerhq.hu/pipermail/ffmpeg-devel/2016-March/191195.html ? Thanks. [14:41:19 CET] <ubitux> 5 FIXME in lavf/dv.c meh [14:57:58 CET] <Daemon404> wait today is Sunday, wtf [14:59:52 CET] <J_Darnley> Yes it is. [15:00:06 CET] <Compn> palm sunday [15:00:09 CET] <Compn> next week is easter [15:00:16 CET] <Compn> stupid holidays. [15:08:29 CET] <Daemon404> i thought yesterday was sunday.... man sickness threw me right off [15:08:37 CET] <Daemon404> s/man/man,/ [15:11:44 CET] <J_Darnley> Being sick will do that [15:18:09 CET] <Compn> Daemon404 : its ok, i was hoping today was monday as well. [16:25:34 CET] <Daemon404> ubitux, have you started poking codecpar [16:26:15 CET] <ubitux> yes [16:26:19 CET] <ubitux> i'm "playing" with dv [16:26:21 CET] <Daemon404> ok [16:26:29 CET] <Daemon404> so you picked one of the most annoying onces [16:26:44 CET] <ubitux> well i did merge it last time but wasn't satisfied with the outcome [16:26:50 CET] <Daemon404> ok [16:26:58 CET] <ubitux> if the last patch i sent is accepted it should be fine [16:27:06 CET] <Daemon404> michael ok'd it i think [16:27:07 CET] <ubitux> i can work on some other area now [16:27:11 CET] <ubitux> yes, the first one [16:27:14 CET] <ubitux> i sent another one [16:27:54 CET] <Daemon404> looks reasonable. [16:28:07 CET] <Daemon404> just waiting for dist-upgarde to finish and im starting to poke stuff [16:28:24 CET] Action: Daemon404 has merge-guilt [16:28:29 CET] <Daemon404> wanna get it done now... [16:28:51 CET] <ubitux> any idea what i should look at now? [16:29:01 CET] <Daemon404> nevcairiel would know best what to prioritize [16:29:17 CET] <Daemon404> movenc is causing a lot of fate failues [16:29:18 CET] <Daemon404> so maybe that [16:31:50 CET] <ubitux> i feel like this is a trap [16:32:05 CET] <ubitux> but i guess all the remaining issues are trap [16:32:10 CET] <Daemon404> pretty much [16:32:15 CET] <Daemon404> except some monkey work [16:32:18 CET] <Daemon404> like porting lib*c [16:32:43 CET] <Daemon404> i was going to look into the nut failures [16:32:46 CET] <Daemon404> wrt ffprobe [16:33:52 CET] <ubitux> i'll start fixing the cc issue [16:34:05 CET] <ubitux> (fate-sub-cc) [16:34:14 CET] <Daemon404> theres something timebasey in microdvdenc too [16:34:17 CET] <Daemon404> isnt that a subtitle format [16:34:19 CET] <Daemon404> or am i misrememberong [16:38:15 CET] <Daemon404> oh there's a bumch of avfilter stuff that accesses ->codec it seems. [16:42:04 CET] Action: Daemon404 builds multiple ffmpeg's to compare fate output [16:42:17 CET] <Daemon404> is there a tool less crappy than vsbindiff yet for binary diffing in cli? [16:43:17 CET] <ubitux> xxd and vimdiff [16:43:30 CET] <Daemon404> that doesnt work very well when size changes ubitux [16:43:42 CET] <ubitux> :( [16:46:20 CET] <ubitux> mmh i guess the cc issue is also related to lavfi [16:46:34 CET] <Daemon404> figures [16:46:45 CET] <Daemon404> im starting to go through fate tests with vbindiff atm [16:46:51 CET] <Daemon404> ill update any hashes where it makes sense [16:46:55 CET] <Daemon404> fix muxers elsewhere [16:52:07 CET] <Daemon404> looks like lavf-mkv changed one DURATION tag due to use of stream timebase instead of codec timebase [16:52:17 CET] <Daemon404> im thinking that ought to be a hash update. [16:56:13 CET] <Daemon404> ubitux, mark any stuff fixed on the pad btw [16:56:38 CET] <ubitux> ok [16:57:16 CET] <Daemon404> ... lol fate refs with merge conflicts [17:02:37 CET] <ubitux> i suppose we're not going to add the timebase to codecpar? [17:04:41 CET] <Daemon404> i argue it still makes no sense to have a "codec" timebase. [17:04:50 CET] <Daemon404> bframes/delay will likely be added though [17:05:13 CET] <Daemon404> ubitux, at least a few of these lavf fate tests write identical files but fail with lavfi errors [17:05:14 CET] <ubitux> so we need to update every decoder using it? [17:05:21 CET] <Daemon404> yes thats how this works [17:05:38 CET] <ubitux> so that "lavf" commit/merge is also going to include all kind of changes to lavc? [17:05:56 CET] <Daemon404> ubitux, no [17:06:12 CET] <Daemon404> this is only for things using the codec time_base in stream->codec [17:06:23 CET] <Daemon404> which should be using the stream timebase IMO [17:06:52 CET] <ubitux> the thing is, apparently in lavc/ccaption_dec, codec time_base is 0/1 [17:07:03 CET] <ubitux> so it breaks the timing [17:07:12 CET] <ubitux> how to proceed here? [17:07:18 CET] <Daemon404> you need to be a bit clearered [17:07:20 CET] <Daemon404> why did it break now [17:07:25 CET] <Daemon404> because it was not set in lavf? [17:07:32 CET] <Daemon404> was it using it as some shitty way to pass stream timebase? [17:07:46 CET] <ubitux> well, i'd like to know if it's wrong for the codec to actually access it [17:07:56 CET] <ubitux> or if the issue is because it's not set [17:08:14 CET] <Daemon404> why would anything but lavc decoder set a codec timebase [17:08:28 CET] <Daemon404> it sounds like the issue youre seeing is that teh codec tb is no longer set in lavf [17:08:35 CET] <Daemon404> which sounds all sorts of wrong [17:11:21 CET] <Daemon404> hmmm where is wm4 or nevcairiel when you need them [17:16:00 CET] <nevcairiel> the question is where did it get the value before [17:18:34 CET] <nevcairiel> and why did lavf need to set it [17:18:55 CET] <nevcairiel> if there is a real need for the codec timebase, we can always re-introduce it with proper documentation and reasoning [17:19:51 CET] <Daemon404> nevcairiel, i had a different question actually =p [17:20:08 CET] <Daemon404> trying to figure out api-h264 failure [17:20:22 CET] <Daemon404> pkt->duration went from all 48000 to all 0 [17:20:30 CET] <Daemon404> didnt find much in rawdec [17:20:47 CET] <nevcairiel> i was going to say has_b_frames, but thats fate-h264-conf, not api-h264 [17:21:14 CET] <Daemon404> yeah this is unrelated to bframes. [17:21:39 CET] <nevcairiel> i wondered about the lack of duration there [17:21:43 CET] <nevcairiel> not sure how its determined [17:21:50 CET] <nevcairiel> what does api-h264 use as a source file? [17:21:58 CET] <Daemon404> h264-conformance/SVA_NL2_E.264 [17:22:01 CET] <Daemon404> it's an elementary stream [17:22:23 CET] <nevcairiel> so maybe its being silly and just basing this off of the codec timebase which it lost? [17:22:30 CET] <Daemon404> yeah but *where* [17:22:37 CET] <nevcairiel> utils.c probably [17:22:37 CET] <nevcairiel> :D [17:22:39 CET] <Daemon404> D: [17:23:37 CET] <nevcairiel> actually it uses the stream timebase [17:23:38 CET] <Daemon404> i mean it looks correct for a sample stream [17:23:40 CET] <Daemon404> it works out to 25 fps [17:23:51 CET] <Daemon404> is this parser related? [17:24:02 CET] <Daemon404> i dunno how it got that info or where from before [17:24:07 CET] <Daemon404> elementary stream stuff in lavf is "special" [17:24:35 CET] <nevcairiel> not sure right now, and i need to run grab dinner [17:24:41 CET] <Daemon404> k [17:24:59 CET] <nevcairiel> but pkt->duration isnt set in all that many places [17:25:19 CET] <nevcairiel> you could poke in ff_compute_frame_duration [17:25:33 CET] <Daemon404> ok [17:25:54 CET] <nevcairiel> not sure what i did to that in codecpar [17:26:01 CET] <nevcairiel> maybe it needs to use the internal avctx or something [17:27:13 CET] <Daemon404> interestingly, ffmpeg cli shows it as 25 fps, correctly [17:28:45 CET] Action: Daemon404 stares at set_codec_from_probe_data in awe [17:35:18 CET] <ubitux> Daemon404: yes, the time_base in st->codec->time_base is not set anymore, so when ffmpeg decodes with a copy of that codec context, shit breaks [17:35:37 CET] <ubitux> ccaption_dec expect that field to be set [17:36:55 CET] <ubitux> (there is all kind of time "adjustment" wrt sub->{pts,end_display_time}) [17:38:29 CET] <Daemon404> i got that [17:38:38 CET] <Daemon404> but i am askign where it is expecting it to be set *from* [17:38:43 CET] <Daemon404> where does that value come from that ccaptiondec uses [17:38:51 CET] <Daemon404> thats kind of a fundemental question [17:42:10 CET] <Daemon404> ok... solved the pkt duration failures [17:42:27 CET] <Daemon404> seems ffmpeg changed ff_compute_frame_duration to ignore avg_frame_rate entirely at some point [17:42:31 CET] <Daemon404> wtf? [17:42:44 CET] <Daemon404> (in favour of r_frame_rate, with no fallback to avg) [17:47:17 CET] <Daemon404> anyway... fixed [17:47:21 CET] <ubitux> ok found it [17:47:27 CET] <ubitux> avformat_new_stream() [17:47:29 CET] <ubitux> /* default pts setting is MPEG-like */ [17:47:31 CET] <ubitux> avpriv_set_pts_info(st, 33, 1, 90000); [17:47:33 CET] <ubitux> :-° [17:47:46 CET] <ubitux> i guess i'll hardcode 1/90000 in ccaption_dec then [17:48:45 CET] <JEEB> :D [17:49:04 CET] <Daemon404> ubitux, do we not have a constant for mpeg timebase [17:49:28 CET] <ubitux> can't find any [17:49:35 CET] <ubitux> libavformat/hls.c:#define MPEG_TIME_BASE 90000 [17:49:37 CET] <ubitux> just this one [17:49:37 CET] <Daemon404> lol [17:49:50 CET] <ubitux> probably not the best place... [17:50:13 CET] <Daemon404> its used in a lot of places, but eh... out of scope here [17:50:17 CET] <Daemon404> ignore me. [17:51:06 CET] <ubitux> any idea where the stream time base is copied to the stream codec timebase? [17:52:45 CET] <Daemon404> i'd grep but FATE is bogging down my machine [17:52:53 CET] <Daemon404> opening a new terminal is effort [17:54:37 CET] <ubitux> i wonder if it's really ok to hardcode mpeg timebase into ccaption decoder though [17:55:00 CET] <Daemon404> can ccaption be in anything but mpegts? [17:55:29 CET] <ubitux> mov etc [17:55:35 CET] <ubitux> wtv [17:55:37 CET] <kierank> can be in anything [17:56:12 CET] <JEEB> if it's the in-AVC stuff then indeed [17:57:24 CET] <Daemon404> does the spec say what timebase it's in? [17:58:13 CET] <kierank> it's cfr [17:58:23 CET] <kierank> so it has a bunch of supported framerates [17:59:30 CET] <Daemon404> kierank, so it's based on the framerate coded in the h264 bitstream? [17:59:35 CET] <Daemon404> (aka not container) [17:59:51 CET] <kierank> iirc there's a framerate code in the closed caption data [17:59:57 CET] <ubitux> the subtitles decoders are supposed to output subtitles pts in AV_TIME_BASE_Q (and start/end time in ms) [18:00:06 CET] <kierank> LOL [18:00:06 CET] <ubitux> so lavc actually needs to know the stream time base [18:00:11 CET] <kierank> what a fail [18:00:16 CET] <kierank> milliseconds... [18:00:27 CET] <kierank> when will OSS learn milliseconds are a shit timebase [18:00:40 CET] <ubitux> AVSubtitle is one of the very old struct [18:00:46 CET] <Daemon404> wait [18:00:47 CET] <ubitux> i never changed since the beginning [18:00:55 CET] <Daemon404> if there is a framerate code in the caption data [18:01:00 CET] <Daemon404> why do we need the stream timebase [18:01:09 CET] <Daemon404> just for start_time adjustment? [18:01:41 CET] <kierank> there might not be a framerate code I forget [18:01:50 CET] <Daemon404> also AV_TIME_BASE_Q is not ms [18:01:51 CET] <Daemon404> it is us [18:01:56 CET] <Daemon404> iirc. [18:02:05 CET] <kierank> again useless timebase [18:02:05 CET] <ubitux> most (all other?) subtitles decoders do the scaling from the stream timebase to AV_TIME_BASE_Q and ms into lavc/utils [18:02:15 CET] <ubitux> by using the avctx->time_base copied from the stream timebase [18:02:33 CET] Action: kierank stops trolling [18:02:35 CET] <ubitux> but ccaption_dec does it inside the decoder because there is some delay thing involved [18:03:01 CET] <Daemon404> wut [18:03:05 CET] <ubitux> the fundamental issue lies into AVSubtitle actually requiring to know the stream timebase to rescale the timings [18:03:14 CET] <ubitux> to AV_TIME_BASE_Q and ms [18:03:21 CET] <Daemon404> this sounds pretty... derp [18:03:30 CET] <ubitux> yes? [18:03:42 CET] <ubitux> so what do we do? :) [18:04:25 CET] <Daemon404> i dont get why ccaption ahs to do it in the decoder due to delay [18:05:49 CET] <ubitux> it's not really important since every subtitles decoder also has that issue, but deported to lavc/utils [18:06:04 CET] <ubitux> if lavc/utils can do it, ccaption dec could as well [18:06:04 CET] <Daemon404> shouldnt it be easy to 'fix' right now then [18:06:10 CET] <ubitux> how? [18:06:17 CET] <Daemon404> unless you mean utils also has to be fixed [18:06:19 CET] <ubitux> how do you fix that without changing the api? [18:07:01 CET] <ubitux> should i quickly introduce a way to decode into AVFrames? :P [18:11:53 CET] <Daemon404> ubitux, how did libav manage it? [18:12:13 CET] <ubitux> do they have subtitles decoders? [18:12:18 CET] <Daemon404> i thought so, maybe not [18:12:32 CET] <Daemon404> yes [18:12:33 CET] <ubitux> they have a few where it doesn't really matter probably [18:12:44 CET] <ubitux> does it still work for them? [18:12:51 CET] <Daemon404> i assume so [18:13:16 CET] <ubitux> they have fate tests? [18:13:30 CET] <Daemon404> i'd need to check [18:13:55 CET] <Daemon404> so if im understanding corectly, subtitles are using codec->time_base as a way to access the stream timebase? [18:13:56 CET] <ubitux> if there is no rescaling in lavc/utils then i highly doubt it works [18:14:03 CET] <ubitux> yes [18:14:23 CET] <ubitux> because the timing into the decoded subtitles need to be rescaled [18:14:38 CET] <Daemon404> right... [18:14:39 CET] <ubitux> contrary to AVFrame.pts/duration [18:14:47 CET] <Daemon404> this seems like it should not be lavc's job... but where we are [18:14:49 CET] Action: Daemon404 thinks [18:15:13 CET] <ubitux> i can start working on the new api to decode into AVFrame if you want [18:15:19 CET] <ubitux> but i don't want this to block codecpar [18:15:33 CET] <ubitux> so we can keep that time base copy temporarly [18:15:43 CET] <ubitux> and we'll be able to drop it when the decoded subtitles holder is sane [18:16:10 CET] <Daemon404> one option is to pass as packet side data [18:16:13 CET] <Daemon404> but thats pretty derp too [18:17:34 CET] <Daemon404> michaelni, ping, i need some help with a commit you made [18:20:58 CET] <JEEB> michaelni: I think the language code thing might break FATE as well if it's hash-based, since it adds a value to the manifest XML [18:21:43 CET] <JEEB> although I'm not sure if the ISMV test writes the XML manifest [18:21:56 CET] <Daemon404> nevcairiel, you too ping. [18:25:53 CET] Action: Daemon404 stabs confusing chnages made inside merge commits [18:26:04 CET] <ubitux> Daemon404: so basically in libav, i'd say (by looking at the code) that AVSubtitle.pts is simply... not set. [18:26:15 CET] <ubitux> except maybe sometimes copied from avpkt but not rescaled [18:26:39 CET] <ubitux> and wrt to start/stop display time, the few decoders they have just hardcode the time bases [18:27:18 CET] <Daemon404> i see [18:30:34 CET] <ubitux> anyway, i'm starting to work on the new avsubtitles holder for now [18:30:54 CET] <ubitux> if you want to fix the sub in codecpar, you will have to keep a codec timebase around [18:31:03 CET] <ubitux> with deprecation flags around if you want but still.. [18:31:46 CET] <Daemon404> ill see what wm4 and nevcairiel say [18:48:39 CET] <Daemon404> i see whats causing a bunch of these lavfi failures for audio [18:49:02 CET] <nevcairiel> probably nut [18:49:06 CET] <Daemon404> nope. [18:49:10 CET] <Daemon404> has_codec_parameters [18:49:17 CET] <Daemon404> it's checking a bunch of fields in internal->avctx [18:49:45 CET] <nevcairiel> isnt that what it should check after decoding [18:50:05 CET] <Daemon404> for adpcm_swf in flv, it's saying it has no sample_Rate [18:50:50 CET] <Daemon404> [adpcm_swf @ 0x2bb9760] Invalid number of channels [18:50:50 CET] <Daemon404> [flv @ 0x2bb8240] Could not find codec parameters for stream 0 (Audio: adpcm_swf, 0 channels): unspecified sample rate [18:50:53 CET] <Daemon404> Consider increasing the value for the 'analyzeduration' and 'probesize' options [18:51:02 CET] <Daemon404> not present pre-codecpar [18:51:20 CET] <nevcairiel> swf demux may just be broken [18:51:38 CET] <Daemon404> ah [18:51:41 CET] <nevcairiel> or flv or whichever [18:52:12 CET] <Daemon404> [voc @ 0x27c5620] Could not find codec parameters for stream 0 (Audio: pcm_u8, 0 channels): unspecified sample rate [18:52:15 CET] <Daemon404> Consider increasing the value for the 'analyzeduration' and 'probesize' options [18:52:18 CET] <Daemon404> same for voc [18:52:26 CET] <nevcairiel> i think thats vocs fault [18:52:38 CET] <nevcairiel> there was something libav changed in there [18:52:42 CET] <nevcairiel> probably flv as well [18:52:50 CET] <Daemon404> ? [18:52:51 CET] <Daemon404> it's .voc [18:53:10 CET] <nevcairiel> something like only creating streams when all info is known, instead of blindly creating them and filling in info later [18:54:17 CET] <nevcairiel> the problem is that "filling in later" then fills that into codecpar, but find_stream_info checks internal avctx and doesnt sync changes from codecpar again (afaik) [18:54:36 CET] <nevcairiel> at least thats what i remember [18:54:41 CET] <nevcairiel> anyway bbl [18:54:46 CET] <Daemon404> i cant wrap my head around how to fix it [18:55:00 CET] <nevcairiel> <nevcairiel> something like only creating streams when all info is known, instead of blindly creating them and filling in info later [18:55:01 CET] <nevcairiel> :) [18:55:06 CET] <nevcairiel> delaying AVStream creation [18:55:13 CET] <nevcairiel> and setting the noheader flag [18:55:26 CET] Action: Daemon404 is not qualified to this probably [18:56:17 CET] <nevcairiel> like I said yesterday, libav had various random patches for months that prepared for this api change by correcting demux behavior and whatnot [18:56:41 CET] <nevcairiel> one shouldnt presume to get this done anytime soon [18:56:47 CET] <Daemon404> heh [18:57:21 CET] <Daemon404> well i'd rather make smll advances [18:57:26 CET] <Daemon404> than let it sit untouched for a week [18:57:28 CET] <Daemon404> like we just have [18:57:39 CET] Action: Daemon404 doesnt want a huge merge backlog [18:57:58 CET] <nevcairiel> considering incremental is not really possible, that cant be helped much [18:58:57 CET] <Daemon404> heh [18:59:20 CET] <Daemon404> what do you suggest then [18:59:24 CET] <Daemon404> (also how long did tep1 take?) [18:59:38 CET] <nevcairiel> honestly tep1 was simpler in comparison [18:59:53 CET] <nevcairiel> much less random behavior changes [19:01:08 CET] <Daemon404> sure... [19:01:20 CET] <Daemon404> but it seems everyone kinda just... stopped [19:02:07 CET] <ubitux> tep1 was done in a a week [19:04:48 CET] <Daemon404> quite frankly im out of my depth here [19:04:58 CET] <Daemon404> :/ [19:09:49 CET] <kurosu> what is the big benefit of this codecpar stuff ? [19:10:31 CET] <Daemon404> kurosu, it's cleanup. everythign we have run into was never right to begin with. [19:10:46 CET] <Daemon404> afaict [19:11:12 CET] <Daemon404> ffmpeg just happens to have significantly more sketchy hacks. [19:20:09 CET] <michaelni> Daemon404, pong, what commit of mine ? what question ? [19:24:24 CET] <michaelni> JEEB, IIRC only 3/3 failed fate, also if theres something easy testable we dont test, more fate tests would be very welcome (by me at least) [19:24:55 CET] <JEEB> ok, so the ISMV test doesn't write the XML manifest [19:25:19 CET] <JEEB> -movflags isml enables that [19:26:38 CET] <Daemon404> michaelni, why can we not use r_frame_rate in ff_compute_frame_duration if there is a parser context present [19:26:46 CET] <Daemon404> i tried to git blame, but it dates back to some merge [19:29:51 CET] <cone-095> ffmpeg 03Clément BSsch 07master:35ba5c424bbe: lavf/dv: do not check for c->sys [19:29:52 CET] <cone-095> ffmpeg 03Clément BSsch 07master:6c0cf11f38f3: lavf/dv: reindent after previous commit [19:29:53 CET] <cone-095> ffmpeg 03Clément BSsch 07master:8284a4ba11e2: lavf/dv: use c->sys->frame_size in dv_frame_offset() [19:33:31 CET] <michaelni> r_frame_rate is a guess, based on timestamps at the file start or set by the demuxer if it has some definite knowledge. If a parser is available it can extract exact frame durations in for example the mpeg1/2 cases. with telecine stuff durations can change midstream, this would be reflected in the parser set repeat_pict but r_frame_rate would stay the same for the lifetime of the stream [19:35:40 CET] <Daemon404> why is avg_frame_rate never attempted to be used? [19:35:50 CET] <Daemon404> but stuff like time_base and codec->framerate is [19:36:06 CET] <Daemon404> sometimes avg is set, but r_ is not and vice versa [19:38:27 CET] <michaelni> iam not 100% sure but i think the problem with avg is that it can result in too large frame durations so that suddenly when a new timestamp comes in it could be in the past which can be problematic. so i _think_ underestimating duration is better. Btw when is r_frame_rate ot set but avg set ? [19:39:07 CET] <Daemon404> michaelni, im working on the codecpar merge, and e.g. rawdec no longer can set the codec timebase [19:39:18 CET] <Daemon404> so it can set r_frame_rate, which wont get used for h264 elementary streams [19:39:23 CET] <Daemon404> because there is a parser open [19:39:30 CET] <Daemon404> and avg_frame_rate will be ignore [19:39:32 CET] <Daemon404> d [19:39:55 CET] <Daemon404> the result of allowing people to set the framerate for "raw" elementary streams... [19:41:32 CET] <JEEB> I don't even remember if that works correctly nowadays [19:41:57 CET] <JEEB> I usually do an initial import into ISOBMFF by L-SMASH's muxer, and then remux with ffmpeg if required [19:44:17 CET] <Daemon404> hmm [19:45:22 CET] <Daemon404> nevcairiel, well i found out why movenc is derpy... oh lord. [19:45:30 CET] <JEEB> > movenc [19:45:41 CET] <nevcairiel> i think wm4 ported movenv, he already said its probably fubar [19:45:46 CET] <nevcairiel> movenc* [19:45:50 CET] <Daemon404> the problem is not in movenc [19:45:59 CET] <Daemon404> it's in mux.c [19:46:30 CET] <Daemon404> movenc calls mov hinting calls rtp_chain calls rtp's write_header which fails in init_pts, which doesnt exist in ffmpeg but we kept for ... reasons? [19:46:40 CET] <Daemon404> which multiplies stream num by codec den [19:46:56 CET] <Daemon404> and i tried fixing that, but now i get some differences on SOME muxes stts atoms. [19:47:13 CET] <Daemon404> it's a lovecraftian horror show [19:48:56 CET] <Daemon404> packet info all matches though [19:50:06 CET] <Daemon404> aha... found it i think [19:50:10 CET] <Daemon404> fiel atom is not being written. [19:53:28 CET] <Daemon404> got it... mayeb mov is fixed now [19:55:55 CET] <Daemon404> or not. [19:59:13 CET] Action: Daemon404 stops for the dya [20:25:42 CET] <Daemon404> nevcairiel, wm4, ubitux, etc - let me know if you have a plan on how to proceed. [20:25:59 CET] <Daemon404> short of flailing randomly for weeks. [20:26:22 CET] <nevcairiel> make fate pass, review all changes [20:26:42 CET] <Daemon404> like 90% of fate failure is the same 2-3 problems [20:26:50 CET] <Daemon404> one of which, at least, is way over my head [20:26:56 CET] <Daemon404> i made some headway - not much. [20:28:37 CET] <Daemon404> we could try to work on a few bits a day each, but that doesnt seem to be how it has gone [20:29:14 CET] <nevcairiel> i got tired of talking to myself about the open questions of the issues, so i just did some more productive work =p [20:30:11 CET] <Daemon404> well im around now that im no longer projectile vomiting. [20:30:20 CET] <Daemon404> wm4 is omnipresent (except for today) [20:32:22 CET] <Daemon404> do you want to start hackign at it again this week with me? [20:32:36 CET] <nevcairiel> not really, pretty busy and going to my parents over easter [20:33:09 CET] <Daemon404> eh ok [20:33:20 CET] <Daemon404> (so am i, hence free time) [20:33:52 CET] <Daemon404> when's a good time to pick it up again then [20:33:56 CET] <Daemon404> and i will make myself available. [20:34:23 CET] <cone-095> ffmpeg 03Marton Balint 07master:48a96383faa0: tests/gapless: add gapless aac tests [20:34:24 CET] <cone-095> ffmpeg 03Marton Balint 07master:25f707694cd3: avformat/utils: increase detected start_time with skip_samples [20:34:25 CET] <cone-095> ffmpeg 03Marton Balint 07master:65efcaeb8467: avformat/mov: read start_pad from edit list start time if codec is aac [20:39:16 CET] <michaelni> ive posted a patch that adds a test for the -framerate option. if someone wants something to test changes to related code [20:47:24 CET] <wm4> Daemon404: I'm trying to avoid doing stuff on weekends [20:49:17 CET] <Daemon404> tahts fine [20:49:30 CET] <Daemon404> poke me during the week then [21:00:36 CET] <Daemon404> ohhhh make fate-lavf-mov passes [21:00:38 CET] <Daemon404> \o/ [21:01:16 CET] <JEEB> 'grats [21:06:17 CET] <nevcairiel> Daemon404: AVCodecContext *mux_enc = ost->st->codecpar; [21:06:39 CET] <nevcairiel> also, dont change ffmpeg.c yet, it needs to work with the old api using new libavformat [21:08:13 CET] <Daemon404> ill revert it [21:08:23 CET] <Daemon404> almost all the mov failures now are missing fiel atom [21:08:47 CET] <Daemon404> which is because field_order isnt being passed correctly [21:08:49 CET] <Daemon404> afaict [21:10:10 CET] <Daemon404> ive been updating the etherpad as i go. [21:10:32 CET] <nevcairiel> field_order doesnt map to some avctx field? [21:10:50 CET] <Daemon404> yes.... field_order [21:11:04 CET] <Daemon404> maybe it's not being copied somewhere [21:11:20 CET] <cone-095> ffmpeg 03Paul B Mahol 07master:8f66a2da3809: avfilter/vf_vectorscope: always flip output vertically [21:11:50 CET] <Daemon404> 1/g 53 [21:31:25 CET] <J_Darnley> That's a little verbose [22:06:46 CET] <yashpatel> michaelni: I'm working on the qualification task of 'FFv1 P frame support' which was to improve compression ration of existing algorithm. I've one problem in understanding the current thing. As we vary GOP from command line, why is it affecting the compression ration, isn't the current implementation is only for I-frames which make GOP=1 by default. [22:07:27 CET] <yashpatel> michaelni: The results I'm getting in experiments by varying the GOP are very slightly different, there isn't much difference in the values [22:21:46 CET] <Loriker> Has anyone attended the "Chemnitzer Linuxtage" in Germany? [22:32:35 CET] <Daemon404> ohhh i think i fixed nut [22:32:53 CET] <BBB_> and the whole world rejoiced [22:34:44 CET] <Daemon404> things i hate: ff_put_v [22:35:21 CET] <nevcairiel> vlc codes arent that special [22:35:42 CET] <Daemon404> nevcairiel, it makes tracking what is written a pita [22:35:51 CET] <Daemon404> i ended up having to use Beyond Compare to compare output files [22:35:54 CET] <Daemon404> due to changed sizes [22:37:12 CET] <Daemon404> daemon404@bbvm:~/dev/f/codecpar$ make fate-lavf-nut [22:37:12 CET] <Daemon404> TEST lavf-nut [22:37:12 CET] <Daemon404> daemon404@bbvm:~/dev/f/codecpar$ [22:37:13 CET] <Daemon404> \o/ [22:37:25 CET] <nevcairiel> do all the lavfi things pass now? [22:37:52 CET] <Daemon404> all the ones i tested just now do [22:38:11 CET] <Daemon404> ffprone only has oen diff now [22:38:12 CET] <Daemon404> - "codec_time_base": "1/51200", [22:38:12 CET] <Daemon404> + "codec_time_base": "0/1", [22:41:08 CET] <Daemon404> just some one with avdevice fails afaict [22:50:31 CET] <Daemon404> yep they all pass now. pad updated. [23:06:08 CET] <michaelni> yashpatel, non key I frames can reuse the range coder / vlc coder statistics so larger GOP compresses better [00:00:00 CET] --- Mon Mar 21 2016

1 0

ffmpeg.log.20160320
by burek 21 Mar '16

21 Mar '16

[00:50:42 CET] <ShalokShalom> hi there [00:51:10 CET] <ShalokShalom> is it correct, that chrome break the law, since they ship the browser with ffmpeg on board? [00:51:30 CET] <J_Darnley> I donn't think so. [00:52:02 CET] <J_Darnley> What particular section of the law were you thinking? [00:52:48 CET] <ShalokShalom> LPGL ? [00:52:58 CET] <J_Darnley> Copyright then. [00:54:09 CET] <J_Darnley> As long as they let you change you change the libraries and provide the exact source they used then they don't have to release their own source [00:54:48 CET] <ShalokShalom> thanks [00:55:17 CET] <iive> it's lesser or library gpl [00:55:28 CET] <ShalokShalom> ok :) [00:56:20 CET] <ShalokShalom> http://en.swpat.org/wiki/GPLv2_and_patents#Prohibition_on_royalties:_sectio… [00:56:54 CET] <iive> it talks about court there, afair [00:58:43 CET] <furq> do you think this irc channel has better lawyers than google [00:59:07 CET] <J_Darnley> I would surprised if it has any. [01:01:44 CET] <furq> besides, it's well known that google is based in luxembourg, where there are no software patents [01:01:51 CET] <furq> or corporation tax [01:02:00 CET] <furq> but mostly they're there for the nice scenery [02:15:55 CET] <Hello71> [23:51:10] < ShalokShalom> is it correct, that chrome break the law, since they ship the browser with ffmpeg on board? [02:16:29 CET] <Hello71> ... never mind. [05:10:16 CET] <geusebio> I've been banging my head on a wall all day, and ffmpeg argument strings are making my head hurt. can I borrow one of you nice folk to help me work out why this is failing? http://pastebin.com/Q7xpUzYz Its a ffmpeg consuming a video stream from a security camera I'm attempting to push to a ffserver instance [05:15:01 CET] <furq> geusebio: does it give a better error message if you run it with -v debug [05:16:14 CET] <geusebio> furq: thanks for asking: http://pastebin.com/6BqFVS8R [05:19:30 CET] <furq> i don't see anything obviously wrong but then i've never encoded mpeg-1 [05:19:55 CET] <furq> [mpeg1video @ 0xfef2e0] MPEG1/2 does not support 3/1 fps [05:20:04 CET] <furq> that looks like it's being overridden but maybe that's causing some issue with ffserver [05:20:45 CET] <furq> it's not particularly hard to cause issues with ffserver [05:25:06 CET] <geusebio> Changed it to 10. same story. changed it to 24 and it went away... now to see if its actually streaming anything.. [05:25:55 CET] <geusebio> sweet jesus it works [05:26:03 CET] <geusebio> its literally the smallest image in the world, but it works [05:28:23 CET] <relaxed> geusebio: mpeg1video only supports certain framerates. you can see the supported ones with "ffmpeg -h encoder=mpeg1video | less" [05:30:39 CET] <relaxed> or use -strict experimental for a non-standard framerate [05:33:45 CET] <geusebio> Mm, it was just to try and get it going - Whats recommended for streaming a video, say, security camera video [05:34:45 CET] <relaxed> I would copy the video stream [05:37:00 CET] <geusebio> I couldn't get that working. [05:38:20 CET] <Prelude2004c> hey guys.. godo evening [05:38:47 CET] <Prelude2004c> i have a problem maybe someone can asist me with .. http://pastebin.com/DT0zwcfj [05:39:00 CET] <Prelude2004c> options are : NVENC_OPTS="-preset hq -numB 1 -goplength 250 -rcmode 32 -qp 23" [05:39:35 CET] <Prelude2004c> so all works well on the output with vlc if i leave the encoding source as 59fps .. but if i set it to 30fps , it plays for hte first few seconds and then vlc starts to freeze and loose video frames and starts to cut out and die [05:39:39 CET] <Prelude2004c> not sure why.. does not make any sense [05:41:04 CET] <furq> geusebio: https://github.com/arut/nginx-rtmp-module [05:41:11 CET] <furq> that should be able to directly restream the input video [05:41:18 CET] <furq> you'll need to transcode the audio to aac [05:41:54 CET] <furq> https://gist.github.com/fur-q/d7028f51c38f7d0bb56e [05:41:58 CET] <furq> that's pretty much the config i use [05:42:33 CET] <relaxed> Prelude2004c: is there a reason you're not using ffmpeg with nvenc support? [05:42:42 CET] <geusebio> I don't really want to run another projects stuff - I've got other tasks for this system to perform [05:42:51 CET] <Prelude2004c> yes was having some major issues with it [05:42:51 CET] <geusebio> when all i really need is the config :P [05:42:55 CET] <furq> i would advise against using ffserver really [05:43:05 CET] <geusebio> What would you suggest? [05:43:05 CET] <furq> it's never been particularly reliable and it's pretty much abandoned now [05:43:08 CET] <Prelude2004c> could not decode the video and audio.. stream issues.. NvTranscoder doesn't complain about i [05:43:13 CET] <furq> i would suggest the thing i just suggested [05:43:40 CET] <relaxed> geusebio: yes, avoid ffserver [05:43:59 CET] <geusebio> :/ [05:44:24 CET] <relaxed> FFmpeg should have purged it long ago [05:44:32 CET] <geusebio> So how do I even use that? [05:44:46 CET] <geusebio> download nginx source, add a module, compile it? [05:44:54 CET] <furq> pretty much [05:45:02 CET] <geusebio> :| [05:45:03 CET] <furq> there's a sample ./configure string at the bottom of the gist i linked [05:45:50 CET] <geusebio> Nobody has a docker container that does this knocking about do they? [05:48:41 CET] <geusebio> Does anyone have a tutorial or something I can follow for getting this going/ [05:49:10 CET] <furq> that gist should have everything you need to set up nginx [05:49:50 CET] <furq> you can ignore the auth.lua bits if you don't need authentication [05:49:57 CET] <furq> then: ffmpeg -i rtsp://rtspurl -c:v copy -c:a aac rtmp://rtmpurl/live/streamname [05:50:28 CET] <Prelude2004c> can anyoen help ? [05:51:16 CET] <relaxed> Prelude2004c: we might be able to help with ffmpeg's nvenc issues [05:52:11 CET] <Prelude2004c> ya i know but i have issues with that thing :( .. and its working well ( as long as i keep the 60fps ) .. with video .. why would me setting -fps 30 start encoding ok.. but after a few seconds the video starts to get choppy and messed up and audio starts to cut out [05:52:16 CET] <Prelude2004c> any suggestion there.. am i missing something ? [05:53:06 CET] Action: geusebio sits and watches a docker container download build-essential, dies a bit on the inside. [05:54:16 CET] <relaxed> no idea, we don't support NvTranscoder here [05:55:20 CET] <ParkerR> Anybody know of a way to stream from the HD PVR directly to twitch? I've tried this but it stalls after about ten seconds. http://ix.io/tZA [05:55:20 CET] <ParkerR> /dev/video0 is a straight H.264 and AAC stream [05:56:06 CET] <relaxed> ParkerR: did you see https://trac.ffmpeg.org/wiki/StreamingGuide ? [05:56:18 CET] <ParkerR> Yeah that's what I started with [06:02:08 CET] <relaxed> ParkerR: try encoding the stream with -vcodec libx264 -tune zerolatency [06:04:55 CET] <ParkerR> ffmpeg -y -f mpegts -i /dev/video0 -c:v libx264 -tune zerolatency -ar 44100 -f flv "rtmp://live.twitch.tv/app/live_blah" still stalls [06:07:35 CET] <geusebio> furq: I cloned nginx, there is no configure in the root of it >>> [06:08:14 CET] <furq> i guess you need to run autogen.sh or autoreconf then [06:08:26 CET] <furq> it's pretty standard for configure to only be generated for releases [06:10:41 CET] <geusebio> This is why I was askin' for a tutorial :p [06:15:33 CET] <relaxed> ParkerR: try copying the stream again with -re before the input [06:18:21 CET] <ParkerR> ffmpeg -y -re -f mpegts -i /dev/video0 -c:v libx264 -tune zerolatency -ar 44100 -f flv "rtmp://live.twitch.tv/app/live_blah" [06:18:27 CET] <ParkerR> [mpegts @ 0x561556475d40] Could not detect TS packet size, defaulting to non-FEC/DVHS [06:18:37 CET] <ParkerR> /dev/video0: could not find codec parameters [06:19:59 CET] <ParkerR> Power cycled the HD PVR and it acted like it was working but just quit out [06:20:19 CET] <ParkerR> With "rtmp://live.twitch.tv/app/live_blah: Input/output error [06:20:19 CET] <ParkerR> " [06:20:34 CET] <relaxed> -c:v copy [06:21:23 CET] <geusebio> ok, to hell with this for tonight. I wasn't expecting to have to crazy things like compile nginx tonight. Night! Cheers for the help though! [06:24:31 CET] <ParkerR> Stops for about 10 seconds right after listing the stream properties, device lights up, but then ends in that input/output error [06:25:21 CET] <furq> can you save the input to a file [06:25:33 CET] <furq> and/or can you stream a file to that twitch url [06:25:45 CET] <furq> or something like -f lavfi -i smptebars [06:31:48 CET] <[mbm]> ParkerR: have you tried running wireshark to see if the remote end is somehow killing the connection? [06:32:05 CET] <ParkerR> [mbm], Umm [06:32:07 CET] <ParkerR> No [06:32:12 CET] <ParkerR> And hey [07:15:53 CET] <satinder___> hi how we can draw text on video [07:16:01 CET] <satinder___> please any one help me [08:11:36 CET] <mrec> hi, is anyone familiar with the RTP protocol? how about the client suddenly disappears is there any mechanism available to stop flooding the network with UDP data? [08:12:03 CET] <mrec> I had a look at some servers, and they keep sending the videodata until they will receive a proper shutdown request [08:14:58 CET] <TD-Linux> mrec, yes, RTCP [08:19:49 CET] <mrec> I will have a closer look at that, so seems like the server which I had a look at doesn't fully support the RTP protocol [11:42:37 CET] <bencc1> is there a tool to overlay text in a video that *moves* with the camera? [11:43:14 CET] <bencc1> for example, if there is a bus, place an ad on the side of the bus that looks real [11:59:39 CET] <andrey_utkin> mrec, another option would be to restrict support of RTSP transports to TCP only. Thus you have RTSP signaling and RTP data interleaved in single TCP conn. When it breaks, you're done. [12:00:22 CET] <andrey_utkin> mrec, RTCP data may be "safely ignored" and things "still work", this may be the case with your server :) [13:04:01 CET] <bencc1> how can I drawtext for only seconds 5-10 in the video? [13:04:03 CET] <bencc1> ffmpeg -i in.mp4 -vf drawtext="text='my test':fontsize=50:fontcolor=white:x=100:y=100:n=250" -strict -2 out.mp4 [13:05:48 CET] <J_Darnley> I think there's an enabled option which takes an expression [13:06:35 CET] <J_Darnley> Use something like: gt(t,5)*lt(t,10) [13:06:56 CET] <DHE> Using the "moving text" method, you could set 'y' to a formula that evaluates to 100 for the desired window and something way off screen otherwise [13:07:26 CET] <bencc1> J_Darnley: thanks. trying [13:07:57 CET] <bencc1> DHE: by "moving text" do you mean that the x and y will be an expression of the time t? [13:08:06 CET] <DHE> yes [13:08:48 CET] <DHE> I skimmed the docs and didn't see an 'enabled' variable. but I've done scrolling text in the past, so my method (with J_Darnley's equation as a starting point) should work [13:09:35 CET] <bencc1> this works: drawtext="enable='between(t,0,10) [13:10:27 CET] <J_Darnley> http://ffmpeg.org/ffmpeg-filters.html#Timeline-editing [13:11:09 CET] <J_Darnley> Oh, there's a between now [13:11:22 CET] <bencc1> nice [13:11:44 CET] <DHE> interesting that timeline note... [13:18:30 CET] <bencc1> can I replace green pixels with a box of text? [13:21:25 CET] <DrSlony> Hello, which audio codec is recommended for general mp3 player support?? [13:21:55 CET] <DHE> ummm... MP3? [13:21:58 CET] <relaxed> libmp3lame [13:22:07 CET] <DrSlony> thanks relaxed [13:22:10 CET] <J_Darnley> There is only one option [13:23:05 CET] <DHE> while I'd love to say something like Vorbis or AAC, you can't be sure they're supported on older devices (ie. before android phones) [13:25:12 CET] <DrSlony> i actually decided to go with vorbis because i know rockbox supports it [13:25:39 CET] <DrSlony> its amazing how many broken mp3s there are floating about [15:31:23 CET] <andrey_utkin> how could I write wav file with RIFF header, instead of RIFF2k, with ffmpeg? [15:33:19 CET] <andrey_utkin> speech synthesis software refuses to work with wav file ffmpeg creates by default [15:34:03 CET] <andrey_utkin> because it expects "data" tag, and instead there's LIST [15:40:18 CET] <bencc1> how can I use fontcolor_expr to fade-in text? [15:40:27 CET] <bencc1> I'm displaying text with drawtext [15:41:27 CET] <bencc1> or maybe use alpha with an expression [15:42:13 CET] <andrey_utkin> bencc1, 1 sec [15:44:37 CET] <J_Darnley> http://ffmpeg.org/ffmpeg-filters.html#drawtext-1 [15:44:46 CET] <J_Darnley> the alpha option [15:45:40 CET] <bencc1> J_Darnley: can I use it to create fade-in and fade-out? [15:46:01 CET] <bencc1> from frame 10 to 20 increase the alpha from 0 to 1 [15:46:10 CET] <J_Darnley> "Draw the text applying alpha blending" [15:46:17 CET] <bencc1> from frames 50 to 60 decrease the alpha from 1 to 0 [15:46:19 CET] <J_Darnley> or does alpha mean nothing to you? [15:46:35 CET] <andrey_utkin> i was doing it kinda so fontcolor_expr=ffffff%{eif\\: max(0\, min(255\, 255*(1*between(t\, 10\, 20) + ((t)/10)*between(t\, 0\, 10) + (-(t - 20))/10)*between(t\, 20\, 100) ) )) \\: x \\: 2 } [15:46:40 CET] <andrey_utkin> bencc1, --^ [15:47:31 CET] <bencc1> andrey_utkin: what max and min do? [15:47:47 CET] <andrey_utkin> clamp the value between 0 and 255 [15:48:27 CET] <andrey_utkin> i think now you can use alpha parameter without concatenating that with color code [15:48:48 CET] <andrey_utkin> maybe at the time i invented this formula, there was no evaluatable alpha parameter [15:49:08 CET] <bencc1> why do you need between three times? [15:49:50 CET] <J_Darnley> Ramp up, constant, ramp down? [15:51:00 CET] <andrey_utkin> bencc1, not really needing between in all three [15:51:19 CET] <bencc1> andrey_utkin: how can the expression be simplified? [15:52:24 CET] <andrey_utkin> bencc1, leave color code in fontcolor, move expression to "alpha", dropping multiplication by 255 and "%{eif:" stuff [15:52:58 CET] <andrey_utkin> further it is ok although you can improve it of course [15:53:04 CET] <bencc1> andrey_utkin: I still need: ramp up, constant, ramp down [15:53:16 CET] <bencc1> so don't I need the {eif? [15:53:40 CET] <bencc1> J_Darnley: very useful. thanks. trying to simplify it [15:55:01 CET] <andrey_utkin> Reposting my Q: How could I write wav file with RIFF header, instead of RIFF2k, with ffmpeg? [15:55:44 CET] <J_Darnley> no idea other than "edit the source" [15:56:31 CET] <bencc1> J_Darnley: what this part does? \\: x \\: 2 [15:56:43 CET] <J_Darnley> NFI [15:56:53 CET] <andrey_utkin> bencc1, part of eif command [15:56:54 CET] <andrey_utkin> drop it [15:57:03 CET] <bencc1> ok [16:00:03 CET] <wodim> hello, how do I seek faster? I'm using -ss/-to and it takes ages. [16:01:10 CET] <J_Darnley> Let me guess, you are telling the encoder to wait rather than instructing the decoder to seek. [16:01:39 CET] <wodim> well I don't know [16:01:47 CET] <wodim> ffmpeg -i file -ss xx -to xx file [16:01:49 CET] <wodim> what's wrong [16:01:59 CET] <J_Darnley> exactly what I thought [16:02:29 CET] <J_Darnley> read the second line of the help [16:02:49 CET] <wodim> I can't use it before -i [16:02:49 CET] <J_Darnley> ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}... [16:03:05 CET] <wodim> not -ss but -to [16:03:18 CET] <wodim> I mean, -ss can be used before -i but -to can't [16:04:00 CET] <wodim> am I supposed to use -t instead and having to calculate the length by hand? [16:04:18 CET] <wodim> s/and// [16:08:29 CET] <wodim> well better than having to wait 5 minutes it is [16:15:24 CET] <bencc1> I'm trying this: [16:15:28 CET] <bencc1> -vf drawtext="enable='between(n,0,5):alpha=n*0.2:text='test':fontsize=110:fontcolor=white:x=100:y=100" [16:15:45 CET] <bencc1> but the alpha changes instantly, instead of gradually [16:18:01 CET] <andrey_utkin> bencc1, too fast fadein? [16:18:13 CET] <andrey_utkin> what about using t instead of n also [16:18:16 CET] <J_Darnley> And what does the help say about the range of alpha? [16:18:44 CET] <bencc1> J_Darnley: "Draw the text applying alpha blending. The value can be either a number between 0.0 and 1.0 The expression accepts the same variables x, y do. The default value is 1. Please see fontcolor_expr " [16:18:57 CET] <J_Darnley> Yes. 5 frames isn't a very long time [16:19:08 CET] <bencc1> andrey_utkin: tried more frames. still instant. I'll try t [16:19:46 CET] Action: J_Darnley wonders whether he has a built with drawtext [16:20:46 CET] <J_Darnley> oh yes, zerano's [16:22:25 CET] <J_Darnley> what the shit is this? [16:22:41 CET] <J_Darnley> Fontconfig error: Cannot load default config file [16:22:41 CET] <J_Darnley> [Parsed_drawtext_0 @ 0000000002895f20] impossible to init fontconfig [16:42:56 CET] <Duality> hi [16:43:01 CET] <Duality> can i force a speed? [16:43:21 CET] <J_Darnley> Speed of what exactly? [16:43:24 CET] <Duality> like force a constant speed, i am running ffmpeg and pipe the images into my program [16:44:29 CET] <J_Darnley> Why? The writing should block and wait if you program is too slow [16:44:49 CET] <J_Darnley> And similar for reading if ffmpeg is too slow. [16:44:55 CET] <Duality> well when i run the pipe it shows me this: frame= 20 fps=8.2 q=-0.0 Lsize= 270kB time=00:00:20.00 bitrate= 110.6kbits/s dup=0 drop=542 speed=8.17x [16:45:00 CET] <Duality> and it runs way to fast [16:45:24 CET] <J_Darnley> Then stop telling ffmpeg to drop frames! [16:45:43 CET] <Duality> how ? [16:45:55 CET] <J_Darnley> Stop giving it an -r option [16:46:27 CET] <Duality> ha [16:46:45 CET] <DHE> or maybe you want to put the -r option somewhere else, like on the input rather than the output? [16:47:03 CET] <Duality> i had used the -r to fix something else, namely that the speed keeps dropping over the lenght of the video [16:47:43 CET] <Duality> length* [16:47:47 CET] <J_Darnley> -r tell ffmpeg to change the framerate of the output video [16:47:57 CET] <J_Darnley> it has nothing to do with encoding speed. [16:48:31 CET] <DHE> ffmpeg keeps the video consistent such that the same image is shown at, say, the 1 minute interval regardless of framerate. it duplicates or drops frames to meet that requirement [16:48:54 CET] <J_Darnley> How about we stop groping around in the dark like blind people trying to fuck and you post your exact command line. [16:49:48 CET] <Duality> my command is this: ffmpeg -i /home/robert/Videos/bad.mkv -vf "scale=96:48" -f image2pipe -pix_fmt rgb24 -vcodec rawvideo - [16:50:01 CET] <DHE> use pastebin, and include the output [16:50:07 CET] <DHE> (see the topic) [16:50:11 CET] <Duality> ah [16:50:13 CET] <Duality> sorry :) [16:51:29 CET] <Duality> http://pastebin.com/KuupQMxp [16:53:16 CET] <J_Darnley> That is surprisingly slow [16:53:53 CET] <Duality> yes [16:53:56 CET] <Duality> :) [16:54:01 CET] <Duality> I am wondering why [16:54:29 CET] <DHE> easily explained by the program accepting the stdout reading the data slowly... [17:09:09 CET] <Duality> it written in python does allot of things though, so uh yea maybe i'll have to rewrite it in c/c++ :) [17:10:45 CET] <J_Darnley> Before rewriting the whole thing, benchmark, profile, and see where the problem is. [17:34:20 CET] <Duality> good idea will do :) [17:47:07 CET] <bencc1> can I change the angle when using drawtext? [17:47:19 CET] <bencc1> so the text will have a little tilt? [17:48:00 CET] <J_Darnley> At this point you should be using ass so you can do full 3d effects [17:48:22 CET] <J_Darnley> And no, I don't think you can [17:48:37 CET] <bencc1> what is ass? [17:48:54 CET] <J_Darnley> The glorious subtitle format. [17:49:02 CET] <bencc1> so it's better to draw the text with imagemagick to an image and than place it on the video? [17:49:22 CET] <J_Darnley> I guess that depends on what you really want to do. [17:49:33 CET] <bencc1> ass will work? [17:52:33 CET] <J_Darnley> Since fansubbers use it to produce infinitely varied styles of karaoke and infinitely varied sign translation I'm sure it can render text with a little tilt. [17:53:37 CET] <J_Darnley> It does require learning new things so if you know how to do what you want with imagemagick then stick with that. [17:54:10 CET] <bencc1> this is the only docs about ass? https://ffmpeg.org/ffmpeg-filters.html#subtitles-1 [17:54:28 CET] <J_Darnley> About the ffmpeg subtitle filter, yes [17:54:39 CET] <kepstin> bencc1: if you're doing ass stuff, it would be best to use aegisub to do the text layout etc. [17:54:40 CET] <J_Darnley> If you want an editor: http://www.aegisub.org/ [17:54:45 CET] <kepstin> it has visual layout editor [17:54:54 CET] <bencc1> I need it in a script [17:55:15 CET] <J_Darnley> And an ass file is a plaintext file you can edit with a script [17:55:53 CET] <kepstin> the aegisub website has docs of the commands you can use for layout in the ass script [17:56:07 CET] <bencc1> I'll look at it. thanks [17:57:53 CET] <bencc1> ffmpeg can take ass script and render it into the video? [17:59:50 CET] <kepstin> bencc1: yes, with the subtitles or ass filters [18:00:09 CET] <bencc1> nice [18:00:22 CET] <bencc1> I'll try to create a simple example with tilted text to see if it works [18:33:36 CET] <bencc1> J_Darnley: aegisub is cool. now trying to burn the subtitle [18:34:47 CET] <JEEB> aegisub is the least retarded open source subtitle editor [18:34:51 CET] <JEEB> I like it <3 [18:36:28 CET] <bencc1> :) [18:47:39 CET] <andrey_utkin> bencc1, still there with your issue? [18:55:22 CET] <bencc1> andrey_utkin: yes [18:55:39 CET] <bencc1> I'm able to use aegisub to fade-in and fade-out text [18:55:45 CET] <bencc1> now I'm trying to animate the position [18:55:47 CET] <andrey_utkin> could you share full minimized example of what you're trying? [18:55:55 CET] <andrey_utkin> preferrably with -f lavfi -i testsrc [18:56:00 CET] <andrey_utkin> so that i can try it instantly [18:56:17 CET] <bencc1> I'm not sure it's possible with ffmpeg without ass [18:56:28 CET] <bencc1> I'm trying to drawtext with several effects [18:56:36 CET] <bencc1> fade-in, fade-out (possible) [18:56:43 CET] <bencc1> movement (possible) [18:56:51 CET] <bencc1> rotation (not possible?) [18:56:52 CET] <andrey_utkin> ass should be irrelevant [18:57:08 CET] <bencc1> can you rotate text with drawtext? [18:57:41 CET] <andrey_utkin> rotation... maybe if you rotate the background picture with dedicated filter, drawtext, then rotate it back :) [18:58:01 CET] <c_14> I'm 99% sure you can rotate ass [18:58:09 CET] <bencc1> ass you can [18:58:14 CET] <bencc1> but drawtext filter in ffmpeg? [18:58:27 CET] <andrey_utkin> c_14, you mean ass or ass? :) [18:59:06 CET] <andrey_utkin> bencc1, not 100% sure, i'd check the doc section of drawtext [18:59:31 CET] <c_14> I don't think you can rotate drawtext [19:07:24 CET] <geusebio> wtf, you're all talking about ass [19:07:42 CET] <geusebio> and being able to rotate ass. [19:10:44 CET] <furq> how do i throw that ass in a circle [19:12:10 CET] <bencc1> geusebio: ass is a format for subtitles [19:13:06 CET] <furq> also i'm pretty sure andrey_utkin already made the same joke [20:28:39 CET] <geusebio> furq: I just wasn't expecting ass everywhere. [20:28:50 CET] <geusebio> Also, trying to compile nginx ala last nights discussion [20:28:53 CET] <geusebio> ./configure: error: no modules/rtmp/config was found [21:34:48 CET] <courrier__> Hey guys, I shot a video using a video gain of 25db, on the camcorder it looked great but now I'm viewing the files on a HD screen, the image is somehow "pixelated", any idea of a filter that could rectify this? [21:36:01 CET] <J_Darnley> I understand all of those words but cannot get unstanding from this particular order. [21:36:14 CET] <J_Darnley> Perhaps you can give us a screen shot. [21:36:31 CET] <BtbN> what is a 25db video gain? oO [21:39:08 CET] <J_Darnley> Now that I see "video" there I guess it means a little over 16x brightness gain [21:40:27 CET] <courrier__> Here's a capture: http://www.cjoint.com/data3/FCuuNTCU4JG_Capture.jpeg [21:40:45 CET] <courrier__> Look at the sofa (top left), this is really ugly [21:41:06 CET] <J_Darnley> Right [21:41:14 CET] <J_Darnley> Camera sensor noise [21:41:30 CET] <courrier__> Not sure exactly what's this video gain, this is the "gain" key of the Sony NEX VG10 [21:42:31 CET] <J_Darnley> A denoiser would blur it out but obviously make it blurrier [21:43:03 CET] <J_Darnley> you can try hqdn3d [21:47:06 CET] <courrier__> J_Darnley: mmmmh OK [21:47:16 CET] <courrier__> any clue about the parameters? [21:47:20 CET] <courrier__> just tweaking? [21:47:36 CET] <J_Darnley> start with none [21:48:44 CET] <c_14> And obviously test on part of your capture first (using -ss and/or -t) to see if you like it before trying it on the whole captur. [21:48:46 CET] <c_14> +e [21:53:39 CET] <courrier__> c_14: thanks for the good advice I'll see how hqdn3d and -ss work :) [22:04:31 CET] <courrier__> Yes, that seems better with the filter [22:32:52 CET] <lx2> Hello 2all. I'm looking for someone with nvenc_h264 usage experience. Looking at the ffmpeg -h full output I see that there's some kind of the 2 pass encoding support there but I can't figure out the correct sequence to use it. With x264 we've got working -pass option that generates log file on the 1st pass and updates it on subsequent passes. [22:32:53 CET] <lx2> But for nvenc it seems that using -pass does nothing: log file ends up 0 bytes in size and the encoding results produced on 1st and sebsequent passes are byte-to-byte the same. What am I doing wrong? Thanks in advance for clarification. [22:33:51 CET] <c_14> nvenc's "2-pass" mode is internal to the hardware encoder [22:34:20 CET] <c_14> It only actually runs 1 pass of the whole file [22:34:23 CET] <lx2> Ough, so it's "fake" 2 pass and has nothing to do with full blown two pass encoding scheme? [22:34:28 CET] <c_14> yes [22:34:38 CET] <lx2> Are there any benefits in using it? [22:34:47 CET] <BtbN> It makes encoding slower but it looks a bit better [22:35:01 CET] <BtbN> Nobody knows what it actualy does internaly. [22:35:22 CET] <J_Darnley> Black box encoders, aren't they great? [22:37:10 CET] <J_Darnley> I wonder how much it buffers since it obviously isn't the whole video. [22:39:18 CET] <BtbN> it does not add any noticable latency, just reduces the maximum fps [22:39:31 CET] <lx2> Thanks a lot for your help. Surprisingly enough I wasn't able to find this info online on ffmpeg forums or in the mailing list archives. Had even tried to look into the source code but video encoding stuff is far from my area of expertise so I failed miserably. From my testings for 720p I see next to none encoding speed difference with 2pass enabled vs disabled. Testing on Win7 x64 with latest nVIDIA drivers, latest ffmpeg compiled from git head and GeForce G [22:40:08 CET] <BtbN> With ffmpeg you run into limits way before the actual nvenc encoder is capped [22:40:21 CET] <BtbN> for 720p it easily encodes 800~1300 FPS [22:40:32 CET] <lx2> Most probably that's the case. [22:40:47 CET] <BtbN> Copying around the frames to/from GPU is was too slow to reach that limit [22:40:51 CET] <BtbN> *way [22:48:15 CET] <lx2> In my case source stream is also H.264 720p and one of the bottlenecks was the decoding speed. Tried different variants with "-f null - -benchmark" and fastest ones were single-threaded dxva2 or multiple threaded default CPU decoder with 2x overcommit ratio vs. CPU cores. I've got AMD FX-8350 on encoding workstation with it's 8 "fake" cores, specifying 16 threads resulted in ~810 FPS decoding speed. [22:48:47 CET] <lx2> dxva2 with single thread ended up around ~500 fps. [22:49:31 CET] <lx2> No hwaccel + default threads setting (i.e. no threads specified) - ~760 FPS. [22:51:53 CET] <lx2> Multithreaded dxva2 seems to perform the same speed as software decoding but requires way lower number of threads: even 2 threads gives around 780 FPS. But there's a sound warning about using hwaccel with multiple threads so I hadn't tried to use it to encode anything large yet. [22:53:05 CET] <JEEB> multithreaded hwaccel in general is a bad idea [22:53:42 CET] <JEEB> and it really shouldn't bring you any speed-up, honestly. wouldn't be surprised if that benchmark didn't work properly in that case [22:54:27 CET] <JEEB> the only reason why some people used or use multithreading with hwaccels is because they are too lazy to recreate the decoder in case the hwaccel fails [22:54:42 CET] <JEEB> (because it will fall back to software decoding with that many threads) [22:56:27 CET] <lx2> Yep, I also have concerns about thread safety vs. dxva and doubt that it is possible to properly support multiple threads accessing the same dxva context and the same hardware at the same time. And I don't see a reason why should CPU multithreading result in faster performance in case we've got other dedicated hardware to do actual decoding. [23:04:50 CET] <BtbN> because the dedicated hardware is designed for real time decoding of media [23:04:59 CET] <BtbN> anything beyond that is a pure bonus [23:05:36 CET] <BtbN> So modern hw decoders are designed in a way that allows them to barely reach 60 FPS for 4K. [23:10:18 CET] <lx2> Exactly. I've seen tests of the hardware decoders comparing Intel vs nVIDIA vs AMD and it looks like Intel's solution is fastest among them. On the other hand it is possible to achieve several orders higher decoding rates on some special hardware. My everyday work is an HPC *nix engineer and recently I've seen benchmarking of the native ffmpeg build for the Intel's Xeon Phi (a.k.a. knc - Knight's Corner). It does wonders as long as you are able to feed it wit [23:12:05 CET] <lx2> Infiniband FDR + lustre + proper cluster storage solution definitely helps but unfortunately it is not something I'd expect to see people using at their homes :-). [00:00:00 CET] --- Mon Mar 21 2016

1 0

ffmpeg-devel.log.20160319
by burek 20 Mar '16

20 Mar '16

[01:43:52 CET] <Shiz> wm4: you can [01:43:55 CET] <Shiz> but not with the demo version [01:43:57 CET] <Shiz> lol [02:18:32 CET] <J_Darnley> Anyone else geting a PM from someone wanting to write a matroska to mp4 multiplexer? [02:44:44 CET] <rcombs> J_Darnley: you mean ffmpeg.c? :P [02:45:02 CET] <J_Darnley> I told him that [02:45:38 CET] <J_Darnley> Instead he went off to read the Matroska and ISOBMFF specs [02:45:47 CET] <rcombs> glhf [02:46:06 CET] <rcombs> can you have NIH syndrome as an individual? [02:46:12 CET] <J_Darnley> Yes! [02:46:29 CET] <J_Darnley> But is usually a symptom of ignorance [02:46:54 CET] <J_Darnley> "I have no idea what libraries exist so I will write my own" [03:59:40 CET] <cone-809> ffmpeg 03Benjamin Steffes 07master:be482e516525: Fix detelecine filter for patterns containing 1 [03:59:40 CET] <cone-809> ffmpeg 03Benjamin Steffes 07master:c411e90bc3f1: Fix start_frame handling in detelecine filter [12:41:04 CET] <cone-376> ffmpeg 03Mark Thompson 07master:fbec157ea08f: lavc/hevc: Allow arbitrary garbage in bytestream as long as at least one NAL unit is found. [12:41:04 CET] <cone-376> ffmpeg 03Michael Niedermayer 07master:48bda6c5f78c: avfilter/vf_detelecine: Remove redundant declaration [13:25:35 CET] <atomnuker> 4.54s vs 4.58s [13:26:10 CET] <atomnuker> why do I get the feeling he did a single run before and after and by chance the latter was .04 seconds faster [13:27:53 CET] <JEEB> lol [13:28:18 CET] <JEEB> with such differences it always comes down to properly calculating the improvements [13:29:26 CET] <kierank> should just be a simd function anyway [13:30:04 CET] <kierank> perhaps even autovectorised [13:32:15 CET] <kierank> atomnuker: do you want to try simding that function [13:32:21 CET] <kierank> it's a nice one to learn from actually [13:34:47 CET] <kierank> 5 instructions i think in total [13:35:02 CET] <kierank> load, abs, copy, sqrt, sqrt, divide, store [13:35:04 CET] <kierank> ok 7 [13:35:29 CET] <kierank> oh a multiply, 8 [13:37:30 CET] <atomnuker> inline asm? [13:39:03 CET] <kierank> Of course not [13:39:06 CET] <kierank> Yasm [16:22:35 CET] <cone-807> ffmpeg 03Michael Niedermayer 07master:068026b0f784: avcodec/mjpegenc_common: Store approximate aspect if exact cannot be stored [18:39:41 CET] <JEEB> ooh-kay... was surprised I had actually set up git send-email on my laptop [18:40:00 CET] <JEEB> mostly because I didn't remember ever copying my .gitconfig :) [18:57:45 CET] <cone-807> ffmpeg 03Michael Niedermayer 07master:efa98cdc2ff1: avformat/file: Add crypto to default whitelist [19:59:50 CET] <J_Darnley> Ampersand is a special character. [20:04:13 CET] <ubitux> nevcairiel, Daemon404 ; can't we merge a compatible commit and update our demuxer/muxers progressively? [20:04:43 CET] <ubitux> we're really accumulating a lag in commits [20:05:28 CET] <nevcairiel> then fix the merge if you care =p [20:05:52 CET] <nevcairiel> and no, that would end up in a even bigger mess then it already is going to be [20:06:44 CET] <ubitux> i'll have 2 or 3 hours to kill tomorrow, can you be more specific about how i can help? [20:06:57 CET] <nevcairiel> make fate pass [20:07:30 CET] <ubitux> is anyone working on something specific? [20:07:48 CET] <nevcairiel> figure out why a test fails, see whats different, make it output the same stuff as before [20:07:57 CET] <nevcairiel> if not possible, make sure to clearly document why output changed [20:08:12 CET] <nevcairiel> i doubt anyone has been working on anything [20:08:25 CET] <nevcairiel> i gave up bothering after not even getting responses from people anymore [20:15:48 CET] <BBB> nevcairiel: I think at some point we just stop caring [20:15:55 CET] <BBB> why is libav changing stuff for no good reason? [20:15:57 CET] <BBB> it just adds work [20:16:04 CET] <BBB> they should work on our tree, or we should stop merging [20:16:13 CET] <BBB> us doubling down on their work-for-the-sake-of-work is stupid [20:16:23 CET] <BBB> its a waste of manpower and nobody cares [20:16:27 CET] <BBB> </troll> [20:16:36 CET] <nevcairiel> some people seem to like some of the api changes [20:16:47 CET] <nevcairiel> i nominate them to merge them cleanly =p [20:16:53 CET] <BBB> then maybe they should do the merging, or they should convince the libav people to work on our tree [20:17:05 CET] <BBB> it makes no sense that ny on of us spends time on stuff we dont want [20:17:11 CET] <BBB> that sounds like a terrible job [20:17:18 CET] <nevcairiel> the thing is, libav went through weeks/months of preparation patches for this api change, changing a few demuxers etc to behave more sanely [20:17:20 CET] <nevcairiel> we dont have that [20:17:26 CET] <nevcairiel> and people try to shoehorn that into this merge [20:18:16 CET] <nevcairiel> those that care can finish it, and if they ask i might help, but i'm certainly not going to drive it all the way myself [20:18:48 CET] <BBB> gotta go, bbl [20:19:40 CET] <bencoh> this whole thing is just getting silly (more than ever) ... [20:30:49 CET] <Daemon404> some people sure do a lot of complaining about something they dont even participate in [20:32:49 CET] <Daemon404> fyi: ive been sick as balls the last week [20:32:53 CET] <Daemon404> hence not around [20:34:45 CET] <jamrial> the codecpar commit on libav's side of things had quite a few fate ref files altered, so it's not unexpected if the same thing happens with some of our own de/muxers [20:35:17 CET] <jamrial> i think most of the time the differences were pts/dts values [20:35:19 CET] <Daemon404> is it just fixing up fate + out demuxers now [20:35:20 CET] <Daemon404> our* [20:35:51 CET] <nevcairiel> probably not [20:36:04 CET] <Daemon404> and tbh i think this merge is worth it [20:36:11 CET] <Daemon404> everything that "broke" so far was shady as fuck [20:36:30 CET] <jamrial> ffprobe fate tests are going to be a pita to analize, what with the long lines full of key:value stuff [20:36:43 CET] <Daemon404> theyll all change in the same way jamrial [20:36:49 CET] <Daemon404> diffing the json output is easier [20:36:51 CET] <nevcairiel> just diff the more readable format [20:36:54 CET] <jamrial> true [20:39:50 CET] <Daemon404> i wanted to work on it this week, but >projectile vomiting [20:40:12 CET] <Daemon404> and some guy keeps emailing me about why encrypted hls is not working or smth, and why havent i fixed it [20:40:30 CET] <nevcairiel> i fixed it [20:40:51 CET] <Daemon404> i saw stuff for the options, but did that include encryption? [20:42:09 CET] <nevcairiel> yes [20:42:15 CET] <Daemon404> ok [20:42:47 CET] <Daemon404> ubitux, i will poke codecpar tomorrow as well [20:42:52 CET] <Daemon404> maybe we can finish it out [20:42:55 CET] <Daemon404> or make some headway. [20:44:08 CET] <nevcairiel> there is some things to decide, like what to do with has_b_frames, i find it a rather handy property to get after find_stream_info to make decoding smoother after [20:45:55 CET] <nevcairiel> most other failures are mov and nut related [20:46:37 CET] <nevcairiel> and some demuxers are not ported at all, primarily those needing external libraries [20:48:05 CET] <Daemon404> nut is likely nto a big deal [20:48:10 CET] <Daemon404> mov sounds lulzy [20:48:52 CET] <Daemon404> what is has_b_frames used for besides delay (which is all sorts of screwed up) [20:50:36 CET] <nevcairiel> knowing it either avoids dropping frames from the beginning of the stream or reduces decoding delay, both of which are equally useful to me [20:51:10 CET] <Daemon404> not sure i follow how it can outright eliminate delat [20:51:12 CET] <Daemon404> delay [20:51:25 CET] <nevcairiel> i didnt say eliminate, i said reduce =p [20:51:36 CET] <Daemon404> same diff [20:51:37 CET] <nevcairiel> it only uses as much delay as it has to, not the maximum [20:52:04 CET] <Daemon404> i mean... i feel like this should belong in, you know, ->delay [20:54:56 CET] <wm4> does anything video even use ->delay [20:54:59 CET] <Daemon404> nevcairiel, does libav codecpar simply entirely ignore the concept of codc delay [20:55:05 CET] <nevcairiel> Daemon404: yes [20:55:10 CET] <Daemon404> oh good [20:55:20 CET] <Daemon404> wm4, it works sometimes, except when it doesnt, when you need has_b_frames [20:55:22 CET] <nevcairiel> which imho was not the right decision, but what do i care what libav does [20:55:24 CET] <Daemon404> except when that doesnt. [20:55:34 CET] <Daemon404> nevcairiel, no i definitely need to know delay [20:55:39 CET] <nevcairiel> i registered my complaints with them [20:55:39 CET] <Daemon404> for frame accurate seeking [20:55:43 CET] <nevcairiel> they ignored [20:55:45 CET] <nevcairiel> so shrug [20:55:51 CET] <Daemon404> i registered that multiple times with elenril [20:56:03 CET] <Daemon404> maybe we can add some delay field to codecpar? [20:56:10 CET] <Daemon404> makes more sense than bframes [20:56:50 CET] <nevcairiel> naming and documentation can be whatever it wants, as long as it carries the has_b_frames info from demux to decode ;) [20:57:21 CET] <Daemon404> Plorkyeran, you may need to read this ^ [20:57:25 CET] <Daemon404> ffms2 uses this info. [20:58:06 CET] <Daemon404> ubitux, tomorrow: me. you. one codecpar. [20:58:37 CET] <ubitux> 20:58 <@Daemon404> ubitux, tomorrow: me. you. one. [20:58:39 CET] <ubitux> wowowow [20:58:49 CET] <Daemon404> >context [20:59:28 CET] <wm4> but isn't has_b_frames determination in lavf quite unclean too? [20:59:43 CET] <Daemon404> im sure it's all sorts of nuuty [20:59:45 CET] <Daemon404> nutty [21:00:13 CET] <nevcairiel> its not that bad, it just has a heuristic to guess how many frames it should decode to determine this value [21:00:55 CET] <nevcairiel> which is also then used for dts/pts generation in raw streams, i think [21:01:10 CET] <jamrial> Daemon404: isn't initial_padding the equivalent of avctx->delay? [21:01:21 CET] <nevcairiel> but thats an audio-only field in codecpar [21:01:34 CET] <jamrial> ah [21:01:36 CET] <nevcairiel> (and a different meaning to the pts/dts delay he wants) [21:01:50 CET] <Daemon404> nevcairiel, so it's pre-roll? [21:02:21 CET] <wm4> it decodes frames to determine delay? [21:02:46 CET] <nevcairiel> it could probably do the same by just parsing them, but it has to determine the re-ordering [21:03:02 CET] <nevcairiel> and our parsers just arent that smart [21:03:10 CET] <Daemon404> im not very concerned if it decodes or parsers [21:03:23 CET] <Daemon404> realistically, we are not going to ever get away from needing to decode in lavf. [21:06:32 CET] <wm4> good thing that "realistic" actually means "pessimistic" [21:09:48 CET] <Daemon404> not really [21:09:51 CET] <Daemon404> i dont think i'd want to remove it [21:09:58 CET] <Daemon404> it's simply not feasible [21:29:58 CET] <cone-807> ffmpeg 03Paul B Mahol 07master:c91b20c464b6: avfilter/vf_waveform: add subsampling input support for remaining filters [21:40:33 CET] <Compn> arent we going to merge all the libs anyway? [21:40:37 CET] <Compn> :D [21:41:48 CET] <Compn> lavc + lavf + lavu = VOLTRON [21:46:17 CET] <cbsrobot> ubitux: ping [21:46:28 CET] <ubitux> cbsrobot: pong [21:46:45 CET] <cbsrobot> shoud I send you the subtitle file on your mail ? [21:47:05 CET] <ubitux> sure, if you want [21:47:46 CET] <Daemon404> kinky [21:48:56 CET] <ubitux> ;) [21:49:08 CET] <cone-807> ffmpeg 03Paul B Mahol 07master:959c7dad88b6: avfilter/vf_waveform: add graticule to aflat filter [21:53:53 CET] <cbsrobot> ubitux: sent [21:54:24 CET] <ubitux> the explanation is simple [21:54:34 CET] <ubitux> tag is not closed, so it's not considered a tag [21:54:58 CET] <ubitux> it should be improved though [21:55:24 CET] <cbsrobot> I thought text shoud get rid of all the formatting [21:55:41 CET] <ubitux> yes, as long as it considered it not text [21:55:48 CET] <cbsrobot> or is there another way to get rid of all the formatting ? [21:56:01 CET] <ubitux> but since the tag is not closed, it's probably not a tag, so it's text (that's the logic here probably) [21:56:15 CET] <cbsrobot> ah [21:56:21 CET] <ubitux> it works if you close the tag, right? [21:56:54 CET] <cbsrobot> well in the ass file there is no <font> tag [21:57:02 CET] <cbsrobot> so not sure where I shoud close it [21:57:17 CET] <ubitux> wait wait [21:57:38 CET] <ubitux> my bad then, that's not the bug [21:58:35 CET] <cbsrobot> I thought it might be a bug becuase there are two styles in the ass file [22:00:17 CET] <ubitux> forget what i said [22:00:20 CET] <ubitux> i'll have a look [22:02:37 CET] <cbsrobot> thanks [22:59:50 CET] <cone-807> ffmpeg 03Michael Niedermayer 07master:92dfeb5c3100: avformat/wtvdec: Set AVFMTCTX_NOHEADER [22:59:51 CET] <cone-807> ffmpeg 03Michael Niedermayer 07master:0ffa9e6ebae3: avformat/utils: Do not wait for more than 1 frame on attachments [00:00:00 CET] --- Sun Mar 20 2016

1 0

ffmpeg.log.20160319
by burek 20 Mar '16

20 Mar '16

[01:08:36 CET] <petecout_> metadata question for you folks. FFMPEG can encode metadata into mpegts segments. Has anyone ever been able to make the metadata dynamic for every segment? I can load it from a file but thats on launch and can't be updated. [01:13:08 CET] <petecout_> Or if someone could help explain this line better: By default, global metadata is copied from the first input file, per-stream and per-chapter metadata is copied along with streams/chapters. These default mappings are disabled by creating any mapping of the relevant type. A negative file index can be used to create a dummy mapping that just disables automatic copying. [01:14:13 CET] <J_Darnley> The last part: -map_metadata -1 disables copying all metadata [01:14:21 CET] <c_14> I know of no way to make the metadata dynamic over segments other than maybe hacking into the segment/hls muxers [01:14:21 CET] <J_Darnley> The rest... [01:14:26 CET] <petecout_> More like the per-stream and per-chapter [01:14:57 CET] <petecout_> c_14: Thank you, that was also something I assumed was the route to go. It would be a custom job. Or I would have to edit the segments after ffmpeg generates them. [01:15:23 CET] <J_Darnley> Metadata can be attached to a whole file or any smaller part of one file right down to every frame [01:15:35 CET] <petecout_> My input is a live rtp stream though. [01:15:45 CET] <petecout_> I was hoping that I could us the data / application channel [01:15:53 CET] <petecout_> and send metadata that way [01:15:58 CET] <petecout_> and have it encoded on the per frame [01:16:15 CET] <J_Darnley> If ffmpeg doesn't understand that you need a decoder for the data stream [01:16:45 CET] <J_Darnley> I don't think ffmpeg has any data stream decoders [01:16:56 CET] <petecout_> Well I was thinking if I formated the metadata to match what ffmpeg needs. [01:17:04 CET] <petecout_> Lol well that line above says it does [01:17:09 CET] <petecout_> map_metadata [01:17:17 CET] <petecout_> is how you either map to a static file or a dynamic stream [01:17:58 CET] <petecout_> but it doesn't look like you can encode per frame. [01:38:37 CET] <petecout_> J_Darnley: Do you have any good links on attaching metadata to a whole file? [01:39:09 CET] <J_Darnley> Yes: the -metadata option [01:39:16 CET] <J_Darnley> otherwise please be more specific [01:40:20 CET] <petecout_> Oh nm [01:40:33 CET] <petecout_> J_Darnley: I thought you knew like via bytearray [01:40:50 CET] <J_Darnley> If you're using the API please say that. [01:42:07 CET] <petecout_> I'm not. I wanted to do it via editing the file itself [01:43:02 CET] <J_Darnley> What? Like a hex editor? Then you had better read about how the file format (mpeg TS is it) stores metdata. [01:43:13 CET] <petecout_> yup [01:43:19 CET] <petecout_> Hoped you had a link [01:43:23 CET] <J_Darnley> No [01:43:25 CET] <petecout_> Thank you anyhow though [01:43:31 CET] <J_Darnley> Every format stores it differently [01:44:14 CET] <J_Darnley> What I used for writing the flac muxer metadata support was https://xiph.org/flac/format.html [01:44:25 CET] <petecout_> Also when you refer to api do you mean like something for java? I've only ever used the cli [01:44:54 CET] <J_Darnley> Yes, the Application Programming Interface [01:45:08 CET] <petecout_> Cheers! [01:45:58 CET] <furq> speaking of audio metadata, did you ever get around to adding xing tags [01:46:06 CET] <J_Darnley> Ha, no. [01:46:08 CET] <J_Darnley> Sorry [01:48:26 CET] <furq> damn [01:48:42 CET] <furq> well then i guess i'll have to write a script three months ago [01:48:51 CET] <J_Darnley> :) [01:50:30 CET] <furq> is there any reason to use twolame over ffmpeg's native mp2 encoder [01:50:46 CET] <J_Darnley> No idea [01:50:55 CET] <furq> twolame is giving me a bunch of linker errors and i'm wondering whether or not i should care [01:50:59 CET] <furq> i suspect not [01:51:25 CET] <J_Darnley> I might be inclined to think that it would give better quality [01:51:37 CET] <J_Darnley> but then it is only mp2 [01:51:51 CET] <furq> same deal with libwavpack i guess [01:58:49 CET] <petecout_> Eureka!!! J_Darnley, I realized instead of writing a file parser and dealing with adding the id3 tags manually. I can just use ffmpeg to add the metadata after the file has been created! Doesn't give me per frame data but meh. I can deal with that. Thanks agian for your help. [01:59:23 CET] <petecout_> Dunno why I didn't think of that before. Sorta a box within a box. [01:59:25 CET] <J_Darnley> You're welcome and sorry it seems to have taken you so long to get what you wanted [01:59:53 CET] <J_Darnley> or atleast close to what you wanted [02:00:26 CET] <petecout_> Lol no this is fine. Figuring out how to get ffmpeg to encode a video and audio stream from a rtp server which was transcoding from webrtc was hard enough. This was pretty easy. [03:21:19 CET] <mrmenacex> ok i'm having a hard time with drawtext can someone look at this for me ? http://pastebin.com/AVQyM3qZ [03:23:33 CET] <J_Darnley> Glorious escaping hell [03:23:58 CET] <J_Darnley> Try escaping the colon on the fontfile filename [03:30:20 CET] <mrmenacex> J_Darnley , lol excaping hell yes that's where i am haha [03:31:15 CET] <mrmenacex> J_Darnley, escaping the colon after C didn't work [03:31:32 CET] <mrmenacex> it doesn't get rid of that colon though i can see the path in the error and it looks right ? [03:33:10 CET] <J_Darnley> meh [03:33:16 CET] <J_Darnley> I don't know then [03:37:55 CET] <mrmenacex> J_Darnley, is that error usually from the font file not loading? [03:39:12 CET] <mrmenacex> oh wow i just moved the font file to the folder i'm encoding in and it worked [03:39:25 CET] <mrmenacex> so it's definitely the path [05:56:57 CET] <apaul> Can someone help me how to write video frames to v4l2 device node like /dev/video0 . [05:57:10 CET] <apaul> any idea.... [10:33:40 CET] <satinder___> Hi any one here which have experience on v4l2 devices I mean /dev/video0......nth devices [10:34:30 CET] <satinder___> I have problem when open /dev/video0 with ffmpeg decoding-encoding example [10:49:24 CET] <satinder___> fflogger : no sir I am not talking about ffmpeg commandline tool , I asking about ffmpeg api function . which function can open raw video format I mean /dev/video0 node [10:49:25 CET] <satinder___> ?? [10:49:52 CET] <relaxed> satinder___: fflogger is a bot, I thought you had an ffmpeg question. [10:50:32 CET] <satinder___> relaxed : ohh sorry ! I don't now [10:51:09 CET] <satinder___> I asking about ffmpeg api , I want open my /dev/video0 node and recieve raw frames [10:52:02 CET] <satinder___> Is there any example for that because which example is given in ffmpeg /ffmpeg/doc/examples/decoding_encoding.c that is not working [10:52:10 CET] <satinder___> can you help me please [10:52:17 CET] <satinder___> thanks in advance !! [13:35:03 CET] <sea`> Does ffserver support 'copy' for the VideoCodec option? [13:39:01 CET] <JEEB> sea`: if you are thinking of using ffserver for something, don't [13:39:06 CET] <JEEB> unless you know the code [14:16:03 CET] <hannes3> hey, i am trying to get with gribs on ffserver. streaming a webcam through it worked fine but now i want to add a -filter_complex. [14:16:27 CET] <hannes3> it looks like doing so adds an additional stream and i cannot figure out how to get rid of it. ffserver tells me "Feed '/tmp/webcam1.ffm' stream number does not match registered feed" [14:16:42 CET] <JEEB> hannes3: how do you guys end up looking into ffserver? [14:17:04 CET] <JEEB> basically if you want to use it, be ready to maintain it [14:17:04 CET] <Smilex> Hey. Is there a way to open audio only files with the C API? avformat_open_input fails unless it's a video file [14:17:14 CET] <hannes3> googling through pages upon pages of people pasting crude raspberry pi "tutorials" that are incomplete and full of mistakes [14:17:16 CET] <hannes3> ah poop [14:17:28 CET] <hannes3> well, i also ended up in the ffmpeg wiki ;) [14:17:50 CET] <JEEB> Smilex: there's even an example for that I think? although I *think* it should work similar to video files as long as you have the needed formats enabled [14:18:43 CET] <Smilex> JEEB: I've been using multiple examples. However the reading function fails to read audio only files [14:18:44 CET] <JEEB> hannes3: it's basically just kept compiling for now, and the next time an API bump happens it will just break and get removed [14:19:03 CET] <hannes3> JEEB: ouch! what is the recommended alternative? [14:19:12 CET] <Smilex> JEEB: Do you know about a function that takes audio data and returns the codec? [14:19:26 CET] <JEEB> hannes3: any proper streaming server [14:19:41 CET] <hannes3> got a recommendation for raspberry? [14:19:56 CET] <JEEB> there's icecast, nginx-rtmp (which seems to have NIH'd DASH/HLS output) or just a normal web server if you can have the segments on disk [14:20:41 CET] <JEEB> hannes3: basically ffmpeg itself can push things out in various ways and many streaming servers support taking that in and serving it [14:21:25 CET] <JEEB> Smilex: I usually just use avformat_open_input, avformat_find_stream_info and then if I'm lazy I use av_find_best_stream [14:21:32 CET] <hannes3> all i am looking for is getting the images from a usb webcam at the raspi to a decent pc in the network with low latency (well, anything <1s) [14:22:12 CET] <Smilex> JEEB: Have you tried that on a .mp3 file? [14:22:37 CET] <JEEB> no, but I'd be surprised if it didn't work since that's pretty much how ffmpeg.c does it [14:23:12 CET] <Smilex> JEEB: Any chance you could try? [14:23:20 CET] <Smilex> I've tried it with a .mp3 and a .flac [14:24:07 CET] <JEEB> I could try later, but I'd be surprised if it would fail since that's pretty much the most standard stuff around... [14:24:24 CET] <Smilex> I probably should try a stable release then [14:25:01 CET] <JEEB> master should work just fine as long as FATE looks green for your arch [14:25:09 CET] <JEEB> http://fatebeta.ffmpeg.org/ [14:26:44 CET] <Smilex> Well I'm getting a very clear error "Invalid data found when processing input", from files I've tested with VLC and clementine [14:27:19 CET] <JEEB> how does `ffmpeg -i file` look like? [14:27:29 CET] <JEEB> and how much customization did you put into your build? [14:27:43 CET] <Smilex> none [14:28:27 CET] <Smilex> http://paste.ubuntu.com/15424563/ [14:28:52 CET] <JEEB> ok [14:29:07 CET] <JEEB> wonder if the default probing duration is different from what ffmpeg.c's default is [14:30:38 CET] <Smilex> http://paste.ubuntu.com/15424593/ <- how I do it [14:31:56 CET] <JEEB> my thingamajig that I did before https://github.com/jeeb/matroska_thumbnails/blob/master/src/matroska_thumbn… [14:32:04 CET] <JEEB> see av_register_all vs avcodec_register_all [14:32:44 CET] <JEEB> in my case I do custom IO but the general gist is the same :P [14:32:50 CET] <Smilex> JEEB: woo! I got further now, thanks! [14:33:23 CET] <Smilex> [mp3 @ 0x3451b60] Header missing <- that does result in error for me. Should it? [14:36:03 CET] <JEEB> no idea, but your ffmpeg.c log doesn't sound too good either with the garbage skipped etc [15:26:49 CET] <somaReverse> Hello! How can I do a screencast saving to a GIF? [15:29:47 CET] <J_Darnley> ffmpeg -i whatever output.gif [15:36:59 CET] <somaReverse> J_Darnley: Thanks. I'm using a tool called 'teiler' to create area screencast. Here is a profile it needs me to change http://ix.io/tNh. How can I make it produce gif? [15:37:15 CET] <J_Darnley> Read it's manual [15:38:14 CET] <somaReverse> This tool doesn't have a manual :-( [15:38:39 CET] <J_Darnley> Then what use is it? [15:38:56 CET] <J_Darnley> What you have provided shows conflicting options [15:39:06 CET] <J_Darnley> How am I supposed to know which it uses [15:39:38 CET] <J_Darnley> Perhaps delete evrything but the extension and set that to gif [15:40:05 CET] <somaReverse> J_Darnley: Ok, I will try it. [15:47:04 CET] <somaReverse> J_Darnley: It works. But the output file is huge (100 times bigger than mp4). [15:47:33 CET] <J_Darnley> Wow(!) You don't say(!) [15:47:50 CET] <J_Darnley> I had no idea gif was in inefficient fortmat(!) [15:48:31 CET] <J_Darnley> That would be the reason why every rubbish image host now serves up webm or mp4 [15:49:56 CET] <somaReverse> J_Darnley: Ok :) [16:52:33 CET] <ffmpegerrorhog> Do I have to register first? [16:53:10 CET] <J_Darnley> Register what and where? [16:53:22 CET] <ffmpegerrorhog> some irc channels make you register first [16:53:34 CET] <ffmpegerrorhog> thank God I found this [16:53:54 CET] <J_Darnley> Right, I don't know why. [16:55:58 CET] <ffmpegerrorhog> I'm having a horrible time with concat [16:56:38 CET] <ffmpegerrorhog> any rules on how to paste error log in here? [16:56:42 CET] <ffmpegerrorhog> it's really short [16:56:56 CET] <J_Darnley> No. Use a pastnin-like site [16:57:00 CET] <J_Darnley> *bastebin [16:57:05 CET] <J_Darnley> OMFG [16:57:10 CET] <J_Darnley> I think you get it [16:57:33 CET] <ffmpegerrorhog> http://pastebin.com/3v4DwZp0 [16:57:52 CET] <ffmpegerrorhog> I will happily paypal for the solution [16:58:09 CET] <J_Darnley> That error comes from your shell, not ffmpeg. [16:58:22 CET] <ffmpegerrorhog> Ok, that makes sense [16:58:36 CET] <ffmpegerrorhog> but the command is proper [16:58:38 CET] <J_Darnley> Does the for loop print correctly when run by itself [16:58:40 CET] <ffmpegerrorhog> well, I think it is [16:58:44 CET] <J_Darnley> ? [16:59:01 CET] <ffmpegerrorhog> if I paste the ffmpeg code into my command line I get this [17:00:05 CET] <kepstin> ffmpegerrorhog: what shell is that script running with? the <( ... ) thing is a bash extension, it won't work if you're using e.g. /bin/sh on a debian-based distro [17:00:09 CET] <ffmpegerrorhog> http://pastebin.com/gTVrubBp [17:00:17 CET] <ffmpegerrorhog> I am using Centos 6.7 [17:01:13 CET] <ffmpegerrorhog> I have #!/bin/bash the first line [17:01:59 CET] <kepstin> but yeah, since that's a syntax error in your shell script, you really need help debugging your script, not your ffmpeg command. [17:02:47 CET] <ffmpegerrorhog> http://pastebin.com/2j2E3WeE [17:02:50 CET] <ffmpegerrorhog> here is the script [17:03:21 CET] <J_Darnley> Wow. [17:03:34 CET] <ffmpegerrorhog> Wow seems like a bad thing :) [17:04:38 CET] <J_Darnley> Okay, maybe not a bad as I first thought] [17:04:46 CET] <ffmpegerrorhog> lol [17:04:49 CET] <J_Darnley> Fade in and out for each image [17:04:54 CET] <ffmpegerrorhog> I accept all criticism! [17:05:03 CET] <ffmpegerrorhog> constructive or not [17:05:40 CET] <ffmpegerrorhog> yes, I had this working on another Centos 6.7 distro [17:05:45 CET] <J_Darnley> In your first loop I would write out the filenames to a temporary file then just use that as the input for the second [17:06:38 CET] <J_Darnley> for ...; ffmpeg ... ; echo "file $f" >> temp.txt; done [17:06:53 CET] <ffmpegerrorhog> okay [17:07:00 CET] <J_Darnley> uh, $f.mpg but that's the idea [17:07:18 CET] <ffmpegerrorhog> but would that kill the original error? [17:07:25 CET] <ffmpegerrorhog> that the bash script is kicking back? [17:07:34 CET] <ffmpegerrorhog> I'm all for optimizing it, don't get me wrong [17:07:49 CET] <J_Darnley> You avoid using the <() syntax [17:07:51 CET] <ffmpegerrorhog> but right now if it ran one time and overheated a server to critical mass I'd be happy [17:08:00 CET] <J_Darnley> Which is what is giving you the problem [17:08:00 CET] <ffmpegerrorhog> (bow) You are a master [17:08:06 CET] <ffmpegerrorhog> I see what you're saying [17:08:11 CET] <ffmpegerrorhog> forgive me, it is noon here [17:08:30 CET] <ffmpegerrorhog> I was up at 5:00 am yesterday and have been working on this project ever since with 3 hours down time [17:08:44 CET] <ffmpegerrorhog> #pepsimax [17:15:22 CET] <ffmpegerrorhog> anyone got experience with text overlays and font manipulation looking for a consulting gig? [17:56:39 CET] <zafu> hi, is there a way to fix a corrupted .3gp file with ffmpeg? When I try to play it I get "moov atom not found" [17:57:51 CET] <JEEB> if it has no index you're pretty much dead [17:58:00 CET] <JEEB> any sort of fixing would have to assume a whole lot of things [17:59:22 CET] <zafu> when I upload it to http://mp4repair.org they give a me an accurate preview of the file's contents, how can they do it? [18:02:53 CET] <JEEB> most probably match it off other files written by similar/same writer [18:03:18 CET] <JEEB> there's no automated way of doing it, you always need to have a reference when recreating something like that [18:03:52 CET] <JEEB> automated as in without any predefined information that is :P [18:04:07 CET] <JEEB> if you can spot files made by X and know how X writes its stuff, it becomes possible [18:11:38 CET] <kepstin> man, poutting codec information and initialization data in the same "atomic" chunk as a variable-length index was such a bad idea in hindsight :/ [18:18:17 CET] <JEEB> kepstin: fragments kind of fix that at least, although that was adopted much much later (by some places) [00:00:00 CET] --- Sun Mar 20 2016

1 0

ffmpeg-devel.log.20160318
by burek 19 Mar '16

19 Mar '16

[01:46:46 CET] <cone-639> ffmpeg 03James Almer 07master:488e6409df24: libwebpenc_animencoder: add missing braces to struct initialization [02:21:11 CET] <unsure> say does anybody know where there is a static version of ffmpeg....the only static windows one i saw does not work on windows in general as it requires special features of vcrt dlls [02:21:48 CET] <unsure> and it is my understanding that those features are only for the latest versions of windows [02:22:25 CET] <unsure> i don't know why people bother with static as it still seems to require certain versions of things [02:22:41 CET] <jamrial> if you can't compile it yourself then grab a binary by zeranoe [02:22:49 CET] <llogan> what version of windows are yoy using? [02:22:54 CET] <llogan> *you [02:23:22 CET] <unsure> jamrial...i think zeranoe was the one i tried .. but i will check again [02:23:53 CET] <unsure> llogan well i tried it on win98 and winxp...but some people seem to be whoring out for only the latest versions of windows [02:24:27 CET] <llogan> 98. xp. why? [02:24:34 CET] <jamrial> nobody cares about win98. nobody should care about win98 [02:24:35 CET] <unsure> llogan...like cheap prostitutes trying to sell trash [02:24:39 CET] <J_Darnley> Since it is a Unicode binary it won't support 98 [02:25:24 CET] <llogan> IIRC there is a recent XP specific build somewhere on Zeranoe. [02:25:35 CET] <unsure> J_Darnley...well i don't see why unicode interpretation can't be added as a supplement for a program to make it work on win98 [02:25:53 CET] <J_Darnley> Why not do that then? [02:26:14 CET] <jamrial> unsure: if you really need winxp support, use one of the stable builds by zeranoe. afaik he's only compiling the snapshots for Vista+ [02:26:16 CET] <unsure> J_Darnley...not me bud...i'm usually fine with ascii... [02:26:18 CET] <jamrial> or just compile ffmpeg yourself [02:26:58 CET] <unsure> jamrial...yes that is what i was trying to say...some people seem to be whoring out for microsoft to support only the latest versions of microsoft [02:27:51 CET] <unsure> jamrial...see most people i know would not touch vista or any microsoft product after win98 or possibly xp if memory leaks was an issue [02:28:31 CET] <jamrial> good for them, i guess [02:29:03 CET] <unsure> jamrial...well it is just an issue of people not trying to keep up with the Jones'es [02:29:23 CET] <llogan> you should use ffmpeg from 2000. [02:29:51 CET] <unsure> jamrial...maybe rich people can afford to use the latest greatest stuff...but poor people can't afford to try to keep up with the Jone's [02:31:29 CET] <unsure> unsure...i personally think all that extra fat of unicode encoding is not really needed to convert or create high definition videos [02:32:29 CET] <J_Darnley> How do I open a file called "01.CnSHf.flac" without unicode? [02:32:33 CET] <unsure> and some people don't think it is economically wise to use an atomic bomb just to kill a mosquito [02:33:00 CET] <unsure> J_Darnley...well use a hex editor to open it [02:33:26 CET] <unsure> J_Darnley...it is just a bunch of one's and zero's anyway [02:33:29 CET] <llogan> i am not a windows user but i think the zeranoe builds for ancient windows when he added --enable-libmfx [02:33:34 CET] <rcombs> J_Darnley: using Shift-JIS :P [02:33:55 CET] <llogan> *stopped working when... [02:34:29 CET] <unsure> J_Darnley...do you know what an on/off switch is? [02:34:51 CET] <J_Darnley> Yes [02:35:06 CET] <J_Darnley> Ultimately if you want an ANSI version them compile one as such. [02:35:22 CET] <J_Darnley> *then [02:35:27 CET] <unsure> J_Darnley...well just look at the one's and zero's and pretend they are about on and off [02:36:25 CET] <unsure> J_Darnley...do you know what TTL logic is.... [02:36:32 CET] <J_Darnley> no [02:36:45 CET] <rcombs> unsure: nobody cares about supporting Win98 and all of 2 people care about supporting XP [02:37:05 CET] <rcombs> (and those people should stop caring about XP) [02:37:16 CET] <unsure> J_Darnley...well transistors are really analog devices..but if you combine two of them in a certain way you can create an electronic on/off switch. [02:37:25 CET] <rcombs> (that XP threading compat hack in w32pthreads does not lead to great things) [02:37:30 CET] <unsure> J_Darnley...then digital begins. [02:37:33 CET] <J_Darnley> oh not time to live then? [02:37:45 CET] <J_Darnley> A good TLA there [02:38:20 CET] <unsure> J_Darnley...no...i asked you if you know what an on/off switch is...do you ever switch on a light bulb or anything [02:39:32 CET] <llogan> this "conversation" is offtopic [02:39:56 CET] <llogan> if you need more help, i suggest posting on zeranoe forum. [02:39:58 CET] <unsure> J_Darnley..then think of a TTL ....as an on/off switch...and consider about 8 of them in parallel [02:40:08 CET] <rcombs> in some channels I would've banned already [02:40:24 CET] <unsure> llogan..well it is not offtopic...he asked how to see a file without unicode support [02:40:40 CET] <unsure> llogan..first he has to know WHAT a file is [02:41:12 CET] <J_Darnley> And you're the one claiming unicode is overkill for i/o [02:41:50 CET] <llogan> this is the IRC channel for FFmpeg development. This is not ##lightswitchesandunicode [02:41:50 CET] <unsure> J_Darnley...i am saying...why use an atomic bomb to kill a lousy mosquito..it is an inefficient waste of scarce resources [02:42:37 CET] <J_Darnley> Then thank god MS gave us an atom bomb when they were incapable of a flyswat! [02:43:13 CET] <unsure> J_Darnley..ok you are getting the idea...economics comes naturally to people when they have to live in the real world [02:45:28 CET] <unsure> J_Darnley...and when resources are scarce...you cannot afford to waste them or invest them unwisely [02:46:21 CET] <rcombs> ah yes, investing all these resources in converting to UTF-16 up in userland (instead of letting the kernel do it) one time per process [02:46:45 CET] <rcombs> how horrid [02:47:08 CET] <rcombs> that'll be a giant slowdown when trying to transcode video [02:47:12 CET] <unsure> J_Darnley...so as a bank of switches....think of a row of Pascal's triangle....so you can see the link between a coin with two sides and an on/off switch. [02:47:53 CET] <unsure> J_Darnley..nobody asks whose face is on a coin...they ask how many sides does it have...does it need more than two? [02:48:13 CET] <rcombs> &people ask how many sides a coin has on a regular basis? [02:48:28 CET] <rcombs> this analogy seems to have gone downhill, and I didn't expect that to be possible [02:48:31 CET] <J_Darnley> And the answer is 3 [02:48:39 CET] <TD-Linux> oh no is this #bitcoin [02:49:19 CET] <unsure> rcombs...it has nothing to do with bitcoin...it is about getting ffmpeg to work on windows that people already paid for...so they never have to pay again [02:50:24 CET] <rcombs> where I come from, we have a saying [02:50:37 CET] <TD-Linux> "install gentoo" [02:50:50 CET] <rcombs> that we apply to people who ask for support for OS versions that the vendor doesn't even support anymore [02:50:53 CET] <unsure> rcombs...well where i come from ...it is corn-bread and chicken [02:51:03 CET] <rcombs> it's very simple, just 2 words [02:51:06 CET] <rcombs> "fuck off" [02:52:18 CET] <unsure> rcombs...well what would you expect a money-grubbing firm to do except to try to keep charging for the same old thing....again and again and again...until people are sick of paying for it so many times...most people already paid a long time ago...and should never have to pay again [02:52:42 CET] <rcombs> alternately take TD-Linux's advice [02:53:44 CET] <unsure> rcombs...and TD...how wise you are..but gentoo is not that easy to install and is a nightmare to upgrade anything with so many blocks of any software upgrade [02:54:09 CET] <rcombs> unsure: you do realize that it takes time and effort to maintain legacy software, right? [02:55:06 CET] <unsure> rcombs...well..we are given some time on this earth..and most people would like to leave something behind after their time is up...so the world knows they once existed [02:56:10 CET] <unsure> rcombs...and most people but not all usually want to create something with QUALITY. [02:57:43 CET] <unsure> rcombs...otherwise in a hundred or so years...no one will ever know you existed....do you know the grave sites and names of the people in the old west who died a hundred years ago? [02:59:29 CET] <J_Darnley> Then we had better do great good or great evil [02:59:38 CET] <unsure> rcombs...i doubt you even know who they were..what their dreams were....what they laughed about...what they cried about..and so on... [02:59:56 CET] <J_Darnley> being too crap to do good I will lean on evil [03:00:51 CET] <unsure> J_Darnley...well do you think you cannot be a Tchaikovsky or a DaVinci...or a Shakespeare or a Homer..or so on [03:01:02 CET] <J_Darnley> Of cpurse not [03:01:07 CET] <J_Darnley> *course [03:01:23 CET] <J_Darnley> I am not creative enough or intelligent enough [03:01:27 CET] <unsure> J_Darnley...why not...why limit yourself for no reason at all? [03:01:57 CET] <unsure> J_Darnley..you don't see Sakaguchi or Uematsu trying to limit themselves. [03:03:16 CET] <unsure> J_Darnley...first of all creativity begins with "I can" not "I am" and if you start with i cannot...you defeat yourself. [03:03:37 CET] <J_Darnley> Sure(!) [03:05:06 CET] <unsure> J_Darnley..if Uematsu had said "I cannot" you would never have heard the harmony in Tifa's theme. [03:06:42 CET] <unsure> J_Darnley...or if the Beatle's had said "I cannot" you would never have realized what a loss the tragedy of John Lennon was. [03:08:14 CET] <unsure> J_Darnley..or if Shakespeare had said "I cannot" you would never have understood the ties between Squall and Rinoa. [03:10:17 CET] <c_14> unsure: if you dislike all this talk of "cannot", why don't you do it yourself? [03:11:00 CET] <unsure> c_14...well i am doing many other things at this time...and i don't have time to do everything [03:11:28 CET] <c_14> And we do? [03:12:00 CET] <unsure> c_14...economics and the presence of scarce resources...dictates that you try to prioritize your activities in some way to avoid wasting your scarce resources. [03:12:05 CET] <cone-639> ffmpeg 03Michael Niedermayer 07master:5694b2821132: avcodec/error_resilience: wait for previous frame to be available [03:12:06 CET] <cone-639> ffmpeg 03Michael Niedermayer 07master:a7b8a6e704d3: avcodec/error_resilience: remove unneeded and disabled code [03:12:54 CET] <unsure> c_14..time is another example of a SCARCE resource. [03:14:23 CET] <unsure> c_14...what if Gallileo had not used his limited time to create a telescope...and instead had wasted it chasing women. [03:15:27 CET] <J_Darnley> Invent telescope or get laid? I know what I'd choose. [03:16:03 CET] <unsure> J_Darnley..well just remember...choices have consequences ...that you might not like with your limited time on this earth. [03:16:31 CET] <j45> get laid, spawn a genius child. child invents telescope. PROFIT! [03:17:13 CET] <unsure> j45....do you consider the warmth and affection of the opposite sexies...to be profitable in some way. [03:17:32 CET] <unsure> sexes [03:18:05 CET] <unsure> j45...what about letting your feet get cold in the wintertime [03:19:35 CET] <unsure> j45..have you been influenced by a James Bond flick on the importance of a good looking woman. [03:21:17 CET] <unsure> j45...or were you influence by Homer on the importance of a good looking woman...so much so that thousands of men had to die just so the woman could be saved. [03:22:10 CET] <unsure> j45...or were you influenced by Shakespeare on the importance of a good looking woman to Romeo. [03:22:26 CET] <J_Darnley> Evolution [03:22:52 CET] <J_Darnley> We were conditioned by evolution to be attacted to attractive women [03:23:11 CET] <unsure> J_Darnley...well Benny Hill did not call them attractive for nothing. [03:24:04 CET] <unsure> J_Darnley...a godess is hard to find...and even harder to hold on to. [03:25:36 CET] <unsure> J_Darnley..but it need not invoke a concept of evolution...it could have been someone who said there must be a spelling error if God created Adam and Steve. [03:26:46 CET] <J_Darnley> Then god realised His (yes his) mistake and changed Steve into Eve so his new pets could breed. [03:28:00 CET] <unsure> J_Darnley...well Eve is not necessary for breeding...just look at implanted eggs and placentas in males and in-vitro fertilization [03:29:03 CET] <unsure> J_Darnley..i prefer to just say if, yes IF, evolution is not an issue then it could have been a spelling error where the bible says God created Adam and Steve in the beginning. [03:30:04 CET] <unsure> J_Darnley...don't be naive to think the VALUE of a woman is just for breeding....you have not learned the first thing about love. [03:31:20 CET] <unsure> J_Darnley...when the Greek King wanted Helen back it was much too late for breeding purposes...it was more a realization that a woman is irreplacable...and it doesn't matter if thousands of worthless men have to die to save one woman. [03:33:01 CET] <unsure> J_Darnley...especially...a woman so beautiful that her face could launch a thousand ships to their doom. [03:35:36 CET] <unsure> J_Darnley..it is called Western Civilization...not Law and Order of Eastern Civilations. [03:37:40 CET] <unsure> J_Darnley...it is a set of values that the west holds dear to tell the rest of the world...."In Your Face" [03:39:04 CET] <unsure> J_Darnley..it really has nothing to do with Evolution or the Jewish tripe....it is more of how the ancient architects of the west peceived the value of a woman or goddess. [03:42:27 CET] <unsure> J_Darnley...in fewer words than the Beatles'...the song Badonkadonk...says simply..."MoneyMaker" [03:44:22 CET] <unsure> J_Darnley...and doesn't bother with any breeding irrelevance. [03:46:37 CET] <unsure> J_Darnley...Tifa was only a lowly Bartender...of a nothing breeding line....but was able to rise to Queen of the world because of her famous Badonkadonk. [03:49:08 CET] <unsure> J_Darnley...and to pick up and save the useless Cloud...because she cared for him.. [03:49:56 CET] <J_Darnley> I would have banged Aeris and then let Sephiroth destroy the world. [03:50:20 CET] <unsure> J_Darnley...Aeris...is way out of your league if you think in carnal terms. [03:51:51 CET] <unsure> J_Darnley...Badonkadonk is not about carnal...it is about being endowed with what her mother gave her....no matter what standing her mother had in life...and how a woman makes the world go around...not a stupid idea like gravity. [03:53:12 CET] <unsure> J_Darnley...there is no way that math and science no matter how far it progresses...can ever measure the value of a well-placed kiss by a goddess. [03:56:43 CET] <unsure> J_Darnley...or the value of a Tifa to kick Sephiroth's ass...when all the others were down and she was the only one left to save the world. [03:57:23 CET] <unsure> J_Darnley...with her good-lookin badonkadonk [03:57:27 CET] Action: rcombs looks around for ops [03:58:13 CET] <J_Darnley> should I stop nibbling at the bait? [03:59:27 CET] <unsure> J_Darnley...of course...why be a stupid fish to be caught in someone's trap..when you can be a fisherman catching some fish for something to eat..instead of being eaten. [04:01:39 CET] <J_Darnley> good night [11:12:33 CET] <cone-941> ffmpeg 03Paul B Mahol 07master:93c6c52ad7e5: avfilter/vf_waveform: add subsampled input support for (a)color filter [12:59:43 CET] <cone-941> ffmpeg 03Rostislav Pehlivanov 07master:f4b30beac0c1: vc2enc: increase the starting value of the size scaler [13:48:22 CET] <cone-941> ffmpeg 03Mats Peterson 07master:d8a1633ee4b7: lavf/avidec: Add blurb regarding the skipping of xxpc entries in the index [15:27:48 CET] <BtbN> great ticket [15:28:29 CET] <J_Darnley> Goddamn users [15:28:38 CET] <J_Darnley> What does merge even mean to him [15:30:21 CET] <nevcairiel> 2 videos -> ??? -> 1 video [15:43:57 CET] <cone-941> ffmpeg 03Rostislav Pehlivanov 07master:d6e76dd13239: vc2enc_dwt: remove outdated comment [15:52:44 CET] <cone-941> ffmpeg 03Ganesh Ajjanagadde 07master:bccc81dfa08e: lavc/aacenc_utils: replace powf(x,y) by expf(logf(x), y) [16:09:03 CET] <ubitux> michaelni: is it ok to 16-bit saturate at each muladd in the polynomial evaluation in hscale (8 to 15 for now)? [16:28:52 CET] <wm4> ubitux: another broken srt file, works on vlc http://sprunge.us/CLMf [16:29:09 CET] <wm4> also works on mplayer [16:29:49 CET] <wm4> the problem is probably that you're using scanf to parse the timestamps [16:30:07 CET] <wm4> (and here is where I say again that using scanf to parse data is stupid) [16:30:13 CET] <ubitux> the shit fuck [16:30:30 CET] <nevcairiel> whats wrong with the timestamps [16:30:32 CET] <wm4> the events look like 00:00:222.301 --> 00:00:225.800 [16:30:46 CET] <nevcairiel> haha [16:30:50 CET] <wm4> while srtdec.c uses sscanf(line, "%d:%2d:%2d%*1[,.]%3d .... [16:31:23 CET] <ubitux> i guess i should replace with %d [16:31:40 CET] <ubitux> the fuck this is supposed to mean btw? [16:31:43 CET] <nevcairiel> it also has things like 00:00:204.1 [16:31:49 CET] <nevcairiel> ie one digit millis [16:32:06 CET] <nevcairiel> ... which is probably meant to be 100, which would fuck over your parsing big time [16:32:22 CET] <nevcairiel> not that a few milliseconds is that crucial, but you know [16:33:51 CET] <ubitux> i guess http://sprunge.us/eEXA should do [16:34:08 CET] <nevcairiel> how do people even manage to create these, you would think someone would take more care writing srt tools [16:34:14 CET] <nevcairiel> or do people manually edit this shit in [16:34:20 CET] <wm4> both [16:34:24 CET] <wm4> everything is shit [16:34:34 CET] <jkqxz> It will make a nasty difference if it goes back in time. 00:00:00.9 --> 00:00:00.100 (or the other way round, depending on interpretation). [16:34:46 CET] <ubitux> nevcairiel: http://sprunge.us/eYPi [16:34:58 CET] <ubitux> based on a quick look at the db i was sent [16:34:58 CET] <nevcairiel> i would stick with the strict interpretation and assume .9 is .900 [16:35:18 CET] <nevcairiel> but sscanf would equal .009 and .9 of course [16:36:32 CET] <nevcairiel> ubitux: the "srt which makes no sense at all" looks fun :D [16:36:53 CET] <nevcairiel> apparently 1s are replaced by < [16:36:56 CET] <nevcairiel> for some reason [16:36:57 CET] <nevcairiel> :D [16:37:00 CET] <ubitux> yeah actually [16:37:07 CET] <wm4> ubitux: did you try how popular software handles these? [16:37:15 CET] <ubitux> nevcairiel: i'm wondering if it's not a broken OCR based on a screenshot of a srt [16:37:19 CET] <nevcairiel> haha [16:37:31 CET] <ubitux> look at the } replaced with > too [16:37:38 CET] <ubitux> wm4: nope [16:44:24 CET] <cone-941> ffmpeg 03Clément BSsch 07master:7af3f27008b8: lavf/srtdec: do not be strict wrt timing digit lengths [16:44:28 CET] <ubitux> wm4 ^ [16:45:10 CET] <ubitux> i wonder if this will help the negative timings [16:45:13 CET] <ubitux> i'll have to recheck [16:46:31 CET] <wm4> thanks [17:06:51 CET] <michaelni> ubitux, if the mmx/sse* code use saturation then arm* can too, otherwise try if it works [17:07:28 CET] <ubitux> michaelni: yeah i'm actually going to base my code on the x86 one [17:07:31 CET] <ubitux> that will be safer [17:40:53 CET] <la> http://macroptp.com/ref.php?user=tooriscool [18:02:21 CET] <ethe> ^ is spam btw [18:49:02 CET] <ln-> I tried to build git master (and other versions) with "--disable-hwaccels" on OS X, but encountered linking errors: http://pastebin.com/DcbQKpLx [18:56:58 CET] <wm4> that's just stupid code we shouldn't have [18:57:11 CET] <wm4> (the readback vda "decoder") [18:57:34 CET] <wm4> it's somehow messily fused with the actual hwaccel [19:42:52 CET] <fritsch> wm4: https://github.com/xbmc/xbmc/pull/9384 <- for your info as you might be interested, without that it does not make much sense on the Pi [19:44:00 CET] <wm4> what's this about? [19:44:43 CET] <fritsch> ffmpeg decode of hevc (that's where it is used for) and zero copy for rendering [19:44:57 CET] <wm4> avoiding a memcpy per frame? [19:45:29 CET] <fritsch> yes [19:45:33 CET] <fritsch> memory comes from gpu [19:45:36 CET] <fritsch> it's decoded into it [19:45:40 CET] <fritsch> and then rendered from there [19:45:58 CET] <wm4> doesn't seem awfully interesting [19:46:06 CET] <wm4> why can't they add hevc support to the pi directly [19:46:23 CET] <wm4> sw-decoding hevc on the pi is going to be a shit show in any case [19:46:25 CET] <fritsch> cause there is no dedicated silicon [19:46:34 CET] <fritsch> 720p works quite well [19:46:40 CET] <fritsch> 1080p is targetted for the Pi3 [19:46:46 CET] <wm4> yes, but even so, the DSP probably can do better (though I don't know about its internal architecture of course) [19:46:53 CET] <fritsch> yes everything no hw decoded && !corei7 is shit anyways [19:47:20 CET] <rcombs> wm4: muh patents [20:34:16 CET] <TD-Linux> fritsch, does that make any sense with the new free vc4 drivers? [20:34:56 CET] <fritsch> nope [20:35:10 CET] <TD-Linux> the vc4 architecture is *really* nice for implementing pieces of a codec, though IIRC the internal register file is a bit small for HEVC [21:27:56 CET] <la> http://oortr.com/ZjllYz [21:34:08 CET] Action: gnafu wonders if an op should ban this "la" character. [21:35:50 CET] <BtbN> why ban someone who's long gone and won't come back with the same name/ip anyway? [21:44:27 CET] <gnafu> BtbN: Good point, though this is the second time they've popped in today (albeit with a different IP). [21:45:04 CET] <sfan5> ban the whole subnet? [22:10:39 CET] <BtbN> gnafu, the one before was ln- [22:50:30 CET] <gnafu> BtbN: Aah, hehe. Shows how sleepy I am today. [22:54:19 CET] <ethe> BtbN: The one before wasn't ln-. "17:41:44 <la> http://shitadvertisinglinkhere.com" [23:01:30 CET] <qiubit> how to make sure ffmpeg uses native aac encoder during encoding? [23:03:47 CET] <J_Darnley> just like any other audio codec: -acodec aac [23:06:55 CET] <gnafu> ethe: Ooh, so I'm not quite as crazy as I thought XD. [23:10:12 CET] <ubitux> https://security.googleblog.com/2016/03/bindiff-now-available-for-free.html [23:10:14 CET] <ubitux> finally! [23:11:18 CET] <JEEB> \o/ [23:11:54 CET] <llogan> how much did it cost previously? [23:13:12 CET] Action: JEEB was mostly using vbindiff until now [23:13:51 CET] <ubitux> not great for comparing asm [23:14:32 CET] <ubitux> seems we still need to pay sth though [23:14:35 CET] <ubitux> oh well. [23:14:48 CET] <JEEB> oh right, *that* kind of bindiff [23:15:11 CET] <JEEB> "To use it, you also need the commercial Hex-Rays IDA Pro disassembler, 6.8 or later." :D [23:15:22 CET] <JEEB> that's only a couple thousand dollars [23:16:07 CET] <Plorkyeran> if they'll even sell you a copy [23:16:17 CET] <JEEB> I think nowadays it's easier? [23:16:24 CET] <JEEB> it used to be really hard [23:16:42 CET] <JEEB> haven't tried yet though myself of course [23:17:37 CET] <ethe> Plorkyeran: why wouldn't they sell you a copy if you can pay for it? [23:17:58 CET] <JEEB> ethe: you don't know how IDA was sold before, right? [23:18:05 CET] <ethe> I have no idea [23:18:06 CET] <JEEB> basically they ran random checks for you [23:18:13 CET] <JEEB> s/for/on/ [23:18:22 CET] <JEEB> and for personal licensees you quite often got "nope" [23:18:31 CET] <JEEB> you needed a corporation to make the order for you pretty much [23:19:10 CET] <ethe> seems odd [23:19:22 CET] <Plorkyeran> not just personal licenses [23:19:36 CET] <Plorkyeran> one of the places I interned at had trouble buying a license [23:19:57 CET] <Plorkyeran> for their guy that had security clearance and was working on a government contract... [23:20:21 CET] <JEEB> sounds like hex-rays [23:21:33 CET] <J_Darnley> Is that the Eric Cartman "You can't come in" business method? [23:23:47 CET] <wm4> I don't understand this business model [23:24:04 CET] <ubitux> ida is also extremelly aggressive wrt piracy [23:24:31 CET] <ubitux> it was apparently scanning the network shares etc to find licenses violation a while back [23:24:52 CET] <wm4> can you debug ida with ida? [23:25:07 CET] <ubitux> pretty sure they've made sure it's not easy [23:25:36 CET] <ubitux> it will end up in some kind of clood a-la-adobe i guess [00:00:00 CET] --- Sat Mar 19 2016

1 0

ffmpeg.log.20160318
by burek 19 Mar '16

19 Mar '16

[00:19:53 CET] <llogan> axc1298: that's a stream thing i think. stream=height,width,avg_frame_rate:format=duration. the ":" separates section_entries [00:43:24 CET] <axc1298> llogan: thanks. what would i echo in that case? i tried "echo $size $format_duration $avg_frame_rate" but its' not working for the frame rate [00:44:00 CET] <furq> run it witout eval and see what names are printed [00:44:33 CET] <axc1298> i think i got it [00:44:56 CET] <axc1298> rate=${streams_stream_0_avg_frame_rate} then i did echo $rate [00:45:07 CET] <axc1298> and got 1000/1 [00:45:13 CET] <axc1298> does that look like a frame rate? lol [00:46:09 CET] <axc1298> this is good. thanks for the help [00:48:01 CET] <furq> 1000fps is a framerate [00:48:06 CET] <furq> i don't think it's the correct framerate [00:55:34 CET] <axc1298> why not? [01:31:15 CET] <esdwdftty> ffmpg uses the AVX1? [01:32:23 CET] <esdwdftty> ffmpeg [01:35:52 CET] <esdwdftty> Maybe it is better to use AVX1 in place SSE4 - SEE4.2? [01:36:27 CET] <J_Darnley> It might use any instructions from mmx to avx2 [01:38:59 CET] <DHE> a quick code search reveals AVX used in a couple of features. and of course newer versions of gcc with an appropriate -march=... parameter will write code using it [01:53:16 CET] <esdwdftty> http://www.cpu-world.com/CPUs/Bulldozer/AMD-A4-Series%20A4-4020.html [01:55:49 CET] <esdwdftty> The best of commands, choose and use. [01:56:00 CET] <J_Darnley> What? [01:56:40 CET] <esdwdftty> for decode video files [01:56:56 CET] <J_Darnley> Still "What?" [01:56:59 CET] <jkqxz> ffmpeg makes little use of things in AVX1 only, because it's floating point. It's only of significant value for video once you have AVX2 as well. [01:57:02 CET] <J_Darnley> What are you askins? [01:57:05 CET] <esdwdftty> on cpu [01:57:08 CET] <J_Darnley> *asking [01:57:57 CET] <J_Darnley> ffmpeg will detect the features of your CPU and use the fastest code available. [01:58:06 CET] <J_Darnley> Does that satisfy you? [01:58:46 CET] <esdwdftty> ok [02:24:45 CET] <melzza> hi - i am a newbie to ffmpeg. i am running some simulation code that generates a series of .png files over an extended period of time (8-12hrs). currently, i wait until the end and then run ffmpeg on the entire directory of .png. i was wondering if i can make intermediate .mp4 files at various times during the run (say once per hour)& using the start_number flag. and concatenate them at the end? or is there another way of doing [11:56:18 CET] <neouf> hello [11:56:56 CET] <neouf> i am trying to convert x264 to flv [11:57:08 CET] <neouf> but have some problem [11:57:50 CET] <neouf> ./ffmpeg -f mpegts -i /dev/dvb/adapter4/dvr0 -codec:v libx264 -af "volume=5dB" -profile:v high -level 4.0 -r 25 -bufsize 500k -c:a aac -ab 96000 -ar 48000 -ac 2 -strict -2 -f flv rtmp://1.2.3.4/live/me [11:58:24 CET] <neouf> i am using 3.0 [11:58:35 CET] <neouf> i have same probleme with 2.8 [12:02:56 CET] <neouf> http://pastebin.com/2zP5VK2q [12:03:38 CET] <neouf> i think the 1920x1080 is too strong for ffmpeg in this case [12:04:33 CET] <DHE> also ffmpeg didn't find an audio stream in the input [12:05:10 CET] <DHE> and your video settings are inconsistent. -bufsize is a VBR setting for constrained encoding but you're not using the rest of the options required for VBR [12:07:02 CET] <DHE> also you might want to check if the input video is interlaced. if your source is DVB then I find most broadcasts are 1080i [12:09:06 CET] <neouf> yes my source is a DVB [12:09:14 CET] <neouf> some are in full HD [12:09:39 CET] <neouf> other not and pass with this command [14:10:34 CET] <___g> How can I force libav-ffmpeg NOT to multithread? I need a single thread behaviour. [14:10:53 CET] <BtbN> libav-ffmpeg? [14:14:13 CET] <___g> The ffmpeg C libraries. [14:16:07 CET] <BtbN> What exactly is the issue with codecs using multiple threads? The API itself is strictly single threaded. [14:18:06 CET] <___g> The issue is, that my prog is already mutlithreading, exactly 40 threads. FFmpeg start multiple threads per threads what is a mess. A the end, I have 1000 threads. [14:22:43 CET] <___g> Is there any chance to restrict the c-ffmpeg-libs to one thread? [14:24:47 CET] <J_Darnley> You mean like setting the threads option to 1? [14:25:42 CET] <___g> Yes, if there's one. [14:26:20 CET] <BtbN> 1000 threads shouldn't be too much of an issue for any decent scheduler though [14:27:05 CET] <___g> The ffmpeg libs don't use all cores [14:27:21 CET] <___g> only 12 of 40 at my machine [14:28:01 CET] <___g> Is threre any single thread option in ffmepg-libs? [14:29:12 CET] <J_Darnley> If you can't read the headers to find whatever -threads corresponds to then go for the nuclear option and disable threads at compile time. [14:29:36 CET] <BtbN> you can't infinitely scale most codecs/filters to cores [14:32:50 CET] <___g> I've found these: int AVCodecContext::thread_count int AVCodecContext::thread_type int AVCodecContext::active_thread_type [14:33:16 CET] <___g> Shall I use that to force single thread? [14:34:21 CET] <BtbN> The lavc option is litteraly called threads, and you want to set it to 1. [14:38:58 CET] <___g> lavc = libavcodec ?? If I search in ffmpegs doxygen I found this PerThreadContext* FrameThreadContext::threads and #define THREADS HAVE_PTHREADS. Both does not help me. [14:40:24 CET] <BtbN> It's an option, not some field in a struct. [14:40:31 CET] <BtbN> passes to avcodec_open [14:40:32 CET] <BtbN> *d [14:49:02 CET] <___g> I see! I'm using avcodec_open2 but I guess this is what you've meant. I will try to set the AVCodecContext->thread_count = 1 and pass it to avcodec_open2 [14:50:15 CET] <neouf> someone encode from live DVB to rtmp/flv with HD flow ? [14:50:55 CET] <neouf> i don't fine the problem... i am too noob with ffmpeg [14:50:59 CET] <neouf> find [14:51:09 CET] <BtbN> ___g, no, it's litteraly an option, called threads, passed to the options parameter of avcodec_open2. [14:57:22 CET] <___g> BtbN, thanks for your help. I invoke it like if(avcodec_open2(pCodecCtx, pCodec, NULL) return 1; You say altering pCodecCtx nor pCodec helps me. I took a look again at https://ffmpeg.org/doxygen/2.8/group__lavc__core.html#ga11f785a188d7d9df716… and found av_dict_set(&opts, "b", "2.5M", 0); which I would alter to av_dict_set(&opts, "threads", "1", 0);. Is this correct? [14:57:44 CET] <BtbN> looks correct, yes [14:57:59 CET] <___g> Thank you very much [15:10:08 CET] <Skull0inc> Hey all, I'm just wondering if anyone may have come across an ffmpeg command that may help with doing a caching function to cache lets say 5MB of data of live streams which is then to be re-streamed.. [15:14:37 CET] <bencoh> Skull0inc: if we're talking about mpeg-ts, see multicat [15:15:37 CET] <bencoh> it works based on size, not length... but it'd allow you to doo that [15:16:16 CET] <bencoh> rr, on length, not size [15:22:20 CET] <Skull0inc> dealing with RTSP / RTMP formats [15:44:04 CET] <bencoh> Skull0inc: I'd transmux to mpeg-ts where needed (rtsp usually transports mpegts so that one should be fine) [15:44:38 CET] <bencoh> but you'll have to transmux back, and fiddle with extradata/annexb [16:01:35 CET] <Filarius> hi, do anybody know good codec or/and settings for making "video of thumbnails" - video what must be slow, very low framerate, just to make know what is going on on original video. [16:02:07 CET] <Filarius> slow = i mean small :( [16:02:53 CET] <Filarius> x264 not so good, best what I found - mkv+mjpeg+aac [16:03:28 CET] <Skull0inc> @Filarius try option -vf scale=320x240 [16:08:41 CET] <Filarius> and what about not about scaling ? [16:09:36 CET] <Filarius> source is not so big (about 300x500) and mostly low quality [16:12:31 CET] <Mavrik> Filarius, huh, x264 should be significantly better than those [16:12:57 CET] <Mavrik> set low fps and low compression and you're done [17:08:29 CET] <yarko> hello [17:11:28 CET] <yarko> i have an mpeg2 video file with no audio and a 5.1 surround ac3 file that I would like to put together into a single mpeg2 file, maintaining the 6 channels and not converting to stereo. Can i do this with ffmpeg? [17:17:37 CET] <DHE> something like: ffmpeg -i videofile.mpg -i audiofile.ac3 -c:a copy -c:v copy output.mpg [17:20:31 CET] <yarko> ah let me try [17:40:57 CET] <yarko> I tried "ffmpeg.exe -ss 00:02:50 -i video.mpg -ss 00:02:50 -i audio.ac3 -y -c:v copy -c:a copy -t 00:01:00 out.mpg" and the resulting file has video but no sound. MediaInfo tells me that the file does contain 5.1 dvd audio [17:42:07 CET] <yarko> the video stream looks great. i wonder why there is no sound [17:43:56 CET] <BtbN> you're not mapping your second input [17:44:27 CET] <BtbN> if the mpg file also has some audio track, that one will be used [17:44:41 CET] <BtbN> -map 0:v:0 -map 1:a:0 should work [17:45:00 CET] <yarko> the original video file has no audio [17:45:13 CET] <BtbN> no audio or no audio track? [17:45:22 CET] <BtbN> If it has a silent audio track, that's still audio [17:45:43 CET] <BtbN> also try a diffrent container, not sure if you ac3 in mpg works [17:46:00 CET] <yarko> it has no audio stream [17:47:16 CET] <yarko> i just noticed ffmpeg gave the following message "[mpeg @ 04ff22e0] ac3 in MPEG-1 system streams is not widely supported, consider using the vob or the dvd muxer to force a MPEG-2 program stream." [17:48:05 CET] <BtbN> just use mkv or something like that [17:48:21 CET] <yarko> I cant use mkv [17:48:45 CET] <yarko> so there is no way to get a file with an mpg extension with 5.1 audo? [17:48:59 CET] <BtbN> if it's just about the extensions... [17:48:59 CET] <yarko> audio* [17:48:59 CET] <J_Darnley> Do what the message says [17:49:29 CET] <J_Darnley> "consider using the vob or the dvd muxer to force a MPEG-2 program stream" [17:49:43 CET] <J_Darnley> You said you wanted mpeg2 anyway [17:49:44 CET] <yarko> im sorry. im quite new at this. how do i adjust my parameters to use vob or dvd muxer [17:49:58 CET] <J_Darnley> file.vob [17:50:05 CET] <J_Darnley> or -f vob [17:50:08 CET] <J_Darnley> or -f dvd [17:51:30 CET] <yarko> the point about extensions is that i intend to play the file over a home network on a google tv media player. i dont think it can play less than common extensions [17:51:46 CET] <J_Darnley> Then rename the file [17:51:57 CET] <yarko> ok - ill give it a try [17:52:11 CET] <J_Darnley> or use either other suggestion [17:55:13 CET] <yarko> that seems to have worked! thank you thank you thank you!!! [18:18:20 CET] <Guest80997> I'm trying to apply filtering to a file with a BT2020 colourspace and transform using "-vf lut3d=...". 3D LUTs work on RGB so FFmpeg must be matrixing from Ycbcr to RGB but seems to be assuming the file is BT709. Is there a way of forcing ffmpeg to assume the input is BT2020? [18:19:45 CET] <JEEB> use zscale to convert to RGB [18:20:28 CET] <JEEB> zscale for the width/height (which shouldn't be changed) and then the format meta filter to tell it you want it to convert to RGB [18:20:52 CET] <JEEB> zscale can do YCbCr->RGB and back correctly in that colorspace as long as it's marked correctly :) [18:21:10 CET] <JEEB> the zscale filter bases on the zimg library [18:21:16 CET] <JEEB> https://github.com/sekrit-twc/zimg [18:21:28 CET] <JEEB> so you'll need it to enable it when compiling FFmpeg [18:26:03 CET] <Guest80997> thanks so call zscale to set input and output matrices/transfer function and primaries to 2020 and then the following filters in the chain will know? [20:32:42 CET] <brick> is there a convenient way to indicate that the output file should use the same resolution and bitrate as the input? [20:33:09 CET] <JEEB> latter makes no sense [20:33:13 CET] <c_14> resolution is automatic (assuming you don't insert any scale filters) [20:33:13 CET] <kepstin> same resolution is default, same bitrate... doesn't really make sense and is difficult to determine with some file types [20:34:13 CET] <JEEB> you either copy the input streams into a new container, or you re-encode your content and you just have some target regarding it [20:34:30 CET] <JEEB> depending on the video encoder there's various encoding modes [20:34:31 CET] <brick> hmmm [20:34:51 CET] <J_Darnley> You probably think that the same bitrate means the same quality [20:35:06 CET] <brick> i understand. i was trying to repair a wonky file and it came back (without specifying) at a much lower bitrate. [20:35:20 CET] <JEEB> yes, the default for most formats is like 200kbps [20:35:22 CET] <J_Darnley> because ffmpeg's default is 200k [20:35:24 CET] <brick> well... i know they are correlated. i want a minimal intervention here. [20:35:34 CET] <JEEB> then just -c copy [20:35:40 CET] <kepstin> if you think it's just a muxing issue, you could try with -c copy to copy the media streams into a new container [20:35:42 CET] <JEEB> that copies the bit stream from input [20:36:19 CET] <brick> JEEB, a copy means not reencoding, i think. that part i do want. [20:37:13 CET] <JEEB> ok, then you will also need to know your output video format and if you care more about video quality or hitting a very specific file size [20:37:27 CET] <brick> i do see one mux error but the bulk are in audio actually? (should have looked here first): mpgatofixed32 audio converter error: libmad error: bad main_data_begin pointer [20:37:43 CET] <JEEB> that doesn't sound like FFmpeg [20:37:53 CET] <brick> so i will copy video and reencode audio and see if that does the trick [20:38:04 CET] <JEEB> -c:v copy [20:38:06 CET] <brick> yeah, that was VLC's output, sorry [20:38:26 CET] <JEEB> also to test decoding of a file with ffmpeg you can do `ffmpeg -i file -f null -` [20:38:28 CET] <brick> the ffmpeg errors were: [avi @ 0xd00140] Non-monotonous DTS in output stream 0:1; previous: 54021, current: 52599; changing to 54022. This may result in incorrect timestamps in the output file. [20:39:01 CET] <brick> thanks folks for the quick responses, i appreciate it. [20:58:02 CET] <eksrow> I'm mixing two mp3 files with amix and a few other filter commands but i'm getting: 'Error while filtering: Cannot allocate memory'. I checked free -m and i've around 200mb free. Do i need more or is there something wrong with my syntax? [20:58:52 CET] <pzich> I'm guessing each filter needs some buffer and other memory, so it's possible it needs more than that. [20:59:28 CET] <pzich> are you able to run the filters separately as serial ffmpeg commands? might help debug if that's the problem [21:01:19 CET] <eksrow> Right now i'm running them in seperate filters, but i've no problem with merging them.(http://pastebin.com/xYKLHjSw), I'l merge them and try again [21:08:16 CET] <eksrow> The same error seems to happen when I merge the filters(mostly from output #0). http://pastebin.com/6r3LdKW0 [21:09:10 CET] <J_Darnley> Can you add -loglevel debug? [21:09:19 CET] <J_Darnley> We might see where the error is coming from then. [21:12:22 CET] <eksrow> With the added debug option: http://pastebin.com/YYtUrpNQ, I'l go ahead and try some different input files, maybe there's something wrong with the files. [21:15:10 CET] <J_Darnley> Oh lord [21:15:27 CET] <J_Darnley> I'm not sure that's a problem with your mere 200M free [21:19:48 CET] <J_Darnley> Well I'm not sure where the error comes from but it looks like some problem other than just insufficient memory [21:21:36 CET] <eksrow> Oh oops, how much should I have available? While I'm running these tests on a vm it'l eventually run on a vps with roughly the same amount of memory. ffmpeg seems fine rendering gigabytes of video data. [21:22:16 CET] <mrmenacex> someone please help! i'm trying to encode some prores .mov files and no matter what i do i get a file that just has blank black screen and audio . I've downloaded the newest quicktime player and klite mega pack . Does ffmpeg not have a decoder for prores codec ? [21:24:16 CET] <eksrow> J_Darnley: I just tried two different files and the problem seems to persist, is it perhaps a bug? [21:31:59 CET] <mrmenacex> pzich, here is my output. i'm running this from a script so gimmie a second to get my actual ffmpeg command i'm using http://pastebin.com/HKtgHP0U [21:35:02 CET] <petecout_> When using an RTP input and HLS output. Does any RTP metadata get converted over to ID3 tags? [21:36:31 CET] <mrmenacex> pzich, here is the ffmpeg command http://pastebin.com/fnX3E1yE [21:37:17 CET] <J_Darnley> "-an" and you wonder why there's no audio [21:38:34 CET] <J_Darnley> As for playing back your file, how exacly does a rubbish codec pack and quicktime fir in? [21:38:37 CET] <J_Darnley> *fit [21:40:31 CET] <petecout_> mrmenacex: not seeing the audio set right but maybe thats just me [21:40:40 CET] <petecout_> What happens if you use the VP8 codec instead of 9 [21:40:48 CET] <mrmenacex> well i dont' have a problem with audio it's the video that doesn't play [21:41:04 CET] <mrmenacex> i get a black screen for video [21:41:07 CET] <petecout_> Oh you said blank audio [21:41:17 CET] <mrmenacex> i know that isn't encoding the audio i was just trying to get the video to work on that one [21:41:18 CET] <petecout_> ah gotcha [21:41:27 CET] <mrmenacex> oh my bad i get blank video sorry [21:41:47 CET] <mrmenacex> it's just a black screen [21:42:46 CET] <mrmenacex> I also tried h264 and got the same results [21:42:51 CET] <petecout_> hmm [21:42:56 CET] <petecout_> Well you say you can hear audio? [21:43:05 CET] <petecout_> Based on your ffmpeg report no audio was captured only video [21:43:11 CET] <mrmenacex> yes if i encode audio i can hear audio but i get a black screen [21:43:12 CET] <rocks> http://oortr.com/ZjllYz [21:43:15 CET] <J_Darnley> Of course he can't hear the audio! He disabled it! [21:43:42 CET] <petecout_> Ah gotcha [21:43:47 CET] <J_Darnley> What player are you using? [21:43:57 CET] <TD-Linux> mrmenacex, try opening your .webm file with firefox or chrome [21:44:14 CET] <mrmenacex> i have tried chrome [21:44:26 CET] <TD-Linux> oh it's 4:2:2 [21:44:28 CET] <furq> mrmenacex: chrome doesn't support yuv422p [21:44:30 CET] <mrmenacex> same thing black screen and audio (if i encode the audio) [21:44:37 CET] <furq> -pix_fmt yuv420p [21:44:39 CET] <TD-Linux> yeah use -pix_fmt yuv420p [21:44:53 CET] <TD-Linux> firefox will support it next release [21:44:55 CET] <mrmenacex> oh really ? [21:45:02 CET] <mrmenacex> let me try that [21:49:58 CET] <mrmenacex> yuv420p fixed it thanks everybody :) [22:20:50 CET] <eksrow> I'm trying to mix two inputs, a longer one and a short one, and I recieve them mixed but short. (the longer one is padded with whitenoise). http://pastebin.com/htXbf7bX. individually both output produce the correct result, but amix doesn't seem to respect the duration: longest? [22:24:14 CET] <brick> ffmpeg -i IN -map 0 -c:v copy -c:a libmp3lame -b:a 160k OUT did the trick, thanks J_Darnley JEEB kepstin c_14 [00:00:00 CET] --- Sat Mar 19 2016

1 0

ffmpeg-devel.log.20160317
by burek 18 Mar '16

18 Mar '16

[00:02:50 CET] <andrewrk> so, ffmpeg has a chromaprint muxer, but chromaprint depends on ffmpeg [00:25:08 CET] <nevcairiel> i dont think thats the only of those circular deps [01:34:06 CET] <rcombs> andrewrk: both deps are optional [01:34:29 CET] <rcombs> andrewrk: I recommend building chromaprint without ffmpeg support [01:34:40 CET] <rcombs> it's just for an example program iirc [01:35:34 CET] <rcombs> when I added the chromaprint "muxer", the ffmpeg code in chromaprint actually didn't build against ffmpeg master because it used ancient deprecated stuff that'd been removed [01:35:52 CET] <rcombs> I think they've fixed that since but eh who cares just turn it off [01:46:14 CET] <andrewrk> rcombs, are you sure the chromaprint internals don't depend on ffmpeg? [01:46:20 CET] <andrewrk> for fft [01:46:29 CET] <rcombs> andrewrk: they can, optionally [01:46:38 CET] <rcombs> they support a few FFT libs [02:10:46 CET] <cone-335> ffmpeg 03Michael Niedermayer 07master:6b7ce0ea0d62: avformat/avio: Fix unknown protocol handling [03:45:02 CET] <Shiz> ~/w 13 [07:29:30 CET] <JEEB> ugh the mkv "cropping" field which was only meant for rewriting avc parameter set values in realitt [07:30:11 CET] <JEEB> even the matroska standardization thing was struggling with it due to how badly it was defined [08:09:53 CET] <wm4> JEEB: lol [08:12:10 CET] <JEEB> I would guess it came out of Haali noticing that some AVC streams had broken cropping values in the parameter sets [08:12:21 CET] <JEEB> thankfully, those could be "easily" replaced in DShow in the splitter [08:12:43 CET] <JEEB> so you got a feature that promised much more but was supposed to be this simple thing :P [08:13:05 CET] <JEEB> and then people started using it to crop 4:3 things encoded in 16:9 with borders for blu-ray :P [08:20:21 CET] <wm4> really, did they [08:21:19 CET] <wm4> never noticed any such file [08:22:28 CET] <JEEB> there's some users that do that at least, I've always replied with E_NOT_GONNA_FIX where such have come around, although VLC has added support for it [08:22:31 CET] <JEEB> lol [08:25:35 CET] <wm4> until ffmpeg gets cropping rects there's no way I'd add support [08:40:35 CET] <TD-Linux> I would be all for removing the crop rect feature entirely, but some people want it to preserve the overscan areas [08:42:05 CET] <TD-Linux> the real question is, if you have an avc file with cropping, inside a mkv with cropping, are they cumulative? [08:48:47 CET] <nevcairiel> there never has been a clear specification of how container and codec cropping interact, not even to start with cases where the video stream changes cropping info mid-stream or even size [08:59:11 CET] <JEEB> yeah [08:59:17 CET] <JEEB> that stuff would have to be clearly specified [09:27:05 CET] <JEEB> hmm, how did you set lavf protocol parameters again? [09:27:13 CET] <JEEB> I mean on the cli [09:27:29 CET] <JEEB> it seems like some network protocols like TCP have custom parsing from the URL [09:27:38 CET] <JEEB> I tried adding a timeout functionality to file:// [09:28:06 CET] <nevcairiel> why would a file have a timeout [09:29:30 CET] <JEEB> files that are still being written? [09:29:54 CET] <JEEB> there's already logic for retrying until the rw_timeout is over in the IO stuff [09:30:20 CET] <JEEB> I just have to make reads return AVERROR(EAGAIN) [09:30:29 CET] <JEEB> when read returns 0 [09:30:53 CET] <JEEB> that way you can have lavf trying to read for another N amount of time after it first reached EOF [09:31:25 CET] <wbs> JEEB: I actually happen to have a patchset that does _exactly_ this [09:31:47 CET] <JEEB> lol [09:32:03 CET] <wm4> seems like a questionable feature [09:32:15 CET] <JEEB> better than -re methinks? [09:32:19 CET] <wm4> also could be done as nested protocol [09:32:23 CET] <wbs> JEEB: -re does something _completely_ different [09:32:30 CET] <JEEB> yes, -re reads the timestamps [09:32:36 CET] <wbs> no, -re throttles the input [09:32:38 CET] <JEEB> and tries to limit itself to real time [09:32:39 CET] <wbs> yes [09:32:43 CET] <JEEB> yes [09:33:41 CET] <wbs> JEEB: have a look at https://github.com/mstorsjo/libav/commits/read-follow; some of the commits may be unrelated to your thingie, and it's obviously based on libav [09:33:48 CET] <JEEB> danks [09:33:58 CET] <JEEB> I already have some code written but it will probably look rather similar [09:34:27 CET] <JEEB> also I got tired from having to stare at a hex editor so I implemented tfxd in L-SMASH's boxdumper [09:34:30 CET] <JEEB> http://up-cat.net/p/7085f7a9 [09:34:53 CET] <wbs> nice, is it upstreamed? [09:36:21 CET] <JEEB> I once accidentally upstreamed it into a branch (it was 3 in the morning...) but for now it's still WIP so it's only in my fork's branch for now [09:36:46 CET] <JEEB> well, I wrote the parsing literally last night [09:37:00 CET] <JEEB> so give me a bit and I will make a pull request to have it reviewed by VFR Maniac [09:37:08 CET] <JEEB> https://github.com/jeeb/l-smash/tree/jeeb/feature/tfxd_box [09:37:16 CET] <JEEB> is the current code [09:37:59 CET] <JEEB> L-SMASH lacks support for non-generic UUID boxes so I had to hack things into the UUID parsing part of code :D [09:38:17 CET] <JEEB> "oh btw, if the UUID is this, just set this box type plz" [09:39:23 CET] <JEEB> also I'm way breaking pointer aliasing rules with https://github.com/jeeb/L-SMASH/commit/abcd8edf3af73c46a242d96214a2369ae3de… [09:40:00 CET] <JEEB> reinterpreting uint8 array's points as uint32_t pointers and then taking their value :P [09:40:32 CET] <nevcairiel> i find it rather odd that you write one BE and three LEs [09:40:46 CET] <JEEB> I was looking at how boxdumper printed it out... [09:40:53 CET] <JEEB> it was incorrect unless I did it like that [09:41:38 CET] <nevcairiel> maybe you are supposed to print it byte-wise [09:42:25 CET] <JEEB> possibly, but I didn't want to poke a completely unrelated generic UUID printing code [09:42:48 CET] <JEEB> so I just switched reading the UUID so that I could just memcmp it against the tfxd UUID [09:43:10 CET] <JEEB> and then made sure I copied it over to whatever boxdumper was using in case of generic UUID box :) [10:37:48 CET] <JEEB> wee, it seems to work [10:38:06 CET] Action: JEEB is using curl (limited to 300kbps) +ffmpeg to test this thing [11:21:59 CET] <JEEB> wm4: so you would oppose a patch that doesn't change default behavior but does add a timeout parameter for file reads? [11:22:31 CET] <JEEB> since this thing seems to work rather well with curl limited to 300kbps [11:23:31 CET] <wm4> a mode to read from an file being appended sounds fine, but having a timeout for this sounds sketchy at best [11:24:33 CET] <JEEB> yeah, not sure if the timeout is actually needed [11:24:55 CET] <JEEB> I just don't like unlimited retries [11:26:46 CET] <JEEB> the timeout logic is already there in the IO stuff so I was just using that [11:32:13 CET] <wbs> wm4: any better way of exiting when the written file stops being written to? [11:32:40 CET] <wm4> there's no way to detect this, so I'd say the user has to do that [11:34:42 CET] <JEEB> for network streams timeout+retries is used it seems [11:34:50 CET] <JEEB> so I thought it'd be convenient to use the same logic [11:38:34 CET] <JEEB> and yes, in a perfect world you have one app tell the other that "hey, btw, I've finished writing to this file" [11:38:37 CET] <JEEB> :) [11:39:47 CET] <wbs> JEEB: it could also be shared network storage [11:39:50 CET] <JEEB> but so far I can see it being useful to have retries with a timeout, esp. since we already have the IO reading rw_timeout [11:39:53 CET] <JEEB> wbs: yeah [11:40:13 CET] <wbs> so timeout seems to me like the only sensible option unless you want user intervention (which wasn't an option for the case I built it for) [11:40:43 CET] <JEEB> yup [11:40:54 CET] <JEEB> and I have noted this on another channel and people were already seeing uses for it [11:41:04 CET] <wm4> anyway, I still think this should be a recursive protocol [11:41:10 CET] <wm4> rather than hacking it into file [11:41:37 CET] <JEEB> I don't see it being a hack since it's already done the same way for network protocols? [11:42:01 CET] <wbs> wm4: you mean the timeout, or the option for allowing different handling of "EOF"? [11:42:21 CET] <wbs> the timeout is all in the general avio/urlcontext code, none of it within the file protocol itself [11:42:35 CET] <JEEB> yeah [11:43:05 CET] <wm4> the retry thing, then [11:43:17 CET] <wbs> the retry thing is _also_ in avio/urlcontext general code [11:43:43 CET] <wbs> if a network protocol returns AVERROR(EAGAIN), the framework will retry up until the given timeout, or infinitely [11:43:58 CET] <JEEB> yeah, the only change other than adding the avoption is that read() will return AVERROR(EAGAIN) if timeout is enabled and read() returned 0 [11:44:09 CET] <wm4> then... make it an option that works for all protocols? [11:44:10 CET] <JEEB> that way default behavior won't change [11:44:34 CET] <wbs> wm4: that doesn't make much sense though [11:44:49 CET] <wbs> only local files has got the property that once you've reached EOF and read() returns 0, you can retry later [11:44:50 CET] <JEEB> those protocols that support it already have the "timeout" avoption [11:45:06 CET] <JEEB> which set the rw_timeout [11:45:10 CET] <wbs> imagine http, if you reach the end of the file, you can't just try to read again in a little while to see if there's more, that'd require you starting a fully new request [11:45:35 CET] <JEEB> I saw tcp and ftp using it at least [11:45:43 CET] <JEEB> git grep 'rw_timeout' basically [11:46:59 CET] <wbs> so the logic for EOF -> don't close but pretend it's EAGAIN, only works for files and thus that option is within the file protocol [11:47:22 CET] <JEEB> well you could say that the option is already global :P [11:47:26 CET] <JEEB> since rw_timeout is already global [11:47:38 CET] <JEEB> so those protocols that support it can set it through their AVOptions [11:47:51 CET] <wbs> JEEB: it's not about the timeout, wm4 already was ok with that [11:47:55 CET] <JEEB> ah,ok [11:48:03 CET] <wm4> then just ignore me [11:48:15 CET] <wbs> he argues that the eof->egain thing should also be a generic option, not specific to file, which I say isn't a good idea [12:47:23 CET] <petru> Hi there! I have a doubt. How can I add a selftest to makefile. For example, I would like to do "make fate-display" but the display-test.* files are not generated [12:48:19 CET] <petru> Briefly, I am trying to do something like "make fate-pixelutils" [12:50:43 CET] <petru> this is to generate an executable file pixelutils-test [12:53:21 CET] <wm4> petru: we have a bunch of such tests, did you look at them? [12:56:06 CET] <petru> yeah, I added "#ifdef TEST" to display.c. I modified the tests/fate/libavutil.mak but I can't make the executable display-test [13:04:49 CET] <petru> the problem is that when I do "make diplay-test" Make throws me the following error: "No rule to make target `libavutil/display-test', needed by `fate-display'". Do you know which Makefile I need to modify to make "display-test"? [13:05:06 CET] <nevcairiel> libavutil/Makefile probably [13:05:32 CET] <petru> ok, I will take a look. Thanks :) [13:08:39 CET] <nevcairiel> generally the makefile in the directory the file is in is responsible for it [13:12:26 CET] <petru> Yes, you were right. I needed to add to make the "display" executable. Thanks for your help :) [13:35:34 CET] <jkqxz> nevcairiel: I didn't pursue further than observing the failure in ff_hevc_split_packet() and fixing it there. (I was hoping the bug would be more interesting than that, tbh.) [13:40:19 CET] <wm4> there are plenty of interesting bugs to pick from [13:42:14 CET] <jkqxz> It would probably be worth having a stream full of zeroes as a FATE test; maybe I'll have a go at handcrafting something nasty. (For H.264 at least you could just use intra4x4 vertical without cabac everywhere and the stream would be full of emulation prevention.) [13:42:53 CET] <nevcairiel> well zeros within the NALs are supposed to be escaped and shouldnt be a problem, but those zeros are part of the AnnexB syntax and not escaped [13:44:44 CET] <nevcairiel> strictly speaking just skipping zeros is more correct, but on the other hand the rbsp parser would consider any non-zeros to be part of the NAL anyway, unless they are preceeded by zeros again =p [13:46:01 CET] <nevcairiel> it seems harmless to downgrade the error to a warning if it could extract some valid NALs, to me anyway [13:46:17 CET] <jkqxz> So a new patch which just changes the return to only be an error if pkt->nb_nals == 0? [13:47:11 CET] <nevcairiel> some day i should make it use the optimized start code finding function [13:47:58 CET] <nevcairiel> but yes, thats what I would suggest [15:21:12 CET] <cone-092> ffmpeg 03James Almer 07master:626b6b769ced: libwebpenc_animencoder: zero initialize the WebPAnimEncoderOptions struct [15:21:12 CET] <cone-092> ffmpeg 03James Almer 07master:f875ba48739f: libwebpenc_animencoder: print library messages in verbose log levels [15:47:38 CET] <Daemon404> hmm [15:47:45 CET] <Daemon404> erankor is not on irc, correct? [15:47:49 CET] <Daemon404> (the cenc guy) [16:22:02 CET] <JEEB> Daemon404: I don't think he is [16:29:54 CET] <mohak> Hi everyone, I'm Mohak. I was interested in two of ffmpeg's gsoc projects. I know I"m a little late; but I hope to submit a good proposal before the deadline with a little guidance. [16:31:31 CET] <durandal_170> proposal is void without completed qualification task [16:37:01 CET] <mohak> Right. I just wanted a little help choosing from the 2 projects and then start working on the qualification task. Is it ok to ask my questions over irc or should I instead use the mailing list? [16:37:12 CET] <mohak> Sorry. I'm a bit new to irc. [16:37:37 CET] <durandal_170> you can ask on both [16:38:27 CET] <durandal_170> you will get answer if mentor for project is available on irc [16:42:53 CET] <mohak> Alright. In that case I should probably use the mailing list or directly email the mentors assigned to those projects. Thanks durandal_170! [17:00:20 CET] <cone-092> ffmpeg 03Michael Niedermayer 07master:7660c135a30e: avformat/segment: Fix "occured" typo [17:00:21 CET] <cone-092> ffmpeg 03Michael Niedermayer 07master:83df0a84a99d: avcodec/motion_est_template: Fix map cache use in qpel_motion_search() [17:38:11 CET] <cone-092> ffmpeg 03James Almer 07release/2.7:c5e12dc10de8: libwebpenc_animencoder: zero initialize the WebPAnimEncoderOptions struct [17:38:12 CET] <cone-092> ffmpeg 03James Almer 07release/2.7:d2161b8a6daf: libwebpenc_animencoder: print library messages in verbose log levels [17:38:13 CET] <cone-092> ffmpeg 03James Almer 07release/2.8:76c157cfd754: libwebpenc_animencoder: zero initialize the WebPAnimEncoderOptions struct [17:38:14 CET] <cone-092> ffmpeg 03James Almer 07release/2.8:175110a04128: libwebpenc_animencoder: print library messages in verbose log levels [17:38:15 CET] <cone-092> ffmpeg 03James Almer 07release/3.0:20d89a3a3271: libwebpenc_animencoder: zero initialize the WebPAnimEncoderOptions struct [17:38:16 CET] <cone-092> ffmpeg 03James Almer 07release/3.0:373bc77a356a: libwebpenc_animencoder: print library messages in verbose log levels [18:04:21 CET] <Compn> mohak : well you can ask here too [18:04:26 CET] <Compn> what projects were you interested in ? [18:06:09 CET] <mohak> Oh, ok. I'm interested in 1. MPEG-4 Audio Lossless Coding (ALS) encoder and 2. Improve the tee muxer [18:13:23 CET] <Compn> mohak : do you have any experience with rice or other algorithms needed for writing an als encoder ? [18:13:44 CET] <Compn> i think atomnuker knows about the als encoder project. its going to be very very difficult [18:25:09 CET] <mohak> No I do not. I thought the major part of the project would be porting the existing encoder at https://github.com/justinruggles/FFmpeg-alsenc. [18:30:25 CET] <Daemon404> thats very incomplete isnt it [18:39:30 CET] <wm4> rcombs: someone asking about hw encoding on RPI, maybe you could link him your old patch or so? http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/191672.html [18:39:58 CET] <rcombs> I don't even know where the old stuff is, and my current branch is very broken [18:40:28 CET] <wm4> yeah, thought it'd be something like this [18:41:23 CET] <wm4> wait why does this guy have a gcc.gnu.org email address [18:53:25 CET] <kierank> time to quickly shoot down that gsoc project [18:53:37 CET] <kierank> before certain people approve it [19:23:45 CET] <jamrial> kierank: i agree with you, but you should at least give a reason when you shoot it down. either the student or someone else will inevitably ask for one [19:24:28 CET] <Daemon404> Hi, [19:24:30 CET] <Daemon404> Get bent. [19:24:33 CET] <Daemon404> - Derek [19:24:35 CET] Action: Daemon404 runs [19:31:27 CET] <durandal_170> what happened? [19:55:11 CET] <Compn> durandal_170 : new project idea from student. [19:55:34 CET] <Compn> why would you need a mouse control using camera + hand signals on a touchscreen android phone ? [19:56:06 CET] <Compn> samsung has 'air gestures' so maybe this would be an open source version of that [19:56:14 CET] <atomnuker> because the last person who tried it obviously did it badly [19:56:43 CET] <atomnuker> or probably did not realize it's a crappy input mechanism [19:57:08 CET] <Compn> although i dont use air gestures. [19:57:30 CET] <Compn> cant even get my phone screen to go on or off when it auto dims to take a phone call [19:57:40 CET] <Compn> i am not good with computer how did i get here [19:59:41 CET] <Compn> oh i guess the air gesture uses proximity sensor, not camera. my bad. [20:01:22 CET] <TD-Linux> it's also been implemented 1000 times with OpenCV by this point [20:02:52 CET] <phh> Compn: well rather than android phones, on Android TV [20:03:10 CET] <TD-Linux> including by gstreamer [20:03:23 CET] <Compn> so then basically 'kinect' [20:03:58 CET] <phh> I think kinect is a bit too short range for that [20:06:57 CET] <wm4> gstreamer implements mouse gestures? [20:15:31 CET] <Compn> mouse gestures are useful in web browsing. dunno about hand > mouse gestures [20:16:11 CET] <Compn> e.g. hold left click then hit right click means go forwards. hold right and click left goes back. [20:16:47 CET] <Compn> never got into voice control, although i've tried it [20:16:55 CET] <Compn> aside from voice google searches [20:17:16 CET] <Compn> anyone use voice control on computer ? [20:25:58 CET] <TD-Linux> wm4, well, it's more of an example of how to make opencv based gstreamer plugins [00:00:00 CET] --- Fri Mar 18 2016

1 0

ffmpeg.log.20160317
by burek 18 Mar '16

18 Mar '16

[00:29:59 CET] <axc1298> furq: i don't know bash. i think something's wrong with line 1 https://paste.debian.net/416145 [00:30:15 CET] <axc1298> for anyone [00:31:29 CET] <axc1298> also would be nice if i can put a few different video formats in there, like avi, mkv, mp4 [00:31:46 CET] <furq> put done at the end [00:33:34 CET] <axc1298> i'm getting 'no such file or directory' when i run the script. [00:33:45 CET] <axc1298> it doesn't need any arguments does it? [00:36:40 CET] <axc1298> oh got it now [00:37:02 CET] <axc1298> it does end with .webm no such file or directory. but does work and list the resolutions now [00:37:40 CET] <petecouture> Does anyone have any good SDP examples when using RTP for the input? I'm able to get the video fine but the audio sounds horrible. It's supposed to be 22k but ffmpeg says it's running at 4kbs [01:02:14 CET] <furq> is there any reason to use librtmp over ffmpeg's native rtmp support [01:09:25 CET] <petecouture> I dunno for rtmp but for licensing issues I have to use native aac over libfaac [01:11:44 CET] <c_14> petecouture: https://pb.c-14.de/t/kng.CCYLVM ? [01:11:49 CET] <c_14> furq: whichever you think has less bugs [01:14:28 CET] <petecouture> c_14: Thank you. *sigh* I don't know SDP at all and it's such a pain. [01:30:26 CET] <petecouture> Would anyone have any advice on encoding RTP audio into ffmpeg to a different format. http://pastebin.com/wnxVgPdA [01:31:00 CET] <petecouture> The audio is being recorded at a huge rate. Like 5 seconds shows up as a minute in the ffmpeg [01:31:02 CET] <petecouture> size= 9kB time=00:02:00.13 bitrate= 0.6kbits/s [01:32:23 CET] <petecouture> It's also just pure white noise [01:33:13 CET] <TD-Linux> ew, 22kbps mp3 [01:33:23 CET] <TD-Linux> I assume ffmpeg is picking up the opus stream? [01:33:52 CET] <DHE> might want to use ffprobe to analyze the file. see what it thinks about it and whether it's correct or not [01:34:05 CET] <petecouture> no [01:34:20 CET] <petecouture> it's picking up the pcm stream [01:34:43 CET] <petecouture> This rtp stream is being provided by a Kurento server which transcodes it from webrtc [01:34:52 CET] <TD-Linux> that's unfortunate, the pcm stream is the worst quality of the offers [01:34:57 CET] <petecouture> the 22kbs was just a test. [01:35:10 CET] <TD-Linux> err wait there is a 48khz and 8khz pcm stream [01:35:18 CET] <petecouture> Hmm the response offer shows it would accept opus [01:35:53 CET] <petecouture> My understanding of SDP is you can list all options and the server/client chooses the best one [01:35:57 CET] <TD-Linux> I guess the 48khz pcm stream is the highest quality, assuming the source is mono and you have a lot of bandwidth :) [01:36:13 CET] <TD-Linux> yeah that's basically correct [01:38:07 CET] <TD-Linux> can you paste the full ffmpeg output [01:39:01 CET] <petecouture> Sure [01:39:29 CET] <petecouture> I GOT IT [01:39:30 CET] <petecouture> Lol [01:39:37 CET] <petecouture> For some reason you reminded me of opus [01:39:44 CET] <petecouture> so I removed the PCMU codec from the list [01:39:48 CET] <petecouture> and it works on opus!!! [01:40:12 CET] <TD-Linux> petecouture, also fwiw I don't think the VP8 stream should be listed in the m=audio line in that SDP... [01:41:11 CET] <petecouture> TD-Linux: Ya it was just there for testing. Right now there's two encoders running webrtc to rtp to hls [01:41:24 CET] <petecouture> I'm trying to passthrough the webrtc directly to ffmpet [01:41:37 CET] <petecouture> ffmpeg, so the media doesn't need to be encoded [01:42:51 CET] <TD-Linux> yeah, opus is likely what the webrtc source is sending [01:43:10 CET] <TD-Linux> in theory the PCM ones should work too, dunno if it's kurento or ffmpeg's fault [01:44:25 CET] <petecouture> Lol TD-Linux: right this is like almost 5 days of trying to figure it out. Some sort of bug is what i'm thinking as far as PCMU [04:04:41 CET] <moli_> hello, could someone please rewrite this command to ffmpeg? >>> mencoder "$1" -srate 44100 -af resample=44100:0:1,format=s16le -oac mp3lame -lameopts cbr:br=128 -ovc lavc -lavcopts vcodec=mpeg4:vqscale=3:vmax_b_frames=0:keyint=15 -ofps 20 -noskiplimit -vf pp=li,expand=:::::224/176,scale=224:176 -ffourcc DX50 -o "$1".fuze.premux [04:05:37 CET] <rrauzy> whoever helps moli_ also, can I see a command that can go through an mp4 format h.264 encoded video, and tell me the pict_type for each frame? (IE: I, P, B) [04:05:55 CET] <rrauzy> I just want to iterate over all frames and gather the pict type (I, P, B) [04:06:24 CET] <rrauzy> for each [04:07:03 CET] <relaxed> rrauzy: maybe ffprobe's -show_frames [04:07:50 CET] <rrauzy> relaxed: This is good advice, but show_frames is giving me the audio data in addition to the frame data, and it doesn't seem to give me the pict_type for all frames, everything seems jumbled and disorganized. [04:08:04 CET] <c_14> -select_streams v [04:08:05 CET] <rrauzy> that was my first thought [04:08:13 CET] <J_Darnley> moli_: rewritten and made better: ffmpeg -i INPUT -acodec aac -ab 128k -vcodec libx264 -crf 18 output.mp4 [04:08:27 CET] <relaxed> rrauzy: you can isolate a specific stream with ffprobe [04:08:28 CET] <c_14> -show_entries frame=pict_type [04:08:40 CET] <c_14> ^those were both for rrauzy [04:09:39 CET] <moli_> @J_Darnley: this is missing many options from the original. e.g. keyframes interval. It must be the exact same, otherwise the device will not play it. [04:10:16 CET] <J_Darnley> Then read the manual if you want to make shit [04:10:42 CET] <moli_> @J_Darnley: ok, thank you for the advice [04:10:52 CET] <rrauzy> c_14, thanks [04:12:51 CET] <moli_> could someone other please rewrite this command to ffmpeg? it must be the exact same conversion. i've read the manual, still came here to ask for your kind help >>> mencoder "$1" -srate 44100 -af resample=44100:0:1,format=s16le -oac mp3lame -lameopts cbr:br=128 -ovc lavc -lavcopts vcodec=mpeg4:vqscale=3:vmax_b_frames=0:keyint=15 -ofps 20 -noskiplimit -vf pp=li,expand=:::::224/176,scale=224:176 -ffourcc DX50 -o "$1".fuze.premux [04:16:12 CET] <relaxed> moli_: something like, ffmpeg -i INPUT -c:a libmp3lame -b:a 128k -r:a 44100 -vf <#video filters here#> -c:v mpeg4 -q:v 3 -bf 0 -keyint_min 15 -vtag DX50 output.avi [04:16:59 CET] <relaxed> moli_: https://trac.ffmpeg.org/wiki/FilteringGuide [04:19:47 CET] <moli_> thank you [04:19:56 CET] <moli_> how do i do -af format=s16le ? [04:20:14 CET] <moli_> little indian 16 bit of the audio [04:20:29 CET] <moli_> *endian [04:20:53 CET] <J_Darnley> You're using mp3 not pcm [04:21:50 CET] <moli_> yes, i know, still [04:21:54 CET] <J_Darnley> It will transformed into float by lame then frequency transformed resulting in the original sample format being meaningless [04:22:43 CET] <moli_> meaningless to every decoder in the world, except this one device i need this for, unfortunatelly [04:23:35 CET] <rrauzy> is the pts an accurate representation of frame order? [04:23:42 CET] <J_Darnley> Wow. A true AI device with psychic powers has been invented and it only plays crap avi files [04:24:56 CET] <moli_> if you are interested, for more information please see http://web.archive.org/web/20100304081211/http://forums.sandisk.com/sansa/b… [04:25:26 CET] <furq> i wonder if i still have the script i wrote to encode video for my sansa fuze [04:25:34 CET] <furq> i probably threw it away after i installed rockbox on it [04:25:58 CET] <furq> i'm pretty certain the input samplerate doesn't make a difference though [04:26:16 CET] <furq> s/rate/format/ [04:27:17 CET] <c_14> rrauzy: frames are played in order of increasing PTS [04:27:37 CET] <rrauzy> ok [04:27:44 CET] <rrauzy> thanks c_14 [04:29:57 CET] <moli_> @furq input sample format? isnt -af format is specifying the output? [04:31:05 CET] <furq> i've never used mencoder but s16le is meaningless for mp3 [04:32:15 CET] <furq> so i assume that's either being ignored or happening before it gets to the encoder to work around some unrelated issue [04:32:28 CET] <c_14> it happens before it gets to the encoder [04:32:56 CET] <c_14> In the worst case the format gets changed twice, in the best case it does nothing in the sense that the filter would have been inserted automatically because libmp3lame wants input in that format anyway. [04:33:07 CET] <furq> yeah you can safely ignore that [04:33:30 CET] <furq> the only thing you need to add to relaxed's command is -vf scale=224:176 [04:33:38 CET] <moli_> theoretically yes, but it is mentioned in multiple solutions, and judging by the work took to make this shitfuze work, maybe it is needed. I am ready to test it out without that one parameter [04:33:53 CET] <furq> it should encode quickly anyway [04:34:12 CET] <moli_> is this only (and only) resizes the video? -vf pp=li,expand=:::::224/176,scale=224:176 [04:34:21 CET] <furq> moli_: like i said, i assume it's working around some issue with mencoder [04:35:14 CET] <c_14> you should be able to copy the vf line as is (probably) [04:35:38 CET] <c_14> hmm, there's no expand filter [04:35:51 CET] <c_14> Don't even know what that one would do [04:35:54 CET] <moli_> i am asking because maybe i've got a better vf line >>> -filter:v "scale=iw*min(224/iw\,176/ih):ih*min(224/iw\,176/ih), pad=224:176:(224-iw*min(224/iw\,176/ih))/2:(176-ih*min(224/iw\,176/ih))/2" [04:36:14 CET] <furq> sure [04:36:22 CET] <furq> pp=li doesn't seem to do much of value [04:36:39 CET] <furq> i assume expand is there to preserve the ar [04:36:54 CET] <furq> but the only bit which matters to the player is scale=224:176 [04:37:38 CET] <c_14> Well, it _might_ need progressive video in which case you could add yadif [04:37:55 CET] <c_14> iff the input is interlaced [04:39:03 CET] <moli_> what does this do? harddup [04:41:28 CET] <furq> It is important that you use harddup as the last filter: it will force MEncoder to write every frame (even duplicate ones) in the output. [04:41:31 CET] <furq> wow mencoder is dumb [04:41:58 CET] <moli_> what is the difference between -deinterlace and -filter:v yadif ? the used algorithm? [04:42:31 CET] <c_14> -deinterlace is deprecated [04:42:37 CET] <c_14> (it just inserts yadif now) [04:43:03 CET] <moli_> so harddup is the same as -noskiplimit [04:44:03 CET] <moli_> then looks like it is all translated. >>> ffmpeg -i "$1" -f avi -vtag DX50 -c:v mpeg4 -q:v 3 -bf 0 -keyint_min 15 -filter:v "scale=iw*min(224/iw\,176/ih):ih*min(224/iw\,176/ih), pad=224:176:(224-iw*min(224/iw\,176/ih))/2:(176-ih*min(224/iw\,176/ih))/2, yadif" -r 20 -vb 700k -minrate 700k -maxrate 700k -c:a libmp3lame -ac 2 -r:a 44100 -b:a 128k "${1%.*}.fuze.premux" [04:44:23 CET] <moli_> could it be maybe rewriten to a better syntax? like the -ac and the -vb parameters [04:45:18 CET] <c_14> You can replace -vb with -b:v, but it's fine as is [04:45:49 CET] <moli_> why use both b:v and minrate,maxrate ? [04:46:45 CET] <c_14> It enforces some constraints [04:46:54 CET] <furq> moli_: i'm pretty sure you want -g 15, not -keyint_min 15 [04:52:54 CET] <moli_> i am running it, the console is littered with Past duration 0.619987 too large [04:54:17 CET] <moli_> nevermind [04:54:35 CET] <moli_> googled it, -filter:v "fps=20, helped for me too [04:58:10 CET] <furq> that's exactly what -r 20 does [04:59:14 CET] <c_14> If you add more than one filterchain the last filterchain will overwrite the previous ones [04:59:34 CET] <c_14> ie in this case your scale won't take effect [04:59:45 CET] <c_14> (assuming the -filter:v is after the -vf) [04:59:54 CET] <c_14> If you put it in front of it, nothing changed [05:00:37 CET] <moli_> the command now is >>> ffmpeg -i "$1" -f avi -vtag DX50 -c:v mpeg4 -q:v 3 -filter:v "yadif, fps=20, scale=iw*min(224/iw\,176/ih):ih*min(224/iw\,176/ih), pad=224:176:(224-iw*min(224/iw\,176/ih))/2:(176-ih*min(224/iw\,176/ih))/2" -r 20 -bf 0 -g 15 -b:v 700k -minrate 700k -maxrate 700k -c:a libmp3lame -ac 2 -r:a 44100 -b:a 128k "${1%.*}.fuze.premux" [05:00:59 CET] <c_14> Ah, that's fine then [05:01:11 CET] <moli_> all video filters are in one parameter, and their order is important too, i guess, so i reordered them [05:02:08 CET] <moli_> second video is having an error """Invalid pixel aspect ratio 351/352, limit is 255/255 reducing""" but after that the console says """Stream #0:0(und): Video: 224x176 [SAR 254:255 DAR 3556:2805], SAR 351:352""" [05:02:39 CET] <moli_> looks like it still applies that pixel aspect ratio? [05:36:25 CET] <moli_> c_14 & furq thank you very much for your help and efforts. sadly it does not work [05:52:38 CET] <furq> you could always install rockbox [05:52:49 CET] <furq> that's a bit drastic but the stock firmware sucks anyway [05:53:58 CET] <moli_> and i cant install video4fuze gui because of the abandoned mencoder [05:55:00 CET] <moli_> i even searched for a compiled mencoder binary , despite the security flaws this holds [05:58:25 CET] <moli_> anyway thanks bye [06:19:21 CET] <petecouture> Can someone recommend the best node package to use for ffmpeg [06:19:35 CET] <petecouture> I tried fluent-ffmpeg but it's having issues with rtp based input [07:53:57 CET] <thebombzen> haha reading above. reminds me how awful it was to work with mencoder [11:38:01 CET] <AndrewMock> How do I calculate the SSIM of a picture? [11:42:37 CET] <relaxed> AndrewMock: there's a ssim filter [11:49:15 CET] <AndrewMock> thx [12:40:21 CET] <tommy``> hi [12:41:00 CET] <tommy``> anyone have used blackdetect filter? [12:49:32 CET] <tommy``> i'm trying this: ffmpeg -i file.mkv -vf blackdetect=d=2:pix_th=0.00 -an -f null [but i cant understand the error] [13:14:57 CET] <zz_> Hi there [13:15:26 CET] <zz_> I'm tryiung to run the following ffmpeg: ffmpeg -re \ -i rtp://localhost:5000 \ -i rtp://localhost:5002 \ -i rtp://localhost:5004 \ -i rtp://localhost:5006 \ -map 0:0 -map 0:1 -map 0:2 -map 0:3 -map 0:4 -map 0:5 -c copy \ -f rtp_mpegts rtp://wi-006:5000 [13:16:00 CET] <zz_> it seems the command blocks at the second rtp input [13:16:23 CET] <zz_> is thre a way to receive from multiple simultaneous rtp streams? [13:19:30 CET] <zz_> nobody there? [13:30:31 CET] <zuloyd> hi [13:31:21 CET] <zuloyd> I'd like to record an rtmp stream into multiple mp4 files of 1 minute each [13:31:25 CET] <zuloyd> is this possible? [13:31:46 CET] <zuloyd> I thought about just passing a "-t 60" parameter and then starting the whole thing again and again, but then I have gaps between the videos [14:06:17 CET] <blubee> hi guys any linux users on here? [14:06:43 CET] <J_Darnley> Not a single person in the world uses Linux(!) [14:06:50 CET] <blubee> I am on debian testing, running ffmpeg with nvidia drivers I get an error; cannot open display :0.0 [14:08:13 CET] <DHE> trying nvenc or opencl encoding? [14:08:19 CET] <DHE> what exactly are you trying to do? [14:08:56 CET] <blubee> DHE: just recording the screen [14:09:22 CET] <blubee> when I purge the nvidia driver i can record desktop no problem [14:09:28 CET] <DHE> and you do have an X session open for which you have permission to connect? [14:10:16 CET] <blubee> I think so [14:10:26 CET] <blubee> this is a single user machine except for root [14:10:58 CET] <blubee> i log in, w/o the nvidia driver i can just use the ffmpeg screengrab command no problems, if I install the nvidia driver then i get the error [14:11:31 CET] <cbsrobot> ubitux: in "ffmpeg -i file.ass -c text file.srt" I see the opening <font> tag, but no closing tags - shoudn't the text encode strip all tags ? [14:15:39 CET] <blubee> here is a log file: http://pastebin.com/TuKjLcJd [14:39:42 CET] <tommy``> guys which gui i can use with ffmpeg? [14:47:25 CET] <J_Darnley> What OS are you on and what exactly do you want to do? [14:48:57 CET] <tommy``> win10, ineed to detect black frames and writeout on txt the timing [14:50:12 CET] <Mavrik> Good luck? :) [14:50:26 CET] <J_Darnley> I can't think of any gui that will let you do that [14:50:44 CET] <J_Darnley> Partly because I'm not sure what that means [14:50:55 CET] <tommy``> https://ffmpeg.org/ffmpeg-filters.html#blackdetect [14:50:56 CET] <tommy``> this [14:52:08 CET] <J_Darnley> ah okay [14:52:16 CET] <J_Darnley> Still no [14:55:02 CET] <tommy``> J_Darnley: is this any sense: ffmpeg -i file.mkv -vf blackdetect=d=2:pix_th=0.00 -f null out [14:55:38 CET] <J_Darnley> Yes but substitute out for NUL (a special Windows filename) [14:56:32 CET] <tommy``> speed is 2x very slow.... [14:58:01 CET] <J_Darnley> Well it won't be fast checking every pixel [14:58:36 CET] <J_Darnley> Perhaps you should stop it and put the whole output on pastebin [14:59:07 CET] <tommy``> frame= 2651 fps= 69 q=-0.0 size=N/A time=00:01:46.12 bitrate=N/A speed=2.78x <------ [15:05:55 CET] <tommy``> J_Darnley: my pc is crap to do this work [15:23:22 CET] <zz_> I'm tryiung to run the following ffmpeg: ffmpeg -re -i rtp://localhost:5000 -i rtp://localhost:5002 -i rtp://localhost:5004 -i rtp://localhost:5006 -map 0:0 -map 0:1 -map 0:2 -map 0:3 -map 0:4 -map 0:5 -c copy -f rtp_mpegts rtp://wi-006:5000 [15:24:03 CET] <zz_> it seems the command blocks at the second rtp input. Is there a way to receive from multiple simultaneous rtp streams? [15:32:31 CET] <zz_> Also, does anyone know why using rtp in output seem to allocate two udp ports instead of just one? [15:33:41 CET] <jkqxz> The second port is n+1, for RTCP? [15:33:54 CET] <zz_> the second port seem to be +1 [15:33:57 CET] <zz_> yes [15:34:06 CET] <zz_> what do you mean for RTCP? [15:34:41 CET] <zz_> it's a second UDP port, not a TCP one [15:38:35 CET] <jkqxz> Yes. An RTP stream uses two UDP ports: port n for the RTP data packets and port n+1 for the RTCP control packets. [15:39:19 CET] <zz_> ok. thanks [15:39:41 CET] <zz_> i will search for RTCP control packets in the documentation [15:39:55 CET] <zz_> Do you happen to know about my other question? [15:40:04 CET] <zz_> Do you happen to know something about my other question? [15:41:15 CET] <kepstin> if it's blocking during startup, that usually means that the stream probing is blocking - could mean that nothing's being received on one of the ports? [15:41:45 CET] <zz_> i have another ffmpeg running on the same machine that is sending the rtp streams [15:42:55 CET] <zz_> ffmpeg -re -i mnt/Archive/Rio\ 2014/matches/Main/match_61.ts -map 0:0 -map 0:1 -map 0:2 -c copy -f rtp_mpegts rtp://localhost:5000 [15:43:13 CET] <zz_> ffmpeg -re -i mnt/Archive/Rio\ 2014/matches/Main/match_61.ts -map 0:3 -c copy -f rtp_mpegts rtp://localhost:5002 [15:43:22 CET] <zz_> I have 4 of those [17:35:00 CET] <mindheist> Hey People .. I have been searching for videos that are considered typically hard to encode [17:35:17 CET] <mindheist> we use ffmpeg as our encoding engine in our product [17:47:06 CET] <jkqxz> mindheist: /dev/urandom? ("ffmpeg -f rawvideo -pix_fmt yuv420p -s:v 1280x720 -r 30 -i /dev/urandom ...".) [18:22:19 CET] <llogan> mindheist: "parkrun" https://media.xiph.org/video/derf/ [18:24:10 CET] <zz_> increasing the -thread_queue_size parameter improves the situation, but the muxing ffmpeg still msses lots of packets [18:52:03 CET] <mindheist> hmmm .. Thanks [18:52:24 CET] <mindheist> But I was looking for more of a database of videos that I could use to test [19:03:24 CET] <J_Darnley> Well as said, parkrun is hard, as is: parkjoy, crowdrun, a section in big buck bunny and another in elephants dream [19:03:40 CET] <J_Darnley> crew is firly noisy [19:03:44 CET] <J_Darnley> *fairly [19:03:50 CET] <J_Darnley> city has many hard edges [19:04:07 CET] <J_Darnley> (and these are just the ones I've seen) [19:04:14 CET] <furq> just record some quakeworld demos [19:30:31 CET] <petecout_> Regarding HLS encoding, has anyone done mid-stream ID3 tag injection over the course of a live stream? I've found documentation to do it pre-stream. http://jonhall.info/how_to/create_id3_tags_using_ffmpeg [19:43:21 CET] <kepstin> that doesn't make sense; HLS uses mpeg-ts streams which shouldn't contain ID3, and no software would use it if it did. [19:43:46 CET] <kepstin> if anything, the info should be put into the playlist (although I'm not sure if this is supported), or just communicated out of band. [20:33:53 CET] <srg2> I'm trying to convert an mp3 file to an mp4. I tried `ffmpeg -i file.mp3 file.mp4`, but it didn't work. Log is here: https://gist.github.com/srguglielmo/d0ca79ddba60aeee586a Anyone know how I can do this? [20:34:17 CET] <srg2> I don't mind a blank video, but if possible, I'd like to include a still image. But that's not too important. [20:37:16 CET] <llogan> get a newer ffmpeg from here: http://johnvansickle.com/ffmpeg/ [20:37:23 CET] <furq> [aac @ 0xebb860] The encoder 'aac' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it. [20:37:30 CET] <furq> do what that error says, or preferably do what llogan says [20:38:20 CET] <llogan> then do: ffmpeg -loop 1 -framerate 5 -i image -i music.mp3 -c:v libx264 -c:a aac -pix_fmt yuv420p -movflags +faststart -shortest output.mp4 [20:38:33 CET] <srg2> What is that error in reference to? Is the mp3 using aac somehow? [20:38:48 CET] <furq> oh nvm [20:38:53 CET] <furq> mp4 defaults to aac if you don't specify [20:38:59 CET] <srg2> ahh [20:39:00 CET] <furq> add -c copy to keep the mp3 [20:39:43 CET] <furq> or if you want an image, use llogan's command but replace -c:a aac with -c:a copy [20:40:49 CET] <srg2> thanks! [21:06:32 CET] <srg2> -c:v libx264 encodes the image into a video using x264, right? [21:06:44 CET] <srg2> I don't think this program I'm using likes x264. is there a more common codec? [21:09:56 CET] <vith> can i use drawtext to overlay the scene detection value onto each frame? i tried -filter_complex "drawtext=text='test %{scene}'" but got %{scene} is not known. my actual goal here is just finding a way to tune the similarity parameter to -vf "select=gt(scene\,0.01)" [21:55:43 CET] <axc1298> anyone know how i can modify this to add the following: "ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 input.mp4" (i would need to replace the input.mp4 part). https://pastebin.mozilla.org/8864131 [21:57:14 CET] <axc1298> since i have $f as the filename. would i need another eval line for duration, and then a duration= line? [22:16:40 CET] <ubitux> cbsrobot: sample? [22:17:06 CET] <ubitux> maybe the font tag wasn't recognized and so was simply copied [22:24:35 CET] <llogan> axc1298: ffprobe -v error -of flat=s=_ -select_streams v:0 -show_entries stream=height,width:format=duration "$f" [22:24:49 CET] <llogan> echo "$format_duration" [22:39:24 CET] <axc1298> thanks llogan [22:48:56 CET] <petecout_> kepstin: Sorry for the late reply. Was grabbing lunch. My understanding is mpeg-ts does support ID3 tags. https://en.wikipedia.org/wiki/ID3 https://en.wikipedia.org/wiki/MPEG_transport_stream [23:02:42 CET] <kepstin> petecout_: huh, that's interesting. so they don't have it in the mp3 stream itself, they're rather sending it as a special metadata packet in the mpeg-ts. I haven't seen anything in ffmpeg to handle that (not saying it's not there, but I suspect it isn't). [23:25:15 CET] <nadermx> I asked a question earlier here regarding multithreading with lame, was told it could not be done. What was suggested was to concat the files. Would that be possible from a youtube dash url? So for example ffmpeg -f concat -i "youtubeurl" -acodec libmp3lame -f mp3 - [23:26:04 CET] <nadermx> Since it seems ffmpeg with larger files (over 10 mins) just cuts it off around that time, not sure if its because of the ffserver [23:26:53 CET] <J_Darnley> The concat demuxer reads a plain text file listing files to read. [23:27:15 CET] <J_Darnley> It isn'y going to parse an html page for you. [23:28:52 CET] <J_Darnley> Or am I not understanding your question properly [23:29:35 CET] <nadermx> I'm inputting the url that youtube-dl gives for the stream from youtube [23:29:53 CET] <nadermx> it works fine if its the only song the server is doing, but if its doing multiple songs it cuts them off after a bit [23:30:24 CET] <nadermx> with larger files [23:30:28 CET] <nadermx> err songs/vids [23:31:44 CET] <nadermx> so if i put a contact of multiple lines of the url would that be a work around? [23:32:01 CET] <J_Darnley> No idea. [23:41:37 CET] <axc1298> llogan: is ":" used as a separator. so i have "stream=height,width:format=duration" and if i want to add frame rate, can i just do "stream=height,width:format=duration:avg_frame_rate"" [23:58:45 CET] <nadermx> another question, i see the buffer can be set for video, can it be done just for audio? I think what might be happening is that its getting the data faster than it can convert it so it drops at some point [00:00:00 CET] --- Fri Mar 18 2016

1 0

ffmpeg-devel.log.20160316
by burek 17 Mar '16

17 Mar '16

[00:38:02 CET] <Daemon404> atomnuker, one reply from ganesh is directed at you [00:38:08 CET] <Daemon404> in case you wish to answer [01:07:30 CET] <kierank> llogan: it is on github now [01:07:35 CET] <kierank> ah y ou said [01:07:38 CET] <kierank> been there for a while [01:46:29 CET] <kierank> wm4: I have many many lavfi misunderstandings [02:11:21 CET] <kierank> wm4: so yeah I asked my lavfi questions [02:11:24 CET] <kierank> I have no idea how you made it work [02:20:37 CET] <llogan> durandal_170: using optipng on the PNG images for the wiki can reduce the size significantly [04:07:32 CET] <cone-229> ffmpeg 03Thomas Mundt 07master:d0a9114f9911: avfilter/vf_bwdif: Add yadif base information to copyright header [09:21:43 CET] <cone-229> ffmpeg 030smail Dönmez 07master:fa3eecf9ab6e: configure: Use lowercase includes/library names for schannel check. [09:30:27 CET] <mateo`> seriously mats is starting to getting on my nerves [09:43:12 CET] <wm4> mateo`: most people's nerves areaffected [09:44:32 CET] <mateo`> i'm not even directly concerned but when i see how he responds to people ... [09:47:08 CET] <wm4> kierank: well, my code has no problems with lots of buffering [10:16:11 CET] <thardin> mats seems to need to learn to enhance his calm [10:16:36 CET] <nevcairiel> i wonder if mailman has a shadowban feature [10:16:45 CET] <nevcairiel> just swallow his mails without telling him [10:17:39 CET] <thardin> that'd be an interesting feature [10:19:50 CET] <ubitux> yeah the shadowban should is probably a good idea [10:20:00 CET] <ubitux> he won't realize anytime soon anyway, he's mostly talking to himself [10:25:12 CET] <petru> Hi there! My name is Petru and I am an undergraduate computer science student. I would like to apply to "Improve Selftest coverage" project [10:26:54 CET] <petru> Now I am trying to understand how tests work and how to implement one. I have read this wiki: http://trac.ffmpeg.org/wiki/FATE/AddingATest but it isn't complete [10:26:59 CET] <cehoyos> Hi, first step is to compile FFmpeg and run fate [10:27:05 CET] <petru> I did [10:27:33 CET] <cehoyos> How did you identify the part of code for which you want to add a test? [10:28:00 CET] <petru> With #ifdef TEST [10:28:11 CET] <cehoyos> No / I don't understand... [10:28:37 CET] <cehoyos> You have to use your favorite profiling tool now to be able to know which part of FFmpeg source code is not covered by fate yet. [10:29:02 CET] <ubitux> or just go to coverage.ffmpeg.org [10:29:10 CET] <cehoyos> I may never have used it myself, but "gprof" is one example. [10:29:16 CET] <cehoyos> Or you go the easy way;-) [10:29:34 CET] <ubitux> you can generate that with gcov toolchain (see configure) [10:29:44 CET] <petru> OK, thanks [10:32:51 CET] <petru> But I would like to see how one test is implemented from start to end. For example "fate-imc" test that is from audio.mak. I don't find the code for this test [10:33:44 CET] <ubitux> CMD = pcm [10:33:51 CET] <ubitux> try git grep 'pcm()' [10:34:09 CET] <nevcairiel> thats probably in regression-funcs.mak or whatever the filename was [10:34:28 CET] <nevcairiel> regression-funcs.sh [10:34:28 CET] <nevcairiel> :) [10:34:36 CET] <petru> ahhhhh [10:34:41 CET] <ubitux> fate-run.sh according to git grep [10:34:44 CET] <petru> Thanks :) [10:34:54 CET] <nevcairiel> ah yeah, fate-run.sh which includes the regression funcs file [10:35:18 CET] <nevcairiel> the fate system is a bit hard to navigate at first [10:36:09 CET] <petru> for a newbie like me yes [10:37:17 CET] <petru> thank you for your help :) [10:44:27 CET] <cone-229> ffmpeg 03Hendrik Leppkes 07master:0d4b8a2c163b: hls: read protocol options through the AVIOContext [10:44:28 CET] <cone-229> ffmpeg 03Hendrik Leppkes 07master:eae2d89bf715: hls: handle crypto in the protocol checks [10:46:03 CET] <BtbN> So Mats says that he is uable to use git propperly, ad expects other people to do that work for him? oÒ [10:46:32 CET] <BtbN> Ad why does my N key Not work for NoN-Capital N aNymore? [10:57:28 CET] <nevcairiel> that is one crazy keyboard failure [11:02:36 CET] <thardin> hm, what to do about that shitty mxf file [11:02:51 CET] <nevcairiel> use the realmedia player "rm" on it [11:02:54 CET] <nevcairiel> it can handle anything [11:04:06 CET] <thardin> that's less optimal than my initial pass at a "solution". I think I'll have to interrogate the user a bit [11:13:40 CET] <cehoyos> thardin: Are you talking about the ticket I tried to fix? [11:15:25 CET] <thardin> yes. these things tend to need digging [11:16:23 CET] <cehoyos> Is my analysis correct? Does the header specify another trac number than the actual frames? [11:16:31 CET] <thardin> yes, as fas as I can tell [11:16:43 CET] <cehoyos> Or is there another possibility to assign the frames to a track? [11:17:13 CET] <thardin> no, you use the lower 4 bytes of the key in the SourceTrack (or MaterialTrack, I forget which) [11:17:29 CET] <cehoyos> And what other information does the frame offer? [11:17:37 CET] <thardin> and mxf is hairy enough as it is without incorporating hacks to mirror hacks in other decoders [11:17:41 CET] <cehoyos> Does it say if it's audio or video? Or anything else? [11:18:04 CET] <thardin> each edit unit has a header which tells you some things [11:18:15 CET] <thardin> unless the file is clip-wrapped (opatom) [11:18:19 CET] <cehoyos> Iiuc, the track is not only identified by a number but also an id, no? [11:18:34 CET] <thardin> the ID is the number [11:18:47 CET] <thardin> parts of the number is metadata [11:19:16 CET] <thardin> like all audio tracks has one of the bytes being some predetermined value [11:19:42 CET] <thardin> the truth is in the spec and/or the mxf book [11:19:53 CET] <cehoyos> In MXFTrack, I see an ID, a number and a sequence_ref [11:20:32 CET] <cehoyos> What is a sequence ref? [11:21:18 CET] <thardin> hum-hum [11:22:44 CET] <thardin> right, you use SourceTrackID to look up TrackNumber in SourcePackage [11:23:01 CET] <thardin> basically the key is pair<SourcePackageID,SourceTrackID> [11:24:02 CET] <thardin> plus LinkedTrackID in the EssenceDescriptor for figuring out the codec specific stuff like resolution, cropping information etc [11:24:38 CET] <cehoyos> Is SourcePackage what I call the "frame"? [11:24:44 CET] <thardin> anyway, what I'm getting at is we have to ask the user (who is likely a developer) why the file has incorrect TrackNumbers [11:25:26 CET] <thardin> no. SourcePackage is more a.. it relates to a specific piece of essence [11:25:37 CET] <thardin> MaterialPackage is the "meta" [11:26:04 CET] <cehoyos> I don't think he is a developer: He says he wants to switch from Mainconcept to FFmpeg but the files do not work with FFmpeg... [11:26:05 CET] <thardin> because mxf supports different "views" of the same piece of essence [11:26:17 CET] <thardin> yes, but the files come from somewhere [11:26:30 CET] <thardin> it's not some random file they found on the internet [11:26:55 CET] <thardin> hence a better approach may be to figure out why the file is bad [11:27:46 CET] <cehoyos> Does mxflib allow to extract a track? [11:27:53 CET] <thardin> yes, you can use mxfsplit [11:27:53 CET] <cehoyos> Did you try for the file in question? [11:28:11 CET] <thardin> I didn't try mxfsplit on that specific file though [11:29:05 CET] <cehoyos> I have mxfsplit 1.0.1, what should I do with it? [11:29:32 CET] <thardin> run it on the file, see what it spits out [11:30:04 CET] <thardin> it should create one file for each essence track (aka stream) [11:30:51 CET] <cehoyos> It aborts because it wants it xml file [11:30:59 CET] <thardin> you need to make install [11:31:06 CET] <cehoyos> Do you remember how to point it to the file? [11:31:10 CET] <thardin> I get the video in a file called _0002-G15010500.Stream [11:31:14 CET] <cehoyos> I already managed once. [11:31:24 CET] <cehoyos> So we are missing something? [11:31:29 CET] <thardin> 15010500 is the track number in hex, or 352388352 in decimal [11:32:27 CET] <cehoyos> So how does mxflib map the frames to this track number? [11:32:30 CET] <thardin> whereas the header points out 15010800, meaning 352389120 [11:32:38 CET] <cehoyos> Ah, sorry. [11:32:47 CET] <thardin> mxfsplit doesn't give a hoot about the header [11:32:53 CET] <thardin> it just extract the essence [11:33:00 CET] <thardin> extracts* [11:33:20 CET] <thardin> for all it knows what the header points to might be in some other file [11:33:30 CET] <thardin> which you figure out using your MAM [11:33:45 CET] <thardin> think how .mov can point to external files [11:34:05 CET] <thardin> except with MXF you don't have filename but PackageIDs [11:35:11 CET] <thardin> so ffmpeg can never truly support MXF [11:35:31 CET] <thardin> because you need a database and all kinds of stuff [11:36:36 CET] <thardin> I'll have to write something on the ticket to try and coax some information out of the user [11:36:53 CET] <thardin> no login info on this machine though, so later this evening I suppose [11:37:20 CET] <cehoyos> I asked him something: https://trac.ffmpeg.org/ticket/5312#comment:7 [11:37:30 CET] <cehoyos> Should I add something? [11:37:51 CET] <thardin> that'll do for now. I can elaborate on it later [11:47:39 CET] <cone-229> ffmpeg 03Luca Barbato 07master:522ab0b9a929: indeo2data: K&R formatting cosmetics [11:47:40 CET] <cone-229> ffmpeg 03Luca Barbato 07master:73f3c8f73edf: indeo2: Fix banding artefacts [11:49:34 CET] <JEEB> thardin: kind of like matroska and segment UUIDs > PackageIDs [11:51:15 CET] <thardin> hooray [11:51:36 CET] <thardin> the way essence is wrapped in mxf is based on some other smpte standard. maybe SDI [11:51:46 CET] <cehoyos> You mean you found something? [11:52:13 CET] <thardin> no, just telling a bit of the history of the thing [11:52:54 CET] <nevcairiel> michaelni: you really shouldn't enable his ramblings [11:54:16 CET] <wm4> michaelni: why did you even do that [11:54:25 CET] <wm4> why not drive forward the merge [11:54:28 CET] <wm4> this is just bullshit [11:54:38 CET] <wm4> also thanks for feeding the troll [11:55:58 CET] <thardin> oh dear [11:57:00 CET] <michaelni> if a developer doesnt know how to use git, i help him and explain how to do what he wanted to do (if i have time and all...) [11:59:03 CET] <michaelni> i just pushed as i had to try it locally to check if my suggested commands work ... [11:59:29 CET] <michaelni> would have been silly to try but then discard and not push the work [12:02:04 CET] <ismail> michaelni: agreed, it was a nice change. [12:16:39 CET] <wm4> michaelni, ismail: it certainly won't improve Mats' behavior, he just got what he wanted by writing lots of annoying posts [12:16:51 CET] <wm4> instead of actually putting effort into it, or god forbid, learning some git [12:17:07 CET] <wm4> or, you know, keeping our development model a bit more chaos-free [12:17:18 CET] <wm4> (now we cherry-pick Libav commits and later merge them...?) [12:17:25 CET] <ismail> thats also true "Mats" problem has to be dealt with on a grand scale [12:18:35 CET] <kierank> wm4: write an open letter to Mats [12:20:37 CET] <cehoyos> (now we cherry-pick Libav commits and later merge them...?) <- I am not saying I disagree with your point but I believe you miss how the merges work in this sentence... [12:21:19 CET] <cehoyos> Or am I wrong? I don't know, sorry. [12:22:40 CET] <ubitux> we'll have to have a merge commit in addition to the cherry-pick to keep track of everything merged [12:22:58 CET] <ubitux> merge commit will be meta only / noop [12:26:37 CET] <wm4> cehoyos: they'll end up twice in the git history [12:26:57 CET] <ismail> ah like github's merge crap [12:27:44 CET] <wm4> uh what, that's how merges fundamentally work [12:27:45 CET] <cehoyos> When I backport regression fixes, it sometimes happens that I try to backport a patch that was already backported by somebody else, git does not error in such a case, it simply returns. I wondered if this would be a similar case. [12:28:05 CET] <ismail> wm4: yeah I know but still ugly [12:28:34 CET] <nevcairiel> if it doesnt conflict, the merge later on would just show up empty, but since this is a comination of two commits, one of those will likely conflict later in the merge and need manual fiddlery to fix [12:29:06 CET] <wm4> well even if git gracefully ignores the changes on merge, the git history will still contain the commits twice [12:29:51 CET] <ubitux> + a merge, so 3 commits [12:30:15 CET] <cehoyos> wm4: Do you still have objections over the mkv patch? [12:31:14 CET] <wm4> cehoyos: it doesn't look like a good idea, why not report it to MS instead [12:31:35 CET] <cehoyos> Report what? That our muxer writes broken files that our demuxer accepts? [12:31:36 CET] <cone-229> ffmpeg 03Matt Oliver 07master:109dfed7fc26: lavc/dxva2_h264: Fix incorrect assert statement. [12:31:40 CET] <wm4> I'm thinking maybe lavf should write no bit depth value here [12:31:43 CET] <nevcairiel> so i started to build chromium, its on a ssd with fast internet and a pretty fast cpu, I bet its still going to take hours =p [12:31:54 CET] <cehoyos> Isn't it a required tag? [12:33:15 CET] <wm4> cehoyos: where does it say this? [12:33:21 CET] <wm4> also what does mkvmerge do here? [12:33:36 CET] <cehoyos> It is not mandatory, but mkvmerge writes it, so I don't see why FFmpeg should not write it. [12:34:06 CET] <nevcairiel> but whats to gain to write it, its not like decoders would need it [12:34:19 CET] <wm4> well until now it wrote a wrong value? (or just what value does mkvmerge write here) [12:34:23 CET] <cehoyos> I thought mkvmerge is the specification nowadays, no? [12:34:33 CET] <cehoyos> Yes, we currently write a wrong value. [12:35:24 CET] <cehoyos> If the patch made no difference (because we already wrote the right value), it couldn't fix the issue... [12:36:42 CET] Action: kierank digests wm4's response [12:36:51 CET] <nevcairiel> it would help if you actually had confirmation that the patch fixes the issue [12:37:52 CET] <wm4> kierank: I'm not an expert on libavfilter, lavfi frame scheduling, or lavfi framesync though [12:38:39 CET] <wm4> oh god github is killing some more vertical space [12:38:42 CET] <cehoyos> nevcairiel: What additional confirmation do you need? [12:38:43 CET] <kierank> lavfi is totally insane [12:38:51 CET] <wm4> they now show a big header on diff views [12:38:52 CET] <cehoyos> Sorry, I don't understand what you mean. [12:39:21 CET] <wm4> nevcairiel: I think it was experimentally confirmed that wmp eats the files produced with the patch [12:39:34 CET] <JEEB> kierank: oh yes it is [12:39:55 CET] <kierank> I am genuinely considering just copying the filters into my code [12:40:28 CET] <nevcairiel> cehoyos: personally i would use a slightly different patch, without hardcoding codec ids or the like, ie http://pastebin.com/SMx5eXNL [12:40:35 CET] <kierank> "How many frames [12:40:35 CET] <kierank> you have to feed is not defined, and is determined at runtime by the [12:40:35 CET] <kierank> internal frame scheduling logic" [12:40:39 CET] <kierank> what.the.fuck [12:41:19 CET] <cehoyos> Apart from more braces imo, please push! [12:41:25 CET] <wm4> kierank: that's just how it works [12:41:48 CET] <kierank> variable latency is allowed? [12:41:50 CET] <wm4> nevcairiel: uh that also seems questionable [12:41:58 CET] <wm4> kierank: I don't see why not [12:42:21 CET] <nevcairiel> wm4: how so, bits per raw sample should generally override the bits in the storage format (ie. sample format) [12:42:52 CET] <wm4> nevcairiel: the code before that is of course worse [12:43:14 CET] <wm4> I'd argue it shouldn't write the element at all if bits_per_raw_sample is not set [12:43:33 CET] <wm4> the sample format can be pretty arbitrary [12:43:40 CET] <nevcairiel> not sure its reliably set when its equal to the storage format [12:43:43 CET] <wm4> there are fixed point and floating point encoders etc. [12:45:44 CET] <nevcairiel> kierank: if you already have a 1:1 association between main and overlay frames, maybe you should just use drawutils to blend them, and not bother with lavfi [12:45:58 CET] <wm4> drawutils isn't public [12:46:23 CET] <kierank> yes that's the problem with lavfi as far as I can tell [12:46:25 CET] <kierank> one true api [12:46:27 CET] <nevcairiel> i suppose that is why i wrote my own frame blender back then [12:47:14 CET] <kierank> wm4: variable latency is insane [12:47:25 CET] <kierank> I can understand in vfr-land it's normal [12:47:29 CET] <nevcairiel> not sure you would actually get that when just using vf_overlay [12:47:29 CET] <wm4> heh [12:47:31 CET] <kierank> but in cfr land I need fixed latencies [12:48:12 CET] <nevcairiel> lavfi in general can make no guarantees, but sometimes a simple filtergraph just happens to work a certain way [12:48:38 CET] <kierank> yes my simple scale filtergraph does what I want it to do [12:48:42 CET] <wm4> kierank: all desktop media frameworks seem to work like this though [12:48:55 CET] <wm4> and vf_overlay is a bit of a problem because of sparse vs. non-sparse [12:48:59 CET] <wm4> I guess [12:49:17 CET] <nevcairiel> 20 minutes in, its still cloning the chromium git repository [12:49:20 CET] <wm4> actually, I haven't made sure that's what happens in your case, so my entire mail might be misdirected [12:49:21 CET] Action: nevcairiel goes watch a movie [12:59:04 CET] <kierank> I guess I could send a dummy subtitle per video frame [13:03:47 CET] <nevcairiel> wm4: so should i push the bits_per_raw_sample mkv patch then? It definitely writes better values than before. And we can argue later about not writing any values in some circumstances later ;) [13:03:57 CET] <wm4> uh ok [13:04:06 CET] <wm4> it's certainly better than checking codec IDs directlx [13:04:09 CET] <wm4> *directly [13:04:14 CET] <nevcairiel> indeed [13:04:21 CET] <wm4> it's still kind of lazy [13:05:03 CET] <nevcairiel> personally i wouldnt write any values for compressed formats at all (unless they are crazy and need it), but thats just me [13:05:11 CET] <nevcairiel> would probably break a bunch of things [13:05:33 CET] <wm4> and I'd still prefer if MS were forced to fix their bug [13:06:31 CET] <nevcairiel> i suppose it uses the value to check decoding support of the stream, if we were to do that, we would also just tell them to write proper values into their files =p [13:07:45 CET] <nevcairiel> anyway can re-work this entire thing another time, accounting for bits_per_raw is a clear improvement either way, so [13:07:50 CET] <cone-229> ffmpeg 03Hendrik Leppkes 07master:c43d4858119e: matroskaenc: set the actual PCM bitdepth in the header [13:08:10 CET] <wm4> another time == never [13:14:57 CET] <cone-229> ffmpeg 03Hendrik Leppkes 07master:c198295dedd5: dxva2_h264: fix size alignment asserts [13:39:23 CET] <kierank> ubitux: is there a way of outputting bitmap subtitles to a file [13:40:46 CET] <kierank> Stream #0:2 -> #0:0 (dvb_teletext (libzvbi_teletextdec) -> ? (?)) [13:40:50 CET] <kierank> kinda useless [13:45:06 CET] <ubitux> kierank: with the cli i don't think so [13:45:16 CET] <ubitux> i did a code a while ago with the api for that [13:45:21 CET] <ubitux> that's relatively trivial [13:45:22 CET] <kierank> ok [14:01:43 CET] <cehoyos> -vcodec copy -map 0 -f rawvideo? [14:01:54 CET] <cehoyos> Sorry: -scodec copy -map 0 -f rawvideo? [14:04:21 CET] <ubitux> you can probably overlay them on a surface and save the stream too [14:04:34 CET] <ubitux> but not sure how exactly you want to output them [14:04:41 CET] <kierank> as like bmp files [14:04:56 CET] <kierank> but no big deal I guess [14:05:01 CET] <ubitux> right, but, as in "one picture for every different rectangle"? [14:05:50 CET] <ubitux> if you have a subtitle that appears for 5 seconds, do you want 5 seconds of the same bitmap, or just a single small picture of the size of the rectangle [14:21:54 CET] <kierank> single picture per sub [14:26:08 CET] <JEEB> was there any parameters that could be given to lavf which could be useful when reading files that are still being written to? [14:26:57 CET] <nevcairiel> dont think so, its not very good with such cases [14:27:01 CET] <JEEB> ok [14:27:18 CET] <JEEB> so I'll need to implement something to have it check the file size updates with a timeout [14:28:18 CET] <JEEB> ffmpeg's -re is an example of something that could go horribly wrong, for example :) [dvb subs with timestamp coming from 14 hours in the future and then ffmpeg.c trying to be 'realtime' with that] [14:40:49 CET] <Daemon404> mats is reallty getting obnoxious... [14:40:53 CET] <Daemon404> even more so [14:58:49 CET] <rcombs> I didn't know that was possible [15:01:27 CET] <Compn> we should encourage it to see the upper limits [15:01:39 CET] <Compn> from a scientific point of view. [15:17:14 CET] <nevcairiel> how do i make configure check for a presence of a define? [15:17:24 CET] <nevcairiel> i couldnt find an example [15:17:53 CET] <Daemon404> #ifndef SOMEDEF [15:17:54 CET] <Daemon404> asdgadgadgadfgsfghxgxfgb [15:17:55 CET] <Daemon404> #endif [15:18:04 CET] <nevcairiel> that doesnt sound very good [15:18:39 CET] <Daemon404> look at x264 or x265 for checking the value of a define [15:18:42 CET] <Daemon404> im sure this can be similar [15:19:22 CET] <nevcairiel> check_cpp_condition apparently [15:21:07 CET] <ubitux> nevcairiel: cpp_condition doesn't work? [15:21:43 CET] <ubitux> nevcairiel: check_cpp_condition bla.h "defined(bla)" [15:21:45 CET] <ubitux> ? [15:22:47 CET] <nevcairiel> i'm trying this now [15:26:46 CET] <nevcairiel> my system is kinda busy linking chromium though, 7gb linker memory use and climbing =p [15:28:22 CET] <Daemon404> you got chromium to build? [15:28:34 CET] <nevcairiel> apparently [15:28:37 CET] <Daemon404> last time i tried, i got their build system in some state where it just *would not* configure and build properly [15:28:38 CET] <nevcairiel> its been linking for like half an hour [15:28:44 CET] <Daemon404> even removing it entirely, left stuff [15:28:46 CET] <wm4> why are you building it at all [15:28:48 CET] <Daemon404> i think it modified the registry [15:28:58 CET] <nevcairiel> technically i'm building CEF [15:29:12 CET] <nevcairiel> i need one with h264 decoding enabled [15:29:15 CET] <Daemon404> cef? [15:29:30 CET] <wm4> https://en.wikipedia.org/wiki/Chromium_Embedded_Framework ? [15:29:36 CET] <nevcairiel> chromium embedded framework, ie. a wrapper around chromium to make it easier to use it in your app [15:29:55 CET] <wm4> sounds very useful [15:30:25 CET] <nevcairiel> all the binary distributions come without h264 decoding because muh licensing [15:31:38 CET] <cone-229> ffmpeg 03Hendrik Leppkes 07master:7d9e064cc13c: configure: check for SEC_I_CONTEXT_EXPIRED before enabling SChannel [15:33:15 CET] <cone-229> ffmpeg 03Hendrik Leppkes 07release/3.0:ee7c347935c0: configure: check for SEC_I_CONTEXT_EXPIRED before enabling SChannel [15:33:24 CET] <Daemon404> O_o [15:41:55 CET] <nevcairiel> o_O [15:42:23 CET] <Daemon404> oh good. sliced h264 decoding produces wrong results on this file, with no errrors [15:42:32 CET] <Daemon404> i only see warnings on loglevel debug [15:42:32 CET] <ubitux> building chromium is the new hype thing? [15:42:46 CET] <nevcairiel> i dont do it for fun, mind you [15:42:56 CET] <wm4> didn't you know, all software converges towards chromium [15:42:57 CET] <nevcairiel> its $work [15:43:21 CET] <Daemon404> wm4, guis are written in js now [15:43:24 CET] <wm4> (actually, towards the browser, but we all know chromium is the only actual browser) [15:43:38 CET] <wm4> Daemon404: you don't need to tell me [15:45:42 CET] <nevcairiel> i wonder how long this linking will take [15:45:46 CET] <nevcairiel> i should watch another movie [15:46:11 CET] <Daemon404> nevcairiel, PGO? [15:46:17 CET] <nevcairiel> no clue [15:46:21 CET] <nevcairiel> i just ran this automated script [15:46:30 CET] <nevcairiel> LTCG in any case [15:46:36 CET] <Daemon404> oic [15:46:47 CET] <Daemon404> yeah. at MS, they have entire farms just for LTCG [15:46:49 CET] <Daemon404> it's slow. [15:48:29 CET] <wm4> building Qt (including chromium) takes only 2 hours or so here [15:48:52 CET] <nevcairiel> doesnt qt use "just" webkit? [15:49:00 CET] <Daemon404> i have never successfully built and used qt on windows, wm4 [15:49:07 CET] <Daemon404> itll build. my app will build. [15:49:07 CET] <Daemon404> BAM [15:49:09 CET] <Daemon404> runtime errror [15:49:12 CET] <Daemon404> some shitty dialogue box. [15:49:22 CET] <nevcairiel> i build Qt on windows fine, but without the web parts, since i dont need those [15:49:24 CET] <wm4> nevcairiel: it provides both (qtwebengine is the chromium one) [15:49:39 CET] <wm4> qtwebkit is deprecated [15:49:40 CET] <nevcairiel> i see [15:49:54 CET] <nevcairiel> i told this one to create a fully optimized build [15:49:57 CET] <nevcairiel> maybe that was a mistake [15:50:21 CET] <Daemon404> sigh refactors [15:50:29 CET] <Daemon404> even git blame -M -w doesnt work [15:50:44 CET] <wm4> at least this kind of software enables https://xkcd.com/303/ [15:51:12 CET] <nevcairiel> Daemon404: i just got used to using the web git interface for that and manually going through parents [15:51:25 CET] <Daemon404> nevcairiel, me too [15:51:56 CET] <wm4> I find gitk is pretty good at traversing history [15:53:39 CET] <Daemon404> currently waiting for github to stop freezing my brwoser [15:53:52 CET] <nevcairiel> this is why i mirror got git-web [15:53:58 CET] <nevcairiel> fucking github interface is the worst [15:54:08 CET] <Daemon404> ... what the hell github [15:54:10 CET] <wm4> github doesn't allow you to search commit history [15:54:14 CET] <Daemon404> i click on the commit in git blame view [15:54:16 CET] <durandal_170> github rocks! [15:54:21 CET] <Daemon404> and the diff *does not* add or mvoe that line [15:54:24 CET] <Daemon404> wtf? [15:55:01 CET] <Daemon404> it dos in git show [15:55:08 CET] <Daemon404> so github is silently removing parts of large diffs [15:55:10 CET] <Daemon404> not even a warning [15:55:43 CET] <durandal_170> also ffmpeg-devel is fine here, learn to use spam filter [15:56:25 CET] <Compn> plonk file ? :P [15:58:06 CET] <Daemon404> currently gone through 3 refactoring and cosmetic commits, still not at original addition of line [15:58:34 CET] <Daemon404> 4 now. a refactoring from svn times. [15:58:49 CET] <wm4> so, does it really work on windows if e.g. libavcodec calls av_malloc, and then libavformat calls av_free on the same memory? [15:59:10 CET] <Daemon404> ... wtf does this? [15:59:13 CET] <Daemon404> that sounds so wrong [15:59:25 CET] <wm4> probably nothing, it's just an example [15:59:40 CET] <Daemon404> .... sigh [15:59:40 CET] <wm4> I want to know if all libs implicitly share libavutil's heap [15:59:40 CET] <Daemon404> https://github.com/FFmpeg/FFmpeg/commit/26b86e47c010029d7ca7c7264f710c240d8… [15:59:44 CET] <Daemon404> original commit [15:59:46 CET] <Daemon404> 0 info [15:59:48 CET] <Daemon404> "fixes <filenames>" [15:59:58 CET] <wm4> that's more info than usual! [16:00:27 CET] <nevcairiel> it tells you that it adds support for non-sequential frame nums [16:01:24 CET] <Daemon404> it doesnt say why it happens, and how the fix works [16:01:27 CET] <Daemon404> because it doesnt work. [16:01:46 CET] Action: Daemon404 has files it prodices wrong output on, and also doesnt know why its nto a warning, but a debug log [16:01:49 CET] <nevcairiel> those conformance samples pass fate, so it must work =p [16:02:08 CET] <Daemon404> thats only true if we verified the output hash against JM [16:02:12 CET] <nevcairiel> and gaps in themself are not necessarily forbidden [16:02:36 CET] <Daemon404> in my case, im getting slices of other frames stiched together [16:02:49 CET] <kierank> does fate even test sliced threads [16:02:49 CET] <Daemon404> quicktime / vlc seem to play it right though [16:03:01 CET] <nevcairiel> vlc doesnt have its own decoder [16:03:02 CET] <Daemon404> the latter is kind confusing [16:03:14 CET] <Daemon404> nevcairiel, it may not use some threading type or feature ffmpeg.c does [16:03:32 CET] <durandal_170> slice threading? [16:03:51 CET] <Daemon404> nevcairiel, or it could be vlc using libav :P [16:03:53 CET] Action: Daemon404 hides [16:04:19 CET] <nevcairiel> try to play some kind of vp9 file, if it works its not libav =p [16:04:38 CET] <durandal_170> can you share one short sample? [16:04:52 CET] <Daemon404> durandal_170, i need to get permission from the user [16:04:55 CET] <nevcairiel> does it only break with threading then? [16:05:00 CET] <Daemon404> nevcairiel, not sure [16:05:01 CET] <Daemon404> lets try. [16:05:48 CET] <Daemon404> [h264 @ 0x749aa0] no picture ooo [16:05:50 CET] <Daemon404> i also like this [16:06:04 CET] Action: Daemon404 likes to think it is an adventure time reference [16:06:23 CET] <nevcairiel> ooo stands for out of order [16:06:36 CET] <Daemon404> ah [16:08:03 CET] <nevcairiel> hm still linking [16:08:07 CET] <nevcairiel> i should have timed this [16:08:56 CET] <Daemon404> nevcairiel, yes [16:09:01 CET] <Daemon404> diff thread count = diff hash [16:09:05 CET] <Daemon404> so it;s broken [16:09:16 CET] <nevcairiel> but fine in single? [16:09:26 CET] <Daemon404> need to verify output [16:09:29 CET] <Daemon404> i just checked it differs [16:13:28 CET] <nevcairiel> where the hell do people get such odd h264 encodes anyway [16:13:28 CET] <Daemon404> 1 thread looks correct. N threads output is nondeterministic. [16:13:34 CET] <Daemon404> so we have a bug. [16:13:52 CET] <Daemon404> nevcairiel, this is made by microsoft's h264 encoder [16:14:00 CET] <nevcairiel> microsoft has a encoder? [16:14:08 CET] <Daemon404> [h264 @ 0x18abe80] user data:"Microsoft H.264 Encoder V1.0 for Windows" [16:14:41 CET] <nevcairiel> i guess they do [16:15:33 CET] <Daemon404> odd as in "has slices" ? :P [16:15:46 CET] <nevcairiel> every bluray has slices, and those decode just fine [16:15:55 CET] <kierank> not many people use slice threading [16:15:58 CET] <kierank> so i'd beg to differ [16:16:08 CET] <Daemon404> does ffmpeg.c use it? [16:16:10 CET] <kierank> most of the dozen or so h264 crashes I found were in slice threads [16:16:15 CET] <kierank> only if you force it [16:16:19 CET] <nevcairiel> Daemon404: not unless you specifically tell it to [16:16:28 CET] <nevcairiel> otherwise it uses frame threading [16:16:29 CET] <Daemon404> ffmpeg -threads 1 -loglevel debug -i a.mp4 a.avi [16:16:34 CET] <Daemon404> im using a bare bones cli command [16:16:37 CET] <Daemon404> its reproducible [16:16:45 CET] <nevcairiel> i think -thread_type slice or something [16:17:00 CET] <Daemon404> dare i try helgrind [16:17:00 CET] <nevcairiel> default is frame+slice, where frame is favored [16:17:08 CET] <Daemon404> or will i be killed by spurious warnings [16:17:30 CET] <nevcairiel> if you can get permission to share the sample, that would probably be helpful [16:17:47 CET] <Daemon404> yeah but >timezones [16:17:53 CET] <Daemon404> response wont be quick [16:20:09 CET] <Daemon404> looks like even if i force frame threads, it is broken [16:20:45 CET] <Daemon404> forcing slice threads = correct output [16:20:48 CET] <Daemon404> so its a frame threading bug [16:21:04 CET] <Daemon404> (much to the shock of kierank) [16:21:30 CET] <kierank> interesting [16:21:49 CET] <kierank> does it actually use slice threading [16:21:58 CET] <kierank> i.e does it warn about deblock between slice [16:22:44 CET] <Daemon404> i dont see anything about that [16:22:45 CET] <Daemon404> so maybe not [16:22:56 CET] <Daemon404> also, with threads = 1, all the 'ooo' debug logs go away [16:23:06 CET] <Daemon404> (still dont know why its only debug) [16:23:34 CET] <kierank> might be a demuxer bug [16:23:37 CET] <kierank> avi and all that [16:23:44 CET] <Daemon404> it's mp4 [16:23:47 CET] <kierank> oh [16:27:22 CET] <wm4> just why, why in the fuck is ffmpeg full of functions that are >300 lines [16:27:33 CET] <kierank> because neckbeards [16:27:55 CET] <wm4> what does that even have to do with neckbeards [16:29:28 CET] <Daemon404> enterprise pointy haired people are just as likely to write them [16:29:40 CET] <atomnuker> punks? [16:30:02 CET] <Daemon404> no, it's a dilvery refernce [16:30:30 CET] <Daemon404> ==17375== ERROR SUMMARY: 25859 errors from 1000 contexts (suppressed: 2254 from 75) [16:30:33 CET] <Daemon404> after 1 frame [16:30:37 CET] <Daemon404> i think helgrind isnt gonna work [16:34:21 CET] <darkapex> atomnuker: Can I pm you the draft of my GSoC proposal for input? [16:35:10 CET] <atomnuker> darkapex: sure [16:35:27 CET] <Daemon404> ... is this thread "teach mats how to git" [16:36:08 CET] <nevcairiel> this thread got its last response hours ago, are you still reading it? =p [16:36:36 CET] <Daemon404> im slow [16:44:25 CET] <wm4> I project every new mail on my retina in realtime as it's fetched from the server [16:44:57 CET] <durandal_170> what? [16:45:30 CET] <kierank> google inbox kids [16:46:03 CET] <durandal_170> google tech? [16:49:19 CET] <wm4> so, when can we drop XP support [16:50:24 CET] <Daemon404> context? [16:50:31 CET] <wm4> no context [16:50:41 CET] <Daemon404> o ok [16:51:11 CET] <wm4> just that I spent some hours debugging a crash caused by thw w32pthreads.h XP hack (but not sure if it applies to ffmpeg without our custom hacks) [16:51:40 CET] <Daemon404> ... xp in a vm? [16:51:45 CET] <wm4> no, win10 [16:51:53 CET] <wm4> the problem was that pthread_cond_wait checked for the cond_wait variable, which was not initialized and set to NULL [16:51:56 CET] <Daemon404> why is xp code even being run then [16:52:06 CET] <wm4> because the containing source file never created a cond var (but got them from another file) [16:52:22 CET] <kierank> that reminds me to check all the cond_waits for spurious wakeups [16:52:48 CET] <wm4> (creating a cond var calls w32thread_init) [16:58:51 CET] <wm4> so, source file A creates a cond var, passes it to source file B, which calls pthread_cond_wait -> crash! [16:59:21 CET] <wm4> unless _WIN32_WINNT >= 0x0600 [17:01:54 CET] <Daemon404> i would just compile with that and say "vista+ only kthx" [17:02:09 CET] <wm4> I'm trying to find out how to set this without breaking everything [17:03:54 CET] <nevcairiel> wm4: wouldnt it crash anyway if you call pthread_cond_wait without a valid condition variable [17:04:04 CET] <wm4> nevcairiel: the cond var is valid [17:04:12 CET] <wm4> it's been initialized in another file [17:04:24 CET] <nevcairiel> "file"? [17:04:30 CET] <wm4> source file, .c [17:04:45 CET] <nevcairiel> the init should be process global [17:04:53 CET] <nevcairiel> shouldnt it [17:05:19 CET] <wm4> no, because these things use static var in a header [17:05:26 CET] <nevcairiel> oh right, its a header [17:05:30 CET] <wm4> to avoid having to link a source file in each sub lib for it [17:07:46 CET] <nevcairiel> if you use a custom hacked version anyway, you might as well convert it into a c file for your project [17:07:59 CET] <wm4> lol no [17:08:17 CET] <nevcairiel> wouldnt be very hard, just remove a bunch of static's [17:10:30 CET] Action: Daemon404 would rather rm xp [17:15:15 CET] <JEEB> hmm [17:15:46 CET] <JEEB> I wonder if some sort of still-being-written files would work if I would do `if(ret == 0) return AVERROR(EAGAIN);` [17:15:59 CET] <JEEB> since the reading mechanism seems to have some five-retries thing [17:16:11 CET] <JEEB> as well as some timeout thing [17:16:21 CET] <BBB> lol helgrind [17:16:31 CET] <Daemon404> BBB, it was useless yes [17:16:32 CET] <Daemon404> howrve [17:16:37 CET] <BBB> howrve? [17:16:41 CET] <Daemon404> however* [17:16:43 CET] <JEEB> however in Daelang [17:16:49 CET] <Daemon404> i dont now too many better ways to debug complex races [17:17:00 CET] <Daemon404> "staring at the code really hard" is pretty crap [17:17:04 CET] <BBB> how often does it reproduce? [17:17:11 CET] <Daemon404> every time [17:17:12 CET] <BBB> 1 in 10 times? 1 in 1000? 1 in 1M? [17:17:22 CET] <Daemon404> output hash changes every time with >1 thread [17:17:29 CET] <Daemon404> and is never correct [17:17:31 CET] <BBB> always to the same value? [17:17:34 CET] <BBB> ah ok [17:17:34 CET] <Daemon404> no [17:17:38 CET] <Daemon404> it is nondeterministic [17:17:39 CET] <BBB> what codec? [17:17:49 CET] <Daemon404> h264 with frame threads [17:17:57 CET] <BBB> send me file Ill look [17:18:09 CET] <Daemon404> waiting on users' permission atm [17:18:19 CET] <BBB> Im not promising anything but Ill at least try [17:18:45 CET] <Daemon404> ill send once they OK it [17:18:50 CET] <Daemon404> i'd open a bug on trac, but... carl. [17:22:53 CET] <wm4> should mingw really define struct pollfd? [17:24:30 CET] <ubitux> Daemon404: yes, helgrind/drd/tsan will give you GB of logs, that's what i'm uploading daily to fate (sorry i'm late to the party) [17:24:55 CET] <ubitux> which makes me wonder what happen to the google guy who was working on it [17:25:18 CET] <nevcairiel> we probably scared him off [17:26:03 CET] <jamrial> wm4: dunno, but i always wondered why it defines pollfd.fd as unsigned while our compat fallback is int [17:26:36 CET] <wm4> jamrial: maybe because the mingw guys are insane? I'm fairly sure the MS headers don't define that struct at all [17:26:59 CET] <jamrial> it generates "libavformat/os_support.c:284:23: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]" warnings when you use it [17:27:15 CET] <Daemon404> isnt it int on linux too [17:27:50 CET] <jamrial> wm4: https://msdn.microsoft.com/en-us/library/windows/desktop/ms740094%28v=vs.85… [17:28:14 CET] <wm4> oh, lol [17:28:20 CET] <wm4> MS are the insane ones then [17:28:27 CET] <jamrial> looks like fd should be int, meaning mingw-w64 is wrong [17:28:34 CET] <Daemon404> fd is int literally everywhere [17:28:36 CET] <Daemon404> except mingw [17:28:39 CET] <wm4> MS incompetence is so amazing [17:28:42 CET] <Daemon404> (according to google) [17:28:55 CET] <wm4> they're defining a function for compat with POSIX [17:29:02 CET] <wm4> except it has a different name and semantics [17:29:11 CET] <wm4> but they still define a POSIX type name for it [17:29:33 CET] <wm4> the one who did this must have been on some bad drugs [17:29:42 CET] <Daemon404> [16:29] <+wm4> but they still define a POSIX type name for it <-- uh they do? [17:29:47 CET] <Daemon404> i dont recall ms defining poll() [17:29:56 CET] <wm4> https://msdn.microsoft.com/en-us/library/windows/desktop/ms740094%28v=vs.85… [17:30:05 CET] <wm4> typedef struct pollfd [17:30:16 CET] <Daemon404> ohlol [17:30:23 CET] <jamrial> they don't define poll() but WSAPoll() instead [17:30:34 CET] <wm4> just insane [17:31:00 CET] <jamrial> which was intended to behave the same as poll(), except that for some bug it doesn't [17:31:39 CET] <wm4> defining struct pollfd kills any source compat wrapper you could have [17:31:45 CET] <wm4> I wonder how cygwin is dealing with that [17:32:31 CET] <Daemon404> #define pollfd someshit [17:32:36 CET] <Daemon404> #include <msheader.h> [17:32:40 CET] <Daemon404> #undef pollfd [17:32:42 CET] Action: Daemon404 runs [17:33:16 CET] <wm4> if you control everything that includes windows.h [17:34:33 CET] <wm4> anyway, can't find a nice way to force the Vista+-only code in w32pthreads.h [17:35:10 CET] <Daemon404> you cant build with the nt define? [17:35:49 CET] <wm4> --extra-cflags=-D_WINNT...? [17:35:57 CET] <Daemon404> yeah [17:36:08 CET] <nevcairiel> that should work, yes [17:36:15 CET] <wm4> right, this could lead to the configure checks not fucking it up [17:36:37 CET] <Daemon404> and uh [17:36:37 CET] <Daemon404> so [17:36:40 CET] <Daemon404> why isnt this default? [17:36:45 CET] <wm4> because XP? [17:36:47 CET] <jamrial> because xp [17:36:50 CET] <Daemon404> so... [17:36:59 CET] <Daemon404> people who want to support a dead os should be the non-default [17:37:01 CET] <Daemon404> not everyone else [17:37:09 CET] <Daemon404> so: same question. [17:37:10 CET] <jamrial> the msvc checks even *force* xp by default, unless extra-cflags says otherwise [17:37:19 CET] <wm4> we don't define _WINNT anywhere [17:37:22 CET] Action: Daemon404 sighs [17:37:24 CET] <wm4> and mingw defaults to something older [17:37:29 CET] <Daemon404> jamrial, that seems so silly [17:37:30 CET] <jamrial> wm4: we do for dxva [17:37:41 CET] <wm4> yeah, with hacks [17:38:15 CET] <nevcairiel> Daemon404: it really makes no difference when running on a newer windows, i dont get why there is always such a big huff about that, the compat code exists either way [17:38:24 CET] <wm4> #if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0602 [17:38:24 CET] <wm4> #undef _WIN32_WINNT [17:38:24 CET] <wm4> #define _WIN32_WINNT 0x0602 [17:38:24 CET] <wm4> #endif [17:45:41 CET] <ubitux> michaelni: in the hscale, can we overread filter? [17:47:27 CET] <ubitux> same question for src [18:06:32 CET] <t4nk263> hello [18:06:41 CET] <t4nk263> are there any known crashes with calling av_strdup [18:07:52 CET] <t4nk263> namely, when trying to call avformat_open_input, with the url: http://195.245.168.21/antena3 [18:08:00 CET] <t4nk263> on 32 bit machines, it would crash [18:36:58 CET] <jamrial> has anyone seen Andreas lately? it's been almost a month and a half since his last email [18:38:46 CET] <Daemon404> jamrial, maybe he got tired of arguing constantly [18:39:54 CET] <jamrial> in the end we reverted the thread change he requested [18:41:44 CET] <wm4> what thread change? [18:42:13 CET] <Daemon404> hwaccel [18:43:00 CET] <Daemon404> anyway, i expect hell show up with some hacks the next time some crappt debian package is unhappy [18:45:05 CET] <wm4> right [18:45:45 CET] <wm4> jamrial: it's been since that since he updated the debian ffmpeg packages too [18:45:53 CET] <nevcairiel> did they at least update ffmpeg in debian/ubuntu to 3.0 then? [18:46:46 CET] <wm4> no [18:46:48 CET] <wm4> 2.8.6 [18:47:51 CET] <jamrial> 3.0 seems to be in "experimental" [18:48:42 CET] <jamrial> wm4: yeah, that's why i was wondering if anyone has seen him. but then again, there hasn't been a new 2.8 point release in a while [18:54:13 CET] <michaelni> ubitux, from what i remember without checking the code, src probably before the last line up to linesize, filter is allocated by us so one could overallocate if its not good enough [19:03:34 CET] <cehoyos> nevcairiel: I didn't test but would have expected a "disable feature" in your patch (while I believe the "enable feature" was and is unnecessary) [19:08:43 CET] <nevcairiel> cehoyos: and why would that be, its not enabled unless explicitly called [19:10:55 CET] <nevcairiel> in any case the logic didnt change, it just added a new condition [19:24:37 CET] <cehoyos> nevcairiel: What does "grep schannel config.h" show with the patch? [19:25:28 CET] <nevcairiel> config.h doesnt change, it just avoids enabling it when its not supported on some old systems [19:25:41 CET] <cehoyos> Neither the zlib, nor the lzma nor the bzlib check contain "enable feature" [19:26:05 CET] <cehoyos> My question is: What does the grep command show on these old systems? [19:26:21 CET] <nevcairiel> it showed 1, now it should show 0 [19:26:37 CET] <nevcairiel> like i said, the logic didnt change today, it just added a new condition [19:26:42 CET] <nevcairiel> anyway, i have to leave now [19:26:59 CET] <cehoyos> Or to say it differently: What happens if you comment the "#define SEC_I_CONTEXT_EXPIRED" out? [19:27:39 CET] <nevcairiel> it will never get enabled, so it remains 0 [19:28:40 CET] <cehoyos> If it remains 0 how can it ever be enabled / how can the disable schannel || check ever be true? [19:28:55 CET] <nevcairiel> there is a difference between disabled and not enabled [19:29:01 CET] <nevcairiel> in any case, it works today [19:29:07 CET] <nevcairiel> really have to leave now, bbl [19:29:12 CET] <cehoyos> Ok, thanks [19:30:12 CET] <cehoyos> The three-way meaning that is used for xcb only makes sense if it fails for --enable-feature (which it does for xvb) but this doesn't seem implemented. [19:52:54 CET] <cone-229> ffmpeg 03Michael Niedermayer 07master:50ef7361cb5f: avcodec/resample: Remove disabled and faulty code [19:56:01 CET] <wm4> so if I tell someone not to use ffserver, what should I tell them to use instead [19:58:53 CET] <cone-229> ffmpeg 03Benjamin Steffes 07master:06267afe1cec: Fix detelecine filter for patterns like 3444 or 33333334. [20:01:24 CET] <JEEB> wm4: depends on what exactly they want to do. for most of the HTTP-streaming-wanting folk there's nginx-rtmp (which seems to have NIH'd a HLS and DASH muxer) [20:01:59 CET] <wm4> <sh4rm4^bnc> i'd like to test mini's ffv1 codec for LAN streaming, but ffserver doesnt seem to support that.. [20:02:07 CET] <JEEB> pffft [20:02:31 CET] <JEEB> I think ffmpeg could listen in http now too [20:02:37 CET] <JEEB> so I guess ffv1 in matroska for that? :P [20:02:41 CET] <JEEB> no idea wtf would support that [20:02:49 CET] <JEEB> other than lavf or vlc or so [20:12:49 CET] <kierank> Ahahaha streaming ffv1 [20:12:53 CET] <kierank> Good luck with that [20:13:59 CET] <Compn> who calls michael mini ? [20:14:23 CET] <Compn> very strange naming scheme that is applied to no one else [20:14:30 CET] <iive> libav parrots [20:19:04 CET] <Daemon404> ive never seen that guy around libav, so it seems very doubtful [20:19:40 CET] <wm4> it's all a conspiracy [20:20:35 CET] <Daemon404> michael can't melt steal beams! [20:20:45 CET] <Daemon404> steel* [20:20:48 CET] <Daemon404> damn i screwed up. [20:21:04 CET] <wm4> freudian slip that you want to steal all ffmpeg work! [20:23:49 CET] <llogan> stupid scanner only saves images as badly compressed JPG... [20:25:29 CET] <ethe> atomnuker: may I PM you (about AAC/audio programming) quick? [20:26:16 CET] <Compn> i'm sure michaelni could melt steel beams, just not with jet fuel ... [20:27:54 CET] <Daemon404> lol [20:31:18 CET] <rcombs> I called him that for a while before he informed me he doesn't like it [20:31:23 CET] <rcombs> no idea where I picked it up from [20:44:58 CET] <atomnuker> ethe: sure [20:50:00 CET] <llogan> rcombs: choose first two characters from any first+last name and they are all look dumb. [20:50:48 CET] <rcombs> BaOb [20:50:54 CET] <rcombs> DoTr [20:51:05 CET] <rcombs> TeCr [20:51:13 CET] <rcombs> BeSa [20:51:19 CET] <rcombs> yeah, nothing great here [21:02:42 CET] <wm4> does anyone have a patch to add DXVA_PicParams_VP9 to mingw? [21:03:56 CET] <wm4> or maybe I shouldn't bother [21:15:34 CET] <jamrial> wm4: nevcairiel's lavfilters fork of ffmpeg [21:15:55 CET] <jamrial> wm4: http://git.1f0.de/gitweb?p=ffmpeg.git;a=commitdiff;h=47edd2355f941a2429c572… [21:16:10 CET] <nevcairiel> i just copy pasted the MS header [21:16:15 CET] <nevcairiel> the mingw people dont like that for license [21:16:27 CET] <wm4> oh, going to steal that [21:16:38 CET] <wm4> what license implications does this have? [21:17:16 CET] <nevcairiel> (more specifically, i copy pasted the struct from the MS headers, they dont have a separate file for it) [00:00:00 CET] --- Thu Mar 17 2016

1 0

ffmpeg.log.20160316
by burek 17 Mar '16

17 Mar '16

[00:00:20 CET] <jookiyaya> yes i do remember reading about TN panels are only 6bit [00:01:35 CET] <iive> that makes them 18bit [00:02:15 CET] <J_Darnley> Yep, they could be pretty shit [00:02:29 CET] <J_Darnley> hence, crt=master race [00:06:12 CET] <iive> they actually use dithering [00:07:33 CET] <TD-Linux> even 8bit panels do dithering due to nonlinear correction [00:09:18 CET] <jookiyaya> why do gamers always talk about "faster fps" if film still to this day still use 23.97 fps [00:10:56 CET] <pzich> jookiyaya: because you don't need a crazy-fast response time for a film [00:11:04 CET] <jkqxz> Because smooth playback for viewing and minimise-latency playback to react to are not the same thing at all. [00:11:48 CET] <drv> also, have you ever seen a fast camera pan in film? it looks awful [00:12:39 CET] <furq> you can very clearly tell the difference between 60fps and 120fps [00:12:44 CET] <furq> especially if the only game you play is quakeworld [00:13:46 CET] <jookiyaya> why is bluray still using 23.97 then [00:14:34 CET] <furq> because films are shot at 23.97fps [00:15:25 CET] <jookiyaya> people don't seem to care improve the fps [00:15:39 CET] <furq> there have been films shot at 48 or 60fps [00:15:48 CET] <furq> people didn't like it because it made everything look like a mexican soap opera [00:15:53 CET] <jookiyaya> they seem to care about resolution though, since we are even at 4k now [00:15:57 CET] <furq> like most fancy TVs with motion compensation do [00:16:12 CET] <jookiyaya> mexican soap opera? i don't get it [00:16:45 CET] <furq> mexican soap operas are shot on video (30fps) because they are cheaply made [00:17:06 CET] <furq> it applies equally to anything which was shot on video and not film [00:17:28 CET] <furq> are there any more jokes you'd like me to explain [00:18:37 CET] <jookiyaya> but i am sure a lot of things are shot at 30fps not just soap opera [00:19:32 CET] <jookiyaya> somebody just typed to me this too: [16:11] <PrincessKnoeki> 60fps looks too much like TV soaps :D [00:21:03 CET] <jookiyaya> A reader recently commented that he would never buy a 4K LED/LCD television because of the Soap Opera Effect [00:21:43 CET] <jookiyaya> i just don't understand why call it "soap opera effect" . i am sure there many things that use 30 fps [01:12:49 CET] <kepstin> 30fps progressive content is actually fairly rare [01:13:21 CET] <kepstin> the thing that most people notice as the "soap opera effect" is up in the 50-60fps range (traditionally, this is interlaced content, so 50-60 fields per second) [05:21:41 CET] <Dominian> morning all... here's a paste of a command I'm trying.. raw stream to .ts... tired and out of ideas: http://pastebin.com/JVy8h1Rn [05:21:46 CET] <Dominian> any help would be appreciated [05:21:50 CET] <Dominian> probably.. something stupid [05:28:24 CET] <J_Darnley> --disable-muxers and you wonder why ffmpeg doesn't know what .ts is? [05:29:33 CET] <J_Darnley> hint: [NULL @ 0x2125720] Unable to find a suitable output format for 'testing.ts' [05:29:56 CET] <J_Darnley> and with that, good night [05:31:02 CET] <Dominian> Nope.. great answer though [05:34:02 CET] <furq> oh hey it's that useless suse package again [05:34:49 CET] <Dominian> So, quick fix or no? [05:35:02 CET] <furq> http://johnvansickle.com/ffmpeg/ [05:35:29 CET] <furq> iirc the last time this came up someone found a different suse package which didn't have everything even vaguely associated with mpeg-la removed [05:35:41 CET] <furq> but i'm too lazy to search the logs for it, and those builds will work [05:36:05 CET] <Dominian> no worires [05:36:07 CET] <Dominian> probably something in packman [05:36:09 CET] <Dominian> thanks [05:52:16 CET] <Dominian> furq: thank you for the link.. much better than the other guys suggestion [09:32:12 CET] <osense> hello [09:32:42 CET] <osense> I'm trying to cancat video with the demuxer on ffmpeg 3.0 and I'm getting "Protocol not on whitelist 'none'!" [09:32:45 CET] <osense> any ideas? [09:32:51 CET] <osense> concat videos, even [09:34:33 CET] <osense> http://pastie.org/10762015 [09:36:25 CET] <relaxed> ffmpeg -h demuxer=concat [09:36:59 CET] <relaxed> -safe 1 [09:37:11 CET] <osense> prepending -safe 0 before -i makes no difference :( [09:37:15 CET] <relaxed> er, maybe it's -safe 0 [09:37:38 CET] <osense> hmm [09:37:49 CET] <osense> okay, when I put in -safe 1 I get "Unsafe file name '/srv/http/20160316.mp4'" [09:38:02 CET] <osense> so it seems like -safe 0 was already being used? [09:51:51 CET] <relaxed> osense: try -protocol_whitelist file [09:54:23 CET] <osense> relaxed: this now gives "Protocol not on whitelist 'file'!" (this is different to the original error message) [09:56:09 CET] <osense> I wonder if this is all because I'm trying to pipe in the filenames instead of using a text file as input [09:57:33 CET] <osense> yeah, works fine with file asd input [11:53:02 CET] <Cyber_Akuma> Just have a quick question, does it matter where I use the "-threads" command? Can I use as my first argument before -i for the input file? [14:28:47 CET] <SixEcho> trying to convert gopro mp4 to webm:vp9/opus ffmpeg -i file.mp4 -vcodec libvpx-vp9 -acodec opus -crf 10 -b:v 0 -b:a 128k file.webm but it's processing at only 3fps& way too slow. suggestions? [14:30:21 CET] <J_Darnley> Get a faster computer. [14:30:23 CET] <SixEcho> MBP mid-2012 4xi7-2.7ghz& make that 0.3fps [14:30:28 CET] <J_Darnley> Make sure you are using the latest version [14:30:58 CET] <SixEcho> J_Darnley: i'm on 3.0 with the latest libvpx as well [14:32:05 CET] <J_Darnley> Meh. Its libvpx. I don't really care. [14:45:32 CET] <luc4> Hello! I would like to stream data (raw audio and video frames) through the network. I was thinking about RTP. Is there an example on how to stream like this using the C libraries? [15:22:38 CET] <Raz-X> hi everyone [15:22:59 CET] <Raz-X> I have some questions about streaming with ffmpeg [15:23:45 CET] <Raz-X> i have to get a video (unknown format), transcode it in mjpeg, and stream it over http [15:24:15 CET] <Raz-X> i'm able to do this with the ffmpeg+ffserver combo, but can i achieve this with just ffmpeg? [15:24:36 CET] <vexii> im trying to create a video file from a series of jpegs, but i get a "Error wile opening encoder", the command im trying to is "ffmpeg -start_number 2216 -i IMG_%03d.jpg -c:v libx264 out.mp4" [15:24:45 CET] <Raz-X> cuz the problem with ffserver is that it has to be restarted entirely to add a new stream [15:25:01 CET] <vexii> (the first jpg is named IMG_2216.jpg) [15:25:14 CET] <Raz-X> any advices? [15:27:33 CET] <eghdk> If I give ffmpeg a mpeg4 file, is it easy enough to crop the video size down? [15:27:59 CET] <eghdk> Example: I have an mpeg4 video, but I want it to be a square video. [15:43:50 CET] <J_Darnley> eghdk: see the crop filter [15:49:47 CET] <vexii> J_Darnley: sorry, here is the command http://pastebin.com/zxAUMaK7 [15:50:17 CET] <J_Darnley> OMFG! We want the full output as printed to your terminal! [15:50:56 CET] Action: J_Darnley notes you already gave us the command [15:51:17 CET] <vexii> chill dude... http://pastebin.com/iTZCEc2i [15:51:34 CET] <J_Darnley> Read the error! [15:51:36 CET] <J_Darnley> [libx264 @ 0x558e2599dba0] width not divisible by 2 (4701x3134) [15:51:47 CET] <J_Darnley> It should be highlighted in red! [15:52:01 CET] <vexii> and how do i handle that ? [15:52:09 CET] <J_Darnley> scale, pad, or crop [15:52:48 CET] <vexii> why do the file need to have a width divisible by 2? no resizing is going on [15:53:09 CET] <J_Darnley> How can you have half a chroma sample? [15:53:18 CET] <vexii> what? [15:53:39 CET] <J_Darnley> Read about chroma subsampling if you really want to know. [15:56:22 CET] <vexii> hmm kind of expected that to be encoding dependent, but guss not [15:56:37 CET] <vexii> so the only way is to resize alle the files` [15:56:39 CET] <vexii> ? [15:56:57 CET] <J_Darnley> Yes, or just let ffmpeg do it while encoding [15:57:09 CET] <J_Darnley> Well, tell ffmpeg to do it. [15:57:20 CET] <vexii> what flag? [15:58:01 CET] <J_Darnley> http://ffmpeg.org/ffmpeg-filters.html#crop http://ffmpeg.org/ffmpeg-filters.html#pad-1 http://ffmpeg.org/ffmpeg-filters.html#scale-1 [15:59:21 CET] <vexii> and i can't get it to auto scale it ? [15:59:43 CET] <J_Darnley> Scale it to what exactly? [16:00:04 CET] <J_Darnley> there is no "make this work" option [16:00:11 CET] <vexii> divisible by 2 [16:00:43 CET] <vexii> i pref not having to chrop pad or scale as the picture is the size i need [16:01:19 CET] <J_Darnley> WTF? If you can't change the frame size then you can't make the width divisible by 2 [16:04:34 CET] <vexii> prefer is on the same as can't. but this is just going to be a bad edge case [16:04:45 CET] <vexii> thanks for the time. [16:22:32 CET] <eghdk> J_Darnley: Thanks. I just wanted to check with a group of people familiar with it until I dumped some time into it [17:57:34 CET] <Prelude2004c> hey everyone good day.. anyone know what a 406 error means ? [17:58:01 CET] <Prelude2004c> using vlc i can pull the url but when i try with ffmpeg i get : [http @ 0x2566100] HTTP error 406 Not Acceptable [17:58:01 CET] <Prelude2004c> [hls,applehttp @ 0x255e240] Failed to open segment of playlist 0 [18:05:33 CET] <jkqxz> Prelude2004c: 406 means the "Accept" header on your HTTP request does not include whatever type the server you are connecting to wanted to send, so it decided to give you an error instead. [18:06:01 CET] <Prelude2004c> ic.. ok investigating.. thank you [18:06:13 CET] <jkqxz> (If you want a more ffmpeg-oriented answer than that then you'll need to provide more information, such as a complete log...) [18:58:02 CET] <llogan> http://ffmpeg.gusari.org/viewtopic.php?f=11&t=2739&p=8224#p8223 [18:58:48 CET] <llogan> poor bastard. he's hopeless. [19:05:36 CET] <J_Darnley> Apple is still making My First Computers(TM) I see [19:06:21 CET] <bencoh> more than ever [19:06:31 CET] <bencoh> but not just apple (and we're not friday yet) :p [19:08:13 CET] <J_Darnley> Oh yes. [19:08:35 CET] <J_Darnley> Can't forget Microsoft's two latest offerings. [19:09:23 CET] <furq> .... Notice the ./ before the ffmpeg: No such file or directory [19:09:27 CET] <furq> that's the saddest thing i've ever seen [19:11:29 CET] <llogan> Just need to find a ffgui with one button for these users. it works by analyzing search history and social media engineering. [19:13:35 CET] <axc1298> hi. i read that with 'ffmpeg -i' i can list some information about a video file, including the resolution. i was wondering if there is a way i can return just the resolution for a list of files, not all the other information that comes with -i [19:14:49 CET] <llogan> ffprobe -v error -of default=nw=1 -select_streams v:0 -show_entries stream=height,width input.foo [19:14:49 CET] <J_Darnley> grep? [19:14:57 CET] <J_Darnley> or ffprobe ^^ [19:15:18 CET] <llogan> another zample: https://trac.ffmpeg.org/wiki/FFprobeTips#WidthxHeight [19:16:15 CET] <axc1298> thanks, that's cool llogan [20:07:39 CET] <axc1298> J_Darnley: i want it in the form 123x456 instead of width=320 height=240 so i ended up using both ffprobe and grep lol [20:10:54 CET] <llogan> axc1298: the example in the link i provided will also provide 123x456 [20:19:04 CET] <axc1298> llogan: nice. i see it there at the bottom now [20:57:33 CET] <jonah> Is it possible to add subtitles to a video with ffMpeg and ffProbe? [20:58:36 CET] <J_Darnley> Why would ffprobe play any role? [20:58:42 CET] <J_Darnley> Otherwise yes. [21:07:10 CET] <jonah> ok, thanks [21:08:38 CET] <J_Darnley> That was it? No "how" or any other followup questions? [21:19:17 CET] <Mavrik> :)) [21:22:41 CET] <thebombzen> haha [21:29:23 CET] <axc1298> so i put the recommendations in that link into a script that shows resolution for a video file. i'm really bad at bash though. if i have a bunch of video files, and each one is in its own directory within the same parent directory, is there a way to run this on them? http://paste.debian.net/416090 [21:29:52 CET] <axc1298> i was thinking i could use it with ls somehow [21:30:34 CET] <furq> for f in */*.avi [21:30:55 CET] <J_Darnley> find and its -exec option [21:31:21 CET] <furq> you won't be able to pass that to exec [21:31:47 CET] <furq> i guess you could do it with xargs but if each file is one directory deep then you might as well use */* [21:32:03 CET] <axc1298> so for f in */*.avi, run that script? [21:32:14 CET] <furq> yeah [21:32:18 CET] <axc1298> cool [21:32:18 CET] <furq> and change $* to $f [21:32:45 CET] <J_Darnley> find . -type f -exec bash script.sh {} ';' [21:33:36 CET] <furq> that's the kind of talk that will get you kicked out of shell script club [23:09:13 CET] <poprop> hello, does the FFmpeg's header/libs win32 binary distribution have the DXVA2 decoding option compiled in? "avcodec_find_decoder_by_name("h264_dxva2")" fails. [23:16:50 CET] <J_Darnley> Who's binary? [23:16:50 CET] <J_Darnley> FFmpeg (the project) doesn't ship any [23:17:53 CET] <poprop> hello J_Darnley: "https://www.ffmpeg.org/download.html#build-windows" which leads to: "https://ffmpeg.zeranoe.com/builds/" [23:18:21 CET] <J_Darnley> then yes I think they do have dxva [23:18:49 CET] <poprop> hum then i must be doing something wrong, thanks for your help it clears things up! [23:21:30 CET] <jkqxz> poprop: DXVA2 is a hwaccel, not a standalone decoder. You want to get the normal ffmpeg decoder ("h264") and then attach the hwaccel to it. [23:24:33 CET] <poprop> this explains a lot, i will attempt this, thanks. Should I initialize the dxva2 hwaccel using the "ffmpeg_dxva2.c"/"dxva2_init" helper function? [23:27:14 CET] <poprop> it seems it expects a "DXVA2Context" through the "opaque" field of the AVCodecContext which can be null. [23:30:04 CET] <jkqxz> You want to do something like ffmpeg_dxva2.c does, yes (that file is basically the example of how to set up the dxva2 hwaccel, for the hwaccel-generic parts you might need to look at ffmpeg.c). [23:30:50 CET] <poprop> great, thank you very much jkqxz, will do. [23:31:32 CET] <poprop> bye everyone, thanks for the help. [23:38:16 CET] <Cyber_Akuma> Does it matter where I use the -threads argument in the command line? Can I use it anywhere within the arguments? [23:38:30 CET] <J_Darnley> Yes and also yes [23:39:11 CET] <J_Darnley> It is a codec option so it affects each codec that you use it with. [23:41:08 CET] <Cyber_Akuma> So, if I use it as my first argument before even -i for the input file, will it apply to everything [23:41:08 CET] <Cyber_Akuma> ? [23:41:48 CET] <J_Darnley> ffmpeg -threads 1 -i INPUT OUTPUT is not the same as ffmpeg -i INPUT -threads 1 OUTPUT [23:42:16 CET] <J_Darnley> To answer your specific question: absolutely not [23:42:32 CET] <Cyber_Akuma> I see, what is the difference? The first one will only affect the imput codec, not the output one? [23:42:40 CET] <J_Darnley> yes [23:43:06 CET] <Cyber_Akuma> So I should use it before my output arguments if I want it to use multithreaded encoding [23:43:18 CET] <J_Darnley> yes [23:43:18 CET] <furq> you normally don't need to specify threads at all unless you're trying to free up cores [23:43:30 CET] <Cyber_Akuma> It seems to default to 1 thread [23:43:30 CET] <furq> most commonly used encoders will automatically use multithreading [23:43:33 CET] <J_Darnley> (a good codec will autodetect though) [23:44:35 CET] <furq> are you by any chance using libvpx [23:44:48 CET] <Cyber_Akuma> Actually, I am using the ffmpeg that MeGui installed [23:44:54 CET] <Cyber_Akuma> oh, for input, yes [23:45:01 CET] <furq> no i mean as an encoder [23:45:11 CET] <Cyber_Akuma> I am converting some mp4 files to webm for embedding in web pages [23:46:03 CET] <Cyber_Akuma> "-c:v libvpx" [23:46:54 CET] <furq> getting multithreading working properly with libvpx is a pain [23:47:16 CET] <Cyber_Akuma> I see [23:47:40 CET] <TD-Linux> in particular, the main way to do multithreaded encodes is tiles [23:47:42 CET] <furq> if it's not one of those sites which only hosts webm then you might as well just use mp4 for the web [23:48:00 CET] <furq> assuming it's h264/aac [23:48:02 CET] <TD-Linux> however VP8 doesn't have tiles [23:48:31 CET] <TD-Linux> the other main way is to split your video and encode sections separately, unfortunately neither libvpx nor ffmpeg will do that for you [23:48:31 CET] <furq> vp8 has --token-parts [23:48:32 CET] <Cyber_Akuma> I do use the mp4 in most sites that allow it [23:48:58 CET] <furq> i'm not sure how that maps to ffmpeg though, i'm just looking at the webm docs [00:00:00 CET] --- Thu Mar 17 2016

1 0