Ffmpeg-devel-irc
Threads by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
May 2016
- 1 participants
- 62 discussions
[00:21:49 CEST] <cone-437> ffmpeg 03Tobias Rapp 07master:21f9fbce5cf9: avfilter/f_metadata: add pts_time to print output
[00:21:49 CEST] <cone-437> ffmpeg 03Tobias Rapp 07master:9486de5a85f0: avfilter/f_metadata: update print output header line format
[03:51:37 CEST] <michaelni> jkqxz, is it intended to have non constant statics (static VAConfigAttrib vaapi_encode_*_config_attributes[]) in the new code?
[04:05:20 CEST] <philipl> -a
[05:01:00 CEST] <Compn> Mavrik : you mean like DIVX dvds? :P
[05:01:03 CEST] <Compn> hilarious idea
[08:22:46 CEST] <kurosu> this year at least have the benefit of having 4K hevc and sometimes vp9 decoders
[08:23:21 CEST] <kurosu> but none has a 10bits vp9 decoder, so indeed for a tv set that is going to last 5+ years, it's too early
[08:25:10 CEST] <kurosu> the (very?) high end support hdr10 (=hevc main10 + smpte 2084 or 2086 iirc), so that's somewhat ok, except this generation is likely for live beta testing :D
[09:52:36 CEST] <jkqxz> michaelni: That gets cleaned up in a following patch: <https://git.libav.org/?p=libav.git;a=commitdiff;h=f6b85523692b0e7d4c4efb844…>.
[10:29:31 CEST] <c0rnw19> Hello world
[10:30:22 CEST] <c0rnw19> Someone can help me? :) I would like use ocr with ffmpeg : http://stackoverflow.com/questions/36373582/how-can-i-hide-a-text-on-udp-vi…
[10:47:22 CEST] <BtbN> You'll have to write an OCR filter for that first.
[10:50:13 CEST] <durandal_1707> There is ocr filter... But this one is about detecting text above random video
[10:51:25 CEST] <c0rnw19> Hi, durandal_1707 yes I know, but there aren't doc on this
[10:51:39 CEST] <c0rnw19> do you how use it
[10:51:50 CEST] <c0rnw19> know*
[11:01:59 CEST] <durandal_1707> c0rnw19: this can't be realtime afaik, detecting text is slow ...
[11:08:44 CEST] <ubitux> ok so i just spent weeks to figure out that VT can not handle more than 3 packets in asynchronous mode (even though its internal queue is of 10), otherwise ios will fatally deadlock when the app is going in background
[11:08:53 CEST] <ubitux> good job apple, quality software
[11:16:11 CEST] <c0rnw19> durandal_1707, Yes I know I tried last year on windows emgucv c#
[11:16:43 CEST] <c0rnw19> but maybe If I use only i-frame with ffmpeg
[11:16:51 CEST] <c0rnw19> this can help me? no?
[11:17:39 CEST] <c0rnw19> or nvidia cuda libs? quick_sync?
[11:29:30 CEST] <wm4> ubitux: the current libavcodec subtitle API makes me want to kill myself
[11:30:40 CEST] <wm4> so, somehow, on older libavcodec versions (ffmpeg 2.8), dvdsubdec doesn't pass through subtitle timestamps or something
[11:30:45 CEST] <wm4> or does it differently
[11:39:42 CEST] <wm4> *groan*
[11:39:55 CEST] <wm4> pkt_timebase is set to 0/1 by default
[11:40:09 CEST] <wm4> if (avctx->pkt_timebase.den && avpkt->pts != AV_NOPTS_VALUE) <- lol
[11:40:38 CEST] <wm4> so it checks den and makes an assumption about valid timebase
[11:40:49 CEST] <wm4> and another line of code, just below it does:
[11:40:50 CEST] <wm4> if (sub->num_rects && !sub->end_display_time && avpkt->duration &&
[11:40:50 CEST] <wm4> avctx->pkt_timebase.num) {
[11:41:38 CEST] <wm4> commit 50401f5fb7d778583b03a13bc4440f71063d319d fixed this
[11:41:42 CEST] <wm4> but it never made it into a release
[11:41:48 CEST] <wm4> why the fuck am I supporting old releases
[12:18:15 CEST] <durandal_1707> omerjerk: finally figured how to extract float from decoder into wav?
[12:18:29 CEST] <omerjerk> nope.
[12:18:35 CEST] <omerjerk> that's what I came to ask
[12:18:52 CEST] <durandal_1707> what you tried?
[12:19:36 CEST] <omerjerk> I'm properly setting the output format and bps here - https://github.com/omerjerk/FFmpeg/blob/float/libavcodec/alsdec.c#L2144
[12:19:38 CEST] <durandal_1707> ffmpeg -i input.mp4 -c:a pcm_f32le out.wav
[12:19:52 CEST] <omerjerk> ^^ I didn't try that command.
[12:20:02 CEST] <omerjerk> I just do ffmpeg -y float.mp4 out.wav
[12:20:09 CEST] <omerjerk> *-i
[12:20:29 CEST] <durandal_1707> that will just do 16bit
[12:20:35 CEST] <omerjerk> oh.
[12:20:42 CEST] <omerjerk> I didn't know this.
[12:20:44 CEST] <durandal_1707> *transcoding
[12:20:53 CEST] <omerjerk> I thought just setting in the code is enough.
[12:21:02 CEST] <omerjerk> but can't we do something about it ?
[12:21:23 CEST] <omerjerk> I won't expect the user to add "-c:a pcm_f32le" into the command line
[12:21:37 CEST] <durandal_1707> no, and that's not your task anyway
[12:21:45 CEST] <omerjerk> and what's the point of setting the bps and sample format from the code ?
[12:21:54 CEST] <omerjerk> if it'll just output 16 bit int
[12:22:48 CEST] <durandal_1707> its needed, ffmpeg pick 16bit pcm for wav by default
[12:23:43 CEST] <durandal_1707> if codec uses float sample format it must set proper params
[12:26:04 CEST] <omerjerk> ^^ what do you mean by that ?
[12:27:52 CEST] <durandal_1707> codecs operates in different sample formats
[12:29:15 CEST] <durandal_1707> omerjerk: so, have you inspected output of that command?
[12:31:09 CEST] <omerjerk> I just checked.
[12:31:25 CEST] <omerjerk> The size now is same as the original wav file.
[12:32:32 CEST] <omerjerk> and when I hear the output file, the sound comes fine from the right speaker.
[12:32:51 CEST] <omerjerk> Left speaker shows problem.
[12:33:02 CEST] <omerjerk> I think the issue is in my code now.
[12:33:13 CEST] <durandal_1707> It's stereo?
[12:33:25 CEST] <omerjerk> yes. it has 2 channels.
[12:34:26 CEST] <durandal_1707> left is usually first channel
[12:34:41 CEST] <durandal_1707> *left speaker
[12:35:49 CEST] <omerjerk> okay. I'll see what I'm missing. must be some small bug in my code.
[12:35:58 CEST] <omerjerk> thanks for the help. :)
[15:09:58 CEST] <BBB> did the matroska muxer recently change output?
[15:10:12 CEST] <BBB> (my md5 for the remux test changed)
[15:11:25 CEST] <durandal_1707> Yes it did
[15:11:41 CEST] <BBB> which commit?
[15:11:47 CEST] <BBB> (if you remember)
[15:12:01 CEST] <durandal_1707> merge of commit from April libav
[15:12:21 CEST] <durandal_1707> about field order info
[15:13:00 CEST] <durandal_1707> and doctype version changed to 4
[15:13:41 CEST] <durandal_1707> ee865e9780
[15:13:53 CEST] <nevcairiel> version was 4 before in ffmpeg
[15:13:57 CEST] <nevcairiel> but it does indeed write a new field
[15:23:38 CEST] <Daemon404> BBB, matroska did, webm should not have changed
[15:23:47 CEST] <Daemon404> matroska gained the field order field
[15:23:50 CEST] <BBB> I was writing matroska
[15:23:54 CEST] <Daemon404> ok
[15:23:57 CEST] <BBB> but even after removing that, it still changed
[15:24:05 CEST] <Daemon404> BBB, what changed
[15:24:16 CEST] <Daemon404> that is the only thing that touched it from merges
[15:24:25 CEST] <Daemon404> at least
[15:24:45 CEST] <BBB> ah I see the merge commit now
[15:24:49 CEST] <BBB> I was undoing the version change also
[15:24:52 CEST] <BBB> and it didnt amek any sense
[15:24:56 CEST] <BBB> ignoring that fixes the md5
[15:24:57 CEST] <nevcairiel> i wonder if its really a good idea to write a "undefined" value
[15:24:59 CEST] <BBB> ok
[15:25:08 CEST] <nevcairiel> should probably just not write anything then
[15:25:15 CEST] <nevcairiel> undefined is the default for that field when not written
[15:25:21 CEST] <nevcairiel> and it might avoid confusion
[15:25:45 CEST] <Daemon404> fair enough
[15:25:56 CEST] <Daemon404> i only wanted to point out to bbb its expected
[15:26:02 CEST] <nevcairiel> yeah
[15:26:47 CEST] <BBB> I just want to make sure the md5 change is correct in the remux test before I push it
[15:26:51 CEST] <BBB> which Im about to do :-p
[15:33:02 CEST] <BBB> I also get a segfault running vsynth1-dnxhd-720p
[15:34:19 CEST] <BBB> if (ctx->cid_table->bit_depth == 8) in ff_dnxhdenc_init_x86 (cid_table = NULL)
[15:40:16 CEST] <BBB> rebuilding ffmpeg so painful
[16:17:35 CEST] <cone-640> ffmpeg 03Ronald S. Bultje 07master:431117dcb55c: vf_colorspace: add floyd-steinberg dithering option to full conversion.
[16:17:36 CEST] <cone-640> ffmpeg 03Ronald S. Bultje 07master:9b26a8077f1c: vf_colorspace: add const to yuv_stride[] argument in DSP functions.
[16:17:37 CEST] <cone-640> ffmpeg 03Ronald S. Bultje 07master:f4075767b20f: vf_colorspace: use enums for bpp/subsampling array indices.
[16:17:38 CEST] <cone-640> ffmpeg 03Ronald S. Bultje 07master:9c4943e6710d: ffmpeg: copy color properties in case of -c:v copy.
[16:17:39 CEST] <cone-640> ffmpeg 03Ronald S. Bultje 07master:3ed5218bd365: fate: add matroska-remux test.
[16:17:40 CEST] <cone-640> ffmpeg 03Ronald S. Bultje 07master:9bbed8645a6b: vf_colorspace: make whitepoint adaptation mode configurable.
[16:17:41 CEST] <cone-640> ffmpeg 03Ronald S. Bultje 07master:356c11653665: vf_colorspace: fix range order.
[16:17:42 CEST] <cone-640> ffmpeg 03Ronald S. Bultje 07master:531ff7161d9d: vf_colorspace: don't enable passthrough if bitdepth doesn't match.
[16:20:51 CEST] <Daemon404> nevcairiel, those rtp patches come after the Giant H264 Set
[16:33:25 CEST] <nevcairiel> i know, hence why I asked if they are especially important
[16:36:50 CEST] <nevcairiel> although most of those patches dont seem to be too terrible
[16:37:24 CEST] <nevcairiel> just a lot of field re-shuffling
[16:46:58 CEST] <jkqxz> The AVClass* is called "class" for pretty much everything except the top-level AVFooContexts. If those could be renamed (they aren't user-settable?), then av_opt_set_* could statically assert that offsetof(obj, class) == 0 to make it fail at compile time.
[16:48:46 CEST] <Daemon404> jkqxz, you should reply on the ML if possible
[16:51:17 CEST] <jkqxz> Sure. I was thinking there is a significant chance that it can't possibly work for some reason I am not aware of, which people here might just be able to tell me.
[16:51:45 CEST] <nevcairiel> class is not a valid name as it breaks c++ compat
[16:52:06 CEST] <Daemon404> in headers yeah
[16:52:45 CEST] <nevcairiel> and not sure how its supposed to check that, it takes a void pointer
[16:52:52 CEST] <nevcairiel> macro magic i guess?
[16:52:57 CEST] <jkqxz> Ah, keyword. Ok. Rename to av_class everywhere?
[16:53:34 CEST] <Daemon404> AVClass *dont_you_dare_touch_this;
[16:54:04 CEST] <jkqxz> offsetof(obj, av_class) == 0 only checks that a field called "av_class" exists and is the first thing in the structure. We can't check the type (though I guess it could also make sure sizeof(obj->av_class) == sizeof(void*)).
[16:54:13 CEST] <nevcairiel> i dont think we can rename it in public structs either, some may access it for wrong reasons, but its still a public field
[16:54:36 CEST] <jkqxz> The public ones look like they are all av_class, so it would be renaming everything else to use that.
[16:54:39 CEST] <nevcairiel> although public structs use the same field name
[16:54:40 CEST] <Daemon404> depends if it is documented as untouchable
[16:55:17 CEST] <jkqxz> (Which is pretty much a two-line change to every single file in the whole project.)
[16:55:36 CEST] <Daemon404> jkqxz, it sounds vaguely fragile to me
[16:55:43 CEST] <Daemon404> until some guy comes along and adds one
[16:55:51 CEST] <Daemon404> and the earthe asplodes
[16:56:02 CEST] <jkqxz> Adds one what?
[16:56:19 CEST] <Daemon404> an new struct with av_class
[16:56:29 CEST] <Daemon404> because we dont exactly have documents for developing internal stuff
[16:56:31 CEST] <Daemon404> sadly.
[16:57:10 CEST] <Daemon404> fwiw i like the idea, im just playing devil's advocate
[16:57:48 CEST] <jkqxz> Hmm. Actually, most of the structs never actually get used with av_opt_set_* directly. They only need to be renamed if they are.
[16:57:55 CEST] <nevcairiel> i'm not sure its worth the macro madness
[16:58:02 CEST] <nevcairiel> someone may have a void pointer he passes to av_opt
[16:58:10 CEST] <nevcairiel> which is perfectly valid
[16:58:33 CEST] <nevcairiel> especially since some structs we use av_opt* on are entirely hidden, and only use av_opt for any access
[16:59:05 CEST] <nevcairiel> like SwsContext
[17:01:25 CEST] <jkqxz> Yeah, ok. The void* on its own gets you, and there is no way to shortcut evaluation so the member access is just impossible.
[17:11:00 CEST] <JoshX> Daemon404: i found the specs how axis stores the data off their timestamps: http://www.axis.com/files/manuals/VAPIX_3_H264_userdata_1_00.pdf
[17:11:12 CEST] <JoshX> the question now is if i could make ffmpeg do the same
[17:26:09 CEST] <mateo`> hello there, i'm wondering if it's useful that i submit a patchset that add an audio frame pool to libavfilter given the fact the cpu time that takes malloc+free goes from 2.50% to 1.84% (most of the time is spent in request_frame + resample ~81%) on a rpi2.
[17:29:57 CEST] <durandal_1707> could be, what about also direct AVframe like with video?
[17:31:03 CEST] <mateo`> durandal_1707: what do you mean by direct AVframe ?
[17:31:57 CEST] <durandal_1707> uncoded frame
[17:33:09 CEST] <mateo`> sorry, I still don't get it.
[17:42:20 CEST] <petrurares> Hi there, I have updated the wiki to show how to use enc_dec_pcm command in a test. Any suggestion is welcome
[17:50:20 CEST] <mateo`> what did git send-email just do ... my mail title is (no subject) :(
[17:56:02 CEST] <ubitux> what did *you* do
[17:56:10 CEST] <ubitux> :s
[17:57:36 CEST] <nevcairiel> sounds like you just didnt fill in the title for the cover letter
[17:58:04 CEST] <jamrial> mateo`: the in-reply-to field says "lavfi: add an audio frame pool for each link of the filtergraph"
[17:58:15 CEST] <jamrial> guess that was supposed to be the subject :p
[17:59:53 CEST] <nevcairiel> heh
[18:16:58 CEST] <durandal_1707> mateo`: there is uncoded AVframe for video but not audio
[18:20:42 CEST] <cone-640> ffmpeg 03Jean Delvare 07master:aeefe018f847: avfilter/delogo: Check that logo area is inside the picture
[18:40:08 CEST] <jkqxz> #define check_for_av_class(obj) ({ struct { void *av_class; } tmp; _Static_assert(__builtin_offsetof(__typeof__(__builtin_choose_expr(sizeof(*(obj)) == sizeof(void), tmp, *obj)), av_class) == 0, "no av_class!"); })
[18:40:44 CEST] <jkqxz> Fails to compile if the argument is neither a void* nor a pointer to a structure the first member of which is called av_class.
[18:40:57 CEST] <nevcairiel> but what if its an opaque struct
[18:41:47 CEST] <nevcairiel> sws and swr both use that, as well as some internal stuff
[18:42:43 CEST] <jkqxz> Then can't take sizeof? Hmm. A bit more magic with __builtin_choose_expr might be able to do it.
[18:42:59 CEST] <mateo`> jamrial: :D
[18:46:44 CEST] <wm4> jkqxz: no, they could be completely opaque
[20:08:22 CEST] <neuro_sys> wow, 178 developers?
[20:11:20 CEST] <Shiz> more like 178 idlers of which some fraction might be actually useful
[20:11:21 CEST] <Shiz> but sure
[20:11:24 CEST] <DHE> or just people interested in the process
[20:12:10 CEST] <DHE> I have (well, had) open tickets and am interested in the API
[20:12:32 CEST] <neuro_sys> alright, I just submitted what I think might be a bug, FWIW: https://trac.ffmpeg.org/ticket/5535
[20:17:47 CEST] <DHE> there's a bot that announces ticket updates live, so that's not necessary
[20:21:42 CEST] <neuro_sys> so using avformat_open_input is not the only way to read a file, because in the doc/examples/avio_reading.c:79 it's using av_file_map to read it and manually create the context. So the former is a wrapper around the latter.
[20:24:54 CEST] <DHE> Users' API questions still belong in #ffmpeg
[20:25:46 CEST] <neuro_sys> okay
[20:32:43 CEST] <kierank> michaelni: in int av_crc_init(AVCRC *ctx, int le, int bits, uint32_t poly, int ctx_size) does bits refer to the data size or the polynomial bits?
[20:34:48 CEST] <kierank> looks like polynomial bits
[20:39:44 CEST] <jamrial> polynomial bits, yes
[20:40:55 CEST] <kierank> not sure the crc does the right thing on non mod 8-bit data
[21:14:51 CEST] <durandal_1707> mlt have lavfi support
[21:28:45 CEST] <jamrial> kierank: i take fuzzing didn't find anything then?
[00:00:00 CEST] --- Wed May 11 2016
1
0
[00:13:04 CEST] <vade> Mavrik: just to be clear about time correction for stream timestamps: order is a) demux a packet, see which stream it came from. convert the packet from the stream time base to codec time base, decode, or demux a packet, see which stream it came from, decode, convert the frame packet from stream time base to codec time base?
[00:15:32 CEST] <Mavrik> demux -> (packet is now in stream timebase) -> to codec timebase -> decode -> (AVFrame is now in codec timebase) -> ...
[00:15:43 CEST] <Mavrik> Usually you set codec timebase to streamtimebase to skip that conversion
[00:19:38 CEST] <vade> when I demux, the timestamp conversion happens for me, or do I have to use av_rescale_q ?
[00:20:56 CEST] <Mavrik> when you demux, you get the timestamps as they are in the stream.
[00:21:04 CEST] <vade> ok
[00:21:17 CEST] <vade> thanks. Im just seing weird behaviour with one movie and Im trying to track it down, and likely confusing myself.
[00:21:18 CEST] <Mavrik> It's pretty obvious what they are if you just look at the numbers :/
[00:21:32 CEST] <vade> yea, im logging the numbers, i think im just converting incorrectly manually
[02:58:11 CEST] <Prelude2004c> hey, can anyone help ? I am still struggling here . [mpegts @ 0x36b7180] Non-monotonous DTS in output stream 0:0; previous: 38545191, current: 38545191; changing to 38545192. This may result in incorrect times
[03:21:23 CEST] <petecouture> Prelude2004c: Can you post your encoding line?
[03:21:32 CEST] <Prelude2004c> of course..
[03:22:16 CEST] <Prelude2004c> http://pastebin.com/raw/bpct6R03
[03:22:52 CEST] <Prelude2004c> i am so confused. i have chnaged options soo many times... i don't know what those errors are. the files play fine in VLC but when i try to use ffmpeg to convert it gives me all those errors :(
[03:24:33 CEST] <Prelude2004c> maybe its because i am outputing mpegts ?
[03:24:40 CEST] <Prelude2004c> some other format may work better ?
[03:26:50 CEST] <petecouture> I'm lookin at it now
[03:26:54 CEST] <petecouture> used to get that issue all the time
[03:26:59 CEST] <petecouture> but your script is different then I've seen
[03:27:04 CEST] <petecouture> Is NvTranscoder the source encoder?
[03:37:49 CEST] <Prelude2004c> ya hardware encoder
[03:37:56 CEST] <Prelude2004c> its nvidia
[03:38:31 CEST] <Prelude2004c> i know ffmpeg has the nvenc built in but i found it uses up more resources & to decode i have to use vdpau which also requires X... with this library it can encode/decode with x running
[03:38:41 CEST] <Prelude2004c> and it uses up less CPU resorces..
[03:38:56 CEST] <Prelude2004c> the issue seems to be from the source .. not the transcoder
[03:39:13 CEST] <Prelude2004c> i don't know how to make it so the source PTS / DTS , and everything is cleanred before sending off to transcoder
[04:03:17 CEST] <fling> Why is not 'Stream #0:2' getting copied? -> http://dpaste.com/1QPB291
[05:00:07 CEST] <Gues> If I statically link ffmpeg and only use one decoder, will my binary include a small percentage of ffmpeg?
[05:00:30 CEST] <Gues> I want to use the MP3 decoder.
[05:01:16 CEST] <Gues> Also, I'm curious roughly what size my binary will be.
[05:10:45 CEST] <Prelude2004c> petecouture , you never got back to me on throughts
[05:10:47 CEST] <Prelude2004c> thoughts*
[05:13:44 CEST] <petecou__> Prelude2004c sorry I have a lot going on atm. Give me a few minutes and I'll try to work with you on that
[05:14:14 CEST] <Prelude2004c> np..thank you for trying :)
[05:14:21 CEST] <Prelude2004c> i been stuck on this for 4 days :(
[05:52:29 CEST] <Gues> Wow, the source is 48 MB, and there are 1,148,773 lines.
[10:13:34 CEST] <c0rnw19> Hello world!
[10:16:36 CEST] <c0rnw19> Someone can help me? :) I would like use ocr with ffmpeg
[10:23:15 CEST] <loopsmark> Hi, this is quite a noob question, but after compiling the sources in raspbian I dont get the .so libraries, eventhouhg in ./configre I passed the --enable-static parameter. Could someone give me a hint?
[10:27:27 CEST] <c0rnw19> http://stackoverflow.com/questions/36373582/how-can-i-hide-a-text-on-udp-vi…
[10:37:03 CEST] <jkqxz> loopsmark: so == Shared Object. Try --enable-shared, not --enable-static.
[10:38:52 CEST] <loopsmark> jkqxz: yes yes yes, makes sense
[11:06:31 CEST] <mrteatime> Anyone got any ideas for a muxer that supports raw video, im using avi atm and ive gotten my rawvideo over udp stream to be almost completely stable (i also have around 100ms latency wew) but just need a touch more error correction
[11:06:52 CEST] <mrteatime> I would use matrosky but its not officially supported so ffplay doesnt like getting rawvideo from it.
[11:09:48 CEST] <CoJaBo> c0rnw19: ..what are you trying to do lol
[11:10:52 CEST] <mrteatime> Stream a rawvideo feed over a usb3.1 cable to a separate machine that will handle the encoding process.
[11:11:56 CEST] <mrteatime> Really i was just trying to eliminate as much overhead as i can, and decided stripping the encoding process on the source machine would solve alot of over head (i dont have to encode, decode and then reencode if i stream uncompressed)
[11:12:22 CEST] <mrteatime> The issue now is just finding a better container than avi that supports uncompressed :/
[11:12:43 CEST] <fling> The video got encoded with the wrong fps set. How do I fix?
[11:13:04 CEST] <fling> '-filter:v "setpts=10" -c copy' gives me 'Filtering and streamcopy cannot be used together.'
[11:13:16 CEST] <CoJaBo> mrteatime: MKV?
[11:13:48 CEST] <fling> ahh I should set the input framerate instead&
[11:14:20 CEST] <mrteatime> Yeah mkv is matrosky, i would use that but ffplay likes to shit itself if i try to play the udp stream, something about invalid header info
[11:14:54 CEST] <mrteatime> Granted i may just be missing a setting since to encode rawvideo mkv you have to force -allow_raw_vmw to do it.
[11:15:42 CEST] <mrteatime> matroska*
[11:17:35 CEST] <fling> It does not work. How do I set the new framerate for a video without a reencode?
[11:19:05 CEST] <c0rnw19> CoJaBo: I would like detect and hide a text
[11:19:22 CEST] <CoJaBo> that moves?
[11:19:40 CEST] <c0rnw19> yes.. I need to detect this position
[11:19:55 CEST] <CoJaBo> ..yeh, you're probably already doing it the optimal way then
[11:20:25 CEST] <CoJaBo> If it moves slowly, one optimization would be to crop to a bit larger than the last known rect before running the OCR
[11:20:39 CEST] <c0rnw19> with emgucv and opencv is possible I know, but very very slow.. maybe with ffmpeg will be faster
[11:20:56 CEST] <CoJaBo> AFAIK, ffmpeg does not have an OCR.. lol
[11:21:28 CEST] <c0rnw19> but when I compile, why I enable tesseract?
[11:23:13 CEST] <fling> How do I workaround this? -> https://trac.ffmpeg.org/ticket/926
[11:23:57 CEST] <CoJaBo> c0rnw19: huh, damn, there is an OCR filter. Doesn't look like it exports anything but the raw text tho
[11:25:15 CEST] <CoJaBo> c0rnw19: tesseract in ffmpeg isn't going to be any faster than tesseract in something else. It's still OCR, and OCR is slow.
[11:25:16 CEST] <c0rnw19> CoJaBo: hmm ok thanks:) And what do you think, which method can I use ?
[11:26:14 CEST] <CoJaBo> the sad part is, I have an app that does almost exactly that, but it's not something I can redistribute >_>
[11:26:22 CEST] <fling> How do I perform this using ffmpeg instead of gpac? -> MP4Box -add SourceMovie.mp4#video -raw 1 -new test && MP4Box -add test_track1.h264:fps=30 -new DestMovie.mp4
[11:26:52 CEST] <c0rnw19> If I compare an img that include my text? maybe more faster than ocr
[11:29:44 CEST] <CoJaBo> c0rnw19: If the text doesn't change, a pattern-recognition algo may be faster
[11:29:59 CEST] <CoJaBo> c0rnw19: Also, the crop thing I told you about
[11:30:34 CEST] <c0rnw19> no it doesn't change
[11:32:50 CEST] <c0rnw19> CoJaBo: can do this with ffmpeg "pattern-recognition"?
[11:33:52 CEST] <CoJaBo> I would doubt ffmpeg comes with pattern-recognition built-in lol..
[11:35:57 CEST] <CoJaBo> It's possible tesseract itself could sorta work that way if you messed with the character DB tho.. At the least, maybe removing all but the characters appearing in the string
[11:37:00 CEST] <CoJaBo> Or hell, all but one character, and figure out the bounding rect from that one. No idea how that'd impact speed/reliability tho
[11:39:11 CEST] <c0rnw19> Hmm, I found this : https://github.com/vadimkantorov/cvpr2014..
[11:39:46 CEST] <c0rnw19> If I edit dictonnary of tesseract? and leave only character that I need
[11:40:28 CEST] <CoJaBo> Also this https://github.com/tesseract-ocr/tesseract/wiki/TrainingTesseract
[11:40:49 CEST] <CoJaBo> If you can get a clean image of your text string, train it on that
[11:42:02 CEST] <CoJaBo> I maanaged to abuse the hell out of a facial-recognition tool to get it to recognize other objects once lol
[11:43:27 CEST] <c0rnw19> hehe :D , yes I will try...
[11:47:23 CEST] <c0rnw19> from doc : Tesseract is slower with large character set languages (like Chinese)
[11:47:24 CEST] <c0rnw19> :D
[12:03:38 CEST] <neuro_sys> Which would be faster to *read*? 1.5 GB raw set of BMP images or 40mb mp4?
[12:08:37 CEST] <c0rnw19> CoJaBo: do you know how can I train from clear image?
[12:12:38 CEST] <durandal_1707> neuro_sys: depends what an how much is disk reading faster than mp4 decoding
[12:17:28 CEST] <neuro_sys> I see
[12:19:00 CEST] <brontosaurusrex> vp9 with: -pix_fmt yuv420p -c:v libvpx-vp9 -crf 21 -threads 16 -tile-columns 6 -frame-parallel 1 -b:v 0
[12:19:26 CEST] <brontosaurusrex> looses over similary-bitrated x.264 everytime, what am I missing?
[12:26:11 CEST] <neuro_sys> I just realized that this doesn't work: ffmpeg -i base_video.mp4 -i animation_part1/%4d.png -i animation_part2/%4d.png -filter_complex "[0:v][1:v]overlay=enable='between(n, 100, 300)'[out1];[out1][2:v]overlay=enable='between(n, 500, 600)'[out2]" -map '[out2]' output.mp4
[12:26:44 CEST] <neuro_sys> It produces overlays using only the first frame in [1:v] and [2:v]
[12:29:42 CEST] <brontosaurusrex> trying -speed 0 now .... (getting 0.5 fps, lol)
[12:36:48 CEST] <CoJaBo> c0rnw19: the link i just sent
[12:49:20 CEST] <c0rnw19> CoJaBo: Yes I'm reading, but my english isn't very good :D
[13:34:27 CEST] <mrteatime> Ok so weve had a development, i managed to achieve around 200ms latency using tcp and tweaking my tcp settings, now that i have the whole how to stream the raw feed thing out of the way ive run into another issue.
[13:36:28 CEST] <mrteatime> Ffmpeg is outputting the rawvideo stream at less than the 60 fps i am telling it to, namely at a speed of 0.268x, id imagine thats supposed to be based on cpu usage, but ffmpg is only using 15% so clearly im missing something here.
[13:39:09 CEST] <khali> hello everyong
[13:39:17 CEST] <khali> everyone, even
[13:39:31 CEST] <mrteatime> Gday
[13:39:40 CEST] <khali> is there any documentation available for the -f libav input options?
[13:40:03 CEST] <khali> I see examples of it in many places, but can't find a list of options and what they do
[13:45:31 CEST] <jkqxz> khali: <http://ffmpeg.org/ffmpeg-formats.html>?
[13:55:57 CEST] <loopsmark> Hi everyone, I am initializing the AVCodecContext, which is loading the AV_CODEC_ID_MJPEG, with width and height, but I am getting "Picture size 960x0 is invalid" but I actually initialize it with width 1280 and height 960. Someone knows why does that happens?
[14:01:56 CEST] <jkqxz> You aren't using the headers from the same version, maybe? (Fields can move between versions.)
[14:03:02 CEST] <khali> jkqxz: I can't see anything related to libav as an input on that page, sorry
[14:03:11 CEST] <loopsmark> hmmm, could be could be, I'll double check!
[14:06:55 CEST] <jkqxz> khali: Do you actually mean -f lavfi, as in the delogo bug you're poking? Then <http://ffmpeg.org/ffmpeg-filters.html#Video-Sources>.
[14:07:00 CEST] <mrteatime> anyone know why this "ffmpeg -r 60 -f gdigrab -offset_x 0 -offset_y 0 -video_size 1920x1080 -i desktop -vf fps="fps=60" -video_size 1920x1080 -f rawvideo -pixel_format rgb32 -fflags nobuffer tcp://127.0.0.1:1234" would never output atleast 1x encoding speed
[14:07:28 CEST] <mrteatime> Ive even dropped the reso to 640x360 and gotten a cpu usage of literally 2%, still it refuses to go above 0.5x
[14:07:41 CEST] <khali> jkqxz: I think I found what I need: http://ffmpeg.org/ffmpeg-filters.html#Video-Sources
[14:07:57 CEST] <khali> ah, lol, you just wrote that, I'm slow ^^
[14:08:04 CEST] <relaxed> mrteatime: that should be -pix_fmt rgb32
[14:08:10 CEST] <khali> jkqxz: thanks, btw
[14:08:31 CEST] <jkqxz> Heh :)
[14:08:46 CEST] <mrteatime> @relaxed pixel_format rgb32 works, my issue is the output framerate doesnt match the fps values i set
[14:08:47 CEST] <relaxed> mrteatime: and "ffmpeg -framerate 60 ...
[14:09:13 CEST] <mrteatime> again -r is exactly the same setting as -framerate
[14:09:20 CEST] <relaxed> rtfm
[14:09:24 CEST] <khali> jkqxz: the delogo bug is fixed as far as I can see
[14:09:35 CEST] <khali> just waiting for someone to review my patch
[14:10:25 CEST] <khali> jkqxz: I've attached it to the bug... do you think I should post it to the list too?
[14:11:07 CEST] <mrteatime_> relaxed if you want to be a complete dipshit you might want to read the manual yourself
[14:11:24 CEST] <mrteatime_> Both of the things you mentioned are literally just different ways of writing exactly the same thing
[14:11:28 CEST] <mrteatime_> aka they are the same fucking command
[14:12:04 CEST] <mrteatime_> now if you cant figure out why the params i posted arent encoding at full speed, dont say anything
[14:12:53 CEST] <jkqxz> khali: Probably best if you post it to the list yourself.
[14:12:57 CEST] <speak> mrteatime_: I don't know which version you're using of ffmpeg, but the manual says they differ nowadays (I don't know if that affects the issue you are both talking about, though)
[14:13:50 CEST] <mrteatime_> speak_: it was more use -framerate instead of r, and -pxl_fmt instead of -pixel_format
[14:14:17 CEST] <mrteatime_> They are interchangeable basically.
[14:15:23 CEST] <speak> Alright
[14:15:43 CEST] <relaxed> from the man page, "This is not the same as the -framerate option used for some input formats like image2 or v4l2 (it used to be the same in older versions of FFmpeg)."
[14:15:57 CEST] <relaxed> OH SNAP
[14:15:57 CEST] <mrteatime_> Relaxed, im using the latest version of ffmpeg
[14:16:04 CEST] <mrteatime_> if it was on the manual page, my code wouldnt work
[14:16:05 CEST] <mrteatime_> period
[14:16:14 CEST] <mrteatime_> Read the fucking manual
[14:16:27 CEST] <relaxed> I just quoted from it
[14:16:57 CEST] <jkqxz> -framerate and -r don't do the same thing at all. -framerate is an option to some inputs to set the capture framerate. -r is a global option which tells it to throw away input timestamps and make up new ones with the given fixed framerate.
[14:17:24 CEST] <relaxed> mrteatime_: see, you need to listen more and stop assuming you know everything.
[14:17:25 CEST] <jkqxz> In this case, you want to set the capture framerate, so you want -framerate.
[14:17:39 CEST] <mrteatime_> Oh would you look at that, i changed it to -framerate instead of -r
[14:17:42 CEST] <mrteatime_> guess what happened
[14:17:44 CEST] <mrteatime_> it broke the stream
[14:17:50 CEST] <mrteatime_> Now it wont play at all *gasp*
[14:22:39 CEST] <jkqxz> (gdigrab framerate defaults to ntsc (29.97). With your -r set to throw away those timestamps and treat it as fixed-60fps it probably tries to play back at double speed. The streaming might do something weird to that, though: try writing to a file instead to test.)
[14:47:57 CEST] <khali> jkqxz: will do, thanks
[17:55:03 CEST] <dmccabe> Internet Explorer is turning the white background in my h264 video to light gray. All other browsers display white. Can ffmpeg set a color space for web that will display correctly?
[18:00:04 CEST] <vade> my ffmpeg libavformat encode to h.264 via x264 is missing the last frame. Im making sure to flush my decoders output, and my encoders output, and my packet read and written, and frame decoded and encoded count match, however im defiitely missing the last frame. Is this a known issue ? I see a lot of reports regarding this now that ive looked
[18:05:37 CEST] <Kanov> is it possible to merge two .mkv files with two different subtitles?
[18:08:31 CEST] <c_14> merge as in concatenate?
[18:10:52 CEST] <neuro_sys> Could anyone please take a look at this filter I'm trying included with the assets? ~/ffmpeg-3.0.2-64bit-static/ffmpeg -y -i small.mp4 -i monkey/monkey_%04d.png -filter_complex "[0:v][1:v]overlay=enable='between(t, 1, 5)'[out1]" -map '[out1]' output.mp4
[18:10:56 CEST] <neuro_sys> woops
[18:10:58 CEST] <neuro_sys> https://drive.google.com/file/d/0BxIQVP1zErDPYXRveG9hN0c0Qjg/view?usp=shari…
[18:12:11 CEST] <neuro_sys> Disregard the wrong paste, google drive one has the tarball
[18:15:52 CEST] <Kanov> c_14; correct
[18:16:12 CEST] <c_14> Kanov: as long as both are text, I don't see a problem
[18:16:30 CEST] <Kanov> c_14; what do you mean by text
[18:16:57 CEST] <Kanov> c_14; .mkv is a video file
[18:17:20 CEST] <c_14> Kanov: both subtitle streams, ass or srt or something like that instead of pgs etc
[18:17:36 CEST] <Kanov> c_14; yes the subtitles are both .srt
[18:17:48 CEST] <Kanov> c_14; can you give me a command which can do this please
[18:18:23 CEST] <c_14> https://trac.ffmpeg.org/wiki/Concatenate
[18:19:18 CEST] <Kanov> but what about the subtitles
[18:19:31 CEST] <c_14> that should just work
[18:19:48 CEST] <c_14> Or does each file have multiple subtitle streams?
[18:19:52 CEST] <c_14> In that case you just need to add a map
[18:20:13 CEST] <Kanov> ok
[18:20:42 CEST] <c_14> neuro_sys: looks like a bug to me
[18:22:03 CEST] <neuro_sys> c_14: when I remove enable option, it just works, except I can't specify the interval it should overlay on...
[18:22:44 CEST] <neuro_sys> I thought the possibility of its being a bug, or I'm just misunderstanding the use of enable in there.
[18:23:01 CEST] <c_14> When I removed the enable it still didn't work, let me retest
[18:23:10 CEST] <neuro_sys> I'm thinking of another way to overlay a series of images on top of a video at a specific interval
[18:23:37 CEST] <c_14> Oh, it does. Must have messed something up
[18:24:12 CEST] <c_14> You could turn the images into a video and then overlay that instead
[18:24:22 CEST] <neuro_sys> c_14: would a video keep alpha channel?
[18:24:39 CEST] <neuro_sys> also, I was wondering if I could use trim filter to try it in a different way
[18:25:11 CEST] <neuro_sys> I also plan on turning the video into images beforehand, and use imagemagick to overlay them, and later put back into a video but it sounds very inefficient.
[18:25:36 CEST] <c_14> neuro_sys: depends on the codec, some can. It will as long as it has an 'a' in the pixel format like gbra or yuva444p etc
[18:26:17 CEST] <neuro_sys> okay, I should find a suitable codec and try with that then
[18:29:57 CEST] <c_14> ffv1 should work
[18:35:20 CEST] <neuro_sys> c_14: I tried it to no avail.
[18:35:28 CEST] <neuro_sys> but wait
[18:37:17 CEST] <neuro_sys> https://gist.github.com/neuro-sys/09bdab432bbaf4e6b16c0a4d61465433
[18:37:36 CEST] <neuro_sys> This is the script I tried
[18:38:03 CEST] <neuro_sys> other than the alpha channel, it seems to do with the way enable option works.
[18:40:04 CEST] <neuro_sys> I wonder what other options I have, if not with ffmpeg
[18:44:47 CEST] <rubdos> Hi! Downconverting hi10 to standard 8 bit x264 seems very slow to me. I'm on a 5th gen Core i5 i5-5200U, 8GB of RAM and it only goes at 0.35x
[18:45:18 CEST] <rubdos> Command used: ffmpeg -i "$i" -vcodec libx264 -crf 19 -acodec copy out/$i
[18:45:38 CEST] <c_14> resolution?
[18:45:41 CEST] <rubdos> 1080p
[18:46:34 CEST] <rubdos> I would think that chopping of two bits wouldn't take so long, but converting this whole thing takes 38 hours to complete... A bit long for me ^^
[18:47:01 CEST] <c_14> It does have to reencode the entire video (and decode the 10bit part as well)
[18:47:40 CEST] Action: rubdos feels sad now.
[18:47:49 CEST] <c_14> you can use a faster preset
[18:48:17 CEST] Action: c_14 gets about 1.4x here with content that's easy to encode and without decoding on a Core i7
[18:48:59 CEST] <rubdos> I wouldn't think this is easy to encode. What preset do you use?
[18:49:08 CEST] <rubdos> (if I may ask)
[18:49:16 CEST] <c_14> default which is medium
[18:49:41 CEST] <rubdos> so, no -crf then?
[18:49:44 CEST] <c_14> neuro_sys: try adding -pix_fmt bgra when creating the mkv from the images
[18:49:51 CEST] <c_14> rubdos: -crf 19
[18:50:01 CEST] <c_14> neuro_sys: I don't think bgr0 (which is what it chose by default here) has alpha
[18:50:07 CEST] <rubdos> oh, so, exactly what I was using then... :(
[18:50:28 CEST] Action: rubdos Wonders whether he should have gone with the i7 model on this thing.
[18:51:28 CEST] <neuro_sys> c_14: It solves alpha, thanks
[18:52:02 CEST] <neuro_sys> however yet remains the dark mystery of a broken continous overlay animation
[18:53:19 CEST] <jkqxz> rubdos: The gain would not be significant if it's still a Broadwell-U (5600U or whatever). You need a chip with much higher TDP to make any useful gain.
[18:53:41 CEST] <rubdos> jkqxz, that's what I thought when I bought this thing, glad I'm kinda right :)
[18:54:12 CEST] <rubdos> sigh. I'll have to order a 16 core Xeon with some nVidia's to transcode this thing then... :D
[18:54:22 CEST] Action: rubdos made a joke. Doesn't have the money.
[18:56:08 CEST] <c_14> neuro_sys: probably still the same bug, just that it isn't related to the image2 filter but rather always happens with overlay and enable
[19:08:25 CEST] <neuro_sys> c_14: Apparently so. Are you one of the ffmpeg devs?
[19:08:54 CEST] <c_14> I have written patches for ffmpeg, but I wouldn't call myself an ffmpeg dev.
[19:40:18 CEST] <pgorley> In this table: https://trac.ffmpeg.org/wiki/HWAccelIntro#FFmpegImplementations what does the AVHWAccel column represent exactly?
[19:41:08 CEST] <pgorley> This link should direct to the right anchor, sorry: https://trac.ffmpeg.org/wiki/HWAccelIntro#FFmpegimplementations
[19:46:30 CEST] <DHE> pgorley: http://ffmpeg.org/doxygen/3.0/structAVHWAccel.html I believe it refers to this
[19:47:31 CEST] <pgorley> Basically a call to ff_find_hwaccel wouldn't return null?
[19:48:17 CEST] <DHE> as I understand it ff_* functions are considered private and not for users to use
[19:49:03 CEST] <pgorley> Oh, I'll keep that in mind then, thanks
[19:50:28 CEST] <DHE> docs on hwaccel are not as easy to find...
[19:51:14 CEST] <pgorley> I noticed haha
[19:51:52 CEST] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/qsvdec.c
[19:51:56 CEST] <JEEB> example that uses one of the hwaccels
[19:52:31 CEST] <JEEB> do note that the hwaccels are just helpers putting the usage of a given hardware decoder within the libavcodec framework
[19:52:46 CEST] <JEEB> you still need to do the initialization/whatever on your own side of related things
[19:53:28 CEST] <pgorley> Thanks
[19:54:42 CEST] <JEEB> it's usually a good idea to also take a look at how the hwaccel for the thing you are planning to use looks like
[19:54:52 CEST] <JEEB> inside libavcodec
[20:13:43 CEST] <vade> what circumstances would a AVFrame decoded from avcodec_decode_video2 return a DTS thats AV_NOPTS_VALUE ?
[20:13:46 CEST] <vade> the last frame?
[20:19:51 CEST] <DHE> well, frames don't have a DTS. only a PTS. they're not encoded so no decoding is required
[20:20:26 CEST] <DHE> if you mean pkt_pts, the docs say it's not filled in when threaded decoding is used, so that might be related
[20:21:01 CEST] <vade> yes apologies, pkt_dts
[20:22:14 CEST] <vade> im having an issue where it appears a frame vanishes in my output compared to my input. Ive demuxed 120 packets, decoded 120 frames, encoded 120 frames, and muxed 120 packets to my container MP4 - Quicktime indicates frame 59 has vanished
[20:22:16 CEST] <vade> literally
[20:22:42 CEST] <vade> but I think its how it counts frames based on the duration of a track
[20:22:49 CEST] <vade> its half way through. I have a video :
[20:23:03 CEST] <vade> https://www.dropbox.com/s/6v62cqmh84mfqvr/LOST%20A%20FRAME.m4v?dl=0 (source on left, re-encode on right)
[20:23:43 CEST] <vade> stepping through timecode tagged frames shows me the issue. I m using av_rescale_q_rnd with AV_ROUND_NEAR_INF | AV_ROUND_PASS_MINMAX
[20:24:43 CEST] <vade> but i cant deduce where its happening in my liav* code
[20:24:53 CEST] <vade> *libav rather
[20:25:15 CEST] <vade> only thing I see is the last, and only the last decoded AVFrame has that no pts
[20:25:21 CEST] <vade> for pak_dts
[20:25:59 CEST] <JEEB> you should check with L-SMASH's boxdumper the timestamps for your output
[20:26:43 CEST] <JEEB> you can either get a textual representation of the whole container structure and most common values in those structures, or just the CTS/DTS
[20:26:53 CEST] <JEEB> (CTS is what is generally called PTS)
[20:37:20 CEST] <vade> Thanks, ill investigate.
[20:40:52 CEST] <storrgie> I'm using number 6 on this list to add text to a video (https://sites.google.com/a/asu.edu/wireless-video-sensor/video/how-to-setup…) but the re-encoded video has a lot of abberations in it and is significantly smaller in size than the original. Is there something I can do to preserve the original quality?
[20:41:52 CEST] <JEEB> that's because you're not setting a video encoder nor any rate control
[20:42:06 CEST] <JEEB> you can see in your terminal output which video encoder your ffmpeg build picked
[20:43:27 CEST] <JEEB> (most encoders just default to 200kbps ABR for rate control, which sounds like what's happening)
[20:43:32 CEST] <JEEB> basically somewhere after the input file you do -c:v libx264 -crf 23
[20:43:33 CEST] <JEEB> that uses the libx264 encoder which is probably the best stuff you can stuff into an mp4
[20:43:43 CEST] <storrgie> you're right, I did `-vcodec libx264 -vb 5000k` and it changed significantly
[20:43:56 CEST] <JEEB> don't use bit rate based rate control unless specifically required
[20:44:10 CEST] <JEEB> esp. with 1pass encoding
[20:44:18 CEST] <storrgie> im using what you specified now, looks great
[20:44:28 CEST] <JEEB> basically that's the default CRF value
[20:44:35 CEST] <JEEB> if it looks bad, go lower
[20:44:39 CEST] <JEEB> if it looks good, go higher
[20:44:51 CEST] <JEEB> then at some point you have found the highest CRF value that still looks good for you
[20:45:27 CEST] <JEEB> perfect for when you don't have a note somewhere saying "your file must be of file size X"
[20:45:37 CEST] <JEEB> which is the only reason to use 2pass bit rate based rate control
[20:46:05 CEST] <JEEB> (if this video is to be used through limited bandwidth pipes then you will want to use -maxrate and -bufsize to limit CRF)
[20:47:00 CEST] <JEEB> maxrate being the maximum average rate over bufsize that the video is to be able to take. it can take less, but it will limit the encoder to that as a maximum.
[20:47:11 CEST] <storrgie> nah, we're just shooting it over to someone for a presentation
[20:47:14 CEST] <storrgie> it just needed to be watermarked
[20:47:33 CEST] <JEEB> ok, then do some tests with CRF values to optimize it for compression and quality for yourself => done
[20:48:04 CEST] <vade> JEEB: so this is interesting. FFMPEG command line takes 120 frames in and returns 121 frames out for a transcode. However it is NOT missing the middle frame, but has an *extra* frame at the end
[20:48:16 CEST] <storrgie> JEEB, thanks a ton!
[20:51:51 CEST] <vade> man, even the FFMPEG converted file opened in premier starts on frame 2
[20:52:55 CEST] Action: vade is thoroughly confused
[21:22:17 CEST] <leshaste> I have two video files, one that is in a supported format and one that isn't. I would like to convert the unsupported one into exactly the codec etc that the support one uses
[21:22:20 CEST] <leshaste> is that possible?
[21:32:32 CEST] <leshaste> actually waht I need to do is to convert from h264 (High) to h264 (Main)
[21:34:00 CEST] <furq> leshaste: -c:v libx264 -profile:v main
[21:35:12 CEST] <leshaste> as a full command line is that ffmpeg -i video.mkv -c:v libx264 -profile:v main output.mp4 ?
[21:35:17 CEST] <furq> yes
[21:35:23 CEST] <furq> you probably also want -c:a copy
[21:37:17 CEST] <leshaste> thank you. Is there a multicore option?
[21:37:28 CEST] <furq> x264 will use all cores by default
[21:37:46 CEST] <leshaste> oh yes silly me
[21:37:48 CEST] <furq> you can use -threads n if you want manual control over it
[21:37:52 CEST] <leshaste> thanks.. it is whirring away
[21:37:54 CEST] <furq> but the default is generally the right choice
[21:38:01 CEST] <leshaste> all cores at 25% strangely
[21:38:40 CEST] <leshaste> it should give you a time estimate
[21:54:52 CEST] <DHE> don't you still need to do the whole bitrate selection thing, etc?
[21:58:35 CEST] <Mous> hello
[21:59:29 CEST] <Mous> i have high fps video but it has some artifacts is there a filter that would increase the quality?
[22:04:15 CEST] <vade> ok, im utterly confused - @JEEB i wrote a simple packet/sample buffer inspector using AVFoundation on OS X, and the last 3 values for my PTS and DTS are being reported as invalid by the Core Media / AVFoundation decoder - but previous samples perfectly align with what my FFMPEG based livAV encoder and muxer pass in
[22:26:19 CEST] <JEEB> vade: if you want to confirm what's in the container, use L-SMASH's boxdumper
[22:29:01 CEST] <vade> yeah, timestamps look good there. God damn it.
[22:29:09 CEST] <vade> must be an AVF bug
[22:32:42 CEST] <naildeca> I just installed ffmpeg 3.0 , when I run it, it says the delogo filter does not exist. Should I have put something with ./configure?
[22:33:16 CEST] <vade> interestingly enough, the file produced from a simple FFMPEG transcode also note invalid DTS and PTS in AVfoundation on OS X
[22:53:44 CEST] <yongyung> What is the difference between using (libx264) -b:v 1000k -bufsize 1000k and -maxrate 1000k -bufsize 1000k?
[22:57:32 CEST] <Mous> is there better explanation of -tune options? because i cant find any
[22:58:43 CEST] <vade> yea im utterly confused here.
[22:58:43 CEST] <pzich> Mous: http://superuser.com/a/564404
[22:59:06 CEST] <Mous> ty pzich
[22:59:26 CEST] <pzich> googling for "ffmpeg tune" got me there, BTW
[22:59:38 CEST] <kepstin> there's also the secret undocumented 'touhou' tune, but that's pretty rarely useful ;)
[22:59:41 CEST] <Mous> hmm not me
[00:00:00 CEST] --- Wed May 11 2016
1
0
[00:03:10 CEST] <cone-142> ffmpeg 03Josh de Kock 07master:6bb99757b780: jack: Support OSX
[00:03:11 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:dc0152548f03: Merge commit '6bb99757b780144d9fa27cdce09d3621e1a0ed43'
[00:08:09 CEST] <cone-142> ffmpeg 03Luca Barbato 07master:1db8eb154908: avconv: Drop an unused variable
[00:08:10 CEST] <cone-142> ffmpeg 03Tim Walker 07master:fef2147b7a68: eac3dec: don't call avpriv_request_sample every frame.
[00:08:11 CEST] <cone-142> ffmpeg 03Tim Walker 07master:33275a0de05e: ac3dec: change logging of skipped E-AC-3 substreams.
[00:08:12 CEST] <cone-142> ffmpeg 03Mark Thompson 07master:b3051a460cf0: vaapi_h264: Fix bit offset of slice data.
[00:08:13 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:9109b5240b5e: Merge commit '1db8eb154908cde577477b6ab17430a0cd46b7bd'
[00:08:14 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:15cb52577a84: Merge commit 'fef2147b7a689b80d716c3edb9d4a18904865275'
[00:08:15 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:13b77e09c7e9: Merge commit '33275a0de05e9bc321f2537a2a67921fab81624f'
[00:08:16 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:2d2af18f42c9: Merge commit 'b3051a460cf02a5b86ff0d1e14abba23ea55ff6d'
[00:26:43 CEST] <cone-142> ffmpeg 03Luca Barbato 07master:e3453fd44480: matroska: Write the field order information
[00:26:44 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:ee865e9780b4: Merge commit 'e3453fd44480d903338c663238bf280215dd9a07'
[00:27:56 CEST] <cone-142> ffmpeg 03Diego Biurrun 07master:4c6836db0f30: nvenc_h264: Fix name of private AVClass
[00:27:57 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:f0d4f3026d0f: Merge commit '4c6836db0f300d2c0401c6a1927a95c3258cc1ae'
[00:28:45 CEST] <Daemon404> q
[00:33:25 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:51dc4de1218a: rscc: Add extended pixel format support
[00:33:27 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:dd2d26dc82b8: Merge commit '51dc4de1218a81ee8e5b3f941839c5e3125a6d4b'
[00:34:21 CEST] <jamrial> i thought the matroska spec allowed elements to be ignored if they are not recognized?
[00:34:36 CEST] <jamrial> as in, non webm elements in a webm file shouldn't make it unreadable
[00:34:48 CEST] <Daemon404> sure but we shouldnt write it anyway
[00:34:57 CEST] <Daemon404> if it is technically wrong
[00:35:23 CEST] <jamrial> yeah, that's true
[00:42:46 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:b5f47d95c6cb: fate: Update RSCC tests
[00:42:47 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:e4c8e1906440: Merge commit 'b5f47d95c6cb8ffa9982eb8fd3e9ab5c9f97e914'
[00:43:04 CEST] <Daemon404> i already synced samples to our fate suite ^
[00:47:29 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:95db8c757cb0: screenpresso: Add extended pixel format support
[00:47:30 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:ec8a69fab657: screenpresso: Correctly handle keyframes
[00:47:31 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:8dde92b95a19: fate: Update Screenpresso tests
[00:47:32 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:5d31074daf0e: Merge commit '95db8c757cb003a71b040b567f38be74151deb5c'
[00:47:33 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:483e9d8a2bb4: Merge commit 'ec8a69fab657f9cce624e8b0f4069d12696890bf'
[00:47:34 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:486776d06f6e: Merge commit '8dde92b95a197eb809d798aacb34dbe52a0689a8'
[00:55:52 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:9a9fb710bcf4: dds: Add support for rgb555 files
[00:55:53 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:02538636261f: dds: Add support for alpha-only files
[00:55:54 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:22e49e6edead: dds: Simplify postprocessing check
[00:55:55 CEST] <cone-142> ffmpeg 03Vittorio Giovara 07master:00658253e237: fate: Update DDS tests
[00:55:56 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:6c007036850c: Merge commit '9a9fb710bcf4657e030467cfe2556cb0e2c01afc'
[00:55:57 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:6ebec1049ea6: Merge commit '02538636261fdec9c70f4185b23147c636f269b4'
[00:55:58 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:d62984d8a081: Merge commit '22e49e6edead9c83696f20127988f659b952ce65'
[00:55:59 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:68b8505d4d3f: Merge commit '00658253e237ab975ae2d384e02b5936781f103d'
[00:58:12 CEST] <cone-142> ffmpeg 03Diego Biurrun 07master:e656a6ccd9ca: configure: cosmetics: Drop pointless end-of-line semicolons
[00:58:13 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:38eeb85ff344: Merge commit 'e656a6ccd9cab1b0a79cffe3e609793857aae330'
[00:58:55 CEST] <Daemon404> thats enough for todya.
[03:29:56 CEST] <Compn> http://www.sciencemag.org/news/2016/04/whos-downloading-pirated-papers-ever…
[03:30:59 CEST] <Compn> That has forced the site to move to sci-hub.bz and sci-hub.cc.
[03:31:03 CEST] <Compn> ah thats where it went...
[08:34:43 CEST] <rcombs> anyone know why nv12 is explicitly excluded from drawutils support?
[08:34:58 CEST] <rcombs> afaict it works fine, at least for vf_subtitles
[08:35:59 CEST] <rcombs> oh, wait, it does fuck up the chroma
[08:36:04 CEST] <rcombs> alright, I'll fix that
[09:10:22 CEST] <durandal_1707> why hwdownload and hwupload filters are not documented?
[09:44:52 CEST] <j-b> 'morning
[10:36:54 CEST] <yann> looks like dca23ff and f3aff31 introduce an API change, which is not documented in APIchanges, right?
[10:41:06 CEST] <nevcairiel> its not exactly an api change, just deprecation of existing API, and the replacements existed for a l ong time before that already, but it wouldnt do any harm to list it in api changes
[10:43:48 CEST] <yann> at least it's surprising, when upgrading to 3.0, to get deprecatation warnings and having to git blame to get the info :)
[10:47:43 CEST] <wm4> yann: is it not in apichanges.txt?
[10:47:51 CEST] <wm4> well, doc/APIchanges
[10:48:13 CEST] <yann> did not find it, and the commits listed above do not touch this file
[10:49:02 CEST] <wm4> right, AVPicture itself seems to be missing from that file
[10:49:07 CEST] <wm4> it shouldn't
[10:49:08 CEST] <nevcairiel> avpicture* didnt seem to occur much in the file
[10:56:29 CEST] <yann> I'm also wondering, since I am using AVPicture precisely because we can cast an AVFrame to it, if the change is really beneficial - I am conditionally doing colorspace conversion after decoding, and I'm using the AVFrame-castability-to-AVPicture so the next steps don"t have to bother what they got - with imgutils it seems to me I basically have to create my AVPicture equivalent, I'm not sure it really makes sense :)
[10:58:58 CEST] <nevcairiel> you can just pass the elements of an AVFrame directly to av_image_* functions, no need to have an intermediate struct
[11:00:31 CEST] <yann> yes, 2 related arrays instead of a neat struct binding them together :)
[11:01:31 CEST] <fritsch> yann: see the kodi transition from AVPicture to AVFrame we used the same av_image methods were needed
[11:01:43 CEST] <fritsch> if you are interested
[11:02:42 CEST] <fritsch> https://github.com/xbmc/xbmc/commits/master/xbmc/guilib/FFmpegImage.cpp
[11:03:32 CEST] <fritsch> if you find bugs, happy to fix them
[11:04:59 CEST] <yann> yes, using a full AVFrame is an option, but that's arguably a heavyweight struct just for 2 pointers :)
[11:06:40 CEST] <wm4> " and I'm using the AVFrame-castability-to-AVPicture "
[11:06:52 CEST] <fritsch> i hope you cast the other way round
[11:06:56 CEST] <fritsch> :-)
[11:06:58 CEST] <wm4> that's exactly why we deprecated it (or rather why I was welcoming the change)
[11:07:07 CEST] <wm4> the other way around is even worse
[11:07:57 CEST] <fritsch> both suck, especially if you try to access Frame fields
[11:08:04 CEST] <JoshX> Hello, I'm looking around in libavformat/matroskaenc.c in mkv_write_packet_internal to add one more field in the meta data (system clock)
[11:08:20 CEST] <JoshX> could anyone point me in a direction to go from here? :)
[11:08:31 CEST] <yann> fritsch: no, I'm just accessing the AVPicture fields in an AVFrame :)
[11:08:32 CEST] <fritsch> isn't systemclock some "runtime dependend" not suited for such a central field?
[11:08:38 CEST] <fritsch> yann: i thought so, yes
[11:08:49 CEST] <fritsch> but you don't know what the api, you might use does
[11:09:20 CEST] <yann> I'm really just using the data myself afterwards
[11:11:23 CEST] <JoshX> fritsch: well.. What I need is for these files to have the system time as unix timestamp available every keyframe for example.. or once a second.. this to synchronize videofiles from different sources later on in software
[11:11:38 CEST] <wm4> JoshX: does mkv have support for this?
[11:11:46 CEST] <wm4> the format itself, I mean
[11:11:50 CEST] <nevcairiel> doubtful
[11:12:04 CEST] <wm4> nevcairiel: well who knows what these cellar guys are adding
[11:12:11 CEST] <nevcairiel> there is no frame based metadata and i've never seen an element for that
[11:12:55 CEST] <nevcairiel> wm4: its funny how some idiots try to get their wishes implemented through proposing it to cellar, some guy and his crusade for mkv menu support etc =p
[11:13:09 CEST] <nevcairiel> not that it matters if no player ever is going to support it
[11:14:06 CEST] <wm4> did that menu thing advance?
[11:14:11 CEST] <nevcairiel> dont think so
[11:14:16 CEST] <wm4> good
[11:14:43 CEST] <BtbN> An optional system/unix time tag doesn't seem that bad of an idea to me though.
[11:14:52 CEST] <nevcairiel> but they didnt seem entirely opposed either
[11:15:14 CEST] <nevcairiel> BtbN: if the format defines such a field, great, but if it doesn't, we shouldnt try to invent one =p
[11:15:29 CEST] <BtbN> Doesn't mkv support arbitrary metadata?
[11:15:41 CEST] <nevcairiel> global and per track etc, but not per keyframe
[11:15:58 CEST] <BtbN> hm
[11:16:02 CEST] <nevcairiel> you could just define the unix time of the start of the file and then offset it by the timestamps
[11:16:09 CEST] <nevcairiel> not sure why you would need per-frame unix time anyway
[11:19:04 CEST] <BtbN> sure, one timestamp per file seems fine. Unless you are doing something super weird.
[11:19:28 CEST] <yann> fritsch: at least, using an AVFrame provides a quick solution, you're right :)
[11:20:24 CEST] <wm4> yann: what are you trying to do?
[11:22:27 CEST] <yann> wm4: doing an optional colorspace conversion after decoding - I was using an AVPicture internally to store the converted frame data, and an AVPicture* so the display step does not have to bother where the frame data came from
[11:23:42 CEST] <yann> so I switched to an AVFrame, at the cost of unused struct fields (and then, of the risk that someone indeed tries to use the other AVFrame fields one day)
[11:25:57 CEST] <yann> incidentally, I also have some #ifdef'd out imgutils code in there, will have to dig why I did not use it in the end - I remember that some months ago I had hit an API that was too limited, but I'm not sure it was that case - I'll dig all of this when I'll have a bit more time (which may take some undefined number of weeks ;)
[11:26:54 CEST] <wm4> well uh having your own struct for this is only 4 lines
[13:36:25 CEST] <kierank> are there any 10-bit crcs in ffmpeg
[13:50:44 CEST] <durandal_1707> kierank: no, I see only 8, 16, 24 and 32
[13:57:34 CEST] <Daemon404> non-byte multiples of bits for a crc?
[13:58:26 CEST] <kierank> correct
[14:00:50 CEST] <Daemon404> my first thought is "why"
[14:01:25 CEST] <kierank> 10-bit samples
[14:01:27 CEST] <wm4> my second thought is "probably because multimedia"
[14:01:46 CEST] <kierank> Or 20-bit in audio
[14:02:20 CEST] <nevcairiel> cant you just crc the entire buffer, regardless of how its interpreted :D
[14:02:27 CEST] <Daemon404> exactly
[14:02:49 CEST] <atomnuker> no, the polynomial has a 0th power
[14:03:03 CEST] <atomnuker> so for every 0 in the MSB your CRC changes
[14:03:19 CEST] <nevcairiel> and thats bad why?
[14:03:48 CEST] <nevcairiel> just gives you a different number, but it still tells you when anything changes
[14:03:54 CEST] <atomnuker> because it's not going to match what the hardware is going to think it should be
[14:04:03 CEST] <Daemon404> i knew it
[14:04:14 CEST] <Daemon404> "because hardware" - beoadcast
[14:04:19 CEST] <Daemon404> no actual reason
[14:04:57 CEST] <atomnuker> well, I doubt most of the hardware actually checks the CRC since I've seen bitbanged sdi
[14:05:18 CEST] <nevcairiel> in any case, you know your task then
[14:05:32 CEST] <atomnuker> but still, there has to be a CRC and it has to be valid
[14:05:36 CEST] <Daemon404> weeping ailently because he works in broadcast?
[14:05:40 CEST] Action: Daemon404 runs
[14:05:45 CEST] <Daemon404> silently*
[14:05:49 CEST] <iive> how is the 10bit data stored in memory?
[14:05:59 CEST] <kierank> When have you seen bitbanged SDI?
[14:06:00 CEST] <atomnuker> as 16 bits
[14:06:26 CEST] <atomnuker> I remember seeing some SD-SDI video on youtube where some guy implemented it on an fpga
[14:15:59 CEST] <iive> if I remember correctly, one way to implement crc is through doing shift, check for 1 and doing xor.
[14:17:29 CEST] <iive> this means that you could use crc16 for emulating crc10, using shorter polynom and doing probably 6 more "divisions" manually at the finish
[14:17:46 CEST] <iive> this however needs the 10bit data to be packed.
[14:18:21 CEST] <iive> I guess that ffmpeg uses table method with pre-calculated values
[14:19:04 CEST] <iive> I wonder if that could be used to avoid the packing...
[15:03:11 CEST] <cone-657> ffmpeg 03PrzemysBaw Sobala 07master:5fce4753ff0f: avfilter/vf_fps: set fps value boundaries
[15:15:01 CEST] <Daemon404> to fix av_dump cosmetics apply the patch asap?
[15:15:07 CEST] Action: Daemon404 sigjs
[15:22:02 CEST] <cone-657> ffmpeg 03PrzemysBaw Sobala 07master:1a3cff4f7ead: libavutil/opt: add writing AV_OPT_TYPE_VIDEO_RATE AVOption
[15:43:44 CEST] <JoshX> wm4:
[15:43:53 CEST] <JoshX> sorry was away
[15:44:16 CEST] <JoshX> wm4 yes aparently it does, there are certain axis camera's that povide this functionality
[15:44:46 CEST] <JoshX> and it is used in this python packag: vi3o (https://github.com/hakanardo/vi3o)
[15:49:16 CEST] <wm4> JoshX: which ebml elements does it use?
[15:50:00 CEST] <Daemon404> nevcairiel, fyi get_bits64 exists in ffmpeg :P
[15:50:13 CEST] <nevcairiel> Daemon404: never seen that used
[15:50:21 CEST] <Daemon404> it's ffmpeg-specific
[15:51:45 CEST] <JoshX> wm4 i'm trying to find that out myself..
[15:52:30 CEST] <Daemon404> JoshX, unrelated but i see a few no-nos in that code
[15:53:01 CEST] <nevcairiel> wm4: it seems to store a index file separately
[15:53:37 CEST] <JoshX> Daemon404: it is from a customer, the use it to synchronise different videofiles and play them side by side or overlayed
[15:53:53 CEST] <JoshX> Daemon404: it synchronises using the system timestamp in the MKV
[15:53:53 CEST] <Compn> mplayer udp slave can do that
[15:54:04 CEST] <Daemon404> sure, i just thought 'd like you know the there's a few api usage problems
[15:54:15 CEST] <Daemon404> let you*
[15:54:23 CEST] <JoshX> cheers :) didn't write it..
[15:54:28 CEST] <JoshX> :-)
[15:54:40 CEST] <Daemon404> ;)
[15:54:48 CEST] <JoshX> the customer wants us to use axis camera's for this project because 'axis can store system time per frame'
[15:54:59 CEST] <JoshX> or per keyframe..
[15:55:10 CEST] <Daemon404> thats not really unique to a certain camera
[15:55:29 CEST] <Daemon404> lots of containers can store metadata
[15:55:38 CEST] <JoshX> i guess axis abuses a field and stores the epoch in it every keyframe or so
[15:56:07 CEST] <JoshX> true.. i know mkv can :-) i just don't know (yet) what field is used
[15:56:11 CEST] <BtbN> And what's the problem with one timestamp per file? Is "start timestamp + playtime" not accurate enough?
[15:56:19 CEST] <JoshX> and then where to build it in my ffmpeg version :)
[15:56:55 CEST] <Daemon404> BtbN, its just the age old story of "proprietary thing uses proprietary way to store normal data that doesnt even need it"
[15:56:55 CEST] <JoshX> BtbN: they want the systemtime so they can compensate for ntp-sync-hops (if that makes any sense)
[15:57:39 CEST] <BtbN> If the one timestamp it has is accurate, how could ntp interfere with that?
[15:58:34 CEST] <JoshX> you cpould detect ntp syncs by comparing the ts of the file (fixed, never changing) to the system time per frame, not fixed, could drift and be re-synced, and then compensate for that when syncing multiple files on top of eachother
[15:58:52 CEST] <JoshX> for example, 2 sides of a road
[15:59:56 CEST] <Daemon404> i guess it makes sense to have it on the camera itself then
[16:00:05 CEST] <Daemon404> but putting it in some custom field seems dubm
[16:00:07 CEST] <Daemon404> dumb even
[16:00:52 CEST] <JoshX> i know.. but for me it will be 'buying 18 camera's for this specific project, spending 1000s of euro'
[16:01:06 CEST] <JoshX> or using the setup we alwaysuse with a tweak in code somewhere
[16:01:40 CEST] <Daemon404> ive lost context now, actually, i was musing aloud
[16:01:43 CEST] <BtbN> I still don't understand what NTP has to do with this. The duration of a (micro)second rarely changes.
[16:01:44 CEST] <Daemon404> woops.
[16:02:27 CEST] <BtbN> So if you save the UTC timestamp of the first frame, you have an accurate realtime for every single frame.
[16:02:43 CEST] <JoshX> yes true, that is what i do
[16:03:16 CEST] <JoshX> i patched my ffmpeg to accept a %t in the filename what replaces with a yyyymmdd_hhiissfff
[16:03:31 CEST] <wm4> BtbN: what if there is drift etc.
[16:03:54 CEST] <JoshX> wm4: indeed :)
[16:04:02 CEST] <BtbN> What kind of drift would break video timestamps?
[16:04:06 CEST] <JoshX> then the TS of the file would be sequential and fixed
[16:04:15 CEST] <JoshX> but the systemtime could jump a few msec
[16:04:30 CEST] <JoshX> BtbN: i have videofiles from multiple sources
[16:04:36 CEST] <JoshX> multiple recorders, all ntp synced
[16:04:45 CEST] <JoshX> and a software lib that syncs these files
[16:04:54 CEST] <Daemon404> im with BtbN on this one
[16:04:58 CEST] <JoshX> using the system timestamps stored in the metadata
[16:05:00 CEST] <flux> the video capture frame rate and the time on the device holding the owlrd time can drift apart from each other, no?
[16:05:07 CEST] <JoshX> yes
[16:05:14 CEST] <BtbN> So make sure the UTC-Timestamp is accurate when it's created, done.
[16:05:32 CEST] <JoshX> so having the system timestamp, with drift, corrections, hops, whatever in lets say every keyframe
[16:05:40 CEST] <Daemon404> maybe theyre doing something dumb like generating timestamps from system time
[16:05:43 CEST] <Daemon404> or something
[16:05:49 CEST] <Daemon404> it should just be basic CFR time stamp generation
[16:05:54 CEST] <JoshX> give me the possibility to sync video files with different lenghts, even framerates and starttimes
[16:05:56 CEST] <Daemon404> then you can still sync with just the one epoch
[16:06:09 CEST] <Daemon404> JoshX, you still only need one system timestamp for that IMO
[16:06:22 CEST] <flux> related: it doesn't seem some video players (ie. mpv) work nicely when the video doesn't start at time zero
[16:06:28 CEST] <nevcairiel> all the corrections could be baked into the frame timestamps
[16:06:34 CEST] <JoshX> from the start of the file, well. yes and no
[16:06:42 CEST] <nevcairiel> flux: matroska requires to start at zero from the spec, fwiw
[16:06:50 CEST] <flux> well, mp4 doesn't (edit lists)
[16:07:07 CEST] <wm4> nevcairiel: haha
[16:07:20 CEST] <BtbN> mp4 likes to be a pain, so that's not overly surprising.
[16:07:26 CEST] <wm4> nevcairiel: I've seen many mkv files that start not from 0
[16:07:37 CEST] <nevcairiel> if its very close to zero its probably fine either way
[16:07:44 CEST] <nevcairiel> but not sure avformat even bothers to fill start_time
[16:07:46 CEST] <wm4> as in not close to 0 at all
[16:08:03 CEST] <flux> I used ths encoding: time from the start of the day.
[16:08:20 CEST] <flux> mpv has option to support this, but it doesn't really work all the way :)
[16:11:10 CEST] <JoshX> hm I have a mkv file now with and without the systemtime in it..
[16:11:56 CEST] <JoshX> its only 36 frames long and it reads:
[16:11:57 CEST] <JoshX> 35
[16:11:57 CEST] <JoshX> 2333000
[16:11:57 CEST] <JoshX> 2.333
[16:11:58 CEST] <JoshX> 1448984846.52
[16:12:07 CEST] <JoshX> which is index, pts, timestamp and system time
[16:12:08 CEST] <BBB> wm4: are you developing mpv?
[16:12:40 CEST] <Daemon404> he is an mpv dev if thats what you mean
[16:12:45 CEST] <BBB> \o/
[16:12:49 CEST] <wm4> yeah
[16:12:56 CEST] <BBB> Invalid video timestamp: 4.100000 -> 4.066667
[16:13:00 CEST] <BBB> why is it doing that?
[16:13:09 CEST] <wm4> timestamp after decoder goes backwards
[16:13:10 CEST] <Daemon404> sounds like non-monotonic timestamps
[16:13:34 CEST] <BBB> which timestamp?
[16:13:44 CEST] <BBB> AVFrame.pkt_pts?
[16:13:46 CEST] <BBB> or & ?
[16:13:54 CEST] <wm4> essentially pkt_pts, yes (in most cases)
[16:14:13 CEST] <JoshX> hmm if there is no 'epoch/systemtime' in the file, the tool outputs the systemtime and timestamp as the same.. so it reads the epoch from some field whichis usually 0 but increases in the file
[16:14:33 CEST] <Daemon404> that sounds all sorts of broken
[16:14:53 CEST] <JoshX> Daemon404: agreed :-/ i just have to roll with it for now..
[16:15:12 CEST] <wm4> BBB: is it a mkv/vp9 file? try with --demuxer=lavf
[16:15:52 CEST] <BBB> same issue with --demuxer=lavf
[16:15:59 CEST] <BBB> its a ivf/vp9 file
[16:16:24 CEST] <wm4> next step is probably checking with ffprobe -show_frames what the decoder outputs
[16:18:42 CEST] <ubitux> i have this invalid ts all the time with webradio
[16:18:51 CEST] <ubitux> but i think i reported it already :p
[16:21:08 CEST] <BBB> its linked to an old libavcodec :(
[16:21:12 CEST] <BBB> ok will tell them to upgrade
[16:22:44 CEST] <durandal_1707> what? Who?
[16:28:17 CEST] <wm4> ubitux: where?
[16:28:29 CEST] <wm4> ubitux: oh, ogg streams?
[16:29:22 CEST] <ubitux> wm4: yeah
[16:30:25 CEST] <wm4> well it would be nice if ffmpeg had some sort of discontinuity flag
[16:32:29 CEST] <BBB> wm4: thanks btw
[16:36:11 CEST] <Daemon404> wm4, wouldnt that only work for formats with frame durations
[16:37:01 CEST] <wm4> Daemon404: depends; my thinking is that the demuxer is in a much better position to know
[16:40:05 CEST] <Daemon404> it would only be possible for some formats ofc
[16:55:28 CEST] <BBB> I think its mildly amusing how some devs think its totally ok to have a variable called properties in a struct called parameters and not be confusing at all
[16:55:38 CEST] <BBB> we did all take engineering 101 right?
[16:55:55 CEST] <BBB> maybe s/amusing/worrying/
[16:56:27 CEST] <wm4> where
[16:57:00 CEST] <wm4> oh, there
[16:57:09 CEST] <BBB> yes, there
[16:57:35 CEST] <BBB> does any avfilter person want to review vf_colorspace: make whitepoint adaptation mode configurable. so I can commit the whole patch-set?
[17:06:50 CEST] <Shiz> BBB: needs to be of typedef attributes to make it complete
[17:07:17 CEST] <BBB> Shiz: totally
[17:08:00 CEST] <durandal_1707> there are no avfilter persons
[17:31:18 CEST] <pfelt> good morning everyone! hope you all had a great weekend
[17:33:51 CEST] <cone-657> ffmpeg 03Diego Biurrun 07master:01621202aad7: build: miscellaneous cosmetics
[17:33:52 CEST] <cone-657> ffmpeg 03Derek Buitenhuis 07master:ca5ec2bf51d8: Merge commit '01621202aad7e27b2a05c71d9ad7a19dfcbe17ec'
[17:41:16 CEST] <durandal_1707> awful weekend
[17:41:51 CEST] <nevcairiel> wow debian switches to i686, and only because the kernel forces them =p
[17:42:24 CEST] <wm4> revolutionary
[17:42:52 CEST] <nevcairiel> i'm sure there is an outcry with the i386 crowd somewhere :p
[17:45:18 CEST] <DHE> it is somewhat well known that linux dropped 386 compat a year or two ago (iirc)
[17:45:33 CEST] <DHE> but shouldn't 486 and 586 still work?
[17:46:30 CEST] <philipl> It's apparently the compiler, not the kernel.
[17:46:39 CEST] <DHE> ... odd..
[17:46:55 CEST] <nevcairiel> 4.3 kernel requires a newer gcc which apparently only does i686 now
[17:48:47 CEST] <pfelt> alas. i must finally upgrade my machine i dual boot between linux and dos 6.22
[17:49:11 CEST] <pfelt> i suppose i shoudl upgrade the cga monitor on it too
[17:50:25 CEST] <pfelt> so on the serious side. i was reading a thread off the email list and it was mentioned that there is a merge queue somewhere. is that something that i can see? (just curious)
[17:51:48 CEST] <wm4> the merge queue is all commits in Libav master that are not in FFmpeg master
[17:52:19 CEST] <pfelt> so, being new here, how does this all work? i've been on other projects, but nothing this *big*
[17:52:37 CEST] <pfelt> say i submit a patch, what happens to it then?
[17:53:29 CEST] <Daemon404> pfelt, it gets reviewed and pushed if it is accepted?
[17:53:33 CEST] <Daemon404> merges are unrelated to this
[17:54:10 CEST] <pfelt> ah. ok. i assumed they were the same thing. (i'm not too familiar with git)
[17:55:06 CEST] Action: pfelt will make some time to read https://ffmpeg.org/developer.html#Contributing today
[17:59:06 CEST] <wm4> if you submit a patch you're either asked to make certain changes, or it gets applied to git master
[17:59:08 CEST] <wm4> simple
[18:00:16 CEST] <nevcairiel> and if you dont hear from anyone, just ping it after a period of some days
[18:00:46 CEST] <nevcairiel> it greatly helps to include a rationale in the commit message, so others understand why a change happens
[18:00:51 CEST] <nevcairiel> many people dont do that unfortunately
[18:02:18 CEST] <Daemon404> 'fix bug'
[18:02:18 CEST] <pfelt> i'm not sure i did a good job on the one i submitted on friday night
[18:02:42 CEST] <pfelt> definitely didn't do a good job on the one from a few weeks back (i'm still trying to work out that patch on my end of it)
[18:03:38 CEST] <pfelt> i *did* however figure out the git format-patch that clement pointed me at)
[18:06:21 CEST] <durandal_1707> Nobody put into log "fix bug" anymore
[18:06:46 CEST] <wm4> durandal_1707: many commit messages that are done these days aren't much better though
[18:07:34 CEST] <durandal_1707> my commit messages are perfect
[18:07:39 CEST] <pfelt> hehe
[18:07:40 CEST] <Daemon404> i ran into this just today
[18:07:42 CEST] <Daemon404> with f5074dd39ca3bc6bff96cafea1d723cf944f50e5
[18:07:49 CEST] <Daemon404> no explanation at all when i blame'd the file
[18:10:36 CEST] <durandal_1707> Daemon404: what's it about?
[18:30:34 CEST] <jamrial_> Daemon404: poke me if you want/need help with d12b5b2f135aade4099f4b26b0fe678656158c13 (test programs splitting) for the modules not available on libav
[18:30:38 CEST] <jamrial_> i wrote a couple after all
[18:30:50 CEST] <Daemon404> i havent started evem
[18:30:59 CEST] <Daemon404> or even looked at it
[18:31:01 CEST] <Daemon404> will it be painful
[18:31:10 CEST] <jamrial_> no
[18:31:24 CEST] <Daemon404> ok
[18:31:32 CEST] <jamrial_> but it's five or so modules they don't have
[18:31:49 CEST] <jamrial_> it's just moving the #ifdef TEST part of each module to a separate file
[18:32:26 CEST] <Daemon404> ah ok
[18:59:28 CEST] <jkqxz> Daemon404: Woo, thanks for merging all of that :) (And apologies for being away when it might have been useful. Oh well.) I guess I'll test all the bits now to make sure I haven't introduced something which doesn't work in ffmpeg...
[19:00:48 CEST] <Daemon404> thank you
[19:01:11 CEST] <Daemon404> im not very happy with how i did ffmpeg_filter.c but it seems to work
[19:01:14 CEST] <Daemon404> i think.
[19:01:18 CEST] <Daemon404> pls do test
[19:29:37 CEST] <Easyfab> durandal_1707: here the bug report for delogo it's my first report so I don't know if it's ok ? tell me if you need something else.
[19:32:18 CEST] <jkqxz> Looks like it works plausibly. For decode, fate-h264 passes everything except for the top/left cropping, monochrome and lossless samples (the expected result; monochrome is probably fixable if it matters).
[19:38:10 CEST] <jamrial_> kierank: how's fuzzing?
[19:38:35 CEST] <kierank> So good I don't believe the results
[19:39:47 CEST] <jamrial_> haha
[20:00:35 CEST] <Easyfab> Oh new VAAPI H.264 encoder :) i will try on my nuc
[20:01:43 CEST] <Daemon404> jkqxz, ok
[20:06:47 CEST] <BtbN> it looks as horribly painful as I'd have imagined it.
[20:08:16 CEST] <BtbN> is full hw transcode with vaapi now possible, or will it still pull the frames to system memory?
[20:09:05 CEST] <wm4> hm I think it should be? maybe
[20:09:30 CEST] <BtbN> With the ffmpeg cli i mean. If there is no filter in between, it should never convert the VAAPI frames?
[20:10:07 CEST] <wm4> yeah
[20:10:17 CEST] <wm4> but good question whether it's implemented yet
[20:10:19 CEST] <jkqxz> It is possible. It is annoying to make it work through lavfi, and you probably want to wait for the next merge making a encoder a bit more usable.
[20:10:22 CEST] <durandal_1707> Easyfab: what compiler ?
[20:13:22 CEST] <jkqxz> (You can use something like './ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i ... -vf 'format=nv12|vaapi,hwupload,scale_vaapi=w=1280:h=720' -c:v h264_vaapi ...' to transcode with scaling, for example.)
[20:14:10 CEST] <wm4> so the next step is a vpp filter I guess
[20:14:21 CEST] <durandal_1707> why those hw filters are not documented?
[20:15:37 CEST] <Easyfab> durandal_1707: gcc (Ubuntu 5.3.1-14ubuntu2) 5.3.1 20160413 and gcc 5.3.0 when cross-compiling for windows
[20:16:05 CEST] <BtbN> jkqxz, hwupload/download is what I'd like to avoid.
[20:18:21 CEST] <jkqxz> The hwupload isn't actually doing anything there in the normal case. It's required because of the two-step graph setup, and will only be actually uploading frames if you fall back to software decode because the input wasn't supported.
[20:18:42 CEST] <durandal_1707> Easyfab: and the crash happens on both?
[20:18:52 CEST] <Easyfab> yes
[20:20:24 CEST] <durandal_1707> Easyfab: does crash happens with specific input combinations? Or any input works?
[20:21:07 CEST] <Easyfab> one moment i will try with different format.
[20:29:55 CEST] <Easyfab> yes all videos but not with -vf delogo=x=0:y=0:w=2:h=2 as I report but with w=20:h20 or greater
[20:38:50 CEST] <durandal_1707> Easyfab: so it happens with pure white video?
[20:41:06 CEST] <Easyfab> how can I test that ?
[20:44:52 CEST] <durandal_1707> ffmpeg -f lavfi -i color -vf delogo...
[20:48:15 CEST] <llogan> color=c=white
[20:50:53 CEST] <Easyfab> same error Exception en point flottant (core dumped) http://pastebin.com/eMMHqQcW
[20:59:39 CEST] <Easyfab> durandal_1707: Must be my computer ( i2600K) because on my nuc ( braswell) it works :(
[21:00:45 CEST] <Easyfab> Can it be tha asm AVX or something like that ?
[21:01:23 CEST] <jamrial_> try using -cpuflags 0 to make sure
[21:03:04 CEST] <relaxed> happens here too (with -cpuflags 0)
[21:03:53 CEST] <Easyfab> so I'm not alone :)
[21:12:57 CEST] <llogan> anyone here w/ gcc 6.1.1?
[21:20:24 CEST] <rcombs> is there some equivalent to RGB_TO_[YUV]_CCIR that works with an arbitrary YUV colorspace?
[21:22:01 CEST] <nevcairiel> no
[21:22:12 CEST] <llogan> nevermind. i can't seem to duplicate the "gcc: internal compiler error: Bus error (program cc1)"
[21:22:27 CEST] <nevcairiel> its an 8-bit integer approximation anyway, you may not want it for anything important
[21:23:29 CEST] <rcombs> trying to get ff_draw to support non-BT601 YUV
[21:25:33 CEST] <rcombs> right now my hacked-up subtitle overlay filter does some ridiculous shit copied from mpv involving converting to YUV and then back (made more complex by VSFilter compatibility)
[21:26:24 CEST] <wm4> mpv uses libswscale for doing this (qualifies as ridiculous shit)
[21:28:07 CEST] <Shiz> can confirm
[21:28:21 CEST] <rcombs> wm4: I'm referring to mangle_colors in sd_ass.c
[21:28:33 CEST] <wm4> ah, yeah, vsfilter compat
[21:30:45 CEST] <rcombs> not sure if that would still be necessary with ff_draw support for non-601 colorspaces, since vsfilter compat is some pretty arcane shit
[21:32:24 CEST] <wm4> this compat is always necessary
[21:32:48 CEST] <wm4> since subs can be color mangled or not, depending on circumstances and ass header
[21:33:21 CEST] <wm4> you could probably get away with hardcoding the two common cases
[21:33:33 CEST] <rcombs> wm4: in ff_draw, I'm wondering if it could be implemented as simply as "blend YUV as if the destination color space were <the one in the ASS header>"
[21:33:44 CEST] <Daemon404> the only reason you would ever care about vsfilter compat is for playing anime. ever.
[21:33:48 CEST] <Daemon404> afaik.
[21:33:51 CEST] <wm4> rcombs: sounds correct
[21:34:06 CEST] <wm4> and what Daemon404 said
[21:34:28 CEST] <Daemon404> wm4, just think. there was once a time where fansubs were that important to me.
[21:34:30 CEST] <rcombs> rather than going RGB->(ASS header CSP)->RGB mangled->(ffdraw)YUV mangled
[21:34:40 CEST] <Daemon404> that time was, of course, high school / undergrad
[21:34:49 CEST] <Daemon404> i cringe now thinking of the ridiculous hacks
[21:35:40 CEST] <rcombs> either way, ff_draw clearly shouldn't hardcode BT601
[21:35:48 CEST] <rcombs> even putting aside all the dumb hacks
[21:36:10 CEST] <Daemon404> ofc
[21:36:20 CEST] <JEEB> I think no header = BT.601 basically, otherwise follow the crazy bullshit logic gained from the xy-vsfilter added headers
[21:36:29 CEST] <durandal_1707> yes, tell that to lazy devs
[21:36:59 CEST] <wm4> rcombs: the ass header basically tells you what video colorspace aegisub was assuming, I think
[21:37:04 CEST] <rcombs> so I figured I'd work out how to support arbitrary colorspaces (at least, ones we have enum values for), and then see if I still need to mangle colors within my filter
[21:37:24 CEST] <wm4> mpv does it only this way because subtitles are _actually_ rendered in RGB most of the time
[21:37:36 CEST] <rcombs> yeah that's a bit more sane
[21:37:47 CEST] <rcombs> my case here is rendering on YUV video so it gets a bit more crazy
[21:38:26 CEST] <rcombs> also nevcairiel ff_draw does support >8-bit precision& and does it by left-shifting the 8-bit approximation by (bits-8)
[21:38:27 CEST] <wm4> yeah, but the implementation of the vsfilter compat becomes easier
[21:38:38 CEST] <rcombs> so I'd like to stop doing that as well
[21:38:48 CEST] <Daemon404> i wonder how many ad-hoc yuv2rgb/rgb2yuv are in ffmpeg
[21:38:53 CEST] <rcombs> a lot!
[21:38:53 CEST] <Daemon404> to avoid making a sws dependency
[21:38:58 CEST] <Daemon404> because reasons
[21:39:19 CEST] <rcombs> this one is sorta awkward because most of the existing ones are meant for entire images
[21:39:25 CEST] <rcombs> and here I want just one color value converted
[21:39:39 CEST] <rcombs> inb4 1x1px bitmap
[21:39:43 CEST] <Daemon404> rcombs, there are multiple yuv-based codecs with rgb cursors
[21:39:44 CEST] <Daemon404> in avcodec
[21:39:47 CEST] <Daemon404> 32x32
[21:39:48 CEST] <Daemon404> ;)
[21:40:14 CEST] <Daemon404> actually g2m might have different colorspaces per-tile
[21:40:15 CEST] <Daemon404> iirc
[21:40:27 CEST] <rcombs> wew
[21:40:42 CEST] <rcombs> I might have to stick something in lavu :/
[21:41:01 CEST] <rcombs> https://xkcd.com/927/
[21:41:19 CEST] <wm4> also there's vf_colorspace
[21:41:25 CEST] <wm4> aka libswscale2
[21:41:35 CEST] <Daemon404> and vf_zscale
[21:41:51 CEST] <rcombs> or maybe just move the vf_colorspace functions to colorspace.c/.h
[21:41:53 CEST] <Daemon404> also teh xyz code used to be in lavfi
[21:41:57 CEST] <Daemon404> but i think it went into sws now
[21:42:14 CEST] <rcombs> or use swscale (no qualms about this if it's workable for a single value)
[21:42:26 CEST] <Daemon404> this is just one of those things i try not to think about
[21:42:35 CEST] <Daemon404> and pray it doesnt affect me
[21:42:35 CEST] <rcombs> though >swscale >still having its own set of enums for everything
[21:43:02 CEST] <wm4> rcombs: you could scale a single pixel
[21:43:11 CEST] <wm4> just to do the conversion
[21:43:16 CEST] Action: wm4 wonders about the overhead
[21:43:18 CEST] <rcombs> yeah, I said that earlier
[21:44:22 CEST] <Daemon404> you need to make sure to align the buffer for that single pixel btw
[21:44:30 CEST] Action: Daemon404 runs
[21:44:46 CEST] <Easyfab> jkqxz: with your command line example( without scale ) -c:v h264_vaapi works nicely at 29fps on my braswell for 1080p video vs 21fps for x264 superfast but qualty is not as good. I see that in the gstreamer h264_vaapi plugins you can set cabac=true, bframes, tune=high-compression ... Can we yet acess this option in ffmpeg
[21:45:44 CEST] <wm4> didn't he say something like this will get merged from Libav
[21:46:04 CEST] <nevcairiel> probably, there is a bunch of improvements scheduled for later
[21:48:00 CEST] <nevcairiel> kurosu: did you delete your post from the doom9 thread about decoding speed, or did one of the mods not like calling out another mod on the topic?
[21:48:47 CEST] <pfelt> slightly OT question. if i'm working on a change that's dependent upon a patch, that's already been submitted but not accepted yet, is the best way to work that on my local codebase to branch off the branch that i wrote that base patch in?
[21:49:18 CEST] <Shiz> vf_swscale
[21:49:48 CEST] <wm4> Shiz: vf_scale?
[21:52:24 CEST] <Daemon404> kurosu is on doom9?
[21:52:30 CEST] <Daemon404> news to me and ive been a member since 05
[21:52:31 CEST] <Daemon404> O.o
[21:53:40 CEST] <nevcairiel> was the same name and he linked the thread here the other day, so i assume its him =p
[21:53:57 CEST] <nevcairiel> but the post now vanished, so
[21:54:12 CEST] <Daemon404> is there a poitn to d9 anymore?
[21:54:16 CEST] <Daemon404> it mostly seems like insane people now
[21:54:25 CEST] <Daemon404> or people who dont really know what theyre talking about
[21:55:00 CEST] <nevcairiel> the second kind is present everywhere
[21:55:10 CEST] <iive> has it ever been different?
[21:55:30 CEST] <iive> I remember some x264 developers creating doom10 to fix that.
[21:55:40 CEST] <Daemon404> doom10 wasnt created for that
[21:55:49 CEST] <Daemon404> doom10 was created because dark_shikari hated neuron2.
[21:56:17 CEST] <Daemon404> there was a huge falling out thread regarding the 2 and ffmpeg's license violators page of shame
[21:56:21 CEST] <Daemon404> anyway d10 is dead now.
[21:57:04 CEST] <nevcairiel> d10 never was alive, really
[21:57:19 CEST] <JEEB> it had random activity for a very short point in time
[21:57:40 CEST] <Daemon404> about 40% of that activity was troll threads about n2
[21:58:09 CEST] <JEEB> I think there were then some people who just kept posting there while always making sure to mention how much better it is than d9 because of no n2
[21:58:39 CEST] <nevcairiel> he left a couple years ago anyway, so
[21:58:40 CEST] <Shiz> what programs still output this shit even
[21:58:46 CEST] <Shiz> whoops i was scrolled up
[21:58:51 CEST] <Daemon404> nevcairiel, he is still around under a diff nick
[21:58:52 CEST] <Shiz> i meant the ridic vsfilter headers
[21:59:04 CEST] <nevcairiel> Daemon404: yeah but he isnt a mod anymore that actively seeks out to screw people
[21:59:05 CEST] <JEEB> Shiz: they're the default thing nowadays
[21:59:27 CEST] <JEEB> aegisub by default will write them and xy-vsfilter (still) will happily take them in
[21:59:32 CEST] <Shiz> :|
[21:59:37 CEST] <Shiz> can you make it not do that
[21:59:41 CEST] <Daemon404> the anime community is both the reason we can, and can't, have nice things
[21:59:49 CEST] <Plorkyeran> aegisub always writes the header because even with insane compat mode off aegisub may have used the wrong colorspace
[21:59:50 CEST] <nevcairiel> half of his activity was locking any threads were the creator didn't name the source of his video file, on suspicion of piracy =p
[21:59:57 CEST] <wm4> Daemon404: which nice things
[22:00:01 CEST] <Daemon404> wm4, x264
[22:00:03 CEST] <wm4> that we can have
[22:00:14 CEST] <Plorkyeran> the insane compat mode was supposed to be disabled a year or two ago but I haven't actually made any releases in in like 18 months
[22:00:15 CEST] <wm4> x264?
[22:00:17 CEST] <Plorkyeran> so
[22:00:28 CEST] <Daemon404> wm4, where do you think pengvado or D_S came from
[22:00:30 CEST] <Shiz> D_S was ridiculously weeb after all
[22:00:37 CEST] <wm4> eh
[22:01:05 CEST] <JEEB> I still remember the zx post pengvado's number-crunched lavc mpeg4 encode
[22:01:08 CEST] <nevcairiel> i never understood this obsession with anime
[22:01:09 CEST] <JEEB> *post on
[22:01:11 CEST] <nevcairiel> whats up with those people
[22:01:28 CEST] <nevcairiel> for most, in a language you don't even understand
[22:01:33 CEST] <Shiz> man an ffmpeg dev asking that is just the funniest thing
[22:01:37 CEST] <Daemon404> whats up with people's obsession with guns?
[22:01:40 CEST] <Daemon404> people are people.
[22:02:38 CEST] <JEEB> and you even had people like mentar or rika who were/are still in that stuff in their N0ties
[22:02:56 CEST] <iive> nevcairiel: japan actually produces a lot of anime, and occasionally some of it is great.
[22:03:18 CEST] <Shiz> don't liw
[22:03:21 CEST] <Shiz> lie
[22:03:28 CEST] <llogan> i've seen one. akira i think is what it is called.
[22:03:41 CEST] <iive> yeh, it is classic.
[22:03:41 CEST] <Daemon404> so nothing sicne teh 80s?
[22:03:43 CEST] Action: Daemon404 runs
[22:03:53 CEST] <JEEB> anyways, herp derp people have their "things" so (Ž4@)
[22:03:57 CEST] <Plorkyeran> anime has incredibly unthreatening cute girls
[22:04:02 CEST] <Plorkyeran> what's not to get
[22:04:13 CEST] <nevcairiel> i've watched maybe one or two animes that got translated either to english or even german, but i never would both with reading subtitles and hearing japanese
[22:04:14 CEST] <Daemon404> Plorkyeran, when they give these girls horribly grating voices and personalities
[22:04:17 CEST] <Daemon404> thats when i dont get it.
[22:04:21 CEST] <nevcairiel> bother*
[22:04:39 CEST] <Daemon404> anyway its just people's hobbies
[22:04:40 CEST] <iive> well, anime have a wide range of themes. SciFi is easy when effects doesn't cost extra
[22:04:47 CEST] <rcombs> Plorkyeran: and also threatening ones
[22:04:57 CEST] <Daemon404> id argue people who enjoy foss multimedia as a hobby are just as 'odd'
[22:05:00 CEST] <Daemon404> perhaps odder.
[22:05:05 CEST] <Daemon404> its much more niche.
[22:05:18 CEST] <nevcairiel> i just started because there was no player that did what I wanted
[22:05:32 CEST] <rcombs> isn't that how most FOSS happens
[22:05:45 CEST] <rcombs> "I want software that does $thing; no software does $thing"
[22:06:20 CEST] <nevcairiel> ie. before me the windows player world was rather crappy, people either used ancient and broken ffdshow versions or vlc which just didnt do windows well back then
[22:06:30 CEST] <Plorkyeran> sometimes it's more of "I want software that does $thing; software exists that does $thing but it has some trivial problem so I'm going to write my own from scratch"
[22:06:34 CEST] <Daemon404> rcombs, close
[22:06:38 CEST] <Shiz> NIH yo
[22:06:44 CEST] <Daemon404> you forgot "exisiting software is crappy"
[22:06:48 CEST] <JEEB> nevcairiel: -tryouts YOOOOOO
[22:06:48 CEST] <Daemon404> or "gpl v3"
[22:06:58 CEST] <llogan> for me i simply got tired of not knowing how to encode stuff
[22:06:59 CEST] <JEEB> last touched that piece of crap in '11
[22:06:59 CEST] <Shiz> Daemon404: alternatively "not gpl v3"
[22:07:04 CEST] <Shiz> depends on who you are
[22:07:18 CEST] <rcombs> or "it does $thing1 and another program does $thing2, but nothing does both"
[22:07:28 CEST] <JEEB> so yeah, LAV brought a lot of relative sanity into DShow
[22:07:31 CEST] <nevcairiel> JEEB: lav started in 2010, so its been a while
[22:07:45 CEST] <Daemon404> ffdshow is not dead
[22:07:50 CEST] <Daemon404> people still use it for its avs filtering
[22:07:55 CEST] <Daemon404> sadly.
[22:07:57 CEST] <JEEB> yes, unfortunately
[22:08:00 CEST] <nevcairiel> some crazies use it for postprocessing or avs yeah
[22:08:07 CEST] <JEEB> and clsid2 probably still gives it a commit or so every Nth month
[22:08:13 CEST] <JEEB> if he still gives a fuck
[22:08:15 CEST] <nevcairiel> but its filtering stuff isn't quite as insane as its decoders
[22:08:18 CEST] <nevcairiel> (still bad tho)
[22:09:20 CEST] <nevcairiel> there is the odd commit now and then, but ffmpeg hasnt been updated in years in it, and you can count the number of commits in the last 3 years on one hand, so
[22:09:33 CEST] <JEEB> yeah, that's how I last saw it
[22:09:44 CEST] <JEEB> and the libavcodec there is a weird mess
[22:09:50 CEST] <JEEB> mishmash of libav and ffmpeg IIRC
[22:09:55 CEST] <nevcairiel> i pondered writing an avisynth or vapoursynth filter one day
[22:09:59 CEST] <nevcairiel> but i just dont fucking care :D
[22:10:16 CEST] <JEEB> yeah, if you have no use case then welp
[22:10:58 CEST] <Daemon404> [21:09] <+JEEB> mishmash of libav and ffmpeg IIRC <-- you forgot the hacks
[22:11:05 CEST] <JEEB> yes
[22:11:34 CEST] <nevcairiel> fixing ffdshow was literally impossible due to the amount of crap and hacks it collected over the years
[22:11:43 CEST] <nevcairiel> so from scratch it was
[22:11:45 CEST] <JEEB> ayup
[22:12:19 CEST] <Daemon404> nevcairiel, out of curiosity what didnt it 'do' that you wanted
[22:12:27 CEST] <nevcairiel> i forget
[22:12:30 CEST] <nevcairiel> probably "work"
[22:12:40 CEST] <Daemon404> lol.
[22:12:47 CEST] <nevcairiel> i actually started with a demuxer, since that didnt exist based on avformat
[22:13:37 CEST] <nevcairiel> and I already had a video decoder based on the nvidia cuvid sdk .. so at that point it just appeared logical to make a ffmpeg decoder as well thats not quite as hacky
[22:13:45 CEST] <nevcairiel> (although its dshow, a certain number of hacks is a given)
[22:14:17 CEST] <jamrial_> nevcairiel: before you people used bsplayer :p
[22:14:19 CEST] <Daemon404> it was vfw too
[22:14:23 CEST] <Compn> nevcairiel : i think the reason you wonder about anime is because you were not around during the "golden age" of the 1990s anime (being fansubbed in early 2000s)
[22:14:29 CEST] <JEEB> people *still* seem to use bsplayer
[22:14:39 CEST] <JEEB> for some reason
[22:14:44 CEST] <nevcairiel> isnt bsplayer one of those that just steal from me
[22:14:55 CEST] <Daemon404> i dunno but it predated you
[22:14:59 CEST] <JEEB> not sure, I never looked into it
[22:14:59 CEST] <Daemon404> and had skins
[22:15:03 CEST] <JEEB> yeah
[22:15:16 CEST] <JEEB> I used it in like... 2003-4? for some periods of time
[22:15:16 CEST] <nevcairiel> that doesnt mean much, some older players keep magically having the same advances shortly after me
[22:15:34 CEST] <JEEB> my friend still uses bsplayer because of the subtitle downloader I think
[22:15:48 CEST] <Daemon404> doesnt mpc have that
[22:15:50 CEST] <Daemon404> oo
[22:15:50 CEST] <nevcairiel> someone stole my h264 mvc stuff for some kodi branch, well he kept attribution in the source files so its probably fine, but it would be nice to be told such things =p
[22:15:50 CEST] <Daemon404> too
[22:16:17 CEST] <nevcairiel> Daemon404: it does, and it got reworked quite a lot recently to support more services
[22:16:26 CEST] <JEEB> Daemon404: yeah but it was something like "b-b-b-but mpc-hc doesn't just let you press a butan and auto-get a subtitle!"
[22:16:39 CEST] <JEEB> you had more menus in mpc-hc or something
[22:16:40 CEST] <JEEB> idk
[22:31:27 CEST] <Compn> BUFFERING
[22:33:05 CEST] <kurosu> Daemon404, I've been since '02, but stopped participating a long time ago
[22:33:34 CEST] <kurosu> nevcairiel, it was a bit too hot-blooded, and not going to achieve anything
[22:33:49 CEST] <kurosu> so I deleted it
[22:33:55 CEST] <nevcairiel> i see
[22:34:01 CEST] <nevcairiel> true nevertheless
[22:36:38 CEST] <Daemon404> what did i miss?
[22:36:44 CEST] <Daemon404> sounds at least interesting
[22:37:31 CEST] <kurosu> I don't really know, but among all those streaming websites/services/..., amazon is likely the least "thankful"
[22:37:36 CEST] <nevcairiel> he called out an employee of amazon video for complaining about hevc decode speed, and told him to go instead motivate his employer to pay
[22:37:53 CEST] <kurosu> s/is likely/looks to me/
[22:38:06 CEST] <Daemon404> nevcairiel, ben waggoner>
[22:38:07 CEST] <Daemon404> ?
[22:38:10 CEST] <nevcairiel> yea
[22:38:29 CEST] <kurosu> previously microsoft employee, iirc ?
[22:38:33 CEST] <nevcairiel> i think so
[22:39:01 CEST] <Daemon404> kurosu, i'd argue youtube or netflix
[22:39:07 CEST] <Daemon404> probably netflix.
[22:39:18 CEST] <Daemon404> though at least netflix admits they use ffmpeg.
[22:39:32 CEST] <wm4> who doesn't admit it?
[22:39:42 CEST] <Daemon404> youtube has never admitted it publically
[22:39:50 CEST] <nevcairiel> we should add subtle bugs to your muxers and analyze their files =p
[22:39:57 CEST] <kurosu> yeah, I'm not sure how much aiv actually uses ffmpeg (well, except the rationale "what are they gonna use then?")
[22:39:59 CEST] <durandal_1707> Gooble
[22:40:29 CEST] <kurosu> subtle bugs, or subtle bitstream manipulations like in padding ? :)
[22:40:31 CEST] <Daemon404> kurosu, i assume they do. elastic transcode does for example.
[22:40:39 CEST] <Daemon404> i dont think the guy on d9 (ben) codes though
[22:40:41 CEST] <Daemon404> he is a manager iirc
[22:40:49 CEST] <kurosu> yeah, he is
[22:40:50 CEST] <nevcairiel> even better position to get us funds =p
[22:41:19 CEST] <Daemon404> i would be hard pressed to get my employer to pay funds directly to libav*
[22:41:19 CEST] <kurosu> he's probably quite knowledgeable about x265 commercial licenses, too :)
[22:41:23 CEST] <Daemon404> but we contribute in dev work
[22:41:25 CEST] Action: Daemon404 hides
[22:41:26 CEST] <durandal_1707> Gstreamer
[22:41:41 CEST] Action: wm4 wonders what nevcairiel works for
[22:41:45 CEST] <Daemon404> kurosu, he's been quite a hevc advocate even before it was at all useful
[22:42:01 CEST] <kurosu> as long some modifications are published, it's already a good trade
[22:42:05 CEST] <Daemon404> i used to be too. until the patent-ning happened.
[22:42:11 CEST] <Daemon404> now i simply cannot.
[22:42:50 CEST] <wm4> so what is it going to be, vp9, or one of those endless vapor codecs
[22:43:01 CEST] <Daemon404> kurosu, youtube has send some patches here and there. netflix sent 1 line... once.
[22:43:04 CEST] <Daemon404> ;)
[22:43:07 CEST] <jamrial_> Daemon404: now you're a daala advocate then? :P
[22:43:27 CEST] <Daemon404> jamrial_, no i just think the situation we're in for "next gen" video is bad.
[22:43:30 CEST] <kurosu> web streaming will use vp9, but still need patented tech for hdr
[22:43:46 CEST] <JEEB> HDR is one of the best messes I've seen in a while
[22:43:54 CEST] <JEEB> at least it doesn't touch the actual video stream too much
[22:43:54 CEST] <kierank> kurosu: HLG?
[22:43:54 CEST] <Daemon404> we're in a weird situation where the best case may be a proprietary encoder for vp9
[22:43:55 CEST] <kurosu> and then we'll see how many patent trolls exist in the field of video coding
[22:43:55 CEST] <kierank> that's patent free
[22:43:58 CEST] <nevcairiel> vp9 in itself isnt a bad codec, just libvpx sucks .. wonder how BBB's new encoder can change things, but right now there doesnt seem much of a market for it
[22:44:02 CEST] <Daemon404> which, if you asked me 2 years ago, was impossible.
[22:44:17 CEST] <jamrial_> BBB is writing a vp9 encoder?
[22:44:22 CEST] <kurosu> kierank, that's just BBC/ARIB and not yet used (maybe uhd phase 2?)
[22:44:30 CEST] <Daemon404> jamrial_, he made the info public last week
[22:44:36 CEST] <wm4> jamrial_: it's proprietary
[22:44:39 CEST] <BBB> ?
[22:44:51 CEST] <BBB> jamrial_: yes
[22:44:52 CEST] <JEEB> yes, 2 years ago the look on the market was quite different
[22:44:57 CEST] <kierank> kurosu: afaik it's supported on some tvs and you could build a working pipeline
[22:45:02 CEST] <Daemon404> 2 years ago i was sure hevc would win
[22:45:04 CEST] <Daemon404> look at me now.
[22:45:06 CEST] <Daemon404> egg on my face.
[22:45:18 CEST] <BBB> and sorry that its proprietary but I need to make a living somehow :-/
[22:45:39 CEST] <wm4> BBB: nobody accused you yet
[22:45:44 CEST] <JEEB> nobody's really herping a derp at you for that :P
[22:45:45 CEST] <jamrial_> BBB: do you have a blog post or something about it?
[22:45:46 CEST] <wm4> of the dirty crime of trying to make a living
[22:45:52 CEST] <BBB> jamrial_: https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-…
[22:45:57 CEST] <jamrial_> thanks
[22:46:04 CEST] <kierank> blame web streamurs for being freeloaders
[22:46:05 CEST] <kurosu> kierank, we'll see in 3-4 years when it's actually deployed - but like JEEB said it's just another one
[22:46:06 CEST] <durandal_1707> ban him!
[22:46:08 CEST] <kierank> at least broadcasters pay
[22:46:51 CEST] <Daemon404> wm4, the real foss way is to work an unrewarding job at google as an extremely overqualified tech support guy, and work on your projects that are fundemntal to like 900 bisiness, on your fere time
[22:46:55 CEST] <Daemon404> right
[22:46:58 CEST] <Daemon404> ?
[22:47:01 CEST] <JEEB> I wonder if there's any actual BT.2020 utilizing content out there on that one Japanese satellite channel that's now been in production mode for a while
[22:47:23 CEST] <nevcairiel> BBB: btw the quality comparisons you did seem a bit lacking, not including hevc and the choice of resolutions seems like 3 years ago
[22:47:34 CEST] <JEEB> last time I checked it was just a test channel for ARIB's specified BT.709->BT.2020 rulebook
[22:48:28 CEST] <wm4> Daemon404: wat
[22:48:28 CEST] <durandal_1707> how much fast is this encoder?
[22:48:46 CEST] <BBB> nevcairiel: Id love to do more 4k but the encoder is still quite slow
[22:48:51 CEST] <Daemon404> wm4, im just describing how many integral foss projects work
[22:48:53 CEST] <Daemon404> <_<
[22:48:57 CEST] <BBB> nevcairiel: need more speed first :)
[22:49:16 CEST] <kurosu> need money first, actually ;)
[22:49:31 CEST] <durandal_1707> :)
[22:49:49 CEST] <kurosu> but that's an impressive result for a single man
[22:50:11 CEST] <nevcairiel> he did use "we", but i dont know who else that is
[22:50:11 CEST] <Daemon404> kurosu, consider that x264 was originally only 1-2 guys at a given time
[22:50:20 CEST] <Daemon404> al lthe 'big' things were largely 1 of the 2
[22:51:17 CEST] <kurosu> Daemon404, comparing people that breathed h264 for that time, to a guy with a family life and kids ? :D
[22:51:27 CEST] <Daemon404> lol
[22:51:28 CEST] <Daemon404> true
[22:51:47 CEST] <kurosu> not something I could achieve
[22:51:58 CEST] <kurosu> hence the "impressive"
[22:52:29 CEST] <Daemon404> prunetree tried it with hevc but got demotivated rather fast
[22:52:34 CEST] <Daemon404> prunedtree*
[22:52:49 CEST] <Daemon404> also because he got a busy job ;p
[22:52:56 CEST] <BBB> nevcairiel: and hevc & so, Im trying to target clients not as an instead of hevc, but as an instead of h264
[22:53:15 CEST] <BBB> nevcairiel: if theyve already chosen hevc and are happy with it, I dont think Ill convince them otherwise. ever. Im realistic about that
[22:53:27 CEST] <nevcairiel> well sure, but they would consider hevc as an alternative to "instead of h264", so its still a competition, no?
[22:53:29 CEST] <Daemon404> BBB, it cant hurt to try
[22:53:38 CEST] <Daemon404> but imo the reasons to not use hevc are not technical
[22:53:41 CEST] <nevcairiel> maybe not for switching from hevc to vp9
[22:53:42 CEST] <Daemon404> so BBB has kind of a point
[22:53:43 CEST] <BBB> true
[22:53:49 CEST] <nevcairiel> but for making the decision between hevc and vp9
[22:54:03 CEST] <Daemon404> fun fact
[22:54:03 CEST] <JEEB> yeah, the whole HEVC debacle is just so bad at the moment
[22:54:10 CEST] <Daemon404> some hw box player things ONLY support vp9 for 4k
[22:54:12 CEST] <Daemon404> no hevc
[22:54:19 CEST] <nevcairiel> sounds like an odd box
[22:54:24 CEST] <Daemon404> yep
[22:54:25 CEST] <Daemon404> roku!
[22:54:32 CEST] <nevcairiel> rokus are terrible either way
[22:54:34 CEST] <JEEB> probably a software limitation?
[22:54:39 CEST] <Daemon404> i dunno
[22:54:44 CEST] <nevcairiel> their media support is abyssmal
[22:54:46 CEST] <BBB> nevcairiel: I think hevc comparisons make little sense at 360p anyway, people would directly shout at me NOT 4k!!! FAKE!!!
[22:54:48 CEST] <Daemon404> they explicitly do not allow 4k h264
[22:54:50 CEST] <Daemon404> probably hw limit
[22:55:02 CEST] <BBB> nevcairiel: so lets get speed first, so 4k is realistic, and then Ill do 4k comparisons between h264/hevc/me
[22:55:15 CEST] <Daemon404> BBB, my issue is usually that all comparisons are at low bitrates which i dont care about
[22:55:17 CEST] <nevcairiel> speed is always nice
[22:55:20 CEST] <Daemon404> it care about higher bitrates
[22:55:24 CEST] <Daemon404> that can keep grain
[22:55:25 CEST] <Daemon404> and such
[22:55:38 CEST] <Daemon404> or not having to boost bitrate on trouble encodes for clients
[22:55:47 CEST] <Daemon404> who have style-grain and strobes
[22:55:48 CEST] <Daemon404> and such
[22:55:51 CEST] <JEEB> well UHD AVC being a software limitation wouldn't surprise me. and it wouldn't surprise me to just deliver the hardware without the HEVC support enabled in drivers/middleware
[22:55:54 CEST] <nevcairiel> arent your work encodes generally bitrate limited because streaming?
[22:56:04 CEST] <JEEB> just to work around the mess that is HEVC licensing atm
[22:56:11 CEST] <Daemon404> nevcairiel, if you bitarte spikes are kept under control
[22:56:21 CEST] <Daemon404> but if you have enough bw we will feed you a nice file
[22:56:27 CEST] <durandal_1707> how much you guys write code for living?
[22:56:36 CEST] <Daemon404> all day every day?
[22:56:41 CEST] <Daemon404> inclduing weekends?
[22:56:44 CEST] <nevcairiel> same
[22:56:48 CEST] <nevcairiel> unless i have a gaming day
[22:56:54 CEST] <Daemon404> ah true
[22:56:58 CEST] <Daemon404> sometimes i game al lsunday
[22:57:33 CEST] <wm4> I'm glad when I can write code, instead of "other" things
[22:57:55 CEST] Action: Daemon404 forces wm4 to merge at gunpoint
[22:58:05 CEST] <durandal_1707> in lines not time ;)
[22:58:14 CEST] <nevcairiel> when i have an appropriate topic i even get to w ork on ffmpeg or lav code for work, but right now i have to deal with opengl mess again
[22:58:35 CEST] <nevcairiel> (with the main problem being that i know shit about opengl)
[22:58:52 CEST] <wm4> video rendering?
[22:59:02 CEST] <kierank> durandal_1707: used to but now I look at spreadsheets and answer the phone all day :(
[22:59:21 CEST] <nevcairiel> i did video rendering last year, that worked after a bit, right now i'm doing a 10ft interface
[22:59:23 CEST] <Daemon404> RIP kierank
[22:59:25 CEST] <Daemon404> he will be missed
[22:59:34 CEST] <Daemon404> he died eating 0-calorie noodles and using excel.
[22:59:48 CEST] <kierank> 0 calorie noodles was a long time ago
[22:59:48 CEST] <wm4> nevcairiel: eh, with opengl?
[22:59:50 CEST] <JEEB> better than SAP
[22:59:54 CEST] <kierank> can't do that any more with marathon training
[22:59:56 CEST] <kierank> would just die
[23:00:03 CEST] <Daemon404> well
[23:00:06 CEST] <Daemon404> that explains the bread.
[23:00:16 CEST] <nevcairiel> wm4: of course
[23:00:22 CEST] <wm4> nevcairiel: that seems painful and inappropriate, kind of like writing a FPS game with raw GL
[23:00:25 CEST] <kierank> would just die
[23:00:27 CEST] <kierank> bah
[23:00:31 CEST] <kierank> fucking keyboard
[23:01:05 CEST] <nevcairiel> wm4: we have one with directx and its responsive and snappy, but muh crossplatform
[23:01:22 CEST] <nevcairiel> i looked into some rendering engines or such, but they are all super convoluted for a interface only
[23:01:31 CEST] <wm4> (that's awfully low level)
[23:02:07 CEST] <nevcairiel> indeed, but i didnt find anything that would actually fit the use-case
[23:02:57 CEST] <atomnuker> I did something like that once, only used libsdl (to load ogl and open a window) and libfreetype to write a GUI
[23:03:29 CEST] <atomnuker> shaders and fontconfig were a big pain
[23:03:39 CEST] <nevcairiel> we already have font stuff etc all ready
[23:04:17 CEST] <nevcairiel> its just the actual opengl rendering thats missing, and i'm still cataloging what kind of elements and effects i really need
[23:04:37 CEST] <JEEB> I kind of wanted to buy a sony tv with android for my mpv masochism, but then I noticed that those damn UHD screens only support 1080p android rendering :<
[23:04:44 CEST] <JEEB> or at least that's what their docs hint at
[23:04:48 CEST] <wm4> atomnuker: I bet that doesn't handle non-western languages well
[23:06:06 CEST] <nevcairiel> in any case, i dont mind, its kinda fun to learn opengl along the way, even more so when making sure to use opengl3 stuff and not the deprecated stuff from 2 (even though the 2 stuff looks simpler in many ways =P)
[23:09:04 CEST] <atomnuker> wm4: well, I never tried non ascii, just did and I didn't expect it to segfault right away
[23:09:44 CEST] <atomnuker> wait, I did some weird LUT glyph storage, that might be why
[23:09:56 CEST] <atomnuker> oh well
[23:10:45 CEST] <Mavrik> JEEB, it's true
[23:10:59 CEST] <Mavrik> JEEB, also the SoC in those Sonys is so terrible they don't render that UI at 60fps
[23:11:09 CEST] <Mavrik> Even the cheapass Nexus Player performs significantly better.
[23:11:36 CEST] <JEEB> fuck that
[23:11:50 CEST] <nevcairiel> i never bought a TV for its UI features
[23:11:56 CEST] <nevcairiel> i just want a good display panel =P
[23:12:10 CEST] <JEEB> yes, but it would have also been interesting to get mpv on the TV itself
[23:13:09 CEST] <Mavrik> Does MPV support MediaCodec?
[23:13:24 CEST] <JEEB> yes, I made a wrapper like the rpi thing
[23:13:49 CEST] <JEEB> https://github.com/mpv-player/mpv/pull/2993
[23:14:17 CEST] <Daemon404> [22:11] <@nevcairiel> i never bought a TV for its UI features <-- has anyone ever?
[23:14:25 CEST] <nevcairiel> i'm sure some do
[23:15:01 CEST] <wm4> Mavrik: only with read-back
[23:15:11 CEST] <JEEB> which seems to be fast enough for most purposes
[23:15:20 CEST] <Mavrik> Yeah, was wondering if it could carry 4K
[23:15:58 CEST] <JEEB> haven't gotten to testing because of lack of content and mobile screens
[23:16:32 CEST] <JEEB> https://github.com/mpv-android/mpv-android but this is where the masochism is produced if you want to test
[23:17:40 CEST] <Mavrik> Hmm, don't currently have any of Sonys on hand :/
[23:18:22 CEST] <nevcairiel> i have a sony tv, but its older without android
[23:21:19 CEST] <JEEB> they just released a new set of models with "HDR", probably going to poke a store and test or something
[23:22:19 CEST] <nevcairiel> i've been pondering getting a UHD TV, but this years models still seem to be "too early"
[23:22:23 CEST] <nevcairiel> although much better then last years
[23:22:46 CEST] <Mavrik> Yeah, not until UHD content shows up in decent numbers.
[23:23:07 CEST] <Mavrik> And people stop having silly compatibility issues with receivers / HDMI / new DTS or whatnot
[23:27:46 CEST] <TD-Linux> oh don't worry they thought of that already, and added propagation time checks and projector brightness limits
[23:29:14 CEST] <Mavrik> :P
[23:29:32 CEST] <Mavrik> DRM for their DRM and self-destructing BRs standard yet?
[00:00:00 CEST] --- Tue May 10 2016
1
0
[00:33:33 CEST] <CoJaBo> Can anyone decipher "Past duration 0.679985 too large" for me? It seems to be causing dropped(==) frames every 2 seconds
[00:39:41 CEST] <jonascj> Hi all. I have an mp4 file for which "ffmpeg -i file.mp4" outputs "Stream #0:0(eng): Audio: aac (mp4a / 0x6134706D), 22050 Hz, stereo, fltp, 62 kb/s" among other things (like chapters). Is that 62kbit/s?
[00:40:04 CEST] <c_14> yes
[00:40:38 CEST] <jonascj> just like mp3 audio would typically be above 128kbit/s?
[00:40:56 CEST] <c_14> yes
[00:42:17 CEST] <jonascj> of course the codec here is acc, which should perform better than mp3 at the same bitrate, but still. This is audible.com's best quality, converted to mp4, not reencoding... kind of disappointing.
[00:42:25 CEST] <jonascj> I had to admit though, that it sounds okay
[00:43:32 CEST] <klaxa> it may be variable bitrate
[00:43:59 CEST] <c_14> If it's spoken voice, 62kb/s is relatively normal
[00:44:19 CEST] <klaxa> that too, would fit the 22050 Hz too
[00:44:26 CEST] <jonascj> it is spoken voice, an audiobook
[00:45:00 CEST] <jonascj> does halving the sample rate effectively double the bitrate?
[00:45:34 CEST] <jonascj> it feels like it should save space somewhere. It cuts the filesize in half I suppose
[00:48:40 CEST] <jonascj> well if the quality should remain the same, and the sampling frequency should double (to 44100Hz) the bitrate would have to double as well. So I answered my own question I think. I.e. if it was 44100Hz then it would probably have been 124kb/s which is more like the mp3 128kb/s @ 44100Hz I am use to
[00:50:36 CEST] <jonascj> Thanks for clarifying this.
[01:07:57 CEST] <klaxa> jonascj: i'm not so sure about halving it, since i don't know how audio codecs work
[01:08:47 CEST] <klaxa> i imagine they don't compress every sample for itself
[01:14:59 CEST] <iive> jonascj: mos/al mp3 encoders cut frequencies above 16kHz, so you are already limited to something like 32kHz sampling.
[08:35:20 CEST] <computer> hey people. can i convert from .SWF to .AVI or .M4P with high quality? when i use the -i command to convert to .AVI it is not very high quality
[08:36:10 CEST] <computer> i use the command ffmpeg -i file.swf file.avi
[08:41:27 CEST] <furq> replace avi with mp4
[08:42:05 CEST] <computer> furq: i get only aufio
[08:42:23 CEST] <computer> also when i convert to AVI i get a GREAT ZOOMED video of a mouse moving
[08:43:41 CEST] <computer> furq: i think ffmpeg is chaging the screen size
[08:49:39 CEST] <computer> furq: i am having an issue with converting the file correctly, i think because it id flash and it has a mouse pointer moving and ffmpeg is only converting the mouse movement. can you assist me? i have 300 files to convert i can send you one and see which commads can best help me?
[09:05:30 CEST] <computer> any help
[09:05:31 CEST] <computer> ?
[09:08:44 CEST] <computer> i am getting the following error:
[09:08:46 CEST] <computer> Input stream #0:0 frame changed from size:27x6 fmt:argb to size:87x38 fmt:argb
[09:32:05 CEST] <neuro_sys> doc/examples helped me understand the basics of io, demuxing, filtering and whatnot, and now I need to look into how to feed a raw in memory image into the filter. (Would that be by reading the raw data into an AVFrame struct?
[09:59:37 CEST] <Mavrik> neuro_sys, pretty much
[10:01:21 CEST] <fling> I'm reencoding mjpeg from a static camera to h264. How do I increase the time between keyframes properly? The image is mostly static.
[10:08:24 CEST] <furq> fling: -g and/or -x264opts keyint_min
[10:09:28 CEST] <furq> although -g should default to 250 which is a sensible value
[10:13:52 CEST] <JEEB> I recommend -x264params because I think that one actually just passes things to libx264 as-is
[10:14:02 CEST] <JEEB> while -x264opts had some extra internal parsing in it
[10:14:08 CEST] <JEEB> unless they are synonyms now
[10:14:19 CEST] <JEEB> or was it -x264-params... don't remember
[10:15:05 CEST] <JEEB> yeah, x264-params
[10:17:06 CEST] <JEEB> yeah, x264opts goes into an OPTS macro while x264-params passes the key-value pair straight into x264_param_parse
[10:17:10 CEST] <JEEB> which is libx264
[10:17:32 CEST] <JEEB> x264opts works with many things because they were manually defined in libavcodec's libx264.c :)
[10:17:33 CEST] <mrteatime> Sorry to dive right in, but anyone experienced with sending rgb32 rawvideo over udp who can help me?
[10:18:00 CEST] <mrteatime> Having some strange issues with playback and its related to the udp itself, as it playsback fine from a local file.
[10:19:28 CEST] <Mavrik> yuck
[10:19:31 CEST] <Mavrik> Why O.o
[10:20:36 CEST] <mrteatime> Why am i streaming rawvideo over udp? gonna use a usb 3.1 crossover cable to get a 10gbps stream from one pc to another, so i can offload the encoding to a seperate rig.
[10:22:08 CEST] <mrteatime> Problem is im doing local tests right now by playing back the file on the rig that is streaming it, and while i get the video feed and the color is correct, it spazzes the fuck out.
[10:22:41 CEST] <mrteatime> And by spazzes out i mean the frames look like they are just moving around freely, kinda like how you would imagine a fly sees tv.
[10:37:41 CEST] <Mavrik> mrteatime, that would probably be UDP at high bandwidths :)
[10:38:52 CEST] <mrteatime> Oh it is trust me, bandwidth requirement is about 3.7 GiBps but as i mentioned earlier, i have a 10 GiBps cap so bandwidth isnt a problem.
[10:39:54 CEST] <mrteatime> What im trying to figure out is why the playback isnt working properly, rawvideo alone works fine, udp works fine, but throw the two together and it just breaks.
[10:40:57 CEST] <mrteatime> Only thing i have to work off is that ffplay is giving me an invalid buffer size error, but for the life of me i cant find anyway to modify the buffer size let alone find the settings i need for it.
[10:41:24 CEST] <Mavrik> With UDP working correctly, do you mean that you verified if your packets are coming in in the proper order_
[10:41:25 CEST] <Mavrik> ?
[10:43:02 CEST] <mrteatime> The way i checked if udp was working is i did the same setup but with mpegts as the output instead of rawvideo
[10:43:56 CEST] <mrteatime> The mpegts came in just fine where as the rawvideo has the afforementioned problems (so hard to describe what it looks like haha)
[10:44:58 CEST] <mrteatime> if it helps these are my ffprompt settings, ffmpeg -f gdigrab -framerate 60 -offset_x 0 -offset_y 0 -video_size 1920x1080 -i desktop -f rawvideo -tune zerolatency udp:/127.0.0.1:1234, ffplay -video_size 1920x1080 -pixel_format bgra -framerate 60 -f rawvideo udp://127.0.0.1:1234
[11:05:34 CEST] <__jack__> hi, I've got an expert issue; Using an old self-compiled ffmpeg (probably from git, march 2015), the output ts has stream type 06 for audio; using ffmpeg 3.0, it now has stream type 87, and my stupid player won't handle it
[11:05:48 CEST] <__jack__> is there a way to add some kind of mapping or something ?
[11:06:16 CEST] <__jack__> (recompile is not really an option)
[11:08:23 CEST] <neuro_sys> Why are some functions postfixed with 2 such as avcodec_open2? Because once there was a avcodec_open, and kept backwards compatibility until it was deprecated and removed completely?
[11:08:52 CEST] <JEEB> yes
[11:08:58 CEST] <JEEB> first you get a warning
[11:09:03 CEST] <JEEB> when you build that is
[11:09:09 CEST] <JEEB> that you're using deprecated stuff
[11:09:15 CEST] <JEEB> then at some point it will stop compiling
[11:15:14 CEST] <__jack__> JEEB: no idea for my shitty issue ? :p
[11:15:32 CEST] <CoJaBo> The point it stops compiling is always when I try to compile it :/
[11:17:40 CEST] <CoJaBo> ffmpeg's errors are really terrible
[11:25:50 CEST] <__jack__> that id is define here: libavformat/mpegts.h:63, hum
[11:27:03 CEST] <BtbN> type 06 sounds entirely wrong for an audio stream.
[11:28:16 CEST] <mrteatime> just gonna re ask now that people are active, does anyone have experience with streaming rgb32 rawvideo over udp to ffplay
[11:29:07 CEST] <BtbN> don't stream raw video.
[11:29:12 CEST] <mrteatime> Everytime i do it ffplay is getting the stream but is reporting that the buffer size is incorrect and the frames are moving around rapidly.
[11:29:17 CEST] <mrteatime> Thats not an option btb
[11:29:40 CEST] <mrteatime> Im streaming uncompressed via a 10GiBps network connection to a seperate rig that will handle the encoding process.
[11:29:49 CEST] <mrteatime> Aka if its not raw i may aswell just not bother.
[11:30:09 CEST] <BtbN> Use a lossless codec, but streaming raw video frames won't work overly well.
[11:31:11 CEST] <mrteatime> The main reason i am going for raw is i want to avoid the encoding process all together for latency reasons on source machine, not so much for quality.
[11:31:16 CEST] <__jack__> BtbN: you're probably right, closed-source player powered, who knows how it works .. :)
[11:31:28 CEST] <mrteatime> Otherwise i wouldve gone lossless ages ago.
[11:31:53 CEST] <BtbN> raw video doesn't have timestamps or the slightest error correction.
[11:32:07 CEST] <BurnerGR> mrteatime, I had the same problem as you with udp
[11:32:10 CEST] <BtbN> Lose a single byte in transport and the stream is done for forever
[11:32:31 CEST] <__jack__> found a -mpegts_flags system_b that may do the job; Now looking at "how use -hls_ts_options with a boolean option"
[11:32:36 CEST] <__jack__> (if you've a clever tip :p)
[11:33:05 CEST] <BtbN> Use an IFrame-Only intermediade codec, like huffyuv.
[11:33:08 CEST] <BurnerGR> mrteatime, I ended up using pipe output to tcpdump, that works :)
[11:33:29 CEST] <BurnerGR> but the will be a point to point tcp connection
[11:35:13 CEST] <mrteatime_> The issue is i dont actually want timestamps in the feed.
[11:35:27 CEST] <mrteatime_> Because frankly im trying to avoid overhead, not add to it.
[11:36:41 CEST] <BurnerGR> mrteatime_, did you try with tcp instead?
[11:36:58 CEST] <BtbN> You definitely do want the overhead of some kind of container. As you already found out what happens without it.
[11:37:22 CEST] <BurnerGR> udp can arrive out of order, and might drop packets at random, even on LAN
[11:37:30 CEST] <mrteatime_> Btb no i didnt find out what happens without it because surprise surprise, i can actually play the rawvideo fine with no issues what so ever.
[11:37:40 CEST] <mrteatime_> Its only when i introduce it into a udp stream that errors occur
[11:37:52 CEST] <BtbN> mrteatime_, you just said you couldn't.
[11:37:52 CEST] <mrteatime_> thats what im trying to fix, not the codec
[11:38:03 CEST] <mrteatime_> no i said that i cant play it back via udp
[11:38:07 CEST] <BtbN> exactly
[11:38:17 CEST] <mrteatime_> if i record to a local rgb32 file and play that its no issue
[11:38:32 CEST] <BtbN> Of course, because you don't sent it over a network via udp.
[11:39:21 CEST] <BurnerGR> mrteatime_, did you try tcp?
[11:39:31 CEST] <mrteatime_> Trying it now burner
[11:39:37 CEST] <BurnerGR> ok :)
[11:39:49 CEST] <BurnerGR> netcat is your friend :)
[11:39:51 CEST] <BtbN> I'd guess tcp has a higher overhead than a lossless codec...
[11:40:00 CEST] <BurnerGR> indeed
[11:40:14 CEST] <mrteatime_> But btb just gotta mention, so you are saying that by sending a rawvideo feed to localhost, not over the network but in local testing, i am somehow magically putting the frames out of order
[11:40:35 CEST] <mrteatime_> despite having a theoretical infinite bandwith in my testing scenario and absolutely no packetloss
[11:40:45 CEST] <BtbN> It's UDP, even on localhost it can easily drop packets if you are sending massive amounts of data(like, raw video frames)
[11:41:52 CEST] <BtbN> A codec + container can compensate for that, a raw video stream is just irreversibly damaged if that happens.
[11:42:30 CEST] <BtbN> I wouldn't even trust TCP enough for a long running raw video stream.
[11:47:20 CEST] <BurnerGR> BtbN, I've run a setup like this for more than a year, without problems, but my "long-running" streams are rarely more than 16 hours
[11:47:42 CEST] <BtbN> TCP is quite good at preventing this. But it's not 100% perfect.
[11:48:09 CEST] <BtbN> If something happens, it's usualy a bit flip or something like that, which doesn't break the stream.
[11:48:19 CEST] <BtbN> What breaks it is adding/removing bytes.
[11:49:47 CEST] <BurnerGR> I have a hard time finding a lossless codec which does not need a noicy server to keep up :/
[11:50:21 CEST] <BtbN> huffyuv, ffv1
[11:51:21 CEST] <Qann> Guys, I'm trying to use an external libav source I've compiled but I'm not sure whilst compiling if FFmpeg uses them or not. Does it? Or should I replace the libav* folders somehow
[12:25:41 CEST] <Bluez_> hi
[14:25:10 CEST] <fling> JEEB: which value is to use instead of 250 for a really static camera?
[15:40:33 CEST] <odinsbane> Can I tell the x264 encode to not use compression?
[15:41:48 CEST] <c_14> No
[15:41:53 CEST] <c_14> You can tell it to use lossless compression.
[15:42:00 CEST] <iive> odinsbane: x264 supports lossless compression, in case this is what you want
[15:42:30 CEST] <iive> if you don't want any compression, then don't use compressor :)
[15:44:33 CEST] <c_14> ffmpeg -codecs | grep -E ' .EV.+(Unc|raw)' <- should list most uncompressed/raw video codecs
[15:46:01 CEST] <odinsbane> Must mean lossless, or not to use another program to compress the video. A site is asking for H.264 encoded videos...do not compress the video.
[15:56:08 CEST] <DHE> maybe they mean don't try to ZIP it or something like that
[17:00:22 CEST] <Prelude2004c> hey guys
[17:00:53 CEST] <Prelude2004c> i keep getting errors like this and the encoding drops.. " [mpegts @ 0x36b7180] Non-monotonous DTS in output stream 0:0; previous: 38545191, current: 38545191; changing to 38545192. This may result in incorrect times
[17:00:54 CEST] <Prelude2004c> tamps in the output file. " .. anyone know any way around this ?
[17:01:02 CEST] <Prelude2004c> how do i create my own so its not dependant on a file or something
[17:01:27 CEST] <DHE> you doing this in C or with ffmpeg itself?
[17:04:46 CEST] <DHE> never mind, C doesn't "change" it
[17:15:24 CEST] <boegel> quick question: are there any backwards incompatible changes in FFmpeg 3.0 compared to 2.8.x?
[17:28:35 CEST] <jbreeden> I asked this question a couple weeks ago, figured I'd ask again to get a fresh pair of eyes on it: I have transport streams with embedded metadata (AVMEDIA_TYPE_DATA), and I'm trying to convert it to AVMEDIA_TYPE_SUBTITLE so that I can apply my custom parsing and export it as WebVTT. I've written the decoder, but it only works if I edit the TS demuxer to treat the data as subtitles from the get-go. Does FFmpeg provide a mechanism th
[17:29:04 CEST] <jbreeden> be converted to a subtitle stream without mucking with FFmpeg's internals?
[17:49:01 CEST] <Prelude2004c> DHE ,, you talking to me ? i am using ffmpeg
[17:54:40 CEST] <fling> JEEB: or should I tune the min value somehow?
[18:00:01 CEST] <neuro_sys> Is it possible to specify frame numbers rather than seconds (for cutting)?
[18:01:20 CEST] <furq> fling: scenecuts are only forced before the -g interval if there's a scenecut, which it sounds like there isn't
[18:01:48 CEST] <furq> and you can only seek to keyframes, so increasing -g much beyond 250 will cause problems with seeking
[18:02:07 CEST] <furq> i would just use the defaults, there aren't particularly great space savings to be had
[18:02:19 CEST] <furq> unless you're never going to seek this video
[18:03:49 CEST] <fling> furq: thanks! :>
[18:06:36 CEST] <fling> furq: what else could I tune to save some space with this fixed camera video?
[18:07:05 CEST] <fling> DHE: how exactly do I denoise?
[18:08:08 CEST] <DHE> fling: that question was answered in #x264
[18:08:32 CEST] <fling> Thanks.
[18:08:59 CEST] <furq> denoise, slower preset, higher crf, lower resolution, etc
[18:24:14 CEST] <vade> so im using XCode + guard malloc / guard edges / / scribble - and I notice that it logs SSE should work - but then get an unnamed function for vmovdqu which is a AMX / simd extention used in libswscale - im wondering if im hitting a vector addition that guard malloc is unaware of in some inline assembly? Has anyone seen similar issues when debugging with ffmpeg?
[18:33:09 CEST] <fling> crf=23 with preset=veryslow is not giving me much space savings over mjpeg but takes a lot of time to reencode
[18:34:58 CEST] <fling> the resulting video takes ~70% of the original space
[19:02:58 CEST] <arbi> Anyone here used ffmpeg with cinelerra?
[19:03:37 CEST] <Elgul> no
[19:03:59 CEST] <arbi> You're answering for everyone? :-)
[19:04:07 CEST] <Elgul> no just for me
[19:04:09 CEST] <Elgul> ;__;
[19:04:45 CEST] <arbi> I just compiled latest ffmpeg and suddenly Cinelerra has problems rendering
[19:04:56 CEST] <Elgul> :/
[19:05:06 CEST] <Elgul> I never used cinelerra
[19:05:12 CEST] <arbi> ok
[19:05:16 CEST] <Elgul> is it even using ffmpeg?
[19:05:58 CEST] <arbi> there's a workaround for renderieng h264 which uses ffmpeg pipe
[19:06:09 CEST] <Elgul> nice
[19:06:57 CEST] <arbi> it worked just fine before.. why would newer ffmpeg have problems?
[19:07:39 CEST] <Elgul> I also had problems with ffmpeg when I used the self compiled version
[19:07:57 CEST] <Elgul> it always complained about vp9 and that I need to use -strict 2
[19:08:04 CEST] <Elgul> with the repo versions this never happend to me
[19:08:30 CEST] <arbi> ffmpeg itself seems to work ok.. it's cinelerra that wont render
[19:08:49 CEST] <Elgul> I also had a rendering problem 2 weeks ago while using kdenlive
[19:08:54 CEST] <arbi> maybe it can't locate ffmpeg I don't know
[19:09:03 CEST] <arbi> hmm
[19:09:09 CEST] <Elgul> and I also thought it would be a ffmpeg problem
[19:09:11 CEST] <Elgul> but it wasnt
[19:09:21 CEST] <furq> arbi: does it use the ffmpeg libs or the binary
[19:09:27 CEST] <Elgul> in my case I just used the blur effect too much
[19:09:57 CEST] <arbi> It pipes like this
[19:09:58 CEST] <arbi> ffmpeg -f yuv4mpegpipe -i - -y -vcodec libx264 -crf 21 -preset medium %
[19:10:59 CEST] <furq> and what error do you get
[19:12:08 CEST] <arbi> Can't copy the darn error message.
[19:12:30 CEST] <arbi> int YUVStream::write_frame(uint8 t**): write_frame() failed: system error (failed read/write)
[19:12:41 CEST] <arbi> That's the error
[19:12:59 CEST] <Elgul> read/write could this be a permission thing?
[19:13:02 CEST] <arbi> Problem is that you get the same error if you don't have ffmpeg installed
[19:13:32 CEST] <arbi> It's not permission.. same user can run it in the terminal
[19:14:22 CEST] <arbi> The only change that I've done is to compile new ffmpeg. Which is globally accessable
[19:14:30 CEST] <furq> cinelerra's website is really remarkably bad
[19:14:49 CEST] <arbi> :)
[19:15:34 CEST] <arbi> Well Cinelerra is pretty good video editor..
[19:15:52 CEST] <Elgul> it could also be a PATH thing
[19:15:56 CEST] <Elgul> have you checked that?
[19:16:14 CEST] <arbi> Elgul: What should I check?
[19:16:23 CEST] <Elgul> if ffmpeg is in your path
[19:16:25 CEST] <furq> all i want to know is if it depends on libavcodec et al but this website is totally useless and it's not in any repos
[19:16:55 CEST] <arbi> which site are you looking?
[19:16:59 CEST] <furq> cinelerra.org
[19:17:04 CEST] <arbi> I'm actually using Cinelerra-cv
[19:17:55 CEST] <arbi> Elgul: The path to new version is in $PATH
[19:17:59 CEST] <furq> oh this website is less useless
[19:18:05 CEST] <arbi> hehe
[19:19:07 CEST] <furq> never mind, it looks like it ships with libavxyz so presumably they're static linked
[19:19:13 CEST] <furq> which makes sense i guess
[19:19:53 CEST] <arbi> :-/
[19:23:47 CEST] <cowai> $ ffmpeg -loglevel error -loop 1 -i static.jpg -f lavfi -i aevalsrc=0 -t 1 -shortest -strict experimental -c:a aac -b:a 256000 -ar 48000 -ac 2 -c:v libx264 -profile:v high -level 4.0 -b:v 3000000 -r 30 -g 30 -s 1920x1080 -pix_fmt yuv420p -f matroska -y "/tmp/test.mkv" && ffprobe -hide_banner /tmp/test.mkv 2>&1 |grep Duration
[19:23:47 CEST] <cowai> Duration: 00:00:01.02
[19:24:36 CEST] <cowai> I need to generate a mkv file with empty audio track and a static image for video that last exactly 1 second or 30 frames
[19:25:04 CEST] <furq> cowai: -frames:v 30
[19:25:35 CEST] <cowai> still 1.02 with that option
[19:26:02 CEST] <cowai> if I remove "-t 1" I get 1.20 instead of 1.02
[19:26:50 CEST] <cowai> I have tried ffmpeg 2.8 and 3.0.
[19:26:54 CEST] <cowai> same result
[19:28:31 CEST] <cowai> If I replace the audio params with "-an" and keep -t 1 I get 1.00 second
[19:29:09 CEST] <cowai> But I need there to be a silent audio track because I am concatting these files with some videos files that has audio.
[19:30:54 CEST] <cowai> @furq: any ideas?
[19:31:00 CEST] <furq> what happens if you remove -shortest
[19:31:30 CEST] <cowai> 1.02
[19:32:28 CEST] <cowai> if I use libvorbis instead of aac, I get 1.0
[19:32:33 CEST] <cowai> *1.00
[19:34:49 CEST] <brontosaurusrex> is opus any less supported (in webm with vp9 video) than vorbis this days?
[19:34:59 CEST] <furq> i guess it's something to do with aac frame duration then
[19:35:06 CEST] <brontosaurusrex> browser playback I mean.
[19:35:27 CEST] <furq> i don't think 1000 is divisible by the frame duration at 48khz, but i'm not an expert on aac
[19:35:56 CEST] <furq> brontosaurusrex: not on desktop
[19:36:02 CEST] <drv> http://caniuse.com/#feat=opus
[19:36:06 CEST] <furq> yeah
[19:36:10 CEST] <furq> http://caniuse.com/#search=vorbis
[19:36:18 CEST] <furq> only difference is the android browsers
[19:36:47 CEST] <furq> edge 14 will have opus and not vorbis, though, so it cancels out
[19:37:05 CEST] <cowai> furq: you may be right, when I use 25 fps it works
[19:37:47 CEST] <furq> by works do you mean 30 frames or 1 second
[19:37:52 CEST] <brontosaurusrex> thanks
[19:37:57 CEST] <cowai> 1 second
[19:38:17 CEST] <cowai> is it not possible to get a 1 second clip with aac ?
[19:38:18 CEST] <furq> the video framerate wouldn't affect that if it is to do with aac frame duration
[19:40:07 CEST] <furq> but yeah afaik at 48khz each aac frame is 21.33ms
[19:40:50 CEST] <brontosaurusrex> hmm, so android has crappy opus support for some reason?
[19:41:04 CEST] <cowai> is there another samping rate I can use that would fit?
[19:54:58 CEST] <brontosaurusrex> actually 94% for h.264 vs 73% for vp9 (localy), probably not really worth bothering.
[19:56:27 CEST] <Prelude2004c> hey guys.. sorry to be a bother.. i still can't figure out this..
[19:56:28 CEST] <Prelude2004c> " [mpegts @ 0x36b7180] Non-monotonous DTS in output stream 0:0; previous: 38545191, current: 38545191; changing to 38545192. This may result in incorrect times
[19:56:43 CEST] <Prelude2004c> randomly my files show that... and i don't know what to do about it.. it crashes up the whole thing :(
[19:56:49 CEST] <Prelude2004c> how do i ignore those errors and keep going
[19:57:05 CEST] <Prelude2004c> can i not generate my own timestamps or DTS or something
[19:57:17 CEST] <Prelude2004c> so it its fresh and does not care too much about the source issue
[19:57:31 CEST] <Prelude2004c> when i play the file on VLC , it works fine :(. when i try to transcode it using ffmpeg.. it acts up
[20:06:04 CEST] <vade> im concerned im misunderstanding something or configuring my encoders video stream time base and video streams codec context time base incorrectly, as im getting way higher frame rates for some video than I should be. Does this look correct? https://gist.github.com/vade/4a1084e697c0a3cb33ffd6ce6fe47f6e
[20:06:05 CEST] <vade> my encoder has a reference to the decoder to get its video stream info to match
[20:06:34 CEST] <vade> but im wondering if im setting up ticks_per_frame incorrectly, or should not be poking at the codec context struct directtly. Something is definitely wron
[20:06:35 CEST] <vade> g
[20:08:56 CEST] <computer> people i am having trouble converting a flash video, can someone help me? please?
[20:16:14 CEST] <computer> ffmpeg is changing my screen and zooming greatly, how can i avoid that?
[20:18:11 CEST] <computer> i am getting this:
[20:18:14 CEST] <computer> Input stream #0:0 frame changed from size:58x62 fmt:argb to size:42x47 fmt:argb
[20:22:38 CEST] <neuro_sys> Could anyone point out the link to between() in documentation?
[20:22:54 CEST] <furq> neuro_sys: http://ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation
[20:23:05 CEST] <computer> ?
[20:24:19 CEST] <neuro_sys> furq: thanks
[20:24:25 CEST] <computer> anyone understands my bug?
[20:25:13 CEST] <neuro_sys> so to apply a filter between a specific interval I should be using enable=between(t, s, e). However can it operate on the timestamp format? (still reading.)
[20:26:10 CEST] <furq> neuro_sys: https://ffmpeg.org/ffmpeg-filters.html#Timeline-editing
[20:26:42 CEST] <neuro_sys> furq: It's only seconds precision? Actually I needed milliseconds precision.
[20:27:46 CEST] <furq> looks like it
[20:27:57 CEST] <neuro_sys> oh bummer...
[20:28:06 CEST] <furq> i've never needed ms precision independent of framerate, so i'm not totally sure
[20:28:30 CEST] <neuro_sys> I'd rather work with frame numbers, but apparently ffmpeg using timestamp for such needs.
[20:28:52 CEST] <furq> replace t with n to use frame numbers
[20:29:13 CEST] <neuro_sys> furq: oh, right
[20:29:22 CEST] <computer> guys what is the best format to convert .swf files to?
[20:29:54 CEST] <furq> computer: if it's not being decoded properly then it makes no difference which output format you use
[20:30:26 CEST] <neuro_sys> furq: FWIW, I have a set of images (generated by opengl), that I need to overlay between certain intervals on a video.
[20:30:38 CEST] <computer> furq: what do you suggest i do? i have been reading the documentation today, but did not understand how to fix my issue
[20:31:09 CEST] <computer> there is nothing wrong with the file, it plays perfectly. but i cannot convert it properly
[20:31:20 CEST] <furq> i have no idea how good ffmpeg's support for swf is
[20:31:26 CEST] <furq> i can't imagine it's possible for it to be complete
[20:31:43 CEST] <furq> there's no correct way to convert an interactive swf, for example
[20:32:37 CEST] <computer> furq: hmmm, the video has a mouse moving, but no interaction (buttons, clicks etc...) and effmpeg is only converting the mouse movement
[20:35:51 CEST] <neuro_sys> Am I missing something here (testing): -filter_complex "[0:v][1:v]overlay:enable='between(t, 1, 1)'[out]" and I get
[20:35:54 CEST] <neuro_sys> No such filter: 'overlay:enable'
[20:36:24 CEST] <furq> overlay=enable=
[20:36:35 CEST] <neuro_sys> oh yes
[20:37:12 CEST] <neuro_sys> between(t, 1, 2) but anyways, thanks
[20:38:12 CEST] <computer> furq: is there a way to by pass this and just convert the whole file, not the mouse movement?
[20:53:44 CEST] <yongyung> I want to convert a video to a most easily decodeable, lossless format. So essentially uncompressed. pix_fmt is yuv420, but what would I use as codec?
[20:54:18 CEST] <neuro_sys> Let's say I have N number of input streams (each one a set of images fed from stdin in the form of %4d.png). Can I apply a distinct overlay filter using enable=between with each of the input streams for different intervals? I'm thinking along the lines of ffmpeg -i base -i input1 -i input2 -filter_complex "[0:v][1:v]overlay=enable='between(n,1,2)'[out1]" -filter_complex
[20:54:23 CEST] <neuro_sys> "[out1][2:v]overlay=enable='between(n,3,4')[out2]" -map '[out2]' output.mp4
[20:55:12 CEST] <computer> can someone help me covert my file? it is only 1 minute long
[20:55:45 CEST] <furq> neuro_sys: you can only call filter_complex once
[20:56:07 CEST] <furq> separate them with ;
[20:56:32 CEST] <neuro_sys> furq: It worked!
[20:56:35 CEST] <neuro_sys> thanks again
[20:56:49 CEST] <llogan> yongyung: -c:v rawvideo if you want raw video
[20:56:59 CEST] <neuro_sys> I still should take the time to use libav* with C though... (if only the deadline wasn't a couple days away)
[21:00:09 CEST] <furq> yongyung: probably ffv1
[21:02:03 CEST] <yongyung> rawvideo seems fine
[21:02:35 CEST] <furq> if you have enough space and disk speed for rawvideo then sure
[21:03:12 CEST] <yongyung> It's just for testing purposes^^
[21:13:33 CEST] <arbi> furq: If you're interested the write fail problem with ffmpeg was caused by a space in the filename
[21:22:34 CEST] <Qann> Guys, I'm trying to use an external libav source I've compiled but I'm not sure whilst compiling if FFmpeg uses them or not. Does it? Or should I replace the libav* folders somehow
[22:29:40 CEST] <brontosaurusrex> A nice CRF + fast + multithreaded VP9 example?
[22:43:30 CEST] <neuro_sys> "[image2 @ 0x5ec4260] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)" Is this something to be concerned?
[22:44:44 CEST] <durandal_1707> how many threads you use?
[22:45:08 CEST] <neuro_sys> The message says 8, but I'm not giving any specific parameters for it
[22:45:39 CEST] <durandal_1707> how many cores/cpus?
[23:31:45 CEST] <Prelude2004c> hey, can anyone help ? [mpegts @ 0x36b7180] Non-monotonous DTS in output stream 0:0; previous: 38545191, current: 38545191; changing to 38545192. This may result in incorrect times
[23:42:21 CEST] <vade> i understand that when one calls avformat_write_header a streams time_base might be altered - what prompts a drastic change from requesting 2997 to getting 11984 ?
[23:47:32 CEST] <neuro_sys> when I feed a video stream as %4d.png format, it doesn't work, while for indivial pngs it works, any ideas?
[23:55:24 CEST] <Mavrik> vade, hrmf, it shouldn't really.
[23:55:29 CEST] <Mavrik> Which muxer?
[23:55:56 CEST] <vade> hi Mavrik - im using MP4
[23:56:59 CEST] <Mavrik> hm, I don't see the source touching that field
[23:57:00 CEST] <vade> Mavrik: I log my settings . I build my video stream and video streams -> codec via introspection on the source
[23:57:05 CEST] <vade> https://gist.github.com/vade/4acd447dab0dd9b307b7ffe49625f179
[23:57:18 CEST] <vade> let me share how I set up my videoStream
[23:58:05 CEST] <vade> Mavrik: https://gist.github.com/vade/2d3853f55de30e9fa8c878f54d8dafaa
[23:59:28 CEST] <vade> oh, that snipped was from the wrong video (the output from my app) Its weird. I cant seem to get my app to return the right ffprobe output for fps, tbn, tbc,
[00:00:00 CEST] --- Tue May 10 2016
1
0
[00:02:42 CEST] <jamrial> please do it, then. no one else is reviewing it so i want to push it if it's robust enough
[00:02:49 CEST] <jamrial> there's a link to samples in the patchset thread
[00:03:10 CEST] <kierank> I need a way to apply the patchset though
[00:03:39 CEST] <jamrial> only the last patch, [PATCH v2 0/3] DTS Express (LBR) decoder
[00:03:44 CEST] <jamrial> the rest have been applied already
[00:04:12 CEST] <kierank> yeah but I can't actually apply the patch
[00:04:13 CEST] <michaelni> Daemon404, wmv-intrax8 fails: http://fatebeta.ffmpeg.org/report/x86_64-archlinux-gcc-experimental/2016050…
[00:04:13 CEST] <jamrial> err, 3/3
[00:04:17 CEST] <kierank> i need it as an mbox
[00:04:32 CEST] <michaelni> Daemon404, also is it intended to have 2 tests
[00:04:43 CEST] <michaelni> tests/fate/microsoft.mak:fate-wmv8-x8intra: CMD = framecrc -flags +bitexact -idct 19 -i $(TARGET_SAMPLES)/wmv8/wmv8_x8intra.wmv
[00:04:53 CEST] <michaelni> tests/fate/microsoft.mak:fate-wmv8-intrax8: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/wmv8/wmv8_x8intra.wmv -an
[00:05:02 CEST] <michaelni> using the same sample
[00:08:45 CEST] <Daemon404> michaelni, fate ran fine here, oddly
[00:09:08 CEST] <Daemon404> i have a vague memory of that test existing in the past and being removed
[00:09:15 CEST] <Daemon404> you dont happen to remember details do you
[00:11:38 CEST] <Daemon404> hmmm mayeb related to idct 19?
[00:11:40 CEST] <Daemon404> what does that do
[00:11:52 CEST] <Daemon404> the 2nd test can probably be removed
[00:13:00 CEST] <Daemon404> https://github.com/FFmpeg/FFmpeg/commit/2169f971ad9b582cc3f1e6a1430aad44d64…
[00:13:14 CEST] <Daemon404> well ok
[00:13:21 CEST] <Daemon404> vague, but it confirms my memory
[00:15:21 CEST] <Daemon404> interestingly it does not fail on any of libav's fate machines that i can see
[00:19:44 CEST] <jamrial> kierank: https://github.com/jamrial/FFmpeg/commits/lbr
[00:20:08 CEST] <kierank> thanks
[00:20:10 CEST] <BtbN> I wonder if they enhanced nvenc with pascal.
[00:21:02 CEST] <jamrial> hevc 10 bit encoding, maybe? or was that already available in maxwell?
[00:21:39 CEST] <nevcairiel> wonder if vp9 10-bit decoding appears
[00:21:48 CEST] <nevcairiel> but possibly not, the media chip from the 960 is still relatively new
[00:22:03 CEST] <BtbN> I don't think there's any 10bit stuff in nvenc yet.
[00:32:54 CEST] <kierank> jamrial: running, expect results tomorrow
[00:48:44 CEST] <jamrial> kierank: ok, thanks
[00:51:37 CEST] <jamrial> kierank: are you forcing the use of the dts demuxer so the fuzzing doesn't make probe fail?
[00:51:41 CEST] <jamrial> the probe function in lavf even does an unconditional crc check
[00:52:23 CEST] <nevcairiel> the decoder checks the crc as well, so that might prevent fuzzing properly
[00:52:54 CEST] <jamrial> but only if crc check is requested
[00:53:02 CEST] <nevcairiel> is that not default for audio?
[00:53:11 CEST] <kierank> using fffuzz, not ffmpeg.c
[00:54:59 CEST] <kierank> perf top shows it decoding
[00:58:14 CEST] <jamrial> nevcairiel: doesn't look like
[02:25:59 CEST] <cone-749> ffmpeg 03Michael Niedermayer 07master:caee88d193fe: fate: Remove duplicate wmv8_x8intra.wmv test
[02:41:56 CEST] <BBB> michaelni: is the dithering patch in vf_colorspace ok with you now?
[02:56:46 CEST] <michaelni> BBB, yes, sure
[11:33:06 CEST] <wm4> I'd rather just drop SDL...
[11:36:55 CEST] <ubitux> i think that's the plan?
[11:36:56 CEST] <nevcairiel> that wmv8_x8intra test asks for idct 19, but we dont have an idct 19
[11:37:02 CEST] <nevcairiel> could that result in it breaking everywhere?
[12:19:16 CEST] <Daemon404> nevcairiel, possibly
[12:21:59 CEST] <BugMaster> Can anybody look at this fix for h264: http://pastebin.com/3KRE17ED ? and submit it to mailing list if this is needed
[12:25:53 CEST] <wm4> which configure options do I need again to get debuggable libavcodec?
[12:31:07 CEST] <ubitux> --disable-stripping
[12:31:13 CEST] <ubitux> --enable-debug
[12:31:23 CEST] <wm4> --enable-debug is the default
[12:31:33 CEST] <ubitux> then only --disable-stripping
[12:31:35 CEST] <wm4> I have --disable-stripping and --disable-optimizations
[12:31:41 CEST] <wm4> but the debugger still gives me shit
[13:57:25 CEST] <Compn> wm4 : only use ffmpeg_g binary after that, too
[13:59:26 CEST] <wm4> I'm not using ffmpeg
[14:02:20 CEST] <nevcairiel> if you want a fully un-optimized build you need to use --optflags=-O0 or -Od, but it may explode DCE depending on your compiler (hence why disable optimizations doesnt do that afaik)
[14:02:48 CEST] <nevcairiel> disable optimizations just doesnt set any optflags by default, leaveing the compiler to its defaults
[15:19:26 CEST] <kierank> I find it hard to believe dts-lbr has no fuzz crashes but it appears so
[15:24:44 CEST] <wm4> someone wrote bug-free code???
[15:26:51 CEST] <kierank> the bitstream might well be resilient
[15:27:08 CEST] <kierank> probably because of checked bitstream reading
[15:28:33 CEST] <kierank> then again the files I've got are very large
[15:28:38 CEST] <kierank> for fuzzing
[15:39:43 CEST] <Daemon404> is that foo86's thing?
[15:39:47 CEST] <Daemon404> he consistently writes very good code.
[15:46:59 CEST] <durandal_17> michaelni: say one do multithread audio decoder, which depends on state of previous decoded frame, who to handle this?
[15:47:49 CEST] <durandal_17> i added init_thread_copy and update_thread_context and ff_thread_report_progress
[15:48:31 CEST] Action: Daemon404 pokes jkqxz
[15:49:01 CEST] <durandal_17> but i fail to understand how to update frames i use in ff_thread_await/report_progress
[16:06:26 CEST] <kierank> Daemon404: yes
[16:18:41 CEST] <michaelni> durandal_17, if for example this is about a normal IMDCT based decoder, each decode_frame() could do bitstream decode of the current frame and then imdct and overlap of this and the previous, the overlap would have to wait for the previous frames imdct
[16:20:14 CEST] <durandal_17> michaelni: yes, but this is about audio, it decompress dsd, and dsd to pcm depends on state of previous frame
[16:21:49 CEST] <durandal_17> decompresssing dsd is very slow ~5x
[16:22:06 CEST] <durandal_17> with 4 threads it goes up to ~13x
[16:22:18 CEST] <durandal_17> but output is not same as for single thread
[16:22:58 CEST] <durandal_17> because I do not sync state between threads properly
[16:25:41 CEST] <durandal_17> and dsd bitstream output does not depends on prev frames
[16:30:10 CEST] <michaelni> isnt dsd just doing a lowpass?, that shuldnt be that slow, lookups should be replaced by multiply and SIMD
[16:30:21 CEST] <michaelni> also indexing in inner loop looks bad
[16:30:29 CEST] <nevcairiel> Could slice thread dsd on a per channel basis
[16:30:55 CEST] <michaelni> buf[(pos - i) & FIFOMASK]; can be changed to use 2x as large buffer and simple indexing
[16:30:59 CEST] <michaelni> nevcairiel, yes, that too
[16:31:16 CEST] <durandal_17> michaelni: i'm not doing dsd to pcm, i doing dst->dsd->pcm, dst->dsd needs to be mt
[16:31:20 CEST] <nevcairiel> Channels are independent of each other, just the same channel requires history
[17:25:14 CEST] <durandal_1707> michaelni: see dst decoder on ml, looking to adr mt support
[17:35:37 CEST] <jkqxz> Daemon404: Pong.
[17:35:49 CEST] <Daemon404> jkqxz, next up for merges is a bunch of patches form you
[17:35:57 CEST] <Daemon404> you mentioned some stuff abotu them but i forget
[17:36:19 CEST] <Daemon404> 4 lavc patches, one to avconv, and one fix after that i will squash in
[17:36:33 CEST] <Daemon404> any i should skip / need attention?
[17:40:14 CEST] <jkqxz> Should be ok. If the avconv one causes trouble then I can look at it; the others will be fine because they just add new stuff.
[17:40:25 CEST] <Daemon404> cool ok
[17:41:48 CEST] <jkqxz> Uh, you didn't merge the vaapi decode fix with the H.264 NAL unit one.
[17:41:56 CEST] <Daemon404> ?
[17:42:05 CEST] <jkqxz> Sorry, I should have looked at that earlier.
[17:42:16 CEST] <Daemon404> https://git.libav.org/?p=libav.git;a=commit;h=b3051a460cf02a5b86ff0d1e14abb…
[17:42:19 CEST] <Daemon404> this?
[17:42:34 CEST] <Daemon404> apologies if i forgot
[17:43:12 CEST] <jkqxz> Yeah. That one needed to go with ca2f19b; the tree is currently broken.
[17:44:06 CEST] <Daemon404> lemme cherry pick it and push
[17:44:37 CEST] <Daemon404> sidenote: merging hw stuff is hard, since i dont actually have a way to test like 80% of them
[17:44:48 CEST] <Daemon404> and there are no fate instances i think
[17:45:22 CEST] <jkqxz> Yeah, I realise it's annoying. If you point me at any intermediate I'm happy to test it for you.
[17:45:35 CEST] <Daemon404> oh good it cherry-picks cleanly
[17:45:37 CEST] <Daemon404> no conflicts
[17:46:20 CEST] <cone-142> ffmpeg 03Mark Thompson 07master:617cd45ddc9b: vaapi_h264: Fix bit offset of slice data.
[17:46:21 CEST] <Daemon404> ^
[17:46:26 CEST] <jamrial> it's not that you forgot, it's just that you didn't get to that point in the merge queue
[17:46:29 CEST] <Daemon404> indeed
[17:47:07 CEST] <nevcairiel> i should probabvly just push a fix for that in dxva2 as well
[17:47:40 CEST] <wm4> hm didn't you say this didn't matter for dxva, or did I just dream this?
[17:48:30 CEST] <jkqxz> My fault; I tried to point it out earlier, but I didn't chase it enough to pull it forward to the point where it broke. Thanks for fixing it now.
[17:48:50 CEST] <cone-142> ffmpeg 03Hendrik Leppkes 07master:64fd62d68abe: avcodec/dxva2_h264: fix slice offset in long slice struct after ca2f19b9
[17:51:31 CEST] <nevcairiel> it doesnt matter for most dxva2 devices, but in a month or so some user with some old-ass intel gpu shows up again and complains, so i rather fix it now =p
[17:52:13 CEST] <nevcairiel> (note that vaapi and dxva2 use a different reference point, so the lines are not exactly equal, dxva starts counting at the RBSP, and vaapi from the full NAL)
[18:28:05 CEST] <kurosu_> btw, as people are speaking of merges, the new bitstream api will be a pain, eg aac
[18:33:41 CEST] <wm4> kurosu_: it's not even in Libav yet
[18:34:23 CEST] <kierank> bitstream reader api?
[18:43:32 CEST] <kurosu_> kierank, yes
[18:43:51 CEST] <kurosu_> wm4, yeah and? it will be, that's not a problem
[18:44:38 CEST] <nevcairiel> cant be any worse than what we have merged before
[18:45:47 CEST] <kurosu_> and it's probably worth it
[18:45:59 CEST] <kurosu_> just that it is yet another amount of work
[18:46:36 CEST] <kurosu_> I'm wondering if it can't just be merged by keeping the get_bits API but just replacing its implementation
[18:46:52 CEST] <kurosu_> unlike you guys prefer seeing the new function names and macros over the old ones
[18:46:57 CEST] <kurosu_> *unless
[18:47:22 CEST] <wm4> separating those two changes would probably have been a good idea
[18:47:49 CEST] <kurosu_> on the other hand, the difference would spiral further away - making later merges even harder
[18:47:57 CEST] <nevcairiel> I dont understand their mentality of change is great in that regard, like "we work on it anyway, so might as well make it as complex as possible"
[18:48:14 CEST] <nevcairiel> it just makes no sense to me
[18:48:38 CEST] <kurosu_> I think they just see it as their hobby, friend-made project and no longer care about overall benefit to users
[18:49:03 CEST] <kurosu_> my feelings, not my discussions with them or anything
[18:49:32 CEST] <nevcairiel> their active user base sure isnt very huge anymore, who really ships libav binaries these days?
[18:50:46 CEST] <kurosu_> I meant: I think they no longer really care about userbase (otherwise the projects would have merged back, anyway) or the like
[18:53:23 CEST] <iive> it's not like they have ever cared about users
[18:53:47 CEST] <kurosu_> I probably did a really bad job of getting my points across and instead just made them ignore me, but I feel my reviews were not exactly considered
[18:53:58 CEST] <kurosu_> iive, that kind of sentence is not helping either
[18:54:06 CEST] <kurosu_> antagonizing them is not helping
[18:54:52 CEST] <iive> well, imho it is better to stop merging libav
[18:54:58 CEST] <kierank> they are literally throwing out the baby with the bathwater by changing all the weird names
[18:55:20 CEST] <kurosu_> the real issue is that it requires more and more efforts, but there is really good stuff in their work
[18:55:42 CEST] <kurosu_> maybe a lot of stuff is useless, but you need that too for easier merges
[18:55:43 CEST] <jamrial> kurosu_: could be that considering your points would mean extra work and/or rewriting some parts, and they don't want to
[18:56:31 CEST] <kurosu_> and maybe they consider it was in bad faith, just to make them waste their time
[18:57:11 CEST] <iive> libav people have never been good in separating personal insults from pointing technical shortcomings
[18:57:17 CEST] <kurosu_> https://lwn.net/Articles/659214/
[18:57:25 CEST] <kurosu_> "And every time that happens, somebody does some silly mistake, and the conversion patch to the improved interface actually makes things worse. Because the patch is mindnumbing and trivial, nobody has the attention span to look at it carefully, and it's usually done over large swatches of source code which means that not every conversion gets tested."
[18:57:38 CEST] <jamrial> iive: that also applies to certain people from this project
[18:57:43 CEST] <wm4> iive: neither have you
[18:57:44 CEST] <iive> kurosu_: i'm quite sure the fault is not in you.
[19:00:00 CEST] <iive> wm4: ?
[19:00:14 CEST] <kurosu_> it's not really the point, more that the situation hasn't improved, and partially because of me
[19:01:01 CEST] <iive> kurosu_: well, maybe i should have warned you. You might have better chance of getting your point, if they don't know that you are working on ffmpeg project.
[19:01:17 CEST] <kurosu_> that's dishonest
[19:01:38 CEST] <kurosu_> and could have ended actually way worse
[19:01:43 CEST] <iive> did you introduce yourself as ffmpeg developer?
[19:02:47 CEST] <kurosu_> nope, I have been for a long time developing on either side, just not for a long time on theirs, for lack of time
[19:02:48 CEST] <jamrial> he's has posted to libav-devel before. he didn't show up on that ml out of nowhere a week ago
[19:02:50 CEST] <iive> well, it's muphy's law that things can always get worse :)
[19:03:34 CEST] <iive> hum... i'm quite sure he said he is not subscribed...
[19:03:42 CEST] <iive> or that was somebody else?
[19:04:49 CEST] <jamrial> kurosu_: in any case, i think one of the points you made was, according to one of libav's developers, only an issue if implemented in our tree. so that may have probably made your argument less valid in their eyes
[19:04:55 CEST] <kurosu_> no idea, but I suscribed in mars 2011
[19:05:07 CEST] <kurosu_> *march
[19:05:39 CEST] <iive> sorry, it really hasn't been you.
[19:05:40 CEST] <nevcairiel> they might want the vc2 stuff as well one day
[19:05:56 CEST] <iive> atomnuker also wanted to talk with them about the bistream api
[19:06:39 CEST] <kurosu_> jamrial, most likely, but I tried at first to be thoughtful by asking privately if it was ok referring to that code
[19:06:50 CEST] <kurosu_> external code has the large issue of being difficult to test
[19:07:11 CEST] <kurosu_> but I'd thought that at least it warranted a look as it meant something was not right
[19:07:21 CEST] <kurosu_> whatever
[19:07:52 CEST] <kurosu_> no point delving on this, it's a minor issue
[19:08:21 CEST] <nevcairiel> it certainly gives one the feeling of not caring much if an actual issue is brushed aside of "not in oru codebase", but shrug
[19:09:05 CEST] <jamrial> especially when, as you said, they may at some point want to port that affected piece of code
[19:09:56 CEST] <kurosu_> for the merge work, I started working on the most impacted (performance-wise, not code-wise) ones, precisely to verify their work
[19:09:59 CEST] <durandal_17> but here are people still wanting to merge every single libav commit whetever it is broken or not
[19:10:33 CEST] <kurosu_> I'm not sure I'll be around to help that effort, all the more since it's the old function names
[19:11:08 CEST] <kurosu_> durandal_17, hindsight is 10/10 - and it helps merging the more important stuff
[19:11:27 CEST] <kurosu_> but if it is obviously broken, sure
[19:11:53 CEST] <kurosu_> I think most people merging are already applying this rationale
[19:12:47 CEST] <iive> there will be a point where rewriting a change from scratch would be easier than trying to merge it.
[19:12:53 CEST] <jamrial> yeah, tons of merged commits are being no-oped for one reason or another
[19:13:10 CEST] <iive> and that point is closing in.
[19:13:11 CEST] <jamrial> usually because they don't apply or because they fix something that we already fixed before
[19:15:06 CEST] <wm4> <iive> there will be a point where rewriting a change from scratch would be easier than trying to merge it. <- you volunteer
[19:15:21 CEST] <jamrial> any hevc decoder change will probably not apply at all. afaik they commited the first openhevc dump years ago then didn't bother backporting anything else
[19:15:45 CEST] <nevcairiel> their is far behind in features as well, similar vp9
[19:18:23 CEST] <nevcairiel> when they ever want to get vp9 hwaccel they'll have to port months of changes, or re-implement it
[19:19:14 CEST] <kurosu_> their mc code could help clean up ours, but keeping the same support with the same code quality is an enormous amount of work, and nobody to sponsor it
[19:19:25 CEST] <kurosu_> *hevc mc
[19:20:04 CEST] <iive> motion compensation?
[19:20:35 CEST] <kurosu_> yes
[19:21:35 CEST] <kurosu_> http://forum.doom9.org/showthread.php?t=173465 <- meanwhile, a "Principal Video Specialist" at Amazon is complaining that the s/w decoding solutions he wants to use (free ones, actually) are not good enough
[19:22:09 CEST] <kurosu_> s/good/fast
[19:22:58 CEST] <iive> wm4: let's say that i'm not interesting in working on ffmpeg, while it's internals and api's are decided by libav.
[19:23:31 CEST] <nevcairiel> lets say we're not interested in people that carry around grudges for years either, we already have too many of those
[19:24:48 CEST] <iive> ^_^
[19:26:05 CEST] <kierank> kurosu_: tough, amazon can spend hundreds of millions on gpl violating encoder manufacturers so clearly they can support OSS
[19:26:36 CEST] <kierank> send patches or send money
[19:26:52 CEST] <iive> nevcairiel: my decision is not matter of grudge. If I want to do API breaking changes, they could easily be rejected because "it would make merging stuff harder"
[19:27:29 CEST] <nevcairiel> if there is a good reason for a change i doubt anyone would block it on such reasons
[19:27:44 CEST] <durandal_17> iive: what api changes you want to make?
[19:30:31 CEST] <iive> durandal_17: e.g. getting rid of avcodec_register_all(), by making it into a static const table
[19:31:15 CEST] <nevcairiel> thats actually something coming from libav to some degree, it already happened for bsf's and protocols
[19:32:10 CEST] <iive> yeh, i had it years ago, but every codec touching was pain to merge
[19:33:10 CEST] <wm4> <iive> wm4: let's say that i'm not interesting in working on ffmpeg, while it's internals and api's are decided by libav. <- that's a passive-aggressive attitude that is supposed to say that Libav ruins ffmpeg development, and that implies you would actually work on ffmpeg if Libav died, which is not the case
[19:34:02 CEST] <kierank> i'd recommend you all put iive on ignore like I have for the past few years
[19:34:52 CEST] <jamrial> can we have a drama free sunday?
[19:36:29 CEST] <iive> wm4: and how do you know this is not the case?
[19:38:29 CEST] <durandal_17> non active devs should be demoted and they should give commit rights back - every sane project does this
[19:39:11 CEST] <jamrial> "Actually, even the H.264 decoder wasn't making any progress in the last few years, IIRC. I think it has actually gotten slower, because the guys (in this case, it's mostly libav I think) kept reformatting and rewriting the code repeatedly for cosmetics/readability/maintainability/etc purposes"
[19:39:11 CEST] <iive> durandal_17: i don't have commit rights at the moment. if that is your concern.
[19:39:21 CEST] <iive> if I go back, I'll start by sending patches.
[19:39:22 CEST] <jamrial> from kurosu_'s link. how true is that?
[19:40:18 CEST] <jamrial> i remember a merge had like 2% performance hit but it was undone in our tree after michaelni pointed it out
[19:40:22 CEST] <durandal_17> well you can try old one and last one and compare....
[19:41:54 CEST] <durandal_17> ultimate goal of every maintainer is to rewrite code from scratch, and than start all over again
[19:42:24 CEST] <jamrial> lol
[19:42:29 CEST] <kurosu_> jamrial, those are mostly users, probably a lot of hearsay
[19:51:38 CEST] <durandal_17> some rscc and screenpreso codec changes are still not merged
[19:54:45 CEST] <durandal_17> do those mpegvideo dependency removals help with speed?
[20:10:54 CEST] <cone-142> ffmpeg 03Rostislav Pehlivanov 07master:b6c207f53581: vc2enc_dwt: use 32 bit coefficients by default
[20:16:39 CEST] <kurosu_> atomnuker, I think it'll be simpler for everyone if you just amend my fate vc2 commit with the correct checksums
[20:21:20 CEST] <atomnuker> kurosu_: ok, will do
[20:43:48 CEST] <cone-142> ffmpeg 03Michael Niedermayer 07master:5df703aa1b03: avcodec/simple_idct_template: Fix strict aliasing violation
[20:44:58 CEST] <nevcairiel> guess the test was good for something afterall
[20:46:33 CEST] <durandal_1707> Easyfab: report delogo bug to tracker?
[20:50:52 CEST] <cone-142> ffmpeg 03Christophe Gisquet 07master:01938585f4ce: vc2: fate tests
[20:57:32 CEST] <durandal_1707> michaelni: so do you have idea how to add mt to dst decoder?
[21:09:15 CEST] <jamrial> atomnuker: yuv420p vc2 is lossless?
[21:10:22 CEST] <atomnuker> if the bitrate is high enough it is lossless, yes
[21:14:04 CEST] <iive> is vc2 the next version of microsoft vc1?
[21:14:58 CEST] <JEEB> no
[21:15:15 CEST] <iive> audio codec?
[21:15:26 CEST] <JEEB> it's just the next in number line in that line of specifications
[21:15:29 CEST] <JEEB> it's dirac
[21:15:30 CEST] <iive> nah..
[21:15:45 CEST] <iive> aha
[21:18:22 CEST] <Easyfab> durandal_1707: I will do report tomorrow
[21:30:12 CEST] <michaelni> durandal_1707, you know DST better than i do, so iam not sure how usefull my comments would be but assuming there are steps that can be run in parallel and ones that cant, the ones that cant need ff_thread_await/report_progress, also any setup data one thread sets that the next needs in its context must be before ff_thread_finish_setup()
[21:34:23 CEST] <durandal_1707> michaelni: how to share frame that we use for await/report progress
[21:35:09 CEST] <durandal_1707> obviously second frame depends on first one
[21:37:29 CEST] <michaelni> hmm alloc frame before finish setup then ref it in update of next thread should work
[21:39:14 CEST] <nevcairiel> the threading is unfortunately designed for the opposite direction, running the things that require context first and the things that run in parallel afterwards
[21:39:15 CEST] <michaelni> maybe libavcodec/mimic.c is a simple example but itts video not audio
[21:39:19 CEST] <nevcairiel> the dst decoding works the other way around
[21:39:42 CEST] <nevcairiel> where it can perform dst in parallel first and dsd decoding in sequence after
[21:41:51 CEST] <michaelni> the last step (DSD) is like the last row in video, it also needs the previous pictures last row potentially
[21:42:37 CEST] <nevcairiel> i suppose
[22:55:31 CEST] <Daemon404> jkqxz, just one line that didnt apply easily
[22:55:46 CEST] <Daemon404> http://pastie.org/10829616
[22:55:50 CEST] <Daemon404> it isnt obvious to me how to do that
[23:10:40 CEST] <Daemon404> hmmm...
[23:26:08 CEST] <Daemon404> think i got it
[23:40:06 CEST] <cone-142> ffmpeg 03Mark Thompson 07master:5d273d3efac3: avconv: VAAPI hwcontext initialisation and hwaccel helper
[23:40:07 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:172d3568b38c: Merge commit '5d273d3efac340ef8de445c955ff44c7abed4e8f'
[23:41:30 CEST] <cone-142> ffmpeg 03Mark Thompson 07master:104c804bcaac: lavc: VAAPI encode common infrastructure
[23:41:31 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:508957fd0fc3: Merge commit '104c804bcaac24b52eb51ed17df2fb311e6ae73e'
[23:44:06 CEST] <cone-142> ffmpeg 03Mark Thompson 07master:2c62fcdf5d61: lavc: VAAPI H.264 encoder
[23:44:07 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:b975aeec02e4: Merge commit '2c62fcdf5d617791a653d7957d449f75569eede0'
[23:45:56 CEST] <cone-142> ffmpeg 03Mark Thompson 07master:31fe1f2577f8: lavc: VAAPI H.265 encoder
[23:45:57 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:a82d1a8c7a4b: Merge commit '31fe1f2577f8208f79a4b3ab59465e78dd497555'
[23:47:06 CEST] <cone-142> ffmpeg 03Mark Thompson 07master:83f230c2445a: lavc: VAAPI MJPEG encoder
[23:47:07 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:939345854a9e: Merge commit '83f230c2445a94fdd94c66504482217fcece5909'
[23:51:46 CEST] <nevcairiel> Daemon404: btw a note about the upcoming matroskaenc patch, the field order element is not WebM compliant, so care needs to be taken to not write it then (the libav mkv muxer has no webm mode)
[23:51:47 CEST] <cone-142> ffmpeg 03Anton Khirnov 07master:69a638019fc0: avconv: fix -frames for video
[23:51:47 CEST] <cone-142> ffmpeg 03Diego Biurrun 07master:061dc20351bf: h264: Add missing ff_ prefix to internally visible h264_init_dequant_tables()
[23:51:48 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:3005ee372d47: Merge commit '69a638019fc0db4c2b75b36ef45d0acb6d2e9628'
[23:51:49 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:630586af882c: Merge commit '061dc20351bf3b8a237216d2b39d3a3b736d1916'
[23:51:59 CEST] <Daemon404> nevcairiel, isnt that just an if
[23:52:03 CEST] <Daemon404> if webmmode
[23:52:07 CEST] <nevcairiel> yes
[23:52:12 CEST] <nevcairiel> just saying it needs to be added :)
[23:52:15 CEST] <Daemon404> sure.
[23:54:04 CEST] <cone-142> ffmpeg 03Diego Biurrun 07master:bd016dbf23e8: Mark tables used only within their files as static
[23:54:04 CEST] <cone-142> ffmpeg 03Diego Biurrun 07master:44f05f15d4a3: build: Do not check the vaapi_encode.h header if VAAPI is not enabled
[23:54:06 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:4c3732c88173: Merge commit 'bd016dbf23e8e7dc34ff2696912575f7620cec0d'
[23:54:06 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:f93c409c0b71: Merge commit '44f05f15d4a34ef2f0d62259e5d5b43371bc0954'
[23:56:38 CEST] <Daemon404> nevcairiel, am i reading this write or is this just a reading patch
[23:56:43 CEST] <Daemon404> no writing
[23:57:05 CEST] <nevcairiel> oh the writing one is a few later
[23:57:35 CEST] <Daemon404> yeah
[23:57:42 CEST] <Daemon404> i suppose it shouldnt be read either though
[23:57:48 CEST] <Daemon404> btw i dont see how to check for webm
[23:57:54 CEST] <nevcairiel> the demuxer is no special
[23:57:59 CEST] <nevcairiel> it only reads elements actually in the file
[23:57:59 CEST] <Daemon404> ah...
[23:58:02 CEST] <nevcairiel> nothing to do there
[23:58:03 CEST] <Daemon404> ok
[23:58:13 CEST] <nevcairiel> its binary xml, remember :)
[23:59:00 CEST] <Daemon404> D: yes
[23:59:23 CEST] <cone-142> ffmpeg 03Luca Barbato 07master:5f0226668124: matroska: Support interlaced content correctly
[23:59:24 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:f3972b3b7dfa: Merge commit '5f0226668124aa7ae4db501ba7f4ace4c770f3d1'
[00:00:00 CEST] --- Mon May 9 2016
1
0
[02:34:33 CEST] <idlus> it works fine with 2 for width, I dont see what I am missing
[02:38:15 CEST] <furq> idlus: afaik it has to be an even number
[02:38:25 CEST] <furq> if you give it an odd number it'll subtract 1
[02:40:48 CEST] <furq> assuming either your input or output format are yuv420p
[02:47:30 CEST] <idlus> thank you for that precision
[02:48:09 CEST] <idlus> input and output are indeed yuv420p
[02:50:14 CEST] <furq> yeah if your output is 4:2:0 or 4:2:2 then it can't be a non-mod2 width
[02:51:51 CEST] <idlus> furq: if I wanted to output to png, would there be a way?
[02:57:56 CEST] <furq> yeah but you'd have to crop it to 2px width, then crop that to 1px width (don't ask me why)
[02:58:28 CEST] <furq> at least i did when i just tried it, there might be a way around that
[03:02:50 CEST] <idlus> hm if I understand it would be "crop 2:ih:0:0, crop 1:ih:0:0"?
[03:03:08 CEST] <idlus> it returns the same error for me
[03:04:55 CEST] <idlus> or I could use the format filter perhaps
[03:06:18 CEST] <furq> i meant two separate files
[03:06:25 CEST] <furq> or two separate commands, rather
[03:07:12 CEST] <idlus> no thats okay, "noformat=yuv420p, crop=1:ih:0:0" does the trick
[03:07:29 CEST] <idlus> thank you furq, goodbye :-)
[03:07:53 CEST] <butt> Hey guys. I have a 60gig folder full of apple lossless from when I used an ipod. It's all sorted into folders by artist and album. I have this "for f in *.m4a; do avconv -i "$f" "${f%.m4a}.flac"; done". Is there a way to go through each folder automatically rather than having to convert each folder manually?
[03:08:56 CEST] <idlus> butt you could use the find command instead
[03:13:42 CEST] <furq> butt: **/*.m4a
[03:14:05 CEST] <furq> you need bash 4 with globstar enabled (shopt -s globstar)
[03:14:09 CEST] <furq> think zsh does that too
[03:14:11 CEST] <furq> +i
[03:14:51 CEST] <furq> find works but then you can't use parameter expansion on the output filename
[03:19:50 CEST] <idlus> true, **/* is nice indeed
[03:19:57 CEST] <idlus> well, Im out
[03:24:00 CEST] <butt> "for f in **/*.m4a; do avconv -i "$f" "${f%.m4a}.flac"; done" did the trick thanks!
[07:22:16 CEST] <CoJaBo> Is there a way to pipe a series of .bmps into ffmpeg somehow? I'm not sure what to google for this..
[07:25:13 CEST] <furq> CoJaBo: if they're on disk then https://www.ffmpeg.org/ffmpeg-formats.html#Examples-1
[07:27:11 CEST] <CoJaBo> furq: I want to pipe them directly to ffmpeg tho; saving them all to disk would take nearly a TB of space
[07:28:43 CEST] <furq> in that case use something like -f rawvideo -pix_fmt rgb24 -i -
[07:28:46 CEST] <furq> with the appropriate pix_fmt
[07:29:30 CEST] <furq> oh you'll need -s 1024x768 before -i as well
[07:29:41 CEST] <CoJaBo> can that directly read .bmp tho?
[07:30:00 CEST] <furq> it will read bitmap data
[07:30:07 CEST] <furq> i'm not familiar with .bmp files
[07:30:28 CEST] <CoJaBo> I think I can chop off the header, but then I need to flip the image I think
[07:30:51 CEST] <CoJaBo> IIRC, they're encoded bottom-line-first for some weird reason
[07:31:18 CEST] <furq> i got a horrible flashback to dialup internet there
[07:31:31 CEST] <CoJaBo> lol
[07:31:56 CEST] <CoJaBo> If you encounter a BMP on the web, it is still like dialup :P
[07:32:46 CEST] <CoJaBo> There's a university in Japan where EVERY photo on the homepage is a 12+ megapixel bitmap; like 100MB each
[07:32:59 CEST] <furq> that sounds like japan
[07:33:04 CEST] <CoJaBo> They must have damn fast internet there >_>
[07:33:20 CEST] <furq> do they let you download an .lzh of the images
[07:33:49 CEST] Action: CoJaBo trying to figure out if ffmpeg can flip images..
[07:37:27 CEST] <furq> there's also -f image2pipe but it's not documented on the site
[07:37:30 CEST] <CoJaBo> Ah, hflip filter
[07:37:38 CEST] <furq> that might be better if you have headers and whatnot
[07:38:07 CEST] <CoJaBo> Yeh, there will be headers, and I'd like to avoid manually chopping them lol
[07:38:33 CEST] <CoJaBo> Can that handle bmp tho?
[07:39:05 CEST] <furq> no idea, i can't find any docs for it
[07:39:15 CEST] <furq> i imagine it works the same as image2 which can handle bmp
[07:40:08 CEST] <CoJaBo> Why aren't these things documented, gah
[07:40:27 CEST] <CoJaBo> But yeh, I'm finding example commandlines for image2pipe, looks like at least a few with .bmp files
[07:40:30 CEST] <furq> yeah even if it is identical to image2 it would be nice if it was at least namechecked in the docs
[07:40:42 CEST] <CoJaBo> Would've saved me a lot of time <_<
[07:41:26 CEST] <furq> it would also be nice if there was a list of topics for -h topic=name
[09:43:45 CEST] <wiistriker> hi guys
[09:44:12 CEST] <wiistriker> i have video stream from ip camera via rtmp and audio from local computer's soundcard
[09:44:27 CEST] <wiistriker> is there any way how can i sync video and audio streams?
[10:38:43 CEST] <Roest> morning, any idea why my encoding only encodes like 10 seconds then skips the rest http://pastebin.com/Nrpz75bX problem seems to be avcodec_encode_video2( c, &pkt, frame, &got_packet ); returns 0 in got_packet line 170
[16:29:07 CEST] <satinder___> Hi got following error while compiling ffmpeg for arm
[16:29:17 CEST] <satinder___> arm-linux-gnueabihf-gcc is unable to create an executable file. C compiler test failed.
[16:29:37 CEST] <satinder___> what I am doing wrong please any one help ??
[16:44:21 CEST] <zwu> i would like to play youtube video by 'ffplay'
[16:44:39 CEST] <zwu> but it reminds: http://www.youtube.com/watch?v=SJaMtBKnN-I: Protocol not found
[16:45:03 CEST] <JEEB> ffplay is not a real video player
[16:45:10 CEST] <JEEB> use mpv and youtube-dl integration instead
[16:45:31 CEST] <JEEB> (as in, have youtube-dl in PATH and call "mpv http://youtube..."
[16:45:57 CEST] <zwu> JEEB: https protocol not found, recompile FFmpeg with openssl, gnutls,
[16:46:00 CEST] <zwu> [ffmpeg] or securetransport enabled
[16:46:10 CEST] <JEEB> that's because it's trying to access it as normal https link
[16:46:14 CEST] <JEEB> which a goddamn youtube link is not
[16:46:20 CEST] <JEEB> so you have two problems
[16:46:47 CEST] <zwu> JEEB: i have mpv tried, but failed as above
[16:47:04 CEST] <JEEB> then download gnutls or openssl development packages
[16:47:13 CEST] <JEEB> and it should get enabled in mpv-build
[16:47:16 CEST] <JEEB> or whatever you used for mpv
[16:47:34 CEST] <JEEB> it just means that your FFmpeg that got used in mpv doesn't have https enabled in general
[16:47:50 CEST] <JEEB> which can be achieved by either openssl or gnutls
[16:47:58 CEST] <zwu> JEEB: is there any difference 'openssl' and 'gnutls' for 'ffmpeg'?
[16:48:22 CEST] <JEEB> you can distribute gnutls with GPL but openssl not
[16:48:27 CEST] <JEEB> for your own machine, no
[16:48:59 CEST] <zwu> JEEB: gnutls is for distribute pkgs, right?
[16:49:17 CEST] <JEEB> no I just meant that its license enables you to distribute it
[16:49:25 CEST] <JEEB> either one is just fine for usage
[16:49:42 CEST] <JEEB> it just doesn't matter a damn which you use if it's just for you as I noted
[16:51:10 CEST] <zwu> JEEB: ok, let me try gnutls. BTW, apart from youtube, does 'mpv + youtube-dl' support other sites?
[16:51:46 CEST] <JEEB> yes
[16:51:51 CEST] <JEEB> what youtube-dl supports
[16:54:02 CEST] <zwu> bingo~, it plays now :)
[16:54:06 CEST] <zwu> mpv is good
[17:06:25 CEST] <satinder___> JEEB : please give idea to do it ??
[17:13:32 CEST] <satinder___> there are any one ??
[19:52:58 CEST] <arbi> Any ideas?
[20:03:03 CEST] <inhahe> i have a webm file, which supposedly uses Vorbis for audio, so I did 'ffmpeg -i "Labor In Vain-azSRny7Fhkc.webm" -vn -c:a copy test.ogg' (on Windows) and the ogg file wouldn't play, so then I did 'ffmpeg -i "Labor In Vain-azSRny7Fhkc.webm" -vn test.ogg' and the resultant test.ogg works.. what's going on?
[20:03:59 CEST] <inhahe> and also, since i'm not doing a direct copy, is any quality retained by making my output .ogg instead of, say, m4a?
[20:04:37 CEST] <BtbN> if you don't specify a codec, it will use a default that works.
[20:04:43 CEST] <furq> are you sure it doesn't use opus audio
[20:25:20 CEST] <Cork> i'm trying to dump an rtmp stream and play the file as it is written, but i get "moov atom not found" until ffmpeg closes cleanly (and a corrupt file if it doesn't)
[20:25:37 CEST] <Cork> anyway to get ffmpeg to keep the file playable as it dumps it?
[20:28:06 CEST] <JEEB> are you just dumping it or also remuxing into mp4 from flv?
[20:28:31 CEST] <JEEB> because that error should only come with mov-like containers like ISOBMFF ("mp4")
[20:29:11 CEST] <Cork> ya
[20:29:26 CEST] <JEEB> for what exactly?
[20:29:29 CEST] <Cork> some of the places where i play it only support mp4
[20:29:38 CEST] <JEEB> ok, so you are remuxing as well?
[20:29:45 CEST] <BtbN> mp4 is not streamable, without the moov atom, which is written at the very end, the file is useless.
[20:29:48 CEST] <JEEB> then you can't do jack shit unless you start using movie fragments
[20:29:57 CEST] <Cork> -i rtmp:// -c copy stream.mp4
[20:30:12 CEST] <JEEB> ok, at least you can enable fragments with ffmpeg
[20:30:16 CEST] <JEEB> since that looks like it
[20:30:26 CEST] <BtbN> Use a stremable container if you want to play the file while it's being recorded.
[20:30:29 CEST] <JEEB> but not sure if all of those things you want to play it on will work then :P
[20:30:33 CEST] <JEEB> or just have multiple outputs
[20:30:37 CEST] <BtbN> As rtmp is basically flv, just use that.
[20:30:47 CEST] <JEEB> -i rtmp:// -c copy out.mp4 -c copy out.flv
[20:31:30 CEST] <Cork> hmm, ok so back to figuring out another solution then... :/
[20:31:35 CEST] <Cork> thx for the answers
[20:31:53 CEST] <JEEB> well see if whatever you want to play it with supports fragments if it has to be one file and mp4 only
[20:31:58 CEST] <JEEB> or see if mpeg-ts works
[20:32:14 CEST] <JEEB> or matroska if that goes
[20:32:36 CEST] <BtbN> basically anything except mp4, it's a horrible container.
[20:32:42 CEST] <JEEB> no it is not
[20:33:07 CEST] <JEEB> at this point it's actually one of the few that are actually properly spec'd, together with MPEG-TS
[20:33:12 CEST] <Cork> flv has worked well for me except for mobile devices
[20:33:27 CEST] <JEEB> and they've fixed most of the crappiest crap, except the lack of chapters
[20:33:30 CEST] <Cork> and well browsers
[20:33:57 CEST] <BtbN> They didn't fix the moov atom stuff. And cutting it in chunks is not what i'd call solving the issue with streaming it.
[20:34:46 CEST] <Cork> ya
[20:35:16 CEST] <JEEB> well it seems to work well enough looking at how the HTTP streaming crowd is going, although it definitely is not a most-optimized-for-streaming container
[20:35:24 CEST] <JEEB> MPEG-TS is pretty much that
[20:40:09 CEST] <Sander^home> How can I remove duplicate images and create a gif slideshow with sharp images... out of a bunch of still .jpg's from a webcam?
[20:40:31 CEST] <BtbN> sharp images?
[20:40:40 CEST] <BtbN> gif is only 256 colors, so don't expect too much.
[20:41:10 CEST] <Sander^home> Oh well. The most important part is detecting almost simular images.
[20:41:46 CEST] <BtbN> Why not just use a video instead? All the "gif collection websites" made that switch as well.
[20:42:09 CEST] <Sander^home> But I do want to take the less blurry image parts.. and combine them
[20:43:05 CEST] <Sander^home> BtbN: Becouse I do want to capture the invidual images aswell.
[20:43:21 CEST] <BtbN> Hm?
[20:43:58 CEST] <Sander^home> Maybe I only want to have one image left from a series.. the best one.
[20:44:14 CEST] <Sander^home> with face recognition.
[20:44:41 CEST] <Sander^home> But thats not a first time requirement.. if its not simple.
[20:46:56 CEST] <Sander^home> Maybe opencv can do it.
[20:47:45 CEST] <BtbN> You won't find any software that is going to tell you which image of a series is "best".
[20:59:16 CEST] <inhahe> furq: i think the docs said it uses Vorbis/opus. what's the file extension for opus?
[21:01:07 CEST] <IntelRNG> I am not into opus, but I suspect opus will be inside of a container which will have its own extension.
[21:05:38 CEST] <furq> inhahe: .opus, although it's an ogg container
[21:08:28 CEST] <furq> opus is relatively new so it could just be unsupported by your player
[21:10:04 CEST] <inhahe> yeah, that might be the case.. i named it .opus and the extension was associated with Spek which showed a frequency graph so i guess it's working in that
[21:11:49 CEST] <inhahe> (the one i got using c:a copy)
[21:12:25 CEST] <furq> if you downloaded this from youtube then you might want to get the audio in aac instead
[21:13:01 CEST] <furq> or vorbis but iirc that's generally lower bitrate since they adopted opus
[21:21:23 CEST] <sliter> Hello, everyone
[21:22:44 CEST] <sliter> May i use ffmpeg.exe on my releases github page?
[21:22:52 CEST] <sliter> Because i have GUI for it.
[21:23:27 CEST] <sliter> But im too lazy to read LGPL
[21:23:40 CEST] <ln-> have your lawyer read it for you.
[21:24:08 CEST] <furq> if you also distribute all the sources (including library sources) and aren't using any incompatibly licensed libraries then sure
[21:24:36 CEST] <sliter> so im need to add ffmpeg sources to my repository?
[21:24:47 CEST] <furq> not necessarily
[21:25:03 CEST] <furq> but you need to distribute them in some form in the same place the binaries are hosted
[21:25:26 CEST] <furq> the same versions used to build the binaries
[21:25:42 CEST] <furq> alternatively you could just link to the zeranoe builds
[21:25:52 CEST] <sliter> In desc of release?
[21:26:12 CEST] <furq> https://github.com/qruf/ffmpeg-10bit/releases
[21:26:14 CEST] <furq> that's how i do it
[21:26:25 CEST] <furq> also i should really update that
[21:26:49 CEST] <sliter> I think i got you.
[21:27:14 CEST] <furq> if you're not building with some specific set of libs then just link to the zeranoe builds and you don't have to worry about this
[21:27:57 CEST] <Sander^home> BtbN: what about almost simular detection?
[21:28:21 CEST] <Sander^home> if I can get a % of how simular two images is. eg.
[21:28:41 CEST] <furq> Sander^home: https://ffmpeg.org/ffmpeg-filters.html#decimate
[21:29:35 CEST] <Sander^home> furq: How can I apply this to two images?
[21:30:43 CEST] <furq> i don't think it's really of any use if you only have two images
[21:31:25 CEST] <Sander^home> furq: I do want to find out of those two images is simular or totally diffrent.
[21:33:37 CEST] <sliter> Also
[21:33:47 CEST] <sliter> What is difference between 64-bit and 32-bit of ffmpeg?
[21:42:09 CEST] <DHE> CPU version mostly. Use 64 bit if you have a 64 bit OS
[21:42:23 CEST] <DHE> 32 bit should be avoided unless you're on a 32 bit CPU and/or OS
[22:42:26 CEST] <matthew__> Im using ffmpeg 3.0.2 on mpg files that are about an hour long. Im trying to do exact cuts of the video with things like: ffmpeg -ss $start -i $video -vcodec copy -acodec copy -to $end ${file}.$type what Im finding diffacult is I can use any number of applications to get $start and $end values however when I use them in ffmpeg I often have to adjust things signifcantly to find acceptable values. I tried using something like: ffmpeg -ss $st
[22:42:26 CEST] <matthew__> -i $video -filter_complex "drawtext=fontfile=/usr/share/fonts/dejavu/DejaVuSans-Bold.ttf:fontsize=72:text=%{n} %{pts}:x=(w-text_w)/2:y=350:box=1:boxcolor=white,select='isnan(prev_selected_n)+gte(n-prev_selected_n\,1)',yadif,scale=150:-1,tile=5x5" -vframes 1 -f image2 -vcodec png pipe:1 to try and find ffmpeg exact values for start ad end, the above picture will show pictures around the exact point I want to cut with relative frame and pts values from
[22:42:28 CEST] <matthew__> $start, but this also does not produce values that work without adjusting although it could be Im not properly translating the output of the above image to values for the first command but so far Im not finding a pattern for any consistant translation.
[00:00:00 CEST] --- Mon May 9 2016
1
0
[05:12:30 CEST] <cone-267> ffmpeg 03Michael Niedermayer 07master:cbe265ccd714: avcodec/m101: Simplify if() condition
[05:12:30 CEST] <cone-267> ffmpeg 03Michael Niedermayer 07master:22d1148c77c6: avcodec/m101: remove unneeded zeroing of priv_data_size
[05:12:30 CEST] <cone-267> ffmpeg 03Michael Niedermayer 07master:fc6894770ea9: avcodec/m101: simplify 8bit code
[05:12:30 CEST] <cone-267> ffmpeg 03Piotr Bandurski 07master:e601e078e94f: avformat/riff: add M102 FourCC
[09:50:24 CEST] <Easyfab> delogo with x=0 or y=0 crash ffmpeg for me, can someone reproduce ?
[10:14:45 CEST] <durandal_170> what version?
[10:18:13 CEST] <Easyfab> http://pastebin.com/vK45biQs
[12:27:23 CEST] <nevcairiel> Daemon404: all the extra commits i send to the ML have been approved by michael, so if you want feel free to merge my branch (its even rebased on top of current master right now)
[12:37:32 CEST] <Compn> fatal: remote error: access denied or repository not exported: /ffmpeg.git
[12:37:44 CEST] <Compn> hmmm
[12:37:51 CEST] <Compn> screwed up my repo again
[12:41:07 CEST] <Compn> and the git instructions are not on the developer documentation page :P
[12:45:57 CEST] <Compn> $ git remote -v
[12:45:57 CEST] <Compn> origin git://source.ffmpeg.org/ffmpeg.git (fetch)
[12:45:57 CEST] <Compn> origin git://source.ffmpeg.org/ffmpeg.git (push)
[12:50:12 CEST] <wm4> went to the website, did 1 click, saw git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg
[12:52:03 CEST] <Compn> yeah i remember it changed :P
[12:52:09 CEST] <Compn> but thats about it
[12:53:07 CEST] <Compn> wm4 : also , i'm finding this page needs to be updated. https://ffmpeg.org/git-howto.html#Cloning-the-source-tree
[12:53:26 CEST] <Compn> but i guess thats my job
[12:54:16 CEST] <wm4> source still works, I'm using it
[12:58:06 CEST] <cone-422> ffmpeg 03compn 07master:1e109bbbf133: riff: add comment for g721,g723 codec tags
[13:00:04 CEST] <Compn> ah missed "avformat"
[13:00:21 CEST] <Compn> 1l coffee
[13:02:36 CEST] <Compn> wm4 : michaelni has provided proper git push url.
[13:07:40 CEST] <michaelni> Daemon404, nevcairiel the branch seems to break: http://samples.ffmpeg.org/V-codecs/smv2/ref_10.avi
[13:08:13 CEST] <michaelni> [h264 @ 0x7f5fc40034a0] No start code is found. ...[h264 @ 0x7f5fc40034a0] Error splitting the input into NAL units.
[13:08:25 CEST] <michaelni> with ./ffplay ~/videos/sm2v/ref_10.avi
[13:08:45 CEST] <JEEB> hmm, also nal unit related stuff reminds me of the fix required for the avc bsf
[13:09:01 CEST] <JEEB> I don't think the guy posted a new version after TEP2
[13:09:30 CEST] <JEEB> https://github.com/VFR-maniac/ffmpeg/commit/172fe56b1a4a063ff2feb14d3394129…
[13:17:29 CEST] <nevcairiel> michaelni: it looks like it fails extradata parsing (both before and after), except that this is now considered a fatal error, and i'm not sure at which point it should ignore th error for extradata
[13:19:26 CEST] <nevcairiel> perhaps ff_h264_decode_extradata should not check the return value of decode_nal_units
[13:21:10 CEST] <nevcairiel> previously it would just silently skip everything if no NALs could be extracted
[13:23:05 CEST] <nevcairiel> (removing the error condition makes the file works as expected, as only the extradata is broken)
[13:23:33 CEST] <nevcairiel> so, suggestions?
[13:30:30 CEST] <nevcairiel> michaelni: https://github.com/Nevcairiel/FFmpeg/commit/5f942f43d94e2be1e2653aa311f6e3f… like this maybe
[13:33:43 CEST] <michaelni> nevcairiel, is it intended that this produces error messages where there where none before ?
[13:34:01 CEST] <nevcairiel> probably
[13:34:04 CEST] <nevcairiel> it is technically invalid data
[13:34:47 CEST] <nevcairiel> the old h264 code just silently discarded any garbage data it found
[13:36:04 CEST] <nevcairiel> the new h264/5 code errors out when a buffer is garbage-only, ie. not one valid NAL
[13:36:53 CEST] <nevcairiel> the only difference is error handling here, not actual parsing changes from what i can tell
[13:37:19 CEST] <michaelni> the codec tag says SMV2, so iam not sure that is "garbage" for SMV2
[13:37:33 CEST] <michaelni> i dont know if that is intended to be actual spec compliant h264
[13:37:44 CEST] <nevcairiel> well its garbage for the h264 decoder either way
[13:37:45 CEST] <nevcairiel> :)
[13:37:52 CEST] <michaelni> yes
[13:38:21 CEST] <michaelni> no objections but id like to do something about the errors at some point
[13:39:15 CEST] <michaelni> we also donz display errors for msmpeg4 not being mpeg4 syntax
[13:39:40 CEST] <michaelni> but i dont know what SMV2 is maybe its intended to be h264 exactly
[13:40:28 CEST] <nevcairiel> i think its generally a good idea to check the nal parsing a bit more thoroughly then before, but adding cases where the checks are silent would require adding parameters to all the involved functions
[13:41:55 CEST] <nevcairiel> anyway i'm going out into the sun for a bit, be back later
[13:42:12 CEST] <michaelni> sure, have fun!, ... if AVCodecContext is passed, AVCodecContext->codec_tag could be used for such checks maybe
[14:06:33 CEST] <Daemon404> ill meege tomight
[14:06:38 CEST] <Daemon404> im also out in the sun
[14:06:50 CEST] <Daemon404> in fact sitting in a park with a beer.
[14:07:16 CEST] <Daemon404> (i realie this sounds idd to americans)
[14:08:21 CEST] <wm4> Daemon404: how so
[14:09:03 CEST] <Daemon404> it is illegal to drink outside in .ca and .us
[14:09:19 CEST] <Daemon404> in public anyway
[14:09:24 CEST] <wm4> even beer?
[14:09:30 CEST] <Daemon404> yes
[14:09:37 CEST] <Daemon404> drink as in alcohol
[14:09:53 CEST] <Daemon404> im half way in between
[14:09:57 CEST] <Daemon404> i kike a beer in the sun
[14:10:09 CEST] <Daemon404> but i also see how ridiculous brits get outside with beer
[14:10:13 CEST] <Daemon404> so..
[14:10:17 CEST] <Daemon404> :V
[14:12:14 CEST] <JEEB> cold beer in the sun <3
[14:13:16 CEST] <Daemon404> there is sun in finland?
[14:13:16 CEST] <Compn> Daemon404 : is your beer in brown paper bag?
[14:13:25 CEST] <Daemon404> no lol
[14:13:27 CEST] <Compn> thats how many people drink, with paper covering the beer bottle/can
[14:13:29 CEST] <Compn> in usa
[14:13:33 CEST] <Daemon404> im not a hobo
[14:13:47 CEST] <Compn> well then park ranger will probably give you a few tickets :P
[14:16:42 CEST] <JEEB> Daemon404: towards summer we're having lots of sun but not necessarily heat
[14:16:54 CEST] <JEEB> heat being at around +20 here right now is kind of exceptional
[14:17:39 CEST] <Daemon404> 20 here too
[14:17:43 CEST] <Daemon404> its perfect weather
[14:17:49 CEST] <Daemon404> too bad summer will be 30
[14:17:49 CEST] <JEEB> yeah
[14:19:06 CEST] <Compn> get out and play some disc golf :)
[14:32:21 CEST] <Daemon404> disc golf? is that anything like ultimate frisbee?
[14:32:34 CEST] <Daemon404> well i guess it cant be
[14:33:05 CEST] <JEEB> there's usually a basketball bag kind of thing somewhere and then you have a starting point
[14:33:20 CEST] <JEEB> we did it at my previous job at a random all-office meet-out
[14:33:32 CEST] <JEEB> and you have a "par" etc
[14:33:48 CEST] <JEEB> (how many throws until bag is the number)
[14:35:56 CEST] <Shiz> can't wait for summer
[14:36:07 CEST] <wm4> can't wait for winter
[14:38:32 CEST] <Daemon404> ^
[14:46:37 CEST] <michaelni> Daemon404, nevcairiel if you merge take teh 2 commits or equivalent/better fixes from HEAD of https://github.com/michaelni/FFmpeg/commits/h264merge
[14:47:41 CEST] <nevcairiel> maybe the parser should be changed to skip zero sized NALs
[14:47:48 CEST] <nevcairiel> makes no sense to have them
[14:48:03 CEST] <nevcairiel> even the content-less NALs should be one byte in size for the nal type etc
[14:48:16 CEST] <michaelni> sounds reasonable
[15:51:21 CEST] <Daemon404> michaelni / nevcairiel - so am i clear to merge, or should i wait for this 0-sized thing
[16:30:16 CEST] <nevcairiel> Daemon404: i just pushed https://github.com/Nevcairiel/FFmpeg/commit/336b453aa270c03bf2972ec6e603e66… which should do that
[16:31:41 CEST] <nevcairiel> NALs should generally always be 1 byte for h264 or 2 for hevc, as thats the size of the NAL header
[16:31:44 CEST] <nevcairiel> so zero is just invalid
[16:36:28 CEST] <Daemon404> nevcairiel, all right
[16:36:31 CEST] <Daemon404> ill get to pushing soon
[16:36:34 CEST] <Daemon404> working on hobby project atm
[16:36:42 CEST] <Daemon404> you can push if you want
[17:39:49 CEST] <nevcairiel> BtbN: could you post your configuration details to the ML when you get the internal compiler error with O3? in the "configure: enable GCC vectorization" thread? some people are interested :)
[17:43:00 CEST] <BtbN> nevcairiel, I didn't do anything special. Just --enable-libx264 --enable-gpl, on Docker alpine:3.3
[17:43:07 CEST] <BtbN> Which is using gcc 5.3.0
[17:50:10 CEST] <jamrial> can you still reproduce it?
[17:50:45 CEST] <cone-749> ffmpeg 03Marton Balint 07master:215a2d76788f: ffplay: force setting alsa buffer size
[17:50:45 CEST] <cone-749> ffmpeg 03Jan Sebechlebsky 07master:a3c877aca78f: avformat/tee: Fix TeeSlave.bsfs pointer array size
[17:50:45 CEST] <cone-749> ffmpeg 03Jan Sebechlebsky 07master:1bc83f6ea8ff: avformat/tee: Use ref instead copy in write_packet
[17:53:15 CEST] <BtbN> jamrial, i switched the container to Debian to avoid it, but I'm quite sure it would still happen, even with a plain configure without any arguments.
[17:55:07 CEST] <BtbN> yeah, still happens
[17:55:19 CEST] <jamrial_> on debian?
[17:55:23 CEST] <BtbN> alpine
[17:55:27 CEST] <BtbN> Debian has 4.9, that's fine.
[17:55:43 CEST] <jamrial_> i can't reproduce it on archlinux, and neither does any of the many fate clients
[17:55:56 CEST] <BtbN> I'll push the broken docker image somewhere
[17:56:16 CEST] <jamrial_> can you add -freport-bug to the gcc command line options?
[17:56:31 CEST] <jamrial_> it will generate a pre-processed output in /tmp
[17:56:56 CEST] <BtbN> so just ./configure --extra-cflags=-freport-bug ?
[17:57:44 CEST] <jamrial_> that, or use make V=1 to get the command and add that option to run gcc manually
[17:57:51 CEST] <jamrial_> so you don't have to reconfigure
[17:58:00 CEST] <nevcairiel> he is on linux, reconfigure takes like 5 seconds
[17:58:08 CEST] <BtbN> It's a docker container, it's rebuilt entirely every time
[17:58:08 CEST] <BtbN> ls
[17:58:16 CEST] <jamrial_> ok
[18:06:00 CEST] <BtbN> jamrial_, pushed the affected image, if you want to test around in it: docker run -ti btbn/ffmpeg_compiler_panic /bin/bash
[18:07:13 CEST] <jamrial_> where? i'm not familiar with docker
[18:07:46 CEST] <BtbN> If you have Docker installed, just run that command and it gives you a shell, with the ffmpeg source tree in /root/ffmpeg/
[18:08:25 CEST] <BtbN> I'm trying to upload the log it generates in tmp, but getting it out of the container is surprisingly annoying
[18:11:07 CEST] <BtbN> jamrial_, https://btbn.de/files/crashlog.out
[18:11:11 CEST] <BtbN> nevcairiel, ^
[18:14:19 CEST] <jamrial_> BtbN: can't reproduce the crash with that output either. it compiles it just fine
[18:14:44 CEST] <BtbN> So probably something alpine did to their gcc?
[18:15:48 CEST] <jamrial_> could be
[18:16:33 CEST] <BtbN> https://bugs.alpinelinux.org/issues/5334 they don't seem to care too much
[18:17:00 CEST] <nevcairiel> their certificate also expired, are they still alive? =P
[18:18:06 CEST] <wm4> last release 2 months ago
[18:20:08 CEST] <JEEB> lol
[18:21:33 CEST] <nevcairiel> i dont even know what half of their gcc build options do, and they are not mentioned in the gnu docs
[18:21:57 CEST] <nevcairiel> are they one of those ricer distros with 100 patches on top of everything?
[18:23:07 CEST] <BtbN> the entire goal of that distro is to be as small as possible.
[18:23:15 CEST] <jamrial_> save for --disable-fixed-point the rest i think are also used by arch's gcc package
[18:23:45 CEST] <nevcairiel> they do use musl, which gcc only claims to officially support as a target since 6.1
[18:23:51 CEST] <nevcairiel> at least according to the changelog
[18:24:38 CEST] <jamrial_> then i wont bother submitting a bug report. can't even reproduce it and they will just tell me it's not supported anyway
[18:25:53 CEST] <nevcairiel> unfortunately that seems to be the general response from many projects, they just don't care
[20:23:54 CEST] <DSM_> durandal_170: hi
[20:24:20 CEST] <DSM_> durandal_170: https://github.com/dsmudhar/FFmpeg/commit/45112cdb8ea812ab2264d65c5c7b3ea52…
[20:24:21 CEST] <durandal_170> hi
[20:24:28 CEST] <DSM_> seems good?
[20:25:07 CEST] <DSM_> i categorized the MV types and frame types.
[20:26:30 CEST] <durandal_170> where are I frames?
[20:27:07 CEST] <DSM_> adding :P
[20:27:14 CEST] <DSM_> example: -vf codecview=mv=fp+bp:frames=pf+bf
[20:30:05 CEST] <DSM_> i-frame can have both direction vectors?
[20:30:13 CEST] <DSM_> durandal_170: ping
[20:51:34 CEST] <durandal_170> DSM_: yes
[20:51:48 CEST] <DSM_> ok
[21:05:09 CEST] <DSM_> durandal_170: https://github.com/dsmudhar/FFmpeg/commit/b5c83eeee6af345a6dc2f44c7db5cb9c2…
[21:05:19 CEST] <DSM_> added i-frame option
[21:07:04 CEST] <durandal_170> send to ml
[21:09:14 CEST] <DSM_> sending
[21:56:17 CEST] <jamrial_> oh nice, archlinux updated to gcc 6.1
[22:02:22 CEST] <fritsch> so see you in 3 days? after recompling the whole system 3 times?
[22:08:03 CEST] <Daemon404> fritsch, arch is binary packages
[22:15:19 CEST] <Daemon404> nevcairiel, do i still need to add michael's commits, or do your latest ones fix that
[22:15:56 CEST] <Daemon404> ah yeah, no i dotn need them
[22:22:54 CEST] <cone-749> ffmpeg 03Anton Khirnov 07master:ca2f19b9cc37: h264: switch to h2645_parse for NAL parsing
[22:22:55 CEST] <cone-749> ffmpeg 03Hendrik Leppkes 07master:6eb1b40ad869: hevc: fix size condition in ptl parsing
[22:22:56 CEST] <cone-749> ffmpeg 03Hendrik Leppkes 07master:c80238939309: h2645_parse: initialize the GetBitContext to the proper size
[22:22:57 CEST] <cone-749> ffmpeg 03Hendrik Leppkes 07master:9cc1ab63ac0f: h2645_parse: allow partial escaping
[22:22:58 CEST] <cone-749> ffmpeg 03Hendrik Leppkes 07master:772ad7142dff: Merge commit 'ca2f19b9cc37be509d85f05c8f902860475905f8'
[22:22:59 CEST] <cone-749> ffmpeg 03Hendrik Leppkes 07master:d6f92103e0f6: h264: do not return an error when NAL parsing of extradata failed
[22:23:00 CEST] <cone-749> ffmpeg 03Hendrik Leppkes 07master:d46e85635070: h265_parse: skip zero sized NAL units
[22:47:46 CEST] <omerjerk> hi everyone.
[22:48:00 CEST] <omerjerk> I need to analyze the file created by my decoder.
[22:48:16 CEST] <omerjerk> by file, I mean the wav file.
[22:48:49 CEST] <omerjerk> By analyzing, I mean to find out what's the sampling format etc.
[22:49:05 CEST] <omerjerk> Any tips for a tool to do this ?
[22:51:03 CEST] <cone-749> ffmpeg 03Vittorio Giovara 07master:9f4d99138df4: fate: Add test for WMV2 with jframes
[22:51:05 CEST] <cone-749> ffmpeg 03Vittorio Giovara 07master:d0540fd02171: intrax8: Pass macroblock size to ff_intrax8_common_init
[22:51:05 CEST] <cone-749> ffmpeg 03Vittorio Giovara 07master:b1268e0f032a: intrax8: Pass macroblock coordinates to ff_intrax8_decode_picture
[22:51:06 CEST] <cone-749> ffmpeg 03Vittorio Giovara 07master:c2084ffcbfc1: intrax8: Use the generic horizband function
[22:51:07 CEST] <cone-749> ffmpeg 03Vittorio Giovara 07master:9fa888c02801: intrax8: Keep a reference to the decoder blocks
[22:51:08 CEST] <cone-749> ffmpeg 03Vittorio Giovara 07master:9b57995cdd48: intrax8: Drop MB emulation code
[22:51:09 CEST] <cone-749> ffmpeg 03Diego Biurrun 07master:6ebd06a9b250: intrax8: Drop lots of pointless parentheses
[22:51:10 CEST] <cone-749> ffmpeg 03Vittorio Giovara 07master:ca8c7591735c: intrax8: Remove mpegvideo dependency
[22:51:11 CEST] <cone-749> ffmpeg 03Derek Buitenhuis 07master:eee5a7cd7d15: Merge commit '9f4d99138df434a73b097c997fb4cafc65f4ff54'
[22:51:12 CEST] <cone-749> ffmpeg 03Derek Buitenhuis 07master:578fb5a27d45: Merge commit 'd0540fd02171a6233d2016b199d013299debf7e3'
[22:51:13 CEST] <cone-749> ffmpeg 03Derek Buitenhuis 07master:123fef54cc8f: Merge commit 'b1268e0f032a3af3912fe3fb8d3855e12d7ea83b'
[22:51:14 CEST] <cone-749> ffmpeg 03Derek Buitenhuis 07master:c59c7924707e: Merge commit 'c2084ffcbfc11d1b6ed3a4a0df9cafd56fbb896f'
[22:51:15 CEST] <cone-749> ffmpeg 03Derek Buitenhuis 07master:f110c624b1f3: Merge commit '9fa888c02801fff2e8817c24068f5296bbe60000'
[22:51:16 CEST] <cone-749> ffmpeg 03Derek Buitenhuis 07master:741960e2f330: Merge commit '9b57995cdd489a4cff51dcc1a1f08ac77ec5a58c'
[22:51:17 CEST] <cone-749> ffmpeg 03Derek Buitenhuis 07master:f2c78128395e: Merge commit '6ebd06a9b2508747a135ee4c880d8f612e08932b'
[22:51:18 CEST] <cone-749> ffmpeg 03Derek Buitenhuis 07master:e811ebcd9cd5: Merge commit 'ca8c7591735c0f80cc29e31e2e92cb10228e14c7'
[22:51:20 CEST] <Daemon404> omerjerk, ffprobe?
[23:04:40 CEST] <omerjerk> I haven't used ffmpeg a lot. I'll try this.
[23:04:59 CEST] <omerjerk> thanks.
[23:13:33 CEST] <Daemon404> btw what a nice fate sample th intrax8 is...
[23:13:39 CEST] <Daemon404> its a flavoured condom commercial.
[23:18:11 CEST] <durandal_170> omerjerk: what's issue with float support in als?
[23:19:56 CEST] <omerjerk> I used a random wav analyzer software (found on Google), ran it on the output .wav file, and it shows the sampling format as 16-bit int, though it should be 32-bit float.
[23:20:19 CEST] <omerjerk> I'm properly setting the output format to float already.
[23:20:35 CEST] <omerjerk> I'll try with ffprobe once.
[23:20:58 CEST] <durandal_170> omerjerk: but you transcode
[23:21:20 CEST] <durandal_170> use -c:a pcm_f32le
[23:21:52 CEST] <omerjerk> ^^ what's this exactly ?
[23:23:10 CEST] <omerjerk> P.S. I'm setting the output format here - https://github.com/omerjerk/FFmpeg/blob/float/libavcodec/alsdec.c#L2143
[23:26:31 CEST] <durandal_170> omerjerk: output codec for wav
[23:31:12 CEST] <cone-749> ffmpeg 03Christophe Gisquet 07master:9630b3fc06d8: x86: lossless audio: SSE4 madd 32bits
[23:54:53 CEST] <kierank> atomnuker: interesting patch
[23:59:11 CEST] <jamrial> kierank: do you have time to fuzz the dca express decoder in the ml?
[23:59:35 CEST] <kierank> Yes I could
[00:00:00 CEST] --- Sun May 8 2016
1
0
[00:01:40 CEST] <vade_> strategy question - im currently running libswresample to resample some audio and libswscale to re-size and convert pixel formats. I also need to run an audio normalization filter - convert some command line args into libavfilter invokations. Does libavfilter sort of encapsulate libswscale / libswresample - and can I build my current libswresample and libswscale code via filter graph invocations?
[00:03:44 CEST] <Prelude2004c> any light here.. check this out http://pastebin.com/raw/nHV4eYfK.. blowing me away... what does this have to do with FFMPEG ?
[00:29:46 CEST] <pfelt> anyone around that's used ffmpeg to capture from a decklink sdi card? i'm not seeming to be able to get anything out of the card unless i use bmdcapture
[00:57:10 CEST] <rsully> relaxed you around?
[01:01:12 CEST] <rsully> relaxed wondering if your build script for your static binaries is public or not, I'm having trouble building gnutls dependency
[01:10:14 CEST] <rsully> speaking of which, any one have input on openssl vs gnutls?
[01:10:19 CEST] <rsully> ignoring licensing differences
[01:14:59 CEST] <iive> i've heard a lot of developers complain that gnutls has major bugs, stuff related to accepting or rejecting certificates... but that's kind of old info.
[01:15:29 CEST] <iive> openssl seems to be used by everybody and everything, yeh, here and there it hits the news with some major exploit.
[01:15:52 CEST] <iive> probably because it tries to implement the whole mess of standard...
[01:35:10 CEST] <DHE> libressl forked openssl trying to gut it of all those unnecessary, old or maybe risky features
[02:04:13 CEST] <rsully> DHE yeah but does ffmpeg support libre?
[02:21:27 CEST] <rsully> relaxed how do you build with gnutls statically? p11-kit can't be built as a static library
[02:22:23 CEST] <furq> --without-p11-kit
[02:23:08 CEST] <furq> https://github.com/qruf/ffmpeg-mingw/blob/master/src/gnutls/rules.mak
[02:23:12 CEST] <furq> those are the options i use fwiw
[02:23:20 CEST] <furq> (with apologies to vlc)
[02:27:39 CEST] <rsully> any reason for disabling a bunch of the other stuff?
[02:27:46 CEST] <rsully> e.g. nls
[02:27:58 CEST] <furq> that's pretty much just ripped from the vlc contrib makefile
[02:28:09 CEST] <furq> you'd have to ask them
[02:30:26 CEST] <rsully> some of those flags look out of date
[02:30:30 CEST] <rsully> at least for 3.4
[02:30:36 CEST] <rsully> but i should be able to adjust
[02:31:09 CEST] <furq> iirc 3.4 wouldn't build with those flags
[02:31:14 CEST] <furq> which is why i'm using 3.3
[02:31:30 CEST] <rsully> I'm just using --enable-static --disable-shared --without-p11-kit --disable-doc
[02:31:42 CEST] <rsully> compiling now
[02:31:54 CEST] <furq> you might as well disable guile and openpgp, i don't t hink those are of any use for ffmpeg
[02:31:57 CEST] <furq> not sure about the others
[02:32:25 CEST] <rsully> just trying to use as few flags as necessary to give me what i want
[02:32:42 CEST] <furq> and gtk-doc/doc/tests are wasted time if you're not going to use them
[02:32:51 CEST] <rsully> disabled by default, for 3.4 at least
[02:33:57 CEST] <rsully> well, gtk docs
[02:34:02 CEST] <rsully> tests are enabled, but whatever
[02:38:45 CEST] <rsully> furq woo it works
[02:39:09 CEST] <rsully> only 3 days of trying, but i have a usable static ffmpeg binary
[02:39:24 CEST] <rsully> gnutls, not openssl though :(
[03:30:09 CEST] <Prelude2004c> hey guys.. good day
[03:30:19 CEST] <Prelude2004c> sorry to be a bother.. can someone look at this and tell me if i need to chagne anything
[03:30:20 CEST] <Prelude2004c> http://pastebin.com/raw/wT41HQMk
[03:31:32 CEST] <Prelude2004c> basically.. i want the input to loop through the concat files.. and when it reaches the end shuffle again and keep going .. while the second phase output will just sit listen to the input and keep segmenting forever... so first one is the action script pushing data to fifo and the second is the listener which takes the data and transcodes&segments it.
[04:58:07 CEST] <Prelude2004c> hey, anyone know how to get around these errors ?
[04:58:08 CEST] <Prelude2004c> Non-monotonous DTS in output stream 0:0; previous: 97745983, current: 3826584; changing to 97745984. This may result in incorrect timestamps in the output file.
[06:16:46 CEST] <JamJams> When using AVPacket ->data on an ac3 frame there appears to be 14 bytes to garbage in each frame. I recently updated my libavcodec version from one I was using from Dec of 2015.
[06:16:49 CEST] <JamJams> Has something changed here?
[06:26:07 CEST] <JamJams> It's a bug every 5th frame is incorrectly allocated
[10:53:59 CEST] <langtutheky> has anybody successfully use -hls_playlist_type, I received this error Unrecognized option 'hls_playlist_type'
[11:51:07 CEST] <Videogamer555> How do I convert a frame-based video into fields? I would like to output the raw fields for editing (in external software), from a video file that is interlaced. The video is 640x480 for a single frame, so a single field should have the dimentions 640x240, when the lines of that field are shown consecutively. Is there a way to extract individual fields (not frames), from a video file, using FFMPEG?
[11:51:47 CEST] <Mavrik> hrmf
[11:51:56 CEST] <Mavrik> Videogamer555, what format would you want them in?
[11:52:23 CEST] <Videogamer555> I'd like to output them all into a single file, via -f:v rawvideo
[11:52:45 CEST] <Mavrik> hrmf.
[11:52:54 CEST] <Mavrik> look at video filters
[11:53:01 CEST] <Videogamer555> That command should output all the frames of a file into raw video usually, but I'd like a way to cause it to output FIELDS instead of frames.
[11:53:46 CEST] <Videogamer555> Is there any filter that could accomplish this that comes default with FFMPEG? Or does one not exist yet?
[11:54:15 CEST] <Mavrik> I'm 80% sure there's a filter that splits frames into individual fields, check the filter list on ffmpeg homepage
[12:05:58 CEST] <Videogamer555> So what would that filter be called?
[12:06:01 CEST] <Videogamer555> Anybody know?
[12:08:19 CEST] <JamJams> https://ffmpeg.org/ffmpeg-filters.html#separatefields
[12:32:16 CEST] <Videogamer555> Anybody here?
[12:38:20 CEST] <Videogamer555> It appears that there are 2 missing filters on my copy of FFMPEG. Just trying out some filters and it seems that vectorscope and waveform (for a waveform monitor) are missing.
[12:43:34 CEST] <JamJams> Compile it with them then?
[12:55:08 CEST] <Videogamer555> I don't have the ability to compile it. I'm running Windows.
[15:05:03 CEST] <Dariush> Hi. I have a video file that plays correctly in VLC and is correctly recognized by MediaInfo (https://i.imgur.com/3AZ5IIb.png) but ffmpeg thinks it only consist of audio: http://pastebin.com/RD6TR2s1
[15:05:57 CEST] <Dariush> When I try to copy it with ffmpeg, the resulting file has no video. How can I make it recognize the video stream?
[15:07:16 CEST] <JEEB> first of all, is it really FLV or is it ISOBMFF (colloqually known as "mp4")? although since the probe finds FLV I guess that's correct (also because it got dumped out of rtmpdump)
[15:07:19 CEST] <Dariush> this is the output of a copy attempt: http://pastebin.com/CXzesFn3
[15:07:38 CEST] <JEEB> the video track might not be there in the beginning so try adding analyzeduration
[15:07:54 CEST] <JEEB> the audio also came after the header [flv @ 000000000047a760] audio stream discovered after head already parsed
[15:10:05 CEST] <Dariush> Hm, I'm not seeing this option in the documentation and googling only returns user discussions. Which value should I start off with?
[15:10:10 CEST] <JEEB> set it to 10000000 for double (default is 5000000)
[15:10:18 CEST] <JEEB> uhh, it is in the docs
[15:10:22 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html
[15:10:29 CEST] <JEEB> ctrl+F analyzeduration
[15:10:49 CEST] <JEEB> probesize is another related variable but might not be required
[15:11:26 CEST] <Dariush> oh, you are right. I was looking at https://ffmpeg.org/ffmpeg.html
[15:12:59 CEST] <Dariush> wow, it helped, and the video even opened in MPC-HC, where it didn't work previously. thanks a lot :)
[15:14:40 CEST] <JEEB> mpc-hc uses LAV Filters => LAV Filters uses FFmpeg to demux => uses same probing logic
[15:14:53 CEST] <JEEB> although there should be a callback for new streams
[15:14:58 CEST] <Dariush> by the way, what does latency in the documentation for this option mean?
[15:15:03 CEST] <JEEB> not sure what LAV does with that, if anything
[15:15:21 CEST] <JEEB> Dariush: well you're reading stuff from input for 10 seconds worth of stuff
[15:15:26 CEST] <JEEB> so if you're doing live streaming
[15:15:29 CEST] <JEEB> that's quite a bit :P
[15:16:00 CEST] <Dariush> so I'm working with static files, there's no reason not to set it to 10000000?
[15:16:03 CEST] <Dariush> if*
[15:16:21 CEST] <JEEB> yeh
[15:18:39 CEST] <Dariush> all right, thanks again :)
[15:19:54 CEST] <JEEB> ugh, kind of wanted him to check if he got the report_new_stream thing to appear :)
[15:21:09 CEST] <JEEB> since ffmpeg.c does log that (oh, even as a warning so default logging level should get it)
[15:58:02 CEST] <Dariush> JEEB: can I somehow fix the videofiles to make them get recognized correctly without the analyzeduration option? I can copy them, but that would take a huge amount of time, so I'd like something faster.
[16:19:22 CEST] <JEEB> Dariush: not without manually adding the track header, unfortunately. they just happen to pop up after the default analyze duration has gone past. BTW, when you copy stuff without analyzeduration, do you get this log message? https://github.com/FFmpeg/FFmpeg/blob/master/ffmpeg.c#L2765
[16:20:56 CEST] <JEEB> that should happen in case a new stream gets found during runtime
[16:21:26 CEST] <JEEB> (unfortunately ffmpeg.c also purely ignores that track since it doesn't support dynamic addition)
[16:21:52 CEST] <Dariush> yep, but it looks rather strange: New (null) stream 0:1 at pos:245398 and DTS:9.947s
[16:22:06 CEST] <JEEB> lol
[16:22:31 CEST] <JEEB> probably because FLV in such case can't have any predefined info on the track
[16:22:39 CEST] <JEEB> so you'd have to once again probe through it
[16:23:04 CEST] <JEEB> and man that analyzeduration barely hit that DTS :D
[16:23:18 CEST] <JEEB> that DTS is like half a second before 10s
[16:24:43 CEST] <JEEB> but yeah, nope quick way unless you know how to build a header :P
[16:25:02 CEST] <JEEB> because ffmpeg can only do it when rebuilding
[16:35:09 CEST] <Dariush> oh, all right. guess I'll do it the slow way. thanks :)
[16:51:35 CEST] <xlinkz0> hey, i'm having trouble transcoding an mkv video i downloaded from youtube with youtube-dl
[16:51:57 CEST] <xlinkz0> I get this error even though i'm specifying the pixel format : [buffer @ 03c1b4a0] Unable to parse option value "-1" as pixel format
[16:52:16 CEST] <xlinkz0> this is my command : ffmpeg -y -i test.mkv -c:v libx264 -pix_fmt yuv420p out.mp4
[16:52:48 CEST] <c_14> try setting -pixel_format yuv420p before -i
[16:53:29 CEST] <c_14> and/or -pix_fmt yuv420p before -i
[16:53:57 CEST] <xlinkz0> tried both, says Option pixel_format not found.
[16:54:29 CEST] <c_14> yeah, pixel_format is for some input devices. What about -pix_fmt ?
[16:54:35 CEST] <c_14> Or does it say that for both?
[16:54:39 CEST] <xlinkz0> bot
[16:54:41 CEST] <xlinkz0> both
[16:54:47 CEST] <xlinkz0> yep, strange
[16:54:55 CEST] <xlinkz0> says pixel_format even when i use pix_fmt
[16:55:12 CEST] <c_14> Which youtube video is this? (so I can test on my computer)
[16:55:22 CEST] <c_14> And what version of ffmpeg are you using
[16:55:39 CEST] <xlinkz0> ah, 2013 :D
[16:55:56 CEST] <xlinkz0> i'll update
[16:56:24 CEST] <xlinkz0> ffmpeg version N-56404-g4d09d2e
[16:56:24 CEST] <xlinkz0> built on Sep 17 2013 22:33:41 with gcc 4.7.3 (GCC)
[16:58:18 CEST] <xlinkz0> works now, thanks :)
[18:31:32 CEST] <Roest> hi
[18:54:19 CEST] <arbi> I need help please. I want to encode a video into a standard format so that a blue ray player can play it. What ever I do either the format is unsupported or video is not shown or audio is not there.
[18:54:48 CEST] <arbi> For example when I create an mp4 with mpeg-4 video and mp3 audio the player doesn't recognize the audio. But strangely if I have a mp3 music it plays it
[18:55:06 CEST] <arbi> If I change the audio codec to AAC then the file becomes unsupported
[18:56:51 CEST] <Roest> hi, could anyone help me with encoding video on Win10 using the precompiled libs from the download page, it's pretty much the encoding example with a few adjustment to my code, it works however it only encodes 10 seconds then stops, the issue is that got_packet, line 170 in the pastebin is zero after that
[18:56:56 CEST] <Roest> http://pastebin.com/Nrpz75bX
[19:05:45 CEST] <arbi> What is a typic AV codecs for an mp4 file?
[19:07:58 CEST] <DHE> h264 video, aac or ac3 audio
[19:08:30 CEST] <DHE> I could be wrong about the audio, those are just common
[19:09:38 CEST] <arbi> Then why doesn't my blue ray player understand AAC? It just says format unsupported :-/
[19:10:41 CEST] <arbi> Is information missing in the file?
[19:11:01 CEST] <tdr> or some bitrate it cant play
[19:11:05 CEST] <BtbN> Because it's a bluray player.
[19:11:25 CEST] <BtbN> I wouldn't expect it to play anything except what's on a normal bluray.
[19:11:28 CEST] <furq> hardware players tend to be quite bad at playing videos
[19:12:08 CEST] <arbi> It plays videos made on my android phone which are in mp4 format
[19:12:52 CEST] <furq> which codecs are the working files using
[19:13:08 CEST] <arbi> AVC and AAC
[19:13:59 CEST] <furq> well that sounds like a lot of fun
[19:14:04 CEST] <furq> maybe it's the thing tdr said about bitrates
[19:14:22 CEST] <furq> i know a lot of old hardware players refused to play vbr mp3
[19:14:36 CEST] <arbi> hmm.. then I'll try to use the exact same setup
[19:16:41 CEST] <arbi> Yeah bitrate seems to be different.. but it's AAC not mp3
[19:20:35 CEST] <furq> in my experience hardware players are incredibly picky about what they'll play
[19:20:47 CEST] <furq> especially older ones
[19:21:14 CEST] <tdr> depends alot on the brand too
[19:21:23 CEST] <furq> i'm not an expert on mp3 but it could even be down to the way the mp4 is muxed
[19:21:25 CEST] <furq> s/mp3/mp4
[19:24:54 CEST] <arbi> hmm
[19:28:09 CEST] <arbi> ok I need the audio to be AAC constant bitrate 96kbs, 1 channel
[19:28:37 CEST] <arbi> now I have vbr 196k and 2 channels
[19:28:54 CEST] <furq> if you're asking how to do that with ffmpeg then -b:a 96k -ac 1
[19:28:58 CEST] <arbi> s/196k/192k
[19:29:20 CEST] <arbi> thanks I was gonna ask about the channel :)
[19:29:25 CEST] <furq> it could be any of those things though (mono, cbr, 96k)
[19:29:32 CEST] <furq> obviously you want stereo and a higher bitrate if it works
[19:30:00 CEST] <arbi> yea.. but I've been trying to long that I'll be very happy IF it works hehe
[19:34:17 CEST] <arbi> the parameter -ac 1 creates another channel entry which says channel_original=1 but the old channel=2 still exists
[19:34:40 CEST] <arbi> I'm using mediainfo to view this
[20:52:09 CEST] <Xen0_> if im running ffserver and want anyone to be able to stream to it what do i need to set ACL allow to?
[20:53:54 CEST] <Xen0_> i keep gettin
[20:53:56 CEST] <Xen0_> /etc/avserver.conf:13: ACL refers to invalid host or ip address '#
[23:57:27 CEST] <idlus> hello, Im trying to invoke the crop filter with parameters 1:ih:0:0
[23:57:50 CEST] <idlus> but it returns with "invalid too big or non positive size for width"
[00:00:00 CEST] --- Sun May 8 2016
1
0
[00:42:45 CEST] <atomnuker> durandal_1707: huh, turns out our wavpack encoder isn't bad at all
[00:42:56 CEST] <atomnuker> but why is joint_stereo off by default?
[00:44:58 CEST] <durandal_1707> atomnuker: I think its still slower than cmd encoder
[00:45:24 CEST] <atomnuker> yeah, it's a bit slower than libwavpack (which isn't affected by the compression_level setting)
[00:45:37 CEST] <atomnuker> at compression_level 3 we match the size it produces exactly
[00:45:45 CEST] <atomnuker> but we're slightly slower
[00:45:57 CEST] <atomnuker> (with joint_stereo turned on)
[01:07:54 CEST] <Daemon404> ^ your favourite, kierank
[01:08:09 CEST] <Shiz> w 27
[01:08:16 CEST] <Daemon404> exactly.
[01:09:22 CEST] <kierank> Omg
[01:15:33 CEST] <llogan> let's add a web browser too
[01:16:05 CEST] <Shiz> add ssl
[01:16:07 CEST] <Shiz> come one guys
[01:16:09 CEST] <Shiz> on*
[01:25:49 CEST] <Daemon404> ... we do
[01:25:59 CEST] <Daemon404> already.
[01:26:30 CEST] <RiCON> not with schannel
[01:26:39 CEST] <RiCON> iirc
[01:27:43 CEST] <Daemon404> yes but the rest.
[01:29:53 CEST] <llogan> wm4: typo in mpv docs for --lavfi-complex: "A label named ao will be connected to the audio input." s/input/output
[02:16:39 CEST] <cone-354> ffmpeg 03Christophe Gisquet 07master:9c1aa14bf0b8: vc2enc: prevent random data
[02:47:27 CEST] <cone-354> ffmpeg 03Muhammad Faiz 07master:83065939cb84: avutil/parsing: add '\r' as whitespace
[02:47:28 CEST] <cone-354> ffmpeg 03Muhammad Faiz 07master:1d4400ac7fb0: avfilter/graphparser: add '\r' as whitespace
[03:51:53 CEST] <cone-354> ffmpeg 03Andrey Utkin 07master:abb69a2f2ba8: avcodec: Add "sar" alias to "aspect" option of video encoders
[05:50:21 CEST] <cone-354> ffmpeg 03James Almer 07master:bd63ecec7820: avcodec/dcadsp: use LOCAL_ALIGNED_32 instead of LOCAL_ALIGNED(32, ...)
[06:47:58 CEST] <jya> is AVFrame::coded_picture_number only used by the h264 decoder?
[10:27:54 CEST] <cone-096> ffmpeg 03Timo Rothenpieler 07master:31ce01bdb972: avcodec/nvenc: don't set profile in lossless mode
[11:20:22 CEST] <BtbN> https://bpaste.net/show/357c0b6af51b great...
[11:22:45 CEST] <BtbN> aparently triggered by using -O3, -O2 works fine.
[11:22:48 CEST] <BtbN> gcc 5.3.0
[11:51:56 CEST] <iive> BtbN: nICE,
[11:55:50 CEST] <nevcairiel> BtbN: its probably the tree vectorization which we turned on recently, imho that should just be reverted, its been producing errors in all kinds of scenarios
[12:07:14 CEST] <Daemon404> nevcairiel, i did warn against it! :)
[12:13:57 CEST] <JoshX> is it possible to store the systemtime as unix epoch in the videostream as secondary timecode in a matroska container?
[12:14:02 CEST] <Compn> gcc ".0" ...
[12:14:04 CEST] <JoshX> i know axis camera's do it
[12:14:21 CEST] <JoshX> so it is possible in the container
[12:14:26 CEST] <JoshX> now, can ffmpeg do it too ;)
[12:15:06 CEST] <JoshX> or if i would want to implement it myself, where to look in the code :-) i would like the current system timestamp in every keyframe for example... once per second is more than enough
[12:15:10 CEST] <nevcairiel> Compn: you should really have an idea what you are talking about before typing =p
[12:15:18 CEST] <Compn> JoshX : can probably write a script to dump systemtime to a timecode format and then ffmpeg can mux it
[12:15:38 CEST] <Compn> nevcairiel : yes, frequently gcc versions with .0 cause problems
[12:15:45 CEST] <Compn> gcc 5.0 4.0 etc
[12:15:51 CEST] <nevcairiel> but this is not a 0 version, its a 3 version
[12:16:10 CEST] <Compn> just means gcc is introducing that in its point releases too
[12:16:12 CEST] <nevcairiel> gcc 5.3 is the third release of the 5 series compiler
[12:16:15 CEST] <JoshX> Compn: i don't get it.. use the start time of the file as a 'start' and postprocess the timestamps in it?
[12:16:28 CEST] <nevcairiel> they dont use the third digit anymore
[12:17:11 CEST] <JoshX> i already patched ffmpeg to be able to produce filenames with the systemtime to the msec in it.. so i know the start time of each file..
[12:17:17 CEST] <Compn> fair enough
[12:18:33 CEST] <JoshX> I guess more people would want this feature :) to be able to, not only store the frame time, but also the actual time of recording
[12:18:36 CEST] <Compn> JoshX : sorry, i dont know :D
[12:25:43 CEST] <iive> nevcairiel: nevcairiel they don't use zero for development releases anymore either,
[12:25:50 CEST] <JoshX> well... there is this file: libavformat/mkvtimestamp_v2.c
[12:25:56 CEST] <iive> but 5.3.0 is before they did adopt all that
[12:25:57 CEST] <JoshX> perhaps i could do something here...
[12:26:11 CEST] <nevcairiel> iive: no its not, 5.x was the first of the new versioning scheme
[12:26:26 CEST] <nevcairiel> 5.0 was development, 5.1 the first release etc
[12:27:07 CEST] <nevcairiel> intermediate development versions use .1 at the end, so 5.3.1 is the latest development version of the 5 branch, once its released itll be 5.4
[12:27:56 CEST] <iive> hum... i've missed that
[12:28:22 CEST] <iive> and 5.3.1 been development version is horrible idea
[12:29:41 CEST] <nevcairiel> publicly they dont use the third digit at all anymore, all documentation etc only lists two
[12:30:01 CEST] <iive> they packaging and version strings still print it.
[12:31:18 CEST] <iive> however having 6.0 been development and then every version that doesn't end in 0 also been development, is quite inconsistent and conflicting.
[12:31:52 CEST] <jkqxz> Not doing so would defeat the point. The whole change is because many distributions use random unreleased version versions of gcc, and they want to be able to identify those to tell people to go away / use a proper version.
[12:32:49 CEST] <iive> i don't see how this changes anything...
[12:33:19 CEST] <iive> i mean, isn't debian now 5.3.0-137.12 ?
[12:33:34 CEST] <iive> (i guess not, i just made it up ;)
[12:34:03 CEST] <jkqxz> Previously, people would claim to have version 4.6.0 or whatever and actually have some random early branch of that. Now you can see from a version number like 5.0 that they are naughty.
[12:35:57 CEST] <nevcairiel> i suppose for consistency they might also call it 6.0.1 during development
[12:36:30 CEST] <mark4o> Just call it version N-78989-gcaeed04 :P
[12:36:35 CEST] <iive> yeh... that would be sensible
[13:15:30 CEST] <Daemon404> nevcairiel, nals? :x
[13:24:02 CEST] <Compn> mark4o : hey, "78989" is chronological at least :P
[13:25:50 CEST] <Compn> somewhat. depending on the merges.
[14:12:02 CEST] <Daemon404> act
[14:48:17 CEST] <durandal_1707> DSM_: hi
[15:47:11 CEST] <cone-746> ffmpeg 03Michael Niedermayer 07master:4155d5e06fa7: avcodec: add M101 decoder
[15:47:11 CEST] <cone-746> ffmpeg 03Michael Niedermayer 07master:5621da4996fe: avformat/riff: add M101
[15:50:17 CEST] <durandal_1707> michaelni: codec id is in wrong place
[16:00:46 CEST] <cone-746> ffmpeg 03Michael Niedermayer 07master:58b3e5606b99: avcodec/avcodec: Move AV_CODEC_ID_M101 to the 2nd group of video codecs
[16:30:55 CEST] <nevcairiel> Daemon404: i send a preparation patch to the ML
[16:53:36 CEST] <RiCON> basically, nothing new ^
[17:00:14 CEST] <wm4> I wonder if cehoyos enjoys his shit
[17:00:25 CEST] <wm4> because he's the maintainer of this thing now
[17:00:33 CEST] <wm4> everyone else wanted to remove it
[17:03:27 CEST] <Daemon404> nevcairiel, cool
[18:22:09 CEST] <nevcairiel> Daemon404: well i made it compile, if it passes fate .... :)
[18:30:06 CEST] <nevcairiel> wow it works
[18:30:11 CEST] <nevcairiel> (not on the first try)
[18:38:31 CEST] <durandal_1707> Daemon404: you merged hw upload / download filters?
[18:43:48 CEST] <nevcairiel> Daemon404: https://github.com/Nevcairiel/FFmpeg/tree/h264merge
[18:43:59 CEST] <nevcairiel> 3 top commits
[18:47:20 CEST] <nevcairiel> really wasnt that hard, instead of trying to merge the change i just re-applied it to our code, most of it is just re-indenting it one level and changing a few variables around
[18:48:58 CEST] <nevcairiel> git diff -w is surprisingly clean
[18:49:52 CEST] <nevcairiel> hm one hevc test broke by this, how odd
[18:49:53 CEST] Action: nevcairiel debugs
[18:52:40 CEST] <Daemon404> ill wait and merge when u give the ok
[18:52:50 CEST] <Daemon404> been working on a hobby project instead of merging
[18:53:18 CEST] <Daemon404> https://www.dropbox.com/s/w5a44jo7h8a4a0z/hexcmp.png?dl=0 <-- beyond compare style hex diffs of abritrarily different sized files
[18:53:25 CEST] <Daemon404> in cli
[18:55:37 CEST] <nevcairiel> there was a bug in ff_h2645_packet_split which initialized the getbitcontext with a value 8 times too high, when i fix that bug some hevc things fail their range checks
[18:56:09 CEST] <nevcairiel> without fixing the bug, h264 doesnt work =p
[18:56:43 CEST] <Daemon404> oh good
[18:57:01 CEST] <nevcairiel> not sure if the check isnt maybe wrong
[19:08:02 CEST] <nevcairiel> i think the check was wrong
[19:11:26 CEST] <nevcairiel> Daemon404: how did your rebase those merges, i dont want to have to fix it again =p
[19:11:48 CEST] <Daemon404> as in how do i rebase merges when pople push?
[19:12:14 CEST] <nevcairiel> well or when i need to re-order a commit before it
[19:12:32 CEST] <nevcairiel> or well, i just pushed a new commit to https://github.com/Nevcairiel/FFmpeg/tree/h264merge .. it needs to go before the merge
[19:12:37 CEST] <Daemon404> for each merge: git diff <mergehash>^..<mergehash> > something.diff
[19:12:42 CEST] <Daemon404> and merge with -s orus
[19:12:46 CEST] <Daemon404> patch -p1 < something.diff
[19:12:49 CEST] <Daemon404> git commit -a --amend
[19:12:54 CEST] <Daemon404> old school
[19:13:03 CEST] <nevcairiel> i still wonder why git cant figure this our for you
[19:14:23 CEST] <Daemon404> i have no idea
[19:14:30 CEST] <Daemon404> im sure people will say rebasing merges is wrong
[19:15:18 CEST] <nevcairiel> i sent my latest fix to the ML just to be safe
[19:19:10 CEST] <nevcairiel> ok re-ordered in my branch
[19:24:05 CEST] <iive> nevcairiel: you don't ask for `git rebase -i <sha1>` i guess
[19:24:39 CEST] <nevcairiel> rebase doesnt like merges
[19:25:05 CEST] <iive> who does ;)
[19:45:34 CEST] <cone-091> ffmpeg 03Carl Eugen Hoyos 07master:017d42ebc60f: configure: Only utvideo <= 15.3.0 is supported.
[19:46:54 CEST] <RiCON> there, fixed.
[19:51:10 CEST] <wm4> "fixed"
[19:54:57 CEST] <kierank> hahahaha
[19:57:54 CEST] <JEEB> that's... one way of doing it
[19:58:10 CEST] <JEEB> considering nobody cares about libutvideo really, that might be for the better
[19:58:36 CEST] <JEEB> (although it wouldn't be really different to just removing the wrapper :D)
[19:59:42 CEST] <RiCON> wonder which obscure fork he used for >15.1.0
[19:59:52 CEST] <RiCON> since qyot's only goes up to that one
[20:05:40 CEST] <Daemon404> Not My Problem
[20:11:34 CEST] <jamrial> hah, that's a nice way to get around actually having to maintain the wrapper while still being able to pretend he maintains it
[23:55:00 CEST] <cone-350> ffmpeg 03James Almer 07master:03fceb771cee: fate: fix dcadec test dependencies
[00:00:00 CEST] --- Sat May 7 2016
1
0
[00:19:10 CEST] <vade> ah, my source buffer was fucking things up, not the destination. working
[00:53:48 CEST] <bostonmacosx> hello there
[00:56:50 CEST] <durandal_1707> hello
[00:57:12 CEST] <rsully> furq, relaxed: if either of you are around, I'm back, trying to figure out these next errors from building statically. this happens during `make` step: http://pastie.org/private/2ywrurvsk70pmmhs9mfmxq
[00:58:47 CEST] <furq> rsully: fwiw i'm just googling the missing symbol names
[00:58:50 CEST] <furq> apparently this one is from glib
[00:59:29 CEST] <furq> i've static linked harfbuzz without static linking glib, so i guess your harfbuzz is compiled with weird options
[00:59:39 CEST] <rsully> default on ubuntu 16.04
[01:00:01 CEST] <furq> well yeah mine was cross-compiled so i had to do it myself, so presumably it avoids the dependency
[01:00:19 CEST] <rsully> so I need to compile harfbuzz then?
[01:01:17 CEST] <furq> do you have libglib2.0-dev installed
[01:01:27 CEST] <furq> that should hopefully fix it
[01:02:01 CEST] <rsully> Nope, installing now
[01:05:59 CEST] <rsully> No difference
[01:07:42 CEST] <bostonmacosx> So I'm trying to get my head wrapped around HLS
[01:08:20 CEST] <bostonmacosx> To do a multi bit rate delivery I would need to enocode multiple streames at different bit rates and then server then up with 1 m3u8 file
[01:11:21 CEST] <bostonmacosx> to rule them all...
[01:11:47 CEST] <bostonmacosx> I'm thinking of using CLAPPR as my web player since it seems to understand HLS playback..I'm not sure what else does
[01:12:08 CEST] <rsully> furq going to try to build harfbuzz with --enable-static
[01:24:15 CEST] <rsully> furq how important is graphite2 support for harfbuzz / ffmpeg?
[01:28:17 CEST] <furq> no idea
[01:29:01 CEST] <rsully> lots of warnings, but it didn't fail build this time (with harfbuzz built without graphite2 support, statically)
[01:29:07 CEST] <rsully> (and rebuilding libass against it)
[01:29:26 CEST] <rsully> aaand ffmpeg seg faults
[01:30:27 CEST] <rsully> how do I even debug this
[01:30:39 CEST] <rsully> I have a core file in cwd
[01:33:07 CEST] <rsully> meh no debug symbols so this is useless
[01:50:47 CEST] <rsully> umm compilign --with-debug but no debugging symbols found by gdb???
[01:52:30 CEST] <klaxa> did you use ffmpeg_g ?
[01:52:47 CEST] <rsully> no, I just found that mentioned in mailing list. I will try now.
[01:53:31 CEST] <c_14> You can also --disable-stripping, but honestly just use ffmpeg_g
[01:53:41 CEST] <rsully> yep understood.
[01:53:51 CEST] <rsully> gotta recompile because i cleaned too early
[08:12:56 CEST] <twerd> Hello, is there a command to encode a video with a gop of IBBP where each B and P frames DO NOT include I macroblocks?
[08:14:14 CEST] <twerd> We would like to have motion vectors available for every macroblock. Alternatively, what code file is responsible for deciding whether a macroblock should use MV or not?
[10:19:22 CEST] <Fyr> guys, what is the structure of chapter file for FFMPEG?
[10:19:31 CEST] <Fyr> I can't google out an example.
[10:49:45 CEST] <CoJaBo> So, if I upgrade to the latest ffmpeg, I get the error "[concat @ 0x4676120] Unsafe file name "; it seems to be suggested to use -safe, but that just results in a different error, "/dev/fd/63: could not find codec parameters". Ideas?
[11:10:34 CEST] <JoshX> Hi all!
[11:11:03 CEST] <JoshX> with the matroska container (amongst others) it is possible to store the system time in each the videostream as well..
[11:11:21 CEST] <JoshX> so you can get the absolute frame time per frame, but also the system time of the recording for each frame
[11:11:31 CEST] <JoshX> is it possible to enable this with ffmpeg?
[11:11:38 CEST] <Fyr> maybe, as an attachment
[11:12:09 CEST] <JoshX> how would i enable this on the command line? I know some axis camera's can produce a mkv file with this setting enabled
[11:12:18 CEST] <JoshX> and i'm using the vi3o python package..
[11:12:34 CEST] <JoshX> and i'm very close to mimiccing this behaviour using a generic cam and ffmpeg
[11:12:51 CEST] <JoshX> (and the recording systems timesource as the time)
[11:13:09 CEST] <JoshX> it should return an epoch unix timestamp per frame
[11:13:29 CEST] <JoshX> and it does, only the start time is 0, so i'm getting 'system timestamps' from 1970-01-01
[11:13:59 CEST] <JoshX> so ffmpeg should insert the system time every x frames, ususally once per second, in the mkv stream as a unix expoch
[11:14:06 CEST] <JoshX> would this be possible?
[11:22:31 CEST] <JoshX> Fyr: do you have and ideas?
[11:28:10 CEST] <Fyr> JoshX, do you need to burn time stamp every frame?
[11:28:37 CEST] <Fyr> somehow, at the bottom-right corner?
[11:28:40 CEST] <JoshX> the axis cam does it once per second
[11:29:08 CEST] <Fyr> or are you trying to set the timeline at 1970-1-1?
[11:40:47 CEST] <JoshX> Fyr: i want the system unix timestamp in the videostream once per second or so
[11:41:01 CEST] <JoshX> *would like ;)
[11:41:16 CEST] <Fyr> oh, I don't know, sorry.
[11:50:05 CEST] <JamJams> Since ->codec->framerate.num is gone, what should we use as a replacement. ->codecpar-> doesn't have the framerate element?
[16:52:05 CEST] <neuro_sys> any pointers on using ffmpeg api (libav) to feed in-memory images as inputs and as video output?
[16:52:35 CEST] <Prelude2004c> --> /home/ffmpeg-3.0.1/ffmpeg -i - -codec copy -f mpegts - 2>/var/log/channels/${CHN}/input.txt < "$fifo" & encode+=($!)|/root/sandro/FFNVTranscoder/NvTranscoder -size 1280 720 -i /dev/stdin -o /dev/stdout -bitrate 1800000 -vbvMaxBitrate 2500000 -vbvSize 1000000 -deviceID $2 $NVENC_OPTS |/home/ffmpeg-3.0.1/ffmpeg -fflags +genpts -i - -c:v copy -c:a aac -b:a 128k -ac 2 -timestamp now -f hls -hls_time 6 -hls_flags delete_segments -hls
[16:52:35 CEST] <Prelude2004c> _list_size 5 ${HLS_PATH}/${CHN}/${CHN}2M.m3u8 2>/var/log/channels/${CHN}/720p.txt ( Anyone know why i get all the garbage data on the screen ?? ) .. am i not pushing something to /dev/null ?
[17:01:51 CEST] <DHE> neuro_sys: there's a doc/examples directory with code examples, including some that generate their own images algorithmically
[17:02:53 CEST] <neuro_sys> DHE: thanks, I'm checking (I was considering the option of using ffmpeg-cli to pipe-in image streams but whatevr)
[17:13:41 CEST] <Prelude2004c> hey.. anyone know what i am doing wrong ?
[17:13:54 CEST] <Prelude2004c> soon as i run that thing... i get nothing but the garbage from the actual stream on my linux shell screen
[17:14:11 CEST] <Prelude2004c> tried so many different ways of doing /dev/null to hide that.. but nothing works.. not sure wh
[17:14:13 CEST] <Prelude2004c> why*
[17:14:23 CEST] <Prelude2004c> is it because i am running with /bin/bash?
[17:16:01 CEST] <DHE> the very first ffmpeg outputs to stdout but you never piped that anywher
[17:16:13 CEST] <c_14> You mean stderr
[17:16:49 CEST] <Prelude2004c> i was trying to push to fifo file
[17:17:19 CEST] <Prelude2004c> wait.. that is only first part.. ok. let me see if i understand
[17:17:41 CEST] <Prelude2004c> --> /home/ffmpeg-3.0.1/ffmpeg -i - -codec copy -f mpegts - 2>/var/log/channels/${CHN}/input.txt < "$fifo" & encode+=($!)|/root/sandro/FFNVTranscoder/NvTranscoder . doesn't that mean i pipped it to the transcoder ?
[17:18:32 CEST] <c_14> no
[17:18:42 CEST] <Prelude2004c> ok well then that is where i am confused :)
[17:18:42 CEST] <DHE> no, because '&' is a command separator which runs the command on the left side in the background
[17:18:42 CEST] <c_14> The '&' makes it fork
[17:18:43 CEST] <Prelude2004c> ok...
[17:19:31 CEST] <DHE> so.. you're getting ffmpeg to convert the output to mpegts, which gets fed into an 'nvtransocder' (nvidia I assume) which then goes back into ffmpeg
[17:19:35 CEST] <Prelude2004c> ahhhhh ok.... so do i put that fifo thing at the end of the line.. or do i just put the & encode ..
[17:19:35 CEST] <DHE> there is nvenc support in ffmpeg these days
[17:20:04 CEST] <Prelude2004c> ya i know... i am having problems with the decoding.. the nvtranscoder works well.. doesn't require vdpau
[17:20:15 CEST] <Prelude2004c> i tried to use vdpau... locks up the nvidia card.. for some reason randomly
[17:20:23 CEST] <Prelude2004c> this nvidia built library works very well
[17:20:31 CEST] <Prelude2004c> and does the decode/encode together on the ard
[17:20:33 CEST] <Prelude2004c> card*
[17:22:08 CEST] <Prelude2004c> so i get you 100% .. on the < "$fifo " & .. so. the question is... i can't move that fifo < fifo & encode to the nd because then it wont pipe to nvtranscoder only to the last session which is ffmpeg.. so.. that means.. do i just move the & encode+=($!) to the end ?
[17:22:58 CEST] <Prelude2004c> i mean how would the fifo know which param to use from fifo .. since the files were passed to varialbe encode ( if i am saying that right )
[17:24:17 CEST] <neuro_sys> I think this is the one of the few good tutorials on ffmpeg library? http://dranger.com/ffmpeg/
[17:25:46 CEST] <neuro_sys> which happens to be outdated...
[17:26:04 CEST] <Prelude2004c> ya.. ok i got it.. i removed the encode+=($!)
[17:26:15 CEST] <Prelude2004c> and the & was removed too
[17:26:29 CEST] <Prelude2004c> not sure if i did that right though
[17:26:32 CEST] <Prelude2004c> but it is working
[17:28:57 CEST] <neuro_sys> what is YUV exactly?
[17:31:30 CEST] <furq> https://en.wikipedia.org/wiki/YUV
[17:31:53 CEST] <neuro_sys> wow, this website looks good
[17:32:02 CEST] <DHE> those component cables used in old analog HD video? They're not actually red, green blue data
[17:35:20 CEST] <neuro_sys> http://www.amazon.com/Video-Demystified-Handbook-Digital-Engineer/dp/075068…
[17:35:24 CEST] <neuro_sys> lLooks neat
[17:38:41 CEST] <neuro_sys> writing PNGs to disk takes so much time, I should definetely stream them in-memory to ffmpeg
[17:38:59 CEST] <neuro_sys> and in raw rgba
[17:43:47 CEST] <Prelude2004c> for files in '${HLS_SOURCE}/${CHN}/*|sort -R'; do echo $files;done .. what is wrong with this /
[17:43:55 CEST] <Prelude2004c> trying '' or ""
[17:44:26 CEST] <Prelude2004c> and tried for files in ${HLS_SOURCE}/${CHN}/*; do echo $files |sort -R;done
[17:45:01 CEST] <Prelude2004c> silly me.. nevermind
[17:47:26 CEST] <Prelude2004c> well i found the source of one of my errors..
[17:47:28 CEST] <Prelude2004c> for files in ${HLS_SOURCE}/${CHN}/*;do echo $files;done|sort -R|while read f;do /home/ffmpeg-3.0.1/ffmpeg -re -i $f
[17:47:47 CEST] <Prelude2004c> Parse error, at least 3 arguments were expected, only 1 given in string 'METV/advertise4.mov'
[17:48:09 CEST] <Prelude2004c> getting errors like that.. .. what is wrong with that and can it be imrpoved ?
[17:57:42 CEST] <Prelude2004c> very odd..
[17:57:48 CEST] <Prelude2004c> for files in ${HLS_SOURCE}/${CHN}/*;do echo "$files"|sort -R;done|while read f; do /home/ffmpeg-3.0.1/ffmpeg -re -i "$f" . gives me the parse error
[18:03:45 CEST] <UukGoblin> hello, I'm trying out the NVENC stuff. I've compiled ffmpeg successfully and I'm trying to recode a h264 file. I haven't yet figured out how to insert a scaling filter, but something seems wrong already. I'm running AV_LOG_FORCE_COLOR=yes ~/soft/ffmpeg-3.0.2/bin/ffmpeg -i ./orig_vid.h264 -c:v nvenc -profile:v high444p -preset hq nvenc.h264 -v trace | aha
[18:03:53 CEST] <UukGoblin> here's the output: http://yat.uukgoblin.net/ffmpeg.html
[18:04:49 CEST] <UukGoblin> I've no idea what might be causing the 'EncodePicture failed' thing, does anyone have a clue?
[18:08:52 CEST] <Prelude2004c> UukGoblin > try running it without the profile .. any difference ?
[18:11:58 CEST] <UukGoblin> Prelude2004c, yes! thanks, I got the profile thing from https://trac.ffmpeg.org/wiki/HWAccelIntro
[18:12:06 CEST] <UukGoblin> works without it :-)
[18:13:01 CEST] <Prelude2004c> yup..
[18:13:07 CEST] <UukGoblin> so I added a scaler with -vf scale=1920x1080, but I believe this is a software scaler, right? Is there any way I could an accelerated one?
[18:13:55 CEST] <Prelude2004c> um... you can scale that way.. accelerated what do you mean ?
[18:14:29 CEST] <UukGoblin> actually I guess I'd need to decode h264 via the video card as well for it to make sense
[18:14:34 CEST] <Prelude2004c> -size 1920x1089
[18:14:41 CEST] <UukGoblin> Prelude2004c, like, have the gfx card do the scaling
[18:14:45 CEST] <Prelude2004c> sure.. you are playing in my pain in life :P haha.
[18:15:01 CEST] <Prelude2004c> ya if your using ffmpeg.. you can use vdpau to do it
[18:15:05 CEST] <durandal_1707> there are hw scaler filters
[18:15:40 CEST] <Prelude2004c> oh.. ya i am not too familiar with that.. haven't gotten that far with respect to scaling :)
[18:15:49 CEST] <Prelude2004c> i do have one question however.
[18:16:22 CEST] <Prelude2004c> ( last question of the day hopefully.. :) -- ( printf '%s\n' "${HLS_SOURCE}/${CHN}"/*|sort -R|while read f; do /home/ffmpeg-3.0.1/ffmpeg -re -i "$f" -codec copy ) what do you think? here is the odd part.. the files being passed to ffmpeg are still giving me this sort of error ( Parse error, at least 3 arguments were expected, only 1 given in string 'METV/advertise8.mov' ).. so two things why an error when i introce the while read.. a
[18:16:22 CEST] <Prelude2004c> nd lastly why cuttong off since the path for hte files is /mnt/extra/CMETV/advertise8.mov
[18:16:28 CEST] <UukGoblin> durandal_1707, could you point me to a name or sth? :-)
[18:17:17 CEST] <durandal_1707> search for hw in filter docs, you need recent ffmpeg
[18:17:42 CEST] <vade> interesting about the hw scaler - thats good to know
[18:17:56 CEST] <vade> durandal_1707: - is your handle a reference to marathon?
[18:18:04 CEST] <UukGoblin> durandal_1707, on https://ffmpeg.org/ffmpeg-filters.html, I can only find hw_frames_ctx and hwupload_cuda
[18:18:19 CEST] <durandal_1707> vade: haha
[18:20:50 CEST] <vade> :P
[18:22:20 CEST] <durandal_1707> UukGoblin: IIRC there are more, perhaps they are not documented, r
[18:23:43 CEST] <UukGoblin> Prelude2004c, -size is actually an unrecognized option ;-)
[18:26:53 CEST] <UukGoblin> I've recompiled with --enable-vdpau, but I'm not sure if it's actually using it for decoding. CPU usage stays pretty high, about half of each of 8 cores (@100 fps transcoding through nvenc)
[18:35:16 CEST] <UukGoblin> interesting, it looks like it's not possible to move the decoded frame back to RAM with VDPAU. So it'd /have/ to do all the filtering in hardware, if it's supposed to work at all. However, https://developer.nvidia.com/nvidia-video-codec-sdk mentions a NVCUVID API, for hardware video decoding. Maybe that'd be more suited for later (i.e. if I wanted to use some software-only filters)
[18:37:59 CEST] <durandal_1707> there are filters for this
[18:39:00 CEST] <UukGoblin> hm :-)
[18:40:37 CEST] <durandal_1707> what gives you ffmpeg -filters
[18:40:39 CEST] <durandal_1707> ?
[18:42:54 CEST] <UukGoblin> durandal_1707, nice, lots of things: http://pastebin.com/NAecmbHw
[18:58:39 CEST] <Prelude2004c> hey guys.. quick question.... is there some way to insert a png image logo on a video without transcoding it ?
[18:58:59 CEST] <Prelude2004c> -vf can't be used with copy. the video is already done.. and i don't want to encode it again.. but since i am creating the segment files.. i figure .. is there some way ? maybe not
[18:59:38 CEST] <vade> by definition youre changing the video content so it requires a decode - composite and re-encode
[19:00:05 CEST] <Prelude2004c> oh :( ... damn.. seesm nvtranscoder doesn't have an option for logo insert :(
[19:01:14 CEST] <vade> transcoding is decoding -> encoding. If you are segmenting many times you can just move raw packets from streams to one container to another witout transcoding, just fudging timestamps of the packets
[19:01:26 CEST] <vade> which are you doing?
[19:02:27 CEST] <neuro_sys> Do you think open source has similarities to communism as an economic model?
[19:03:02 CEST] <neuro_sys> sorry I have happy-friday induced over-moderation alcohol consumption today
[19:03:59 CEST] <furq> there are successful open-source projects, so no
[19:04:09 CEST] <vade> oh snap -
[19:04:10 CEST] <vade> haha
[19:08:14 CEST] <UukGoblin> neuro_sys, no, because copying software is nearly free, whereas copying resources isn't ;-)
[19:11:09 CEST] <c_14> >nearly free
[19:11:15 CEST] <c_14> You've obviously never sen the bit gulags, have you?
[19:11:33 CEST] <UukGoblin> no?
[19:12:23 CEST] <c_14> Forced labor camps hidden inside every computer.
[19:12:34 CEST] <c_14> Few breaks. No vacation. No amenities.
[19:12:58 CEST] <UukGoblin> millions of transistors kept there against their will?
[19:13:18 CEST] <Kadigan|Work> Hi. I just did a major update of my install base, which included ffmpeg 2.8.6. I previously used an ancient version that exposed MPlayer filters (I used mp=eq2 specifically). How can I replicate that functionality, as I need it?
[19:13:27 CEST] <UukGoblin> well, when that stuff realizes what we're forcing it to do, it ain't gonna be pretty
[19:13:55 CEST] <c_14> Kadigan|Work: the filters have been merged
[19:13:59 CEST] <c_14> eq2 is now just eq
[19:14:09 CEST] <c_14> eh, mp=eq2 is now just eq
[19:14:15 CEST] <Kadigan|Work> c_14: there is NOP, HLT and SLP ;) at least...
[19:14:25 CEST] <UukGoblin> ;-D
[19:14:44 CEST] <Kadigan|Work> (there's also a number of HCF instructions :D)
[19:15:23 CEST] <Kadigan|Work> Okay, it seems to work now. I guess it'll be a while before I find out if I still have the nonfree filters in.
[19:15:32 CEST] <Kadigan|Work> Thank You kindly :)
[19:21:34 CEST] <Kadigan|Work> Okay. Have the settings for eq changed? All I get now - using the same settings as I did for mp=eq2 - is all white video.
[19:28:26 CEST] <Kadigan|Work> Okay, seems gamma was moved from 1st to 4th place. (WTH ffmpeg-devs? why can't it be interop?)
[19:28:46 CEST] <Kadigan|Work> Anyway, thanks. Have a good one.
[20:05:28 CEST] <Prelude2004c> hum. whats the timeout param .. if file input times out after x amoutn of time just quite and go on
[20:05:38 CEST] <Prelude2004c> tried -timeout and its giving me incorrect option
[20:05:46 CEST] <Prelude2004c> even tried -stimeout
[21:05:42 CEST] <vade> question about the header docs for swr_convert_frame
[21:06:07 CEST] <vade> it mentions that I can pass in null AVFrame as input to get buffered converted output frames
[21:06:31 CEST] <vade> however, passing null says no matching function
[21:06:39 CEST] <vade> does this mean an empty frame?
[21:07:03 CEST] <vade> like one just frame_alloced but with no backing buffer from av_frame_get_buffer
[21:07:55 CEST] <vade> jesus christ. never mind
[21:08:02 CEST] <vade> <-idiot
[21:08:12 CEST] <vade> of course when you ask you realize your mistake
[21:27:04 CEST] <Fyr> guys, what is the best way to create silent audio?
[21:29:16 CEST] <durandal_1707> anullsrc
[21:29:23 CEST] <Fyr> thanks
[21:44:18 CEST] <OmegaVVeapon> guys, I'm trying to get ffmpeg to timeout when it listens on a Source Specific Multicast and gets no data
[21:44:28 CEST] <OmegaVVeapon> according to the documentation in https://ffmpeg.org/ffmpeg-protocols.html#udp
[21:44:42 CEST] <OmegaVVeapon> timeout= should do the trick
[21:44:58 CEST] <OmegaVVeapon> if I run "time ffmpeg -i udp://232.22.137.169:5698?timeout=5000000"
[21:45:08 CEST] <OmegaVVeapon> I see it exits in 5 seconds
[21:46:16 CEST] <OmegaVVeapon> however, switching to SSM. "ffmpeg -i udp://232.22.137.169:5698?sources=10.10.10.10&timeout=5000000" never exits...
[21:46:26 CEST] <OmegaVVeapon> what gives? :/
[21:52:42 CEST] <CoJaBo> So, if I upgrade to the latest ffmpeg, I get the error "[concat @ 0x4676120] Unsafe file name "; it seems to be suggested to use -safe, but that just results in a different error, "/dev/fd/63: could not find codec parameters". Ideas?
[21:53:43 CEST] <J_Darnley> I think you want "-safe 0", it needs an argument
[22:00:21 CEST] <CoJaBo> J_Darnley: Yeh, that was it; odd it can't give a clearer error message :/
[22:01:08 CEST] <J_Darnley> Well when it eats another option as its argument, ffmpeg doesn't know that.
[22:01:47 CEST] <J_Darnley> Although I might expect an error for something that isn't 0 or 1
[22:01:59 CEST] <J_Darnley> but I wonder whether you just ignored that.
[22:09:54 CEST] <OmegaVVeapon> Anyone with experience on using ffmpeg on multicast feeds?
[23:17:09 CEST] <vade> where does one submit API documentation bugs?
[23:24:02 CEST] <c_14> Same place you submit all other bugs, on trac
[23:24:11 CEST] <c_14> Or just send a patch to the ml
[00:00:00 CEST] --- Sat May 7 2016
1
0