Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

January 2016

1 participants
62 discussions

ffmpeg-devel.log.20160115
by burek 16 Jan '16

16 Jan '16

[00:30:21 CET] <cone-777> ffmpeg 03Ganesh Ajjanagadde 07master:2e4fd16f5b90: lavc/aacenc: use isfinite to simplify isnan/isinf logic [00:34:05 CET] <cone-777> ffmpeg 03Andreas Cadhalpun 07master:f8bc0137bdf8: lavu: prevent overflow in av_clip_intp2_c [01:00:57 CET] <cone-777> ffmpeg 03Andreas Cadhalpun 07master:763c572801a3: asfdec_o: only set asf_pkt->data_size after sanity checks [01:00:58 CET] <cone-777> ffmpeg 03Andreas Cadhalpun 07master:aa180169961b: asfdec_o: reject size > INT64_MAX in asf_read_unknown [01:00:59 CET] <cone-777> ffmpeg 03Andreas Cadhalpun 07master:0002d845e873: asfdec_o: check avio_skip in asf_read_simple_index [01:01:00 CET] <cone-777> ffmpeg 03Andreas Cadhalpun 07master:74474750f1ac: asfdec_o: prevent overflow causing seekback [01:01:01 CET] <cone-777> ffmpeg 03Andreas Cadhalpun 07master:3776a72962b0: asfdec_o: make sure packet_size is non-zero before seeking [01:01:02 CET] <cone-777> ffmpeg 03Andreas Cadhalpun 07master:0e32153e9c29: asfdec_o: break if EOF is reached after asf_read_packet_header [01:01:03 CET] <cone-777> ffmpeg 03Andreas Cadhalpun 07master:c29e87ad55a2: asfdec_o: check for too small size in asf_read_unknown [01:01:55 CET] <J_Darnley> Is it michaelni I should ask about getting push access? [01:24:15 CET] <jamrial> is the new asf demuxer good enough to replace the old one by now? [01:27:56 CET] <Timothy_Gu> J_Darnley: yes [01:28:11 CET] <Timothy_Gu> kierank: trac.ffmpeg.org is timing out for some reason. is that expected? [01:28:29 CET] <kierank> works4me [01:29:35 CET] <J_Darnley> Timothy_Gu: thanks [01:29:43 CET] <kierank> can't remember what the sudo password is [01:31:50 CET] <gajjanag> jamrial: spot anything else, or is patchv3 ready to be posted? [01:35:18 CET] <kierank> we should sign this https://github.com/dear-github/dear-github [01:36:27 CET] <jamrial> gajjanag: not as far as i could see, so post it [01:40:22 CET] <gajjanag> kierank: why not, but do you think if github changes in response some day we will use it more? [01:40:27 CET] <kierank> no [01:40:32 CET] <kierank> we want the opposite [01:40:38 CET] <kierank> pull requests disabled [01:40:43 CET] <kierank> so that *everyone* uses the ml [01:40:46 CET] <gajjanag> jamrial: posted [01:42:06 CET] <gajjanag> kierank: ah, I think it will slowly take care of itself; but it won't hurt to sign [01:45:50 CET] <gajjanag> kierank: for a hard measure, maybe https://nopullrequests.appspot.com/ is useful [01:46:02 CET] <kierank> we have https://github.com/FFmpeg/FFmpeg/pull/153 [01:47:13 CET] <gajjanag> kierank: I meant if you want to automate some of the work, instead of comment/manual close of each one [01:47:26 CET] <J_Darnley> kierank: that has a "it is ${CURRENT_YEAR}" :) [01:54:31 CET] <kierank> J_Darnley: gonna submit 422 asm for review? [01:55:15 CET] <J_Darnley> Yes, probably tonight [01:55:27 CET] <J_Darnley> I was tinkering with it some more [01:55:45 CET] <J_Darnley> (and fixing the 1 bug I saw) [02:26:33 CET] <durandal_1707> kierank: I guess you need to implement update_thread_context [02:27:30 CET] <kierank> Lol question in one chan and reply in other [02:29:27 CET] <durandal_1707> I don't want to wake them :P [02:46:15 CET] <llogan> kierank: i see one FFmpeg dev signed it (but under another project) [02:46:45 CET] <J_Darnley> Woo! Snow! [02:47:39 CET] <llogan> Timothy_Gu: what's with PRs like this? https://github.com/FFmpeg/FFmpeg/pull/169 [02:51:33 CET] <Timothy_Gu> llogan: no idea. Somebody who has no idea how GitHub works I guess. [02:51:49 CET] <llogan> IIRC, there are several like that [02:52:58 CET] <ac_slater> hey all. When I do `-b:v 500kb`, for example, how does the value make it to an encoder? [02:53:00 CET] <Timothy_Gu> Yeah seems like so. https://github.com/FFmpeg/FFmpeg/pull/157 is a different case: this person is trying to merge the upstream to their local tree [02:53:14 CET] <J_Darnley> ac_slater: magnets [02:53:27 CET] <ac_slater> J_Darnley: haha [02:53:37 CET] <Timothy_Gu> ac_slater: umm what do you mean? [02:54:13 CET] <ac_slater> Timothy_Gu: I'm writing an encoder and I want to use the `-b:v` parameter. Is t AVCodecContext->bit_rate? [02:54:15 CET] <J_Darnley> Seriously, the value will be pasred and set in the context structure [02:54:18 CET] <ac_slater> Is it * [02:54:22 CET] <Timothy_Gu> Yes. [02:54:40 CET] <ac_slater> ah ok. "b" != bit_rate. Thanks guys [02:55:10 CET] <Timothy_Gu> ac_slater: see https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/options_table.h#L45 [02:55:18 CET] <Timothy_Gu> `OFFSET(bit_rate)` [02:55:29 CET] <ac_slater> I was looking for that! Thanks guys [02:55:31 CET] <Timothy_Gu> which expands to `offsetof(AVCodecContext,bit_rate)` [02:55:40 CET] <Timothy_Gu> np [02:57:47 CET] <llogan> i'll be back in 10 days. [03:40:41 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:7ec9c5ce8a75: avcodec/pngenc: Replace memcpy by av_image_copy() [03:40:42 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:8f4c3e4b9221: avcodec/pngenc: Fix mixed up linesizes [03:40:43 CET] <cone-777> ffmpeg 03Mats Peterson 07master:b58cfa616c16: lavf/mov: Confine 0x00000000 to raw/twos fourcc mapping to version 0 sample descriptions [03:44:52 CET] <ac_slater> is it appropriate to ask about existing encoders here? [03:48:51 CET] <ac_slater> well, if not, ignore it. So, I have an encoder that only encodes YUV420P. Should I use swscale to convert the input source's pixel format, or is there a better way? Thanks! [03:49:45 CET] <J_Darnley> If you're writing an encoder for libavcodec then only allow 420as input and ffmpeg will take care of the conversion for you. [03:50:36 CET] <J_Darnley> Or is it some other encoder you are writing? [03:50:55 CET] <ac_slater> in my AVCodec struct instance, I set `.pix_fmts = AV_PIX_FMT_YUV420P;` [03:50:59 CET] <ac_slater> is this what you maen [03:51:01 CET] <ac_slater> mean * ? [03:51:06 CET] <J_Darnley> Yes [03:51:13 CET] <ac_slater> J_Darnley: yes, sorry. I'm writing for libavcodec [03:51:16 CET] <ac_slater> thanks mate [03:53:45 CET] <J_Darnley> PS I think it is a list so you'll need to terminate it with 0 or whatever value is needed. [03:54:18 CET] <ac_slater> J_Darnley: I was being brief, it is a list. AV_PIX_FMT_NONE is also in there [03:54:30 CET] <J_Darnley> ah good [03:55:46 CET] <J_Darnley> Oh my. "Digibetes"? What has the media invented now? [03:58:16 CET] <ac_slater> J_Darnley: I'm having some newbie issues with the general flow of an avcodec encoder. when my encode() function is called, the proper pixel format conversions already happened? [03:58:23 CET] <J_Darnley> Yes [04:00:46 CET] <ac_slater> hmm. Then I guess I don't know how to *properly* copy yuv420p data to my encoder's buffer. Using memcpy(), everything is greenish. Should I be using av_image_copy* ? [04:00:58 CET] <J_Darnley> Maybe. [04:01:08 CET] <ac_slater> yea, of course you wouldnt know ;P [04:01:11 CET] <J_Darnley> You do know what the "p" means, right? [04:01:12 CET] <ac_slater> very specific things here [04:01:18 CET] <ac_slater> packed? [04:01:22 CET] <J_Darnley> No [04:01:24 CET] <ac_slater> damn [04:01:27 CET] <J_Darnley> planar [04:01:44 CET] <J_Darnley> The samples are split into the first 3 data planes [04:01:55 CET] <ac_slater> right [04:02:07 CET] <J_Darnley> The first for luma [04:02:18 CET] <J_Darnley> and the 2nd and 3rd for chroma [04:02:27 CET] <J_Darnley> (I don't remeber which order) [04:02:30 CET] <ac_slater> I know that much at least [04:02:35 CET] <J_Darnley> Good [04:02:44 CET] <ac_slater> and the bit depth, etc [04:02:53 CET] <J_Darnley> Sorry if I'm being too... basic [04:03:18 CET] <J_Darnley> I would ask, can't yourencoder work directly from the input image? [04:03:28 CET] Action: J_Darnley curses his spacebar [04:03:29 CET] <ac_slater> it's necessary sometimes. And yes [04:04:09 CET] <ac_slater> I don't need to do anything except ensure it's yuv420p (it says "packed planar") [04:04:32 CET] <J_Darnley> Now that's odd phrasing [04:04:38 CET] <J_Darnley> Where is that? [04:05:09 CET] <ac_slater> have you ever heard of OMX ? [04:05:15 CET] <ac_slater> openMAX [04:05:16 CET] <J_Darnley> No [04:05:21 CET] <J_Darnley> Oh maybe that [04:05:29 CET] <ac_slater> it's a generic interface for encoders/decoders [04:05:37 CET] <ac_slater> my hardware encoder happens to use that [04:06:16 CET] <ac_slater> so, when I configure the OMX layer, my encoder will only accept YUV420PackedPlanar [04:07:34 CET] <ac_slater> the comment for that enum value is "packed for each payload in planar slices" [04:10:29 CET] <ac_slater> J_Darnley: ^ [04:15:50 CET] <J_Darnley> Sorry I don't know what that means [04:16:08 CET] <J_Darnley> and a little searching hasn't turned up something I understand [04:16:18 CET] <J_Darnley> I'm sure others might know [04:16:32 CET] <ac_slater> J_Darnley: thanks for the help mate [04:16:48 CET] <J_Darnley> If you want you could send an email to ffmpeg-devel. [04:16:51 CET] <ac_slater> If building didnt take > 5mins each time, I would more trial and error [04:16:57 CET] <ac_slater> J_Darnley: I'm thinking about it [04:17:03 CET] <J_Darnley> Just make sure you mention openmax [04:17:31 CET] <J_Darnley> When you change 1 file it shouldn't take that long to build [04:17:46 CET] <J_Darnley> Or is that on some low-power device? [04:18:00 CET] <ac_slater> yea it's not ffmpeg, it's the other stuff [04:18:05 CET] <J_Darnley> ah [04:18:39 CET] <ac_slater> thanks for the advice and help mate [06:27:28 CET] <cone-777> ffmpeg 03James Almer 07master:e3c188e72c02: avcodec/rmdec: add missing av_log argument [12:09:24 CET] <durandal_1707> is it ok to add afftfilt filter? [12:10:56 CET] <ubitux> durandal_1707: what would that be? [12:11:18 CET] <ubitux> A->V? [12:11:34 CET] <ubitux> A->"A"? [12:17:16 CET] <durandal_1707> yes [12:20:43 CET] <ubitux> "yes" is not a valid answer here :p [12:41:49 CET] <wm4> lol [12:41:59 CET] <wm4> what's "A" anyway? [12:42:13 CET] <durandal_1707> Anarchy [13:18:15 CET] <nevcairiel> durandal_1707: did that ever visit the ML? i didnt see it [13:19:12 CET] <durandal_1707> nevcairiel: what are you talking about? [13:19:32 CET] <nevcairiel> afftfilt [13:20:50 CET] <durandal_1707> I haven't written it yet [13:52:46 CET] <atomnuker> what the hell, I get a segfault in "if (!last && class && class->option && class->option[0].name)" [13:53:36 CET] <atomnuker> this could only happen if the class doesn't exist, yet its there [13:58:00 CET] <durandal_1707> atomnuker: code? [13:58:36 CET] <atomnuker> the dirac encoder I posted in the ML [14:02:56 CET] <durandal_1707> is there software that forbids RE in its EULA and uses ffmpeg? [14:17:08 CET] <cone-165> ffmpeg 03Michael Niedermayer 07master:6ba42b6482c7: avformat/hls: More strict url checks [14:17:39 CET] <nevcairiel> atomnuker: your DiracEncContext lacks an AVClass as the first member, maybe that causes it? [14:20:08 CET] <Daemon404> that would definitely cause it [14:26:00 CET] <kierank> durandal_1707: pretty much most software [14:35:48 CET] <atomnuker> nevcairiel: thanks, works now [14:36:29 CET] <Daemon404> kierank, which trumps which in the EU though [14:36:34 CET] <Daemon404> EULA vs RE for compat law [14:36:40 CET] <kierank> RE [14:36:44 CET] <Daemon404> figured [14:36:45 CET] <kierank> compat law iirc [14:36:52 CET] <nevcairiel> law > some random text some company writes [14:37:00 CET] <Daemon404> thats debatable in the usa [14:37:09 CET] <nevcairiel> thats because in the USA the companies make the law [14:57:59 CET] <kierank> J_Darnley: is there any reason why you can't add code for the 10-bit v210 path as well? [14:58:04 CET] <kierank> or is it sufficiently different [15:03:31 CET] <J_Darnley> To be honest: I didn't look at it. [15:04:02 CET] <J_Darnley> I guess it should be possible [15:04:35 CET] <J_Darnley> Once I groked the split lanes I just unrolled the loop using the high dqword [15:07:47 CET] <J_Darnley> Gramner: I need to ask you about the v210 checkasm test. Are you around? [15:29:25 CET] <gajjanag> all: some updates on fclose; the real reason that one checks fclose is that ferror does not set errno, and thus gives no info on cause of failure [15:30:27 CET] <gajjanag> if all one cares about is simply returning a failure code, it will be enough in the read-only case to check ferror [15:50:19 CET] <cone-165> ffmpeg 03Michael Niedermayer 07master:cfda1bea4c18: avformat/hls: Even stricter URL checks [16:01:23 CET] <gajjanag> michaelni: do you view this as sufficient justification to check fclose even in the read-only case? [16:11:35 CET] <michaelni> gajjanag, i need to make a few new relaeses due to that hls security bug, ill leave it to the other devels to review/comment on fclose [16:14:30 CET] <gajjanag> michaelni: ok, thanks. btw, no hurry at all, and I will be gone for 2 weeks, so feel free to comment later if you wish [16:23:15 CET] <durandal_1707> new A->V filter: abitscope [16:23:57 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:2f65366c112d: avformat/mov: Update handbrake_version threshold for full mp3 parsing [16:23:58 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:0a6324fe9315: swscale/utils: Fix intermediate format for cascaded alpha downscaling [16:23:59 CET] <cone-165> ffmpeg 03Andreas Cadhalpun 07release/2.8:83c0df90b0a0: mjpegdec: extend check for incompatible values of s->rgb and s->ls [16:24:00 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:709abc74f5ef: avcodec/put_bits: Always check buffer end before writing [16:24:01 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:14c63dc9b0d8: swscale/utils: Use normal bilinear scaler if fast cannot be used due to tiny dimensions [16:24:02 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:aee9aa92161f: avcodec/h264_slice: Fix integer overflow in implicit weight computation [16:24:03 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:6457cd17be8a: avcodec/motion_est: Fix mv_penalty table size [16:24:04 CET] <cone-165> ffmpeg 03Thomas Mundt 07release/2.8:3fb97a01ce74: avfilter/vf_scale: set proper out frame color range [16:24:05 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:36861557a7a6: avcodec/mpegvideo_enc: Clip bits_per_raw_sample within valid range [16:24:06 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:d79b6dd9f9f7: avformat/ivfenc: fix division by zero [16:24:07 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:cb4ba7456a79: avformat: Add integer fps from 31 to 60 to get_std_framerate() [16:24:08 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:df4ee166f1a3: avcodec/mss2: Check for repeat overflow [16:24:09 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:34e06ce309c9: avcodec/mjpegdec: Fix negative shift [16:24:10 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:9cad20822370: avcodec/g2meet: Check for ff_els_decode_bit() failure in epic_decode_run_length() [16:24:11 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:b8382a1faeb2: avcodec/dvdec: Fix "left shift of negative value -254" [16:24:12 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:e5567f2f6982: avcodec/aacdec_template: Check id_map [16:24:13 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:f05e0e76d657: avcodec/wavpackenc: Headers are per channel [16:24:14 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:d7f7586c3fcc: avcodec/wavpackenc: Check the number of channels [16:24:15 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:d408261b6514: avcodec/mpeg4video: Check time_incr [16:24:16 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:f459afdd7247: avformat/asfenc: Check pts [16:24:17 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:90c2256ee52c: avformat/aviobuf: Fix end check in put_str16() [16:24:18 CET] <cone-165> ffmpeg 03Maxim Andreev 07release/2.8:b7d54d6e0726: avformat/hls: forbid all protocols except http(s) & file [16:24:19 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:c781a1e14b68: swscale/yuv2rgb: Factor YUVRGB_TABLE_LUMA_HEADROOM out [16:24:20 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:1fd955606216: swscale/yuv2rgb: Increase YUV2RGB table headroom [16:24:21 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:cdac68fbab69: swscale/utils: Detect and skip unneeded sws_setColorspaceDetails() calls [16:24:22 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:be9b89314f32: swscale: Move VScalerContext into vscale.c [16:24:23 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:07da25548f79: swscale/vscale: Check that 2 tap filters are bilinear before using bilinear code [16:24:24 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:0c5a71fececb: avcodec/pngenc: Replace memcpy by av_image_copy() [16:24:25 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:4676e20a9da6: avcodec/pngenc: Fix mixed up linesizes [16:24:26 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:23b903aaf4ee: avformat/hls: More strict url checks [16:24:27 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:28f89bc439be: avformat/hls: Even stricter URL checks [16:28:12 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.8:e303ca3ac94f: Update for 2.8.5 [16:28:13 CET] <cone-165> ffmpeg 03James Almer 07release/2.8:063928910ff8: configure: bump copyright year to 2016 [16:36:57 CET] <gajjanag> durandal_1707: wip, or finished (can't see on ml)? [16:38:01 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:d41b91ba33a5: swscale/utils: Fix intermediate format for cascaded alpha downscaling [16:38:02 CET] <cone-165> ffmpeg 03Andreas Cadhalpun 07release/2.7:a7a7c6e44c40: mjpegdec: extend check for incompatible values of s->rgb and s->ls [16:38:03 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:b65c06ee5efe: avcodec/put_bits: Always check buffer end before writing [16:38:04 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:d7a13ff23b5e: swscale/utils: Use normal bilinear scaler if fast cannot be used due to tiny dimensions [16:38:05 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:5b14f436c635: avcodec/h264_slice: Fix integer overflow in implicit weight computation [16:38:06 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:2c58d734132f: avcodec/motion_est: Fix mv_penalty table size [16:38:07 CET] <cone-165> ffmpeg 03Thomas Mundt 07release/2.7:2f6d3459d908: avfilter/vf_scale: set proper out frame color range [16:38:08 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:3dd0d43d8cf7: avcodec/mpegvideo_enc: Clip bits_per_raw_sample within valid range [16:38:09 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:2316c3586591: avformat: Add integer fps from 31 to 60 to get_std_framerate() [16:38:10 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:8c08247990ca: avcodec/mss2: Check for repeat overflow [16:38:11 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:7cfea0d41cb0: avcodec/mjpegdec: Fix negative shift [16:38:12 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:3820c6a979ca: avcodec/dvdec: Fix "left shift of negative value -254" [16:38:13 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:d755045e7801: avcodec/aacdec_template: Check id_map [16:38:14 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:d0fd9bec1f8d: avcodec/wavpackenc: Headers are per channel [16:38:15 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:858f43043f74: avcodec/wavpackenc: Check the number of channels [16:38:16 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:0e3c36518d99: avcodec/mpeg4video: Check time_incr [16:38:17 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:f1cdd93517c8: avformat/asfenc: Check pts [16:38:18 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:a2b234b917bf: avformat/aviobuf: Fix end check in put_str16() [16:38:19 CET] <cone-165> ffmpeg 03Maxim Andreev 07release/2.7:cde38373d134: avformat/hls: forbid all protocols except http(s) & file [16:38:20 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:f5060bce3108: swscale/yuv2rgb: Factor YUVRGB_TABLE_LUMA_HEADROOM out [16:38:21 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:f0cc6f74fcfe: swscale/yuv2rgb: Increase YUV2RGB table headroom [16:38:22 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:119659b759a6: swscale/utils: Detect and skip unneeded sws_setColorspaceDetails() calls [16:38:23 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:123d356829d6: avformat/hls: More strict url checks [16:38:24 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:e681e92d2c8a: avformat/hls: Even stricter URL checks [16:38:25 CET] <cone-165> ffmpeg 03James Almer 07release/2.7:d4a7e8979338: configure: bump copyright year to 2016 [16:38:26 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.7:99f3f5a8d595: Update for 2.7.5 [16:39:31 CET] <Gramner> J_Darnley: I'm here now [16:40:00 CET] <J_Darnley> Ah [16:40:03 CET] <durandal_1707> gajjanag: just an idea [16:40:56 CET] <nevcairiel> durandal_1707: whats it do [16:42:00 CET] <J_Darnley> Gramner: I think I need to change the v210 test to allow testing different widths (xmm vs ymm) [16:42:26 CET] <J_Darnley> Is there another test you think I should look at copying? [16:44:09 CET] <durandal_1707> nevcairiel: displays what bits are used in audio [16:44:17 CET] <Gramner> I don't think there's anything that does that which you can copy [16:45:05 CET] <J_Darnley> okay [16:45:23 CET] <J_Darnley> I'll look in more detail later [16:46:14 CET] <gajjanag> durandal_1707: another filter idea, fir/convolve (http://manpages.ubuntu.com/manpages/natty/man1/sox.1.html) I needed this once for a project [16:50:47 CET] <Daemon404> how is it that this hls thing is 'vuln', but a dref box in a mp4/mov file can happily open a relative path? [16:51:03 CET] <michaelni> atomnuker, aac-pns-encode test fails on 32bit bsd http://fate.ffmpeg.org/report.cgi?time=20160115044841&slot=x86_32-debian-kf… [16:51:48 CET] <michaelni> seems also happening on some linux boxes [16:52:33 CET] <kierank> Daemon404: nobody reported it yet [16:52:48 CET] <Daemon404> harr harr [16:53:14 CET] <JEEB> lol [16:53:30 CET] <atomnuker> damn, the deviation is 98 [16:53:40 CET] <gajjanag> Daemon404: noob q, what is a dref box [16:54:15 CET] <JEEB> reference to another sample basically [16:54:19 CET] <JEEB> (in another file or otherwise) [16:54:32 CET] <JEEB> it's what the segment linking in matroska got its ideas off of [16:54:37 CET] <Daemon404> gajjanag, 'box' is a term from the isobmff (mp4) spec [16:54:43 CET] <Daemon404> it's a tag/structure [16:54:52 CET] <Daemon404> a dref box can reference external tracks [16:55:00 CET] <Daemon404> it's common for NLE software. [16:55:14 CET] <Daemon404> JEEB, matroska is much less powerful [16:55:22 CET] <Daemon404> i dont think it can do it per-track [16:55:24 CET] <Daemon404> only full file [16:55:46 CET] <cone-165> ffmpeg 03Michael Niedermayer 07master:48f5244df7ea: avfilter/vaf_spectrumsynth: Fix mixed declaration and statment [16:56:12 CET] <RiCON> (and the files need to have the same tracks) [16:56:26 CET] <nevcairiel> yeah matroska is just time-based slicing [16:56:37 CET] <Daemon404> RiCON, and even then it is iffy [16:56:43 CET] <Daemon404> i rememebr problems with flac [16:56:54 CET] <gajjanag> Daemon404: so the problem is that it can reference an arbitrary external track? [16:57:15 CET] <Daemon404> we have checks to disallow 1) absolute paths 2) differing origins [16:57:21 CET] <Daemon404> but we happily allow relative local paths [16:57:43 CET] <Daemon404> (i think this appleus to http too when opening the master mp4 over http) [16:58:04 CET] <gajjanag> Daemon404: ok, so in your opinion what is the set of paths we should allow? [16:58:12 CET] <Daemon404> by default? none. [16:58:14 CET] <JEEB> Daemon404: yeah, matroska just has you setting segment UUIDs per timeline [16:58:44 CET] <Daemon404> gajjanag, my point was more that the "security researcher" field can be kind of a cricle jerk. [16:58:53 CET] <JEEB> RiCON: in theory it's not limited ('cause it's not specified, d'uh). but in practice DShow stuff was quite picky :D [16:58:57 CET] <Daemon404> like this hls 'vuln' [16:59:21 CET] <gajjanag> Daemon404: I do agree, I was just trying to understand this a bit better [16:59:23 CET] <JEEB> <@Daemon404> i rememebr problems with flac <- audio frames not matching on the exact timestamps of the segments [16:59:44 CET] <JEEB> so audio would leak from "other side" of the link [17:00:03 CET] <JEEB> <pre-OP><linked OP><loud bang right in the beginning> [17:00:13 CET] <JEEB> the bang could be heard if the audio frames didn't match [17:00:19 CET] <Daemon404> JEEB, sounds like current problems when segmenting for dash :P [17:00:24 CET] <JEEB> :D [17:00:25 CET] <Daemon404> except browsers will just stop playing [17:00:29 CET] <Daemon404> depending on the vedor [17:00:38 CET] <JEEB> DASH is a fucking piece of shit implementation wise [17:00:48 CET] <Daemon404> only on client side [17:00:52 CET] <JEEB> yes [17:00:55 CET] <JEEB> muxing is OK [17:01:00 CET] <Daemon404> and only because everyone just implements youtubes subset [17:01:04 CET] <Daemon404> and bugs [17:01:23 CET] <JEEB> yes, and then people just say "well I didn't try to create files that would break things" [17:01:26 CET] <JEEB> and I go :V [17:01:35 CET] <JEEB> as if I'm *trying* to create files that break things [17:02:27 CET] <Daemon404> i see you arr familiar with the broadcast vendor industry [17:02:29 CET] <Daemon404> are* [17:03:53 CET] <JEEB> also I'm an asshole that doesn't accept a multimedia workaround as a "fix", it's not "fixed" I just made something a bit more retarded to make it work [17:08:15 CET] <gajjanag> JEEB,Daemon404: I have seen this many times, and would like an insider opinion as to why multimedia is so broken [17:08:48 CET] <Daemon404> it's an incredibly vast thing to say "multimedia is broken" [17:08:53 CET] <Daemon404> you are going to have to be more specific. [17:09:12 CET] <Daemon404> (also i dont agree with the sweeping generalization) [17:18:57 CET] <gajjanag> Daemon404: I guess it is really how one views things, at some level, yes, one can play stuff, but there are many things that don't make sense [17:18:59 CET] <gajjanag> https://www.youtube.com/watch?v=NoWV2JdoNnc [17:19:40 CET] <Daemon404> im not going to watch a 44 minute video to discene somethign specific you mean [17:20:55 CET] <gajjanag> Daemon404: not referring to anything in particular, but see minute 13 or so [17:21:28 CET] <cone-165> ffmpeg 03Michael Niedermayer 07master:da6f34516b60: avcodec/x86/fmtconvert: Add emms to int32_to_float_fmul_array8_sse() [17:21:28 CET] <Daemon404> heh [17:21:45 CET] <Daemon404> the bits at 13 minutes can be appleid to almost any industry [17:21:50 CET] <Daemon404> it's not unique to multimedia. [17:26:36 CET] <gajjanag> Daemon404: ok, you see the problem for me is that this my first semi-serious software work, I have been kept insulated from most of the industry ;) [17:27:29 CET] <gajjanag> Daemon404: maybe 2 years from now I will see similar things in academia, who knows [17:27:38 CET] <Daemon404> academia has a different set of problems [17:27:50 CET] <Daemon404> namely being 90% politics, and living in a bubble [17:28:24 CET] <Daemon404> (and also no journals requrie cod to be checked/published) [17:30:29 CET] <gajjanag> Daemon404: http://reproducibility.cs.arizona.edu/v2/index.html, something I saw a while back [17:31:15 CET] <Daemon404> yeah ive seen it [17:31:46 CET] <Daemon404> i'd also note i tend to see a lot more interesting papers (IM) come out of R&D (ms research etc) thna most universities (with a few exceptions) [17:31:51 CET] <Daemon404> s/IM/IMO/ [17:32:29 CET] Action: Daemon404 should go see if anything good has been published lately [17:34:29 CET] <Daemon404> anyone opposed to a patch to disable all dref opening [17:34:39 CET] <Daemon404> teh default state can be up for debate, of course. [17:37:19 CET] <gajjanag> Daemon404: can you outline any possibly legit use cases of dref opening [17:37:51 CET] <Daemon404> yes [17:37:53 CET] <Daemon404> NLEs use it [17:37:57 CET] <Daemon404> to avoid remuxing 400gb files [17:38:04 CET] <Daemon404> same reason NLEs use edit lists [17:38:11 CET] <Daemon404> (which we dont properly support) [17:39:24 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:bb70069e6a5c: swscale/utils: Fix intermediate format for cascaded alpha downscaling [17:39:25 CET] <cone-165> ffmpeg 03Andreas Cadhalpun 07release/2.6:a5fb5a18e3e2: mjpegdec: extend check for incompatible values of s->rgb and s->ls [17:39:26 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:9c4d8343bb30: avcodec/put_bits: Always check buffer end before writing [17:39:27 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:dbe194002a79: swscale/utils: Use normal bilinear scaler if fast cannot be used due to tiny dimensions [17:39:28 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:85732714ce94: avcodec/h264_slice: Fix integer overflow in implicit weight computation [17:39:29 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:f3cf94fa47d1: avcodec/motion_est: Fix mv_penalty table size [17:39:30 CET] <cone-165> ffmpeg 03Thomas Mundt 07release/2.6:482ca8241d77: avfilter/vf_scale: set proper out frame color range [17:39:31 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:81bac54ab3cd: avcodec/mpegvideo_enc: Clip bits_per_raw_sample within valid range [17:39:32 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:c0315b74e256: avformat: Add integer fps from 31 to 60 to get_std_framerate() [17:39:33 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:aa5ae8b2136f: avcodec/mss2: Check for repeat overflow [17:39:34 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:bb1263185b60: avcodec/mjpegdec: Fix negative shift [17:39:35 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:526b5facc59e: avcodec/dvdec: Fix "left shift of negative value -254" [17:39:36 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:60956a9dc862: avcodec/wavpackenc: Headers are per channel [17:39:37 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:6d483543217f: avcodec/wavpackenc: Check the number of channels [17:39:38 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:9b8d1a183d46: avcodec/mpeg4video: Check time_incr [17:39:39 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:fbfef00e6883: avformat/asfenc: Check pts [17:39:40 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:6d5fca34a629: avformat/aviobuf: Fix end check in put_str16() [17:39:41 CET] <cone-165> ffmpeg 03Maxim Andreev 07release/2.6:8b93f6676b89: avformat/hls: forbid all protocols except http(s) & file [17:39:42 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:4bafd677953f: swscale/yuv2rgb: Factor YUVRGB_TABLE_LUMA_HEADROOM out [17:39:43 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:1ba90ce49e27: swscale/yuv2rgb: Increase YUV2RGB table headroom [17:39:44 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:f0b6705e1a76: swscale/utils: Detect and skip unneeded sws_setColorspaceDetails() calls [17:39:45 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:232c2ed4a4a5: avformat/hls: More strict url checks [17:39:46 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:82db8bcffae0: avformat/hls: Even stricter URL checks [17:39:47 CET] <cone-165> ffmpeg 03James Almer 07release/2.6:80fc1f3399f1: configure: bump copyright year to 2016 [17:39:48 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.6:3fd30f53a99e: Update for 2.6.7 [17:41:13 CET] <gajjanag> Daemon404: ok, so in such cases is there typically any relation typically between the paths that may be used to think of a good default? [17:41:31 CET] <Daemon404> im not sure what you mean [17:41:48 CET] <gajjanag> like, e.g same directory, or something like that [17:42:14 CET] <Daemon404> it's already restriected to relative paths and same origin by default [17:42:17 CET] <J_Darnley> kierank: FYI I have the 10-bit v210 asm working. I'll get it into a patch after dinner. [17:42:18 CET] <Daemon404> absolute paths are opt-in [17:43:28 CET] <wm4> relative paths including .. ? [17:43:44 CET] <Daemon404> ? [17:44:38 CET] <wm4> <Daemon404> it's already restriected to relative paths and same origin by default [17:44:57 CET] <gajjanag> Daemon404: how about something like concat, i.e have a safemode flag [17:45:00 CET] <wm4> "relative paths" doesn't sound very safe [17:45:24 CET] <Daemon404> master.mov may open subdir/slave.mov [17:51:18 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:5d865cb375c4: avutil/mathematics: Fix division by 0 [17:51:19 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:65e7ad746fab: avformat/matroskaenc: Check codecdelay before use [17:51:20 CET] <cone-165> ffmpeg 03Rainer Hochecker 07release/2.5:50aacb334a34: avformat/utils: estimate_timings_from_pts - increase retry counter, fixes invalid duration for ts files with hevc codec [17:51:21 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:07b96325311b: avformat/mxfenc: Do not crash if there is no packet in the first stream [17:51:22 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:75e4949ec128: avfilter/vf_mpdecimate: Add missing emms_c() [17:51:23 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:a5b4b807757f: avcodec/h264_refs: Fix long_idx check [17:51:24 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:c1521dd418db: swscale/utils: Fix intermediate format for cascaded alpha downscaling [17:51:25 CET] <cone-165> ffmpeg 03Andreas Cadhalpun 07release/2.5:f48392197d36: mjpegdec: extend check for incompatible values of s->rgb and s->ls [17:51:26 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:1363d0759df3: avcodec/put_bits: Always check buffer end before writing [17:51:28 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:c3abdd0f4461: swscale/utils: Use normal bilinear scaler if fast cannot be used due to tiny dimensions [17:51:28 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:d472b83abc76: avcodec/h264_slice: Fix integer overflow in implicit weight computation [17:51:29 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:1b3dffc0c7ff: avcodec/motion_est: Fix mv_penalty table size [17:51:30 CET] <cone-165> ffmpeg 03Thomas Mundt 07release/2.5:53025e8681c1: avfilter/vf_scale: set proper out frame color range [17:51:31 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:2111d5161926: avcodec/mpegvideo_enc: Clip bits_per_raw_sample within valid range [17:51:32 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:7974642cfd60: avformat: Add integer fps from 31 to 60 to get_std_framerate() [17:51:33 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:4c6b48a08e5a: avcodec/mss2: Check for repeat overflow [17:51:34 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:e2285e7cc83f: avcodec/mjpegdec: Fix negative shift [17:51:35 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:1d02458c0672: avcodec/dvdec: Fix "left shift of negative value -254" [17:51:36 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:71b640230ec8: avcodec/wavpackenc: Headers are per channel [17:51:37 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:4865d66b76f7: avcodec/wavpackenc: Check the number of channels [17:51:39 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:1c99807cb704: avcodec/mpeg4video: Check time_incr [17:51:39 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:8419971a42a8: avformat/asfenc: Check pts [17:51:40 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:a7dea6f2cdce: avformat/aviobuf: Fix end check in put_str16() [17:51:41 CET] <cone-165> ffmpeg 03Maxim Andreev 07release/2.5:e183075dc11b: avformat/hls: forbid all protocols except http(s) & file [17:51:42 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:9c67c52acc94: swscale/yuv2rgb: Factor YUVRGB_TABLE_LUMA_HEADROOM out [17:51:43 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:dc6a9162a2d2: swscale/yuv2rgb: Increase YUV2RGB table headroom [17:51:45 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:4089af67ab93: swscale/utils: Detect and skip unneeded sws_setColorspaceDetails() calls [17:51:45 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:8d5060192cf2: avformat/hls: More strict url checks [17:51:46 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:83913c6e7e1e: avformat/hls: Even stricter URL checks [17:51:47 CET] <cone-165> ffmpeg 03James Almer 07release/2.5:6456043ff76e: configure: bump copyright year to 2016 [17:51:48 CET] <cone-165> ffmpeg 03Michael Niedermayer 07release/2.5:fba2fdaea32e: Update for 2.5.10 [17:58:45 CET] <cone-165> ffmpeg 03James Almer 07release/2.8:b8fa3ff95d88: avcodec/wavpackenc: print channel count in av_log call [18:06:40 CET] <cone-165> ffmpeg 03Michael Niedermayer 07n2.8.5:HEAD: avcodec/x86/fmtconvert: Add emms to int32_to_float_fmul_array8_sse() [18:11:54 CET] <cone-165> ffmpeg 03James Almer 07master:36778627e249: x86/intmath: add missing early clobber to output operands [18:23:50 CET] <cone-165> ffmpeg 03James Almer 07release/2.5:7e297b4bc6af: avcodec/wavpackenc: print channel count in av_log call [18:23:51 CET] <cone-165> ffmpeg 03James Almer 07release/2.6:b901d1bbc9a0: avcodec/wavpackenc: print channel count in av_log call [18:23:52 CET] <cone-165> ffmpeg 03James Almer 07release/2.7:a697577a641d: avcodec/wavpackenc: print channel count in av_log call [18:33:11 CET] <J_Darnley> Dammit Telenet. Are you going to disconnect me again? [18:35:24 CET] <cone-165> ffmpeg 03James Almer 07n2.7.5:HEAD: x86/intmath: add missing early clobber to output operands [18:35:25 CET] <cone-165> ffmpeg 03James Almer 07origin/release/2.7:HEAD: x86/intmath: add missing early clobber to output operands [18:53:32 CET] <jamrial> http://pastebin.com/cYRAseHb [18:54:15 CET] <jamrial> happens with mingw-w64 x86_32. can someone confirm it's not just me, and/or also test on linux x86_32? [18:55:34 CET] <nevcairiel> that happened to me randomly/rarely, well not sure if that specifically, but sometimes float dsp test would fail and re-run would fix it [18:55:55 CET] <nevcairiel> maybe you should checkasm it to make sure its all behaving ;) [18:57:15 CET] <jamrial> it's that seed value specifically [18:57:35 CET] <Daemon404> could it be some derpy driver changing teh fp state? [18:57:45 CET] <Daemon404> oh, ok [19:02:18 CET] <jamrial> happens only if i use the sse2 or avx optimized versions of vector_dmul_scalar. It goes away if i force cpuflags to 0 [19:02:27 CET] <jamrial> mingw-w64 x86_64 is fine [19:04:04 CET] <kierank> av_packet_from_data is insane [19:04:37 CET] <kierank> forces you to use av_malloc and av_free [19:11:45 CET] <Daemon404> kierank, it's expect though [19:11:49 CET] <cone-165> ffmpeg 03Paul B Mahol 07master:7d76294ce006: avfilter: add ahistogram multimedia filter [19:11:54 CET] <Daemon404> it is to be consumed nternally [19:11:55 CET] <kierank> but what if my memory is from elsewhere [19:12:05 CET] <kierank> I want to output to hardware or whatever [19:12:18 CET] <kierank> bit hypothetical but it exists these days with kernel bypass [19:12:30 CET] <Daemon404> sounds niche? [19:12:46 CET] <Daemon404> presumably the internal code needs the properties av_malloc can guarantee [19:12:57 CET] <kierank> if so then ok [19:13:27 CET] <Daemon404> that said, retty sure you can override av_mallocs implemention in configure [19:13:31 CET] <Daemon404> pretty* [19:13:37 CET] <Daemon404> gl;hf though [19:13:42 CET] <kierank> well the point is to output to my own memory [19:13:44 CET] <kierank> not to change malloc [19:14:11 CET] <Daemon404> output what? encoded packets? [19:15:03 CET] <kierank> yes [19:15:17 CET] <Daemon404> inside libav*? [19:15:21 CET] <kierank> a lot of our encoded packets have a higher bitrate than some people's raw frames [19:15:23 CET] <Daemon404> or to feed to libav* [19:15:32 CET] <kierank> frame -> dirac -> avpkt [19:15:56 CET] <Daemon404> im struggling to figure out if you want to call the func internally or from user code [19:16:01 CET] <Daemon404> and why it needs to be an avpacket at all [19:16:14 CET] <kierank> I need to encode to dirac so i get an avpacket out [19:16:27 CET] <kierank> I want it in my own memory though so I use av_packet_from_data [19:16:55 CET] <Daemon404> does get_buffer2 not work for encoders? [19:16:58 CET] Action: Daemon404 checks [19:17:11 CET] <kierank> no ff_alloc_packet(2) [19:18:00 CET] <Daemon404> hmm yea [19:18:16 CET] <Daemon404> maybe it can be extended to use such a callback [19:18:22 CET] <Daemon404> i dont know how nutty it is or not [19:18:26 CET] <Daemon404> and what SIMD will break [19:24:43 CET] <wm4> don't packets need to be allocated with padding? not sure if that applies to output [19:25:46 CET] <cone-165> ffmpeg 03Piotr Bandurski 07master:23ac355487e7: avformat/riff: add YUYV FourCC (Drastic YUYV) [19:25:47 CET] <cone-165> ffmpeg 03Piotr Bandurski 07master:eded2e4fac98: avformat/riff: add C210 FourCC (Canopus C210) [19:25:52 CET] <Daemon404> wm4, sure but you have to do that anywya [19:25:55 CET] <Daemon404> its documented as such [19:26:02 CET] <Daemon404> av_malloc doesnt automagically do it [19:29:19 CET] <wm4> yeah [19:29:51 CET] <wm4> (which I find strange... why doesn't ffmpeg just use standard malloc, and then some sort of aligned-and-padded malloc alternative) [20:06:17 CET] <jamrial> can somebody confirm if that seed fails for you as well? the issue appears to be in compare_doubles(), where the check apparently can't handle the values generated by lfg with that seed [20:09:51 CET] <J_Darnley> What system did you want checked? [20:11:35 CET] <jamrial> it fails for me using mingw-w64 x86_32. it would be nice to check that and also linux x86_32 [20:12:09 CET] <J_Darnley> curses I need to reconfig [20:13:29 CET] <J_Darnley> FYI it works fine on linux64 [20:17:12 CET] <J_Darnley> odd [20:17:59 CET] <J_Darnley> Fails for me too [20:18:48 CET] <J_Darnley> Same error as yours [20:18:56 CET] <jamrial> what system? [20:19:55 CET] <J_Darnley> Windows 7 64-bit, i686-w64-mingw32, run through cygwin64 [20:20:05 CET] <jamrial> ok [20:20:37 CET] <jamrial> does this patch fixes it without breaking every other float_dsp test for you? http://pastebin.com/cDEQREzN [20:21:17 CET] <J_Darnley> What!? I don't have d2u installed? [20:23:40 CET] <J_Darnley> That did fix that test. How do I run "other tests"? [20:24:38 CET] <J_Darnley> Other runs without the seed work [20:25:26 CET] <jamrial> float_dsp-test runs a lot of tests. if you didn't get any new error then they are all fine [20:25:41 CET] <J_Darnley> I did not get any errors [20:26:33 CET] <J_Darnley> kierank: I sent 10-bit v210 asm to the list [20:28:23 CET] <kierank> Can you send to libav if possible [20:28:48 CET] <J_Darnley> Now, or would you like me to wait for comments? [20:29:22 CET] <kierank> Now please [20:33:45 CET] <jamrial> anyway, i'm not sure if that new check is truly correct. for all i know it may fail with other seed values [20:35:43 CET] <J_Darnley> kierank: done, you may need to tell them to check their moderation log [20:36:07 CET] <kierank> Thanks [20:36:31 CET] <J_Darnley> (yes, there are the "awaiting moderation" replies) [20:45:35 CET] <jamrial> or maybe http://pastebin.com/n8p18db5 [20:46:51 CET] <J_Darnley> That also works [20:48:19 CET] <jamrial> if someone that actually knows that they are doing wants to try to fix this themselves, or confirm that's a good fix, then that'd be great [20:48:33 CET] <jamrial> in any case it's not really important, i guess. it's just a test that fails with some specific seed values [20:51:19 CET] <BtbN> I wonder how long it'll take the ML-Server to notice that my servers IP changed. And then it will unload a bunch of mails in my direction... [21:19:01 CET] <Compn> do you need me to fix any queued mails ? what ml if so [21:19:23 CET] <Compn> oh thats libav ml, nevermind then [21:47:32 CET] <J_Darnley> Compn: yes, sorry about the confusion [21:51:18 CET] <cone-165> ffmpeg 03Paul B Mahol 07master:d4ce63a1bf25: avfilter/af_sidechaincompress & af_agate: use audio fifo from lavu [21:52:21 CET] <BtbN> Compn, I just got myself a new server, so all my domains got a new IP. The ffmpeg-devel and ffmpeg-user inboxes are suspiciously quiet now. [21:56:04 CET] <kylophone> I'm finishing up an audio filter that needs to upsample to 192kHz and then back down to the original sample rate. [21:56:13 CET] <kylophone> Wondering if I can set that in query_formats() [21:57:08 CET] <durandal_1707> no, it would upsample but no downsample [21:57:16 CET] <kylophone> or is it better to handle the upsampling > downsampling internally with libswresample? [21:57:59 CET] <wm4> why does it need to downsample back to original rate? [21:58:13 CET] <durandal_1707> depends how you want filter is used [21:58:50 CET] <durandal_1707> 192000 is for audiophiles? :P [21:59:51 CET] <kylophone> The broadcast spec for a "true-peak" limiter says to upsample to 192 [22:01:23 CET] <kylophone> I tried libswresample, but ended up with a 16 sample delay in my buffer [22:01:44 CET] <kylophone> which is annoying to deal with [22:03:29 CET] <durandal_1707> delay is going to be there anyway [22:19:18 CET] <klue> What versions does the recent ffmpeg vulnerabiliy affect? (The one that provides SSRF, local file reads, etc) [22:20:00 CET] <BtbN> ok, the ml found my new IP now [22:22:15 CET] <gajjanag> jamrial: is v3 of fma ok? [22:24:52 CET] <Compn> klue : got a link to the cve ? [22:25:46 CET] <J_Darnley> I think he means that overblown hls+concat issue from yesterday [22:26:08 CET] <jamrial> gajjanag: the new assembly looks correct, so assuming that difference in the output is ok, then yes [22:27:11 CET] <gajjanag> jamrial: difference seemed fine, it was just some +/- 0 and nan shifting thing [22:27:14 CET] <klue> Compn: J_Darnley: I do not know the CVE. And yes, that one. [22:27:22 CET] <kylophone> I'm assuming this is normal for libswresample: http://i.imgur.com/Yy89i7E.png [22:27:37 CET] <kylophone> the front of the buffer gets filled with zeros [22:28:05 CET] <kylophone> and the rest of the buffer is delayed by a certain amount [22:28:16 CET] <mark4o> CVE-2016-1897 and CVE-2016-1898 http://seclists.org/oss-sec/2016/q1/91 [22:28:46 CET] <kylophone> Second frame starts at 0.1 in that image [22:28:58 CET] <klue> mark4o: Thanks! [22:31:53 CET] <Compn> lol [22:32:01 CET] <Compn> yes, thats how concat works [22:32:13 CET] <Compn> you specify local file and encode it to wherever, in this case, http server. [22:32:35 CET] <Compn> its like issuing a cve "i emailed my passwords.txt file to bill gates. its all thunderbirds' fault" [22:33:13 CET] <wm4> no it's not [22:33:35 CET] <JEEB> oh right [22:33:40 CET] <JEEB> playlists to playlists [22:33:40 CET] <Compn> put ffmpeg in applications group and dont give it permission to /etc/ [22:33:43 CET] <cone-165> ffmpeg 03Paul B Mahol 07n2.6.7:HEAD: avfilter/af_sidechaincompress & af_agate: use audio fifo from lavu [22:33:57 CET] <JEEB> but still, lol [22:34:29 CET] <JEEB> sure tho, it's a bug [22:34:30 CET] <Compn> i like the other claim too. "rename playlist as avi and ffmpeg still knows its a playlist" ... should this be a bug or feature ? [22:34:59 CET] <wm4> surely you know ffmpeg probes files by content and not by file extensions [22:35:10 CET] <Compn> wm4 : http://seclists.org/oss-sec/2016/q1/85 [22:35:15 CET] <Compn> did you read it? [22:35:24 CET] <J_Darnley> Not on one thread I read. People were debating that. [22:36:03 CET] <gajjanag> wm4: so the fundamental reason why fclose needs to be checked is _only_ for diagnostics; else ferror suffices for the read only case [22:36:20 CET] <wm4> not that again [22:36:22 CET] <Compn> i'm surprised the guy didnt include the option to convert /etc/passwords to video using the text decoder and then upload to http://... [22:36:56 CET] <Compn> erm /etc/passwd [22:37:00 CET] Action: Compn lols [22:37:55 CET] <mark4o> Compn: hls doesn't have a way to specify filters for the urls in the playlist [22:37:57 CET] <Compn> (note to anyone reading this irc in archives, i do not speak for ffmpeg security or the project. i'm just a guy) [22:39:48 CET] <Compn> yeah, probably hls shouldnt be using concat... [22:39:51 CET] <Compn> ehe [22:39:56 CET] <Compn> although it is interesting feature. [22:42:43 CET] <gajjanag> all: what is the policy in situations like this, where wm4 seems to refuse to discuss the issue [22:47:06 CET] <cone-165> ffmpeg 03Ganesh Ajjanagadde 07master:5989add4ab4e: lavu/x86/lls: add fma3 optimizations for update_lls [23:11:14 CET] <gajjanag> all: random, minor stuff has been pushed to https://github.com/gajjanag. clear wip stuff has been marked at the tip of my master, rest are things I am ok with [00:00:00 CET] --- Sat Jan 16 2016

1 0

ffmpeg.log.20160115
by burek 16 Jan '16

16 Jan '16

[00:03:11 CET] <furq> ok apparently bilinear filtering on a prescaled screen looks much better [00:03:19 CET] <furq> http://i.imgur.com/vRCrnUM.png [00:03:24 CET] <furq> so thanks for that inadvertent tip if nothing else [00:06:50 CET] <furq> i'll be sure to keep you all up to date with all the latest developments on what filters i use to play neo-geo games [01:43:57 CET] <genii> Hi. I can't figure out why one video plays properly (exiftool results for that one http://paste.ubuntu.com/14500184/ ) and the other doesn't ( exiftool results for that one: http://paste.ubuntu.com/14500181/ ) Could it be Major Brand : MP4 Base Media v1 [IS0 14496-12:2003] versus Major Brand : MP4 v2 [ISO 14496-14] ? If so can I get it to encode to that version, I already tried -level 4.2 option [01:48:29 CET] <genii> The format is side-by-side left view first ( 3D ) [01:49:01 CET] <Guest83269> why don't you add a progress bar in your ffmpeg ? its 2016 and no native progress bar [01:50:09 CET] <Guest83269> also why dont you add a basic basic encoding queue system inside ffmpeg [02:49:01 CET] <llogan> patch welcome, anonymous complainer who isn't here anymore. [02:49:58 CET] <llogan> genii: play in what? are you using ffmpeg? [02:51:30 CET] <ac_slater> hey all. I'm writing an encoder and I cant figure out how to use the "b" (bitrate) option. When I do `-b:v myCodec` via the ffmpeg binary, how does this make it to my codec and how to I get the value? [02:52:19 CET] <ac_slater> s/myCodec/500 or some number [02:56:20 CET] <waressearcher2> ac_slater: hallo und herzlich willkommen [02:57:07 CET] <ac_slater> waressearcher2: thanks mate [02:57:31 CET] <ac_slater> I figured my issue out. '-b:v' makes its way into AVCodecContext.bit_Rate [02:57:35 CET] <ac_slater> bit_rate * [03:07:11 CET] <k_sze[work]> Hello. [03:07:31 CET] <k_sze[work]> Just me or by video frames are refcounted when decoding FFV1 level 3? [03:07:45 CET] <k_sze[work]> *by default [04:29:19 CET] <hayatae> Hey guys, I'm looking at the exact same problem as this: https://lists.libav.org/pipermail/ffmpeg-user/2010-September/027126.html [04:29:32 CET] <hayatae> Doesn't look like an answer was ever posted. Does anyone here have any ideas? [04:44:25 CET] <waressearcher2> hayatae: hallo und herzlich willkommen [04:48:00 CET] <hayatae> hej, tak [06:40:34 CET] <ac_slater> hey guys. I have a frame of video in a AVFrame. To pass it to my encoder, I need to copy the data to an AVPacket. My pixel data is YUV420P. My AVPackets are just green. This probably has to do with copying the planes. Clues? [06:53:17 CET] <waressearcher2> ac_slater: hallo und herzlich willkommen [07:01:33 CET] <ac_slater> /quit [07:03:50 CET] <Jetfantastic> Hi, I was very recently (like 5 minutes ago) recommended ffmpeg because I needed an easy way to convert multiple files from h.265 to h.264 at the same time, specifically because my bluray player doesn't support h.265. How would I convert a folder of h.265 mkv files into h.264 mp4 files? [07:09:18 CET] <douglasbay> How can I tell if the I frame in my video is an IDR frame, through ffprobe? [07:10:23 CET] <xintox> what's a good HLS player for web [07:10:43 CET] <xintox> also looking for a desktop player that can open multiple instances simultaneously. [07:11:05 CET] <xintox> i've been usign clappr but its really sluggish [07:11:12 CET] <xintox> and vlc only lets me open one instance [07:46:51 CET] <Jetfantastic> Hi, I was very recently (like 5 minutes ago) recommended ffmpeg because I needed an easy way to convert multiple files from h.265 to h.264 at the same time, specifically because my bluray player doesn't support h.265. How would I convert a folder of h.265 mkv files into h.264 mp4 files? [07:54:13 CET] <Betablocker> hello world ! [07:55:15 CET] <Jetfantastic> Does anyone use this program and know how to convert many files at once? [07:59:23 CET] <relaxed> Jetfantastic: you can write a script to do it [07:59:39 CET] <Jetfantastic> How would I do that [08:00:10 CET] <Jetfantastic> I just got recommended the program and there seems to be no guide for the inexperiences [08:00:16 CET] <Jetfantastic> *Inexperiences [08:00:18 CET] <relaxed> Which OS? [08:00:23 CET] <Jetfantastic> Win10 [08:00:42 CET] <Jetfantastic> 64bit [08:01:37 CET] <relaxed> I don't know how to script for windows, but google should give you plenty of examples. Google: windows ffmpeg for loop [08:02:09 CET] <Jetfantastic> I just wanted to watch Rick and Morty on my Bluray Player :( [08:05:21 CET] <relaxed> if it's a smart bluray player then it might read whatever have off a disc [08:06:11 CET] <Jetfantastic> Nah, It doesn't read h.265 or mkv [08:06:17 CET] <Jetfantastic> for whatever reason [08:06:49 CET] <Jetfantastic> I might just do it on my TV through PLEX [08:09:46 CET] <chungy> in bash you'd do: for file in *.mkv; do ffmpeg -i "$file" -c:a copy -c:v h264 "$(basename "$file" .mkv).mp4"; done [08:09:55 CET] <chungy> I have no clue about cmd/powershell myself either [08:11:41 CET] <chungy> you can actually install bash on Windows via Cygwin, that's what I'd do, but it's probably a heavyweight solution [11:03:21 CET] <EvilDin> hi, I have source video which ffprobe says it has length 11.99s, then I transcode that high quality video to lower quality, when I checked transcoded file with ffprobe I got length 12,03s, 40ms more then original. We have web player which detects video length and it is weird that when you switch quality video length is changed. Is there anyway how could I transocde that this would not happen? [11:21:57 CET] <waressearcher2> EvilDin: hallo und herzlich willkommen [12:24:42 CET] <Fyr> guys, how to scale down volume since 34:02 to 38:42 of a WAV? [12:30:46 CET] <waressearcher2> -af volume=volume=-20dB:precision=fixed ? [12:31:19 CET] <Fyr> for the whole file? [12:39:37 CET] <Fyr> is it possible to split frequencies and scale down only high ones? [13:08:35 CET] <durandal_1707> Fyr: that's called equalizer [13:09:35 CET] <durandal_1707> and high one can be removed with lowpass filter too [13:18:38 CET] <Fyr> durandal_1707, thanks for the idea. is there a way to draw a curve to decrease some frequencies while keeping the others? [13:20:23 CET] <durandal_1707> Fyr: drawing by hand - no, but anequalizer can draw curves from params you set [13:24:20 CET] <Nanabot> ffmpeg -loop 1 -i img.png -i audio.mp3 -c:a copy -shortest out.mp4 [13:24:51 CET] <Nanabot> This works for making a music video with a static image, but I noticed it added 4 seconds of silence to the end of my video... [13:25:38 CET] <waressearcher2> Nanabot: -shortest [13:26:17 CET] <Nanabot> err yeah I had that -r 1 -shortest output.mp4 [13:26:31 CET] <waressearcher2> -t length-4 [13:29:03 CET] <Nanabot> I noticed that removing -r 1 (thus default framerate 25) makes the duration normal [13:29:49 CET] <Nanabot> ah thanks, -t (actual song length) works [14:01:42 CET] <Nanabot> Is there a flag I can add so the colors aren't shifted? I noticed the colors are off. [14:51:29 CET] <Nanabot> Oh, it was just my video player being idiotic. -pix_fmt yuv420p (encoding png to h264) [14:52:27 CET] <Nanabot> It didn't show any difference until I switched player. [14:56:24 CET] <Nanabot> I spent too long to figure that out. [16:40:47 CET] <Prelude2004c> hey guys.. good day.. anyone know how with ffmpeg i can set the version to 2 for HLS .. i think right now default is hls version 3 [16:41:50 CET] <JEEB> I'm really sorry if you're having to support something that only supports that :P [16:41:58 CET] <Betablocker> lol [16:44:15 CET] <Neon> I'm trying to mix 10 audio files using ffmpeg and after a while it fails with the message Error while filtering: Cannot allocate memory. I'm using a command like: ffmpeg -i file1 -i file2 ... -filter_complex amix=inputs=10,volume=10 -c aac mixdown.aac. Any idea how I can fix this problem? [16:46:14 CET] <durandal_1707> try amerge filter [16:46:19 CET] <Neon> Damn, it fails after mixing 1:29:54.21 h and the longest input file has 1:30:01 h... Coincidence? [16:49:03 CET] <Neon> [aac @ 0000000002d696a0] Unsupported number of channels: 10 [16:49:50 CET] <Neon> When I try to use amerge. I've already mixed another set of files and it went well. I used amix for them, because amerge gave me that error. [16:59:23 CET] <Neon> Trying amerge with libvorbis now. [17:04:24 CET] <durandal_1707> Neon: what version you use? [17:04:44 CET] <durandal_1707> the limit is 64 here [17:06:33 CET] <Neon> durandal_1707: [17:06:34 CET] <Neon> ffmpeg version N-77504-gbaf4c48 [17:07:24 CET] <Neon> Not sure if that's the version string. It looks unusual to me. But that's what I get from ffmpeg -v. [17:07:40 CET] <Neon> Maybe it's because it's a Windows version. [17:10:26 CET] <Neon> Well that didn't work as expected. I've got a 20 minute ogg now that seems silent. [17:22:32 CET] <alcros> Hey guys, i have a question. Is it possible to cut the ads (mostly 2-3) out of a TV capture without reencoding the video in one ffmpeg command? [17:30:10 CET] <Neon> alcros: If it helps, this explains how to cut a piece out of a video (with copy encoding): http://superuser.com/questions/377343/cut-part-from-video-file-from-start-p… But you need to know the time markers and I don't know if you can make multiple cuts in one command. [17:38:28 CET] <alcros> Neon: i know the time markers, this is not the problem...when i use something like this: ffmpeg -i test.ts -ss 10 -t 10 -ss 60 -t 10 -c:a copy -c:v copy test_cutted.ts i get only a 10sec video...but thanks for your help [18:51:42 CET] <Zeranoe> Does 0.5.15 support any way to find the build time configuration? I don't believe it has avcodec_configuration(void). [19:06:58 CET] <yongyung> Not really an ffmpeg question, but since people here are using it: I want to youtube-dl bestaudio+bestvideo, but I don't like the default behavior. For example, youtube-dl prefers 128k vorbis over 160k opus, and h264 over vp9. I tried -f 141/251/bestaudio, but somehow it still downloads vorbis instead of 251 when 141 isn't available [19:14:38 CET] <yongyung> Actually, running from console works but not from a batch file, even though it should be exactly the same looking at the batch output [19:14:40 CET] <livingBEEF> 248+251/248+250/137+140/best [19:14:49 CET] <livingBEEF> how about something like that? [19:19:14 CET] <yongyung> livingBEEF: LMAO I got it. If you quote the link it doesn't work, if you don't it does. Oo [19:21:35 CET] <livingBEEF> Is that bash? [19:23:07 CET] <PsychiC> Hello guys and gals , iŽm having issues with transcoding an input stream from OBS , reencode it and send to another rtmp destination. I canŽt get ffmpeg to work or it gives audio only or out of sync etc. IŽve been trying for days with various OS and ffmpeg versions , but IŽm stuck :( I could really use some help which would be greatly appreciated. [19:23:26 CET] <furq> yongyung: -f bestvideo[ext=webm]+bestaudio[ext=webm] [19:23:35 CET] <furq> please don't blame me for how ridiculous that is [19:24:31 CET] <livingBEEF> furq: doesn't seem all that bad to me [19:25:07 CET] <livingBEEF> -o seems much worse [19:25:26 CET] <furq> well you'd expect -f best[ext=webm] to work [19:25:41 CET] <furq> but that does the same thing as -f webm [19:26:34 CET] <yongyung> furq: The problem with that is that it would prefer opus 160k over aac 256k, and not all videos seem to have vp9 yet [19:26:48 CET] <yongyung> (141 is aac 256k) [19:26:49 CET] <livingBEEF> separage video/audi DASH probably has something [19:26:54 CET] <livingBEEF> to do with that [19:28:32 CET] <livingBEEF> well... if opus is better even at those bitrates, it's the correct thing [19:28:57 CET] <yongyung> livingBEEF: Opus 160k is guaranteed not better than aac 256k [19:28:58 CET] <livingBEEF> it can always mux it together as mkv or something [19:29:14 CET] <furq> opus 160k should still be pretty much transparent though [19:29:20 CET] <livingBEEF> how sure are you about that? [19:29:20 CET] <yongyung> The only reason it prefers opus there is the extension [19:29:33 CET] <furq> does bestaudio prefer vorbis over opus [19:29:37 CET] <livingBEEF> Isn't aac quite a bit older? [19:29:48 CET] <furq> good aac encoders are competitive with opus [19:30:03 CET] <furq> good aac and opus are both basically transparent at 128k though afaik [19:30:14 CET] <furq> 256k seems like overkill for stereo [19:30:24 CET] <yongyung> livingBEEF: Audio codecs really don't have the same development as video codecs, mp3, vorbis, aac, opus are all pretty close, a significantly higher bit rate will always sound better [19:30:26 CET] <LeonG> what aac encoder does youtube use? [19:30:32 CET] <furq> no idea [19:30:40 CET] <furq> probably not appleaac which i believe is still the best [19:30:54 CET] <LeonG> because some were really badf at 256kbps [19:30:56 CET] <yongyung> The description says "google", but I'd assume they use fdk_aac [19:30:59 CET] <furq> if it's using FAAC or some old library then 160k opus probably is better [19:31:05 CET] <furq> i doubt they would be though [19:31:06 CET] <LeonG> yeah [19:31:16 CET] <livingBEEF> afaik mp3/opus is a BIG difference at very low bitrates [19:31:37 CET] <yongyung> There is, but 192k mp3 still sounds better than 128k opus [19:31:42 CET] <livingBEEF> you can have like 10-20k mono w/ opus [19:32:07 CET] <furq> apparently youtube did use faac at one point [19:32:50 CET] <furq> according to an unsourced hydrogenaudio post they use fdk now [19:35:11 CET] <furq> does bestaudio not always prefer aac then [19:35:17 CET] <furq> it does on everything i've tried [19:36:06 CET] <yongyung> furq: It does, but it's extension isn't webm [19:36:19 CET] <furq> i mean just bestaudio with no extension specified [19:36:27 CET] <LeonG> webm only can contain vorbis or opus audio [19:36:54 CET] <yongyung> furq: When you don't specify and extension aac is preferred, which is good, but it prefers 128k vorbis over 160k opus [19:37:12 CET] <yongyung> And a lot of videos don't have 256k aac available [19:37:22 CET] <yongyung> In which case I want to choose opus, not vorbis [19:37:29 CET] <LeonG> good point [19:38:20 CET] <furq> are there videos where 160k opus is available but 256k aac isn't [19:38:28 CET] <furq> i assumed those both went with the 720p video [19:38:46 CET] <furq> the next step down is 128k vorbis and then 70k opus [19:40:36 CET] <yongyung> furq: Yes there are, you want one?^^ [19:40:54 CET] <furq> sure [19:41:09 CET] <furq> youtube seems like a mess so it wouldn't surprise me, but i couldn't find any [19:41:24 CET] <yongyung> https://www.youtube.com/watch?v=qKHavcFDaSc [19:42:18 CET] <furq> that's really dumb [19:43:23 CET] <furq> i can sort of see why youtube-dl's -f specification is so nuts now [19:43:35 CET] <furq> not that it's as good as it could be [19:44:33 CET] <yongyung> Well if youtube-dl --output "%(title)s.%(ext)s" -f "303/299/302/298/248/bestvideo+141/251/bestaudio" would work it'd be fine with me [19:44:41 CET] <yongyung> But he's just ignoring the audio [19:45:28 CET] <yongyung> And yeah, not defining --output has no effect [19:49:40 CET] <yongyung> I guess I'm gonna load them separately and write a script to merge everything [19:54:44 CET] <livingBEEF> yongyung: thoe problem is that you have to have EVERYTHING you want between '/' signs. [19:55:21 CET] <livingBEEF> You can't say "I want any of these video formats in this order and than any of these audio formats" [19:55:48 CET] <livingBEEF> you have to specify them as pairs like 1+2/1+3/9+2 [19:56:13 CET] <yongyung> livingBEEF: That'd be so many pairs that writing a script is probably easier [19:58:32 CET] <livingBEEF> yongyung: you can only specify the semsible ones - only webm+webm and mp4+mp4 [19:59:05 CET] <yongyung> livingBEEF: They're all sensible to me, I merge to mkv [20:00:29 CET] <livingBEEF> 303+141/303+251/303+bestaudio/299+141/299+251/299+bestaudio/302+141/302+251/302+bestaudio/298+141/298+251/298+bestaudio/248+141/248+251/248+bestaudio/bestvideo+141/bestvideo+251/bestvideo+bestaudio/ [20:05:12 CET] <livingBEEF> you could have someting like `{format1,format2,...}+{aformat1,aformat2,...} | tr -d ' '` if it's bas [20:05:16 CET] <livingBEEF> *bash [20:08:49 CET] <livingBEEF> concerning http://news.softpedia.com/news/zero-day-ffmpeg-vulnerability-lets-anyone-st… [20:09:02 CET] <livingBEEF> an idea which versions are affected [20:09:09 CET] <livingBEEF> *any? [21:06:19 CET] <micechal> how can I use ffmpeg to fix a file broken this way: https://bpaste.net/show/ec9119777994 ? [21:06:48 CET] <micechal> I'd like to enable seeking there and get rid of the errors [22:15:00 CET] <Prelude2004c> hey guys.. quick question.. i have a source that sometimes the frame rates per second drop.. any way for me to deletect frames and if they drop below say 20fps to automatically exit so ic an restart the request [22:15:26 CET] <klue> What versions does the recent ffmpeg vulnerabiliy affect? (The one that provides SSRF, local file reads, etc) [22:29:31 CET] <JEEB> klue: everything but current master and releases made a few hours ago http://git.videolan.org/?p=ffmpeg.git;a=summary [22:31:44 CET] <JEEB> looking at the patches to HLS recently I'm not really sure what else could have been achieved other than reading local files that the running ffmpeg process had access to? [22:35:04 CET] <JEEB> ok, so it was about meta playlists [22:35:07 CET] <JEEB> that contain urls [00:00:00 CET] --- Sat Jan 16 2016

1 0

ffmpeg-devel.log.20160114
by burek 15 Jan '16

15 Jan '16

[00:09:05 CET] <J_Darnley> kierank: another function patch for you, h264 chroma422 https://gitlab.com/J_Darnley/ffmpeg/commit/6380c010adfb2462318599263db5d83c… [00:10:59 CET] <J_Darnley> jamrial ^ if you want to look too [00:15:25 CET] <kierank> NICE [00:19:31 CET] <J_Darnley> oops a slight bug there [00:19:46 CET] <J_Darnley> I need to reserve 1 mmsize more stack space [00:27:57 CET] <kierank> J_Darnley: is ff_h264_dct_dc_add_8_c a bug? [00:28:00 CET] <kierank> there seems to be asm [00:32:01 CET] <cone-219> ffmpeg 03Maxim Andreev 07master:7145e80b4f78: avformat/hls: forbid all protocols except http(s) & file [00:33:00 CET] <kierank> seems to be different for 422 [00:33:16 CET] <wm4> haha that commit [00:33:57 CET] <wm4> wait why is file allowed [00:34:36 CET] <durandal_170> send that picture of you over here [00:35:03 CET] <durandal_170> kill server side [00:37:10 CET] <J_Darnley> kierank: did I comment something by accident? [00:37:24 CET] <kierank> no I mean in the asm profiler I sent you [00:37:35 CET] <kierank> one of the asm functions runs as c but it appears the asm exists [00:37:44 CET] <kierank> in the init it's chroma_format dependent but I dunno why [00:37:46 CET] <J_Darnley> ah [00:37:56 CET] <kierank> don't see how the c can be chroma independent but the asm not [00:38:42 CET] <kierank> some nice work though [00:38:47 CET] <kierank> big speedups on 422 [00:39:09 CET] <durandal_170> numbers! [00:39:33 CET] <J_Darnley> grep can't find that function for me [00:40:24 CET] <kierank> J_Darnley: https://github.com/FFmpeg/FFmpeg/blob/235381e674bf0921cbb7871946e2ff08bd84d… [00:40:40 CET] <ChALkeR> Btw, does mplayer use ffmpeg or share code with ffmpeg in any way? [00:40:44 CET] <ChALkeR> mplayer is also affected [00:41:00 CET] <ChALkeR> even after installing a fixed version of ffmpeg. [00:41:28 CET] <wm4> mplayer has no hls code and uses ffmpeg's [00:43:23 CET] <J_Darnley> Oh yes, its buried in the templating [00:43:54 CET] <ChALkeR> wm4: I guess it bundles libavformat [00:44:15 CET] <wm4> normal builds do [00:44:43 CET] <durandal_170> make sure it uses new libavformat [00:46:52 CET] <wm4> so why does the fix allow local files? [01:05:10 CET] <J_Darnley> kierank: I can't explain why that uses a C function [01:05:27 CET] <kierank> there's a check in the init that looks at the chroma format [01:06:56 CET] <J_Darnley> but not for that idct function [01:07:38 CET] <J_Darnley> oh wait, am I looking at the wrong function [01:09:53 CET] <J_Darnley> oh add vs add8 [01:10:28 CET] <J_Darnley> Are mmx and mmxext functions disabled on that system you profiled? [01:10:41 CET] <kierank> that is avdev iirc [01:10:45 CET] <kierank> no shouldn't be [01:11:07 CET] <J_Darnley> oh I see one mmxext further down [01:11:38 CET] <kierank> hmmm [01:11:58 CET] <kierank> all protected by if (chroma_format_idc <= 1) [01:12:57 CET] <J_Darnley> I'll step though in gdb and have a look [01:21:46 CET] <J_Darnley> I wonder whether it is from probing [01:22:16 CET] <J_Darnley> the dsp_init function gets called a few times and one with idc value = 1 [01:25:45 CET] <cone-219> ffmpeg 03Andreas Cadhalpun 07master:44ac13eed495: dca: fix misaligned access in avpriv_dca_convert_bitstream [01:31:31 CET] <kierank> I don't understand why the >= 422 check is needed [02:07:43 CET] <cone-219> ffmpeg 03Ganesh Ajjanagadde 07master:a0a47a09b0e2: lavu/libm: add isfinite fallback [02:11:51 CET] <jamrial> wtf [03:21:28 CET] <BBB> jya: hey there - really happy to see you guys using ffvp9 [03:36:10 CET] <jya> So am I :). However unless we can change the threading model as I referred to in my post to the devel list. It's going to have problem. [03:40:49 CET] <BBB> jya: it sounds like it can be figured out& wm4 can sometimes be a little grumpy, thats ok [03:41:30 CET] <BBB> jya: if we do what derek and somebody else suggested (michael?) and use a threadqueue as a optional parameter into each avcodeccontext and allow you to implement that in whatever way, would that be sufficient? [03:42:00 CET] <BBB> its a little bit overdesigned maybe but then again this isnt a problem that will occur for simple usage so maybe thats ok [04:04:10 CET] <jya> BBB: yes that would be. So long that we can share the thread pool. So for us we can limit the overall number of threads used globally. [04:05:20 CET] <jya> wm4 suggestion of not using threads is a very poor one. Because there are times when you *do* want to use many threads. In fact I would want to use as many threads as possible. [04:06:13 CET] <jya> Like the user has one window watching YouTube. Multi-threading is pretty much a must. [04:07:48 CET] <jya> I can't really understand why you would want to limit the use of a thread pool overall though and make that optional. It's such a superior concept :) [04:09:28 CET] <jya> Being C, such new API would probably only need a pointer to a context and a pointer to the function to call. Similar to how Apple VideoTooolbox callback system works. [04:10:21 CET] <BBB> jya: right& we use that for integrating with threading frameworks already [04:12:24 CET] <BBB> example: https://www.ffmpeg.org/doxygen/trunk/group__lavc__misc.html#gae120ec60cdf49… [04:12:35 CET] <BBB> all this stuff is rather creepy, but hey& [04:12:38 CET] <jya> If one of you could provide the framework/API to connect to. I would be able to write something very quickly to integrate that in gecko. [04:13:17 CET] <jya> I wonder what chrome is doing for addressing this problem. [04:13:31 CET] <BBB> they cap it at 2 threads or so, dont they? [04:13:38 CET] <jya> For their use of libvpx, they just create new threads per decoder. [04:13:42 CET] <BBB> there might be other things that Im not aware of [04:13:52 CET] <BBB> I dont think they do anything advanced TBH [04:14:07 CET] <BBB> but its been a while since I last looked at it [04:14:30 CET] <jya> They use 2 for vp8; then 4 if width >= 1024 and 8 if >= 2048. Then they min that with what ever number of processors is available. [04:15:20 CET] <jya> Having said that. WebKit has never been much caring about resources and low-end system :) [04:15:32 CET] <jya> Well now blink. [04:15:57 CET] <BBB> I couldnt build chrome on my laptop for the longest of times :D [04:16:29 CET] <jya> In my tests, I found that ffvp9 pretty much always allowed us to decode one resolution up compare to libvpx. [04:16:58 CET] <jya> Eg 1080p where it used to do 720p max, 720p where it was 480p etc [04:17:15 CET] <BBB> its a lot faster, thats all I know ;) [04:17:19 CET] <jya> That's on quad core laptops. Not that much on dual core. [04:17:24 CET] <BBB> its not as much faster on hyper-high end machines [04:17:32 CET] <jya> The difference isn't as dramatic there. [04:17:54 CET] <BBB> like, 40% or so on mid-to-low end hardware (sandybridge to old intel pentiums) [04:17:58 CET] <BBB> and more like 25% on haswell [04:18:12 CET] <jya> I found a sample video where my Mac Pro 8 cores will takes 49s to decode 10s worth [04:18:25 CET] <BBB> haswell can be improved a lot (theres not much axv2, jamrial wrote some but loopfilter/idct is not covered) [04:18:37 CET] <BBB> holy crap thats bad [04:18:41 CET] <BBB> how big is that video [04:18:42 CET] <jya> And with ffvp9 it's fast enough to play real time. [04:18:43 CET] <BBB> is that 8k? [04:19:10 CET] <BBB> ooo I know, it doesnt use frame-parallel=1 [04:19:13 CET] <jya> No 4K, encoded with one of the early version of libvpx, with a single keyframe at the beginning. [04:19:23 CET] <BBB> if you disable frame-parallel and tiling, libvpx doesnt do multithreading [04:19:34 CET] <BBB> Ive brought this up several times with them but I dont think they hav manpower to fix it [04:19:47 CET] <BBB> its quite some work and they dont care since youtube uses tiling and frame-parallel [04:19:54 CET] <jya> YouTube doesn't use that encoding. So the difference isn't as flagrant. [04:20:39 CET] <BBB> Im going to sleep now& is what I said about the threadpool helpful or do you need more details on that? [04:20:52 CET] <jya> And I'm going for lunch :) [04:21:19 CET] <jya> It is. So long that there's a possibility that it can be done. [04:21:40 CET] <jya> Makes me feel better that reading wm4 ridiculing the idea. [04:22:08 CET] <BBB> well, were not an organization so youll get more noise in discussions, not noise as in stupid people, but noise as in more noticeable when theres no complete agreement [04:22:38 CET] <BBB> but I think the threadpool idea isnt completely outrageous, and derek/michael seem to be ok with the basic concept also, so its probably fine [04:23:49 CET] <jya> Great. [05:25:37 CET] <cone-730> ffmpeg 03Claudio Freire 07master:62dfe1d40d87: avcodec/aacenc_is: replace pow(x, 0.75) by x/sqrtf(sqrtf(x)) [08:11:46 CET] <wm4> jya: so I still don't understand why you think it's a good idea to keep hundreds of decoders alive at the same time - even if you use a thread pool, it will use a lot of memory and CPU time no matter how you implement it [08:13:05 CET] <jya> because you may have 100 of videos playing at the same time. of course it will use a lot of memory. But we're not going to rewrite the W3C spec because you think it's silly :) [08:13:50 CET] <wm4> I believe you already deallocate images etc. if they're not visible (and many websites also lazily load images with JS) [08:13:58 CET] <wm4> now I'm wondering why this should be different with video [08:14:15 CET] <wm4> but I guess I'm just stupid [08:14:58 CET] <jya> if they are not visible, then sure, we have strategies in place to not display hidden videos, though we continue to play audio (we have to) [08:15:10 CET] <wm4> (meanwhile I'm restarting firefox every other day because its memory management is so great, heh) [08:15:43 CET] <jya> when a video is hidden, we stop decoding while we continue to play the audio if there's an audio track, or otherwise simulate where it's up to [08:16:27 CET] <jya> however, many videos used in ads, happen to not even have more than a single keyframe, and they may use JS to make them play in a loop [08:16:50 CET] <jya> wm4: which distribution are you using? [08:16:57 CET] <jya> (assuming you're using linux) [08:17:30 CET] <jya> because the funny thing is we're tracking a big leak in libavcodec 54 from LibAV used in ubuntu 14.04 [08:19:50 CET] <wm4> jya: debian unstable (I believe it uses ffmpeg already) [08:20:08 CET] <wm4> I wonder if that memory leak is the one I fixed a long time ago [08:21:12 CET] <jya> unfortunately, unlike google, we aren't at liberty to ship ffmpeg [08:21:36 CET] <jya> so we're stuck with whatever is installed, and you wouldn't believe how many people are still using 12.04 with LibAV 8 [08:22:15 CET] <jya> and we've only allowed to use ffmpeg directly in firefox 43, before it had to be through gstreamer [08:23:46 CET] <jya> back to playing a video in the background, the user expect when a tab is put in the background that the only difference is being hidden. E.g. any animations, music, videos, just continue as if it wasn't hidden. And so when the tab/window becomes visible again it shows up as if it hadn't been hidden at all [08:23:54 CET] <jya> many people put youtube and listen in the background [08:24:29 CET] <jya> while we attempt to suspend decoding the video track, when becoming visible and resuming decoding: we want the seek to be fast [08:24:51 CET] <jya> so if we've determined that the keyframe is too far off , we may not pause the decoding [08:25:14 CET] <wm4> I'm sure the user appreciates it when hundreds of audio clips are played at the same time (sorry I find this still absurd) [08:25:44 CET] <jya> well, they can disable the audio by clicking on the volume for a particular tab [08:26:09 CET] <jya> doesn't mean that when you make it back , you have to resume from where you were [08:26:23 CET] <jya> and if it was a live audio stream, you have trouble [08:27:07 CET] <jya> there's also the issue that a JS could very well decide to grab frames from a video playing [08:27:26 CET] <jya> so we also have to detect that (in which case you can't pause) [08:28:02 CET] <jya> but to cut it short, how its used is pretty much limitless. You don't "educate" the user on how many windows they should have opened [08:28:26 CET] <jya> so it comes down to what actually happen: and having lots of videos playing at once, happen a lot [08:28:56 CET] <jya> if we're too slow at decoding video, we drop and ultimately skip to key frame [08:29:14 CET] <wm4> is that why my firefox seems to be constantly using CPU even if it runs in the background and I don't interact with websites (yay we're getting more of that in the future) [08:29:22 CET] <jrosser> we built a video editor in a browser http://www.bbc.co.uk/rd/projects/nearly-live-production [08:29:35 CET] <jrosser> lots of simultaneous videos [08:30:10 CET] <jrosser> that sort of thing is key for new production tools [08:30:53 CET] <jya> wm4: because a page is rarely static it'd made of anymated objects. [08:31:19 CET] <jya> you could always use lynx, it's very efficient [08:31:50 CET] <jya> i [08:33:02 CET] <jya> what jrosser describe is typically a case where having a global pool thread would help: it goes super fast when you have just the main video playing, but doesn't bog down the entire machine when you have too many [08:35:37 CET] <jrosser> get them all synced too please :) [08:35:52 CET] <jrosser> but thats a different discussion..... [08:41:38 CET] <dinux5> which repository should I clone in order to get started with contributing to ffmpeg ? I am a newbie and good at C . [08:43:31 CET] <JEEB> git.videolan.org's ffmpeg [08:43:51 CET] <JEEB> that's the current main repo [11:45:13 CET] <kierank> jya: why cant you ship ffmpeg [11:46:45 CET] <jya> legal reasons, I can't comment further [11:48:11 CET] <durandal_1707> patents [11:48:17 CET] <kierank> On what [11:48:26 CET] <kierank> ffvp8 and vp9? [11:49:25 CET] <jya> we are shipping the ffmpeg code for ffvp8 and ffvp9 since last week. [11:49:51 CET] <kierank> Then why can't you statically link [11:50:01 CET] <kierank> Or ship your own .so [11:50:12 CET] <t4nk283> what is the best way to package ffmpeg into software so that a program refers to its own copy instead of searching the system? [11:50:16 CET] <jya> well, more exactly a butchered version of ffmpeg that can only do vp8 and vp9 [11:51:14 CET] <jya> kierank: 1: firefox isn't GPL (static linking) 2. again we can't ship ffmpeg nor use its code. [11:51:45 CET] <kierank> Probably only a few hundred kB with vp8/9 [11:51:57 CET] <jya> I wish [11:53:31 CET] <t4nk283> please let me know if my question is unclear [11:53:48 CET] <jya> 5.2MB source code, 3.6MB for libavcodec, 300kB for libavutil [11:54:07 CET] <jya> that's debug build though [12:05:06 CET] <wm4> was this with --disable-everything? (or whatever it was) [12:42:04 CET] <jya> wm4: i exctracted such as only vp8/vp9 decoder and all it depends on would compile (so that upgrading in the future would be easy). So for example there is common code in the h264 part, so that's included too. It was made in such a fashion that no one could ever enable any other codecs. [12:42:15 CET] <jya> the files were identified after using ./configure --disable-everything --disable-protocols --disable-demuxers --disable-muxers --disable-filters --disable-programs --disable-doc --disable-parsers --enable-parser=vp8 --enable-parser=vp9 --enable-decoder=vp8 --enable-decoder=vp9 --disable-static --enable-shared --disable-debug --disable-sdl --disable-libxcb [12:42:16 CET] <jya> --disable-securetransport --disable-iconv --disable-swresample --disable-swscale --disable-avdevice --disable-avfilter --disable-avformat --disable-d3d11va --disable-dxva2 --disable-vaapi --disable-vda --disable-vdpau --disable-videotoolbox --enable-asm --enable-yasm as command [12:42:42 CET] <jya> (note that I find it rather humour that there are still so much stuff you must disable on top of --disable-everything) [12:43:22 CET] <nevcairiel> there is also --disable-all that disables even more, but unless you turn some stuff back on after that, i dont think it actually builds anything [12:44:55 CET] <atomnuker> that's kinda evil unless you can't even distribute the source code [12:45:28 CET] <wm4> (I really love how ffmpeg shares parts between vp8 and h264, even though Google claims vp8 does not violate h264 patents) [12:45:50 CET] <wm4> it's like ffmpeg devs said "no, that's bullshit" [12:46:12 CET] <nevcairiel> there is always overlap in the more generic DSPs [12:46:35 CET] <wm4> at least that doesn't have "h264" in the names [12:47:52 CET] <nevcairiel> vp8 uses h264pred apparently [12:47:55 CET] <nevcairiel> vp9 doesnt [12:49:12 CET] <nevcairiel> looks like just for soem defines [12:49:38 CET] <nevcairiel> oh no, it actually uses the pred code as well [13:08:45 CET] <durandal_1707> I just remove bass note with GIMP, will push spectrumsynth soon [13:22:50 CET] <ubitux> tmm1: i will look tonight [14:31:59 CET] <cone-990> ffmpeg 03Paul B Mahol 07master:70df51112ccc: avfilter/af_dynaudnorm: fix possible null pointer dereference [14:54:08 CET] <durandal_1707> how to do afftfilt, like aeval but in frequency domain? [14:54:43 CET] <Daemon404> kierank, gopro having layoffs [14:54:44 CET] <Daemon404> it's all your fault [14:57:50 CET] <Compn> did apple buy it out ? [14:58:09 CET] <Compn> gopro cameras going to go up in price and also white plastic... [15:14:15 CET] <an3k> is this the channel of the well-known ffmpeg package in debian/ubuntu ? [15:14:53 CET] <J_Darnley> No [15:14:57 CET] <J_Darnley> We are imposters [15:16:36 CET] <an3k> so you are the libav guys who caused the removal of the ffmpeg package? [15:16:56 CET] Action: J_Darnley facepalms [15:17:01 CET] <J_Darnley> that was a bad joke [15:17:07 CET] <J_Darnley> Yes this this is FFmpeg [15:17:10 CET] <BBB> hehehe [15:17:27 CET] <J_Darnley> Libav is that way *points* somewhere [15:17:48 CET] <BBB> an3k: were ffmpeg developers; some of us may be involved with debian packaging, but were primarily involved in the actual software development, not so much debian packaging [15:18:18 CET] <an3k> J_Darnley I understood the joke. Just wanted to be sure that I'm not talking with these bastards who cause a huge headache :) [15:19:04 CET] <BBB> wm4: h264pred is just a name [15:19:32 CET] <BBB> wm4: to say that that tecnology originates in h264 is kind of silly, its shared between various decoders and h264 is just the bestknown/first of them so the naming originates from that [15:20:03 CET] <an3k> Since two days I'm trying to get VapourSynth + L-SMASH + L-SMASH Works compiled and because there's no ffmpeg I have to compile that too and I haven't yet figured out what I have to compile/link statically and what dynamically so everything works ... [15:20:26 CET] <BBB> nevcairiel: and the intra prediction between vp8/vp9 is mostly identical, its in fact a todo item of mine, the issue is simply that vp9 has much bigger prediction sizes (up to 32x32 for intra), so h264pred would have to essentially be rewritten for it to work [15:20:41 CET] <BBB> nevcairiel: also note that hevc/vp9 duplicate nearly identical code between their intra predictors [15:21:01 CET] <BBB> I just dont feel like merging it all back together, so much work for so little gain :/ [15:21:09 CET] <wm4> BBB: let's say, calling it "h264pred" for a codec which claims to be completely independent from h264/mpeg could be considered an offense [15:21:23 CET] <BBB> wm4: various people have told me that :) [15:21:27 CET] <BBB> wm4: but its just a name [15:21:35 CET] <BBB> it has no legal meaning [15:21:54 CET] <BBB> if it really offends you, we can consider renaming it I suppose [15:22:16 CET] <wm4> I still find it funny [15:22:37 CET] <BBB> I think it shows how nearly-identical most dct-based codecs are [15:22:57 CET] <BBB> but it doesnt mean vp8 is based on h264, or vice versa [15:23:09 CET] <BBB> it just means all of them are veyr similar [15:23:22 CET] <nevcairiel> But it could mean that there is a patent common to all those codecs [15:26:49 CET] <BBB> regardless of whether it does exist, isnt there some agreement between mpegla and google to not sue re:vp8 and vp8++ (i.e. vp9)? [15:32:13 CET] <J_Darnley> an3k: I don't really know what you're talking about but is there a problem when you statically link everything? [15:34:34 CET] <kierank> Gramner: ping [15:34:48 CET] <an3k> J_Darnley: not with ffmpeg but L-SMASH Works. However since you're asking and the current topic is VPx: when I configure libvpx with --disable-static latest ffmpeg from git complains about libvpx being too old (>= 0.9.1). Without --disable-static ffmpeg doesn't complain [15:36:19 CET] <J_Darnley> Is configure/gcc/ld picking up an old system libvpx? [15:37:06 CET] <J_Darnley> Shared libs tend to be preferred (by these tools) [15:37:31 CET] <J_Darnley> Also what does config.log say about the failing test? [15:37:36 CET] <an3k> no other libvpx installed [15:37:56 CET] <J_Darnley> And I guess we should take this to #ffmpeg [15:38:45 CET] <J_Darnley> ha ha I haven't been there since "FFmpeg 2.4.2" was in the topic [15:38:54 CET] <an3k> sure. hehe [15:46:51 CET] <atomnuker> the current git master of the linux kernel finally supports using ath9k as an RNG [15:47:01 CET] <atomnuker> result: the blocking /dev/random never blocks now [15:48:38 CET] <cone-990> ffmpeg 03Michael Niedermayer 07master:5e5f82a28737: swscale/yuv2rgb: Factor YUVRGB_TABLE_LUMA_HEADROOM out [15:48:39 CET] <cone-990> ffmpeg 03Michael Niedermayer 07master:8f3a9a8c278a: swscale/yuv2rgb: Increase YUV2RGB table headroom [15:48:40 CET] <cone-990> ffmpeg 03Michael Niedermayer 07master:cc538e9dbd14: swscale/utils: Detect and skip unneeded sws_setColorspaceDetails() calls [15:54:03 CET] <BBB> did ganesh ever revert the patch I asked him to revert? [15:55:14 CET] <J_Darnley> was that isfinite? [15:55:46 CET] <J_Darnley> (I didn'tsee any reverts in cvslog) [15:55:54 CET] <BBB> yes [15:57:36 CET] <nevcairiel> dont think so [16:03:24 CET] <durandal_1707> Revert war [17:03:36 CET] <J_Darnley> Heh. Trying to defend your GPL violations never looks good. [17:04:15 CET] <J_Darnley> If you distribute a binary you must offer the source. What's hard about that? [17:07:01 CET] <atomnuker> michaelni: I have this incredibly naive function to write golomb: http://paste.debian.net/365845/ [17:07:21 CET] <atomnuker> I'm trying to remove the while loop but I've no idea how to do it efficiently [17:09:46 CET] <michaelni> something with ff_log2(val) maybe a +- 1 somewhere [17:29:07 CET] <BBB> I really dont know what to do with ganesh anymore [17:29:10 CET] <BBB> ... [17:29:12 CET] <BBB> I give up :( [17:29:31 CET] <durandal_170> what happened? [17:30:36 CET] <BBB> he commits a patch saying that I reviewed it (which I didnt), so I ask him to revert it so it can go through regular review and he refuses [17:30:40 CET] <BBB> I dont know what to do anymore [17:30:42 CET] <BBB> I give up [17:32:21 CET] <durandal_170> I'm gonna revert it then [17:32:42 CET] <BBB> I dont want a revert war [17:32:49 CET] <BBB> thats not helping anyone :/ [17:37:18 CET] <michaelni> i think ganesh is a bit stressed because he will be away from internet or so IIRC i guess he wanted to get some work/patches done before [17:37:49 CET] Action: michaelni just guessing [17:49:50 CET] <Daemon404> not sure why that is stressful [17:58:32 CET] <Gramner> kierank: pong [17:58:52 CET] <kierank> can you have a look at J_Darnley's v210 patch [17:59:03 CET] <kierank> i.e does it look sane [17:59:24 CET] <Gramner> sure [18:43:39 CET] <durandal_1707> michaelni: what fftfilt could do beside what is in examples? [18:51:50 CET] <nevcairiel> BBB: its been months and he still hasnt learned the basic netiquette of pushing, but noone wants to listen to me, soo. [18:57:35 CET] <jamrial> if you're talking about ganesh, then everybody agrees with you [19:26:19 CET] <BBB> nevcairiel: ok, I was wrong [19:27:05 CET] <J_Darnley> Have you people seen the news today about a severe bug in openssh? [19:27:10 CET] <J_Darnley> http://undeadly.org/cgi?action=article&sid=20160114142733 [19:27:54 CET] <nevcairiel> doesnt seem that serious [19:28:05 CET] <nevcairiel> client only, needs malicious server [19:29:09 CET] <J_Darnley> True. [19:29:26 CET] <rcombs> and the server verification check happens before you can exploit it [19:29:43 CET] <J_Darnley> You can also defend against leaks by using different priv. keys for different hosts. [19:30:01 CET] <rcombs> or by turning off the roaming client code [19:30:01 CET] <wm4> heh, it's always useless features that cause the security issues [19:30:12 CET] <rcombs> (for this particular bug) [19:30:18 CET] <wm4> "Server side was disabled/gutted for years already, but this aspect was surprisingly forgotten." [19:30:33 CET] <J_Darnley> PuTTY is also claimed to be unaffected [19:30:35 CET] Action: J_Darnley cheers [19:30:37 CET] <rcombs> wm4: hey it probably would've been useful if it actually got significant deployment [19:30:50 CET] <nevcairiel> putty is an entirely different client [19:30:55 CET] <rcombs> but I guess everyone just uses mosh instead [19:31:48 CET] <rcombs> and I guess mosh is just as "affected" since it uses OpenSSH at startup [20:01:30 CET] <atomnuker> something odd just hit the mailing list [20:02:35 CET] <Daemon404> atomnuker, shhh it;s SMPTE [20:02:38 CET] <Daemon404> not BBC [20:03:28 CET] <atomnuker> it's the allcodecs description [20:03:36 CET] <atomnuker> which is ALWAYS correct [20:03:49 CET] <Daemon404> lul [20:03:58 CET] <atomnuker> VP-3 is *totally* not Theora [20:04:08 CET] <wm4> does this belong into the category "awesome but useless"? [20:04:33 CET] <Daemon404> people use it vc-2 in real life [20:04:34 CET] <atomnuker> mhmaybe, it supports lossless though [20:04:37 CET] <Daemon404> it is unfortunate [20:04:59 CET] <atomnuker> it's almost always used with interlacing too -_- [20:14:04 CET] <kierank> jrosser: patch on ML [20:16:25 CET] <jrosser> i see [20:16:32 CET] <jrosser> nice work :) [20:17:49 CET] <jrosser> Systemd a typo? [20:18:18 CET] <kierank> rofl [20:18:40 CET] <jrosser> on so many levels :) [20:19:03 CET] <kierank> atomnuker actually loves systemd [20:19:31 CET] <durandal_1707> noooooo!! [20:19:35 CET] <Daemon404> he can meet his idol at FOSDEM [20:19:56 CET] Action: durandal_1707 crying [20:21:52 CET] <kierank> Gramner: thanks [20:23:30 CET] <kierank> 7:04 PM <"wm4> does this belong into the category "awesome but useless"? --> for you maybe [20:24:56 CET] <wm4> so who uses it? [20:25:01 CET] Action: kierank [20:25:25 CET] <durandal_1707> anime folks certainly not [20:26:01 CET] <wm4> kierank: and what for? [20:26:06 CET] <wm4> sorry if I'm being too curious [20:26:14 CET] <kierank> compressing live videos and stuff [20:26:48 CET] <durandal_1707> snow? [20:26:52 CET] <kierank> the same reason people use jpeg2000 [20:27:16 CET] <Compn> same reason people use dirac? :P [20:27:44 CET] <kierank> is it possible to have an avpacket use your own memory [20:27:57 CET] <wm4> yes, same as with AVFrame [20:29:03 CET] <wm4> "compressing live videos" [20:29:14 CET] <wm4> and archiving them? [20:29:20 CET] <jrosser> vc2 is in the same class as j2k and tico, and some of prores [20:29:40 CET] <kierank> jrosser: i doubt anyone knows what tico is here [20:29:57 CET] <jrosser> if you want a codec with only a few lines of latency and mild compression, its useful [20:30:01 CET] <jrosser> otherwise not [20:32:59 CET] <tmm1> ubitux: thanks [20:47:31 CET] <gajjanag> @all: updated fclose business with more verbose/detailed info, https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/187154.html [20:48:26 CET] <gajjanag> want to achieve some level of common understanding regarding it, so request for interested people to be on irc [20:49:03 CET] <Compn> yo gajjanag , nice to see you here [20:49:14 CET] <Compn> yes there are a few devs who have questions about patches [20:49:30 CET] <gajjanag> in particular, seems like BBB, michaelni, and wm4 have expressed opinions on it, so it would be helpful if all 3 are there [20:49:42 CET] <gajjanag> @Compn: was here yesterday as well ;) [20:49:45 CET] <Compn> ahhh :) [20:50:09 CET] <Daemon404> my only opinion is: no gnulib [20:50:19 CET] <Compn> no systemd [20:50:25 CET] <Compn> no autotools [20:50:26 CET] <Compn> :p [20:50:35 CET] <gajjanag> @Daemon404,compn: definitely agreed :) [20:56:10 CET] <cone-777> ffmpeg 03Paul B Mahol 07master:653f9d84ae83: avfilter: add spectrumsynth filter [20:59:26 CET] <durandal_1707> gajjanag: what's point of is_finite hack? [21:00:23 CET] <durandal_1707> @ is not part of nick it means nick is channel operator [21:00:34 CET] <gajjanag> durandal_1707: just to simplify something michael pushed recently [21:01:16 CET] <gajjanag> he had an isnan/isinf check [21:02:03 CET] <gajjanag> btw, are .i64 of hann/hanning supposed to be identical (recently pushed)? [21:05:38 CET] <durandal_1707> yes [21:09:23 CET] <gajjanag> durandal_1707: nothing else I can find by code inspection, thanks [22:02:20 CET] <ubitux> tmm1: is your github up-to-date? [22:02:53 CET] <tmm1> yes, but i changed the branch name to upstream-cc [22:03:11 CET] <ubitux> ok [22:03:46 CET] <ubitux> tmm1: are you available for quick reviews? [22:03:54 CET] <tmm1> yep [22:04:05 CET] <ubitux> ok, give me sth like 5-10 minutes then [22:04:15 CET] <ubitux> time to get a ff setup working again [22:04:43 CET] <tmm1> sure [22:05:21 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:7b6e6895f2cb: swscale: Move VScalerContext into vscale.c [22:05:22 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:e06403331cec: swscale: Move Contexts used only in hscale.c into it [22:05:23 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:8feeffc1d7ca: swscale/slice: Fix doc typo [22:05:24 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:705a2f70ee14: swscale/slice: Fix indention [22:05:25 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:fe6372bb614d: swscale/vscale: Add fixme comment to "ugly" code [22:05:26 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:b99f49871679: swscale/output: Assert that yalpha and uvalpha are within their expected range [22:05:27 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:eb7802afefb7: swscale/vscale: Check that 2 tap filters are bilinear before using bilinear code [22:09:30 CET] <cone-777> ffmpeg 03Aman Gupta 07master:260e3687173b: lavc/ccaption_dec: flush context on seek [22:12:41 CET] <ubitux> tmm1: the fate test introduced in the 3rd commit is not correct [22:12:48 CET] <ubitux> it still includes this 999 thing [22:13:03 CET] <ubitux> i'm going to fix it up, unless you have an objection [22:13:19 CET] <ubitux> but if you can do it that would help [22:17:31 CET] <tmm1> ah, i can fix that [22:18:04 CET] <ubitux> thanks [22:19:35 CET] <tmm1> hrm, i changed taht previous commit to use 10s as the duration [22:19:45 CET] <tmm1> (i noticed that's what VLC does, and it makes a lot more sense than infinite) [22:22:15 CET] <tmm1> oh i only changed one spot, i see [22:25:15 CET] <tmm1> ubitux: pushed, fix that realtime commit and the following fate test [22:28:04 CET] <ubitux> tmm1: well, 10sec is actually not that great [22:28:46 CET] <ubitux> the thing is, with the incoming timing patch, you could get a negative duration reaches the final user [22:29:02 CET] <ubitux> who could set it to whatever prefered timeout [22:29:15 CET] <ubitux> while is 10s duration is actually very misleading [22:29:19 CET] <ubitux> s/is/a/ [22:29:45 CET] <cone-777> ffmpeg 03Paul B Mahol 07master:2bbc7e9625f2: avfilter/vf_fftfilt: use the name 's' for the pointer to the private context [22:29:46 CET] <cone-777> ffmpeg 03Paul B Mahol 07master:d6f1abe9ce08: avfilter/vf_fftfilt: this is video filter so use pixels instead of samples [22:35:08 CET] <tmm1> ubitux: ok so you prefer -1 ? [22:35:21 CET] <ubitux> yes [22:36:05 CET] <ubitux> tmm1: what you can do though is adding an option to force a special timeout [22:36:41 CET] <ubitux> not sure that's worth the effort but well [22:36:57 CET] <ubitux> i might apply the timing patch this week end, if things go well [22:39:19 CET] <tmm1> ubitux: pushed [22:42:17 CET] <cone-777> ffmpeg 03Aman Gupta 07master:5c041e2cccc1: lavc/ccaption_dec: implement real_time option [22:42:18 CET] <cone-777> ffmpeg 03Aman Gupta 07master:fdbe5cd5c523: fate: add test for realtime ccaption decoder [22:45:19 CET] <ubitux> tmm1: what's this 0 value you're refering to in 'Row 10 was chosen as it corresponds to the value of "0" in a PAC'? [22:45:27 CET] <ubitux> i see no 0 in row_map [22:45:45 CET] <ubitux> (i don't get what this is really about) [22:47:06 CET] <tmm1> ubitux: row_map[0] == 11 [22:47:45 CET] <tmm1> ubitux: basically it defaults the position of subs to near the bottom, in the case where you tune into a stream *after* a PAC which tells you where to place characters [22:47:54 CET] <tmm1> if you're not planning on merging the positioning changes it doesn't matter [22:48:12 CET] <tmm1> i should have put it later in the patchset [22:48:36 CET] <tmm1> i can rearrange if you want, or you can skip that one for now [22:49:02 CET] <ubitux> just trying to figure out the thing [22:49:30 CET] <ubitux> about tab offset, is there something to do about the skipped ' ' in capture_screen()? [22:50:40 CET] <ubitux> my other comments about the musical notes and positioning still hold btw [22:50:49 CET] <tmm1> tab offset similarly doesn't matter without the positioning patch, since it will be skipped as you said [22:50:58 CET] <ubitux> ok [22:51:07 CET] <ubitux> do you mind if i postpone the review of these patch for this week end or so? [22:51:17 CET] <tmm1> ubitux: yea that's fine, i mostly want the real time one merged [22:51:17 CET] <ubitux> (i think the most urgent one was the real time thing?) [22:51:20 CET] <ubitux> right [22:51:22 CET] <ubitux> ok [22:51:45 CET] <tmm1> the claer patch is useful too [22:52:08 CET] <ubitux> is it reorderable? [22:52:21 CET] <tmm1> yes it should be independent [22:53:17 CET] <tmm1> i reordered and pushed [22:53:20 CET] <ubitux> you have an unrelated change in this commit, and pointless (); can you fix those and move it as a first commit in your branch? [22:53:51 CET] <tmm1> ok, separate whitespace commit? [22:54:16 CET] <ubitux> yeah [22:55:43 CET] <ubitux> but the file still has style mistakes all over, so you probably want to do them all at once [22:55:51 CET] <tmm1> pushed [22:56:00 CET] <tmm1> that's the only one i had changed in this patchset, if you see others i can include them in the first commit [22:57:02 CET] <ubitux> the condition shouldn't be >=? [22:57:26 CET] <ubitux> i mean it was originally "until i < ctx->cursor_row - keep_lines" [22:57:36 CET] <ubitux> so i == ctx->cursor_row - keep_lines wasn't reached [22:59:32 CET] <tmm1> yea i think that was incorrect, that line is supposed to be cleared as well [23:00:24 CET] <ubitux> why not make a simpler loop? [23:00:41 CET] <tmm1> how so [23:01:50 CET] <tmm1> if keep_lines is 2, the cursor_row and the one above it should stay and everything else is cleared [23:02:18 CET] <ubitux> like, for (i = ctx->cursor_row; i < ... [23:02:45 CET] <ubitux> and UNSET_FLAG(.., i - ctx->cursor_row) [23:03:01 CET] <ubitux> you would about crawling through all the entries before reaching the start [23:03:05 CET] <ubitux> and all the entries after the end [23:03:19 CET] <ubitux> and the loop might be more readable [23:03:23 CET] <ubitux> no? [23:03:34 CET] <ubitux> s/about/avoid/ [23:04:11 CET] <tmm1> doesn't seem as intuitive to me, i want to scan all rows and clear them unless they fall in the whitelisted range [23:04:41 CET] <ubitux> oh my bad, ok i see [23:04:55 CET] <ubitux> i had it the other way around in mind [23:08:19 CET] <ubitux> tmm1: broken } or something [23:08:54 CET] <tmm1> looking [23:09:18 CET] <ubitux> maybe broken git.. the '}' looks present [23:09:42 CET] <ubitux> ah you put it in the whitespace one [23:10:02 CET] <tmm1> ah i see it [23:10:07 CET] <tmm1> i was surprised when i rebased that without conflicts [23:11:03 CET] <tmm1> pushed [23:11:18 CET] <tmm1> ugh now the next one got messed up lol [23:11:20 CET] <tmm1> good job git [23:12:10 CET] <tmm1> ok fixed up [23:13:58 CET] <cone-777> ffmpeg 03Aman Gupta 07master:9027806e3cf6: lavc/ccaption_dec: clean up whitespace [23:13:59 CET] <cone-777> ffmpeg 03Aman Gupta 07master:3a0e5cfcee5b: lavc/ccaption_dec: clear all unused rows during rollup [23:20:03 CET] <tmm1> ubitux: re: positioning, it works quite well for me. i've watched several hours of content from different feeds with it enabled [23:20:08 CET] <tmm1> here are some examples https://www.dropbox.com/sh/oczgb8e8t3ggz18/AABeH2hVvRXWxNtYPjkYnM6la?dl=0 [23:21:16 CET] <ubitux> isn't it a bit too much on the left? [23:21:39 CET] <ubitux> are we good on the font size? [23:22:51 CET] <tmm1> yea i suppose it never gets all the way to the right, since PLAYRES is 4:3 [23:23:11 CET] <ubitux> https://www.youtube.com/watch?v=8TZLxPdC3hk you might want to check this [23:23:20 CET] <ubitux> with the sample i gave you last time [23:23:30 CET] <ubitux> so you can see expected output [23:24:02 CET] <tmm1> good idea i'll try that [23:24:08 CET] <tmm1> i am seeing captions on the far right side too actually [23:24:13 CET] <tmm1> so i guess libass is scaling the aspect as well [23:24:31 CET] <tmm1> and many captions show up dead center, so pretty sure its correct [23:24:42 CET] <ubitux> btw, one thing we can do too [23:24:49 CET] <ubitux> is actually have a bitmap mode [23:24:59 CET] <ubitux> we have cga fonts builtin ffmpeg [23:25:08 CET] <ubitux> so creating a bitmap might be doable [23:25:13 CET] <tmm1> ah interesting, didn't know there were fonts available [23:25:25 CET] <ubitux> that's what we often use in filters [23:25:28 CET] <ubitux> to print text [23:25:33 CET] <tmm1> tbh i didn't plan on spending so much time on closed captions, and now that its working i'm ready to move on [23:25:40 CET] <tmm1> that's the main reason i'm hesitant to dive into character sets [23:26:28 CET] <ubitux> try git grep 'avpriv_cga' [23:26:30 CET] <ubitux> sure [23:26:33 CET] <ubitux> okay [23:26:48 CET] <ubitux> i think supporting the styles and positioning correctly is important though [23:27:05 CET] <ubitux> that test case with the expected output on youtube could be a good check [23:27:20 CET] <ubitux> since it's showing how tv are displaying them [23:27:39 CET] <ubitux> it's using various charset, colors and positioning [23:39:28 CET] <durandal_1707> michaelni: so no other examples for fftfilt? [23:40:00 CET] <durandal_1707> I tried some and failed [23:45:48 CET] <tmm1> ubitux: positioning looks equivalent, colors and charsets are obviously still missing [23:49:13 CET] <michaelni> fftfilt=weight_Y='cos(X)' [23:49:20 CET] <michaelni> but i dont know what to call it [23:52:03 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:fc2588a1d6cb: swscale/vscale: Use matching sliceY/chrSliceY for luma/chroma [23:52:04 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:80fd348bb7d9: avformat/rmdec: Check size in ivr_read_packet() before use [23:52:05 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:c3a24006d552: avformat/rmdec: Fix Packet memleak at close() [00:00:00 CET] --- Fri Jan 15 2016

1 0

ffmpeg.log.20160114
by burek 15 Jan '16

15 Jan '16

[00:37:19 CET] <durandal_170> thetrueavatar: nope [00:52:48 CET] <rkantos> Hi.. Could someone give me a simple way to test h264_qsv or check why I'm getting these errors from this command? ffmpeg -i test.nv12.mp4 -b:v 2000k -maxrate 2000k -c:v h264_qsv out.qsv.mp4 [00:52:58 CET] <rkantos> [h264_qsv @ 0000000002c20b00] Selected ratecontrol mode is not supported by the QSV runtime. Choose a different mode. [01:37:18 CET] <rkantos> hmm... [01:37:29 CET] <rkantos> does the h264_qsv require opencl support? [02:05:29 CET] <Hfuy> Hello. [02:05:42 CET] <Hfuy> If it says "Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))", does that imply it's reencoding? I asked for -c:v copy [02:06:01 CET] <c_14> yes [02:06:12 CET] <Hfuy> Gah. [02:06:46 CET] <Hfuy> My commandline is something like c:\ffmpeg -i "g:\U5 60439down2 R0-4.m4v" "D:\e1.mp4" -c:a copy -c:v copy [02:06:57 CET] <Hfuy> should be fairly straightforward, you'd think [02:07:13 CET] <c_14> options have to be before the output file [02:07:19 CET] <c_14> Otherwise they're not aplied [02:07:21 CET] <c_14> *Output options [02:07:23 CET] <c_14> *applied [02:07:24 CET] <Hfuy> Really? I thought things after the output was global. [02:07:26 CET] <Hfuy> Has that changed? [02:07:36 CET] <c_14> There is no "global" position. [02:07:47 CET] <c_14> per-file options have to placed before the file they affect [02:07:51 CET] <c_14> global options can be placed wherever [02:07:57 CET] <c_14> the -c option is not global [02:09:40 CET] <Hfuy> Holy hell. 25600 frames per second to rewrap it? [02:09:51 CET] <Hfuy> Oh well, I guess that's the power of a big RAID. [02:13:30 CET] <Hfuy> The whole file's only about 90,000 frames. I guess 1GB file by 350MB/second disk performance... [02:13:44 CET] <Hfuy> I'm surprised it can get it through the CPU that fast. [02:16:16 CET] <c_14> You're just remuxing. The only real limit is how fast you can copy data into RAM and write it back to disk. The actual remuxing has little overhead. [02:16:27 CET] <Hfuy> Well, yes, but even so. [02:16:46 CET] <Hfuy> In the case of m4v to mp4, is it really just throwing a header on it? [02:17:06 CET] <Hfuy> I guess it has to build a basic atom structure but essentially it's a header and perhaps a tail end. [02:33:26 CET] <waressearcher2> I can type 100000 characters per second using vim [03:32:17 CET] <kepstin> um, I have a faster way to remux m4v to mp4. "mv file.m4v file.mp4" [03:32:40 CET] <kepstin> (they're different extensions for the same format...) [03:58:03 CET] <hackman42> I'm currently using libVLC for MPEG2 video playback in a tvOS app. Can I just use ffmpeg instead? [04:03:57 CET] <an3k> Hi, I'm trying to compile ffmpeg and some other stuff and followed https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu but I still get this error http://pastebin.com/7c2biMFq [04:04:27 CET] <an3k> The ./configure I used is http://pastebin.com/Z9sx7nK7 [04:05:40 CET] <an3k> I mean http://pastebin.com/GXwP4Bbf [04:16:12 CET] <SpootDev> don't think I had to do the fpic in ubuntu...lemme look [04:20:31 CET] <SpootDev> yeah, in Alpine linux I had to mess with fpic, but not in ubuntu. I wrote a script awhile ago to help with my build/deployments if you wanna try it https://github.com/Meta-Man/Meta-Man.Build/blob/dev-0.0.3/build_deployment_… pretty sure it won't eat a kitten [04:21:27 CET] <SpootDev> cuz kittens give Morbo gas [04:22:33 CET] <an3k> hehe thanks :) [04:22:46 CET] <an3k> Is it possible that maybe L-SMASH Works is the problem? [04:23:00 CET] <SpootDev> no clue [04:53:56 CET] <an3k> yep, it was L-SMASH Works ... it always wanted to build shared libs and when forced to build static ones it couldn't find its dependencies [04:54:18 CET] <an3k> oh come one ... /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginT.o: relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC [04:54:31 CET] <an3k> Guess I'll simply ignore L-SMASH :( [09:23:13 CET] <abuisson> Hi, I would like to know how to bypass MP4 metadata (moov/udta atom) while doing a remux... for example while doing a simple copy 'ffmpeg -i IN -c:v copy -c:a copy -c:d copy OUT' or a more complex mapping 'ffmpeg -i IN1 -i IN2 -map 0:0 -map 1:1 -c copy -movflags +faststart OUT' ? [09:25:08 CET] <waressearcher2> abuisson: hallo und herzlich willkommen [10:24:47 CET] <sgo11> http://pastebin.ubuntu.com/14494824/ I am capturing videos from an usb camera with ubuntu 14.04 LTS. (1), How can I use 30 or 25 fps with my usb camera? The driver always forces to use 1/15. (2), How can I use MJPG instead of yuyv422 ? thanks a lot. [10:25:49 CET] <sgo11> I did google, some post suggests to use -input_format mjpeg, but my ffmpeg does not have that option argument. [11:14:03 CET] <Mavrik> sgo11, hmm, if you're missing -input_format I guess you should update your ffmpeg first to get it. [11:14:16 CET] <Mavrik> As for framerate, I'm concerned because even v4l2 tool doesn't say anything about your device supporting 30fps [11:14:24 CET] <Mavrik> and the output says "driver switched fps" [11:14:50 CET] <Mavrik> It's entirely possible that's due to you using raw instead of mjpeg input though (not enough bandwidth) [11:15:15 CET] <sgo11> Mavrik, v4l2-ctl --list-formats-ext shows 30fps, is that incorrect? I am using ffmpeg from a ppa repo. this is the latest version in that repo... [11:15:36 CET] <Mavrik> can you pastebin that output? [11:15:59 CET] <Mavrik> As for PPA... I guess it's not up to date enough, that's usually the case for all Ubuntu deb packaging repos [11:17:12 CET] <Mavrik> Are you using this PPA: https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media ? Because your version string isn't from a stable release :/ [11:18:11 CET] <sgo11> Mavrik, actually, even if the output video shows 15fps. I don't think that is true. I am bad in English. the video is very slow (lag?). not sure how to express. it is the same result as 4 fps. can I trust the output video info? [11:19:01 CET] <sgo11> Mavrik, I am using http://ppa.launchpad.net/mc3man/trusty-media/ubuntu/. yeah. [11:19:42 CET] <sgo11> Mavrik, The previous pastebin link has output of v4l2-ctl --list-formats-ext. [11:20:15 CET] <Mavrik> hmmmm. [11:21:19 CET] <Mavrik> sgo11, try "v4l2-ctl --set-parm=30" and then run ffmpeg? [11:21:26 CET] <sgo11> I am using motion to do motion detection and video output before. it always outputs 4 fps even with mjpeg. I don't know why. that's why I am trying ffmpeg directly. even if ffmpeg shows 15 fps. but the result video is just the same as motion output video 4fps one. [11:22:01 CET] <sgo11> I will try that now. [11:22:28 CET] <Mavrik> ah :/ [11:23:13 CET] <sgo11> Mavrik, I didn't start the capturing. the output is weird. $ v4l2-ctl --set-parm=30 >> Frame rate set to 5.000 fps [11:23:27 CET] <sgo11> I haven't started [11:23:28 CET] <Mavrik> huh. [11:23:30 CET] <Mavrik> That IS wierd. [11:23:57 CET] <sgo11> do I need sudo? I didn't try sudo [11:24:06 CET] <Mavrik> Nah... hrmf. [11:24:13 CET] <Mavrik> sgo11, ok, let's try setting resolution first [11:24:33 CET] <Mavrik> v4l2-ctl --set-fmt-video=width=640,height=480,pixelformat=1 [11:24:39 CET] <Mavrik> v4l2-ctl --set-parm=30 [11:24:42 CET] <Mavrik> Does that work? [11:25:12 CET] <Mavrik> (It seems like the camera thinks it's set to 1600x1200( [11:25:17 CET] <sgo11> Mavrik, it works. at least, the output shows: Frame rate set to 30.000 fps [11:25:28 CET] <Mavrik> Try capture now at 640x480 [11:25:32 CET] <Mavrik> It should now be mjpeg as well. [11:25:47 CET] <Mavrik> (pixelformat=1 - mjpeg, pixelformat=0 - yuv422) [11:25:50 CET] <sgo11> ok. I will run this command again: "ffmpeg -f v4l2 -framerate 30 -video_size 640x480 -i /dev/video1 output.mkv" [11:27:27 CET] <sgo11> Mavrik, not really. set to 15fps again. http://pastebin.ubuntu.com/14495070/ [11:28:11 CET] <sgo11> Mavrik, maybe 15fps is OK for me. but I just doubt the output video is really 15 fps. it looks exactly the same as 4 fps one created by motion. [11:29:00 CET] <sgo11> Mavrik, this is the motion log if you are interested: http://pastebin.ubuntu.com/14494999/ [11:29:55 CET] <sgo11> the motion log has event_new_video FPS 4. whatever I tried to modify motion.conf, it's always 4 fps. [11:33:25 CET] <sgo11> the usb camera has Low luminance compensation function. (I am not sure how to say this properly in English). Will that result in low fps? can I turn it off somehow? [11:35:00 CET] <sgo11> I did google, maybe it should be called "Low light compensation". that is a function in the usb camera device hardware. [11:47:40 CET] <Mavrik> sgo11, yes, motion detection, luminance correction, etc. can mess up your FPS and cause camera to batch frames [11:51:30 CET] <sgo11> Mavrik, this is the output of --list-ctrls: http://pastebin.ubuntu.com/14495164/ how to turn off luminance correction? should I change backlight_compensation or exposure_auto or something else? [11:53:13 CET] <sgo11> by the way, with v4l2-ctl --set-ctrl or v4l2-ctl --set-fmt-video, will this affect the result permanently? or will this lose after a reboot? [12:00:26 CET] <Taoki> Hello. How do I make ffmpeg ignore missing frames when compiling a series of png files? It works if for instance I have 001.png + 002.png + 003.png, but not if I have 001.png + 003.png. [12:00:33 CET] <Taoki> I tried using the -r flag but no difference. [12:00:44 CET] <Taoki> Currently it stops at 001.png. [12:05:45 CET] <Taoki> Got it! Simply had to use %*.png [12:39:03 CET] <sgo11> Mavrik, some updates. after I set exposure_auto to be manual and then set exposure_absolute to be 900. motion software can output 11 fps video now. I tried ffmpeg command directly, the result is the same as motion software. Now, I have three questions hopefully if you or anyone can answer me. [12:39:06 CET] <sgo11> (1), from my test, is the fps determined by usb cam hardware only? no software arguments can change anything. (2), does v4l2-ctl --set-ctrl affect the param permanently? if no, how to make it permanent? (3) now, I am pretty sure ffmpeg shows fps info incorrectly. Even if the output video shows 15 fps and all player such as vlc tells me 15 fps. but it's wrong. before it was 4 fps and now it's 11 fps. how can I tell the true fps from the video file? [14:10:40 CET] <sgo11> brb [14:55:31 CET] <an3k> Hi, when I configure libvpx with --disable-static latest ffmpeg from git complains about libvpx being too old (>= 0.9.1) [14:55:53 CET] <an3k> with just this option left out everything is fine again. [15:30:34 CET] <flamia> so... are we supposed to use h265 yet? [15:31:30 CET] <flamia> only issue i see is that even with veryfast preset is really slow [15:32:47 CET] <flamia> nvm i get the same speed using medium [15:34:39 CET] <Mavrik> Well, the encoder is slow as heck and the HW decoders are very rare. [15:34:55 CET] <Mavrik> So most people won't be able to watch your output comfortably :) [15:35:04 CET] <an3k> but the files are sooo tiny :) [15:35:07 CET] <flamia> you're saying that even watching is expensive? [15:35:12 CET] <flamia> O.o [15:35:35 CET] <flamia> is crf working the same as in h264? [15:35:41 CET] <an3k> ever compared a crf22 H.264 with a crf22 HEVC? :) [15:35:57 CET] <flamia> does the crf point at the same quality? [15:36:20 CET] <flamia> yeah. i read 50% smaller [15:36:24 CET] <an3k> more [15:36:49 CET] <flamia> i encode at 24 frame per second [15:37:11 CET] <an3k> I don't know if both do the same crf but afaik they do, especially I couldn't find as much settings as for x264 [15:37:35 CET] <flamia> i only set crf [15:38:08 CET] <flamia> but hardware decoding is on some new pc or still not? [15:38:36 CET] <an3k> in HEVC i do so too but in H.264 I did set more [15:40:01 CET] <an3k> welcome J_Darnley :) [15:40:13 CET] <an3k> libx264: PATH="$HOME/bin:$PATH" ./configure --prefix="$HOME" --enable-shared [15:40:24 CET] <an3k> libx265: PATH="$HOME/bin:$PATH" cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX="$HOME" -DENABLE_SHARED:bool=on ../../source [15:41:15 CET] <an3k> libvpx: PATH="$HOME/bin:$PATH" ./configure --prefix="$HOME" --disable-examples --disable-unit-tests --disable-static [15:41:51 CET] <an3k> ffmpeg: PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/lib/pkgconfig" ./configure --prefix="$HOME" --extra-cflags="-I$HOME/include" --extra-ldflags="-L$HOME/lib" --disable-static --enable-shared --enable-gpl --enable-avresample --enable-libvpx --enable-libx264 --enable-libx265 [15:42:44 CET] <flamia> probably intel skylake wil support h265 [15:43:05 CET] <an3k> and the result was ffmpeg complained about the libvpx version being too old. As soon as I ran configure for libvpx without --disable-static (followed by make; make install) again ffmpeg wasn't complaining anymore [15:43:37 CET] <J_Darnley> So what does ffmpeg's config.log say? [15:43:37 CET] <flamia> what about youtube? still using h264? [15:44:00 CET] <furq> youtube uses h264 and vp9 [15:48:23 CET] <an3k> J_Darnley: sorry, the correct ffmpeg configure is PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/lib/pkgconfig" ./configure --prefix="$HOME" --extra-cflags="-I$HOME/include" --extra-ldflags="-L$HOME/lib" --disable-static --enable-shared --enable-gpl --enable-avresample --enable-libvpx --enable-libx264 --enable-libx265 [15:49:04 CET] <an3k> config.log http://pastebin.com/hgrkfrqY [15:50:04 CET] <J_Darnley> So.. what's in ~/lib? [15:51:43 CET] <an3k> no vpx lib at all [15:52:06 CET] <J_Darnley> Then I guess your problem lies with vpx. [15:52:19 CET] <J_Darnley> Does it need --enable-shared? [15:56:03 CET] <an3k> Hmm. Let me start from scratch. This is currently too confusing. But you answer your Q: It has the --enable-shared option but did not failed when just --disable-static is set. [15:56:55 CET] <J_Darnley> Perhaps libvpx behaves like x264. [15:57:26 CET] <J_Darnley> You need to enable whichever library you want. [15:58:11 CET] <J_Darnley> Or do I mean like ffmpeg [15:58:14 CET] <J_Darnley> Whichever [15:58:32 CET] <an3k> :) [15:58:34 CET] <J_Darnley> Try --enable-shared if you want a shared lib from it [15:59:03 CET] <an3k> yeah I just did but ran into other errors now I didn't had before. That's what I meant with confusing and starting from scratch [16:01:41 CET] <J_Darnley> ah ok [16:19:50 CET] <an3k> J_Darnley you're right. I missed --enable-shared which caused in no libs getting made at all. That is however different from libx264 and libx265 as well as ffmpeg itself. Sorry for distraction and confusion [16:33:38 CET] <J_Darnley> Don't worry. [17:02:49 CET] <Prelude2004c> hey everyone good day.. is there any way to have ffmpeg exit if frames per second drop below 20 for example ? [17:03:53 CET] <kepstin> Prelude2004c: why do you want to do that? [17:04:53 CET] <Prelude2004c> because i am picking up some sources from europe and sometimes ffmpeg drops below 20fps .. then i restart the stream get and it picks back up [17:04:54 CET] <Prelude2004c> its odd [17:06:25 CET] <Prelude2004c> it is odd.. i dont know why it does that [18:40:15 CET] <askldjd> Hey, quick question. I'm running ffmpeg via command line two different ways. The first way, I'm taking input from stdin and outputting to file.ogg. The second way, I'm taking input from stdin and outputting to stdout, then capturing stdout with another app and writing that to file.ogg. The outputs from these two methods are very different. [18:40:32 CET] <askldjd> The first works and creates a valid ogg file that I can play. The second does not. [18:41:17 CET] <askldjd> Looking in a hex editor, I am getting sane data from stdout written to my file, but some of the header data is just... different (not wrong - but different from method 1) [18:41:51 CET] <askldjd> Using this in method 1: var ffmpeg = execFile('ffmpeg.exe', ['-f', 'alaw', '-ar', '16415', '-i', '-', '-f', 'oga', '-codec:a', 'libvorbis', '-qscale:a', '2', 'stuff.ogg']); [18:42:00 CET] <askldjd> and this for method 2: var ffmpeg = execFile('ffmpeg.exe', ['-f', 'alaw', '-ar', '16415', '-i', '-', '-f', 'oga', '-codec:a', 'libvorbis', '-qscale:a', '2', '-']); [18:42:28 CET] <askldjd> am I missing some option that ffmpeg is implying when the output file is specified versus when the output is to stdout? [18:44:17 CET] <askldjd> The file size for method 2 also ends up being about double that for method 1. Not sure what the heck it's doing. [18:59:20 CET] <podman> I'm starting to wonder if HLS might make more sense than DASH right now [18:59:42 CET] <JEEB> yes, it is generally much better supported [18:59:59 CET] <JEEB> also I feel like HLS.js will be a better alternative to DASH.js for the MSE camp [19:00:58 CET] <podman> Yeah, if I wanted to support ABS on iOS, I'd need to use HLS because safari doesn't support MSE yet [19:01:58 CET] <podman> and I have no idea what android supports [19:02:22 CET] <JEEB> android >= 4 supports HLS and there's a pretty good DASH library from google [19:02:46 CET] <furq> hls.js apparently works in android chrome [19:02:57 CET] <podman> yeah, looks like chrome on android supports MSE [19:03:16 CET] <podman> so, dash works everywhere except iOS [19:03:23 CET] <podman> HLS works pretty much everywhere? [19:03:39 CET] <JEEB> (meanwhile the DASH player for MSE from Google is not really good... of course if you are mostly aiming at Chrome and you are using a very limited subset of things in DASH it will work) [19:03:52 CET] <podman> yeah, just regular VoD stuff [19:04:00 CET] <JEEB> even for VoD [19:04:00 CET] <podman> it's pretty good at that [19:04:10 CET] <JEEB> I was able to use libavformat and create stuff it really didn't like [19:04:31 CET] <JEEB> ffmpeg cli does some timestamp/packet dropping that causes that kind of stuff not to be created I guess [19:04:36 CET] <podman> yeah, i'm not trying to create some things it doesn't like [19:04:56 CET] <podman> haven't really had issues with it yet [19:05:12 CET] <JEEB> it's not like I'm *trying* , just noting that I'd say that in general you'd be seeing more compatible implementations on the DASH side [19:05:15 CET] <JEEB> uhh [19:05:16 CET] <JEEB> HLS side [19:06:16 CET] <JEEB> anyways, it's always "fun" to see how lavf and ffmpeg cli create different stuff due to the random things ffmpeg cli does :) [19:06:26 CET] <podman> anyway. Seems like hls gets support in any desktop browser that supports MSE, support in iOS, support in android either though MSE or native support, flash though any number of libraries for fallback if needded [19:06:27 CET] <JEEB> (ffmpeg cli uses lavf internally) [19:06:36 CET] <JEEB> yeah [19:06:49 CET] <podman> DASH is missing iOS which is kind of a big issue [19:07:02 CET] <podman> i'd need to make HLS representations anyway [19:07:03 CET] <podman> hmm [19:19:41 CET] <podman> dash.js doesn't support mpeg-2 TS containers, right? that way i could pretty much use the segments interchangeably and just have a MPD and M3U8 for dash and hls respectively? [19:19:59 CET] <JEEB> most probably not [19:20:51 CET] <podman> i guess i could write my own? [19:21:09 CET] <JEEB> I... guess [19:21:20 CET] <JEEB> dash.js seems like something /very/ over-engineered tho [19:23:37 CET] <furq> why would you do that instead of just using hls [19:23:56 CET] <furq> other than the vague spectre of deprecation [19:24:03 CET] <podman> pretty much that [19:24:24 CET] <furq> as long as there's a working js implementation you should be pretty much fine [19:24:37 CET] <furq> unless ios devices all retroactively move to dash [19:25:13 CET] <podman> which is unlikely, sure [19:30:10 CET] <podman> i guess potentially a bigger issue is HEVC [19:34:18 CET] <furq> yeah if you need any features which aren't already in hls.js then you'll be waiting for apple to maybe release some specs if they feel like it [19:35:10 CET] <podman> What does youtube do for iOS in safari? [19:36:48 CET] <podman> interesting, just progressive download [19:37:04 CET] <furq> i think they use hls for livestreaming [19:37:22 CET] <furq> for vod then i assume they use http like they did pre-dash [19:37:32 CET] <podman> yeah, that's what it looks like [19:37:32 CET] <furq> which is restricted to 360p and 720p [19:37:43 CET] <furq> s/then// [19:37:56 CET] <podman> which is also what we currently do [19:38:45 CET] <furq> i internally associate dash with massive headaches because seeking was broken for me on youtube for about a year after they deployed it [19:38:57 CET] <furq> and then the whole MSE-on-firefox fiasco [19:39:29 CET] <furq> it's probably an unfair assessment though [19:48:47 CET] <podman> I've just started messing around with it and am pretty happy so far [19:48:55 CET] <podman> but lack of iOS support is very annoying [19:50:47 CET] <shincodex> then gut the makefile for it. [19:51:53 CET] <furq> what [19:55:45 CET] <shincodex> trying to figure out if pthreadA can write to memory of heap allocated array [19:56:01 CET] <shincodex> while pthreadB can read another section of heap allocated array [19:56:04 CET] <shincodex> without a mutex [19:56:09 CET] <shincodex> or locking of any form safely [22:50:09 CET] <vidjufeffex> Can anyone help me find a single example that use the -time_base flag in ffmpeg or the "timebase" option using x264opts, the former is an unrecognized command the latter comes up as a bad option [22:57:23 CET] <Asterisk> Is there an effective way to chain multiple scalers together in FFMpeg without having to write to an intermediate file? [22:58:25 CET] <J_Darnley> Use more than 1filter [22:59:33 CET] <Asterisk> How can I set sws_flags separately for each filter in the sequence? [23:00:39 CET] <J_Darnley> give a flags argument to each scale filter [23:00:41 CET] <J_Darnley> http://ffmpeg.org/ffmpeg-filters.html#scale-1 [23:08:09 CET] <Asterisk> Ah, I need to set the sws_flags paramater within each -vf block, not preceding them. [23:08:10 CET] <Asterisk> Thanks. [23:09:44 CET] <J_Darnley> What do you mean "each block" You can only have 1 [23:11:38 CET] <Asterisk> I guess I need to study the filtergraph syntax more thoroughly. [23:12:18 CET] <J_Darnley> -vf "scale=w:h:flags=X,scale=w:h:flags=X" [23:12:31 CET] <J_Darnley> (why you wantto do this I have no idea) [23:12:32 CET] <Asterisk> Thanks. [23:15:16 CET] <Asterisk> It's for classic DOS game videos. They usually have a source resolution of 320x200, but a pixel aspect ratio of 5:6. So the best way to make a 720p or 1080p video that both preserves the original pixely graphics and corrects the aspect to 4:3 is to upscale to 1600x1200 with a point scaler, then use an interpolative scaler to downscale to e.g. 1440x1080. [23:15:49 CET] <J_Darnley> Oh god! Use an aspect ratio! [23:15:54 CET] <Asterisk> I was previously using Avisynth to do it, but I wanted to push everything directly to FFMpeg so it could be easily automated. [23:16:06 CET] <Asterisk> What do you mean? [23:16:43 CET] <J_Darnley> scale to whatever multiple you want then... what's the option? let me look [23:17:17 CET] <J_Darnley> -aspect 4:3 [23:17:46 CET] <J_Darnley> Or I'm sure there's a filter for that too [23:18:43 CET] <Asterisk> But the point scale to 1600x1200 already corrects the aspect ratio without distortion. [23:19:08 CET] <J_Darnley> Oh yes [23:19:14 CET] <J_Darnley> why are you scaling twice then? [23:19:46 CET] <Asterisk> To scale down to 1080 or 720 vertically *with* interpolation. [23:20:15 CET] <J_Darnley> i hate people [23:20:17 CET] <Asterisk> The goal is to preserve the pixels. [23:21:23 CET] <durandal_1707> there is xbr and supersai and hqx filter [23:22:01 CET] <Asterisk> Those attempt to smooth away the pixels. [23:22:37 CET] <Asterisk> I'm trying to replicate the original appearance of the game graphics. [23:22:39 CET] <durandal_1707> nope. Have you tried it? [23:23:25 CET] <durandal_1707> what's wrong using single scale filter? [23:23:40 CET] <durandal_1707> you can chain filters [23:23:58 CET] <Asterisk> That's what I'm doing -- chaining two scaling filters. [23:23:59 CET] <durandal_1707> -vf scale,scale,scale,.... [23:24:38 CET] <Asterisk> Upscale to 1600x1200 with a nearest-neighbor scaler, then use interpolation to downscale to 1440x1080 from there. [23:26:10 CET] <durandal_1707> using sws_flags options? [23:27:20 CET] <Asterisk> Right. I set "neighbor" for the upscale, and "lanczos" for the "downscale". [23:28:42 CET] <furq> do you really need nearest scaling [23:28:51 CET] <furq> i've upscaled plenty of game footage with bilinear and it looks fine [23:29:19 CET] <Asterisk> I don't think upscaling with bilinear looks fine at all. [23:29:28 CET] <TD-Linux> ick, not retro games :) [23:29:32 CET] <Asterisk> It fuzzes all of the pixel boundaries. [23:29:59 CET] <furq> shrug [23:30:04 CET] <Asterisk> I'm upscaling DOS games with a res of 320x200 and non-square pixels. [23:30:05 CET] <TD-Linux> (but there are possibly better upscalers than nearest that would antialias the pixel boundaries, essentially) [23:30:06 CET] <furq> i use bilinear scaling in mame [23:30:14 CET] <furq> maybe i've just got used to it [23:30:16 CET] <TD-Linux> you monster [23:30:32 CET] <TD-Linux> are you sure it's actually bilinear scaling though? [23:30:38 CET] <Asterisk> But antialiasing the pixel boundaries would make it worse, not better. You're supposed to see discrete pixels. [23:30:44 CET] <furq> it says it's bilinear scaling in the options [23:30:59 CET] <furq> actually it says "bilinear filtering" [23:31:55 CET] <TD-Linux> https://github.com/haasn/mpvhq-upscalers/blob/master/Ark-small.md [23:31:55 CET] <durandal_1707> Asterisk: discrete 32x32 blocks [23:31:58 CET] <Asterisk> Bilinear filtering in game options usually refers to upscaling textures for 3D. [23:32:12 CET] <TD-Linux> it might be only doing bilinear on the boundaries [23:32:57 CET] <Asterisk> TD-Linux: Only "oversample" is showing proper graphics in those shots. Everything else is horribly distorted. [23:33:21 CET] <Asterisk> durandal_1707: ? [23:33:32 CET] <TD-Linux> Asterisk, I linked it only for bilinear, none of those scalers are designed for pixel art [23:34:10 CET] <JEEB> Asterisk: btw I recommend you try the zimg-library based zscale library for the non-nearest neighbor scaling :) [23:34:12 CET] <Asterisk> TD-Linux: Exactly -- that's why I'm using the nearest-neighbor upscale initially. [23:34:36 CET] <JEEB> s/zscale library/zscale filter/ [23:34:41 CET] <durandal_1707> He mentioned he don't want pixel art [23:35:03 CET] <Asterisk> JEEB: I tried that with VapourSynth, and it works pretty well, but I wanted to automate everything with FFMpeg. [23:35:20 CET] <JEEB> durandal_1707 made a filter into FFmpeg using zimg :P [23:35:25 CET] <JEEB> which is called zscale [23:35:32 CET] <Kenneth___> I'm looking for documentation on using SIGINT to terminate ffmpeg but I can't find it any more [23:35:38 CET] <JEEB> (as opposed to 'scale') [23:35:50 CET] <Kenneth___> Is that still supported? Is it documented anywhere? [23:35:58 CET] <Asterisk> Ah, cool, I'll give that a try. [23:37:15 CET] <JEEB> also zimg is now the default scaler @ vs, which is <3 [23:38:02 CET] <durandal_1707> but its slower [23:38:58 CET] <Asterisk> Meh, I need to recompile ffmpeg to support zscale. [23:40:15 CET] <durandal_1707> indeed [23:40:43 CET] <JEEB> durandal_1707: uhh I'm not going to comment on the FFmpeg vf wrapper's speed, but the base library and the VS wrapper of it are pretty fast enough [23:41:07 CET] <JEEB> and IIRC threads much better than swscale in VS, although I'd have to actually get some numbers out for that [23:41:17 CET] <durandal_1707> compared to swscale [23:41:47 CET] <JEEB> but to be honest, even if the FFmpeg vf wrapper would be slower, as long as it's not unbearably slow I'd use it [23:41:54 CET] <durandal_1707> Yes I want numbers [23:41:55 CET] <JEEB> correct >= SUPAH OPTIMIZED [23:42:12 CET] <JEEB> although zimg has plenty of rice in it too [23:43:13 CET] <durandal_1707> it have no real support for packed formats [23:43:33 CET] <durandal_1707> last time I looked [23:43:53 CET] <JEEB> sure, I didn't say it was more universal in that sense [23:44:19 CET] <durandal_1707> Its shame [23:44:32 CET] <TD-Linux> this is still my favorite upscaling https://my.mixtape.moe/babbpi.jpg [23:44:47 CET] <TD-Linux> unfortunately it's a lot heavier than ffmpeg [23:46:23 CET] <furq> ok that took far too long to figure out how to get a filtered screenshot out of mame, but [23:46:36 CET] <furq> http://i.imgur.com/H480tei.png is uglier than http://i.imgur.com/Kt8GKaG.jpg [23:46:56 CET] <TD-Linux> yeah that's not bilinear [23:47:31 CET] <furq> the only difference is that i enabled "bilinear filtering" [23:47:49 CET] <TD-Linux> err the second screenshot is [23:47:53 CET] <furq> oh right [23:48:09 CET] <llogan> has anyone compared yadif and w3fdif lately? [23:49:10 CET] <furq> but yeah pixels aren't supposed to look that crisp and i don't like any of the faux crt filters [23:49:24 CET] <furq> not that mame comes with any [23:50:07 CET] <Asterisk> furq: That's a console/arcade game, anyway. Pixels *should* look nice and crisp for PC games that were intended for use with RGB displays. [23:51:03 CET] Action: TD-Linux still has one of those sony rgb monitors on his "holy grail" list [23:57:27 CET] <Asterisk> Compare with EGA graphics - http://i.imgur.com/RL3Sxfq.png vs. http://i.imgur.com/Ochy0nK.png [00:00:00 CET] --- Fri Jan 15 2016

1 0

ffmpeg-devel.log.20160113
by burek 14 Jan '16

14 Jan '16

[00:00:23 CET] <michaelni> or various state machines that do multiple symbols at once (i think thats what the referenced code does but i didnt look too closly) [00:01:33 CET] <michaelni> also its possible t merge the qoffset/qfactor into the used VLC/LUT which would avoid a * + >> and the seperate sign handling (it could all be done in te table at init time) [00:02:16 CET] <michaelni> that would require 128 such tables though IIUC but in reallity probably only very few would see much use cpu cache wise [00:03:12 CET] <kierank> i see [00:05:24 CET] <kierank> I was thinking of removing the quantise and doing it in simd [00:05:31 CET] <kierank> de-quant* [00:07:01 CET] <michaelni> thats possible too, but it competes with doing it in the tables, question is which is faster. For 8x8 IDCTs in mpeg IIRC SIMD dequent is slower than doing it without SIMD but that was long ago [00:07:28 CET] <michaelni> in mpeg the large number of 0 elements kill SIMDs advantage [00:09:26 CET] <kierank> I see [00:34:23 CET] <kierank> my suspicion at high bitrate dirac there won't be a lot of zeros [00:36:36 CET] <atomnuker> depends on screen content [00:37:23 CET] <atomnuker> at 3 level transforms images upscaled from 480 or 720 won't have much at all in the HH orientation of the last level [00:38:19 CET] <kierank> those are most likely to have the zero end termination thing though [00:41:27 CET] <atomnuker> well, they would have 1*right-left*bottom-top*levels*4 bits, all one [00:42:04 CET] <atomnuker> without any padding and the 32ish bits used for quantization and padding signalling [00:55:38 CET] <kierank> michaelni: also for transforms am I right in saying the inplace transform is just coefficient reordering? [00:55:43 CET] <kierank> and no transform changes? [00:57:27 CET] <kierank> and also is there a reason you didn't change the golomb read function to open the bitstream once per slice [01:00:00 CET] <J_Darnley> Sometimes I really hate the amount of macros used in assmebly [01:16:08 CET] <michaelni> kierank, yes, inplace vs non inplace is generally a matter of reordering [01:16:32 CET] <kierank> interesting so I could write simd and then do the inplace reordering later? [01:17:46 CET] <michaelni> i dont know the dirac code well enough to say that for certain [01:18:30 CET] <michaelni> about opening the bitsteram reader just once per slice, that would be better yes [01:19:04 CET] <michaelni> no reason why i didnt except not immedeatly seeing a pretty way to do it [01:19:13 CET] <kierank> yeah it's not going to be pretty [01:19:16 CET] <kierank> might just do it for hq [01:30:20 CET] <J_Darnley> idontunderstandanyofthis [02:05:07 CET] <J_Darnley> oh come on! you shouldn't abuse t# for simd registers [03:11:04 CET] <cone-117> ffmpeg 03Michael Niedermayer 07master:115fb6d03ef6: avformat/aviobuf: Fix end check in put_str16() [03:11:04 CET] <cone-117> ffmpeg 03Michael Niedermayer 07master:9ca64c31d2f4: avutil/common: Protect GET_BYTE in GET_UTF8() by () [09:04:42 CET] <cone-514> ffmpeg 03Carl Eugen Hoyos 07master:d3fe2e0dc991: lavc/mjpeg2jpeg: Accept more mjpeg streams as input. [09:29:04 CET] <omerjerk> Hi [09:29:43 CET] <omerjerk> yesterday @durandal_170 mentioned about libavfilter GUI for possible GSoC project. [09:29:59 CET] <omerjerk> I'll keep it in mind. [09:30:27 CET] <omerjerk> Any other ideas which I can think of, just in case ? [09:44:16 CET] <wm4> the libavfilter gui idea was generally rejected [09:44:40 CET] <wm4> there's a projects idea page on the wiki somewhere [09:44:53 CET] <omerjerk> there is a wiki for gsoc 2015 [09:45:01 CET] <omerjerk> are you talking about that ? [09:48:37 CET] <wm4> not sure didn't look myself [09:51:07 CET] <durandal_1707> there is wiki on trac.ffmpeg.org [09:53:40 CET] <durandal_1707> another idea is adding float pixel format to libswscale [10:02:50 CET] <omerjerk> thanks :) [10:07:57 CET] <wm4> wow what is this teletext thing [10:09:23 CET] <wm4> that's more of a pain than you'd expect, and for such an outdated technology [10:11:01 CET] <durandal_1707> teletext is outdated? [10:13:04 CET] <durandal_1707> should the our vorbis encoder be removed? [10:42:31 CET] <nevcairiel> outdated yes, but still in use anyway [11:44:14 CET] <Fyr> hey guys, is it possible that this bug: [11:44:14 CET] <Fyr> https://trac.ffmpeg.org/ticket/4905 [11:44:14 CET] <Fyr> has been already solved? [11:51:01 CET] <wm4> if you can't reproduce it with exactly the same steps, it might be possible [11:56:32 CET] <kierank> We need to reject ideas for gsoc asap [11:56:40 CET] <kierank> Can't have this webserver thing happen again [11:57:20 CET] <Compn> so start putting "keirank rejected" after each idea [11:57:21 CET] <Compn> :) [12:31:57 CET] <wm4> kierank: reuse the old ideas? some were even good [12:32:24 CET] <kierank> The crap ones [12:33:12 CET] <wm4> man, I read "reject" as "project" [13:16:05 CET] <kierank> why is he adding teletext [13:16:11 CET] <kierank> just use libzvbi for god's sake [13:16:30 CET] <kierank> ffmpeg shouldn't be the place for analogue processing [13:20:04 CET] <bencoh> kierank: libzvbi is GPL, that might explain why [13:20:14 CET] <kierank> er is it? [13:20:26 CET] <kierank> https://github.com/kierank/libzvbi-obe-dev/blob/master/COPYING.LIB [13:20:29 CET] <bencoh> "The Zapping VBI library, in short ZVBI, provides functions to capture and decode VBI data. It is written in plain ANSI C with few dependencies on other tools and libraries, licensed under GPL. Some features:" [13:20:40 CET] <bencoh> maybe this isnt up-to-date? [13:21:23 CET] <kierank> the lib is lgpl [13:21:28 CET] <kierank> https://github.com/kierank/libzvbi-obe-dev/blob/master/src/libzvbi.h [13:21:33 CET] <kierank> I've always based it off that [13:22:21 CET] <bencoh> ah, nevermind then [13:22:39 CET] <kierank> grr damn email client sending a blank email [13:26:53 CET] <wm4> haha [13:27:01 CET] <wm4> I just wondered about that [13:27:49 CET] <kierank> his code isn't robust enough for the crazy analogue shit you get [13:49:02 CET] <ChALkeR> Is there a better work-around for now around that recent security issue than building with --disable-network? [13:49:43 CET] <J_Darnley> Don't connect to a network? [13:49:43 CET] <ChALkeR> more specfic: which workaround should the downstream (distros) apply? [13:50:17 CET] <ChALkeR> J_Darnley: tell all users to don't connect to a network? =) [13:50:26 CET] <ChALkeR> that's not a fix. [13:50:32 CET] <J_Darnley> best way to keep safe [13:50:41 CET] <ChALkeR> What do you mean? [13:51:08 CET] <ChALkeR> I am asking how to prevent a specific security issue. [13:51:29 CET] Action: J_Darnley admits he has no idea what you're talking about [13:51:34 CET] <ChALkeR> not a «turn off the pc» type of thing [13:52:31 CET] <ChALkeR> J_Darnley: an attacker could craft a malicious video file, any operation on which with ffmpeg (thumbnail creation, ffprobe, etc) will read a local file specified by the attacker and send it to a remote server owned by the attacker [13:53:02 CET] <ChALkeR> that vulnerability is public, has code samples and instructions on how to build such a malicious video file [13:53:31 CET] Action: J_Darnley knows nothing about that [13:53:31 CET] <ChALkeR> it affects servers that use ffmpeg to probe uploaded videos and/or generate thumbnails [13:53:51 CET] <ChALkeR> it also affects users that download the vide [13:53:54 CET] <ChALkeR> *the video [13:54:32 CET] <ChALkeR> opening the video is not even required in some situations file manager (i.e. Dolphin) automatically generates thumbnails using ffmpeg, that is enough to execute that bug [13:54:53 CET] <ChALkeR> desktop search indexer using ffmpeg to probe files also could be enough [13:55:21 CET] <ChALkeR> that vulnerability is widely disclosed and as public as it could be [13:55:35 CET] <kierank> ChALkeR: link? [13:55:45 CET] Action: J_Darnley resists the urge to rant some more [13:55:53 CET] <kierank> afaik for mp4 there is some filtering to stop that [13:56:16 CET] <ChALkeR> kierank: http://habrahabr.ru/company/mailru/blog/274855/ original blog post is in Russian, use https://translate.google.com or https://translate.yandex.com [13:57:04 CET] <ChALkeR> it has code samples [13:57:51 CET] <ChALkeR> that blog post was at the index page of that site some time ago, and is now at page4 of that site [13:57:56 CET] <ChALkeR> http://www.alexa.com/siteinfo/habrahabr.ru alexa rating [13:58:31 CET] <ChALkeR> So there is no reason to keep the discussion private. [13:58:41 CET] <wm4> trickery with HLS [13:59:49 CET] <funman> The developers of ffmpeg/libav alerted to the problem, I did and sent them a patch. [14:00:13 CET] <wm4> "concat:http://dx.su/header.y4m|file:///etc/passwd" combine all the useless features [14:00:17 CET] <wm4> and make a security hole [14:00:44 CET] <ChALkeR> funman: I was pretty sure that they are informed by now =). The question is: what should the downstream do to mitigate this? [14:01:09 CET] <ChALkeR> Is there any better solution than --disable-network for now? [14:01:25 CET] <wm4> is this only with HLS or are there other cases? [14:01:29 CET] <funman> --disable-protocol=hls ? [14:02:10 CET] <ChALkeR> wm4: No idea. [14:02:41 CET] <ChALkeR> funman: Does that cover everything? Is any other protocol affected? [14:02:51 CET] <funman> yes, no [14:03:11 CET] <wm4> (also I've never seen a report or a patch about this issue until now, even though I lurk this channel and the ML a lot) [14:03:34 CET] <funman> i dont see maxim andreyev in the mailing lists either, maybe he sent the patch in private to somebody? [14:04:04 CET] <ChALkeR> funman: Judging from that blog post and the comments, I doubt that he had taken any steps to contact ffmpeg devs. [14:04:18 CET] <wm4> I think there's a secret security ML, but I'm not on it [14:04:52 CET] <funman> highzeth: read the very last line of the post [14:06:38 CET] <funman> UPD: patch/bug in ffmpeg/libav sent [14:06:39 CET] <ChALkeR> funman: Ah. It wasn't there some time ago. [14:06:42 CET] <funman> On the security@, so no link [14:08:11 CET] <ChALkeR> funman: Looks like that line was added just recently =). [14:14:42 CET] <nevcairiel> its less fun to post exploits if you first notify and wait for them to be fixed, isnt it =p [14:29:48 CET] <ChALkeR> funman: Ah, it was added ~3 hours ago. [14:46:23 CET] <durandal_1707> you mean fix for this is commited? [14:53:26 CET] <nevcairiel> no [14:56:24 CET] <atomnuker> so suppose I have a put bit context with some 20ish bytes written [14:56:47 CET] <atomnuker> and suppose I want to write to the context in parallel [14:57:02 CET] <nevcairiel> like, threads? [14:57:06 CET] <atomnuker> yes [14:57:06 CET] <Daemon404> i dont see how you can put bits parallel [14:57:11 CET] <Daemon404> how would you even know what order [14:57:21 CET] <nevcairiel> that sounds evil [14:57:33 CET] <atomnuker> I know the exact size each thread should write [14:57:36 CET] <durandal_1707> use multiple put bits [14:57:58 CET] <nevcairiel> you could open multiple put_bits contexts offset into the buffer if its fixed size [14:58:05 CET] <Daemon404> can put bits seek? [14:58:08 CET] <nevcairiel> of course if you are not byte aligned you are screwed [14:58:11 CET] <atomnuker> well, yes, I do that, I init a context for every thread [14:58:13 CET] <Daemon404> nevcairiel, you still run into issues then [14:58:16 CET] <atomnuker> everything is aligned [14:58:19 CET] <Daemon404> but what if they overlap the same byte [14:58:21 CET] <Daemon404> it wotn work [14:58:31 CET] <atomnuker> everything is aligned. [14:58:34 CET] <Daemon404> ah [14:58:37 CET] <nevcairiel> Daemon404: he said he knows their writing size, so he should be able to set them up properly [14:58:45 CET] <Daemon404> nevcairiel, only works if aligned [14:58:48 CET] <Daemon404> but he said they are so. [14:59:03 CET] <atomnuker> yes, but then what, my main put bit context still hasn't been seeked forward [14:59:06 CET] <Daemon404> personally [14:59:10 CET] <durandal_1707> write another, better API [14:59:11 CET] <Daemon404> i think such an approach is a bit silly [14:59:16 CET] <Daemon404> why nto just queue them for a single put bit [14:59:21 CET] <Daemon404> put_bits is hardly a bottleneck [14:59:22 CET] <nevcairiel> atomnuker: there is skip_put_bytes/bits [14:59:24 CET] <atomnuker> and I can't call put_bits_seek or put_bits_flush since they'll screw everything up [14:59:55 CET] <atomnuker> seek requires calling flush before that which just fills the whole thing with junk [15:00:10 CET] <Daemon404> skip_bts should work [15:00:13 CET] <Daemon404> or whatever it's called [15:00:18 CET] <Daemon404> i dont think it flushes [15:00:21 CET] <Daemon404> but see what i said above [15:01:01 CET] <Daemon404> (alternatively, just init a new context with buf+offset) [15:01:17 CET] <atomnuker> the problem is I'm writing badly optimized golomb so to get decent performance I need to thread that [15:01:22 CET] <nevcairiel> you probably need to flush+align the main context before going into the threads to avoid funnyness [15:35:57 CET] <durandal_1707> is it time to switch to lgpl3? [15:49:59 CET] <kierank> durandal_1707: no [15:50:04 CET] <kierank> is that a troll [15:50:49 CET] <durandal_1707> no, why would it be [15:51:09 CET] <durandal_1707> qt is switching [15:51:34 CET] <JEEB> because they have a corporate licensing offer? [15:51:51 CET] <JEEB> and thus they want to have stuff that people can't put into plastic boxes [15:52:07 CET] <JEEB> (with LGPLv3 that is) [15:58:10 CET] <durandal_1707> we should too [15:58:45 CET] <kierank> really? [15:58:52 CET] <kierank> no more ffmpeg in a smart-tv [15:58:59 CET] <kierank> for example [16:00:50 CET] <durandal_1707> yes, exactly [16:01:04 CET] <Mavrik> Let's pull a GCC! ;) [16:02:10 CET] <J_Darnley> Cue a fork from the last lgpl2 commit [16:03:02 CET] <J_Darnley> (don't get me wrong, I'm all for the tivo-clause) [16:03:44 CET] <kierank> durandal_1707: you don't want people using ffmpeg? [16:04:27 CET] <kierank> they'll use libvlc instead [16:05:58 CET] <kierank> should we do outreachy btw? [16:12:17 CET] <wm4> doesn't the ffmpeg license say "or later" [16:14:12 CET] <durandal_1707> they already use libvlc [16:14:38 CET] <kierank> yes for demuxing [16:14:46 CET] <kierank> they'll drop ffmpeg altogether [16:19:44 CET] <wm4> who uses libvlc for demuxing and ffmpeg for decoding? [16:23:15 CET] <bencoh> people that need libvlc for whatever reason but still need a (software) decoder [16:23:46 CET] <bencoh> they might use libvlc as a "player" library [16:24:04 CET] <bencoh> (and use the default internal demux for supported streams) [16:26:57 CET] <cone-219> ffmpeg 03Claudio Freire 07master:2a31b076b444: AAC encoder: fix assertion error with prediction [16:26:58 CET] <cone-219> ffmpeg 03Claudio Freire 07master:00d481b2c375: AAC encoder: avoid assertion failure on PNS [16:26:59 CET] <cone-219> ffmpeg 03Claudio Freire 07master:509f16801746: AAC encoder: don't apply MS on special bands [16:27:00 CET] <cone-219> ffmpeg 03Claudio Freire 07master:4dcb69cc12d0: AAC encoder: in IS, fix index of sf_idx, band_type [16:27:01 CET] <cone-219> ffmpeg 03Claudio Freire 07master:6711aa21e263: AAC encoder: various fixes in M/S coding [16:27:02 CET] <cone-219> ffmpeg 03Claudio Freire 07master:aa64a483575b: AAC encoder: fix I/S relative error evaluation [16:27:03 CET] <cone-219> ffmpeg 03Claudio Freire 07master:699c2ee56053: AAC encoder: encode out-of-phase I/S efficiently [16:27:53 CET] <kierank> wm4: they don't use ffmpeg that's the point for decoding [16:27:55 CET] <kierank> they have a hardware decoder [16:33:46 CET] <fritsch> a hw decoder does not decode all formats [16:33:55 CET] <nevcairiel> like a TV producer cares [16:34:06 CET] <nevcairiel> they just print a list of supported formats and call it a day [16:35:40 CET] <fritsch> what I found yesterday on our forum [16:35:45 CET] <fritsch> a reencode hevc 10 bit bluray to: [16:36:06 CET] <fritsch> to: AVC High 10(a)L5.2 [16:36:14 CET] <fritsch> they in deed recoded the bluray to hi10p ... [16:36:20 CET] <fritsch> in 4k [16:36:38 CET] <fritsch> so even the "scene" (how they call themselves) don't care if anyone can watch their content [16:37:30 CET] <nevcairiel> the real scene has pretty strict rules on what can be used, but there are a bunch of things on the side of it that just encode in whatever the hell they want [16:37:34 CET] <nevcairiel> like the anime people [16:38:03 CET] <fritsch> i think that was an anime guy wanting to switch sites :-) [16:38:05 CET] <fritsch> sides [16:38:31 CET] <nevcairiel> anime has used avc hi10p for ages, they dont care about hardware decoders [16:39:07 CET] <JEEB> there's people and companies that provide hw compatible encodes anyways :P [16:40:17 CET] <iive> anime groups are completely separate from the "scene" [16:40:27 CET] <JEEB> and many forget that for quite a while plastic DVD player boxes only supported MPEG-4 Part 2, so you'd get scorn for using AVC [16:40:45 CET] <iive> they are also the first to try new things and adopt new formats. [16:40:46 CET] <JEEB> nowadays not using AVC would just be labled dumb [16:41:51 CET] <JEEB> iive: basically the benefits of 10bit AVC were known and people were *really* eager to make test encodes in 2010 or so. nowadays it's just become the thing to use in the now-really-dead fansubbing scene [16:42:06 CET] <iive> fritsch: btw, does bluray support hevc already? [16:42:16 CET] <JEEB> there's seemingly an agreement on the new format [16:42:23 CET] <JEEB> haven't seen any specs or discs [16:42:23 CET] <nevcairiel> iive: the UHD Blu-ray standard does, but there are no devices or discs yet [16:43:26 CET] <fritsch> iive: you can buy it a amazon, will be shipped march 1 st [16:43:42 CET] <fritsch> nevcairiel: check amazon, they started 5 days ago with the first ~ 30 titles [16:43:49 CET] <JEEB> ok [16:43:51 CET] <fritsch> intel should speed up with broxton [16:44:13 CET] <nevcairiel> fritsch: my industry contacts said that UHD playback devices are "delayed" =p [16:44:16 CET] <wm4> they have enough CPUs that can decode it in software, lol [16:44:20 CET] <fritsch> nevcairiel: hehe [16:44:34 CET] <fritsch> i got a sample of this hi10p 4k encoding ... [16:44:42 CET] <fritsch> i can share it if you want a "dumpest encoding ever" file [16:45:15 CET] <fritsch> https://www.dropbox.com/s/bjf7yywuei0o9i8/sampleForFritsch.mkv?dl=0 [16:45:16 CET] <nevcairiel> its not that special, i'm sure i have a 4k 444 10-bit encode somewhere [16:45:18 CET] <JEEB> pretty sure that's not from a blu-ray, but rather one of the UHD HEVC channels. the Japanese one airs 10bit and has IIRC aired docus and movies [16:45:51 CET] <fritsch> JEEB: Bram Stoker's Dracula (1992) - Release for ULTRAHDCLUB <- google that [16:46:10 CET] <JEEB> (Ž4@) not interested enough tbqh [16:46:36 CET] <iive> just tell us how big is that thing. [16:46:38 CET] <fritsch> http://www.amazon.com/Bram-Stokers-Dracula-Ultra-HD/dp/B00Q2KG5CO <- amazon [16:46:42 CET] <fritsch> 100 MB [16:46:49 CET] <fritsch> the sample I linked [16:46:59 CET] <fritsch> it's a 100 MB dd of that file I requested from the user [16:47:05 CET] <fritsch> that whined it would not be playable on his core i3 [16:47:15 CET] <iive> oh... [16:47:38 CET] <fritsch> amazon's compatible devices mention: Fire HD 10 [16:47:40 CET] <JEEB> it'd be even less playable with the sw HEVC decoder to be honest :P [16:48:06 CET] <fritsch> and "Apple iPhone ios 7" [16:48:07 CET] <fritsch> haha [16:48:08 CET] <iive> encoding whole bd into 100mb would be remarkable achievement ;) [16:48:17 CET] <fritsch> haha [16:48:24 CET] <fritsch> nope, i told him to dd me a sample [16:48:30 CET] <fritsch> that I see it with my own eyes [16:48:37 CET] <JEEB> iive: you can encode a 24min episode of an animoo series into floppy size if you want to :P [16:48:44 CET] <JEEB> getting it small really isn't the issue IMHO [16:48:48 CET] <iive> 16x16? [16:48:50 CET] <J_Darnley> Didn't someone once encode BBB into 1 megabyte? [16:49:07 CET] <JEEB> iive: you can get much more resolution out of that :P [16:49:22 CET] <JEEB> given that blocks are 16x16 and you can use cheap modes for it [16:49:30 CET] <J_Darnley> I think I'm misremembering, it was probably 1Mbit [16:50:03 CET] <JEEB> in the meaning that if you go down enough x264 will basically start throwing away some detail to make it more simply decode'able [16:50:06 CET] <Compn> the 100gb bluray discs wont play in current players. you need the new hardware that can handle it... [16:50:08 CET] <JEEB> uhh, encode'able [16:50:19 CET] <iive> i remember somebody encoding anime at 16x16, with bitrate that allows transimition over dialup. [16:50:51 CET] <J_Darnley> Compn: really? [16:50:52 CET] <JEEB> sure, that was done back in the day with 180p or so? [16:51:18 CET] <JEEB> esp. if it was OK to make it not VBV'd [16:51:31 CET] <JEEB> if you had to VBV you'd probably make it a bit less good [16:52:15 CET] <JEEB> but yeah, unless you're trying to 1080p30 at like 192kbps or so in which case headers etc are starting to cost quite a bit, you can have x264 hit your desired sizes pretty well [16:52:20 CET] <atomnuker> klaussfreire: nice [16:54:37 CET] <bencoh> JEEB: did you say they air 10bit in japan? [16:54:47 CET] <JEEB> HEVC, yes [16:54:57 CET] <JEEB> there's like one channel that airs it atm, or two [16:54:57 CET] <bencoh> ah, okay [16:55:11 CET] <nevcairiel> there is test stations on most satellites that air hevc 10 [16:55:13 CET] <JEEB> funny enough at least one airs BT.2020 [16:55:25 CET] <JEEB> nevcairiel: this isn't at least test any more [16:55:32 CET] <JEEB> I think they were in test mode circa 2014 [16:56:55 CET] <atomnuker> NASA has a 4K HEVC stream on some microwave band AFAIK [16:59:07 CET] <fritsch> astra has a channel hevc 10 bit 4k [16:59:09 CET] <fritsch> already [16:59:21 CET] <fritsch> ouh nevcairiel said that [16:59:40 CET] <fritsch> here is a recording of that astra channel: http://fritsch.fruehberger.net/samples/future-live-tv-hevc-10bit.ts [16:59:48 CET] <JEEB> yes, also IIRC that started airing after the one I mentioned :P but yes, at this point there's plenty of those. [17:01:36 CET] <nevcairiel> i have recordings from astra, eutelsat, hispasat and the japanese thing [17:02:04 CET] <nevcairiel> eutel and hispa are 8-bit for some reason, maybe not final product [17:02:25 CET] <fritsch> yeah also seen some 8 bit hevc stations [17:02:32 CET] <fritsch> those are the intel compatible ones [17:02:43 CET] <fritsch> or pre S912C amlogic [17:10:01 CET] <cone-219> ffmpeg 03Kieran Kunhya 07master:bfc8a4dabe5a: diracdec: Add slice threading to HQ profile [17:54:25 CET] <durandal_1707> kierank: for what you use dirac? [17:54:42 CET] <kierank> various evil broadcast things [17:55:43 CET] <Daemon404> evil? like itv? [17:55:50 CET] <durandal_1707> evil in what sense? [17:58:28 CET] <kierank> durandal_1707: cpu light codec [17:58:38 CET] <kierank> high bitrate [17:58:57 CET] <gajjanag> michaelni: wrt ffmpeg_opt patch, "proper" thing is to check eof at each fgets, close if io error (with message) instead of checking just fclose, should I do this? [18:02:43 CET] <durandal_1707> ah the mit guy is here, let's troll him [18:06:34 CET] <cone-219> ffmpeg 03Michael Niedermayer 07master:0634c5425306: avcodec/aacenc: Fix NAN check [18:06:35 CET] <cone-219> ffmpeg 03Michael Niedermayer 07master:9006567bae4a: avcodec/aacenc: mark output as const as its not written to [18:10:47 CET] <michaelni> gajjanag, yes checking syntax & premature EOF would probably be the proper thing to do [18:15:46 CET] <gajjanag> michaelni, thanks, will amend. Just checking if the code complexity is fine [18:17:34 CET] <gajjanag> all: I will be mostly without net for 2 weeks starting Friday. For any regressions/other issues with stuff I did, please send private email, will try my best [18:18:26 CET] <gajjanag> will push all my stuff to github on Friday; nothing interesting [18:21:33 CET] <gajjanag> before next release, would like to see rint64_clip exported, not important, just that we bumped version for it [18:23:31 CET] <durandal_1707> hmm does it starts with av? [18:26:20 CET] <barthalion> hey folks [18:26:41 CET] <barthalion> we (as in arch) have received a bug report linking to this: https://news.ycombinator.com/item?id=10893301 [18:27:09 CET] <J_Darnley> Yes, we heard. The OP there wqas here earlier [18:27:59 CET] <barthalion> great in the meantime before patch is available, is there something better than disabling networking in our build? [18:28:46 CET] <J_Darnley> I suggested not connecting to a network. Other suggested disabling HLS. [18:29:51 CET] <gajjanag> durandal_1707: it was av_rint64_clip, but regressed on broken platforms (msvc here), so moved to ff_ in lavu/internal in 5c3dee7dad [18:47:47 CET] <philipl> fritsch: So this new chromcast-in-chromium announcement means they'll actually publish code showing how to do casting. Is that interesting for you? [18:48:08 CET] <gajjanag> klaussfreire: there is a trivial aacenc_is one liner I posted, can you please examine? [18:50:07 CET] <klaussfreire> On the ML? [18:50:37 CET] <gajjanag> yes [18:51:14 CET] <gajjanag> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186936.html [18:52:39 CET] <klaussfreire> Oh, I usually search "aac" on the -devel list and check those messages earlier, it seems doing that skips mentions of "aacenc", not sure why. I guess I'll have to also search for aacenc from now on. [18:52:41 CET] <klaussfreire> I'll take a look [18:53:15 CET] <atomnuker> gajjanag: I saw that one but I forgot to post [18:53:38 CET] <atomnuker> does it actually increase performance? [18:54:18 CET] <atomnuker> because I think pow(x, 3.0/2.0) or pow(x, 0.75) looks cleaner [18:55:19 CET] <atomnuker> the function gets called on every single scalefactor band (128 at most) but I doubt replacing pow with 2 sqrts has much of an impact [19:00:11 CET] <gajjanag> @atomnuker: don't know, doubt it does. On the other hand using the double sqrt(sqrt()) will have less variation across libm's; pow is notoriously hard to get right [19:00:49 CET] <gajjanag> (if that matters) [19:08:13 CET] <klaussfreire> I believe it may decrease fp error on some platforms. MIPS for instance. [19:08:26 CET] <klaussfreire> So it's probably a good idea [19:12:27 CET] <atomnuker> yeah, our FATE fuzz values are already too high [19:12:48 CET] <gajjanag> atomnuker: so here are some benches dug up just now [19:13:14 CET] <gajjanag> sqrtf(sqrtf)): 74154 deci, 4096 runs [19:13:40 CET] <gajjanag> sqrt(sqrt)): 75951 deci, 4096 runs [19:13:56 CET] <gajjanag> pow: 79034 deci, 4096 runs [19:14:44 CET] <gajjanag> all fate-aac-is-encode, timer around the two calls to ff_aac_is_encoding_err [19:17:37 CET] <iive> may i ask basic math question? ... how do you get pow(x, .75) with 2 sqrt? [19:19:28 CET] <c_14> sqrt(sqrt(x * x * x)) [19:19:31 CET] <iive> you need to also power of 3? [19:20:01 CET] <klaussfreire> x * sqrt(sqrt(x)) = x * x^(-1/4) = x^(1-1/4) = x^(3/4) = x^(0.75) [19:20:19 CET] <iive> so the above benchmark is not complete [19:21:04 CET] <iive> the line above with pow(3/2) kind of confused me. pow(3/4) makes sense. [19:21:09 CET] <c_14> klaussfreire: don't you mean sqrt(x * sqrt(x)) [19:21:37 CET] <c_14> You can factor x^2 out of the first sqrt [19:21:46 CET] <c_14> you can't drag it out of the second [19:23:17 CET] <klaussfreire> Sorry, I should have said x / sqrt(sqrt(x)) [19:23:55 CET] <klaussfreire> Wolfram agrees: http://www.wolframalpha.com/input/?i=x%2Fsqrt%28sqrt%28x%29%29 [19:24:15 CET] <c_14> Ye, that'll work. [19:24:26 CET] <c_14> I don't know which of those the compiler will optimize the best though& [19:24:42 CET] <klaussfreire> I don't think it'll be faster, but it may be more accurate [19:25:05 CET] <klaussfreire> pow has to go through log, which I believe suffers from accuracy problems in some implementations [19:25:33 CET] <gajjanag> @cc_14: sqrt(x * sqrt(x)) is likely slightly faster than x/sqrt(sqrt(x)), as it lacks a divide [19:26:28 CET] <klaussfreire> And it has the benefit of being the expression used in other places, so I think that one is preferrable [19:28:04 CET] <gajjanag> @klaussfreire: which to use, sqrt(x * sqrt(x)) or sqrtf(x * sqrtf(x))? [19:28:30 CET] <cone-219> ffmpeg 03Michael Niedermayer 07master:da144c2ddd8c: avcodec/diracdec: Inline svq3_get_ue_golomb() and merge the sign bit decoding into it [19:28:31 CET] <cone-219> ffmpeg 03Michael Niedermayer 07master:bbd977162590: avcodec/diracdec: Factor +2 out of the inner loop [19:28:32 CET] <cone-219> ffmpeg 03Michael Niedermayer 07master:39fb3f18c52d: avcodec/diracdec: Handle the 0 vlc case at the top of coeff_unpack_golomb() [19:29:08 CET] <BBB> gajjanag: depends on whether x is a float or not / whether the output variable is float or not [19:29:44 CET] <gajjanag> @BBB: output is a float, input is a float, but this by no means guarantees sqrtf(x * sqrtf(x)) is correctly rounded [19:29:45 CET] <klaussfreire> It's almost all floats, I don't remember any double [19:30:06 CET] <klaussfreire> But yeah [19:30:10 CET] <gajjanag> this is why one may want to use sqrt(x*sqrt(x)) [19:30:37 CET] <gajjanag> (still not guaranteed; but practically will be) [19:30:43 CET] <klaussfreire> It's about energies, I don't believe it matters much if the error is 1 or 2ulp [19:31:37 CET] <gajjanag> @klaussfreire: it can't, at least in the sense of fate since a libm may easily be off by such amounts. Just giving for completeness and awareness ;) [19:33:22 CET] <atomnuker> well, the rest of the code uses sqrtf(a * sqrtf(a)) [19:33:49 CET] <atomnuker> (at least the 1 other place which raises to 0.75 anyway) [19:34:54 CET] <J_Darnley> Now that I've read that big scary bug story I am less worried than I was. It only affect people who make output files available to the world. [19:35:18 CET] <gajjanag> @atomnuker: all right, seems good to go in with this then? will add a bench to the message [19:36:35 CET] <atomnuker> gajjanag: sounds good [19:38:27 CET] <Compn> J_Darnley : thats what it said at 100gb bd disk at amazon... [19:38:49 CET] <Compn> J_Darnley : like the diff between dvd and dvd dual layer or dvd-r vs dvd+r ... different stupid drive required. [19:39:29 CET] <J_Darnley> + vs - is/was stupid but I think all drives could read all [19:39:57 CET] <Compn> they made drives that were both compatable later iirc [19:40:07 CET] <Compn> i have old dvdrom drives, i doubt they will read much. [19:40:30 CET] <J_Darnley> perhaps my drives were always too new [19:41:05 CET] <J_Darnley> I am chuckling though. My brother just bought a BD player and BD drive. [19:41:42 CET] <Compn> only bluray hardware i have is a player i pulled out of the trash... [19:41:56 CET] <Compn> and a 3d bluray disc i bought for testing at a garage sale [19:42:17 CET] <Compn> got 5 or 6 laserdisk and beta players though :D [19:42:45 CET] Action: Compn hucks a laserdisc at J_Darnley [19:43:57 CET] <J_Darnley> Praise laserdisc! [19:44:05 CET] <J_Darnley> It saved the original cuts of Star Wars [20:36:05 CET] <tmm1> ubitux: could you commit some of these patches that anshul signed off on [21:02:59 CET] <llogan> i don't understand help requests via twitter. [21:03:08 CET] <llogan> ...100 messages later [21:22:48 CET] <Daemon404> llogan, simple: direct them to a proper venue [21:22:52 CET] <Daemon404> 140 chars is not enough [21:23:02 CET] <JEEB> pretty much [21:28:07 CET] <llogan> yeah, that's what i always do. [21:29:30 CET] <llogan> but i don't think these "kids" will understand the concept of mailing lists [21:29:49 CET] <Daemon404> llogan, ... bug trackers? [21:30:04 CET] <Daemon404> even the cool kids need bug trackers of some sort [22:33:07 CET] <BBB> llogan: stackoverflow [23:27:54 CET] <cone-219> ffmpeg 03James Almer 07master:17e7fdf61a04: avcodec/wavpackenc: print channel count in av_log call [23:53:43 CET] <cone-219> ffmpeg 03Michael Niedermayer 07master:92465a2347d9: avcodec/aacenc: Check for +-Inf too [00:00:00 CET] --- Thu Jan 14 2016

1 0

ffmpeg.log.20160113
by burek 14 Jan '16

14 Jan '16

[00:07:21 CET] <diginet> so, I'm using the zeranoe FFmpeg builds for windows, but the cinepak encoder doesn't show up for whatever reason. Has it been disabled? I swear I remember there being an encoder [00:26:44 CET] <kbarry_> Currently I have a single HLS input, going to a single RTMP output. [00:27:02 CET] <kbarry_> I read the tee documentation, but can't even see to get it to perform the same ob [00:27:05 CET] <kbarry_> job [00:27:28 CET] <kbarry_> ie, I have a single HLS input, wanting to go to a single RTMP endpoint [00:28:50 CET] <yongyung> does libopus have "true" vbr or do the quality settings just correspond to a bit rate setting? [00:29:40 CET] <TD-Linux> yongyung, by default opus has unconstrained VBR. the bitrate settings basically choose a quality that averages to that bitrate on a large corpus of music [00:30:08 CET] <TD-Linux> you can, however, constrain the VBR in various ways or run CBR [00:31:04 CET] <yongyung> TD-Linux: So if I'd want to encode a song or a video with libopus I'd just use whatever bitrate I want to target instead of -q:a? [00:31:11 CET] <TD-Linux> yongyung, yup. [00:32:35 CET] <kbarry_> http://pastebin.com/NT7PcgnF [00:33:04 CET] <kbarry_> The first section, i am doing HLS to file, which works. Then I try HLS to file via tee, no dice [00:33:15 CET] <kbarry_> lastly I try hls to rtmp via tee, also no dice [00:33:53 CET] <kbarry_> Stream #0:0 -> #0:0 (aac (native) -> ? (?)) seems problemativ [00:33:55 CET] <llogan> diginet: what makes you think it's not there? [00:37:41 CET] <drv> (why in the world do you want to encode Cinepak in 2016?) [00:41:21 CET] <furq> kbarry_: afaik you need to specify the output codec with the tee muxer [00:42:59 CET] <kbarry_> i thought that is what I was doing when i used [f=flv] [00:43:20 CET] <kbarry_> furq: apparently I am missing something else? [00:43:46 CET] <furq> -c copy or -c:v libmp3lame (or whatever codec you want) [00:44:45 CET] <furq> normally it will try to guess appropriate codecs for the format, but since tee uses its own format i guess that breaks it [00:44:53 CET] <kbarry_> yeah, [00:45:06 CET] <kbarry_> need to figure out how to translate that into the tee syntax [00:45:19 CET] <kbarry_> [f=flv:c=libmp3lame] isnt working [00:45:25 CET] <furq> just specify it as you would normally [00:45:42 CET] <furq> unless you need different codecs for each output in which case you're on your own [00:46:00 CET] <kbarry_> Ohh, lemme give it a try [00:46:27 CET] <kbarry_> mind telling me what -c:v means? [00:46:32 CET] <kbarry_> (This is audio only) [00:46:41 CET] <furq> i meant -c:a [00:47:59 CET] <kbarry_> Ooooooh, that works. But what if I DID wanna change things per output stream, [00:48:42 CET] <kbarry_> how do ie, how do I translate -c:a libmp3lame into the tee snytax. [00:48:49 CET] <furq> i don't know if that's even possible [03:06:09 CET] <k_sze> I don't understand the -cpu-used option of libvpx-vp9 [03:06:24 CET] <k_sze> How does it go from -16 to 16? What does it even mean? [03:17:37 CET] <k_sze> I don't know what I'm doing wrong, but transcoding form H.264 to vp9 is *extremely* slow on my server (32 Xeon cores) [03:17:53 CET] <k_sze> These are the parameters I'm trying to use: [03:18:50 CET] <k_sze> ffmpeg -i my_h264_video.nut -pix_fmt yuv420p -c:v libvpx-vp9 -threads 16 -quality realtime -cpu-used 16 -tile-columns 2 -tile-rows 2 -y output.webm [03:19:06 CET] <k_sze> I'm getting below 10 fps transcoding speed, what the heck? [03:19:11 CET] <k_sze> And my server is not busy. [03:19:53 CET] <k_sze> It looks like ffmpeg fails to do multithreaded encoding of vp9. [03:20:32 CET] <k_sze> I'm only using 100% CPU. Stuck with ffmpeg 2.5.3 at the moment because we have code that depends on it and can't freely upgrade until we can test that the newest 2.8.3 doesn't break anything. [11:10:54 CET] <gilbahat> Hi, quick question, is there any way to peg ffmpeg to a specific GPU in a multi-gpu setup? [11:11:34 CET] <gilbahat> I have 4 nvidia GPUs on my system and I need tight control over which GPU will be used for hwaccel [11:15:49 CET] <gilbahat> brb [11:19:57 CET] <ChALkeR> Hi all! Does anyone know, is the sending-local-files-to-remote-server vulnerability fixed already? [11:49:27 CET] <ChALkeR> That's critical, and it's as public as it could be. [11:50:13 CET] <ChALkeR> it was on the index page of http://www.alexa.com/siteinfo/habrahabr.ru (and is now on page4 of the same site), has code samples and instructions on how to build a malicious file [13:25:55 CET] <xodmaster> Hi, I have ffmpeg for windows 32 bit, and I wonder if there is any config or envvar to make ffmpeg suppress the startup message with version, build flags etc ? Getting tiresome to see that message everytime. [13:27:55 CET] <furq> xodmaster: -loglevel quiet -stats [13:32:01 CET] <xodmaster> furq, thanks, but is there any config file or so to modify, or is a (bat) script front-end the only way ? [13:32:24 CET] <xodmaster> tthe only way to not write that option down each time I mean. [13:35:24 CET] <Mavrik> ffmpeg doesn't have config files, it's a one-off use tool [13:37:51 CET] <xodmaster> Mavrik, I suppose it is. I suppose Iäll just create a frontend script, but it would be nice that the build itself had the quiet loglevel option as default. [13:38:44 CET] <xodmaster> Most commandline tools I have used are quiet by default, only a few were verbose about the version/build info etc. [13:47:23 CET] <ChALkeR> Is there a better work-around for now than building with --disable-network? [13:48:27 CET] <ChALkeR> I filed https://bugs.archlinux.org/task/47738 with a suggestion to recompile with --disable-network for now. [14:32:58 CET] <InTheWings> AVDISCARD_* missing from hevc ? [14:57:01 CET] <InTheWings> no clue ? [14:57:51 CET] <InTheWings> it should at least be able to drop non IRAP, no ? [15:41:10 CET] <gilbahat> hi, quick question - anyone know if I can pin hwaccel to a specific GPU? I have a machine with 4 GPUs and need strict control over who/what touches which GPU [15:42:33 CET] <gilbahat> anything, even something hackish, would do& [16:41:17 CET] <t4nk895> hello, I am trying to stream ffmpeg from a webcam attached to a raspberry pi over the internet (not local network) to a laptop. Every network streaming guide I find seems to only apply to local networks. Can someone help? [16:42:55 CET] <klaxa> this sounds more like a networking issue [16:44:07 CET] <DHE> local networks is only a restriction if you're dealing with multicast or NAT. I assume the latter is the issue? [16:45:13 CET] <t4nk895> it's entirely possible [16:45:18 CET] <t4nk895> I'm brand new to this [16:45:34 CET] <t4nk895> my router does have NAT settings - let me check them [16:46:59 CET] <t4nk895> I'm using bridge mode ( devices operate transparently (no NAT or DHCP). Clients receive DHCP leases from the LAN or use static IPs. Use this for shared printers, file sharing, and wireless cameras.) [16:47:30 CET] <t4nk895> I have a separate modem/router and access point [16:47:57 CET] <t4nk895> I've set up port forwarding on the gateway(modem and router, but only being used as router) [16:48:12 CET] <t4nk895> that allowed my streaming to work locally [16:48:50 CET] <t4nk895> but I haven't found an ffmpeg command that seems to work when I'm away from home - even if I use a vpn to get around any potential port issues on my remote netwrok [16:48:54 CET] <t4nk895> *network [16:49:41 CET] <klaxa> how do you call ffmpeg? [16:50:15 CET] <Betablocker> what do u mean klaxa ? [16:50:24 CET] <Betablocker> ffmpeg is called ffmpeg :D [16:50:41 CET] <klaxa> i mean what is the command he is using [16:50:42 CET] <t4nk895> sudo ffmpeg -i /dev/video1 -f mpeg tcp:[remote address]:1234 [16:51:05 CET] <t4nk895> that seems to work (if i recall correctly) from the video source [16:51:15 CET] <t4nk895> i might have used rtp instead of tcp [16:51:24 CET] <bencoh> why do you need to run ffmpeg as root? [16:52:05 CET] <t4nk895> i was getting issues before, so I am running as root until I find a command that works - there was some issue with permissions in opening a port (i think) at one point [16:52:15 CET] <fritsch> bencoh: i think he had a port < 1024 in his original command [16:52:48 CET] <klaxa> the address you are specifing should be a local ip bound to an interface or 0.0.0.0 to bind to all interfaces [16:53:14 CET] <t4nk895> @klaxa, can you explain that? not sure I follow [16:53:28 CET] <klaxa> on the pi you want to stream the video [16:53:56 CET] <klaxa> you don't know from where clients will connect, but you know on what ip address the packets will arrive [16:54:00 CET] <furq> tcp://0.0.0.0:12345?listen [16:54:02 CET] <t4nk895> okay [16:54:13 CET] <t4nk895> so the ip should be that of the pi? [16:54:14 CET] <klaxa> for example you could only use wifi or ethernet [16:54:25 CET] <furq> t4nk895: 0.0.0.0 will listen on all available addresses [16:54:27 CET] <klaxa> yes [16:54:40 CET] <klaxa> if in doubt use 0.0.0.0 [16:54:41 CET] <t4nk895> 0.0.0.0 on the pi? [16:54:44 CET] <furq> yes [16:54:49 CET] <t4nk895> hmm okay [16:54:50 CET] <furq> then your actual lan/net ip on the client [16:55:16 CET] <t4nk895> and that would be the address of my home network (on the client)? [16:55:36 CET] <furq> the pi's lan ip if you're on the local network, your internet ip if you're not [16:55:53 CET] <t4nk895> would the internet ip work on my home network? [16:56:02 CET] <klaxa> it should [16:56:03 CET] <furq> it should do [16:56:04 CET] <t4nk895> I'd like to eventually make a script that'll work anywhere [16:56:11 CET] <t4nk895> okay, thank you so much [16:56:19 CET] <t4nk895> I'm going to ssh into my pi and try it now [16:56:57 CET] <t4nk895> any idea why the connection might be refused? [16:57:37 CET] <furq> what client are you using [16:57:53 CET] <t4nk895> terminal on a macbook [16:58:04 CET] <furq> oh wait you mean the ssh connection? [16:58:19 CET] <t4nk895> i'm already connected to the pi over ssh [16:58:25 CET] <t4nk895> when I try my stream command [16:58:34 CET] <t4nk895> the connection is refused on that ip address [16:58:34 CET] <furq> right, what are you trying to stream it with [16:58:35 CET] <furq> ffplay? [16:58:39 CET] <t4nk895> yes [16:58:55 CET] <furq> i just tested it and that works for me [16:58:59 CET] <t4nk895> but the pi is refusing the connection, not the computer [16:59:32 CET] <furq> pastebin the exact ffmpeg and ffplay commands [16:59:39 CET] <t4nk895> okay [17:00:29 CET] <furq> http://sprunge.us/jUNN [17:00:31 CET] <furq> that works for me [17:01:03 CET] <t4nk895> http://pastebin.com/L0Kp7DUj [17:01:06 CET] <furq> oh wait you're using the net ip aren't you [17:01:16 CET] <furq> er [17:01:22 CET] <furq> you're using two different ports there [17:01:39 CET] <t4nk895> sorry, 1234 is the port I'm using [17:01:40 CET] <furq> also ?listen goes on the server side [17:01:47 CET] <t4nk895> that's good to know haha [17:01:48 CET] <t4nk895> thank you [17:02:01 CET] <furq> and obviously you'll need to forward port 1234 [17:02:36 CET] <t4nk895> already done :) [17:02:49 CET] <furq> also that server will only serve one client and it'll stop running as soon as the client disconnects [17:03:03 CET] <furq> if you need something more robust you should look into a proper streaming server [17:03:43 CET] <t4nk895> i'll try that [17:03:44 CET] <t4nk895> thank you [17:06:06 CET] <t4nk895> hmm I'm still getting an issue [17:06:18 CET] <t4nk895> the client is timing out before the connection begins [17:06:24 CET] <t4nk895> the server is streaming though! :) [17:07:45 CET] <t4nk895> could that be an issue with the network i'm on? [17:25:20 CET] <Taoki> Hi everyone... need a little help with something: I use a 3D animation program which outputs each frame to a png file (001.png, 002.png, 003.png, etc). But while I create test renders, I don't need such a high frame rate, so I can enable an option to skip frames. This however means that there are gaps in the numbers (001.png, 003.png, 005.png, etc). Does ffmpeg know to ignore these gaps? [17:26:09 CET] <Taoki> So for instance, if there are normally 3 frames: 1.png, 2.png, 3.png: If 2.png is missing, ignore it and just stitch 1.png and 3.png. And so on for any number of frames. [17:26:28 CET] <Taoki> I tried this a while ago but it didn't work for me. So maybe some parameter or another trick will do? [17:32:58 CET] <DHE> where you put -r for setting the framerate matters. put it before the -i option to set the framerate of the source [18:26:40 CET] <kingron> can someone help with this case? https://stackoverflow.com/questions/34772421/ffmpeg-convert-and-add-silent-… [18:30:04 CET] <lxde_sea> kingron, Try inserting "-ss 0:00 -to 4:00" after the video input. (besides, your converted file has a higher bitrate than the original - this doesnt improve quality, just increase the size) [18:30:29 CET] <lxde_sea> kingron, in fact, you can leave out the bitrates alltogether, ffmpeg will (usualy) get some nice ones for you [18:30:52 CET] <lxde_sea> err, typo. ment audio input. [18:44:59 CET] <kingron> trying ... [18:51:13 CET] <kingron> <lxde_sea>, "-ss 0:00 -to 0:04" same results :/ [18:51:21 CET] <kingron> lxde_sea, "-ss 0:00 -to 0:04" same results :/ [18:51:44 CET] <kingron> tried also -t 4.00 [18:54:04 CET] <lxde_sea> kingron, is the source long enough? (or longer?) [18:54:35 CET] <lxde_sea> then you might try changing the latter to: -to 0:04.003 [19:01:28 CET] <kingron> lxde_sea, no luck it stays at 3.997 or 4.23 [19:02:39 CET] <kingron> in this example it's very tiny the difference, but long mpegs have a bigger duration difference [19:05:37 CET] <lxde_sea> kingron, sorry then, not that familar to help then :( [19:25:07 CET] <Taoki> DHE: I currently use -framerate to specify the FPS. The problem however is I remember that ffmpeg couldn't notice missing frames, and would stop after frame 1 because it wouldn't find 2 instead of skipping to 3.\ [19:58:06 CET] <thetrueavatar> hi [19:59:03 CET] <thetrueavatar> I'm now trying to use ffmpeg to encode in mpeg2 to make a dvd. Have some question if someone is available [20:04:30 CET] <DHE> that's not how IRC works. ask your question to nobody in particular and you'll get your reply (eventually) [20:05:28 CET] <thetrueavatar> ok then let's go ^^ [20:06:56 CET] <thetrueavatar> I just want to get the best mpeg2 encoding to have something nearly lossless. I found some information in the faq but was a bit surprised of the result. Has a file around 2gb for a film that last 1h37min [20:07:39 CET] <thetrueavatar> Also don't understand if it worth making 2 pass if I set a qscale. I would say no cause I'm targeting quality not size but saw this in faq [20:08:41 CET] <thetrueavatar> I first used nero to do some authoriting and make him convert my source in mpeg2 and it says it used a nearly 10000Kb/s bitrate while encoding with ffmpeg show me a bitrate around 2600k. [20:09:13 CET] <thetrueavatar> Is the nero encoder so terrible compare to ffmpeg mpge2 encoder ? [20:10:08 CET] <thetrueavatar> My original file is a 3.5gb 1080p h264+256kbps audia [20:11:26 CET] <DHE> when you use qscale ffmpeg will product a file whose per-frame image quality is about constant. that's potentially bad for DVD because you're supposed to adhere to the bitrate/buffer requirements. I believe the target is between 9 and 10 megabits. Nero might be going for exactly that while ffmpeg is just meeting your quality request [20:13:11 CET] <thetrueavatar> Is there a way to be dvd compliant with mpeg ? Saw a -target pal-dvd option [20:14:17 CET] <thetrueavatar> here is my current options: ffmpeg -i Kyrielle\ montage\ tout\ OK.avi -c:v mpeg2video -bf 2 -mbd rd -trellis 2 -cmp 2 -subcmp 2 -pix_fmt yuv420p -me_method epzs -threads 4 -vf zscale=w=720:h=406 -qscale:v 1 -c:a ac3 -b:a 320k Kyrielle-Z.mpg [20:16:03 CET] <furq> 720*406 isn't dvd compatible [20:16:06 CET] <DHE> The target option will basically expand into "-c:v mpeg2video -c:a ac3 ...", including the bitrate thresholds. [20:16:20 CET] <thetrueavatar> I know standard is 720x576 [20:16:29 CET] <thetrueavatar> but tought I could keep orignal ratio [20:16:45 CET] <furq> use -aspect 16:9 [20:16:54 CET] <DHE> the scaled image will retain the original ratio by leaving the ratio information in the source video file unless overridden [20:17:41 CET] <thetrueavatar> os use -aspect 16:9 instead of zscale ? [20:18:01 CET] <furq> zscale to 720*576 and then set -aspect 16:9 [20:18:15 CET] <furq> as DHE says you might not need to explicitly set -aspect but it does no harm [20:19:06 CET] <DHE> leave aspect out unless the image looks distorted. it shouldn't. just check the output .mpg with the video player of your choice. [20:20:11 CET] <thetrueavatar> and for the rest I keep it so ? My goal is that's readable on any dvd player [20:21:01 CET] <thetrueavatar> if I use -target pal-dvd I have notice that it use 6000k bitrate [20:38:05 CET] <DHE> that's the target's default. go ahead and override. the profile set allows bandwidth spikes [20:41:09 CET] <thetrueavatar> well qscale doesn't seem to override the -b:v [20:43:00 CET] <thetrueavatar> hum I write it to fast. Bitrate seems to be ok [20:44:45 CET] <thetrueavatar> I'have been told that zscale with zimg was better than the default scaling [20:44:56 CET] <thetrueavatar> will it override the -s option ? [20:49:03 CET] <Betablocker> i have an rtsp stream&. in vlc the adress will produce a video. if i try to catch it with ffmpeg nothing happens. i am at the end of ideas what is going wrong :/ here is the error code http://pastebin.com/KCpAQQ0G [20:59:45 CET] <klaxa> that's weird, try adding -map 0 [20:59:49 CET] <klaxa> Betablocker: ^ [21:10:15 CET] <Betablocker> ok [23:40:28 CET] <bahoo> I did a `ffmpeg -i` on two different videos, both of which were created using the same ffmpeg command on two different machines, presumably with different codecs / libraries setup. [23:40:47 CET] <bahoo> One video plays fine in QuickTime, the other does not. This was the one line that was different: https://dpaste.de/UFi4 [23:41:24 CET] <bahoo> Does anyone smarter than me spot anything that might trip up QuickTime there? [23:46:02 CET] <drv> probably 4:2:0 vs 4:4:4 color space [23:47:59 CET] <furq> apparently quicktime doesn't support hi444pp [23:48:09 CET] <furq> by "apparently" i mean according to a comment on a stackoverflow answer [23:48:12 CET] <furq> oh never mind [00:00:00 CET] --- Thu Jan 14 2016

1 0

ffmpeg-devel.log.20160112
by burek 13 Jan '16

13 Jan '16

[00:13:55 CET] <cone-652> ffmpeg 03Andreas Cadhalpun 07master:d637a58750ef: diracdec: fix idwt_stride calculation in bytes [00:54:46 CET] <kierank> how do I make avctx->execute actually use multiple threads [00:57:18 CET] <philipl> pass it a thread pool? [00:57:19 CET] Action: philipl runs [00:57:43 CET] Action: kierank slaps philipl around a bit with a large spiny-back [00:57:49 CET] <atomnuke1> kierank: isn't that already set up properly because low delay mode used it [00:57:54 CET] <kierank> doesn't work [00:58:01 CET] <kierank> uses one thread in reality [00:58:35 CET] <kierank> ok missing AV_CODEC_CAP_SLICE_THREADS seems to help [00:59:54 CET] <kierank> caps out at 26fps, dunno why [01:06:02 CET] <J_Darnley> Up yours Telenet! Stop dropping my connections! [01:16:38 CET] <Compn> trouble in belgian paradise ? :P [01:26:39 CET] <cone-652> ffmpeg 03Ricardo Constantino 07master:d50b5d547f40: rtmpdh: Initialize gcrypt before using it [01:26:49 CET] <kierank> is there a way to allocate thread local storage [01:43:33 CET] <kierank> atomnuker: are slice widths guaranteed to be mod-8? [01:44:40 CET] <atomnuker> nope [01:44:52 CET] <atomnuker> but for all practical purposes - yes [01:45:20 CET] <kierank> well it matters unfortunately [01:45:41 CET] <kierank> for simd [01:45:50 CET] <atomnuker> well yeah, the current encoder and decoder supports odd-numbered lenghts and widths [01:46:18 CET] <kierank> bugger [01:46:32 CET] <iive> isn't linesize invented to help with that? [01:46:33 CET] <atomnuker> we could limit them to powers of two only [01:46:53 CET] <kierank> doesn't change the fact files could exist that aren't [01:47:03 CET] <atomnuker> oh yeah, damn [01:49:19 CET] <kierank> ah vc2hqdecode has hardcoded slice hights [01:49:20 CET] <kierank> lol [01:49:29 CET] <kierank> with special simd for each [01:49:35 CET] <kierank> that's clever [01:51:50 CET] <atomnuker> no, it's not actually hardcoded [01:51:55 CET] <atomnuker> you can still set them [01:52:14 CET] <kierank> the simd has harcoded slice heights [01:52:34 CET] <atomnuker> ah [01:52:45 CET] <atomnuker> but it rejects any slice dimensions it doesn't like [03:39:17 CET] <cone-652> ffmpeg 03Michael Niedermayer 07master:7c97946d6131: avcodec/mpeg4video: Check time_incr [05:23:48 CET] <thebombzen> I noticed a typo: libavdevice is not build with libv4l2 support. [05:24:00 CET] <thebombzen> should be libavdevice is not built with libv4l2 support. [05:24:19 CET] <thebombzen> not important enough for a bug report but figured I'd mention it here. [05:51:48 CET] <Timothy_Gu> thebombzen: fixed, thanks! [05:53:20 CET] <cone-652> ffmpeg 03Timothy Gu 07master:d64d6edfc7f5: Correct two build/built typos [08:58:21 CET] <kierank> michaelni: any suggestions about how to make dirac_get_se_golomb faster? [08:59:04 CET] <kierank> It takes up 80% of decode time... [10:18:13 CET] <kierank> nevcairiel: I think slice threaded encoding is supported via avctx->execute actually [10:18:57 CET] <kierank> lol ganesh and mats [10:32:02 CET] <wm4> ganesh is still sending completely useless patches [10:32:14 CET] <wm4> like checking fclose() return values for files opened read-only [10:32:29 CET] <wm4> (which is still a "good idea") [10:33:32 CET] <BtbN> Well, having a lot of commits has an effect now. [12:04:52 CET] <michaelni> kierank, it should be possible to write a function like svq3_get_se_golomb for dirac, that is to use a LUT for the small and likely cases that already contains the sign [12:05:09 CET] <kierank> michaelni: in the new dirac decoder they wrong a simd golomb decoder [12:05:11 CET] <kierank> heard of that before? [12:05:15 CET] <kierank> wrote* [12:06:06 CET] <kierank> https://github.com/bbc/vc2hqdecode/blob/master/vc2inversetransform_sse4_2/v… [13:45:59 CET] <michaelni> kierank, did anyone benchmark that ? [14:36:44 CET] Action: Daemon404 really wonders how the heck ami_stuff finds this ... stuff [14:55:15 CET] <cone-090> ffmpeg 03Mats Peterson 07master:adef8ee794aa: lavf/matroskadec: Use av_realloc() in get_qt_codec() [15:23:32 CET] <J_Darnley> What? libavcodec doesn't already have a pb_255 constant? [15:24:19 CET] <iive> i thought that one is easy to generate? [15:24:24 CET] <J_Darnley> Oh it is [15:24:32 CET] <J_Darnley> I just assumed I could cextern it [15:27:44 CET] <ubitux> http://pastie.org/pastes/10685605/text [15:27:50 CET] <ubitux> any idea why causes this ^ [15:27:52 CET] <ubitux> ? [15:27:54 CET] <ubitux> what* [15:28:18 CET] <wm4> cause what exactly? [15:28:32 CET] <ubitux> the inexact duration in aac [15:28:34 CET] <wm4> isn't it because of frame sizes? [15:29:13 CET] <wm4> (so the duration would be aligned on frame sizes by padding or discarding some audio) [15:30:09 CET] <ubitux> if i extract again the aac to a wav, the duration is back to 6 [15:32:10 CET] <ubitux> the start time is also 0.023220 for some reason [15:32:29 CET] <wm4> ah [15:32:35 CET] <wm4> that's the skip mechanism [15:32:36 CET] <ubitux> so maybe it's padding the 5736 extra sample at the beginning? [15:32:38 CET] <wm4> it cheats a bit [15:32:46 CET] <wm4> something like this [15:32:57 CET] <wm4> but it sounds like the reported duration is wrong then [15:34:01 CET] <durandal_170> ubitux: did I got answer from you yesterday? [15:34:06 CET] <ubitux> >>> 0.023220 * 44100 [15:34:08 CET] <ubitux> 1024.002 [15:34:18 CET] <ubitux> durandal_170: mmmh [15:34:41 CET] <ubitux> durandal_170: i don't know for ifft api [15:34:59 CET] <ubitux> well [15:35:10 CET] <ubitux> i guess you need to put it back if you had it outside [15:36:01 CET] <ubitux> like, with ifft you need to feed N/2+1 complex (2 samples) for N real (1 sample) [15:36:09 CET] <ubitux> your buffer is likely of size N [15:36:20 CET] <ubitux> and not N+2 [15:36:46 CET] <ubitux> so the real part of the last sample should be placed in the imaginary part of the first one before you feed it [15:37:10 CET] <ubitux> wm4: yeah reported duration is wrong [15:37:16 CET] <ubitux> by a margin of 1024 [15:37:28 CET] <wm4> ubitux: so something has to subtract the padding... but who [15:37:41 CET] <wm4> (I find this start time hack to adjust timestamps a bit questionable too) [15:37:56 CET] <ubitux> the first pts is like -1024 [15:38:14 CET] <wm4> huh [15:38:22 CET] <wm4> and yet start_time is 1024? [15:38:24 CET] <Daemon404> ubitux, there is a stupid padding removal thing in movdec iirc [15:38:29 CET] <Daemon404> for itunes aac padding [15:38:30 CET] <Daemon404> or some shit [15:38:32 CET] <Daemon404> mayeb related? [15:38:44 CET] <ubitux> streams.stream.1.start_pts=-1024 [15:38:46 CET] <ubitux> streams.stream.1.start_time="-0.023220" [15:38:48 CET] <ubitux> streams.stream.1.duration_ts=265624 [15:38:50 CET] <ubitux> streams.stream.1.duration="6.023220" [15:39:09 CET] <Daemon404> oh, that looks normal [15:39:18 CET] <Daemon404> thats a standard way of chopping off the aac primign samples. [15:39:29 CET] <Daemon404> (in mp4) [15:39:40 CET] <ubitux> but shouldn't we duration -= start_time? [15:39:59 CET] <wm4> just got an email [15:40:01 CET] <wm4> "Recently, I meet a lots of mp3 file probe as H263 mime. It's make me very confuse." [15:40:12 CET] <Daemon404> ubitux, yes... if youre demuxer is sane [15:40:12 CET] <wm4> mp3 misdetected has h263? [15:40:16 CET] <Daemon404> your* [15:40:32 CET] <Daemon404> i bet lavf defines duration simply as sum of all samples [15:40:34 CET] <wm4> Daemon404: should the demuxer do it? [15:40:38 CET] <Daemon404> regardless of if theyre ona timeline [15:40:44 CET] <nevcairiel> wm4: and i thought everything misdetected as mp3 [15:41:00 CET] <Daemon404> wm4, in ubitux's case it's chopped off using edts [15:41:08 CET] <Daemon404> so yes demuxer imo [15:41:17 CET] <Daemon404> (our edts support is lulz) [15:41:47 CET] <wm4> nevcairiel: yeah... [15:41:54 CET] <Daemon404> ubitux, if you look at the file in box dumper, youll probably see something like [15:42:09 CET] <Daemon404> edts with an edit saying to play 0.023220-6.023220 [15:42:14 CET] <Daemon404> and a duration of 6.023220 [15:42:25 CET] <Daemon404> because duration, i dont think counts edits [15:42:37 CET] <Daemon404> it's just the duration of the physical track [15:42:43 CET] <ubitux> ah, this edts shit again [15:42:53 CET] <Daemon404> because ffmpeg has no cocnept of presentatio timeline [15:42:54 CET] <Daemon404> at all. [15:45:13 CET] <wm4> ah wtf the website is 163.com, and it loads scripts from 162.net [15:45:16 CET] <wm4> very funny, china [15:46:16 CET] <omerjerk> Hi [15:46:39 CET] <omerjerk> I'm a student developer from Delhi and would like to apply for GSoC this year. [15:47:37 CET] <omerjerk> Does ffmpeg has its ideas page for GSoC'16 up yet ? [15:47:50 CET] <omerjerk> or if not, from where should I begin ? [15:47:56 CET] <omerjerk> Thanks in advance. :) [15:48:01 CET] <J_Darnley> The 2015 page, probably [15:48:25 CET] <Daemon404> er... orgs cant even apply yet [15:48:29 CET] <Daemon404> we dont even know if well be accepted [15:51:02 CET] <omerjerk> I'm sure ffmpeg will get in. [15:58:55 CET] <durandal_170> libavfilter GUI, idea for example [15:59:24 CET] <Daemon404> ... that should definitely not be in ffmpeg.git [16:00:05 CET] <durandal_170> it should, in python for example [16:00:22 CET] <atomnuker> durandal_170: what about the whole audiovisual filters in mpv thing? [16:00:23 CET] <wm4> wat [16:00:36 CET] <wm4> atomnuker: well that has nothing to do with ffmpeg [16:00:53 CET] <Daemon404> ... no it definitely does nto belong in ffmpeg.git [16:01:02 CET] <Daemon404> it's a downstream api/cli-use tool [16:01:05 CET] <wm4> ffmpeg.git should be split! [16:01:09 CET] <Daemon404> dont shit everything into ffmpeg.git [16:01:12 CET] <wm4> then we don't need to think too hard about such things [16:01:29 CET] <j-b> split it! [16:01:45 CET] <durandal_170> atomnuker: mpv needs to be rewritten anyway [16:01:54 CET] <J_Darnley> Do any of you use GDB's save-history feature? If so do you make it write to a particular file? [16:03:41 CET] <durandal_170> have someone tried listening pictures via spectrumsynth [16:04:58 CET] <J_Darnley> Not me. [16:14:39 CET] <cone-090> ffmpeg 03Carl Eugen Hoyos 07master:27fa70fdfe87: lavc/mjpeg2jpeg: Check for jpeg file header. [16:51:45 CET] <mateo`> are there guidelines regarding what a decoder is supposed to do with frame->pts/pkt_pts/pkt_dts ? is the decoder supposed to rescaled the input packet pts with the avctx->time_base or framerate ? [16:52:12 CET] <nevcairiel> its not supposed to do anything, iirc [17:02:19 CET] <mateo`> the mediacodec decoder is working a bit like the qsv one, it has an internal queue of packets, a parser to convert the bitstream, so it's not one input - one output [17:02:50 CET] <wm4> timestamps are to be passed through (for video codecs with reordering) [17:03:03 CET] <wm4> and yes, with such an API it's going to be very painful [17:03:09 CET] <wm4> (I've done it with mmal, sort of) [17:03:28 CET] <wm4> might actually be easier to go through with adding a m:n decoding API first [17:03:41 CET] <nevcairiel> that doesnt really resolve your timestamp trouble [17:07:18 CET] <wm4> what's the problem? [17:09:16 CET] <mateo`> I'm not sure I have a problem. I just want to make sure i'm doing things right. [17:09:53 CET] <mateo`> mediacodec wants its input buffer pts in us (and this the output buffer pts is in us) [17:10:57 CET] <Daemon404> sounds simple enough [17:10:59 CET] <mateo`> so i'm rescaling the input packet pts to us (using avctx->time_base), then i'm doing the opposite on the output buffer to set the frame->pts [17:11:02 CET] <Daemon404> but that is pretty odd [17:11:07 CET] <Daemon404> literallu nothing uses us [17:12:13 CET] <mateo`> for reference, http://developer.android.com/reference/android/media/MediaCodec.html#queueI… [17:12:34 CET] <Daemon404> ............. [17:12:36 CET] <Daemon404> long for PTS [17:12:38 CET] Action: Daemon404 deskfaces [17:13:06 CET] <nevcairiel> long in java is 64-bit [17:13:19 CET] <Daemon404> hmm ok [17:13:24 CET] <Daemon404> i thought it mirrored the C api [17:13:51 CET] <mateo`> the C API uses an int64_t for it [17:13:52 CET] <wm4> mateo`: do these have to be real timestamps? I know lavc doesn't need a time_base [17:14:06 CET] <Daemon404> mateo`, am i correct in thinking the only timebase that the api supports is Œs? [17:15:14 CET] <mateo`> wm4: maybe i can just put the packet->pts into it if the decoder in software mode (and not to a surface) [17:16:05 CET] <wm4> software mode as opposed to hw decoding? [17:16:33 CET] <mateo`> nope, software mode means you actually get main memory buffers as ouput [17:19:51 CET] <mateo`> the other mode let the decoder output directly to a surface [17:20:02 CET] <BBB> do you really need to rescale the output back? [17:20:16 CET] <BBB> I mean, the output is not changed from input right? [17:20:22 CET] <BBB> so you can just give back the original value [17:20:47 CET] <BBB> a linear lookup in a list of N entries is not that bad if N is very small (like, 5-10 frames?) [17:22:00 CET] <BBB> mateo`: and I think you only set pkt_*, not pts itself, pts itself is a best-effort calculated based on pkt_* IIRC [17:22:10 CET] <BBB> (in utils.c) [17:22:50 CET] <mateo`> BBB: I think it might work (I will have to test) to not rescale the pts at all and let the value pass through mediacodec [17:23:01 CET] <BBB> even better [17:23:03 CET] <Daemon404> why does it even care about timestamps mateo` ? [17:23:11 CET] <BBB> it probably doesnt [17:23:15 CET] <BBB> :) [17:23:21 CET] <Daemon404> i mean, that would make sense. [17:24:53 CET] <mateo`> Daemon404: I don't know why mediacodec would care about the values [17:25:41 CET] <Daemon404> exactly [17:26:46 CET] <mateo`> BBB: I'll have to take a look at what utils.c is doing to generate the frame pts, it's a bit of a blackbox to me atm (that's why i'm asking all those questions, i guess) [17:27:15 CET] <cone-090> ffmpeg 03Michael Niedermayer 07master:782c4ab4ede2: avcodec/truemotion2: Cleanup in case of tm2_read_stream() failure [17:36:59 CET] <kierank> michaelni: yes authors did and it's faster [17:39:50 CET] <Timothy_Gu> gi/tb [17:39:54 CET] <Timothy_Gu> oops [17:41:18 CET] <michaelni> kierank, faster than what ? previous dirac code or ffmpegs or something else ? [17:41:28 CET] <kierank> faster than their previous code of course [17:41:29 CET] <kierank> their c [17:41:45 CET] <kierank> why would they compare their on decoder to ffmpeg [17:42:01 CET] <michaelni> also the distribution of the values does matter for that stuff, the code we have is optimized for small values [17:42:56 CET] <kierank> that may not be the fastest, no? [17:43:02 CET] <michaelni> it would be interresting to know if their code is faster compared to ffmpegs [17:43:25 CET] <kierank> their decoder is faster yes [17:43:44 CET] <kierank> 80% of the time in our decoder is spent on golomb and dequant [17:44:05 CET] <michaelni> this should not be, 80 sounds too much [17:44:39 CET] <kierank> on a 700mbit file though [17:44:45 CET] <michaelni> is *golomb() inlined ? [17:44:55 CET] <kierank> yes [17:45:26 CET] <michaelni> where can i find the file used for testing ? [17:45:49 CET] <kierank> I will need to upload it somewhere [17:45:50 CET] <kierank> it is large [17:46:13 CET] <kierank> http://pastie.org/private/gy3t0aa80ldmymqqioqmw [17:46:59 CET] <michaelni> would be usefull to have the same video for testing [17:47:18 CET] <kierank> yes uploading it now [17:51:38 CET] <kierank> michaelni: obe.tv/Downloads/output.drc [17:51:50 CET] <kierank> and you will also need the slice thread patch I posted [17:52:24 CET] <kierank> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186943.html [18:04:06 CET] <dinux5> may I know the time zone in which most of the community members reside so that i know the perfect hours to ping you all when I have doubts ? :) [18:05:08 CET] <kierank> mostly europe [18:05:32 CET] <dinux5> ohk .thank you. [19:33:20 CET] <durandal_1707> anybody knows anything about overlap-add and audio synthesis? [19:35:23 CET] <llogan> michaelni, Compn: I'll be gone from Jan 15-25. My ML queue clearing may be non-existant then. [19:37:07 CET] <J_Darnley> Cock. I forgot which operand was not-ed in pandn. [19:48:51 CET] <BBB> durandal_1707: something, very little but I did write a decoder once [19:48:59 CET] <BBB> durandal_1707: what the question? [19:49:16 CET] <BBB> durandal_1707: and re: why are people obsessing about that patch, Ill try not to, Im just trying to not get more unnecessary code in if I can prevent it [19:49:23 CET] <BBB> but my attention span only goes so far [19:50:03 CET] <durandal_1707> BBB: I'm doing ifft and overlapping so I get back reasonable sound [19:50:14 CET] <BBB> ok [19:51:38 CET] <BBB> (but what is the question?) [19:51:39 CET] <durandal_1707> the idea is allow users to modify signal in frequency domain, its spectrogram and ifft back to time domain [19:52:29 CET] <durandal_1707> some stuff I did by guessing [19:52:45 CET] <TD-Linux> like an equalizer? [19:53:04 CET] <durandal_1707> Like what to multiply signal after overlap and ifft [19:53:38 CET] <durandal_1707> equalizer can be done in time domain [19:54:14 CET] <TD-Linux> well any linear filter can be done in time domain :) [19:54:48 CET] <BBB> durandal_1707: Id almost certainly do what other codecs do, like on2avc uses straight fft [20:01:37 CET] <michaelni> Compn (or someone else), do you want to create a sponsors page for ffmpeg ? Theres at least one person who wants to donate and is asking about the possiblity of having a logo or link somewhere [20:14:58 CET] <durandal_1707> BBB: question is what's best windows to do fft with overlap do editing and then ifft back with overlapping [20:19:36 CET] <durandal_1707> idea is to edit video spectrogram [20:19:36 CET] <cone-090> ffmpeg 03Michael Niedermayer 07master:d73f0c586e7e: avformat/asfenc: Flush packet before duration becomes unrepresentable [20:19:37 CET] <cone-090> ffmpeg 03Michael Niedermayer 07master:7c0b84d89911: avformat/asfenc: Check pts [20:23:01 CET] <BBB> durandal_1707: Id do the same as what on2avc does, from what I remember it does 50% overlap (so each sample is always windowed exactly twice) [20:30:32 CET] <durandal_1707> BBB: I do with magnitude and amplitude reduced to 8bit and 85% overlap with hann window works pretty well so far [20:31:08 CET] <durandal_1707> s/amplitude/phase [20:32:09 CET] <BBB> you can always make it configurable :D [20:32:12 CET] <durandal_1707> 0.875 exactly [20:32:24 CET] <BBB> I guess each sample twice is called 100% overlap [20:32:26 CET] <BBB> so 100% is ok [20:32:58 CET] <durandal_1707> no, that's 50% [20:34:40 CET] <durandal_1707> so does doing compression in frequency domain like with video makes sense? [20:36:50 CET] <TD-Linux> durandal_1707, absolutely, you might like to look at the opus demos [20:36:54 CET] <cone-090> ffmpeg 03Carl Eugen Hoyos 07master:405abdbaee52: lavf/mpjpegdec: Do not call av_log() while probing. [20:37:04 CET] <TD-Linux> https://people.xiph.org/~xiphmont/demo/ [20:37:52 CET] <TD-Linux> all modern audio codecs use the MDCT, not FFT though [20:39:21 CET] <BBB> if you ever wonder why I bring up on2avc, its b/c afaics its the only codec using an actual full fft [20:39:23 CET] <BBB> :-p [20:39:24 CET] <BBB> so ys [20:39:26 CET] <BBB> yes* [20:49:24 CET] <Compn> michaelni : maybe llogan would volunteer ? its not really a donation if they request a sponsored link though.... [20:49:54 CET] <Compn> more like buying real estate on a website that gets a high google ranking :P [20:51:41 CET] <michaelni> yes, thats a valid way to see it too [20:54:13 CET] <llogan> is this regarding "We would like to become Sponsor"? [20:57:47 CET] <Compn> (we get a lot of those crap emails) [20:57:58 CET] <Compn> "business opportunity" [20:57:59 CET] <Compn> heh [20:59:15 CET] <TD-Linux> I got a lot of those when I controlled a .edu domain [20:59:55 CET] <TD-Linux> they are after the high pagerank of a well known domain [21:01:35 CET] <Compn> right [21:02:08 CET] <Compn> i've explained the "we want to help protect your domain by registering ffmpeg.com.cn for you" emails to michaelni before. :) [21:02:41 CET] <Compn> michaelni is too nice really. thats what the problem is. [21:03:13 CET] <michaelni> llogan, yes, that guy was asking since a long time and reynaldo talked with him but reynaldo is busy now and its not entirely clear if its "bad" guy or not [21:06:49 CET] <michaelni> also does adding "nofollow" avoid any "SEO" & "bad" guy issues ? if so we could easily require that to be on any sponsor links [21:07:57 CET] <llogan> ill add it to my todo list and maybe take a look after work [21:08:08 CET] <michaelni> llogan, ok thx [21:23:12 CET] <durandal_1707> why is google now fuzzing encoders and muxers? [21:26:10 CET] <cone-090> ffmpeg 03Paul B Mahol 07master:2009d922db7a: avfilter/avf_showspectrum: add posibility to display phase [21:26:11 CET] <cone-090> ffmpeg 03Paul B Mahol 07master:57df71eaf7c4: avfilter/avf_showspectrum: reduce number of operations [21:34:58 CET] <durandal_1707> Compn: who complained about swscale? [21:35:00 CET] <bencoh> maybe because they heavily rely on those for their transocding farm with user-supplied contentand want them to be not too unsafe? [21:38:42 CET] <Compn> [15:08] <wm4> fritsch: yeah, seems to add libswscale deps (why) [21:38:54 CET] <Compn> durandal_1707 : usual suspects :p [21:39:35 CET] <durandal_1707> Compn: there should not be such dep [21:39:48 CET] <Compn> it needs to convert some colors for the intel driver hw accel [21:39:52 CET] <Compn> what should happen ? [21:40:05 CET] <Compn> previous patch had colorspace conversion in the decoder [21:40:19 CET] <nevcairiel> it should just define the appropriate input format and let ffmpeg.c do the conversion is what should happen [21:41:03 CET] <Compn> nevcairiel : great, reply to my mail and put that useful comment on the ml so person can fix it [21:41:22 CET] <Compn> i think you already did before [21:41:28 CET] <Compn> maybe got ignored/missed [21:41:44 CET] <nevcairiel> he didnt even bother to fix the obvious ugly mistakes and re-posted this giant patch without a single line of acknowledgement of the feedback we have given [21:42:22 CET] <Compn> perhapse a mail linking to the missed comments is in order then [21:42:32 CET] <nevcairiel> it certainly doesnt feel likely at this stage that the commit is going to be acceptable anytime soon [21:42:46 CET] <Compn> i'm not saying to commit anytime soon either. [21:42:55 CET] <Compn> just talkin bout it bout it. [21:48:51 CET] <durandal_1707> I'm really proud of writing first VV->A filter in lavfi [22:00:14 CET] <llogan> which one is it? sorry, i was just sitting here mouthbreathing and not following lately [22:32:42 CET] <durandal_170> llogan: spectrumsynth, reverses showspectrum [22:36:40 CET] <wm4> how does it sync the two video streams? [22:37:49 CET] <cone-090> ffmpeg 03Paul B Mahol 07master:57e4571679cd: configure: showspectrum now uses fft, add showspectrumpic [22:40:26 CET] <durandal_170> wm4: they must have same properties, it picks one by one [22:40:48 CET] <durandal_170> in fifo [22:50:59 CET] <wm4> so what if one stream has 30 fps and the other 60? [22:51:33 CET] <kierank> loooool mixing vfr streams [22:51:49 CET] <kierank> goodluckwiththat [22:52:36 CET] <nevcairiel> could be cfr, but different [22:58:25 CET] <durandal_170> wm4: it check frame rate, if it doesn't match it aborts [22:58:40 CET] <wm4> that's... not very robust [23:06:12 CET] <J_Darnley> Does ffmpeg have a difference video filter? [23:06:46 CET] <Compn> dont think so [23:07:10 CET] <Compn> would be nice to make wrapper script for other filter/features of image processing [23:07:24 CET] <Compn> that way we dont have to reinvent wheel for every thing , but hey i'm crazy... [23:09:03 CET] <durandal_170> J_Darnley: see blend filter [23:09:25 CET] <durandal_170> and tblend [23:09:48 CET] <J_Darnley> ah thanks [23:10:10 CET] <durandal_170> Compn: you should learn or keep calm [23:17:08 CET] <J_Darnley> Damn. I've just seen that I've got a stuck pixel. [23:21:07 CET] <J_Darnley> Difference too small to see with naked eye [23:22:02 CET] <J_Darnley> time for an expression! [23:26:23 CET] <J_Darnley> good. it isn't always wrong [23:26:24 CET] <durandal_170> On monitor? [23:26:29 CET] <J_Darnley> yes [23:26:36 CET] <J_Darnley> stuck on bright red [23:27:01 CET] <J_Darnley> or rather green and blue are stuck on 0 [23:54:57 CET] <cone-090> ffmpeg 03James Zern 07master:1a876cc581e7: libvpxdec: fix 'ISO C90 forbids mixed declarations and code' warning [23:56:58 CET] <kierank> michaelni: can you elaborate on what else could be done to speed things up [23:59:16 CET] <michaelni> not open/close the reader between each symbol, and decode multiple symbols at once (there are many ways to do that) like do 2symbols at once like we do for huffyuv or decode a run of zeros with the fllowing symbol as one symbol if its bitlength fits in a LUT / VLCtab [00:00:00 CET] --- Wed Jan 13 2016

1 0

ffmpeg.log.20160112
by burek 13 Jan '16

13 Jan '16

[05:03:40 CET] <thebombzen> so it appears ffmpeg has a delay when reading from a webcam. do we know why this is? [05:03:53 CET] <c_14> buffer? [05:22:24 CET] <thebombzen> well yes. but can I get rid of it? [05:22:37 CET] <c_14> not really [05:22:54 CET] <thebombzen> then why can mplayer play it without a buffer. [05:23:09 CET] <thebombzen> if ffplay/ffmpeg can't. [05:23:36 CET] <c_14> Well it probably could, but the buffer isn't really settable. [05:23:46 CET] <c_14> You could try setting probesize/analyzeduration to something small [05:24:50 CET] <thebombzen> I tried that. didn't work. also tried -avioflags direct -fflags nobuffer [05:25:11 CET] <thebombzen> also, did anyone ever figure out the whole bitstream filter issue? I think it might actually be a bug. [05:26:29 CET] <c_14> if you do ffmpeg <your input options> -c copy -f mjpeg out.mjpeg; and then use the bitstream filter on that file does it work? [05:27:48 CET] <thebombzen> I just tried that. it still whines. [05:28:14 CET] <c_14> then it might be a bug [05:28:20 CET] <c_14> open a ticket on trac [05:29:22 CET] <thebombzen> ah. looks like I have to compile a minimal build :P [05:29:32 CET] <thebombzen> oh well. worth it. [05:45:38 CET] <c_14> Oh, if you can. Can you attach a sample as well? [05:49:31 CET] <thebombzen> Opened a bug, attached a short sample. [06:28:45 CET] <kuroro> i want a very precise cut of a video (i.e milliseconds in duration), from 00:00:00.120 to 00:00:00.340, after reading some resources online, it seems like this is difficult as ffmpeg is "forced to only use/split on i-frames" [06:29:00 CET] <c_14> only if you don't reencode [06:29:10 CET] <kuroro> im interested in learning more about why it has to split on i-frames [06:29:40 CET] <kuroro> c_14, so if i reencode, precision cutting would be possible? [06:29:45 CET] <c_14> Because in order to correctly render P and B frames, the I frames are necessary [06:29:47 CET] <c_14> yes [06:30:33 CET] <kuroro> are there uncompressed video formats by the way? [06:30:40 CET] <c_14> rawvideo [06:30:48 CET] <kuroro> i imagine there wont be any I/P/B frames in there [06:31:02 CET] <c_14> There are plenty of lossless video formats if you just want a lossless conversion. [06:31:10 CET] <c_14> rawvideo is all I-frames [06:31:20 CET] <c_14> There are other i-frame only codecs and some codecs with i-frame only modes [06:31:29 CET] <kuroro> what's an example of rawvideo format ? [06:31:39 CET] <c_14> rawvideo [06:31:41 CET] <kuroro> oh, which codecs are i-frame only? [06:32:00 CET] <c_14> ffv1 was for a while at least [06:32:08 CET] <kuroro> i see [06:32:14 CET] <c_14> it might have gotten P frames though, can't remember [06:32:36 CET] <kuroro> im gonna try reencoding to see if cutting will be more precise [06:34:10 CET] <kuroro> btw, do you have any resource recommendation for learning more about i/p/b frames (i.e from a programming standpoint ideally), and not just the MPEG standard [06:34:40 CET] <c_14> There's probably a bunch of tech talks out there. [06:35:06 CET] <c_14> Maybe more if you go into specially motion prediction/motion compensation. [06:35:17 CET] <c_14> eh, no not compensation that's something else [06:35:30 CET] <c_14> well [06:35:35 CET] <c_14> w/e [06:36:25 CET] <kuroro> ic. im just curious if we can remove I/P frames from a video, and have video players only play the B frames [06:36:35 CET] <c_14> no [06:36:35 CET] <kuroro> basically just showing the changes [06:37:05 CET] <c_14> The P/B frames are mainly the parts of the video that completely changed along with a bunch of motion vectors. [06:37:07 CET] <kuroro> but theoretically, would it be possible to create a custom player that plays only the b frames :) [06:37:13 CET] <c_14> Depending on the exact changes you could display _something_ [06:37:15 CET] <c_14> sure [06:37:17 CET] <c_14> but [06:37:19 CET] <c_14> eh [07:36:02 CET] <k_sze> Anybody has any idea what pixel formats are supported by Google Chrome's H.264 decoder? [07:37:33 CET] <chungy> yuv420p and yuv444p should both work. Can always make 10-second tests :P [07:39:02 CET] <k_sze> It looks like Firefox only supports yuv420p. :( [08:33:43 CET] <inhahe> Do .flv files store their audio in .aac form? Why when I convert a file from .flv to .m4a using ffmpeg it's slow, indicating that it's decoding and re-encoding the data? How do I just extract the audio directly to an audio file? [08:37:35 CET] <waressearcher2> inhahe: -c:a copy [08:39:49 CET] <inhahe> what is "copy" in that? [08:39:56 CET] <inhahe> is that part of the command? [08:40:02 CET] <inhahe> or do i replace that with an output file name/ [08:41:34 CET] <waressearcher2> ffmpeg -i input.flv -c:a copy output.m4a [08:41:45 CET] <inhahe> thank you [08:42:21 CET] <waressearcher2> bitte [08:59:35 CET] <inhahe> waressearcher2: woah, i noticed that when i do that the output file, the m4a, is actually larger than the flv (almost the same size) [08:59:41 CET] <inhahe> does it include the video in the m4a? [08:59:47 CET] <inhahe> can i use -nv with c:a copy? [09:03:42 CET] <waressearcher2> ja [09:09:24 CET] <xintox> waressearcher2: howdy [09:11:05 CET] <waressearcher2> xintox: hallo, whe geht's ? [09:13:25 CET] <inhahe> that worked (-vn) [09:18:01 CET] <xintox> waressearcher2: howdy mate! [09:18:06 CET] <dongs> should I be able to extract hdmv_pgs_subtitle using ffmpeg? [09:18:25 CET] <dongs> i see https://trac.ffmpeg.org/ticket/2208 but thats a 3 years old bug, i guess it should be fixed by now? [09:24:13 CET] <dongs> never mind, TSMuxeR handle it [09:50:15 CET] <inhahe> waressearcher2: when using c:a copy from flv to m4a, it works but one thing that shows up is "[ipod @ 000000000051eee0] Codec for stream 0 does not use global headers but container format requires global headers" - does it automatically put those global headers in for me, or is it actually writing .aac files and not m4a? (my understanding is that m4a is aac + global headers) [10:13:52 CET] <waressearcher2> inhahe: Äh, 'tschuldige ich habe echt keine ahnung [10:14:46 CET] <inhahe> ok, anyone know? [11:12:55 CET] <gilbahat> hi, quick question which I couldnt find the answer for on docs. I have built ffmpeg with vdpau (enable-vdpau shown on compile options) but I still didnt get it as a hwaccel option. what could be the reason? [11:27:25 CET] <gilbahat> I am trying to explicitly enable them in the conf and still the printout is enabled hwaccels: (i.e. blank) [11:40:34 CET] <codingquark> Need some help: I encoded a video with libx264 (medium preset). Need to play it in Firefox browser. I'm able to play it with mkv container but not with mp4 container. What am I missing? [11:41:32 CET] <furq> are you sure you've got that the right way round [11:42:56 CET] <codingquark> furq: meaning? [11:43:13 CET] <furq> it should be able to play mp4 but not mkv [11:43:56 CET] <codingquark> No, this is what is happening. Should I link the video? [11:44:13 CET] <furq> sure [11:44:45 CET] <codingquark> videodeckassets.s3.amazonaws.com/10000/long.mkv [11:44:56 CET] <codingquark> videodeckassets.s3.amazonaws.com/10000/long.mp4 [11:45:17 CET] <furq> yeah the mp4 plays and the mkv tries to download [11:45:21 CET] <furq> which is exactly what i'd expect [11:45:38 CET] <codingquark> With mp4, the browser shows 'video corrupt' [11:45:52 CET] <codingquark> How come it plays on your Firefox?! [11:46:12 CET] <furq> are you on the latest firefox [11:46:14 CET] <codingquark> Also, it is noteworthy that everything plays fine on Chrome. [11:46:20 CET] <furq> and do you have any plugins installed which would try to hijack movie playback [11:46:25 CET] <codingquark> Firefox 43 [11:46:29 CET] <furq> i think there are VLC plugins and whatnot which do that [11:46:56 CET] <furq> if mkv is playing in the browser then i assume it's not using firefox's builtin player [11:46:57 CET] <codingquark> Yeah, I think mkv is being played by the VLC plugin. [11:47:15 CET] <codingquark> Then why is mp4 video corrupt? [11:47:24 CET] <furq> no idea, it looks fine here [11:47:34 CET] <furq> try it again with the plugin disabled [11:47:40 CET] <codingquark> Okay. [11:49:24 CET] <codingquark> Now the broswer is crashing when I open the mp4 video. [11:49:39 CET] <codingquark> So, mp4 is the right container to use? [11:49:55 CET] <furq> yes [11:50:10 CET] <codingquark> Okay. Seems a browser problem then. [11:50:49 CET] <codingquark> Thanks for the help. Will check on different versions and plugin settings. If problem persists, will ask again. Thanks again! [11:52:53 CET] <k_sze> It looks like encoding with libx264 used to be non-deterministic? [11:53:01 CET] <k_sze> Is that still the case? [11:56:41 CET] <furq> k_sze: iirc it's deterministic by default [11:57:11 CET] <furq> https://mailman.videolan.org/pipermail/x264-devel/2015-April/011036.html [12:22:21 CET] <k_sze> furq: "This is actually the intended behavior." [12:22:29 CET] <k_sze> but it's not documented at all. wtf [12:30:38 CET] <pgunnars> Hello, was wondering about transcoding webm videos. Is there an argument which lets me retain same quality? [12:31:08 CET] <furq> the same quality as what [12:32:09 CET] <pgunnars> the input file, which is of the same format [12:32:17 CET] <pgunnars> so I'm cutting a webm to webm [12:32:21 CET] <pgunnars> would like to retain the same quality [12:36:00 CET] <relaxed> pgunnars: use -c copy to copy the streams [12:37:20 CET] <pgunnars> relaxed: but -c copy isn't frame accurate (which I need) [12:37:39 CET] <furq> if you're cutting on i-frames then that'll work fine [12:38:03 CET] <furq> oh nvm you already said you're not [12:38:31 CET] <furq> if you need to transcode then there's no way to automatically use the same quality [12:39:38 CET] <pgunnars> -lossless 1? [12:39:57 CET] <furq> that won't lose any quality but it will also result in a massive file which will probably be unplayable [12:40:56 CET] <pgunnars> what would you recommend? [12:41:15 CET] <furq> ffprobe the input file, make a note of the video bitrate and pass that to -b:v [12:41:22 CET] <furq> you'll lose some quality but hopefully not too much [12:44:12 CET] <pgunnars> use -crf as well maybe? [12:45:20 CET] <furq> you can't use -crf as well as -b:v [12:45:28 CET] <furq> you have to explicitly set -b:v 0 to use crf [12:45:50 CET] <furq> crf is generally better though so if you know what that involves then go for it [12:47:26 CET] <pgunnars> furq: don't think thats true [12:47:27 CET] <pgunnars> https://trac.ffmpeg.org/wiki/Encode/VP9 [12:47:38 CET] <pgunnars> Constrained Quality [13:23:31 CET] <wuqiong> hi, how to enable videotoolbox for iOS? [15:21:20 CET] <j105rob> trying to stream to ffserver using ffmpeg and view with VLC, but not seeing any video; where do I start to figure out why this is not working? [15:27:42 CET] <j105rob> the input is via stdin, I am using python to create the frames [15:28:02 CET] <j105rob> so I am calling ffmpeg thru a subprocess [15:32:12 CET] <kynlem_> c_14 bencoh are you around guys? [15:33:39 CET] <kynlem_> i am doing this: ffmpeg -i VideoForCutting.mp4 -ss 0 -t 60.06 -an -vcodec copy ~/noaudio-chunk00.mp4 [15:34:13 CET] <kynlem_> and the durtion of the file comes out as expected: 01:00.06 [15:34:58 CET] <kynlem_> but if i copy the audio as well (-acodec copy), it is 01:00.08 [15:36:11 CET] <kynlem_> the sample rate of the audio stream is 48kHz, doesn't that make it safe to assume that there's an audio sample per each hundredth of a second? [15:36:56 CET] <kynlem_> and if so (and no sample gets cut in the middle), why would ffmpeg pad the audio stream (or cut it at a further point than requested)? [15:40:01 CET] <thebombzen> kynlem: because with -acodec copy it won't cut along the samples, it'll cut along the audio frames [15:40:13 CET] <thebombzen> to get sample-based precision you'd have to reencode the audio [15:41:05 CET] <thebombzen> kynlem_: although lossless audio (like alac in mp4) is actually a reasonable size, but don't expect great compatibility unless it's flac. [15:41:58 CET] <thebombzen> j105rob: try testing the components separately. e.g. first, stream it to a file and see if you get what you want [15:42:40 CET] <j105rob> @thebombzen that is where I am headed now& looks like stdin on the subprocess is not flushing [15:42:42 CET] <j105rob> thx! [15:43:29 CET] <kynlem_> is there a way to list the timestamps of where the audio frames start? [15:44:52 CET] <kynlem_> for instance, with video, i'm lucky enough that in the case of my camera, each 8th frame is an i-frame -- so just had to little math to be on the safe side with where i'm cutting [15:45:42 CET] <thebombzen> unfortunately, I have no idea how to do that. sorry [15:45:49 CET] <kynlem_> so there's still hope that audio frames appear at fixed frequences [15:46:01 CET] <kynlem_> is that common at all? or usually they're starting at random points? [15:46:29 CET] <thebombzen> I think that would have to depend on the encoder or on the codec [16:02:01 CET] <bencoh> you wont get a sample-based precision cut by just cutting/transcoding with ffmpeg [16:02:24 CET] <bencoh> since ffmpeg will just decode audio frames, take the raw frame, pass it to the encoder, and output encoded frames [16:03:22 CET] <bencoh> and as I told you last time, you might even run into the "last few samples" issue where it will need to pad the last frame with blank [16:04:56 CET] <bencoh> btw, a sample is a smallest audio unit, you cant cut it. you probably meant "and no frame gets cut in the middle" [16:05:04 CET] <bencoh> the* [16:05:18 CET] <bencoh> kynlem_: ^ [16:12:33 CET] <kynlem_> bencoh: kudos. is there a way to list the timestamps where each frame starts? [16:14:19 CET] <bencoh> programmatically, sure, with ffmpeg, maybe [16:21:02 CET] <kynlem_> bencoh: how would you accomplish what i am trying to do? [16:21:29 CET] <kynlem_> i need to cut a video into independent pieces (not segments) [16:21:43 CET] <kynlem_> each roughly one minute long [16:22:33 CET] <kynlem_> without sound samples padded at the end [16:23:04 CET] <bencoh> with -c:a copy it's not padded [16:23:46 CET] <bencoh> ffmpeg returns a different length for resulting size, probably because of dts difference between first audio and first video [16:25:19 CET] <bencoh> (or any other reason for that matters) [16:25:33 CET] <bencoh> what's wrong with this method btw? [16:25:52 CET] <kynlem_> when i put these pieces one right after another in adobe premiere [16:25:57 CET] <kynlem_> there's this popping sound [16:26:10 CET] <bencoh> why do you want to stitch with adobe premiere ? [16:26:24 CET] <bencoh> sounds like XY problem :) [16:26:33 CET] <kynlem_> my whole point is to deal with small files [16:27:02 CET] <kynlem_> for the thing i'm making, i only need a small portion of the massive amount of video i recorded [16:27:29 CET] <bencoh> actually I suspect adobe premiere is the one padding when importing your segments [16:27:30 CET] <kynlem_> so if i cut 2gb videos files into smaller chunks, i only need a few smaller chunks for the project [16:28:13 CET] <kynlem_> bencoh: when i stich the videos back with ffmpeg, i don't notice any sort of popping sound [16:28:31 CET] <bencoh> which is why I'm saying adobe is the one introducing the issue :) [16:28:42 CET] <kynlem_> yes [16:29:05 CET] <kynlem_> but when i put the 2gb video files (max size) that my camera produces one right after the other [16:29:12 CET] <kynlem_> there's no such popping sound [16:29:28 CET] <kynlem_> probably because the stream lengths match perfectly [16:29:56 CET] <kynlem_> so i was wondering if i could somehow accomplish that [16:40:57 CET] <bencoh> kynlem_: why dont you just cut the part you need with ffmpeg and import it in adobe? [18:06:24 CET] <Nudin> Hi, I'm having troubles understanding the variables in the setpts-filter [18:08:33 CET] <c_14> Which exactly? [18:08:51 CET] <Nudin> What I would need is a value going from 0 (start of video) to 1 (end of video) I first thought TB could be exactly this, but I'm not sure anymore [18:09:48 CET] <c_14> The setpts filter doesn't know the duration of the video, therefore it can't do what you want it to. [18:11:14 CET] <hurstly> how do you go about setting the pid for the video and audio i.e from one format to another but you wanna keep the same pid if possiable? [18:11:30 CET] <Nudin> damn, but ok, so I'll have to do the normalisation myself. [18:12:18 CET] <Nudin> @c_14: "T" is the original playback-timepoint in seconds? [18:12:40 CET] <c_14> yes [18:14:55 CET] <Nudin> Ok, thanks a lot! (You just ended me of trying to read the sourcecode for 3 hours with only minor C knowlege, so real huge thanks) [18:16:05 CET] <kbarry> I'm looking for a recommended/Suggest OS for using FFMPEG in the *nix world. [18:16:55 CET] <kbarry> I have had a hard time getting it to function on centos 6.5, which is where almost all my *nix experience has been. [18:17:08 CET] <furq> debian, of course [18:17:19 CET] <kbarry> I'm hoping to use ffmpeg, and my mentor suggested I ask the community what OS was preffered. [18:17:23 CET] <kepstin> yeah, that's probably just cause the dependencies are so old on centos 6 [18:17:29 CET] <c_14> If you use a static build it doesn't really matter. [18:17:34 CET] <furq> that too [18:17:43 CET] <furq> but if you're looking for a distro to switch to then debian is pretty good [18:17:55 CET] <kbarry> nah, I wont be switching [18:17:58 CET] <furq> it's hard to find one worse than centOS [18:18:14 CET] <kbarry> my shop is 60% centos 6.5, and the rest if Windows Server 2012 [18:18:19 CET] <kbarry> Hahahaha [18:18:25 CET] <furq> you have my condolences [18:18:26 CET] <kepstin> if you want to stick with centos (used to rpms, whatnot), then consider switching to 7 [18:18:37 CET] <kbarry> We are looking into 7. [18:18:44 CET] <furq> fedora has the same RHEL roots as well [18:19:00 CET] <furq> not that i'm recommending it [18:19:01 CET] <kbarry> Apparently the Architect hasn't had enough experience with Centos7. [18:19:13 CET] <furq> does he demand you capitalise the word architect [18:19:16 CET] <kbarry> so Debian? [18:19:38 CET] <kbarry> Nah, just poor grades in grammar school. [18:19:55 CET] <kbarry> BTW, I appreciate the help. [18:20:01 CET] <furq> debian has ffmpeg in stable's backport repo and in testing and unstable [18:20:11 CET] <furq> the latest version [18:20:13 CET] <kbarry> Sweet. [18:20:19 CET] <kbarry> I have only rarely used debian. [18:20:35 CET] <kbarry> Any gotchas for a newbie to it, that I might want to be aware? [18:20:37 CET] <furq> i've hardly used anything else in years [18:20:43 CET] <furq> aside from the odd venture into freeBSD land [18:20:56 CET] <furq> i've not used centOS recently enough to remember what's different [19:10:15 CET] <j105rob> streaming a known working mpg file to ffserver and the WMP isnt showing the video, it appears to be connected. any hints on debugging what is wrong with the setup? [19:31:00 CET] <pmac_> Hey guys, does anyone here have any recomendations for USB webcams theyve succesfully used with OSX & FFMPEG to live-stream to RTMP? [20:10:06 CET] <gilbahat> Hi, I have just tested ffmpeg with hwaccel videotoolbox and it significantly decelerates decoding. since its relatively new, I cant find much in the way of documentation. can anyone help perhaps? [20:12:15 CET] <TD-Linux> gilbahat, are you trying to decode much faster than realtime? [20:13:34 CET] <gilbahat> at this moment I am just trying to get a synthetic benchmark running before Im going to try it on real workloads. I think I have a slight hint though: I see this when running with hwaccel: [20:13:36 CET] <gilbahat> Input stream #0:0 frame changed from size:320x240 fmt:yuv420p to size:320x240 fmt:nv12 [20:14:17 CET] <gilbahat> I dont see it when running without hwaccel [20:15:04 CET] <gilbahat> TD-Linux: yes, I want to decode as fast as possible, faster than realtime. this is for batch processing, not for playback. [20:15:25 CET] <TD-Linux> yeah hwaccel needs a special pixel format [20:15:34 CET] <TD-Linux> like what are the actual framerates you are seeing? [20:15:52 CET] <DHE> colourspace conversion will impose a performance hit, yeah... [20:15:59 CET] <TD-Linux> if you're aiming for over several hundred FPS I think you're going to really struggle with the hwaccel because it's not designed for that [20:16:22 CET] <TD-Linux> you're going to run in to communication latency [20:16:48 CET] <gilbahat> TD-Linux: atm trying to get the best out of the hardware. at least as a first goal, try to get it faster than CPU and go from there... [20:17:56 CET] <gilbahat> without: frame=23909 fps=6889 q=-0.0 Lsize= 2689762kB time=00:13:17.76 bitrate=27620.4kbits/s with: frame=23909 fps=813 q=-0.0 Lsize= 2689762kB time=00:13:17.76 bitrate=27620.4kbits/s [20:30:39 CET] <gilbahat> is this an ffmpeg limitation, a mac API limitation or hardware limitation? [20:31:07 CET] <gilbahat> (i mean the input colorspace constraint) [20:33:11 CET] <TD-Linux> gilbahat, oh yeah at 813fps I don't think you're going to get much more than that from hw [20:33:27 CET] <TD-Linux> the pixel layout constraint is usually a hw limitation [20:34:23 CET] <TD-Linux> hw usually requires a roundtrip to get each frame out. trying to wake up a process at more than 1khz on os x is pretty untenable [20:36:26 CET] <gilbahat> TD-Linux: its still surprising that CPU does x8 better. cant it do blocks of frames though at least and not go frame-by-frame to avoid it? [20:38:10 CET] <yongyung> So since youtube uses vp9 now, do you guys think it'd make sense to encode videos with libvpx for youtube instead of libx264? Is the encoder good yet? [20:38:30 CET] <dystopia> stick with x264 [20:38:43 CET] <furq> youtube reencodes anyway so just use whichever is most convenient [20:38:52 CET] <dystopia> in a couple of years, switch to x265, when hardware decoders are in everything [20:39:06 CET] <furq> any upload time gains from using vp9 will be wiped out by how much longer it takes to encode [20:39:53 CET] <yongyung> furq: Is the encoder *that* slow? I've got shit internet but an ok PC where I am atm (3570k/4.2gh, less than 1mbit upload) [20:40:09 CET] <furq> maybe i'm doing something wrong but i can't get it to use more than about 20% cpu [20:40:26 CET] <TD-Linux> modern libvpx, 1.4.0 and later, is reasonably fast [20:40:51 CET] <furq> i'm using 1.5 and it's still incredibly slow [20:41:20 CET] <furq> much slower than x265 [20:41:22 CET] <TD-Linux> the crossover point with x264 qualitywise is at like -speed 2 iirc [20:41:52 CET] <TD-Linux> furq, at what speed levels? [20:42:08 CET] <furq> it's still really slow at -speed 4 [20:42:12 CET] <TD-Linux> with x265 you still lose a lot of compression at anything less than -preset veryslow [20:42:30 CET] <furq> iirc i get less than realtime at 480p with -speed 4 [20:42:35 CET] <furq> it's only using one HT core [20:43:10 CET] <TD-Linux> you have to specify -threads and slices manually unfortunately [20:43:16 CET] <furq> yeah that doesn't work [20:43:31 CET] <TD-Linux> well at 480p you'll only have like one slice [20:43:58 CET] <furq> oh? [20:47:45 CET] <gilbahat> TD-Linux: do you know if I can get QSV in mac or is vda/videotoolbox wrapping around QSV with that regards? [20:47:52 CET] <furq> hmm [20:48:05 CET] <furq> it's a bit better with 720p content and -slices 4 [20:48:10 CET] <furq> still only using ~35% though [20:48:21 CET] <bencoh> considering x265 isn't exactly "fast", much slower than x265 means ... really slow ;p [20:48:23 CET] <furq> 20fps at -speed 4 [20:48:28 CET] <TD-Linux> 35% being two of your cores? [20:48:37 CET] <furq> it's a quad core i7 with HT [20:48:45 CET] <furq> so about 1.5 HT cores [20:48:56 CET] <bencoh> HT doesn't help that much for encoding with SIMD optims [20:49:15 CET] <TD-Linux> IIRC min slice width is 512? [20:49:31 CET] <furq> what are recommended options for multithreading anyway [20:49:47 CET] <bencoh> I usually don't count on HT when encoding [20:50:24 CET] <bencoh> (so my ratio is more like 1 than 1.5) [20:51:03 CET] <bencoh> at least for live encoding [20:51:04 CET] <TD-Linux> -threads 8 -tile-columns 6 [20:51:10 CET] <furq> is -frame-parallel still needed [20:51:16 CET] <TD-Linux> no [20:52:04 CET] <furq> yeah that still sucks [20:54:42 CET] <furq> i wonder if it's a windows issue [21:19:51 CET] <j105rob> trying to stream a mpg to a ffserver and the client, in this case VLC shows no output at all. http://pastebin.com/nzF7Jxg4 [21:20:13 CET] <j105rob> Where do I start to look for the issues? [21:21:12 CET] <j105rob> the ffserver out put is here: http://pastebin.com/TeX82eZi [21:25:05 CET] <j105rob> server config is here: http://pastebin.com/RsZcQEBe [21:26:20 CET] <llogan> ffserver is where questions go to die [21:26:26 CET] <llogan> unfortunately [21:27:08 CET] <j105rob> :( [21:27:28 CET] <j105rob> how do people stream? [21:27:35 CET] <j105rob> maybe I am using the wrong tool [21:29:21 CET] <llogan> i don't know. i don't do streaming stuff. [21:32:56 CET] <Betablocker> hi j105rob [21:33:02 CET] <j105rob> hello [21:33:27 CET] <Betablocker> maybe https://datarhei.github.io/restreamer is a solution for you [21:34:18 CET] <j105rob> @Betablocker thx, will look at it now [21:34:33 CET] <Betablocker> it is for livestreaming & you could stream without streaming provider. it is not for big audiences but for normal private cases it is working. you could use youtube live, ustream or smthin like that for big audiences [21:35:26 CET] <j105rob> @Betablocker so, you can use ffmpeg to provide the source of the stream? [21:36:02 CET] <Betablocker> it is invisibel working in the tool in the link above - but yes ist works with ffmpeg [21:36:40 CET] <Betablocker> ffmpeg is a swiss army knife for video - you can do nearly everything with it if you could handle the shell commands [21:37:04 CET] <Betablocker> what kind of video source do u have ? live or vod ? [21:37:20 CET] <j105rob> I am using ffmpeg to create a stream of frames from a FIFO [21:37:34 CET] <j105rob> then I want to send it to a live stream server [21:38:37 CET] <Betablocker> what do you mean with fifo ? [21:38:55 CET] <j105rob> linux FIFO pipe [21:39:04 CET] <j105rob> here is the command I am using: $ ffmpeg -re -f rawvideo -vcodec rawvideo -s 16x16 -pix_fmt argb -r 20 -i /tmp/vid -an http://ffserver.labs.g2-inc.net:8090/feed1.ffm [21:40:51 CET] <j105rob> the /tmp/vid is the FIFO [21:41:13 CET] <j105rob> I am dumping ARGB data arrays into it to create the frame [21:41:29 CET] <pmac_> any recomendations for USB webcams theyve succesfully used with OSX & FFMPEG to live-stream to RTMP? [21:42:00 CET] <Betablocker> same again pmac_ & take al look at http://datarhei.github.io/restreamer could handel that very easy [21:42:24 CET] <Betablocker> @j105rob i do only livestreaming the command is: fmpeg -i "rtsp://video.sour.ce.ip:554/" -map 0 -c:v copy -c:a copy -f mp4 "rtmp://des.tina.tion.ip [21:43:10 CET] <Betablocker> thats an example &. for sending livecontent to an streaming rtmp servern - should work with vod tooif you change your source [21:43:50 CET] <Betablocker> @pmac_ http://www.ideasonboard.org/uvc/#devices [21:44:07 CET] <llogan> i've never found one that doesn't work on linux [21:44:20 CET] <j105rob> thx @Betablocker , Ill try that.. [21:49:03 CET] <pmac_> @Betablocker, unfortunalty it looks like that list is out-of-date, it lists a bunch of Logitech cameras, but they appear to be discontinued [21:50:50 CET] <Betablocker> crap - sry [21:52:32 CET] <Betablocker> like llogan said & it is hard to find cameras that dont work with osx the big player like logitech or microsoft should all work [21:52:52 CET] <Betablocker> the make quite good hardware for usb cameras [22:36:20 CET] <kbarry_> I'm trying to use "tee" to produce multiple (say 2) rtmp streams. [22:37:46 CET] <kbarry_> ffmpeg -i http://SOURCE.COM/FILE.m3u8 -ar 44100 -f flv "rtmp://DESTINATION.net/stream/file" is what I am starting with. [23:32:07 CET] <Hfuy> Hello. I'm writing a script that reads ffmpeg's status information from stderr. It doesn't seem to include the progress info. Where does that come out? [23:33:14 CET] <llogan> what you say !! [23:33:59 CET] <Hfuy> Old meme is old. [23:34:22 CET] <llogan> then you get no answer [23:34:35 CET] <Hfuy> Sigh. Okay. I have no chance to survive. [23:34:37 CET] Action: Hfuy makes his time, etc [23:35:05 CET] <llogan> what i meant earlier is that i didn't quite understand your question [23:35:27 CET] <Hfuy> Well, I've written a windows script host script to do batch processing. [23:35:41 CET] <Hfuy> It reads the StdErr property of the process, which is where ffmpeg sends it status info. [23:36:00 CET] <Hfuy> I get the usual preamble where it lists the configure options of the ffmpeg executable and describes the input file. [23:36:04 CET] <Hfuy> But I don't get the progress info. [23:37:33 CET] <Hfuy> Basically, I get everything down to "Press [q] to stop, [?] for help" [23:38:07 CET] <Hfuy> Also it never seems to exit, even once the job is done. [23:43:55 CET] <llogan> can you show your code? [23:44:34 CET] <Hfuy> Sure, but unless you're familiar with windows script host, it may not help. [23:44:44 CET] <Hfuy> Weirdly, when I redirect with 2>file.txt it works fine [00:00:00 CET] --- Wed Jan 13 2016

1 0

ffmpeg-devel.log.20160111
by burek 12 Jan '16

12 Jan '16

[00:04:39 CET] <J_Darnley> :) [00:04:44 CET] <J_Darnley> having fun? [02:04:10 CET] <cone-072> ffmpeg 03Michael Niedermayer 07master:56ec8f85e2b8: avcodec/ac3enc: Remove duplicate #include [02:04:10 CET] <cone-072> ffmpeg 03Mats Peterson 07master:71f73ee3250a: lavf/matroskadec: Normalize noncompliant A_QUICKTIME/V_QUICKTIME private data [04:08:05 CET] <tmm1> ubitux: yea that should work [04:08:25 CET] <tmm1> are there docs on ass positioning tags? [04:08:32 CET] <tmm1> might take a stab at that [04:09:10 CET] <tmm1> so captions show up under the person speaking [04:31:22 CET] <tmm1> aha found it [09:09:23 CET] <tmm1> ubitux: got positioning working: https://github.com/tmm1/FFmpeg/commit/bd71d74f0 [09:54:58 CET] <ubitux> tmm1: not sure that's a really good idea :p [09:55:39 CET] <ubitux> but about an7, if that's indeed the default alignment, can you put it in the default style? [10:18:44 CET] <wm4> note that mpv discards the default style [10:25:36 CET] <ubitux> huh? why? [10:34:50 CET] <wm4> because the user is supposed to control the tsyle via settings [10:38:09 CET] <ubitux> but that's only if the user has settings, right? [10:38:39 CET] <ubitux> ccaption uses white on black monospace by default typically, you probably want to retain that style [10:44:35 CET] <wm4> no, always [10:44:51 CET] <ubitux> sad. [10:45:50 CET] <wm4> ? [10:47:53 CET] <ubitux> well, you're saying the default style is not honored, while it technically should, so that's sad :) [10:51:06 CET] <wm4> no way I'm letting hardcoded ffmpeg things dictate what the user should see [10:51:27 CET] <fritsch> do you also discard keyframes, cause they are hardcoded? :-) [10:53:34 CET] <ubitux> i don't understand the reasoning, but whatever [10:54:06 CET] <wm4> ubitux: arbitrary positioning, font and font size [10:54:20 CET] <wm4> in mostcases (srt etc.) [10:54:29 CET] <wm4> I'm shocked you don't understand this [10:54:47 CET] <ubitux> it's probably fine for srt and basic subtitles [10:54:57 CET] <ubitux> but it's not in case of more advanced ones like ccaption [10:55:11 CET] <kierank> http://www.theregister.co.uk/2016/01/11/math_bug_splatters_skylake_intel_wo… [10:55:33 CET] <wm4> should have gone with haswell after all huh [10:56:33 CET] <rcombs> hah, nice [11:54:47 CET] <wm4> ubitux: also, considering that CCs can apparently do layouting by putting characters on a grid, you could argue ASS is really not a right representation for them [11:54:57 CET] <ubitux> sure [11:57:16 CET] <wm4> in fact, just using some sort of bitmap font would save a lot of pain (except that you'd have to get this font from somewhere) [13:10:27 CET] <kierank> wm4: how does ass deal with rollup captions? [13:10:40 CET] <wm4> well ass does have animations [13:10:42 CET] <kierank> i remember there was a long brouhah about this in webvtt [13:11:11 CET] <wm4> although it seems modern insane ass subtitles (as seen in the anime scene) use multiple ass events per videoframe now? [13:17:57 CET] <fritsch> anime scene, that's the hi10p + 7.1 flac guys ... [13:18:00 CET] <fritsch> what did you expect? [13:19:04 CET] <wm4> yeah, the subtitle renderer becomes the bottleneck, instead of video decoding [13:19:23 CET] <wm4> libass had to get asm optimizations etc. [13:21:31 CET] <kierank> j-b showed me some anime madness once [13:23:53 CET] <ubitux> you're saying this like it's an exception [13:24:32 CET] <ubitux> i don't consider this like such bad thing though [13:25:30 CET] <fritsch> i consider the anime scene acting totally insane ... [13:25:52 CET] <fritsch> audio / video codec chosen [13:25:57 CET] <fritsch> and so on [13:26:02 CET] <fritsch> that sub stuff just matches [13:27:09 CET] <nevcairiel> flac isnt that insane of a codec [13:50:17 CET] <fritsch> nevcairiel: if your target audio system is spdif based and can only do ac3/ dts for multichannel ... [13:50:22 CET] <fritsch> you got an issue [13:50:44 CET] <nevcairiel> you always got an issue if your system is limited like that ;) [13:50:44 CET] <fritsch> remember: they made their decision at the time an ION-2 was the perfect media center [13:50:57 CET] <fritsch> yeah we talk 2009/2010 [13:51:14 CET] <nevcairiel> but ac3 live encoding is a common feature in many media software if you really must [14:00:44 CET] <fritsch> yeah, yeah, we have it [14:00:50 CET] <fritsch> since several years [14:00:52 CET] <kierank> nevcairiel: there are neckbeards who specifically want dolby or dts encoders [14:01:08 CET] <fritsch> in nowadays android world all want passthrough [14:01:12 CET] <fritsch> cause of the licences ... [14:02:29 CET] <wm4> when they could just use flac or vorbis [14:02:45 CET] <nevcairiel> or even opus these days [14:03:52 CET] <fritsch> "but my receiver supports dts-hd and is not used ..." [14:04:16 CET] <fritsch> technical folks are easy to explain that matter, but everyday joe with his big amp at home - starts whining [14:04:43 CET] <wm4> then educate gim [14:04:46 CET] <wm4> him [14:05:23 CET] <wm4> well the real problem is that hardware essentially stops working if you don't feed it the "usual" [14:44:40 CET] <durandal_1707> anyone know good book about audio resythesis from spectrogram? [15:46:28 CET] <tmm1> ubitux: why not a good idea? [16:37:05 CET] <J_Darnley> I *have* found a "bug" in yasm. Nasm will exit with an "interminable macro recursion" error. Yasm won't. [16:38:25 CET] <ubitux> tmm1: because the playres might not match the real one? [17:36:20 CET] <wm4> nevcairiel: do you happen to know if mingw-w64's latest release includes updated hevc headers yet? [17:37:10 CET] <BtbN> It took them several years to include dx10/11 headers [17:37:15 CET] <nevcairiel> latest release? is that still 4.0? then no [17:37:24 CET] <wm4> 4.0.4 [17:37:37 CET] <wm4> also why are they still on SF, jesus christ [17:37:49 CET] <BtbN> because money [17:37:55 CET] <wm4> I hope that native C99 clang or whatever it is is coming along [17:42:02 CET] <wm4> yeah, no hevc stuff in there [17:42:04 CET] <wm4> what the hell [17:42:20 CET] <nevcairiel> mingw moves slower than anyone else [17:43:46 CET] <nevcairiel> i use a patched mingw-w64 4.0.4 myself now because the official one has a broken mkstemp that makes binutils break randomly [17:44:27 CET] Action: Daemon404 used to use HEAD [17:44:50 CET] <wm4> nevcairiel: do you have that patch handy? I was about to patch 4.0.4 for hevc stuff [17:45:01 CET] <jamrial> that's what i use since it's what's shipped as msys2's mingw64 package [17:45:20 CET] <nevcairiel> wm4: https://files.1f0.de/mingw/patches/mingw-w64-4.0.4-fix-mkstemp.patch [17:45:22 CET] <jamrial> a relatively rencet trunk snapshot [17:45:46 CET] <wm4> nevcairiel: thanks [17:46:26 CET] <wm4> also that dxva main 10 patch, do you plan on updating/posting it, or should I continue this? (maybe adding a private option to allow extended profiles?) [17:47:00 CET] <jamrial> and mingw isn't slow. what seems slow is calling it as part of a make recipe [17:47:27 CET] <jamrial> on windows, that is. cross compiling from linux is fast [17:47:32 CET] <nevcairiel> slow to add things, not slow in building or whatnot [17:48:48 CET] <jamrial> ah right [17:50:30 CET] <nevcairiel> wm4: where would you add a private option, i thought about it and didnt see an obvious spot [17:50:50 CET] <wm4> didn't think much about it - to the hevc decoder? [17:55:34 CET] <cone-652> ffmpeg 03Michael Niedermayer 07master:c71999ef97b7: avformat/dfa: Fix packet leak on error [17:55:34 CET] <durandal_1707> anybody played with spectrumsynth? [17:56:36 CET] <nevcairiel> wm4: that sounds odd, maybe rather go without one then [17:58:31 CET] <wm4> nevcairiel: what else would you suggest for keeping absolute API compatibility? [17:59:05 CET] <nevcairiel> thats why i didnt add one, there was no natural field :D [17:59:51 CET] <wm4> we could add a new pixfmt, but that's IMHO too radical [18:32:38 CET] <J_Darnley> Shit! Trying to work around that infinite loop I cause others. [18:45:26 CET] <durandal_1707> J_Darnley: where? [18:47:12 CET] <J_Darnley> In yasm [18:47:48 CET] <J_Darnley> User error causes an infinite loop trying to expand a define [18:55:01 CET] Action: J_Darnley sighs [18:55:11 CET] <J_Darnley> x264asm has so much indirection [19:12:48 CET] <cone-652> ffmpeg 03Michael Niedermayer 07master:26757b0279b4: avcodec/wavpackenc: Headers are per channel [19:12:49 CET] <cone-652> ffmpeg 03Michael Niedermayer 07master:59c915a403af: avcodec/wavpackenc: Check the number of channels [19:27:17 CET] <tmm1> ubitux: seems to work as expected on 1080p so i assume libass is scaling the coordinates up [20:12:52 CET] Action: J_Darnley facepalms [20:13:09 CET] <J_Darnley> I just moved the bug elsewhere of course [20:14:30 CET] <Daemon404> bugs are like energy, you cant destroy them [20:16:15 CET] <wm4> lol [20:16:49 CET] <wm4> so ffmpeg got a bit piece of the big bang? [20:17:45 CET] <J_Darnley> I wonder how different the nasm and yasm code bases are. [20:19:33 CET] <nevcairiel> isnt it independently implemented [20:20:59 CET] <nevcairiel> ie. based on nasm behavior and syntax, but not code? [20:21:27 CET] <J_Darnley> I thought it was a fork [20:21:28 CET] <J_Darnley> :( [20:21:54 CET] <J_Darnley> "Yasm is a complete rewrite of the NASM assembler" :( [20:23:54 CET] <J_Darnley> And the bug is already in their system: https://tortall.lighthouseapp.com/projects/78676/tickets/156-infinite-loop-… [20:24:11 CET] <J_Darnley> Hey, its from Loren! [20:25:56 CET] <wm4> wow 4 year old bug? [20:26:07 CET] <Daemon404> ... pretty sure the only way the last bug we found in yasm got fixed was by loren sending a patch [20:26:17 CET] <Daemon404> in fact i found a bug in my (very limited) yasm usage [20:26:21 CET] <wm4> wasn't it that yasm is dead now and nasm is back to life? [20:26:22 CET] <Daemon404> in the preproc [20:26:26 CET] <Daemon404> and it was never fixe [20:26:27 CET] <Daemon404> d [20:26:39 CET] <Daemon404> wm4, it had a release in 2014 or 2015 or something [20:27:00 CET] <nevcairiel> yasm 1.3 is relatively new [20:27:09 CET] <J_Darnley> Maybe I should go back to nasm then? [20:30:07 CET] <J_Darnley> They've had 6 releases in 2014 and 2 in 2015 [20:31:03 CET] <Daemon404> ping/bump the bug? [20:32:40 CET] <J_Darnley> I could. I would have to make an account though. [20:33:17 CET] <wm4> tmm1, ubitux: yes, all coordinates in ASS tags use the PlayResX/Y as virtual resolution... but you still could get problems if the aspect ratio mismatches [20:33:52 CET] <Daemon404> [19:32] <+J_Darnley> I could. I would have to make an account though. <-- reason #1 i rareky file bugs [20:33:56 CET] <Daemon404> rarely* [20:34:21 CET] <J_Darnley> I'll start with an email to their devel list. [20:41:57 CET] <J_Darnley> Oh fuck! [20:42:07 CET] <J_Darnley> I subscribed just fine [20:42:28 CET] <J_Darnley> but then my email got returned [21:28:46 CET] <durandal_1707> ubitux: is phase addition to showspectrum ok? [21:31:23 CET] <ubitux> durandal_1707: can't tell if the math are correct, so probably [21:31:44 CET] <ubitux> no performance hurting? [21:32:21 CET] <ubitux> you might want to "constify" the function mode (trick the compiler into creating two functions, one for magn one for phase) [21:32:31 CET] <ubitux> btw, since you're on showspectrum [21:32:47 CET] <ubitux> it might be time to fix the highest and lowest freq computation [21:33:39 CET] <ubitux> (im(1) actually being im(n)) [21:33:54 CET] <ubitux> (im(0) sorry) [21:48:03 CET] <durandal_1707> ubitux: i use its output for ifft input in spectrumsynth [21:49:18 CET] <durandal_1707> with it you can modify frequency with gimp [21:51:20 CET] <durandal_1707> it looks like noise but if its not same resynthesis sound awful [21:52:47 CET] <durandal_1707> ubitux: do I need to replace im0 even if doing ifft? [23:18:37 CET] <cone-652> ffmpeg 03Andreas Cadhalpun 07master:63c9b30f98ce: qtpalette: make the color_* variables unsigned again [23:18:38 CET] <cone-652> ffmpeg 03Andreas Cadhalpun 07master:f6e1c96730eb: ffmdec: change type of len to ptrdiff_t [23:21:07 CET] <cone-652> ffmpeg 03Ganesh Ajjanagadde 07master:07a11ebcab9b: lavc/cbrt_tablegen: speed up tablegen [00:00:00 CET] --- Tue Jan 12 2016

1 0

ffmpeg.log.20160111
by burek 12 Jan '16

12 Jan '16

[00:08:39 CET] <thetrueavatar> Ok I'm leaving you. Thanks for all the time dedicated to support me and sorry if sometimes I have being a bit annoying. Have a good night [00:23:37 CET] <waressearcher2> thetrueavatar: bis bald [01:40:25 CET] <iRy> Is there a way to cache the input before encoding? System Linux [01:40:52 CET] <c_14> copy it onto a ramfs? [01:41:41 CET] <iRy> Kind of. VLC has an option called :network-caching=[time in ms] [01:41:59 CET] <c_14> What does vlc have to do with anything? [01:42:03 CET] <iRy> Looking for similar with ffmpeg [01:42:16 CET] <iRy> Just using it as reference [01:42:25 CET] <c_14> Why do you want it? [01:43:30 CET] <iRy> I've got a network stream which is a little unreliable, some missing frames etc. I would like to cache it before [01:44:04 CET] <c_14> Depending on the stream type it might have a caching/buffer option [01:44:23 CET] <iRy> It's a HLd [01:44:27 CET] <iRy> HLS [01:44:30 CET] <iRy> Stream [01:44:38 CET] <iRy> Sorry cell phone [01:46:10 CET] <c_14> There's a timeout/reconnect_at_eof option [01:46:17 CET] <c_14> Other than that, nothing really. [01:47:49 CET] <iRy> I'll give it a try [01:48:27 CET] <c_14> You'll probably want reconnect_streamed as well [01:50:17 CET] <iRy> Well I'm not loosing the connection sometimes it's just laggy because of one or two missing frames [01:51:12 CET] <iRy> I'll be at the computer in about 15min. I could post the log [01:51:55 CET] <c_14> sure. I mean you could try using -c copy to output to disk and then use that as input, but [01:52:37 CET] <iRy> Was thinking same thing but I would like to avoid that solution [01:53:38 CET] <Logicgate> llogan you around? [01:55:38 CET] <Logicgate> Can one do -t 6s [01:55:47 CET] <Logicgate> instead of -t 00:00:06? [01:55:54 CET] <c_14> drop the s, and yes [01:55:59 CET] <c_14> just -t 6 [01:56:35 CET] <Logicgate> ok thanks [03:40:30 CET] <sagerdearia> Hi all. I'm working on setting up some video surveillance stream administration to work across an open publich mesh network. I am researching to determine if it is possible to convert RTSP streams from ip cams to appear on a web page. [03:40:45 CET] <waressearcher2> sagerdearia: hallo und herzlich willkommen [03:40:49 CET] <sagerdearia> Thanks :) [03:41:03 CET] <sagerdearia> Is it possible to use ffmpeg to produce an rtp stream? and if so, how does that work exactly? [03:41:22 CET] <sagerdearia> I'm currently playing around with this: ffmpeg -i rtsp://172.16.34.232:554/live/ch00_0 -vcodec copy -acodec copy [03:55:53 CET] <sagerdearia> Alright, this is doing something, but I have no idea what: ffmpeg -i rtsp://172.16.34.232:554/live/ch00_0 -vcodec copy -acodec copy -y -f rtp rtp://127.0.0.1:7000/ [03:56:16 CET] <sagerdearia> After running that, I checked `nmap -p 7000 127.0.0.1` but it is still closed and not open [03:57:26 CET] <tdr> you could find that from netstat output too [03:59:15 CET] <sagerdearia> tdr, true: `netstat -a|grep 7000` shows nothing also [03:59:40 CET] <sagerdearia> What does the "-f rtp rtp://127.0.0.1:7000/" actually do? [03:59:56 CET] <sagerdearia> Must I have some kind of server running on port 7000 that is listening for connections before running that ffmpeg command? [04:00:44 CET] <sagerdearia> I think what I am trying to do is run ffmpeg so that in a web page running on local webserver, I can try to display a live video stream that is sourced from the rtsp stream from the ip cam [04:00:54 CET] <sagerdearia> I'm not sure if that will work [04:01:12 CET] <tdr> tried looking for a howoto guide for your setup, may be easier than guessing [04:03:03 CET] <jbg> hello, I get no audio when I play local video files with ffplay. I get the following error: No more combinations to try, audio open failed. Installing libsdl2 didn't resolve my issue. How can I get audio to play? [07:14:39 CET] <Renari> I have a webm encoding command like so: https://gist.github.com/Renari/91574d81defdee2d19c8 [07:15:08 CET] <Renari> Now I'm trying to speedup the video output and read that this can be done by manipulating the keyframes. [07:15:30 CET] <Renari> However in my command this isn't working and I believe it's because I have two -vf flags (thus ignoring the first one). [07:16:10 CET] <Renari> How do I pass multiple filters with vf? Just separate them with commas? [07:17:11 CET] <mark4o> yes [07:19:21 CET] <Renari> Alright, thanks everywhere I checked about video filters was just showing examples of single filters. [07:21:56 CET] <k_sze> Weird. A few days ago I ran `ffmpeg` on a .nut file without specifying -threads, and /proc/<pid>/status shows there were 50 threads [07:22:05 CET] <k_sze> today I run the same thing and I get only 42 threads. [07:22:30 CET] <k_sze> (and I have not added or removed CPUs from the system) [07:24:04 CET] <mark4o> Renari: see https://trac.ffmpeg.org/wiki/FilteringGuide for some more complex examples [07:25:28 CET] <k_sze> And I don't get why the base number of threads seems to be 24. [07:25:56 CET] <Renari> Ah this is separating them within the string with a comma. I separated the strings with a comma and that worked. [07:33:37 CET] <Logicgate> hey guys [07:33:44 CET] <Logicgate> -acodec copy -c:v libx264 -movflags +faststart -crf 18 scale=720:-2:flags=lanczos,format=yuv420p when doing this I'm getting an error [07:33:51 CET] <Logicgate> Unable to find a suitable output format for 'scale=720:-2:flags=lanczos,format=yuv420p' [07:34:19 CET] <mark4o> Logicgate: you need -vf before scale=... [07:34:41 CET] <Logicgate> oh my god lol [07:34:42 CET] <Logicgate> thanks [08:12:40 CET] <k_sze> Similarly weird on Windows: ffmpeg with no -threads argument: total 16 threads according to Task Manager [08:12:53 CET] <k_sze> ffmpeg with -threads 4: total 15 threads according to Task Manager. [08:12:58 CET] <k_sze> And I have 4 real cores. [08:22:44 CET] <odinsbane> k_sze: how much is it working? [08:28:33 CET] <odinsbane> Is it swamping a bunch of cores, or just using multiple threads. [09:17:56 CET] <Logicgate> My god [09:23:58 CET] <waressearcher2> Logicgate: was ? [10:29:46 CET] <k_sze> odinsbane: it *does* look like it uses all 4 cores in any case. [10:30:20 CET] <k_sze> just a bit strange that ffmpeg seems to automatically pick 5 threads when I have 4 real cores. [10:31:58 CET] <furq> it's not that unusual [10:32:14 CET] <furq> e.g. x264 with -threads auto uses (1.5 * logical cores) threads [10:32:22 CET] <k_sze> I only have one FFV1 level 3 stream in a .nut file. [12:18:15 CET] <k_sze> Does ffmpeg have built-in filter to colormap gray data (e.g. gray16le) to color? [12:18:48 CET] <k_sze> I have these gray16le videos that I would like to convert and make them streamable to web browsers. [12:19:06 CET] <sagerdearia> I'm back from previous discussion, for anyone that was around. [12:19:29 CET] <sagerdearia> This is doing something, but I have no idea what: ffmpeg -i rtsp://172.16.34.232:554/live/ch00_0 -vcodec copy -acodec copy -y -f rtp rtp://127.0.0.1:7000/ [12:19:40 CET] <sagerdearia> Must I have some kind of server running on port 7000 that is listening for connections before running that ffmpeg command? [12:20:21 CET] <sagerdearia> What I am trying to do is run ffmpeg so that in a web page running on local webserver, I can try to display a live video stream that is sourced from the rtsp stream from the ip cam [12:20:55 CET] <bencoh> this is not what you're looking for :) [12:21:08 CET] <furq> sagerdearia: yes you must and also web browsers can't play rtp or rtsp [12:21:26 CET] <furq> you probably want HLS or DASH [13:50:48 CET] <thebombzen> I noticed that FFmpeg uses the API of libquvi 0.4, which is the one in the Debian repos, and it's incompatible with the latest git (2 years ago) libquvi. Would that be something we'd switch to, even though it'd break those builds? [14:06:14 CET] <BtbN> Isn't libquvi dead anyway? [14:12:25 CET] <JEEB> pretty much [14:12:31 CET] <JEEB> the AGPL version never went much anywhere [14:12:42 CET] <JEEB> youtube-dl pretty much has been my choice for quite a while now [14:12:57 CET] <JEEB> (unlike its name it supports pretty much all kinds of services) [14:19:32 CET] <bencoh> :( [14:49:06 CET] <sweb> i convert mp3 to ogg but converted file not seekable ffmpeg -i '/home/sweb/www/mymusss/out/Jenny Lewis with The Watson Twins/2006 - Rabbit Fur Coat - 4 - Happy.mp3' -codec:a libvorbis -qscale:a 4 '/home/sweb/www/mymusss/conv/2006 - Rabbit Fur Coat - 4 - Happy.ogg' [14:49:11 CET] <sweb> http://paste.ubuntu.com/14469116/ [15:27:53 CET] <hero_biz> hi guys... [15:28:35 CET] <hero_biz> guys, I wonder if anyone has ever encoded a video suitable for playing on smartphones(around 5" screen). [15:29:11 CET] <hero_biz> I like to know what setting is better for such encods. [15:30:16 CET] <hero_biz> I always use semi-hq settings, so I'm not sure what setting is good for easy play on such small screen. [15:32:50 CET] <DHE> the screen size is of minimal consequence. your bigger issues are hw decoder capabilities and bitrates. find out what the smartphone you're targeting can do and encode to those specs. 5" modern phones can probably do 720p h264 under a Main profile [15:34:04 CET] <DHE> though 720p might sound overkill, this is where you'll want to actually check it yourself. you might think it's a high resolution but people hold phones less than 2 feet from their faces [15:35:23 CET] <bencoh> I'd rather show a well-encoded 480p than a bit-starved 720p, though [15:35:35 CET] <bencoh> but that's up to you (or your customer feedback) [15:36:41 CET] <hero_biz> but I think size is a real concern too. [15:37:08 CET] <hero_biz> because videos for smart phones are the ones that you want to send through apps normally. [15:37:18 CET] <hero_biz> so big videos will be quick problem. [15:37:43 CET] <DHE> I just double-checked my Nexus 5's specs. It has a 1080p screen. So it can PROBABLY do 1080p decoding at 30fps. [15:38:06 CET] <hero_biz> DHE, it can, because I have tested. [15:38:15 CET] <hero_biz> but those videos will be too big... [15:38:29 CET] <DHE> what kind of bitrates are you looking at? 3 to 4 megabit h264 is actually okay for low-to-medium action 720p [15:38:55 CET] <DHE> for, say, a football or hockey game you might want higher [15:39:06 CET] <hero_biz> lets assume someone want to share it through apps, like fb, telegram,... [15:39:37 CET] <hero_biz> I think those rate will be too high for these reasons. [15:40:13 CET] <hero_biz> I think maybe somethign for webrip is more suitable,isn't it? [15:40:21 CET] <hero_biz> *like [15:49:51 CET] <furq> hero_biz: fwiw youtube's 720p videos are usually about 2.5mbit [15:50:06 CET] <furq> i'm pretty sure they run heavy denoising filters on everything though [15:50:54 CET] <furq> if you're concerned about users' bandwidth then you'll probably want to use adaptive bitrate anyway [15:53:23 CET] <DHE> I am a bit confused. you're uploading to facebook, don't they do their own transcoding or other video prep anyway? [15:53:24 CET] <hero_biz> i think I go around crf 25, 320p, maybe somedenoise filter [15:53:47 CET] <hero_biz> DHE, at least youtube does that [15:53:53 CET] <hero_biz> fidelity adaptation [15:54:25 CET] <DHE> so facebook just serves up whatever you give it? [15:54:26 CET] <hero_biz> so people with different bandwidth all could use resulting video suitable for them [15:54:42 CET] <hero_biz> hm...I think facebook encodes too,not sure though [15:56:25 CET] <furq> is this for livestreaming [16:00:22 CET] <_julian> hi [17:49:38 CET] <kynlem> hey. what would be a good lossless audio codec to use inside a mp4 container? [17:49:48 CET] <c_14> alac [17:50:24 CET] <c_14> Not sure there are many others you can even put in mp4 [17:51:23 CET] <c_14> You'll have to use -f mov though. ffmpeg won't find the correct tag if you use -f mp4 [17:52:22 CET] <kynlem> does using -f mov have any other implications? [17:53:48 CET] <c_14> There are minor differences, but it should still be playable. [17:56:05 CET] <furq> it supports ALS and SLS but those are probably even less well-supported than alac [17:56:32 CET] <c_14> Does ffmpeg even have encoders for those? [17:56:37 CET] <kynlem> i see. well, what i need is not lossless encoding per se [17:57:06 CET] <kynlem> i am just splitting a huge video file into many smaller ones (easier to deal with) [17:57:21 CET] <c_14> use -c copy? [17:57:26 CET] <c_14> Should be exact enough with audio [17:57:28 CET] <c_14> eh -c:a copy [17:57:52 CET] <kynlem> yeah, did that. and doing the split at i-frames, so everything's cool with the video [17:58:26 CET] <bencoh> but when merging them back it introduces some a/v desync? [17:58:43 CET] <kynlem> no, i'm just getting a popping sound at the point where the files meet in adobe premiere [17:59:03 CET] <kynlem> tried alac (worked as you said), but still popping sound [17:59:53 CET] <kynlem> i wonder if it has something to do with premiere. this should never be happening when i reencode the audio losslessly when splitting, right? [18:00:54 CET] <c_14> Have you tried concatting the audio streams with ffmpeg to see if it happens there as well? [18:04:06 CET] <kynlem> yeah, just that. no popping sound. does ffmpeg perform any kind of transition automatically when concat'ing? [18:04:16 CET] <c_14> no [18:04:53 CET] <kynlem> i see. is it safe to cut aac stream at any point in general? [18:05:13 CET] <kynlem> or does it have a concept similar to what i-frame is for video streams? [18:05:43 CET] <c_14> If you're copying the audio stream you're cutting at audio frames anyway, so that's fine. If you're reencoding to alac you're reencoding so that's fine as well. [18:08:15 CET] <kynlem> yeah, what i meant is: can i cut it at *any frame* without reencoding? [18:08:33 CET] <c_14> yeah [18:08:53 CET] <c_14> That's what I was trying to say. [18:08:55 CET] <kynlem> thanks, c_14 :) [18:09:37 CET] <bencoh> as long as you dont cut in the middle of an audio frame [18:10:06 CET] <c_14> ffmpeg won't let you do that [18:10:11 CET] <bencoh> oh and, actually you might have issues when re-encoding to an audio codec with a different frame size [18:10:41 CET] <bencoh> since avcodec would have to add some blank samples for the last frame [18:10:54 CET] <kynlem> ffmpeg -ss 120.12 -t 60.06 -i VideoForCutting.mp4 -acodec copy -vcodec copy ~/chunk-02.mp4 [18:11:39 CET] <kynlem> that's what i'm doing basically. it's 1800 (video?) frames per file. [18:12:10 CET] <kynlem> (each 8th frame is an i-frame in case of my camera, so i'm safe on the video side.) [18:13:24 CET] <kynlem> bencoh: is there a way to secure myself from that happening? [18:13:52 CET] <bencoh> use -c:a copy as c_14 told you :) [18:14:06 CET] <kynlem> yeah, i'm doing that [18:14:28 CET] <kynlem> as long as ffmpeg doesn't exit with an error, i can assume the audio frame didn't get cut? [18:14:48 CET] <bencoh> yeah [18:15:17 CET] <kynlem> kudos. [18:15:27 CET] <thebombzen> hey, I seem to be having an issue. I'm getting Mjpeg from a webcam and I want to use the mjpeg2jpeg bitstream filter so I can put jpeg frames in an image2pipe. but the filtert complains that the input isn't mjpeg. [18:16:00 CET] <thebombzen> ffmpeg -f v4l2 -input_format mjpeg -video_size 1280x720 -i /dev/video0 -c copy -f mjpeg -bsf mjpeg2jpeg -y /dev/null [18:16:23 CET] <thebombzen> but it complains that: [NULL @ 0x222f280] input is not MJPEG/AVI1 [18:16:31 CET] <thebombzen> which is wrong. because it's mjpeg. any ideas? [18:18:44 CET] <BtbN> well, which format is it instead? [18:20:18 CET] <thebombzen> it's mjpeg. that's what's weird. [18:20:50 CET] <relaxed> thebombzen: pastebin.com the command and console output [18:21:01 CET] <thebombzen> http://pastebin.com/Tyth5MLp [18:21:03 CET] <thebombzen> here it is [18:21:40 CET] <thebombzen> and then a bunch more error messages like those that I didn't copy in [18:21:50 CET] <thebombzen> by like those I mean Identical to those [18:23:10 CET] <relaxed> lose -f mjpeg and try using img-%04d.jpg as the output [18:24:09 CET] <thebombzen> nope. let me pastebin it [18:24:31 CET] <thebombzen> http://pastebin.com/pkrRdY0e [18:29:22 CET] <relaxed> what if you omit the -bsf ? [18:31:13 CET] <thebombzen> it works: http://pastebin.com/wn5HWYe8 [18:31:41 CET] <thebombzen> however, the jpegs are corrupted. [18:31:51 CET] <thebombzen> display.im6: Huffman table 0x00 was not defined `image0001.jpg' @ error/jpeg.c/JPEGErrorHandler/316. [18:32:01 CET] <relaxed> what are you trying to pipe it to? [18:32:41 CET] <thebombzen> I'm trying to pipe it to a Java program that reads the images from stdin and displays them to the screen. simple Java webcam viewer [18:33:09 CET] <thebombzen> but it shouldn't matter. it should work no matter why I want to do that [18:33:28 CET] <thebombzen> of course, reencoding it with -c mjpeg fixes it. but the idea is not to waste cpu [18:45:48 CET] <thebombz_> Also, using -f image2pipe did not work [20:20:14 CET] <FeeL_LiKe_GoD> Is there any way to obtain real CBR on transport stream via ffmpeg? As far as I tried it seems almost impossible [20:23:11 CET] <DHE> like mpegts? there's a -muxrate option which will pad out the stream with NULLs [20:23:57 CET] <FeeL_LiKe_GoD> Yeah like mpegts. I tried this parameter but TS' CBR still varying [20:56:53 CET] <guest2015> hello [20:57:40 CET] <guest2015> I'm getting an 403 error when trying to download m3u8 playlist file [20:58:06 CET] <guest2015> 403 Forbidden error message, what can I do to download that video? [20:59:27 CET] <DHE> if it's your web server, try checking the error.log [20:59:44 CET] <guest2015> no not my webserver [21:00:04 CET] <DHE> then you're screwed [21:00:24 CET] <furq> do you get a 403 outside of ffmpeg [21:00:37 CET] <guest2015> yes in Safari as well [21:00:46 CET] <furq> well then yeah, what DHE said [21:02:12 CET] <guest2015> but how does the video player on the website "authorize" to play the video? [21:02:20 CET] <guest2015> its included via Javascript [21:02:45 CET] <guest2015> any chances that I can find a key in the source code of the website? [21:03:12 CET] <furq> does safari have builtin developer tools [21:03:16 CET] <DHE> that's up to the player. could be anything from cookies to IP address association that only lasts 10 seconds to a super-secret handshake that only the cool kids know [21:03:26 CET] <furq> in chrome or firefox you could check the request in the developer tools network tab [21:04:28 CET] <guest2015> yes Safari does as well and I have a m3u8 URL but sometimes I can see the video with this URL in Safari and sometimes it results in 403 error [21:05:08 CET] <furq> check the request headers for a successful get of the m3u8 [21:05:27 CET] <furq> it might well be more complicated than that though [22:15:21 CET] <podman> i'm surprised there are so few good tutorials for dash :( [22:18:09 CET] <Betablocker> dash is kinda new & but it will grow in the future [22:18:56 CET] <Betablocker> there are only a few players supporting dash. and the support is often experimental or in a few stadium [22:19:39 CET] <JEEB> most DASH implementations suck... hard [22:19:46 CET] <JEEB> hopefully it will get better [22:20:13 CET] <Betablocker> no need to get in panic - it will grow [22:20:34 CET] <JEEB> I'm not panicing [22:20:46 CET] <Betablocker> just kidding :) [22:21:35 CET] <Betablocker> take a look at the clappr player dash plugin & https://github.com/clappr/dash-shaka-playback [22:22:04 CET] <Betablocker> sounds interesting [22:22:09 CET] <JEEB> I just know I have some needs, like possibly having audio and video not start at the exact same point (like there being 0.9 seconds of audio before the first video picture - which often happens with live streams. and you can guess how well the browser crap (except for Edge's and I think Google's Android's parser) handles it [22:26:18 CET] <podman> I'm just having a difficult time even creating and properly segmenting files for dash [22:26:41 CET] <podman> seems like some implementations don't even like muxed content, like dash.js [22:35:24 CET] <JEEB> do note that how well dash.js works seems to heavily depend on the browser as well [22:35:49 CET] <JEEB> for example under latest chrome beta I can't get that 0.9 second of audio before first video PTS sample to work at all [22:35:53 CET] <JEEB> (a VoD sample) [22:36:14 CET] <JEEB> meanwhile if I use the same damn thing on Firefox Dev Ed (aka aurora), that works OK except doesn't let me seek into the first 0.9 seconds :P [22:36:50 CET] <JEEB> in browsers funny enough MS Edge is the best so far in DASH support [22:36:59 CET] <JEEB> for android there is a google library to support it, which is good [22:37:14 CET] <podman> have you tried other players? like google's? [22:37:16 CET] <JEEB> everything else that is not VLC or so just sucks [22:37:18 CET] <JEEB> yes [22:37:20 CET] <TD-Linux> JEEB, well Edge has as native DASH player, are you using that or MSE? [22:37:30 CET] <podman> https://github.com/google/shaka-player [22:37:31 CET] <JEEB> TD-Linux: of course the native one [22:37:51 CET] <JEEB> podman: that one sucks dongs, is pretty much chrome-specific and only works with content that is done in a very specific way [22:37:57 CET] <JEEB> it's worse off than their android lib [22:38:47 CET] <JEEB> I'm actually more hopeful of the MSE HLS parsers than the MSE DASH implementations [22:39:14 CET] <podman> JEEB: seems fine to me. works in Chrome, Safari, Firefox... Haven't tested in IE yet, but would be surprised if it had issues [22:39:29 CET] <JEEB> podman: then you just haven't tried anything that it doesn't like [22:39:48 CET] <podman> why would i feed it something it doesn't like if i control the source? [22:40:01 CET] <JEEB> because sometimes what you want to do is what it doesn't like? [22:40:11 CET] <podman> ok, well i don't? [22:40:17 CET] <JEEB> well then sure fine [22:40:25 CET] <JEEB> but then again in that case it's not any better than dash.js IIRC [22:40:42 CET] <JEEB> although they're all trainwrecks at this point :P [22:40:45 CET] <JEEB> if they work for you, great [22:40:50 CET] <TD-Linux> some of this is DASH's fault [22:41:06 CET] <podman> dash.js has some random restrictions based on the profiles it supports [22:41:08 CET] <TD-Linux> it's exceddingly flexible [22:41:30 CET] <podman> like it doesn't support muxed audio/video as far as i can tell (at least not their demo) [22:43:18 CET] <podman> "Multiplexed representations are intentionally not supported, as they are not compliant with the DASH-AVC/264 guidelines" [22:43:20 CET] <podman> :( [22:43:43 CET] <TD-Linux> "guidelines" [22:43:57 CET] <JEEB> uhh [22:44:10 CET] <JEEB> what do you mean multiplexed? as in muxed into one source file? [22:44:25 CET] <JEEB> because most DASH examples have had tracks in containers ;) [22:44:51 CET] <podman> i'm not using the dash-avc/264 profile though :\ [22:45:04 CET] <JEEB> I don't give a fuck how it's called :/ [22:45:10 CET] <JEEB> just tell me what it actually means [22:45:33 CET] <TD-Linux> you're not a professional unless you know all of the specifications and acronyms [22:45:40 CET] <JEEB> specs are OK [22:45:41 CET] <podman> multiplexed = muxed [22:45:44 CET] <JEEB> yes, I know [22:45:59 CET] <podman> yes, it means that the audio and video are in a single container in a single file [22:46:03 CET] <JEEB> ok [22:46:07 CET] <JEEB> so what I guessed [22:46:23 CET] <podman> right, it's what it means :P [22:46:34 CET] <JEEB> no, muxed is just muxed [22:46:38 CET] <JEEB> as in, not a raw bit stream [22:46:47 CET] <podman> uh, that's not what that means [22:47:20 CET] <JEEB> "I output a video track into a raw bit stream and then mux it into ISOBMFF" [22:47:53 CET] <JEEB> I do understand the multi in multiplexing [22:47:55 CET] <podman> muxed is short for multiplexed which means combining to signals into one signal [22:48:03 CET] <podman> two [22:48:14 CET] <podman> has nothing to do with raw [22:48:16 CET] <JEEB> well you could think of the container information as another signal :P like timestmaps [22:48:56 CET] <podman> you could, i guess [22:49:00 CET] <JEEB> but yeah, as far as I can see muxing is putting something into a "container" and demuxing is taking something from a container [22:49:13 CET] <podman> sort of [22:49:13 CET] <JEEB> at least that's how it's used around most multimedia OSS circles [22:49:33 CET] <podman> anyway, dash.js doesn't like that [22:49:43 CET] <JEEB> yeah, kind of not surprising [22:53:10 CET] <JEEB> since the idea seems to be to have f.ex. audio completely separate and then X different video sterams [22:53:10 CET] <JEEB> *streams [22:53:10 CET] <podman> which adds an unneeded layer of complexity on to of everything [22:53:10 CET] <JEEB> well you could just support ISOBMFF with fragments, but almost nobody does that :/ [22:53:10 CET] <TD-Linux> JEEB, well the idea is more "generated stream on the fly" so there are use cases where DASH makes sense but the other stuff isn't necessary [22:53:11 CET] <JEEB> (also I love calling it that, lol - such an oversized callsign for the format) [22:53:11 CET] <TD-Linux> probably the best thing to do for now is "whatever youtube does" because most browser implementations are geared basically just for that :/ [22:53:14 CET] <podman> yeah, pretty much. it was interesting reading firefox's discussion about supporting dash [22:53:49 CET] <podman> so, it seems like that's probably the best bet for now. separate audio and video streams, eh? [22:54:03 CET] <podman> I guess that'll save a few megs here and there for our customers [22:54:14 CET] <JEEB> yeah, separately muxed into the sub/superset of ISOBMFF [22:54:25 CET] <JEEB> which DASH uses [23:17:53 CET] <podman> TD-Linux: there isn't a channel for DASH, is there? [23:18:02 CET] <TD-Linux> nope [23:18:11 CET] <podman> or a mailinglist? [23:18:25 CET] <TD-Linux> don't know of any. [23:18:37 CET] <podman> :\ [23:18:44 CET] <TD-Linux> for browser related stuff there is #media on irc.mozilla.org [23:19:15 CET] <podman> i love how flash is "dead" and no one wants to use it anymore but there is really no viable alternative yet. clearly DASH is the successor but there is like zero community that I know of [23:20:06 CET] <TD-Linux> yeah. I don't even know of any opensource working DASH streaming servers [23:22:59 CET] <podman> which is silly because youtube and netflix and the browser makers have crowned dash the successor for video playback on the web [23:26:42 CET] <Kalculus> I'm trying to make a stream like: ffmpeg -f dshow -i audio="Microphone" -c:a libmp3lame -f mpegts udp://192.168.0.255:12345 However, how can I password protect the stream? From the manual it doesn't say udp:// can have a username & pass. Recommendations? [23:32:32 CET] <podman> TD-Linux: well, i got it working with the onDemand Profile and single segments. progress! [23:32:48 CET] <podman> now i just want multiple segments and I'll be happy [23:33:53 CET] <TD-Linux> podman, well to be precise, chrome crowned MSE, not dash :) [23:34:03 CET] <podman> TD-Linux: that's true [23:35:09 CET] <podman> let's see if I can get the live profile to work [23:35:53 CET] <TD-Linux> Kalculus, that's just blasting unencrypted UDP packets. there's no way to protect the stream [23:36:41 CET] <c_14> Besides throwing it over something like an ipsec tunnel or a vpn or something [23:36:43 CET] <Kalculus> TD-Linux: is there a simple way to make a stream from my microphone that requires a username/password to connect to? [23:37:58 CET] <TD-Linux> Kalculus, you can with icecast [23:37:59 CET] <TD-Linux> http://www.icecast.org/docs/icecast-2.4.0/auth.html [23:38:33 CET] <TD-Linux> its a bit more complicated than what you're doing though. you need to both run icecast and a source client [23:39:53 CET] <TD-Linux> the nice thing about icecast though is you can just play the stream in a browser. [23:40:23 CET] <c_14> The easiest thing to do imo would be to forward it over ssh [23:41:28 CET] <Kalculus> oh. let me try Icecast [23:45:56 CET] <Kalculus> For the command I posted above, it's just constantly broadcasting UDP packets all the time? Is there a way I can make it more client/server, so it only sends the stream to a user that connected? [23:46:26 CET] <podman> Interesting, the video is working but the audio is not [23:46:59 CET] <c_14> Kalculus: icecast [23:47:19 CET] <c_14> or maybe tcp with ?listen [23:49:21 CET] <TD-Linux> Kalculus, yeah icecast does what you want. it's designed for internet radio and the like. [00:00:00 CET] --- Tue Jan 12 2016

1 0