Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

April 2015

1 participants
60 discussions

ffmpeg-devel.log.20150424
by burek 25 Apr '15

25 Apr '15

[01:25:27 CEST] <cone-969> ffmpeg 03Andreas Cadhalpun 07master:4b657a1b1eed: alac: reject rice_limit 0 if compression is used [01:56:45 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:c0d847e457c1: tests/fate-run: do not attempt to parse tiny_psnrs output if it failed [03:01:22 CEST] <cone-969> ffmpeg 03Martin Storsjö 07master:eb7ddb506684: rtsp: Don't warn about unparsed time ranges [03:01:23 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:f8951d36dfca: Merge commit 'eb7ddb5066843ab16caf33b05eafb2576648b797' [03:22:16 CEST] <cone-969> ffmpeg 03Andrey Utkin 07master:1bd2646a6da8: rtpenc_jpeg: Handle case of picture dimensions not dividing by 8 [03:22:17 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:cd69c0e0181c: Merge commit '1bd2646a6da808f6f9881525771db098c54bc3d2' [04:01:04 CEST] <cone-969> ffmpeg 03wm4 07master:0f776df09e0b: avformat/wvdec: fix seeking [04:13:46 CEST] <Timothy_Gu> michaelni: are your release branch fate clients using "branch" variable in fate_config.sh? It's messing the server up [04:14:44 CEST] <Timothy_Gu> BTW the new server finally got deployed at http://fatebeta.ffmpeg.org/ \o/ [04:24:34 CEST] <michaelni> they set branch somewhere yes [04:25:43 CEST] <michaelni> i should add some other branches maybe not just releases if the server cannot yet handle that [04:26:18 CEST] <michaelni> or is there a problem on the client side ? [05:10:37 CEST] <cone-969> ffmpeg 03Timothy Gu 07release/2.4:0014b243733d: fate: Include branch information in the payload header [08:58:11 CEST] <cone-359> ffmpeg 03James Zern 07master:acb07f33c40c: git-howto.texi: fix a typo [09:07:37 CEST] <cone-359> ffmpeg 03James Zern 07master:238ec505e263: libvpxenc: only set noise reduction w/vp8 [09:07:38 CEST] <cone-359> ffmpeg 03James Zern 07master:e07ef1ada3d8: libvpxenc: cosmetics: reindent [09:07:39 CEST] <cone-359> ffmpeg 03James Zern 07master:db3f86871eb1: libvpxdec: cosmetics: reindent [10:57:12 CEST] <cone-359> ffmpeg 03Clément BSsch 07master:8e985b727181: avutil/frame: fix everythnig/everything typo [16:19:53 CEST] <BBB> michaelni: do you still need a github tree to merge outstanding patches? [16:20:08 CEST] <BBB> (I have one, its a little old and theres some cruft in it, but it may make your life easier) [16:35:49 CEST] <cone-359> ffmpeg 03wm4 07master:537ab680534e: avformat/mp3: large id3 tags break concatenated file detection [16:36:26 CEST] <michaelni> BBB, i can just apply the patches from the ML, its np [16:38:55 CEST] <BBB> ok ty [16:39:06 CEST] <BBB> I have a current tree here: https://github.com/rbultje/ffmpeg/commits/vp9-profile1-wip [16:39:10 CEST] <BBB> dont take the top 2 patches [16:39:23 CEST] <BBB> they make 444 work but they break 420 (oops) [16:53:55 CEST] <cone-359> ffmpeg 03Ronald S. Bultje 07master:345e3be7baa7: vp9: add lf_deltas fate test. [16:53:56 CEST] <cone-359> ffmpeg 03Ronald S. Bultje 07master:4b02032fb4cf: vp9: add fate tests for show-existing-frame feature. [17:11:20 CEST] <cone-359> ffmpeg 03Ronald S. Bultje 07master:3de13d5212b6: vp9: remove another optimization branch in iadst16 which causes overflows. [17:11:21 CEST] <cone-359> ffmpeg 03Ronald S. Bultje 07master:ed45edb2f6fe: vp9: use aligned size to write segmentation map into cache. [17:11:22 CEST] <cone-359> ffmpeg 03Ronald S. Bultje 07master:0eccf7d43af7: vp9: add fate test for segmentation image-edge issue. [17:11:23 CEST] <cone-359> ffmpeg 03Ronald S. Bultje 07master:640d878bc161: vp9: fix intraonly frame decoding. [17:11:24 CEST] <cone-359> ffmpeg 03Ronald S. Bultje 07master:5d914a4a4334: vp9: add fate test for intraonly frames. [17:29:46 CEST] <BBB> michaelni: ty [17:30:03 CEST] <michaelni> np [17:30:08 CEST] <BBB> michaelni: whats your opinion on merging a (now working) not-yet-bitexact version of profile 1 decoding? [17:30:21 CEST] <BBB> basically everything works and it looks mostly ok, but the loopfilter code hasnt been fixed yet [17:30:52 CEST] <BBB> I wont have much time next week, so we can merge as-is as experimental feature, or just hold off until I get to fixing loopfilter 2 weeks from now [17:30:56 CEST] <BBB> care either way? [17:31:12 CEST] <BBB> (profile 1 = 444/422 support in vp9) [17:31:29 CEST] <michaelni> sounds usefull so i would favor merging [17:32:38 CEST] <BBB> I also havent security-tested it much yet [17:32:44 CEST] <BBB> (Im seeing it segfault in bits) [17:33:03 CEST] <BBB> how about we keep it in my tree for a bit and Ill poke you next week to merge if Ive had time to at least debug the segfaults I see? [17:33:05 CEST] <michaelni> security issues would be not so good [17:33:17 CEST] <michaelni> ok [17:34:19 CEST] <BBB> I think 444/420 work, 422/440 don't [17:34:23 CEST] <BBB> so thats sort of an issue [17:34:24 CEST] <BBB> ohwell [17:41:33 CEST] <BBB> hm ok thats fixed now [17:41:47 CEST] <BBB> its not tested for performance yet, and again, loopfilter for non-420 is broken [17:41:57 CEST] <BBB> but if you dare: https://github.com/rbultje/ffmpeg/commits/vp9-profile1-wip [17:42:29 CEST] <BBB> test samples available at http://downloads.webmproject.org/test_data/libvpx/vp91-2-04-yuv4{22,40,44}.… [17:42:50 CEST] <BBB> now I gotta grab my family and run for the airport, bye [18:50:24 CEST] <cone-359> ffmpeg 03Shivraj Patil 07master:97f074f13404: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for HEVC copy and hv mc functions [20:48:08 CEST] <cone-359> ffmpeg 03Martin Storsjö 07master:b90adb0aba07: rtsp: Make sure we don't write too many transport entries into a fixed-size array [20:48:08 CEST] <cone-359> ffmpeg 03Michael Niedermayer 07master:10a28e8a08d6: Merge commit 'b90adb0aba073f9c1b4abca852119947393ced4c' [20:49:03 CEST] <BtbN> Looks like i successfully eliminated allmost all floating point math. Only thing i couldn't find a replacement for is sqrt [20:51:21 CEST] <michaelni> ff_sqrt() [20:51:34 CEST] <BtbN> That's in libavcodec, i'm in avfilter. [20:52:30 CEST] <michaelni> it could be moved to libavutil, where it was originally [20:52:30 CEST] <BtbN> Was aparently moved there from libavutil, because only libavcodec used it and there were some issues with the table beeing used accross libs. [20:55:21 CEST] <BtbN> It's decently fast with just sqrt. The only major issue left is the pixel format mapping. Do you happen to know if there is some way to map formats? [20:55:43 CEST] <BtbN> BGR0/BGRA->BGRA, RGB0/RGBA->RGBA, and so on. [20:55:52 CEST] <BtbN> In a filter. [20:56:12 CEST] <BtbN> Currently the filter chain just picks whatever output format it likes, even though i don't intend to do format conversions [20:56:46 CEST] <cone-359> ffmpeg 03Vittorio Giovara 07master:5bba3ab0cf7a: internal: Make dlog/tlog a no-op when disabled [20:56:47 CEST] <cone-359> ffmpeg 03Michael Niedermayer 07master:036162a37870: Merge commit '5bba3ab0cf7a0238ee1ea31ca2da08ce860fd8f9' [21:12:46 CEST] <jamrial> if the table is not too big, it could be duplicated in libavfilter [21:13:52 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/HEAD/libavcodec/mathtables.c#L63 it's not too horrible. [21:15:53 CEST] <cone-359> ffmpeg 03Vittorio Giovara 07master:3c04ec04df8c: riff: Add GLV4 fourcc for mpeg4 [21:15:54 CEST] <cone-359> ffmpeg 03Michael Niedermayer 07master:9c56cf09ca6d: Merge commit '3c04ec04df8cba12f3a7408709ff5c1fddfe8d82' [21:25:45 CEST] <wm4> that subtitle guy doesn't seem too bad, although he/she/it keeps posting patches with commented code [21:27:19 CEST] <cone-359> ffmpeg 03Vittorio Giovara 07master:b17cbb0b1c4f: riff: Add GMP4 fourcc for mpeg4 [21:27:20 CEST] <cone-359> ffmpeg 03Michael Niedermayer 07master:861dec5e9025: Merge commit 'b17cbb0b1c4fdf8324eff24d40a02201bfaebfd3' [21:34:51 CEST] <cone-359> ffmpeg 03Vittorio Giovara 07master:a4edaeb50fc7: hq_hqa: Fix table data for profile 17 [21:34:52 CEST] <cone-359> ffmpeg 03Michael Niedermayer 07master:0d3821a6df96: Merge commit 'a4edaeb50fc7510f28a5d79349a7926a182c9930' [21:48:41 CEST] <cone-359> ffmpeg 03Vittorio Giovara 07master:d90133b77bf6: asvenc: Mark codec as init-thread-safe and init-cleanup [21:48:42 CEST] <cone-359> ffmpeg 03Michael Niedermayer 07master:a649650a0ea0: Merge commit 'd90133b77bf69667d10e54de9aae7da223c6876a' [22:00:49 CEST] <cone-359> ffmpeg 03Vittorio Giovara 07master:43171886e08b: huffyuvenc: Mark codec as init-thread-safe and init-cleanup [22:00:50 CEST] <cone-359> ffmpeg 03Michael Niedermayer 07master:f2978aa7ed0f: Merge commit '43171886e08b6a2f20a1e2f3ecc95a7984b591cd' [22:21:04 CEST] <cone-359> ffmpeg 03Vittorio Giovara 07master:bb428e00ac15: hqx: Mark codec as init-thread-safe and init-cleanup [22:21:05 CEST] <cone-359> ffmpeg 03Michael Niedermayer 07master:8d5088a168d1: Merge commit 'bb428e00ac158244d6691bf135be404e85b66a8b' [22:24:42 CEST] <wm4> uh what the heck, why does the png decoder have a delay? [22:24:54 CEST] <wm4> if I feed it one packet, I don't get a picture [22:25:03 CEST] <wm4> it takes a second flush call to get one [22:26:31 CEST] <Compn> hmm, never noticed this in the strings gxavc.dll ... G:\GeoSourceCode\MyCodec\8400_GAVC_EncCheckSize_HalfD1_ChgHdr_POS_176x144_UVPitch_SSE3_Di\x264_v628_vc60\encoder\ratecontrol.c [22:27:16 CEST] <Compn> lots of x264 stufff, strings GXAVC.dll | grep -i x264 [22:47:23 CEST] <cone-359> ffmpeg 03Vittorio Giovara 07master:74a1cad7e3ba: lclenc: Mark codec as init-thread-safe and init-cleanup [22:47:24 CEST] <cone-359> ffmpeg 03Vittorio Giovara 07master:eae7338e1592: libx264: Make codec use the init-cleanup flag and mark it as init-thread-safe [22:47:25 CEST] <cone-359> ffmpeg 03Michael Niedermayer 07master:9ba1c62775ca: Merge commit '74a1cad7e3ba79e5b1e5b2e2bcf6179520442679' [22:47:26 CEST] <cone-359> ffmpeg 03Michael Niedermayer 07master:c180f0f6d398: Merge commit 'eae7338e1592f4a398b7c3cb9d1ac854b7a44ff8' [23:20:38 CEST] <kierank> Compn: is it a gpl violation? [23:23:16 CEST] <cone-359> ffmpeg 03Vittorio Giovara 07master:18db1286b045: libxvid: Make codec use the init-cleanup flag and mark it as init-thread-safe [23:23:17 CEST] <cone-359> ffmpeg 03Michael Niedermayer 07master:437bdf482e92: Merge commit '18db1286b04557aa2d2df7efbcb65ae825d5a469' [23:23:18 CEST] <cone-359> ffmpeg 03Michael Niedermayer 07master:c949a4500e14: avcodec/libxvid: remove now redundant init cleanup code [23:54:57 CEST] <cone-359> ffmpeg 03Andreas Cadhalpun 07master:cfdaa4de6c49: dss_sp: use lowercase codec name without whitespace [23:54:58 CEST] <cone-359> ffmpeg 03Michael Niedermayer 07master:cea62a90c0b7: Merge commit 'cfdaa4de6c496b0b761c763cd18067cb1af268a7' [00:00:00 CEST] --- Sat Apr 25 2015

1 0

ffmpeg.log.20150424
by burek 25 Apr '15

25 Apr '15

[01:23:46 CEST] <Halit> hey guys i have a problem, may i ask questions ? [01:26:30 CEST] <Halit> im trying to applying those filters same time http://pastebin.com/wPwV7xFU [01:26:51 CEST] <Halit> i coldnt find a solution for it [01:27:16 CEST] <klaxa> just add the string from -vf to the -filter_complex [01:27:47 CEST] <klaxa> your string for -filter_complex should look like this: "setpts=PTS/1.07;atempo=1.07;scale=1.2*iw:-1, crop=iw/1.2:ih/1.2" [01:27:57 CEST] <klaxa> it should work correctly, but i haven't tested it [01:30:45 CEST] <Halit> it says no such filter '-vf' [01:31:07 CEST] <Halit> the code was ffmpeg -i input2.mp4 -filter_complex -vf "setpts=PTS/1.07;atempo=1.07;scale=1.2*iw:-1, crop=iw/1.2:ih/1.2" output2.mp4 [01:31:21 CEST] <klaxa> remove the -vf [01:31:33 CEST] <Halit> by the way thanks for answer [01:32:59 CEST] <Halit> it says "cannot find a matching stream for unlabeled input pad 0 on filter Parsed_scale_2 [01:33:37 CEST] <klaxa> hmm let me do some testing [01:34:19 CEST] <Halit> i find a similar job for this http://pastebin.com/9AQwaRSG [01:34:41 CEST] <Halit> but i couldnt edit it for myself [01:35:33 CEST] <klaxa> can you try this: "setpts=PTS/1.07;atempo=1.07;[0]scale=1.2*iw:-1[1];[1]crop=iw/1.2:ih/1.2" ? [01:35:52 CEST] <Halit> im trying [01:40:02 CEST] <Halit> code worked but have couple proglems [01:40:19 CEST] <Halit> setps and atempo has worked [01:40:27 CEST] <Halit> scaling and coping not [01:41:16 CEST] <Halit> and the video time was same i was slowing down video , it slowed the video but rest of video was blank [01:42:46 CEST] <klaxa> what are you trying to achieve with the crop? [01:44:02 CEST] <Halit> I am trying to speed up and zoom the video [01:45:33 CEST] <Halit> i just want the video with %108 speed and %20 zoomed [01:45:48 CEST] <c_14> First, I'd try and explicitly name all input filterpads. Second, don't use numbers as names for the filterpads, in the best case it's confusing, in the worst it might break things. Third, name and explicitly map all output pads. [01:46:18 CEST] <klaxa> yeah it's been a while since i used -filter_complex [01:49:01 CEST] <c_14> -vf setpts=PTS/1.07,scale=1.2*iw:-2,crop=iw/1.2:-2 -af atempo=1.07 [01:49:16 CEST] <c_14> In this case you shouldn't even need a complex [01:50:56 CEST] <Halit> I have tried a lot of codes, but all of them didnt work. and your code says http://prntscr.com/6xfk32 [01:52:30 CEST] <c_14> oooh, does crop not support -2 [01:52:32 CEST] <c_14> hmm [01:54:48 CEST] <c_14> yeah, just change that last -2 to iw/1.2; it might also be better to change the other -2 to a -1 (in the scale) [01:56:01 CEST] <Halit> http://prntscr.com/6xfltz [01:56:27 CEST] <c_14> get rid of the ; [01:58:26 CEST] <Halit> the code was worked, but output file not cropped vertically [01:58:53 CEST] <c_14> you still need the :ih/2 at the end of the vf [01:59:06 CEST] <c_14> -vf setpts=PTS/1.07,scale=1.2*iw:-1,crop=iw/1.2:ih/2 -af atempo=1.07 [02:00:38 CEST] <Halit> now the video was not closed horizontal :):) [02:00:45 CEST] <Halit> cropped [02:01:29 CEST] <c_14> What's your command? [02:01:52 CEST] <Halit> i think its not ih/2 it should be ih/1.2 [02:02:01 CEST] <Halit> yeah [02:02:03 CEST] <Halit> it worked [02:02:12 CEST] <c_14> eh, right [02:02:32 CEST] <Halit> thank you man i'm really appreciate it [02:02:54 CEST] <Halit> I was trying to do this 3 hours [02:03:20 CEST] <Halit> sorry for bad englsh [02:03:27 CEST] <c_14> No problem [02:05:21 CEST] <Halit> permitting more can I ask a question? [02:05:30 CEST] <c_14> sure [02:05:48 CEST] <Halit> lets say i want to add another command [02:05:56 CEST] <Halit> like watermark video [02:06:08 CEST] <Halit> the code is ffmpeg -i input.mp4 -i a.png -filter_complex "overlay=(W-w)/1:(H-h)/1" output.mp4 [02:06:25 CEST] <Halit> how can i add this to our last commands [02:06:57 CEST] <Halit> first we will need to get rid of filter complex :) [02:08:11 CEST] <c_14> Change the filters to -filter_complex '[0:v]setpts=PTS/1.07,scale=1.2*iw:-1,crop=iw/1.2:ih/1.2[tmp];[tmp][1:v]overlay=(W-w)/1:(H-h)/1[v];[0:a]atempo=1.07[a]' -map '[v]' -map '[a]' [02:10:41 CEST] <Halit> it says http://prntscr.com/6xfqch [02:11:11 CEST] <c_14> eh, right. Windows. replace all ' with " [02:11:26 CEST] <c_14> Windows doesn't like single quotes. For whatever reason. [02:14:23 CEST] <Halit> Thanks man it worked [02:14:49 CEST] <Halit> if I did this on ubuntu , I would use ' for " ? [02:15:02 CEST] <c_14> In thase case it shouldn't matter. [02:15:04 CEST] <c_14> Call it force of habit. [02:15:10 CEST] <c_14> *this [02:15:35 CEST] <Halit> okay thank you again [02:15:52 CEST] <Halit> You saved me from a big trouble [02:59:02 CEST] <trodis> hi there is there a tutorial which explains how to configure ffserver to stream opus codec [03:10:07 CEST] <anon131> zeranoe.com is down? [03:12:59 CEST] <jaggz> I need some help with a screen recorder that's making the audio out of sync with the video. It (activepresenter) records the video and audio separately, and the audio is 4 seconds out of sync with the video by the end... [03:13:01 CEST] <jaggz> http://www.pasteall.org/58029 [03:13:42 CEST] <jaggz> activepresenter's docs say this happens when the audio sampling rate, in windows, is off from its value, although I have those now both at 44100 [03:15:06 CEST] <jaggz> although I just noticed the Stereo Mix is set to 2 channels, while the video capture software is set to Mono. I'm not sure if that could cause the issue or not [03:16:33 CEST] <jaggz> I'm joining them with this: ffmpeg.exe -y -i "$1" -i "$2" -af "compand=0:1:-90/-900 -70/-70 -21/-21 0/-15:0.01:12:0:0" -c:v libxvid -b:v 100k "$3" [03:17:43 CEST] <jaggz> Video input is Duration: 01:54:52.94, and audio is 01:54:48.86 [03:20:11 CEST] <jaggz> so I have two issues: 1. the original cause (probably not on topic for this channel, but if anyone has any insight...), and 2. How to correct past recordings to get them back in sync [04:00:56 CEST] <jaggzt> nobody around eh? [05:16:32 CEST] <anon-136136> I'm trying to scale an input clip before converting it to gif with a supplied palette. I don't know how to use both filters at once. http://pastebin.com/Ys4Yy6WW [11:17:47 CEST] <luc4> Hello! Is it possible with ffmpeg or ffprobe to extract information from a media in a structured format, like XML? [11:18:48 CEST] <luc4> I found -print_format but it does that only partially. [11:25:41 CEST] <BtbN> Partialy? Looks like xml to me. [11:33:21 CEST] <luc4> BtbN: yes, valid, but partially structured... https://paste.kde.org/pirthvsbw [11:33:42 CEST] <luc4> BtbN: do you see the same? [11:33:59 CEST] <BtbN> I see you didn't check what's on stdout and what's on stderr. [11:37:05 CEST] <luc4> BtbN: sorry, you mean I should only take stdout into consideration? https://paste.kde.org/p9n6wrsap [11:37:45 CEST] <luc4> BtbN: oops, sorry, bad paste: https://paste.kde.org/pboq8za8k [11:37:56 CEST] <BtbN> looks fine to me? [11:37:59 CEST] <luc4> BtbN: but this is not the same info... [11:38:12 CEST] <BtbN> read the manpage on how to get which info then. [11:38:16 CEST] <luc4> BtbN: I mean... there is less data in here. [11:38:24 CEST] <BtbN> there is a huge bunch of -show_whatever options. [11:38:33 CEST] <luc4> BtbN: ah I see [11:38:37 CEST] <luc4> BtbN: thanks! [11:58:33 CEST] <Fyr> guys, can anyone provide me with QuickTime libraries from iTunes (needed it for QAAC). [12:05:23 CEST] <Fyr> (No longer applicable) [12:52:25 CEST] <luc4> Hello! In this output https://paste.kde.org/pboq8za8k, I suppose format refers to the container, does it? But what does it mean format_name="mov,mp4,m4a,3gp,3g2,mj2"? [13:01:28 CEST] <Mavrik> luc4, yeah, in ffmpeg terms "formats" are (mostly) containers [13:01:42 CEST] <Mavrik> you're getting the list of those because those are essentially the same and are handled by the same muxer [13:01:59 CEST] <Mavrik> and ffprobe will just dump the "description" field of a muxer there :) [13:02:30 CEST] <luc4> Mavrik: oh, I see. Isn't there an ID that I can clearly map to a specific container? [13:02:52 CEST] <Mavrik> uh [13:03:05 CEST] <Mavrik> they all have the same ID :) [13:03:15 CEST] <Mavrik> because they're the same, that's what I'm telling you [13:03:39 CEST] <Mavrik> and I don't think it will tell you internal metadata field that differs them [13:03:43 CEST] <luc4> Mavrik: yes, I know... I thought those where similar, not exactly the same... [13:03:59 CEST] <Mavrik> yeah [13:04:07 CEST] <Mavrik> luc4, I think you'll just have to fall back to the extension in that case :/ [13:04:16 CEST] <luc4> Mavrik: but I also see format_long_name="QuickTime / MOV". So this uses the extension? [13:05:15 CEST] <Mavrik> luc4, nop, see the source: https://ffmpeg.org/doxygen/trunk/mov_8c.html#a31dd0edb055c69d828c83b97365bf… [13:05:21 CEST] <Mavrik> you'll get that for everything handled by mov muxer [13:05:54 CEST] <luc4> Mavrik: so including mp4? [13:38:14 CEST] <jkli> hi guys [13:38:50 CEST] <jkli> when i want to speed up a video , like by 200% and is there a simple way to do it without re-encoding the whole video? [13:40:27 CEST] <jkli> geez, loading ffmpeg windows build with 30KB/s [13:40:33 CEST] <jkli> why is this so slow... [15:25:50 CEST] <Fyr> guys, what license does FDK AAC Enc have? [15:32:28 CEST] <JEEBsv> custom fraunhofer one, which is why it's under --enable-nonfree [15:32:55 CEST] <JEEBsv> that leads to you not being able to distribute the binary [15:33:03 CEST] <JEEBsv> because of licenses mismatching [15:35:02 CEST] <Fyr> JEEBsv, what if I distribute it in the same directory with the binary of the program? [15:35:13 CEST] <BtbN> You can't do that. [15:35:43 CEST] <BtbN> You can't even do tha without enable-nonfree, unless your program is also under GPL [15:36:01 CEST] <BtbN> Unless it uses the pure LGPL version of ffmpeg [15:36:23 CEST] <Fyr> no, I meant this: [15:36:23 CEST] <Fyr> my_program.exe [15:36:23 CEST] <Fyr> fdaaacenc.exe [15:36:23 CEST] <Fyr> libFDKAAC.dll [15:36:52 CEST] <BtbN> You have to build ffmpeg with enable-nonfree, so you can't redistribute it. [15:37:19 CEST] <Fyr> that's why I'm not talking about ffmpeg. [15:42:14 CEST] <Anoia> icatchersupport <icatchersupport(a)icode.co.uk> [15:42:23 CEST] <Anoia> err, mispaste, sorry [15:45:37 CEST] <trodis> hi there i cant figure out how to stream in combination with ffmpeg + ffserver and the opus codec [15:45:53 CEST] <trodis> right now this is how my config looks like [15:46:00 CEST] <trodis> http://ix.io/i5M [15:46:28 CEST] <JEEBsv> Fyr: if you can follow your software's license together with fdk-aac's license and there's no ffmpeg/libavcodec/etc related then you're OK, it just means that you have read fdk-aac's license and have confirmed that you actually are compliant with it [15:46:44 CEST] <trodis> and this is how i feed the stream ffmpeg -f alsa -i pulse http://192.168.1.138:8090/feed1.ffm [15:47:00 CEST] <JEEBsv> IIRC it contained stuff like having to license properly AAC and friends if you wanted to distribute a binary [15:47:11 CEST] <trodis> when i try to play the stream i get the Error http://192.168.1.138:8090/test.opus: Invalid data found when processing input [15:47:12 CEST] <JEEBsv> IANAL and just read the fine license [17:35:14 CEST] <hydalgo> hello after calling avformat_write_header my time_base is changed from 1/25 to -18082736/1. logging each frame prints 1/2800. I posted the details in stackoverflow: http://bit.ly/1d9ARxJ [00:00:00 CEST] --- Sat Apr 25 2015

1 0

ffmpeg-devel.log.20150423
by burek 24 Apr '15

24 Apr '15

[00:08:26 CEST] <cone-444> ffmpeg 03Tucker DiNapoli 07master:cbe27006cee0: postproc: Made QP, nonBQP, and pQPb arrays [04:21:10 CEST] <BBB> michaelni: if you like, I can upload a tree to github for merging [04:21:18 CEST] <BBB> michaelni: that may be easier than hand-applying all these patches [04:37:56 CEST] <michaelni> BBB, sure but you left 1 minute after you asked [04:41:04 CEST] <Compn> lol [04:56:18 CEST] <jamrial> av_clip_uint8_c() in common.h, shouldn't "return (-a)>>31" be "return (-a)>>31 & 0xFF"? [04:58:31 CEST] <michaelni> the return type is uint8_t so it should be fine [04:59:18 CEST] <jamrial> oh right, missed that [04:59:20 CEST] <jamrial> nevermind then [05:08:41 CEST] <cone-292> ffmpeg 03James Almer 07master:d7f62f033c21: fate: add cinepak encoder vsynth tests [05:29:06 CEST] <cone-292> ffmpeg 03Ronald S. Bultje 07master:e8b4f6d6befc: vp9: add support for resolution changes in inter frames. [05:29:07 CEST] <cone-292> ffmpeg 03Ronald S. Bultje 07master:df287f3e4362: vp9: add fate size for resolution changes. [05:37:57 CEST] <j-b> 'morning [09:17:42 CEST] <durandal_1707> 'morning [11:40:49 CEST] <BtbN> https://github.com/BtbN/FFmpeg/blob/master/libavfilter/vf_colorkey.c#L110 Now it is to convert this to integer-math. Seems to work fine otherwise. [11:53:03 CEST] <ubitux> BtbN: ah cool you've started adding threading [11:53:14 CEST] <ubitux> don't forget to add the flags, otherwise it probably won't have any effect [11:53:49 CEST] <BtbN> It seems to work already. At least it starts it with 5 jobs [11:54:09 CEST] <ubitux> strange [11:54:16 CEST] <ubitux> do you see any performance improvement? [11:54:40 CEST] <ubitux> maybe it's doing 5 slices but... incrementally :p [11:54:41 CEST] <BtbN> Nope, but i'm bottlenecked by the yuv->rgb and rgb->yuv conversion. [11:55:02 CEST] <ubitux> you didn't use the drawutils btw? [11:55:14 CEST] <ubitux> oh well, i'll wait for your next patch :) [11:55:34 CEST] <BtbN> It's still very much work in progress, it's very possible i missed obvious helpers because i simply didn't know about them. [11:55:54 CEST] <ubitux> you shouldn't use av_frame_make_writable [11:56:25 CEST] <ubitux> anyway, will re-review at the end [11:56:31 CEST] <BtbN> Why not? I'd have to copy the entire color plane anyway. [11:56:39 CEST] <ubitux> then get a new buffer [11:56:57 CEST] <ubitux> making it writable is if you need to modify the frame inplace [11:57:09 CEST] <ubitux> there are multiple scenario: [11:57:21 CEST] <ubitux> 1. you can not do in-place processing [11:57:37 CEST] <ubitux> 2. you need to modify the frame [11:58:23 CEST] <ubitux> 3. you can do in-place processing, but if it's non writable you can save a frame copy [11:58:38 CEST] <ubitux> anyway, i'm not sure of your case [11:58:42 CEST] <BtbN> I potentialy have to modify the frame format though. [11:58:50 CEST] <BtbN> As BGR0 gets BGRA in the process for example. [11:59:03 CEST] <ubitux> ah if you have different pixel format, just get a new buffer then [11:59:22 CEST] <ubitux> but do not make your input writable (don't modify it then, just write in the new out) [11:59:42 CEST] <BtbN> It's not realy a diffrent format, i just make use of the formerly unused byte. [12:00:04 CEST] <BtbN> So in-place processing is very much possible. [12:00:22 CEST] <ubitux> mmmh [12:00:30 CEST] <ubitux> i see [12:00:33 CEST] <BtbN> And as the entire RGBA color is in a single plane, i'd have to copy it anyway [12:00:45 CEST] <BtbN> So there shouldn't be much difference between manualy copying it, or make_writable [12:00:51 CEST] <ubitux> are you sure it's not going to do something stupid as mapping ARGB to RGBA typically? [12:01:12 CEST] <ubitux> (like, let's say the previous filters output ARGB and the next filter in the graph can take only RGBA) [12:01:26 CEST] <ubitux> (to save a convert, it might do this) [12:02:09 CEST] <BtbN> yes, i wondered about that. I'm currently setting outlink->format in config_props of my output link. [12:02:12 CEST] <ubitux> you can test it with something like format=abgr,colorkey,format=rgba [12:02:29 CEST] <ubitux> (i suppose) [12:02:45 CEST] <BtbN> I'd basicaly have to somehow tell it that 0BGR gets ABGR, BGR0 gets BGRA, and so on. [12:02:52 CEST] <ubitux> hopefully the pixel format negociation is smart enough to save the convert now [12:03:08 CEST] <ubitux> BtbN: yeah, i don't remember how to achieve that though [12:03:12 CEST] <ubitux> saste might know [12:03:44 CEST] <BtbN> I could avoid that by just accepting Alpha-Formats as input, but then a potentialy unneccsary conversion is done. [12:03:54 CEST] <ubitux> one thing you can do is basically make the frame writable if and only if the pixel format are "compatible" [12:04:12 CEST] <ubitux> and otherwise get a new buffer [12:04:23 CEST] <ubitux> actually... you might just swap the pointers [12:04:54 CEST] <ubitux> oh and btw, you are rewriting every pixel of the same frame [12:05:02 CEST] <ubitux> so technically, you can avoid making it writable [12:05:14 CEST] <ubitux> and if it's not writable, you should get a new buffer instead [12:05:26 CEST] <BtbN> I'm only re-writing the alpha byte of each pixel. [12:05:27 CEST] <ubitux> because making it writable will get a new buffer AND copy the frame data [12:05:34 CEST] <ubitux> ah mmh [13:10:35 CEST] <cone-969> ffmpeg 03wm4 07master:60191e3aec6a: fate: add mp3 CBR seek test [13:39:16 CEST] <BtbN> ubitux, https://bpaste.net/show/29fd51b05f71 it seems to select the wrong output format first(line 75), but later, when it gets the first actual output frame, it switches to the right one(line 105). [13:41:43 CEST] <nevcairiel> dont you have rgba in the command line [13:50:45 CEST] <BtbN> nevcairiel, yes. The problem is, the colorkey filter "converts" bgr0->bgra, rgb0->rgba, ... [13:50:57 CEST] <BtbN> But there doesn't seem to be a way to communicate this in query_formats [13:51:32 CEST] <nevcairiel> there must be other filters that convert some sort of mapping [13:52:27 CEST] <cone-969> ffmpeg 03Vittorio Giovara 07master:45340f9fc77e: network: Do not leave context locked on error [13:52:47 CEST] <BtbN> Haven't found one so far [13:53:15 CEST] <nevcairiel> query_formats does seem to be able to have access the input already, no? [13:53:28 CEST] <nevcairiel> at least vf_scale references the incoming filter connection to figure out pixel formats [13:54:28 CEST] <BtbN> Hm, if the input is already accesible [13:55:07 CEST] <BtbN> I remember reading somewhere that this isn't the case. [13:55:16 CEST] <wm4> BtbN: from what I remember it's not possible, but I might be very much wrong [13:55:21 CEST] <nevcairiel> if i were to implement a filter graph, i would connect it one by one, and only call query_formats once the input was connected .. but of course there is no guarantees lavfi is sane in any way [13:56:11 CEST] <wm4> lavfi tries to do "perfect" format negotiation by doing a global search or something [13:58:24 CEST] <nevcairiel> most filters do in_format=out_format .. they somehow need to be able to know which format is the input to set the proper output format, no? [13:58:42 CEST] <ubitux> BtbN: you should just add some code to swap the pointers if necessary [13:58:58 CEST] <BtbN> swapping what pointers? [13:58:59 CEST] <nevcairiel> rgba doesnt have pointers, its interleaved :D [13:59:02 CEST] <ubitux> so whatever it selects you get back on your feet [13:59:06 CEST] <ubitux> ah damn ofc [13:59:10 CEST] <ubitux> forgot that "detail" [14:00:38 CEST] <BtbN> the vf_scale query_formats just asks swscale is the format is a supported input/output format [14:00:45 CEST] <BtbN> it doesn't reference the actual input format. [14:01:27 CEST] <BtbN> The only solution i see would be to go BGRA-Only as both input and output format. [14:02:15 CEST] <BtbN> But something, somehow is able to handle on-the-fly output format changes. At least my filter works, even though it initialy was negotiated for a diffrent output format. [14:04:48 CEST] <wm4> <nevcairiel> most filters do in_format=out_format .. they somehow need to be able to know which format is the input to set the proper output format, no? <- they set a shared format list for those 2 outputs [14:05:13 CEST] <wm4> then the common lavfi code "reduces" these format lists while minimizing conversions [14:05:25 CEST] <wm4> that's where my understanding ends [14:05:31 CEST] <nevcairiel> sounds evil [14:06:25 CEST] <BtbN> So basicaly, a filter that does some kind of mapping just isn't supported? [14:06:38 CEST] <nevcairiel> apparently [14:06:56 CEST] <nevcairiel> is changing the format after init bad? [14:07:20 CEST] <BtbN> That's what i'm doing. I change the outlink format in its config_props [14:07:25 CEST] <BtbN> And it actualy does work [14:09:50 CEST] <wm4> BtbN: you should ask one of those who actually know [14:09:58 CEST] <wm4> like saste I suppose? [14:10:07 CEST] <wm4> maybe ubitux and Nicolas George [14:10:27 CEST] <ubitux> i think you should just remap yourself inside your code if necessary [14:11:00 CEST] <BtbN> So basicaly implement full RGB color format conversion? [14:11:08 CEST] <ubitux> also, you might want to work with native rgb endianess and be done with that [14:29:42 CEST] <BtbN> ubitux, native means bgr0/bgra on little endian, an argb/0rgb on big endian? [14:29:43 CEST] <BBB> BtbN: Id ask michael/stefano, I tihnk that it was supported [14:30:43 CEST] <ubitux> BtbN: #define AV_PIX_FMT_RGB32 AV_PIX_FMT_NE(ARGB, BGRA) [14:31:01 CEST] <cone-969> ffmpeg 03Vittorio Giovara 07master:32da94fa7f73: lavf: Reset global flag on deinit [14:31:01 CEST] <ubitux> #define AV_PIX_FMT_RGB32_1 AV_PIX_FMT_NE(RGBA, ABGR) [14:31:03 CEST] <ubitux> #define AV_PIX_FMT_0RGB32 AV_PIX_FMT_NE(0RGB, BGR0) [15:29:24 CEST] <vadmeste> Hello everybody. I want to be able to copy the m3u8 file generated by ffmpeg when streaming my video online. I just wonder if it is possible that m3u8 could be corrupted.. Is there any mechanism to know that the current state of the m3u8 file regulary updated by ffmpeg is consistent ? [15:30:24 CEST] <Daemon404> is this for hls? [15:30:34 CEST] <Daemon404> if so, it should be atomic. [15:31:09 CEST] <nevcairiel> i made it atomic a while ago, if you use hlsenc [15:31:19 CEST] <nevcairiel> speaking of hlsenc, did your overhead-reduction ever get applied Daemon404? [15:31:32 CEST] <Daemon404> i kinda forgot [15:31:46 CEST] <Daemon404> after angry email came in from some guu [15:31:47 CEST] <Daemon404> guy* [15:32:04 CEST] <nevcairiel> why do people write angry emails about such things [15:33:03 CEST] <nevcairiel> anyone bothered to check if gcc 5.1 miscompiles ffmpeg yet? [15:33:30 CEST] <Daemon404> not yet [15:33:34 CEST] <Daemon404> msys2 has made me lazy [15:33:41 CEST] <Daemon404> and they dont have 5.1 yet [15:33:42 CEST] <nevcairiel> i still dont like msys2 [15:33:48 CEST] <Daemon404> why [15:33:58 CEST] <nevcairiel> i cant just run bash.exe and have a working build env [15:34:01 CEST] <BtbN> Updating to gcc 5.1 is a major pain for most distributors. [15:34:13 CEST] <Daemon404> nevcairiel, wut? [15:34:16 CEST] <Daemon404> you run the shell -> works [15:34:31 CEST] <nevcairiel> yes, with their script that sets up the environment [15:34:35 CEST] <BtbN> I prefer cygwin as unix-like environment on windows. [15:34:36 CEST] <nevcairiel> but not from a plain bash/sh.exe [15:34:58 CEST] <Daemon404> i would never do that anyway [15:35:07 CEST] <Daemon404> i always ran msys.bat [15:35:11 CEST] <nevcairiel> works just fine on my old msys [15:35:33 CEST] <nevcairiel> and i have a bunch of windows batch scripts that call build scripts using sh.exe [15:35:36 CEST] <Daemon404> heh [15:35:53 CEST] <nevcairiel> ie. my fate scripts, for example! [15:36:42 CEST] <Daemon404> my fate scripts work fine in msys2 [15:36:50 CEST] <Daemon404> since i was lazy and did: [15:36:55 CEST] <Daemon404> env > myenv [15:37:02 CEST] <Daemon404> and regex'd it into a shell script [15:37:04 CEST] <Daemon404> (lol) [15:37:17 CEST] <vadmeste> Daemon404: yes it is for hls, thanks for answering, could you just tell me how did manage to implement that atomic update, is it tmp + rename ? [15:37:47 CEST] <Daemon404> yes [15:37:50 CEST] <Daemon404> look at hlsenc.c [15:38:06 CEST] <nevcairiel> my main fate scripts are .bat files because they need to call the microsoft env script [15:38:18 CEST] <nevcairiel> so they just call sh fate-run.sh or something [15:38:21 CEST] <Daemon404> nevcairiel, mine are too. [15:38:31 CEST] <Daemon404> the ycall a wrapper script [15:38:33 CEST] <Daemon404> which loads the env [15:38:53 CEST] <BtbN> cygwin is somehow able to source bat files, i use that for the VC-Env-Stuff. [15:39:05 CEST] <nevcairiel> can you at least use the msys.bat to directly call a command with env setup? [15:39:12 CEST] <wm4> debian already has gcc 5 [15:39:20 CEST] <BtbN> With the old abi only. [15:39:37 CEST] <BtbN> Or did they rebuild the entire system with the new one? [15:39:49 CEST] <nevcairiel> they rebuild the entire system all the time anyway [15:40:06 CEST] <BtbN> Well, this update would require a version bump on absolutele very package. [15:40:16 CEST] <wm4> even pure C ones? [15:40:21 CEST] <nevcairiel> no [15:40:31 CEST] <BtbN> Everything that somehow links against libstdc++ [15:40:33 CEST] <ubitux> it's only related to c++ madness [15:40:35 CEST] <ubitux> as usual [15:40:52 CEST] <BtbN> Can also be C stuff, that linkst against a C++ library. [15:41:02 CEST] <Daemon404> wrong [15:41:10 CEST] <Daemon404> the c stuff by definition only uses teh c abi [15:41:17 CEST] <Daemon404> if it links against a lib which uses c++ it doesnt matter [15:41:20 CEST] <Daemon404> the c abi remains stable [15:41:25 CEST] <Daemon404> only the extrnal lib needs to be rebuilt [15:41:36 CEST] <nevcairiel> indeed [15:53:20 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:06747f8484aa: tests/tiny_psnr: do not ignore errors from run_psnr [16:39:03 CEST] <Prelude2004c> hey guys. can anyone help me with segment.c programming [16:39:20 CEST] <Prelude2004c> need to encrypt data of each created segment ... doesn't seem to have that capability [17:00:35 CEST] <cone-969> ffmpeg 03Ronald S. Bultje 07master:d02619fde301: vp9: add fate test for bilinear MC filter. [17:00:36 CEST] <cone-969> ffmpeg 03Ronald S. Bultje 07master:c82e870c12b2: vp9: maintain lf_delta values if feature is turned off. [17:00:37 CEST] <cone-969> ffmpeg 03Andreas Cadhalpun 07master:58d605ee9b32: alsdec: only adapt order for positive max_order [20:35:30 CEST] <cone-969> ffmpeg 03Ronald S. Bultje 07master:d9555adf06d5: vp9: set timestamps for show_existing_frame return images. [20:35:31 CEST] <cone-969> ffmpeg 03Pedro Arthur 07master:2a7128f4ed00: Add gamma encodign/decoding before/after scaling in libswscale [20:35:32 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:b57f9f57240a: swscale/swscale: Get rid of the SWS_GAMMA_CORRECT flag [21:17:31 CEST] <cone-969> ffmpeg 03Federico Tomassetti 07master:8eb57dc9d5ea: buffersrc: Use the correct deallocation function [21:17:32 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:16576a66626a: Merge commit '8eb57dc9d5ea13c12573e0759da0f7e79825af98' [21:31:29 CEST] <cone-969> ffmpeg 03Luca Barbato 07master:aef0be08756e: avcodec: Unref the dummy buffer on the fail path [21:31:31 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:c39b07ff282a: Merge commit 'aef0be08756e00f363c524453c948a6e2a348614' [21:57:36 CEST] <cone-969> ffmpeg 03Luca Barbato 07master:a78f5548d94f: avcodec: Free the default avoptions on init failure [21:57:37 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:b112e25dde39: Merge commit 'a78f5548d94f23ce23cece41edf0fe9d18926de6' [22:04:50 CEST] <cone-969> ffmpeg 03Luca Barbato 07master:28eddef689f2: hq_hqa: Validate get_vlc2 return value [22:04:51 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:400810abee8f: Merge commit '28eddef689f2b4843a84f7d05fd9614246f92cc4' [22:15:09 CEST] <cone-969> ffmpeg 03Luca Barbato 07master:0a51c7d42a51: prores: Set the bits_per_coded_sample for alpha pix_fmt [22:15:10 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:8d31b22869f6: Merge commit '0a51c7d42a519c63178a4f3e35b8967f21da3a6a' [22:58:35 CEST] <cone-969> ffmpeg 03Timothy Gu 07master:358b7ec3099e: fate: Fix test name for pixfmts tests [22:58:36 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:802c0af68f22: Merge commit '358b7ec3099eca6e999ad9dc0da0a23571a7a2f8' [00:00:00 CEST] --- Fri Apr 24 2015

1 0

ffmpeg.log.20150423
by burek 24 Apr '15

24 Apr '15

[00:00:00 CEST] <hydalgo> hi trying to use av_packet_rescale_ts but it is not defined in the ffmpeg 2.1.3 used by chrome-pnacl.. what is the equivalent function in 2.1 version? [00:05:30 CEST] <hydalgo> my current version for avcodec.h in /usr/local (ubuntu) is 56.34.100, but nacl sdk has version 55.39.101 [00:13:23 CEST] <llogan> kyleogrg: 23.98 is actually 24000/1001 (or the alias ntsc-film) http://ffmpeg.org/ffmpeg-utils.html#Video-rate [00:55:07 CEST] <hydalgo> exit [02:24:39 CEST] <Freakshow> question: how necessary is libfreetype for ffmpeg? [02:25:04 CEST] <Freakshow> stupid ubuntu is tripping on it even with libfreetype6-dev installed [02:28:31 CEST] <llogan> Freakshow: it is needed for drawtext filter [02:28:56 CEST] <Freakshow> llogan: and if thats never used? [02:29:02 CEST] <llogan> then you don't need it [02:29:05 CEST] <Freakshow> :D [02:29:15 CEST] <Freakshow> hooray for not needing! [02:29:44 CEST] <Freakshow> I dont know why its tripping up though, aptitude shows libfreetype6-dev is there& the .pc file is in the correct place [02:30:52 CEST] <llogan> does the tail of config.log have any clues? [02:30:57 CEST] <llogan> what is your ffmpeg configure? [02:31:08 CEST] <llogan> (use a pastebin site if you need to paste multiple lines) [02:36:19 CEST] <Freakshow> sure. crap& I think I just overwrote it after removing the --enable [02:36:20 CEST] <Freakshow> let me check [02:37:47 CEST] <Freakshow> its easy enough for me to reproduce [03:15:55 CEST] <Freakshow> llogan: false alarm& maybe aptitude didnt install when I thought it did [03:16:20 CEST] <llogan> i didn't know people still use aptitude [03:17:07 CEST] <Freakshow> lulz& yeah sometimes its muscle memory really. But after adding it back to the compile it worked this time around. [03:17:43 CEST] <Freakshow> more like apt<tab> and done [03:17:45 CEST] <Freakshow> :P [03:21:54 CEST] <llogan> there is a ubuntu compile guide on the wiki [08:25:34 CEST] <Raptors> Hey guys [08:25:55 CEST] <Raptors> How do you set a keyframe interval of 1 second? [08:26:20 CEST] <Raptors> tried this "-force_key_frames expr:gte(t,n_forced*1)" and -g 30 [08:26:27 CEST] <Raptors> neither worked [08:26:36 CEST] <Raptors> is it because I'm using -vcodec copy? [09:17:13 CEST] <durandal_1707> Raptors: yes [09:25:19 CEST] <jkli> hi guys [09:25:28 CEST] <jkli> is there any way to speed up the video speed? [09:25:35 CEST] <jkli> want to play videos in 200% by default [09:46:56 CEST] <NehezvoltRegelni> Hi! What would you use to have biidrectional audio stream between two linux boxes? (So one's mic on anothers speaker and back) [10:45:48 CEST] <kevmitch> is there a way to get the ffmpeg command line tool to convert audio to "native" pcm type for the input. [10:47:03 CEST] <kevmitch> for example if the input is ac3, 48000 Hz, stereo, fltp -> pcm_f[32|64][le|be] [10:47:43 CEST] <kevmitch> not sure what endianness bit depth is implied by fltp [10:48:21 CEST] <kevmitch> or dts (DTS-HD MA), 48000 Hz, 5.1(side), s16p (default) [10:48:54 CEST] <kevmitch> -> pcm_s16[le|be] [10:50:12 CEST] <kevmitch> it seems that if I specify wav output i always just does pcm_s16le regardless of the input [10:50:50 CEST] <kevmitch> for example that happens with "ffmpeg -c:a libdcadec -i input_with_ac3.mkv -map 0:1 out.wav" [10:51:01 CEST] <kevmitch> oops, sorry [10:51:13 CEST] <kevmitch> ffmpeg -i input_with_ac3.mkv -map 0:1 out.wav" [10:51:22 CEST] <kevmitch> obviously dcadec is not applicable for ac3 [10:52:35 CEST] <kevmitch> or do I have to manually figure this out and specify "ffmpeg -i input_with_ac3.mkv -map 0:1 -c:a pcm_f64le out.wav" [10:52:55 CEST] <RahulAN> Hii all [10:53:08 CEST] <RahulAN> i want to grab certain area of scree [10:53:28 CEST] <RahulAN> *screen in a .png image [10:53:38 CEST] <RahulAN> is it possible ? [10:54:18 CEST] <kevmitch> https://trac.ffmpeg.org/wiki/Capture/Desktop [10:54:57 CEST] <kevmitch> RahuIAN:^ [10:56:34 CEST] <RahulAN> kevmitch, that makes a video [10:56:46 CEST] <RahulAN> i need to have only a screen shot [10:57:50 CEST] <NehezvoltRegelni> RahulAN: man import [10:58:37 CEST] <RahulAN> NehezvoltRegelni, I guess that is what i need [10:59:01 CEST] <kevmitch> yeah, just use .png as output and give it the -t "time for one frame" [10:59:24 CEST] <BtbN> kevmitch, ffprobe -v quiet -show_streams -select_streams a:0 yourinputfile.mkv [11:00:11 CEST] <kevmitch> BtbN: so basically I have to parse it and figure it out for each case? [11:00:23 CEST] <BtbN> ffprobe output is easily parsable. [11:01:13 CEST] <BtbN> ffprobe -v quiet -show_streams -select_streams a:0 -show_entries stream=sample_fmt,sample_rate yourinput [11:02:12 CEST] <kevmitch> so there's no way to get ffmpeg to do "the right thing" for me [11:02:28 CEST] <BtbN> ffmpeg sticks to its defaults unless told to do something else. [11:03:44 CEST] <kevmitch> and does fltp mean 32bit float? [11:04:47 CEST] <BtbN> samplefmt.h describes it as "float, planar" [11:08:30 CEST] <kevmitch> flt/fltp -> pcm_f32le, dbl/dblp -> pcm_f64le [11:22:25 CEST] <capradmar> sorry to insist but I raise a problem here: http://stackoverflow.com/questions/29773692/ffmpeg-crashes-on-startup-upon-… [11:25:28 CEST] <vadmeste> Hello everybody. I am streaming a live video using HLS and I want to use two options to read the stream: 1. live, 2. normal video. I've noticed that is enough to add EXT-X-ENDLIST to a the m3u8 file to switch from live mode but I wonder if there is a better method. Any suggestion ? [11:37:11 CEST] <vadmeste> I can write a shell script which copies the m3u8 file and adds EXT-X-ENDLIST, however ffmpeg is also writing on the same file at the same moment and I wonder if m3u8 copy could be corrupted... [12:57:55 CEST] <juke> hi [12:59:04 CEST] <juke> is there a way to control ffmpeg instance via fifo/telnet/something ? [14:27:23 CEST] <courrier> Hi all! My avconv records artefacs (flashing strips at the top of the image) while grabbing x11 displaying an OpenGL view [14:27:28 CEST] <courrier> see: http://www.cjoint.com/data3/3DxoNU0oUF8_original.avi [14:27:58 CEST] <courrier> Here's my command line: avconv -video_size 800x600 -framerate 20 -f x11grab -i :0.0+30,130 -vcodec libx264 -crf 0 -preset ultrafast original.mp4 [14:28:25 CEST] <courrier> I'm using avconv version 9.18-6:9.18-0ubuntu0.14.04.1, Copyright (c) 2000-2014 the Libav developers [14:28:59 CEST] <courrier> I tried different video codecs but they all produce the same result [14:29:17 CEST] <courrier> Any clue to record a non-flashing screen? Thanks :) [14:35:36 CEST] <sfan5> courrier: did you try ffmpeg instead of avconv? [14:39:10 CEST] <courrier> sfan5: hum, I guess ffmpeg has been replaced by avconv in Ubuntu repos, I thought it was outdated ^^ [14:39:21 CEST] <courrier> But I aven't tried nope [14:41:17 CEST] <klaxa|work> a common misconception [14:51:50 CEST] <courrier> fflogger: oow, thanks [14:52:08 CEST] <courrier> is there still a working ppa to install it easily? [14:52:15 CEST] <courrier> the ppa is the answer is dead [14:56:48 CEST] <klaxa|work> courrier: what about this one? https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media [15:24:42 CEST] <caiman> Hello, i have a question about extract all scene of my video (but with an interval), my first cmd : [15:24:42 CEST] <caiman> ffmpeg -r 1 -i GOPR0016.MP4 -vf select='gt(scene\,0.08),scale=320:240' -an -vsync 0 -qscale:v 2 scene/thumb%03d.jpg [15:24:43 CEST] <caiman> But i would like a next scene every 10sec for exemple, someone have an idea ? [15:45:59 CEST] <CooKieLord> Hi guys, anyone available for a question wrt to the libavcodec libs? [15:46:23 CEST] <CooKieLord> I'm trying to find out what is the proper way to reset a codec (H264 decoder in particular) after I find that it seems to be in an inconsistent state. [15:58:53 CEST] <Mavrik> CooKieLord, just reopen it? [15:58:58 CEST] <Mavrik> and close the previous one [15:59:13 CEST] <CooKieLord> Alright. [15:59:41 CEST] <CooKieLord> I inherited a codebase, and they're calling the avcodec_flush_buffers(videoDecContext) function [15:59:49 CEST] <CooKieLord> Is that also correct? [16:12:31 CEST] <zumba_addict> hi folks, why is my fade in not working? ffmpeg -loop 1 -i dollypic1.jpg -c:v libx264 -t 3 -r 24000/1001 -vf fade=in:0:30 -vf fade=out:42:30 -pix_fmt yuvj444p dollypic1.mp4 [16:16:29 CEST] <c_14> You can't have more than one -vf [16:16:35 CEST] <c_14> Use a filter_complex instead [16:16:46 CEST] <c_14> though [16:16:52 CEST] <c_14> In that case you can probably just chain them [16:29:16 CEST] <zumba_addict> got it [16:29:34 CEST] <zumba_addict> how do I do that c_14, do you have an example? [16:29:51 CEST] <c_14> -vf fade=in:0:30,fade=out:42:30 [16:30:09 CEST] <zumba_addict> ah, my mistake, I used semicolon rather than comma [16:30:26 CEST] <zumba_addict> that's why i had an error earlier, it's like fade=out is not a filter [16:31:33 CEST] <zumba_addict> it worked now :) thanks [16:33:08 CEST] <zumba_addict> and also, is there like a simpler way of calculating for the start and end of fade? I wish all we have to do is mention a duration number where fade will start and end [16:33:51 CEST] <zumba_addict> i always have to calculate the number of frames that is on my video, then estimate an ending or starting frame plus the duration of the shadow [16:37:15 CEST] <c_14> Sadly not without scripting since ffmpeg itself doesn't know how many frames there are in the video before it finishes encoding. [16:38:47 CEST] <Prelude2004c> hey, anyone good at c code ? i need the segment.c workedd on [17:05:11 CEST] <courrier> klaxa|work: thank you :) [18:32:43 CEST] <kyleogrg> hi [18:33:48 CEST] <kyleogrg> I've done some experiments with converting a DVD ISO to x264 MP4 [18:34:03 CEST] <kyleogrg> Or rather, x265 (HEVC) [18:35:05 CEST] <kyleogrg> The ISO is 4.33GB and the x265 MKV is 2.94GB. [18:35:35 CEST] <kyleogrg> I used a very low CRF, somewhere between 15 and 18? [18:35:52 CEST] <kyleogrg> So, does the large file size of the MKV surprise you? [18:36:11 CEST] <RobotsOnDrugs> no, and i bet it took a really long time to encode [18:36:22 CEST] <RobotsOnDrugs> x265 is slow [18:36:34 CEST] <kepstin-laptop> lots of factors affect file size, and 3gb isn't exactly large for a full-length movie with low crf encoding. [18:36:44 CEST] <kyleogrg> yeeeess. I used ripbot264, which now has x265 support, and it took 3 computers about 3 days to encode a 3-hour movie. [18:37:09 CEST] <kepstin-laptop> you're probably encoding at sufficiently high quality that it's doing a very good job of preserving the mpeg2 artifacts from the dvd. [18:37:17 CEST] <kyleogrg> uh-huh [18:37:21 CEST] <RobotsOnDrugs> iirc, you probably want a CRF value in the mid-high 20s for x265 [18:37:41 CEST] <RobotsOnDrugs> 18 is a little low even for x264 [18:37:45 CEST] <kepstin-laptop> yeah, it uses a different scale from x264 [18:38:07 CEST] <kepstin-laptop> and x264 uses a different scale between 8bit and 10bit too, dunno if that's true of x265 [18:38:13 CEST] <RobotsOnDrugs> i wouldn't go as low as 18 with x264 unless the source is really, really clean [18:38:16 CEST] <kyleogrg> so this makes me ask the question: do i want to have a so-called transparent transfer to MKV? [18:38:41 CEST] <kyleogrg> most of these DVDs are recorded off TV [18:38:49 CEST] <kepstin-laptop> kyleogrg, you're the person who has to answer that :) [18:39:10 CEST] <RobotsOnDrugs> DVDs aren't often even close to clean [18:39:19 CEST] <kyleogrg> see, i don't want to go overkill. i was hoping the file sizes would be smaller, but I guess if they are much smaller, i will risk losing quality [18:39:57 CEST] <RobotsOnDrugs> for x265, try a CRF of 35 on a few hundred frames and decide for yourself [18:40:19 CEST] <kepstin-laptop> yeah, you'll just have to experiment and see what you decide on. [18:40:24 CEST] <kyleogrg> yes [18:40:37 CEST] <RobotsOnDrugs> also take a look at denoising filters [18:41:26 CEST] <RobotsOnDrugs> i personally am ignoring x265 for the time being since it is so slow [18:41:45 CEST] <kyleogrg> Is the CRF value fairly objective? For instance, is CRF 18 generally transparent no matter the quality of the source? [18:42:35 CEST] <RobotsOnDrugs> that's hard to say with x265 since they don't have a ton of psychovisual stuff yet iirc [18:43:33 CEST] <kyleogrg> okay, how about x264? [18:44:03 CEST] <RobotsOnDrugs> the quality of the source matters [18:44:38 CEST] <RobotsOnDrugs> you're not going to notice a slight softness if the source has a ton of MPEG2 artifacts [18:45:19 CEST] <__jack__> kyleogrg: you are looking for lossless aren't you ? [18:46:05 CEST] <RobotsOnDrugs> and for clean sources, it can get very subjective since certain kinds of artifacting aren't necessarily noticeable as such, especially with psy optimizations [18:46:09 CEST] <kyleogrg> Not true lossless; just the highest quality at a reasonable file size. (I know that's a vague goal.) [18:46:37 CEST] <RobotsOnDrugs> that is, you might notice a difference if you really looked, but wouldn't necessarily be bothered by it [18:47:28 CEST] <kyleogrg> well, i am not a connoisseur. i'll probably not be bothered by tiny things which would bother ffmpeg users [18:48:09 CEST] <kyleogrg> so i'm looking for settings which normal people generally will accept [18:48:25 CEST] <__jack__> default crf is good then [18:48:35 CEST] <__jack__> default everything, in fact [18:48:52 CEST] <__jack__> just ffmpeg -i source -c:a blabal -c:s clabla -c:v libx264|5 output.mkv [18:49:10 CEST] <kyleogrg> what's c:s? [18:49:21 CEST] <c_14> subtitle codec [18:49:38 CEST] <kyleogrg> ffmpeg can extract dvd subs? [18:52:20 CEST] <__jack__> can't it ? [18:52:40 CEST] <kyleogrg> okay, these were my settings for dvd-to-x265: placebo, crf 20, detelecine. output mkv size was 68% of dvd size. [18:53:10 CEST] <kyleogrg> __jack__: oh, i dunno. i actually never tried [18:53:59 CEST] <kyleogrg> that 68% size compression seems far too high. i wonder how much it will be reduced with default settings [18:55:35 CEST] <kyleogrg> say, at youtube settings [18:56:26 CEST] <kyleogrg> well, i guess youtube doesn't use x265. but at youtube *quality* settings [18:57:12 CEST] <c_14> Youtube quality is pretty terrible [18:57:13 CEST] <relaxed> maybe you needed to deinterlace? what's the output's framerate? [18:59:13 CEST] <kyleogrg> relaxed: I detelecined, so the dvd was 30i and the output is 23.976p [19:07:30 CEST] <sfan5> kyleogrg: how long does an encode with placebo preset take? [19:07:47 CEST] <kyleogrg> sfan5: incredibly long [19:07:54 CEST] <sfan5> how many days? [19:08:17 CEST] <kyleogrg> as i said earlier, it took 3 computers 3 days to encode a 3-hour dvd [19:08:45 CEST] <sfan5> sorry, didn't read all of the stuff [19:11:33 CEST] <kyleogrg> no it's ok [19:11:55 CEST] <kyleogrg> i wonder if it will become faster in the future [19:12:24 CEST] <__jack__> placebo is known to be deadly [19:12:47 CEST] <__jack__> very bad "computing power" vs "quality/bitrate gain" [19:16:31 CEST] <relaxed> I would stick with veryslow [19:17:00 CEST] <kyleogrg> __jack__: yeah. somebody on this channel recommended placebo for x265 [19:17:16 CEST] <kyleogrg> that's probably just an opinion [19:17:24 CEST] <c_14> I don't think I've ever heard anybody recommend placebo. [19:17:36 CEST] <kyleogrg> but he thought that it wasn't worth using over x264 unless placebo was used [19:17:44 CEST] <Mavrik> Yeah, whoever recommended placebo was on drugs [19:17:50 CEST] <Mavrik> It's named PLACEBO for a reason :P [19:18:11 CEST] <kyleogrg> yeah, haha [19:18:23 CEST] <kyleogrg> i wonder how much faster veryslow would be [20:15:50 CEST] <kyleogrg> hey [20:16:09 CEST] <kyleogrg> I know that with x264 you can target an output file size with two-pass mode. [20:16:46 CEST] <kyleogrg> I'd like to encode a large batch of videos and target a batch size. [20:16:52 CEST] <kyleogrg> How?? [20:17:41 CEST] <c_14> two_pass_bitrate_per_file = (batch_size / num_videos) [20:18:12 CEST] <kyleogrg> yeah, but the shorter videos will end up being higher quality than the longer videos [20:18:22 CEST] <kyleogrg> the video durations vary quite a bit [20:19:10 CEST] <c_14> crf with maximum bitrate = (batch-size / num_videos) [20:19:34 CEST] <kyleogrg> hmmm [20:19:37 CEST] <c_14> Though, if you want to reach the batch size, you'll have to keep a running count for what to use as the video maxrate [20:19:51 CEST] <c_14> Otherwise you might undershoot due to the short videos [20:21:17 CEST] <kyleogrg> What about: two_pass_bitrate_per_file = (batch_size / total_minutes_of_all_videos) * minutes_of_this_video [20:21:53 CEST] <c_14> It would have to be seconds [20:21:59 CEST] <c_14> but that could work [20:22:06 CEST] <kyleogrg> yeah [20:22:15 CEST] <BtbN> you could concat all the input videos, and later split them without re-encode. [20:22:33 CEST] <kyleogrg> c_14: how could i get the total seconds? [20:22:38 CEST] <kyleogrg> tbN: [20:22:40 CEST] <c_14> You can only split on keyframes though [20:22:51 CEST] <kyleogrg> BtbN: that would be a very very very long video [20:23:09 CEST] <c_14> ffprobe all the input files and grab the duration (and hope that the duration is accurate) [20:23:12 CEST] <BtbN> But you'd get the exact size you want. [20:23:40 CEST] <BtbN> You could also put some index file next to it, so you actualy have only that one huge video. That depends on what you want to do though. [20:23:42 CEST] <kyleogrg> BtbN: i wouldn't have thought of that, but it could work [20:24:01 CEST] <BtbN> And it also depends on all input videos beeing similar enough to just concat them. [20:24:05 CEST] <kyleogrg> c_14: is there a way to get the exact duration? [20:24:29 CEST] <kyleogrg> BtbN: yes, that's true [20:24:31 CEST] <Raptors> durandal_1707, is there a way to force keyframe interval with -vcodec copy? [20:24:40 CEST] <c_14> ffmpeg -i video -f null /dev/null and then check the printed duration at the end; ffprobe -count_frames might be able to do something as well [20:24:47 CEST] <c_14> Raptors: no [20:24:54 CEST] <Raptors> :( [20:24:58 CEST] <BtbN> Raptors, how exactly do you intend to make new keyframes appear without re-encoding? [20:25:09 CEST] <kyleogrg> c_14: hmm, i wonder if count frames is more accurate [20:25:23 CEST] <Raptors> BtbN, can you re-encode with the same settings as the source file? [20:25:31 CEST] <Raptors> is there a setting for that? [20:25:34 CEST] <BtbN> No. [20:25:39 CEST] <Raptors> :( [20:25:43 CEST] <BtbN> And there is no way to do lossless re-encode. [20:25:46 CEST] <c_14> kyleogrg: well, count_frames by itself won't help. Because the frames don't have to have a constant duration. You'd have to combine it with something else. [20:25:49 CEST] <BtbN> Unless you actualy do encode to a lossless format. [20:25:53 CEST] <Raptors> well I don't really mean lossless [20:26:17 CEST] <Raptors> I mean use the same bitrate, codec and whatnot but force keyframes [20:26:37 CEST] <BtbN> As there is no way to know what settings were used to encode something, that's kind of impossible. [20:26:41 CEST] <kyleogrg> c_14: so i can't just do frame_count / frame_rate? [20:27:04 CEST] <Raptors> Couldn't you look at the settings of the file? [20:27:07 CEST] <c_14> kyleogrg: only if you are 100% sure the input is entirely cfr [20:27:13 CEST] <Raptors> err [20:27:15 CEST] <BtbN> There are no settings saved anywhere. [20:27:21 CEST] <Raptors> codec information [20:27:31 CEST] <Raptors> like it shows on vlc [20:27:42 CEST] <BtbN> It's not possible to get the encoding parameters from that. [20:27:53 CEST] <Raptors> alright. Thanks for the info [20:27:57 CEST] <BtbN> Could be vbr, could be cqp, could be min/max cp, crf with maxrate, ... [20:28:05 CEST] <kyleogrg> c_14: hmm, it may be in my case. the input videos are dv-avi [20:29:22 CEST] <kyleogrg> I assume that DV AVI is cfr [20:30:12 CEST] <kyleogrg> but i'm confused. isn't there some way to get the precise duration? when i open an .mp4 in VLC, it says the duration [20:30:31 CEST] <c_14> Which may or may not actually be accurate. [20:30:58 CEST] <c_14> Depending on various things. [20:31:04 CEST] <kyleogrg> ok [20:31:32 CEST] <c_14> You can use it. It should be accurate enough most of the time. It'll just sometimes not be accurate. And that'll break things. [20:31:46 CEST] <kyleogrg> but whether or not the duration is accurate, the video *has* a certain length, right? i mean, it has a certain number of frames which will play [20:32:07 CEST] <c_14> sure [20:32:18 CEST] <c_14> The sum of all the durations of each frame. [20:32:23 CEST] <kyleogrg> c_14: sure... and it's probably close enough for my purposes, i'm thinking [20:32:58 CEST] <kyleogrg> ahh... and to get that, you'd need to (slowly) calculate that [20:33:05 CEST] <kyleogrg> which VLC probably doesn't do [20:33:40 CEST] <c_14> Most containers store a "duration" field. Whether or not it's accurate depends on the muxer, and whether or not it was cut/etc. [20:33:53 CEST] <kyleogrg> ok [20:34:34 CEST] <kyleogrg> i had never thought about that. i thought duration was actual duration, calculated when the file was opened in the player [20:34:56 CEST] <kyleogrg> not just part of the metadata. interesting [22:43:25 CEST] <kyleogrg> for x264, why is encoding 30i to 30p more efficient than 30i to 30i? that is, why is deinterlacing more effecient than making an interlaced x264 file? [22:56:20 CEST] <kepstin-laptop> kyleogrg, because interlaced content is more complex for the video encoder to deal with. [22:58:29 CEST] <kyleogrg> hmm, but isn't 30i fewer fields, or less visual data, than 30p? [22:58:55 CEST] <kyleogrg> in a sense, isn't 30p twice the amount of data? [22:58:57 CEST] <kepstin-laptop> here's the catch - it's actually 60i, not 30i [22:58:57 CEST] <kyleogrg> if that makes sense [22:59:08 CEST] <kepstin-laptop> there's more temporal data, less spatial data [22:59:18 CEST] <kepstin-laptop> and the spatial data has gaps in it [22:59:41 CEST] <kyleogrg> ah [23:00:00 CEST] <kyleogrg> then what about going from 60i to 60p? [23:00:36 CEST] <kyleogrg> is that a good idea? or would you do 60i to 30p [23:01:10 CEST] <kepstin-laptop> e.g. with yadif=1 ? for some sources that can make sense, where there's a lot of motion that you'd like to preserve [23:01:58 CEST] <kyleogrg> uhhuh [23:02:05 CEST] <kepstin-laptop> it'll probably have lower storage efficiency than 60i, but it really depends a lot on the video content. [23:02:35 CEST] <kyleogrg> you mean 60i x264 would be more efficient than 60p x264? [23:02:42 CEST] <kepstin-laptop> and the quality of the deinterlacer used [23:02:48 CEST] <kepstin-laptop> it depends, maybe, maybe not [23:02:57 CEST] <kyleogrg> interesting [23:03:05 CEST] <kepstin-laptop> you'd have to try it on your video to see [23:03:18 CEST] <kyleogrg> they would generally be played in vlc, which has good (I think) deinterlacers [23:04:17 CEST] <kepstin-laptop> storing video interlaced might be good if you're trying to preserve video data as much as possible, and expect later deinterlacers to get better [23:04:30 CEST] <kepstin-laptop> but if you're doing that, you should use -c copy rather than reencode the video :) [23:05:00 CEST] <kyleogrg> yeah [23:05:12 CEST] <kyleogrg> but then why even copy? i already have the source [23:07:50 CEST] <kepstin-laptop> exactly. [23:08:43 CEST] <kepstin-laptop> the only reason you have to do anything reencoding your video is if either you want to deinterlace it, or you're nearly out of space and are critically short on funds to buy a new hard drive [23:14:03 CEST] <kyleogrg> i'm trying to think of a case where encoding to 60p is more efficient than 60i [23:15:51 CEST] <lordkrondor> i've tested mcdeint to take 1080i59.94 to 1080p59.94 & 1080i50 to 1080p50 [23:15:54 CEST] <lordkrondor> looks pretty decent [23:16:14 CEST] <kepstin-laptop> lordkrondor, using it in combination with yadif=1? [23:16:51 CEST] <lordkrondor> you have to, ya so before mcdeint you do yadif=3:1 for bff or sd, or yadif=3:0 for HD or tff [23:17:17 CEST] <lordkrondor> then do mcdeint=1:0:10 for tff and mcdeint=1:1:10 for bff I think [23:17:23 CEST] <kepstin-laptop> lordkrondor, how did the yadif+mcdeint compare to yadif alone? [23:17:36 CEST] <lordkrondor> much better, but very slow to process [23:17:40 CEST] <lordkrondor> 5fps for HD [23:18:02 CEST] <lordkrondor> makes a difference for things that have sharp lines like lasers [23:18:05 CEST] <kepstin-laptop> hmm, last time I tried, I didn't really see much visible improvement. I should poke at it again. [23:18:22 CEST] <kepstin-laptop> yeah, yadif has issues with some diagonal sharp edges [23:18:35 CEST] <kyleogrg> well, wouldn't 60p be twice as many fields, and so more data, as 60i? [23:18:53 CEST] <lordkrondor> to be honest, with x264, its not that much more [23:18:59 CEST] <kyleogrg> is it just doubling the fields to make it 60p? [23:19:12 CEST] <lordkrondor> its doing motion compensation to create a new frame from each field [23:19:12 CEST] <kepstin-laptop> kyleogrg, yes, but the advantage is that the data interpolated by the deinterlacer can be used in predictions for the next frame. [23:19:14 CEST] <lordkrondor> but its looks amazing [23:19:39 CEST] <kepstin-laptop> as opposed to encoding the interlaced stuff directly, where the encoder has to just work with missing data. [23:20:33 CEST] <kyleogrg> but in theory, to have a smaller output video, i could encode 60i to 60i, and then use a good deinterlacer when viewing? [23:21:01 CEST] <kepstin-laptop> kyleogrg, I think it really depends on what's in your video. you'd have to try and see. [23:21:04 CEST] <lordkrondor> good luck getting mcdeint to filter in realtime [23:21:05 CEST] <lordkrondor> ;) [23:21:29 CEST] <kyleogrg> kepstin-laptop: yeah, i guess i'll have to experiment [23:22:03 CEST] <kepstin-laptop> e.g. if a section video is completely static, then x264 actually will encode the interlaced video as progressive. [23:22:04 CEST] <kyleogrg> lordkrondor: so the "ideal" deinterlacing solution is too slow for realtime, hence should be applied during encoding? [23:22:32 CEST] <lordkrondor> from my experience in my de-interlace testing, yes. i'd test it out both ways and see for yourself [23:22:42 CEST] <lordkrondor> and that's purely using mcdeint to get the best results [23:23:09 CEST] <kepstin-laptop> of course, computers keep getting faster, and some of the deinterlacing filters using graphics card processing with motion compensation are quite good [23:23:26 CEST] <lordkrondor> ya if someone enhanced mcdeint to use a gpu, I bet that would be pretty neat [23:25:00 CEST] <kyleogrg> what do you think is the best deinterlacer? [23:25:15 CEST] <lordkrondor> Snell Alchemist OD ;) [23:25:24 CEST] <lordkrondor> but thats 10k pounds for a license [23:25:53 CEST] <kyleogrg> wha? [23:25:57 CEST] <lordkrondor> commercial software [23:26:00 CEST] <kyleogrg> yeah [23:26:08 CEST] <kyleogrg> how about the best free one [23:26:08 CEST] <lordkrondor> I downloaded a test license to see how it fared [23:26:13 CEST] <kyleogrg> and? [23:26:24 CEST] <lordkrondor> it was really nice hah [23:26:31 CEST] <lordkrondor> but in ffmpeg, I like mcdeint best [23:26:45 CEST] <lordkrondor> yadif if you want speed [23:26:57 CEST] <kyleogrg> you mean yadif+mcdeint is best? [23:27:16 CEST] <lordkrondor> well ot use mcdeint, you have to use yadif to pass each field as its own frame [23:27:27 CEST] <kepstin-laptop> I recall that back in the mencoder days you could use tfields+mcdeint instead, but the yadif one worked better. [23:27:30 CEST] <lordkrondor> yadif on its own is pretty nice [23:28:36 CEST] <kyleogrg> how could alchemist od be so good? [23:28:47 CEST] <kyleogrg> i mean, is deinterlacing that complicated? [23:29:49 CEST] <lordkrondor> I think so.. uses alot of motion estimation to create missing video to take one field to make a frame, or interpolate the two fields into a frame and accomodate for the difference in the case of extreme motion [23:29:58 CEST] <kepstin-laptop> kyleogrg, imagine you had a painting someone drew, and someone ruined it by taking a brush and drawing black stripes across it. your job is to figure out what used to be under the stripes and repaint it. [23:29:59 CEST] <kepstin-laptop> yes, it's complicated :) [23:30:37 CEST] <kyleogrg> yeah [23:30:38 CEST] <kyleogrg> haha [23:30:51 CEST] <kyleogrg> it has to invent, or infer, the missing lines [23:31:51 CEST] <kepstin-laptop> yep. and it has some advantages, it knows what is in those missing lines on the previous and next frames - but that doesn't help if there's motion, unless you know what's moving where... [23:32:36 CEST] <kepstin-laptop> the easiest deinterlacing job is when nothing in the frame is moving, then you can just re-use the missing lines from a previous frame and everything will look perfect [23:32:43 CEST] <kyleogrg> yes [23:32:47 CEST] <kepstin-laptop> but movement is hard :) [23:33:00 CEST] <kyleogrg> yes, i can imagine [23:33:07 CEST] <kyleogrg> is ffmpeg used for commercial content? [23:33:29 CEST] <kyleogrg> let's say there's an indie filmmaker who wants to encode his movie and sell dvds [23:33:41 CEST] <kepstin-laptop> kyleogrg, I imagine it is used in a number of places for commercial content; but i suspect less for tv broadcast. [23:34:01 CEST] <kyleogrg> ok, but it's permitted? [23:34:10 CEST] <kepstin-laptop> well, yes... [23:35:31 CEST] <kyleogrg> what about the non-free aspects of ffmpeg? [23:35:32 CEST] <kepstin-laptop> it's up to you and your lawyer to handle doing any patent licensing that may be appropriate in your jurisdiction, but the software itself has no restrictions against using it for commercial video. [23:35:36 CEST] <kyleogrg> i guess they're... non-free? [23:36:07 CEST] <kepstin-laptop> the "non-free" option in ffmpeg refers to enabling a combination of things that results in a ffmpeg that you can't legally distribute [23:36:23 CEST] <kepstin-laptop> nothing stopping you from using it however you like tho, as long as you don't distribute it. [23:36:47 CEST] <kyleogrg> could i encode using libfdk_aac and sell that video? [23:38:00 CEST] <kepstin-laptop> as far as the ffmpeg devs are concerned, yes [23:38:16 CEST] <lordkrondor> from what i've been told in regards to mpeg-la stuff (x264) - if you sell or offer the content as part of a subscription, I think you need to work out a license agreement. [23:38:33 CEST] <kyleogrg> yeah [23:38:59 CEST] <kepstin-laptop> but that would be just as true if you were using e.g. the built-in aac encoder rather than libfdk_aac. [23:40:16 CEST] <kyleogrg> right [23:43:20 CEST] <kyleogrg> so ffmpeg employs reverse engineering for most codecs [23:43:28 CEST] <kyleogrg> does this cause legal problems? [23:45:51 CEST] <kepstin-laptop> ask a lawyer. that said, the reverse engineering mostly applies to somewhat uncommon codecs that don't have standards. [23:46:44 CEST] <kyleogrg> ok [23:48:05 CEST] <lordkrondor> or prores which apple won't license to anyone they don't feel like [00:00:00 CEST] --- Fri Apr 24 2015

1 0

ffmpeg-devel.log.20150422
by burek 23 Apr '15

23 Apr '15

[01:19:12 CEST] <cone-874> ffmpeg 03Andreas Cadhalpun 07master:ca9849eecdf7: aacpsy: correct calculation of minath in psy_3gpp_init [01:55:44 CEST] <cone-874> ffmpeg 03Vignesh Venkatasubramanian 07master:4f287a3c5007: webmdashenc: Add minimumUpdatePeriod [03:46:01 CEST] <cone-874> ffmpeg 03James Almer 07master:ba625dd8a12b: avcodec: use av_mod_uintp2() where useful [03:53:31 CEST] <Prelude2004c> up everyone.. good evening.. having trouble passing a ffmpeg -i < input > -vcopy and -acopy -f mpegts udp://destination:port ... < --- this causes artifacts i guess because some UDP traffic is missed on the network. Over a distance i guess this is not the best way to pull data. anyone know a better way without transcoding it at source ? [03:53:32 CEST] <Prelude2004c> maybe somehow with little horsepower i can push it via TCP or something that way if a packet doesn't arrive it gets retransmitted i want to make sure our stream is clean so i can encode it properly any ideas ? [04:40:23 CEST] <Timothy_Gu> Prelude2004c: isnt UDP not designed for perfect quality? [05:39:17 CEST] <Timothy_Gu> Daemon404: since when did your ICL FATE clients die? [06:21:44 CEST] <Timothy_Gu> time xz -dc report.xz >/dev/null 6.711s ||||| time xz -dc report.xz | wc 57.531s [06:46:52 CEST] <jamrial> nevcairiel: latest mingw-w64 version (i think still git head, probably not in any formal release) implemented the dxva hevc defines [06:47:22 CEST] <jamrial> and it broke compilation of your ffmpeg fork for lavfilters where you hardcode the compat hevc header :p [06:50:17 CEST] <jamrial> should be easy to fix, just check for HAVE_DXVA_PICPARAMS_HEVC before including the compat header [10:09:29 CEST] <haasn> Out of curiosity: How quickly do posts to FFmpeg-devel get moderated? [10:09:41 CEST] <haasn> Or moderator approval, rather [10:10:00 CEST] <Kumi1> It's Non-Moderated [10:10:12 CEST] <Kumi1> Unmoderated [10:10:18 CEST] <Kumi1> https://www.ffmpeg.org/contact.html#IRCChannels [10:11:33 CEST] <haasn> It's non-moderated -> Your message to ffmpeg-devel awaits moderator approval [10:32:34 CEST] <wm4> haasn: because you're not subscribed [10:36:51 CEST] <haasn> I know this, but I don't want to subscribe just to post a message [10:36:58 CEST] <haasn> That seems counter-intuitive to me [10:37:05 CEST] <nevcairiel> then you'll have to wait until a moderator approves it [10:37:06 CEST] <haasn> What does sending messages have to do with receiving messages? [10:37:19 CEST] <haasn> Yes, that's what I'm doing [10:37:53 CEST] <nevcairiel> in general, everyone who tries to submit patches or the like should really submit, because you will otherwise not get the responses to your mail [10:38:03 CEST] <nevcairiel> s/submit/subscribe/ [10:42:49 CEST] <haasn> I think the API is bad here. Subscription should not be an everything-or-nothing thing. It should be possible to subscribe to replies to your own posts only. In fact, I think this should be the default behavior [10:43:37 CEST] <haasn> Every single major forum software supports this kind of notification strategy. I don't know why whatever ML software you're using is incapable of it [10:43:39 CEST] <haasn> Oh well [10:43:40 CEST] <wm4> actually, maybe it's quite good to force a certain level of involvement in an all or nothing way [10:44:57 CEST] <haasn> Then I choose nothing [10:45:42 CEST] <haasn> Same deal with most bug trackers. If people make it hard to post bugs, people don't want to post bugs [10:46:22 CEST] <haasn> Lost count of how many bug reports I've simply never submitted because they wanted me to sign up for some stupid one-time account just to post a simple bug; meanwhile eg. on Github it's a matter of seconds to hit New Issue [10:46:26 CEST] <wm4> on the other low quality bug reports cause negative productivity [10:46:32 CEST] <haasn> And I also get e-mail replies automatically [10:46:32 CEST] <wm4> *hand [10:46:33 CEST] <haasn> To my own bug reports, only [10:46:53 CEST] <haasn> Email notifications for replies* [10:46:54 CEST] <wm4> github requires you to rrgister too [10:47:14 CEST] <haasn> Sure, but I don't have to register for every single project [10:47:16 CEST] <haasn> Just once for the whole website [10:47:43 CEST] <haasn> True about low quality bug reports I gues [10:48:17 CEST] <haasn> But at the end of the day it's just one type of specific filtering heuristic, I'm not sure if it works that well in practice [11:59:35 CEST] <cone-444> ffmpeg 03Vignesh Venkatasubramanian 07master:f82ce6aa882b: webmdashenc: parameter'ize minimumUpdatePeriod [12:11:05 CEST] <cone-444> ffmpeg 03Andreas Cadhalpun 07master:afc7748d1f6a: alsdec: check sample pointer range in revert_channel_correlation [12:33:04 CEST] <BBB> hm vp9 build time is also getting our of hand [12:33:12 CEST] <BBB> maybe Ill split (finally!) in multiple files [12:35:21 CEST] <nevcairiel> speaking of vp9, do you have plans to support high bitdepth/chroma extensions? users asked me about it :( [12:37:22 CEST] <kierank> haasn: you can subscribe and not receive emails [12:37:32 CEST] <kierank> and just ask to be cc'd in [12:40:20 CEST] <wm4> lol at the libvpx bug that made it into the "standard" [12:42:59 CEST] <kierank> wm4: happens in h264 too [12:43:04 CEST] <kierank> but in SVC [12:45:26 CEST] <wm4> pretty awesome [12:55:39 CEST] <kierank> wm4: http://www.itu.int/rec/T-REC-H.Imp264-201007-S/en [14:06:42 CEST] <Compn> haasn : do you need me to approve some mail ? [14:07:04 CEST] Action: Compn guessing someone already approved it [14:07:06 CEST] Action: Compn checks [14:07:53 CEST] <Compn> ok i see it [14:08:04 CEST] <Compn> haasn : also i'll do you a favor and auto-accept any mails from that addy [14:08:05 CEST] <Compn> Add nand@.... to one of these sender filters: Accepts [14:08:15 CEST] <haasn> Heh, neat; thanks [14:08:25 CEST] <haasn> Now I don't even have to go through the process of complaining about hating mailing lists and subscription :p [14:08:37 CEST] <Compn> right :) [14:09:13 CEST] <Compn> mail accepted, should already show up on the list now [14:10:37 CEST] <Compn> you replied to a post but it does not have re: in subject :P [14:12:05 CEST] <Compn> oh no nevermind i'm blind [14:12:27 CEST] <haasn> I just copied the fields from the mailto: link generated by that page [14:12:35 CEST] <haasn> My manually URL decoding it. And copy/pasting the headers into my email client. [14:12:43 CEST] <haasn> Technology sure is wonderful [14:22:53 CEST] <iive> are you writing your emails using telnet client? [14:24:07 CEST] <av500> isnt everybody? [14:25:25 CEST] <Compn> we should put a note on the contact page that we can do this so those people who dont like registering dont have to register ;P [14:26:09 CEST] <Compn> because haasn isnt the first person to have this anti-registration opinion, and will not be the last. hey i dont like registering either :P [14:31:11 CEST] <haasn> iive: I'm using a relatively young e-mail client, I've already submitted a feature request for mailto support [14:31:44 CEST] <cone-444> ffmpeg 03wm4 07master:7dd8bf53bdb5: avformat: add common mechanism for skipping samples at the start of file [14:31:45 CEST] <cone-444> ffmpeg 03wm4 07master:066b92e91d67: avformat/mp3dec: use the common mechanism for skipping samples [14:41:24 CEST] <cone-444> ffmpeg 03wm4 07master:c3a73666ad1e: avformat/mp3dec: allow enabling generic seek mode [15:28:56 CEST] <BBB> nevcairiel: yes [15:29:28 CEST] <BBB> nevcairiel: if users have specific requests, they are free to contact me btw, Im cont(r)actable [15:29:39 CEST] <Daemon404> BBB, surprising [15:29:45 CEST] <Daemon404> many us companies have anti-moonlighting clauses [15:29:48 CEST] <Daemon404> US* [15:29:52 CEST] <BBB> I quit [15:30:05 CEST] <BBB> I work for myself, Im just having random fun right now [15:30:55 CEST] <Daemon404> o [15:31:10 CEST] <Daemon404> thats fairly risky, given where you live, i would htink [15:32:48 CEST] <BBB> ? [15:33:18 CEST] <Daemon404> you dont have a guaranteed source of income [15:33:22 CEST] <Daemon404> if contracting [15:34:41 CEST] <BBB> well kinda late for that now I guess [15:34:43 CEST] <BBB> I already quit [15:34:45 CEST] <BBB> so... [15:53:00 CEST] <vibr> kierank, the deadline's really close now, but i'd still like to finish the qualification task for outreachy [15:54:36 CEST] <vibr> kierank, from looking at fate i understood that all test code is in fate-run.sh [15:54:53 CEST] <vibr> there's no test code anywhere else, is that correct? [15:55:26 CEST] <kierank> vibr: erm [15:55:51 CEST] <kierank> deadline? [15:56:09 CEST] <vibr> the deadline for finishing the qualification task [15:56:16 CEST] <vibr> i thought it's this friday [15:56:37 CEST] <kierank> where does it say that? [15:56:57 CEST] <vibr> michaelni said 11 days ago that i had 1-2 weeks left [15:57:08 CEST] <vibr> that would mean 3 days to go now [15:57:47 CEST] <michaelni> 1-2 weeks meant i did not know exactly when the deadline is [15:58:17 CEST] <michaelni> if you pass qualification we can still try to get a 2nd slot of course but we are technically too late [15:59:09 CEST] <vibr> i see [15:59:27 CEST] <michaelni> rather we WILL try not just can [16:00:10 CEST] <vibr> that would be great [16:00:44 CEST] <vibr> the outreachy website says the selections decision are posted next monday [16:01:22 CEST] <vibr> that sounded like a hard deadline to me [16:01:52 CEST] <vibr> anyway, may i ask some questions then, kierank? [16:01:56 CEST] <kierank> yes [16:02:02 CEST] <kierank> of course [16:02:35 CEST] <vibr> is all test code inside fate-run.sh? [16:03:21 CEST] <vibr> i understood that fate-run.sh calls ffmpeg to encode and decode <file> and then compares the output to the original <file> [16:04:34 CEST] <kierank> yes [16:04:34 CEST] <wm4> fate-run.sh can call various things [16:04:39 CEST] <wm4> not only ffmpeg [16:04:49 CEST] <kierank> it is one of the tthings as wm4 says [16:05:42 CEST] <wm4> one of the arguments passed to fate-run.sh is the function that is run [16:05:54 CEST] <wm4> like framecrc() [16:06:09 CEST] <wm4> I don't completely understand the magic that calls fate-run-sh in the first place though [16:06:25 CEST] <wm4> lots of makefile magic... [16:06:46 CEST] <vibr> yes, it seems to be quite involved [16:07:18 CEST] <vibr> can fate-run call API functions or even local functions? [16:08:06 CEST] <kierank> no [16:08:12 CEST] <kierank> it's a makefile/shell-script [16:08:57 CEST] <vibr> that's why i thought it calls ffmpeg only [16:09:19 CEST] <vibr> i can't find the definition of framecrc right now [16:10:23 CEST] <wm4> there's a shell function in fate-run.sh, and there's a muxer in libavformat, which do you mean? [16:11:36 CEST] <vibr> none ;) [16:11:47 CEST] <vibr> so that's what you meant ;) [16:14:11 CEST] <cone-444> ffmpeg 03wm4 07master:58fade2c6848: avformat/mp3dec: make generic index mode the default [16:15:07 CEST] <vibr> so, kieranc, for the granularity of the tests: first i thought of writing a unit test for one of the functions in flacdec.c (because you pointed me to flac) [16:15:42 CEST] <vibr> but i think you don't want that granularity, you want tests on the level of the API? [16:15:58 CEST] <kierank> correct [16:16:11 CEST] <kierank> it's worth saying a test has already been written for flac [16:16:22 CEST] <vibr> where's that test? [16:16:33 CEST] <kierank> libavcodec/api-test-flac iirc [16:17:33 CEST] <vibr> it's new then? [16:18:02 CEST] <michaelni> it would be best if each applicant writes a different qualification task so a diferent test would be better and more usefull than a 2nd flac test [16:19:14 CEST] <vibr> yes, i think so [16:19:51 CEST] <vibr> it says Copyright (c) 2001 Fabrice Bellard and Copyright (c) 2015 Ludmila Glinskih [16:20:11 CEST] <vibr> but it wasn't in my source code tree when i cloned it two weeks ago [16:21:29 CEST] <gavinatkinson> michaelni: Around? [16:24:38 CEST] <vibr> hm, so the API regression testing is assigned already? [16:24:40 CEST] <reynaldo> gavinatkinson: hello [16:24:49 CEST] <reynaldo> gavinatkinson: you from FreeBSD isnt it ? [16:25:27 CEST] <reynaldo> Im ont of the peeps admining GSoC for the team [16:25:32 CEST] <reynaldo> ont/one [16:25:41 CEST] <reynaldo> will follow up privately if you dont mind [16:27:45 CEST] <gavinatkinson> reynaldo: Ah, cool. [16:29:09 CEST] <kierank> vibr: as far as I know there's no reason why two students couldn't work on the same task [16:29:46 CEST] <vibr> ok [16:29:57 CEST] <vibr> but what about the qualification task, then? [16:32:37 CEST] <wm4> so we need a new one? there's enough API to test [16:32:55 CEST] <kierank> h264 or another bitexact codec is easiest [16:35:10 CEST] <vibr> But Camila Souto already wrote a test for h264? [16:35:23 CEST] <kierank> she did? [16:35:42 CEST] <vibr> it says so on the link posted above? [16:35:43 CEST] <kierank> I see nothing on the ml [16:35:53 CEST] <vibr> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2015-Qualis?version=52 [16:35:57 CEST] <kierank> vibr: it is what she *intended* to do [16:36:02 CEST] <kierank> there has been no submission [16:36:19 CEST] <kierank> note how the completed box is not ticked [16:36:29 CEST] <vibr> oh, i see [16:41:31 CEST] <vibr> do you want me to look at api-flac-test.c or not? The qualification task is easier that way with a "template" which can be adapted [16:42:44 CEST] <kierank> you can if you want or you can look at the examples [16:42:50 CEST] <kierank> api-flac-test is based off the examples [16:42:51 CEST] <vibr> ok [16:43:05 CEST] <kierank> there's a difference though in that you won't be able to do the same encode -> decode test with h264 [16:43:18 CEST] <kierank> normal h264 is bitexact but not lossless [16:46:22 CEST] <vibr> do i need to look at the standard for h264 then? [16:47:08 CEST] <vibr> what's the definition of bitexact or where can i look it up? [16:48:23 CEST] <kierank> no you don't need to look at the h264 standard [16:48:49 CEST] <kierank> the definition of bitexact is that the implementation requires a bit for bit exact decode of a video [16:48:54 CEST] <kierank> for other formats such as mpeg-2 this is not required [16:50:29 CEST] <wm4> lossless means the output of the decoder is exactly the same as what you've put into the encoder [16:50:40 CEST] <vibr> yes [16:50:47 CEST] <wm4> bitexact means the output of the decoder can be different, but every decoder will output the same [16:51:19 CEST] <wm4> and for something that is neither lossless nor bitexact, every decoder could output something slightly different from each other [16:51:24 CEST] <wm4> (obviously bad for testing) [16:52:16 CEST] <vibr> but there's only one decoder for h264, so i can't compare the output of differenct decoders? [16:53:15 CEST] <kierank> vibr: correct, but there are crc's already in fate for various test h264 clips [16:53:23 CEST] <kierank> so if they change then something has broke [16:53:47 CEST] <vibr> ok [16:54:17 CEST] <wm4> a decoder that's not bitexact could vary from platform to platform too [16:55:02 CEST] <wm4> some decoders in ffmpeg can be made bitexact by setting a flag (skips platform specific optimizations that change the output, I think) [16:55:12 CEST] <cone-444> ffmpeg 03Andreas Cadhalpun 07master:35e855d5b695: dss_sp: use lowercase codec name without whitespace [16:57:42 CEST] <iive> mpeg1/2 are not bitexact because they allow different precision for (i)dct, [16:57:50 CEST] <BBB> vibr: in practice, such differences can happen when we implement things like idcts (for video) differently per platform for performance reasons. it also can happen for float (usually audio) based decoders. [16:58:01 CEST] <BBB> mpeg1/2 are indeed example of codecs where the idct isnt specified [16:58:22 CEST] <BBB> prores is a more modern example where we dont know if the idct is specified and so it varies per platform [16:58:27 CEST] <iive> because of this they can have a small number of P-frames and need frequent I-frames. [16:58:37 CEST] <BBB> bitexact works around that so you get the same output on each platform [16:59:13 CEST] <kierank> we'll find out soon about prores idct [16:59:15 CEST] <iive> mpeg4-2 asp defines stricter parameters for (i)dct, this allows increasing the refresh interval. [16:59:16 CEST] <kierank> it's getting standardised [16:59:25 CEST] <kierank> https://kws.smpte.org/kws/public/projects/project/details?project_id=278 [16:59:30 CEST] <BBB> oh cool [16:59:34 CEST] <kierank> soon by smpte standards is about 5 years [16:59:38 CEST] <Daemon404> into the smpte dumping ground [16:59:44 CEST] <BBB> :) [16:59:59 CEST] <Daemon404> i still wanna do vc-5. [17:00:01 CEST] <Daemon404> but im not paying $300. [17:00:02 CEST] <kierank> I doubt the spec will be any good [17:00:07 CEST] <kierank> Daemon404: you missed the guy who was working on it [17:00:10 CEST] <kierank> he said the spec was crap [17:00:14 CEST] <Daemon404> rofl [17:00:25 CEST] <kierank> it was good for lossy but useless for lossless [17:00:38 CEST] <Daemon404> what was it lacking? [17:00:44 CEST] <Daemon404> precise dwt? [17:00:53 CEST] <kierank> apparently lossless was just a footnote [17:01:59 CEST] <vibr> kierank, the test h264 clips are in the fate-suite/h264* dirs, where are the crcs? [17:02:48 CEST] <kierank> http://git.videolan.org/?p=ffmpeg.git;a=tree;f=tests/ref/fate;h=3c25ec16d76… [17:03:19 CEST] <vibr> thanks! [17:30:39 CEST] <wm4> is is there a reason why the test programs are part of the libavcodec/libavformat/etc. directories? [17:31:35 CEST] <kierank> because for some reason there was a rush to commit the code [17:31:49 CEST] <kierank> I have asked lglinskih to work on moving them to the correct place [17:31:53 CEST] <Daemon404> to meet deadlines apparently [17:39:38 CEST] <cone-444> ffmpeg 03Andreas Cadhalpun 07master:b3408ae4c64c: mpeg4videodec: only allow a positive length [17:41:47 CEST] <wm4> right, the deadline was some hours away or something [17:42:00 CEST] <wm4> anyway, there are older test programs that do this [17:42:40 CEST] <nevcairiel> why does the deadline require that its commited, do they really say "it has to be commited to the main code base" in their requirements? I highly doubt that, as many more serious projects have extremely strict requirements for that [17:45:35 CEST] <BtbN> int diff_r = r - ctx->colorkey_rgba[0]; With r and colorkey_rgba[0] both beeing uint8_t, will the result still be int, so 100-200 will be -100, and not 155? [17:46:23 CEST] <nevcairiel> its likely doing the calc in the types that the vars are in [17:46:44 CEST] <BtbN> I remember there beeing some thing about C where it does all calculations as ints [17:47:20 CEST] <wm4> nevcairiel: true [17:47:37 CEST] <nevcairiel> https://ideone.com/mfBlB7 [17:47:40 CEST] <nevcairiel> this says it works [17:47:41 CEST] Action: nevcairiel shrugs [17:48:25 CEST] <wm4> uint8_t is promoted to int [17:48:26 CEST] <wm4> I think [17:48:27 CEST] <nevcairiel> no guarantees it didnt optimize out my example :p [17:53:28 CEST] <kierank> 4:41 PM <"wm4> right, the deadline was some hours away or something --> the deadline said nothing about committing [17:53:36 CEST] <BtbN> Why is ff_sqrt in libavcodec/mathops.h? [17:54:14 CEST] <kierank> https://lists.libav.org/pipermail/libav-devel/2012-October/037115.html [17:54:15 CEST] <kierank> of course [17:54:19 CEST] <kierank> need to play the libav shuffle [17:54:32 CEST] <lglinskih> wm4: It was the simplest way to integrate it into FATE. At first I wanted to put it in tests/api directory! But it's not easy=/ I still don't understand all makefile-magic [17:55:06 CEST] <BtbN> And can i still use that in a filter? Seeing that even libavutils includes that header. [17:55:10 CEST] <nevcairiel> loading data tables from other shared libraries is somewhat annoying re: portability, so i dont mind moving those things to the place they are actually used [17:57:27 CEST] <kierank> nevcairiel: how come? [17:57:28 CEST] <cone-444> ffmpeg 03Ludmila Glinskih 07master:5adee9c0af74: api-flac-test: Coding style [17:57:29 CEST] <kierank> is it a windows thing? [17:57:45 CEST] <nevcairiel> yes [17:57:59 CEST] <ubitux> http://pastie.org/pastes/10107660/text funny the AES-128 bench& i wonder if gcrypt is correct [17:58:00 CEST] <kierank> ah yes I remember actually [17:58:34 CEST] <kierank> ubitux: aes-ni? [17:58:58 CEST] <Daemon404> i am frankly surprised libav* doesnt manually implement ssl [17:59:20 CEST] <nevcairiel> i'm still refusing to bundle openssl or gnutls or something, i'm still waiting for the native! [17:59:21 CEST] <nevcairiel> :D [17:59:37 CEST] <wm4> Daemon404: did those curl plans for a SSL abstraction/wrapper lib go somewhere? [18:00:05 CEST] <nevcairiel> i should just take some pain killers and write a SChannel implementation [18:00:07 CEST] <Daemon404> wm4, yes [18:00:14 CEST] <Daemon404> they killed it [18:00:16 CEST] <Daemon404> it went to death [18:01:43 CEST] <wm4> sad [18:01:53 CEST] <BtbN> This is kinda strange, why the hell is something basic as ff_sqrt in avcodec... [18:02:27 CEST] <Daemon404> because of ricing [18:02:28 CEST] <BBB> BtbN: no use outside avcodec yet [18:02:29 CEST] <nevcairiel> because it was used there, and only there? [18:02:48 CEST] <BtbN> BBB, well, there is at least one pice of code in libavutils that uses it, which is kinda strange. [18:03:03 CEST] <BBB> then we should move it into avutil [18:03:18 CEST] <Daemon404> the whole reason it was like this is cause of ricing: OMG FUNCTION CALL OVERHEAD [18:03:24 CEST] <Daemon404> and sharing tables between libs is derp [18:03:27 CEST] <BBB> what do I do if a decode to yuv yields identical results but a decode to md5 gives different results between two decoders? [18:03:30 CEST] <BtbN> It's an inline in a header...? [18:03:46 CEST] <Daemon404> BtbN, i seem to rememebr it beign a LUT, i may be wrong [18:03:46 CEST] <BBB> BtbN: sharing tables between libs is derp [18:03:59 CEST] <BBB> see the mess we got in with pixfmtinfo [18:04:10 CEST] <nevcairiel> its a bit weird, fixed_sqrt uses ff_sqrt .. fixed_sqrt is a inline function, which in turn is only ever used from avcodec [18:04:36 CEST] <Daemon404> why do we need our own sqrt btw? [18:04:41 CEST] <BBB> Daemon404: int [18:04:43 CEST] <BBB> not float [18:04:48 CEST] <nevcairiel> but fixed_sqrt is part of the fixed point stuff contributed by the crazy mips people [18:05:00 CEST] <wm4> ac3dec uses it [18:05:23 CEST] <BBB> is there a flag to tell avformat to ignore timestamps? [18:05:30 CEST] <BBB> like, -vsync 0, but also works in muxers [18:05:36 CEST] <wm4> BBB: what context? [18:05:38 CEST] <nevcairiel> littering all our pretty decoders with special conditions for fixed point decoding [18:05:49 CEST] <BBB> [yuv4mpegpipe @ 0x7fdad9849c00] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 6 >= 6 [18:05:49 CEST] <BBB> av_interleaved_write_frame(): Invalid argument [18:05:53 CEST] <BBB> I get that when I use -vsync 0 [18:06:15 CEST] <Daemon404> i dont know what else you expect when passing ts through [18:06:30 CEST] <Daemon404> eitehr you fix timestamps or you pass them through [18:06:40 CEST] <Daemon404> i dont know why there would be a "make up timestamps" option for muxing [18:08:40 CEST] <BBB> I just want to write yuv frames as they come [18:08:45 CEST] <BBB> my yuv file has no timestamps [18:08:52 CEST] <BBB> I dont want it to touch anything [18:08:54 CEST] <BBB> just write it [18:09:37 CEST] <nevcairiel> y4m muxer should probably set the no-timestamps flag, then you are happy [18:11:07 CEST] <nevcairiel> its not using the timestamps anyway [18:12:10 CEST] <Daemon404> y4m has a "framerate" [18:12:24 CEST] <nevcairiel> but not timestamps [18:12:31 CEST] <nevcairiel> so its pointless to complain about them [18:13:41 CEST] <Daemon404> i know [18:14:13 CEST] <nevcairiel> gcc 5.1 was officially released today btw [18:14:26 CEST] <wm4> huh, so I missed 5.0 being released? [18:14:42 CEST] <nevcairiel> they changed their versioning [18:14:54 CEST] <nevcairiel> they are using chrome versioning now, 5, 6, 7, 8 .. etc [18:15:03 CEST] <BtbN> And they break the C++ abi, which is a lot of fun for everyone. [18:15:04 CEST] <nevcairiel> 5.0.1 was pre-release, 5.1 is first stable [18:15:38 CEST] <Daemon404> in practice you shouldnt be relying on c++ ABI [18:15:43 CEST] Action: Daemon404 stares at avisynth [18:15:52 CEST] <nevcairiel> BtbN: thats probably more C++'s fault than GNUs fault [18:16:15 CEST] <BtbN> hm? It's the fault of whoever implements libstdc++, which is made by the gcc guys [18:16:44 CEST] <BtbN> They could have at least bumped the soname [18:16:48 CEST] <BtbN> And keep the old one for compat [18:17:46 CEST] <nevcairiel> this claims that old apps should continue to work, and only things build against new headers use the new ABI https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html [18:18:09 CEST] <nevcairiel> (plus a define to defeat the new ABI) [18:18:16 CEST] <BtbN> Yes, it continues to work as long as absolutely everything is build using the same abi. [18:18:25 CEST] <Daemon404> well... they should have bumped the soname [18:18:29 CEST] <Daemon404> thats kinda what sonames are for [18:18:43 CEST] <BtbN> A single lib or binary using a diffrent abi, and it explodes. [18:18:48 CEST] <Daemon404> it's worth noting that glibc does the exact same thing [18:18:53 CEST] <Daemon404> (and everyone LOVES glibc) [18:19:04 CEST] <BtbN> glibc at least has propper backwards compat. [18:19:44 CEST] <wm4> glibs makes application reference all sort of crazy symbols [18:19:45 CEST] <BtbN> a binard built against an old one will allways continue to work. Even when mixed with binaries using more recent features. [18:20:05 CEST] <wm4> and contributed to the impression that you can't reasonably deploy binaries on Linux [18:20:26 CEST] <BtbN> Not without staticaly linking in the libc at least. [18:21:22 CEST] <wm4> ^ or this impression [18:22:25 CEST] <BtbN> The windows solution of having a ton if diffrent libcs isn't much better though. [18:23:53 CEST] <Daemon404> BtbN, you cant REALLY statically link glibc [18:23:58 CEST] <Daemon404> same sort of issues [18:24:14 CEST] <BtbN> you get at least rid of most symbol crazyness that way [18:24:16 CEST] <Daemon404> and you can link msvcrt statically [18:25:38 CEST] <wm4> the old maintainer of glibc hated static linking [18:25:44 CEST] <wm4> and made it as bad as possible [18:26:50 CEST] <Daemon404> he hated everything [18:27:00 CEST] <Daemon404> he is the definition of asshat [18:27:52 CEST] <BtbN> Wasn't he also the one that purposfully left a /bin/sh shebang in files that were clearly using bash-only features? [18:29:09 CEST] <wm4> BtbN: at least this sounds like something he'd do [18:30:13 CEST] <BtbN> Forced a few distributions that weren't using bash as /bin/sh to patch a bunch of glibc scripts. [18:31:11 CEST] <Daemon404> BtbN, almost as annoying as #!/bin/bash [18:31:18 CEST] <Daemon404> (bash does *not* belong in /bin) [18:31:42 CEST] <BtbN> That's way to established to change it though [18:31:58 CEST] <BBB> you guys need to get a job [18:32:05 CEST] <BBB> like, one where you need to sit down and get work done [18:32:18 CEST] <BBB> seriously, if the most important thing you can do in your life is to debate whether bash belongs in /bin... [18:32:20 CEST] <Daemon404> BtbN, its 5:30pm here. [18:32:23 CEST] <Daemon404> er BBB [18:32:43 CEST] <Daemon404> also you couldnt really sound like more of a douche if you tried ther.e [18:32:48 CEST] <BtbN> An entire new init system was born over the debate where stuff belongs. [18:33:20 CEST] <wm4> systemd got it wrong though [18:33:30 CEST] <wm4> they made /usr/bin the "official" place for no reason [18:33:39 CEST] <wm4> it should have been /bin, because /usr is bullshit [18:34:05 CEST] <Daemon404> my last job actually did care about /usr/bin vs /bin [18:34:13 CEST] <Daemon404> since embedded land may not have /usr mounted at init time. [18:37:33 CEST] <BtbN> systemd solved that by making a mounted /usr a requirement... [18:37:48 CEST] <Daemon404> i dont know of any embedded linux stuff using systemd [18:37:50 CEST] <Daemon404> full stop [18:37:59 CEST] <wm4> there's a phone using systemd [18:38:02 CEST] <wm4> was it jolla [18:38:21 CEST] <Daemon404> ubuntu phone maybe? [18:38:28 CEST] <wm4> whatever lachs0r has [18:38:35 CEST] <Daemon404> jolla [18:38:43 CEST] <Daemon404> the once the MUH FREEDUMS people like [18:38:45 CEST] <wm4> they run systemd [18:39:22 CEST] <BBB> another one thats fun [18:39:44 CEST] <BBB> what if I have a scalable sequence [18:39:48 CEST] <wm4> (it also runs btrfs, which dies when it's out of space... I wonder how that interacts with journald lol) [18:39:59 CEST] <BBB> and for whatever reason, AVCodecContext.width/height is different between two decoders [18:40:07 CEST] <BBB> (on init) [18:40:14 CEST] <BBB> but is identical once the decoding starts [18:40:36 CEST] <BBB> framemd5 wont work now, since muxing/encoding AVCodecContext.width/height is copied upon init [18:40:59 CEST] <BBB> so even if decodes are identical between two decoders, encoding will look different because scaling touched it [18:41:06 CEST] <BBB> how can I tell ffmpeg to not resize? [18:41:28 CEST] <BBB> as in, quite literally, do not touch my frames which you send to the encoder [18:41:42 CEST] <BBB> (where encoder is rawenc and muxer is framemd5) [19:00:04 CEST] <wm4> michaelni: so do you want a separate CBR-mode mp3 seek test? [19:12:20 CEST] <michaelni> wm4, sounds like a good idea [19:13:23 CEST] <wm4> ok, I only need to find out how to pass extra arguments for a seek-test call (to enable CBR-mode seeking) [19:38:36 CEST] <wm4> are the fate-seek-lavf tests dead? [19:39:11 CEST] <cone-444> ffmpeg 03wm4 07master:53ff9a4ec9ce: fate: gapless: remove useless tests [19:45:44 CEST] <jamrial> dead how? [19:46:09 CEST] <wm4> not called by "make fate" or "make fate-seek" [19:46:22 CEST] <wm4> and manually calling them doesn't seem to work either [19:46:48 CEST] <jamrial> make fate-seek does call them [19:46:52 CEST] <jamrial> just tried [19:47:07 CEST] <wm4> not here [19:47:57 CEST] <jamrial> from seek.mak : "FATE_SEEK += $(FATE_SEEK_LAVF-yes:%=fate-seek-lavf-%)" "fate-seek: $(FATE_SEEK)" [19:48:17 CEST] <jamrial> something must be wrong on your end [19:48:29 CEST] <wm4> ah, 'Im stupid [19:48:35 CEST] <wm4> I accidentally removed this line [19:48:46 CEST] <wm4> sorry [20:23:25 CEST] <BtbN> Is calling av_frame_make_writable the same as what writing_filters.txt suggests in line 238+? [20:25:43 CEST] <ubitux> > [FFmpeg-user] Merging animated gif and mp3 [20:25:44 CEST] <ubitux> it begins. [20:26:31 CEST] <nevcairiel> BtbN: make_writable is writeing_filters 250+, ie. in-place processing [20:26:58 CEST] <BtbN> nevcairiel, yes, but i don't see it making any difference if all i'm processing is packed RGBA? [20:27:11 CEST] <BtbN> As i will have to copy the entire buffer anyway if the frame isn't writable [20:27:22 CEST] <nevcairiel> but it might be writable [20:27:36 CEST] <BtbN> in that case make_writable just won't do anything [20:27:37 CEST] <sfan5> ubitux: i tried putting apng, ac3 and ssa into a container the other day; didn't work out [20:28:18 CEST] <nevcairiel> BtbN: indeed, but if you do in-place processing, then you should call make_writable, since it may or may not be writable, its a no-op when not needed [20:28:34 CEST] <wm4> <ubitux> > [FFmpeg-user] Merging animated gif and mp3 [20:28:37 CEST] <BtbN> yeah, i can see a difference for YUVA, where alpha is in its own plane. [20:28:40 CEST] <wm4> use uncompressed rar as container? [20:29:02 CEST] <ubitux> yeah [20:29:06 CEST] <BtbN> nevcairiel, yes, i meant make_writable vs. the manual approach of individual buffers. [20:29:20 CEST] <nevcairiel> individual buffers are only needed if you cannot do in-place processing [20:29:44 CEST] <nevcairiel> ie. you need input from surrounding pixels, which in-place doesnt easily do since it overwrites the original ones =p [20:30:15 CEST] <BtbN> Yes, but for YUVA, if the input is not writable, I'd only need to allocate a new alpha buffer. [20:30:28 CEST] <BtbN> Wouldn't even have to copy it, as i generate an entirely new one anyway. [20:31:21 CEST] <BtbN> But currently, my RGB based colorkey is doing a better job for a greenscreen than yuv based chromakey... :D [20:31:24 CEST] <cone-444> ffmpeg 03Mate Sebok 07master:4d98015dcf65: dshow: add capture device save and load [20:31:25 CEST] <cone-444> ffmpeg 03Andreas Cadhalpun 07master:86d00ede4f9a: bink: check vst->index_entries before using it [20:31:28 CEST] <nevcairiel> i dont think you can keep the references to the same YUV planes and only allocate a new A plane, dont think frames are designed to work like that [20:31:59 CEST] <kierank> I think it's possible to do with buffer referencing [20:32:02 CEST] <kierank> but it's not a good idea [20:32:06 CEST] <kierank> well it is [20:32:09 CEST] <kierank> but it won't work within ffmpeg [20:32:19 CEST] <kierank> I have the same problem with chroma conversions and luma memcpy [20:32:58 CEST] <wm4> nevcairiel: uh, actually... even libavfilter plays tricks with separate buffers/planes [20:33:02 CEST] <wm4> I forgot which filter [20:33:18 CEST] <nevcairiel> wm4: and if people actually used avfilter, it would probably blow up :D [20:34:10 CEST] <nevcairiel> in other news, why does every article about a simple audio low-pass filter assume you majored in signal processing [20:34:28 CEST] <BtbN> I'm also thinking the same about chromakey algorithms... [20:34:39 CEST] <BtbN> I just can't find anything that's not written like a scientific paper [20:34:59 CEST] <BtbN> The plain stupid RGB approach doesn't work propperly for YUV [20:36:43 CEST] <nevcairiel> I really do not want to use the avfilter biquads filter for this, so I figured, can't be too hard to figure out, but meh! [20:36:44 CEST] <wm4> ah, it was vf_pad which does the crazy stuff [20:37:20 CEST] <wm4> it makes quite a lot of low level decisions how the referenced buffers work [20:37:36 CEST] <wm4> so you can crop a frame and then pad it again, without having to copy the frame [20:37:38 CEST] <wm4> (useful huh) [20:37:47 CEST] <nevcairiel> and it gets away with it because only ffmpeg.c uses it :D [20:41:40 CEST] <BtbN> I wonder if me just adding a fourth buffer to the frame is ok, for the alpha data, in case it doesn't already exist. [20:42:20 CEST] <BtbN> I'm also not sure how to communicate the output format, as it depends on the input format. [20:47:12 CEST] <jamrial> so cinepak encoder has 0% coverage. adding a couple vsynth tests is trivial, but it's so painfully slow that i wonder if it's worth adding them [20:47:41 CEST] <wm4> why is there a cinepak encoder? [20:48:00 CEST] <jamrial> because someone wrote it, i guess :p [20:48:57 CEST] <michaelni> a test with 2-3 frames of low resolution is too slow too ? [20:51:05 CEST] <jamrial> oh right, passing -vframes 3 or so [20:51:56 CEST] <jamrial> yeah, it's "fast" that way. i'll send a patch later [20:57:39 CEST] <Compn> wonder how many companies have sent michaelni some hardware for testing :D [20:57:51 CEST] <Compn> wonder if michael has enough room for all of these computers in his place :D [21:01:23 CEST] <BtbN> Most companies are quite happy to send hardware samples. [21:02:17 CEST] <BtbN> Sending hardware to some developer means there most likely will be software making use of it, which ultimately leads to more users. [21:13:54 CEST] <BBB> I do wonder about these toy encoders [21:14:01 CEST] <BBB> I mean, cinepak... [21:14:37 CEST] <wm4> as usual ffmpeg will keep it because ffmpeg never removes anything [21:16:06 CEST] <llogan> you want to save 67K [21:17:04 CEST] <wm4> and potentially a lot of time needed for maintenance [21:17:31 CEST] <BBB> was this one of mikes toy projects? [21:17:35 CEST] <BBB> (melanson) [21:17:58 CEST] <jamrial> the c file mentions Tomas Härdin [21:18:29 CEST] <BBB> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-January/153472.html ? [21:18:31 CEST] <BBB> Rl [21:19:00 CEST] <BBB> oh he sent the email [21:19:06 CEST] <BBB> it was written by tomas, yes [21:21:18 CEST] <jamrial> Aetey is the maintainer, though [21:48:10 CEST] <cone-444> ffmpeg 03Ronald S. Bultje 07master:d02d04a18f30: vp9: remove one optimization branch in iadst16 which causes overflows. [21:48:40 CEST] <jamrial> :( [21:51:59 CEST] <jamrial> fortunately this comes after you wrote the sse2 version [21:55:31 CEST] <BBB> (did my response to you ever made it here before I got disconnected, jamrial?) [21:55:38 CEST] <jamrial> no [21:58:58 CEST] <BBB> hm [21:59:40 CEST] <BBB> I said fortunately it only requires to swap some mulhrsw with slightly more expensive sets of pmaddwd instructions [21:59:49 CEST] <BBB> so kinda sad, but not the end of the world [22:00:35 CEST] <jamrial> yeah [22:01:13 CEST] <BBB> I still have bugs in vp90-2-15-segkey_adpq.webm and vp90-2-16-intra-only.webm [22:01:20 CEST] <BBB> and of course profile 1 and 2 are missing [22:08:08 CEST] <BtbN> Great, something seems to be causing random memory corruption. [22:08:21 CEST] <BBB> asan, valgrind! [22:09:05 CEST] <BtbN> At least the avctx->priv address changes between config_props of my output pin and filter_frame. [22:09:11 CEST] <BtbN> And i don't think it is supposed to do that. [22:09:33 CEST] <BtbN> The random crashes i get also clearly indicate memory corruption. [23:31:42 CEST] <cone-444> ffmpeg 03wm4 07master:748d4816d92c: avformat: add AVFMT_FLAG_FASTSEEK, use it for mp3 [23:51:22 CEST] <cone-444> ffmpeg 03Tucker DiNapoli 07master:6264b6227c77: postproc: Replaced inline asm for prefetching with prefetch functions [00:00:00 CEST] --- Thu Apr 23 2015

1 0

ffmpeg.log.20150422
by burek 23 Apr '15

23 Apr '15

[00:29:24 CEST] <DusteD> I have a videofile and around 9000 images (all same dimensions), the first image is a map, the rest of a "dot", I'm trying to think of the most reasonable tactic for overlaying the map-image, and then the correct dot-image onto the video. The video is 60 fps, and the images are 5 fps. [00:29:47 CEST] <DusteD> My first instinct is to extract all frames from the video as single images and use imagemagick and bash scripting [00:30:17 CEST] <DusteD> but, I'm wondering if maybe there is a more intelligent way, like, converting all the images to a video first, and overlaying the two videos [01:48:56 CEST] <kyleogrg> what's a good way to change a encode a video with square pixels? [01:49:19 CEST] <kyleogrg> my source video is ntsc and isn't square [01:50:31 CEST] <kyleogrg> One source says to use "scale=iw*sar:ih". is this good? [02:38:26 CEST] <kyleogrg> is there any reason to use high444 profile for x264? [02:43:13 CEST] <klaxa> larger colorspace [02:45:24 CEST] <kyleogrg> klaxa: if i'm converting from NTSC DV-AVI to MP4, do you think high444 will produce any noticeable improvement? [02:46:06 CEST] <klaxa> depends on the content [02:46:26 CEST] <klaxa> and depends on the source [02:46:51 CEST] <klaxa> do some test encodes and judge for yourself [02:46:56 CEST] <kyleogrg> ok [02:47:10 CEST] <kyleogrg> and technically speaking, will this profile produce a smaller file? [02:47:34 CEST] <klaxa> would probably be larger [02:47:58 CEST] <kyleogrg> all right [02:48:02 CEST] <klaxa> but i have no idea, the easiest way to find out is by doing two encodes with the same setting [02:48:10 CEST] <klaxa> except for the profile [03:00:57 CEST] <kyleogrg> if my source video is 4:1:1 chroma subsampling, is there any reason to convert it using the high444 profile? [03:40:19 CEST] <Prelude2004c> sup everyone.. good evening.. having trouble passing a ffmpeg -i < input > -vcopy and -acopy -f mpegts udp://destination:port ... < --- this causes artifacts i guess because some UDP traffic is missed on the network. Over a distance i guess this is not the best way to pull data. [03:40:28 CEST] <Prelude2004c> anyone know a better way without transcoding it at source ? [03:40:41 CEST] <Prelude2004c> maybe somehow with little horsepower i can push it via TCP or something [03:40:51 CEST] <Prelude2004c> that way if a packet doesn't arrive it gets retransmitted [03:40:56 CEST] <Prelude2004c> i want to make sure our stream is clean [03:41:00 CEST] <Prelude2004c> so i can encode it properly [03:41:02 CEST] <Prelude2004c> any ideas ? [03:52:21 CEST] <Prelude2004c> can anyone help? [03:58:14 CEST] <klaxa> Prelude2004c: [03:58:15 CEST] <klaxa> Apr 19 00:41:53 <klaxa> you can use http if you are using a single client and a single server [03:58:16 CEST] <klaxa> Apr 19 00:42:37 <klaxa> Prelude2004c: https://ffmpeg.org/ffmpeg-all.html#http [03:58:16 CEST] <klaxa> Apr 19 00:42:41 <klaxa> see: listen option [03:58:16 CEST] <klaxa> Apr 19 00:43:53 <klaxa> or tcp: https://ffmpeg.org/ffmpeg-all.html#tcp [04:01:57 CEST] <Prelude2004c> cool, let me try it .. [04:02:02 CEST] <Prelude2004c> never knew about ogg [04:04:57 CEST] <Prelude2004c> http://22.22.22.22:5003: Cannot assign requested address [04:04:57 CEST] <Prelude2004c> [root@ts-stream ~]# ffmpeg -i udp://239.255.10.10:5000 -c copy -listen 1 -f ogg http://22.22.22.22:5003 [04:05:04 CEST] <Prelude2004c> what does it mean ? [04:14:18 CEST] <Prelude2004c> the server:port .. is that localhost ? [04:14:28 CEST] <Prelude2004c> or can it be a remote url? [08:05:22 CEST] <Prelude2004c> hey , anyone here ? why all my videos look funny if i don't deinterlace [08:08:42 CEST] <botnut> hi all - never used ffmpeg/ffserver before - but can ffserver be used to stream a video source to many people - keep in mind I would prefer that the video source not be from a file - but rather a stream itself to ffserver in mpjeg format - also this is a live feed [08:10:00 CEST] <Prelude2004c> why dn't you just output to a local port like RTMP . [08:10:18 CEST] <Prelude2004c> or better yet, output HLS segments and then it will use adaptive bit rate straming [08:11:00 CEST] <botnut> the source is coming from a raspberry pi using picamera - it was hard to get it to go real time as is - but we did - now the trick is getting that stream over to a broadcasting server of some sort [08:12:36 CEST] <Prelude2004c> hwo to you view the source right now? [08:13:01 CEST] <botnut> we open vlc and connect to the pi directly - however - this won't be an option because we want to have this fed on the web with many clients [08:13:28 CEST] <Prelude2004c> you can use VLC to outout [08:13:39 CEST] <Prelude2004c> why don't you output rtmp > wowza server and then have that serve all the customers [08:14:02 CEST] <botnut> hrmmmm [08:14:19 CEST] <Prelude2004c> vlc i am not sure can do segmenting but it probably can.. [08:14:36 CEST] <Prelude2004c> then just dump the files to a directory people can access [08:14:44 CEST] <Prelude2004c> but wowza is popular [08:15:13 CEST] <botnut> the idea of dumping it to the file system indicates to me we will have lag of 1-3 seconds or so [08:15:20 CEST] <botnut> would prefer as near real time as possible [08:15:37 CEST] <botnut> there is no need to go back in time and see previous video - just the current feed [11:00:08 CEST] <aleb> How can I get the frame numbers for the frames which contain the full picture (not the diff since the previous frame)? [11:02:20 CEST] <Anoia> I frames (vs incremental P Frames) [11:31:51 CEST] <aleb> And how do I print the list of frames? [12:55:58 CEST] <aleb> $ ffprobe -i x.MTS -show_frames -of csv | grep frame,video [12:55:58 CEST] <aleb> frame,video,1,37456,0.416178,37456,0.416178,37456,0.416178,1800,0.020000,768,129895,1920,1080,yuv420p,1:1,I,0,0,0,0,0 [14:52:08 CEST] <Fyr> could anyone tell me what genre Christmas carols have? [17:29:39 CEST] <squeegily> I have an MP4 which is 240x134. I want to: scale it to 512px wide, then "crop" it to 512px high (centered), with a transparent background, and save it as a GIF.. I can't figure out how to do it, though [17:30:07 CEST] <squeegily> I'm stuck on ffmpeg -i $MP4 -vf "scale=512:-1" $GIF [17:30:48 CEST] <squeegily> I took a look at https://trac.ffmpeg.org/wiki/Scaling%20%28resizing%29%20with%20ffmpeg but I'm not understanding the cropbox thing [17:30:52 CEST] <c_14> -vf scale=w=512:h=-2,crop=h=512:w=iw [17:35:29 CEST] <squeegily> Invalid too big or non positive size for width '512' or height '512' [17:36:28 CEST] <squeegily> Maybe "crop" is the wrong word.. The GIMP equivalent of what I want to do is Canvas Size, <increase>, Center [17:36:46 CEST] <squeegily> I want to "un-crop" the image to reveal a transparent background [17:36:50 CEST] <c_14> You want to make it bigger? [17:36:51 CEST] <c_14> pad [17:37:23 CEST] <squeegily> pad worked.. how do I center the image? [17:37:43 CEST] <c_14> x=iw/2:y=ih/2 [17:37:49 CEST] <c_14> wait [17:37:59 CEST] <c_14> x=(ow-iw)/2:y=(oh-ih)/2 [17:38:03 CEST] <squeegily> Also, how do i make the background transparent instead of black? [17:38:40 CEST] <c_14> :color=black@0 [17:38:41 CEST] <sfan5> you can have a transparent background, but you can't save transparency into gifs [17:38:48 CEST] <squeegily> Why not? [17:38:54 CEST] <squeegily> Is a bug report open for that? [17:39:01 CEST] <sfan5> because GIF doesn't support that [17:39:28 CEST] <squeegily> sfan5: What does GIMP use for transparent GIFs then? Other image viewers and browsers seem to view them fine [17:40:23 CEST] <squeegily> ..I thought [17:41:08 CEST] <sfan5> ... [17:41:11 CEST] <sfan5> I don't know [17:41:56 CEST] <squeegily> Yeah I just tested it by taking a GIF outputted by ffmpeg, opening it in GIMP, adding an alpha channel, and re-exporting [17:41:58 CEST] <sfan5> GIF doesn't support transparency, so GIMP is doing something but not saving transparency [17:42:31 CEST] <squeegily> That transparency showed up in my browser and image viewer and when re-opened in Gimp [17:42:40 CEST] <squeegily> I suspect it's legitimate [17:42:59 CEST] <squeegily> "test.gif: GIF image data, version 89a, 512x512" [17:43:15 CEST] <sfan5> could you upload some gif with transparency somewhere? [17:43:27 CEST] <sfan5> I don't know what GIMP does to save transparency [17:44:06 CEST] <squeegily> I had this book on HTML4 that mentioned that Photoshop was able to save to a high enough GIF standard to support it or something like that [17:44:15 CEST] <squeegily> It was a really old book, I don't know if I have it anymore [17:44:27 CEST] <squeegily> But that means GIFs have probably supported it forever [17:44:33 CEST] <squeegily> Anyway, here's the image: http://a.uguu.se/fiuxrv_test.gif [17:45:05 CEST] <squeegily> 1 sec I broke the animation [17:45:21 CEST] <sfan5> i meant a transparent gif [17:45:30 CEST] <sfan5> but i did it myself with gimp [17:45:30 CEST] <sfan5> and now I'm confused [17:45:33 CEST] <squeegily> Check the bototm half of the image [17:46:06 CEST] <sfan5> it's transparent... [17:47:19 CEST] <squeegily> Here's one with a hole in his face for clarity: http://a.uguu.se/ccqwrn_test.gif [17:47:34 CEST] <sfan5> ahh [17:47:51 CEST] <sfan5> apparently gifs can have an 1-bit alpha channel [17:47:56 CEST] <squeegily> The GIF ffmpeg outputted had transparency properly set on every frame except a single one [17:48:24 CEST] <squeegily> Just the first frame lacked an alpha channel; I could have simply removed that frame to fix the animation [17:48:43 CEST] <squeegily> Since it set the color for every pixel which was never later overwritten [17:49:03 CEST] <squeegily> So it seems ffmpeg does support gif transparency 90% of the way [18:13:23 CEST] <capradmar> I post that on SO: http://stackoverflow.com/questions/29773692/ffmpeg-crashes-on-startup-upon-… [18:13:28 CEST] <capradmar> any idea? [20:14:01 CEST] <faLUCE> Hell, how can I cut the first 3.5 seconds of myfile.mp3 ? [20:25:06 CEST] <sfan5> faLUCE: if you want just the 3.5s: ffmpeg -i myfile.mp3 -t 00:00:03.500 output.wav if you want everything after 3.5s: ffmpeg -ss 00:00:03.500 -i myfile.mp3 -ss 0 output.wav [20:47:34 CEST] <faLUCE> sfan5: thanks [21:08:55 CEST] <kyleogrg> Hello [21:09:10 CEST] <kyleogrg> Aside from this IRC channel, there is also a mailing list for support, right? [21:09:30 CEST] <c_14> yes [21:10:23 CEST] <kyleogrg> Is that what this is? https://ffmpeg.org/pipermail/ffmpeg-user/2011-November/003203.html [21:10:32 CEST] <kyleogrg> (for example) [21:10:33 CEST] <llogan> ffmpeg-user [21:10:36 CEST] <llogan> http://ffmpeg.org/contact.html [21:11:09 CEST] <llogan> make sure to provide your actual command and the complete console output. [21:11:17 CEST] <kyleogrg> okay [21:11:37 CEST] <llogan> if you do not subscribe then you will have to wait for moderator approval. usually less than 24 hrs. [21:11:53 CEST] <kyleogrg> So that's the place to go if I need support (other than here)? [21:12:17 CEST] <llogan> yes. here and ffmpeg-user ML are the two official user support methods [21:13:08 CEST] <kyleogrg> is there a cleaner way to view these ffmpeg-user threads? like an html version? [21:13:20 CEST] <llogan> the link you provided is HTML [21:13:32 CEST] <llogan> but some people may prefer third party viewers like nabble or gmane [21:13:41 CEST] <kyleogrg> yes. well, like... i don't know [21:13:47 CEST] <kyleogrg> something that looks like a forum [21:13:56 CEST] <kyleogrg> maybe it's just me, but it's hard to read [21:14:10 CEST] <kyleogrg> things all run together. lots of >>>>>>>>>> [21:14:23 CEST] <llogan> http://news.gmane.org/gmane.comp.video.ffmpeg.user [21:14:27 CEST] <llogan> http://ffmpeg-users.933282.n4.nabble.com/ [21:14:57 CEST] <kyleogrg> ah, thanks a lot [21:17:13 CEST] <kyleogrg> i like the second link [21:17:17 CEST] <kyleogrg> just what i was looking for [21:20:10 CEST] <llogan> more ML info: https://trac.ffmpeg.org/wiki/MailingListEtiquette [21:22:04 CEST] <kyleogrg> thanks, i'll look at it [21:36:09 CEST] <CooKieLord> Hi! I'm just wondering if I'm in the right place for a question with regards to how to use the FFMPEG library in C++ code [21:42:43 CEST] <c_14> Well, you're not in the wrong place at least. Whether or not someone is currently around who can help you is another question. The best bet is to ask and wait to see if someone can help you, and/or ask on the libav-user(a)ffmpeg.org ml. [21:43:12 CEST] <CooKieLord> Awesome thanks [21:47:50 CEST] <kyleogrg> Okay, I want to concatenate many chunks of a video file into one. [21:48:06 CEST] <kyleogrg> they are numbered 1 to 178 [21:48:40 CEST] <kepstin-laptop> kyleogrg, you'd probably want to write a script that generates your ffmpeg command then. [21:48:44 CEST] <kyleogrg> rather than writing out "concat:001.blah|002.blah|003.blah" and so on... [21:48:55 CEST] <kyleogrg> exactly! but how? [21:49:18 CEST] <kepstin-laptop> if you're using linux, it's a pretty trivial shell script. if you're using windows... well, i can't help you there ;) [21:49:38 CEST] <kyleogrg> I simply need to concat all the *.blah files in a folder. they are already in order, so that won't be a problem [21:49:40 CEST] <llogan> you probably can't use the concat protocol [21:49:49 CEST] <kyleogrg> llogan: why not? [21:50:11 CEST] <llogan> it's for "cat friendly" formats. you probably need the concat demuxer or concat filter [21:50:14 CEST] <kyleogrg> these are actually chunks of a video stream which can just be joined together [21:50:39 CEST] <kyleogrg> basically I was using Ripbot264 to encode a x265 (yes x265) video [21:50:46 CEST] <llogan> if it works for you then go ahead and use it [21:51:05 CEST] <kyleogrg> it made many chunks, but the batch file to join them failed [21:51:26 CEST] <kyleogrg> yeah. but how can i just say "use all the files in this folder"? [21:51:57 CEST] <llogan> some examples here https://trac.ffmpeg.org/wiki/Concatenate [21:51:58 CEST] <kyleogrg> i thought i remember there being a simple solution [21:52:40 CEST] <kyleogrg> hmm ok [21:53:15 CEST] <kyleogrg> thanks [21:56:44 CEST] <CooKieLord> Are there examples or documentation anywhere on how to properly reset the decoder in C++ if we get into an inconsistent state? [21:57:11 CEST] <CooKieLord> The examples on how to use avcodec_decode_video2 that I can find are very optimistic and don't really show how to handle errors. [22:02:22 CEST] <kyleogrg> okay, trying to concat, i'm getting "unable to find a suitable output format for 'output.265'" [22:02:55 CEST] <kyleogrg> these are all .265 files, chunks which need to be concatenated [22:03:06 CEST] <kyleogrg> and i'm saying "-c:v copy" [22:07:21 CEST] <kyleogrg> all righty. now stream copying to output.mp4. this seems to be working (it's still going), but for every file chunk, I'm getting "pts has no value" [22:37:26 CEST] <hunternet93> how do i convert a video from .mov to .mp4 without re-encoding the mov's h.264 video stream? [22:44:18 CEST] <c_14> -c:v copy [23:22:50 CEST] <kyleogrg> i used ffmpeg to mux a x265 stream and AAC stream to MP4 [23:22:59 CEST] <kyleogrg> but the audio seems to gradually get out of sync [23:23:04 CEST] <kyleogrg> any clues? [23:23:48 CEST] <kyleogrg> I did something like: ffmpeg.exe -i "input.265" -i "input2.aac" -c:v copy -c:a copy output.mp4 [23:24:46 CEST] <kyleogrg> and ffmpeg wanted me at add (something like) aac_adtstoasc to the command line [23:25:03 CEST] <BtbN> If the input files are entirely without meningfull timestamps, that's not too surprising. [23:25:43 CEST] <kyleogrg> yeah [23:25:54 CEST] <kyleogrg> what can you recommend as a solution? [23:26:35 CEST] <kyleogrg> i don't know how to add timestamps or anything like that [23:26:36 CEST] <BtbN> Don't use raw files. [23:26:42 CEST] <kyleogrg> sure [23:26:52 CEST] <kyleogrg> but i'm just experimenting with this particular file [23:27:09 CEST] <BtbN> The offset changing over time propably means ffmpeg makes a wrong guess about the framerate [23:27:11 CEST] <kyleogrg> a certain distributed encoding program generated all these .265 chunks [23:27:36 CEST] <kyleogrg> ok [23:27:58 CEST] <BtbN> Or samplerate [23:28:02 CEST] <kyleogrg> although mediainfo (idk if i should trust it) says the output file is 23.976 frames (which is correct) [23:28:06 CEST] <BtbN> Not sure if it also has to guess that [23:28:25 CEST] <BtbN> What does ffprobe say about the file? [23:28:30 CEST] <BtbN> mediainfo is not ffmpeg. [23:30:32 CEST] <kyleogrg> for the .265 stream, it says: 24.17 fps, 23.98 tbr, 1200k tbn, 23.98 tbc [23:31:32 CEST] <kyleogrg> for the aac stream, it says: Duration: 03:02:43.53, bitrate: 316 kb/s [23:31:32 CEST] <kyleogrg> Stream #0:0: Audio: aac (LC), 48000 Hz, 5.1, fltp, 316 kb/s [23:32:07 CEST] <kyleogrg> the .265 stream reports no duration or bitrate in ffprobe [23:32:27 CEST] <BtbN> Well, 24.17 fps clearly sounds like a bad guess [23:33:18 CEST] <kyleogrg> and as i mux again here, it says: Estimating duration from bitrate, this may be inaccurate [23:33:39 CEST] <kyleogrg> for the aac [23:33:39 CEST] <BtbN> Which is why you don't use raw files, they are lacking a lot of vital information. [23:33:44 CEST] <kyleogrg> yeah [23:34:11 CEST] <BtbN> Just play with the video framerate, i'd guess it's just wrong. [23:34:22 CEST] <kyleogrg> i'll try it, thanks [00:00:00 CEST] --- Thu Apr 23 2015

1 0

ffmpeg-devel.log.20150421
by burek 22 Apr '15

22 Apr '15

[00:12:20 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:e6e8cc8ce9c2: avformat/img2dec: do not rewind custom io buffers [00:35:28 CEST] <kierank> wm4: so as far as I can tell it's not possible to link to avcodec in /tests [00:35:32 CEST] <kierank> which is annoying [00:41:58 CEST] <cone-905> ffmpeg 03Deb Mukherjee 07master:26a0bcb15b83: Support for VP9 high-color/high-bit-depth encoding [00:49:56 CEST] <kierank> anyone knowledgable about the Makefile system? [01:04:41 CEST] <jamrial> kierank: check doc/examples/Makefile, it links to libraries outside of their respective folders to compile example programs [01:05:00 CEST] <jamrial> it could be adapted to compile these api test programs from inside tests/ [01:05:25 CEST] <kierank> thanks [01:08:16 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:ba631b791435: avformat/utils: Ensure that AVFMT_FLAG_CUSTOM_IO is set before use [01:15:03 CEST] <wm4> kierank: huh, but aren't there other tests using lavf etc.? [01:15:18 CEST] <kierank> they all use ffmpeg.c [01:18:30 CEST] <wm4> I wasted so much time on ffmpeg.c's bullshit semantics for -ss [01:29:41 CEST] <cone-905> ffmpeg 03Vignesh Venkatasubramanian 07master:30ba28fe8e57: webmdashenc: Fix potential memory leak [02:03:01 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:ecf34e8fc2f7: avformat/mp3dec: Adjust returned timestamp in the CBR seeking case [02:25:46 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:a924b83cccf2: avformat/nsvdec: remove trace log from probe(), this is better done generically not per format [02:39:18 CEST] <BBB> is there a way to force ffmpeg to not resize? [02:39:41 CEST] <BBB> like, if my input resizes from size axb to cxd and I just want these frames to be sent like that to the encoder (rawenc+framemd5 in this case) [04:21:26 CEST] <ubitux> alright, i'm soon back in the game. [04:23:20 CEST] <jamrial> \o/ [04:29:40 CEST] <ubitux> oh, colorkey filter, cool [04:57:04 CEST] <ubitux> note: the style of the flac test is wrong; i think i saw someone raise the issue, it could be nice if it could be fixed [05:24:04 CEST] <ubitux> rcombs: are you feeling like adding test(s) for the ASS thing? [05:24:53 CEST] <ubitux> i think it would be nice to have a bunch of small mkv with all kind of crazy ass muxed in (with different pattern of extradata/codecprivate sickness) [05:26:41 CEST] <rcombs> ubitux: that sounds like an excellent idea, if I can work up the motivation to learn to write fate tests [05:26:54 CEST] <rcombs> or do you want unit tests [05:26:57 CEST] <rcombs> (or, is fate unit tests?) [05:27:02 CEST] <rcombs> (I don't know things) [05:27:15 CEST] <ubitux> there are functionnal tests [05:27:23 CEST] <ubitux> it's generally calls to ffmpeg [05:27:31 CEST] <ubitux> to do very specific tasks [05:27:38 CEST] <ubitux> (it has various other tools though) [05:27:46 CEST] <ubitux> but in this case, a demux will be enough [05:28:01 CEST] <ubitux> look at tests/fate/subtitles.mak [05:28:45 CEST] <ubitux> and add maybe fate-mks-[1..N] tests, that will be triggered by make fate-subtitles (and thus make fate) [05:29:02 CEST] <ubitux> see http://ffmpeg.org/fate.html [05:29:10 CEST] <ubitux> if you need to upload one or more sample, ask michaelni [05:29:17 CEST] <ubitux> ideally, small ones [05:30:26 CEST] <ubitux> typically, i think having extradata with various crap like no [Events] header, some with V4 style, some with V4+ styles, and that sort of madness might help [05:30:33 CEST] <ubitux> but anyway... :) [05:31:00 CEST] <ubitux> i'm not sure how to construct easily such stream, so i didn't bother doing it [07:16:07 CEST] <Timothy_Gu> wait onemda is from Croatia right? [09:47:44 CEST] <wm4> michaelni: what happens if non-mp3 data is fed to the mp3 parser or the dcoder? like a id3v1 tag? [09:47:47 CEST] <wm4> *decoder [09:50:18 CEST] <wm4> ubitux: didn't you want some subtitle tests from me? I feel like adding some now [10:43:27 CEST] <durandal_1707> wm4: where you found 24bit Apng sample? [11:05:53 CEST] <wm4> durandal_1707: not sure, and I don't have it anymore [11:07:48 CEST] <michaelni> parsers should generally pass data through they dont recognice, the decoder should ignore it i think but i dont know if it does [11:09:18 CEST] <wm4> I guess I'll check... [14:27:09 CEST] <cone-874> ffmpeg 03Michael Niedermayer 07master:8f9a3817d502: avfilter/vf_qp: fix cleanup on error [15:00:42 CEST] <wm4> michaelni: with our mp3 test sample, the CBR seek actually gets off by one frame towards the end of the file [15:01:11 CEST] <wm4> michaelni: I found out that mpg123 actually indexes the file while seeking (instead of skipping it without reading the data) [15:01:29 CEST] <wm4> michaelni: I want to implement the same thing for libavformat (we discussed it to some degree) [15:06:38 CEST] <michaelni> libavformat should already index and use the index if seek otherwise fails (like no cbr no toc) [15:07:57 CEST] <wm4> well, I'm not sure what exactly it does in this case [15:08:06 CEST] <nevcairiel> unfortunately "should" is not a "actually does" =p [15:08:57 CEST] <nevcairiel> also, it only indexes parts you already played, seeking into the future doesnt work that way ... plus on vbr samples, it doesnt even figure out how long an audio file actually is, which a full index would also cure [15:09:24 CEST] <wm4> I suppose there's some chance what I want it to do is already buried there (like if the seek target is beyond the last index entry, it keeps reading packets until the target is reached) [15:09:45 CEST] <wm4> i.e. lazy indexing [15:09:52 CEST] <wm4> a full index would be nice too [15:10:02 CEST] <wm4> it'd be possible to actually seek in files with timestamp resets [15:10:26 CEST] <nevcairiel> for some reason people want to keep using my stuff for audio files, including vbr stuff, and they always whine when the duration is off :( [15:10:42 CEST] <wm4> what file types does this affect? [15:10:51 CEST] <wm4> mp3 with xing headers should be ok (just seeking is broken) [15:10:54 CEST] <nevcairiel> usually thats raw audio files [15:11:00 CEST] <wm4> ah that stuff [15:11:01 CEST] <nevcairiel> ie. raw aac [15:11:14 CEST] <wm4> apparently it's popular to use such files as external audio tracks [15:11:27 CEST] <nevcairiel> i keep telling them to shove it into m4a, but they wont listen [15:11:38 CEST] <wm4> so it's for use with video, and naturally this requires accurate seeking [15:11:44 CEST] <wm4> stupid crap [15:12:05 CEST] <nevcairiel> i'm kinda surprised i dont get complaints from the external audio track crowd [15:21:35 CEST] <cone-874> ffmpeg 03Paul B Mahol 07master:77e794908b18: avcodec/hq_hqa: remove superfluous log message [15:32:21 CEST] <wm4> ok it seems to work [15:32:34 CEST] <wm4> I only had to remove the seek callback and not add the xing entries [15:33:00 CEST] <wm4> michaelni: so what do you say, use the generic index creation & seek code, and remove all the mp3 seek code? [15:33:23 CEST] <wm4> or shall there be a compatibility option to use the old mode (on or off by default?) [15:36:39 CEST] <BBB> michaelni: whats the practical effect of your patch? [15:36:45 CEST] <BBB> michaelni: the remove-memalign-warning one [15:36:54 CEST] <BBB> michaelni: youre not stating what your actual goal is [15:37:05 CEST] <BBB> michaelni: do you want to support mixing av_realloc and av_malloc? [15:37:37 CEST] <wm4> BBB: I believe that's the intention [15:38:40 CEST] <BBB> so is mac an affected platform? [15:39:20 CEST] <wm4> realloc removes the alignment (I think), so this patch can unfortunately not work (I think) [15:45:36 CEST] <kierank> interesting how nicholas suddenly cares about the POSIX spec [15:46:56 CEST] <wm4> he didn't before? [15:49:16 CEST] <kierank> no but he complains that I follow specs too closley [15:49:19 CEST] <kierank> closely [15:50:29 CEST] <wm4> oh I see [16:04:36 CEST] <robUx4> hi [16:06:41 CEST] <robUx4> do you have any sample where the decoder profile changes mid-stream ? [16:08:03 CEST] <robUx4> H264, MPEG4.2 or any video codec where it's possible [16:09:03 CEST] <nevcairiel> http://fate-suite.ffmpeg.org/h264/reinit-small_420_8-to-large_444_10.h264 [16:09:40 CEST] <robUx4> thx [16:09:40 CEST] <nevcairiel> this changes practically everything there is to change, size, chroma, bitdepth [16:10:56 CEST] <michaelni> BBB, i dont want to mix them, but rather they are likely mixed in various codepathes and finding and avoiding it all costs time that could be better spend elsewheer IMHO [16:11:24 CEST] <BBB> michaelni: I dont see why it matters then [16:11:31 CEST] <BBB> michaelni: as in, I dont think the patch makes sense [16:11:33 CEST] <robUx4> Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuv420p, 240x196, 25 fps, 25 tbr, 1200k tbn, 50 tbc [16:11:33 CEST] <robUx4> [h264 @ 04a97320] Reinit context to 352x288, pix_fmt: yuv444p10le [16:11:43 CEST] <robUx4> that's what I needed, thx [16:11:45 CEST] <BBB> michaelni: its not like youre actively spending time trying to find and identify such codepaths, right? [16:11:55 CEST] <michaelni> BBB, yes i see what you mean [16:11:59 CEST] <nevcairiel> I think the warning should stay in, if it happens to cause problems in practice we can always fix them once reported as such, i dont think anyone is actively chasing after such cases [16:11:59 CEST] <BBB> michaelni: just in some cases youll find a crash, and itll turn out to be related to this [16:12:03 CEST] <BBB> michaelni: so you fix the bug [16:12:12 CEST] <BBB> michaelni: so I dont see how it costs time to keep the comments where they are [16:12:42 CEST] <nevcairiel> ..not that I care personally, Windows has an aligned realloc :D [16:12:47 CEST] <BBB> kierank: I think you sometimes just need a big teddybear hug [16:12:58 CEST] <BBB> nevcairiel: but we dont use it, do we? [16:12:59 CEST] <BBB> :-p [16:13:03 CEST] <nevcairiel> i think we do [16:13:06 CEST] <BBB> oh rly [16:13:08 CEST] <BBB> thats cool [16:13:30 CEST] <nevcairiel> yes we do [16:13:33 CEST] Action: nevcairiel checked [16:20:27 CEST] <michaelni> wm4, about mp3, users should have the option to use cbr/toc based seeking if they dont want to index the whole file for a seek to near the end, i have no oppinion on what should be default [16:21:35 CEST] <wm4> then I'd say let's try with actually correct seeking on by default [18:05:38 CEST] <nalply> Did I spam ffmpeg-devel? If so I am sorry for my mistake. [18:06:56 CEST] <Compn> im not seeing any large spams... [18:07:39 CEST] <wm4> git send-email misusage? [18:07:50 CEST] <nalply> wm4: Yes. Some members got spam from my in form of CC emails. [18:08:02 CEST] <wm4> yeah, I got some too [18:08:08 CEST] <wm4> but nothing on the actual list [18:08:08 CEST] <nalply> Terribly sorry! [18:08:45 CEST] <nevcairiel> the auto-CC behavior of git send-email is kinda annoying [18:09:11 CEST] <nalply> It's because I did a merge [18:09:32 CEST] <Timothy_Gu> lol [18:10:16 CEST] <Timothy_Gu> nalply: are you "Daniel Ly"? [18:10:20 CEST] <nalply> Yes [18:10:35 CEST] <Timothy_Gu> ah yep i got one too [18:10:50 CEST] <Timothy_Gu> You should probably say sorry on #libav-devel too [18:11:43 CEST] <nalply> Thanks for the tip. [18:12:26 CEST] <nalply> I will be back Thursday and retry. [18:49:32 CEST] <kierank> michaelni: so what do I need to do for outreachy [18:49:35 CEST] <kierank> I don't see this button [19:01:54 CEST] <michaelni> kierank, on https://outreachy.gnome.org/?q=view_projects&prg=4&p=717 theres a "Willing to mentor" button somewhere at the bottom [19:02:04 CEST] <kierank> ah thanks [19:02:38 CEST] <kierank> ah you click on the project name [19:03:17 CEST] <michaelni> thanks, it worked, it lists you now [19:04:26 CEST] <kierank> wtf R = floor (10 * min (1, 1 / average_reply_delay)) [use days for all units] [19:09:00 CEST] <kierank> reynaldo: ping [20:28:07 CEST] <cone-874> ffmpeg 03Luca Barbato 07master:9b2c57bef5e2: drawtext: Add an alpha option [20:28:08 CEST] <cone-874> ffmpeg 03Michael Niedermayer 07master:122150168f7d: Merge commit '9b2c57bef5e2f3f61a5fd708ba7d5351f5b3f386' [20:37:38 CEST] <reynaldo> kierank: pong [20:37:50 CEST] <reynaldo> sry for the delay, was having lunch [20:37:54 CEST] <reynaldo> kierank: still there? [21:17:29 CEST] <kierank> reynaldo: YES [21:17:32 CEST] <kierank> whoops [21:17:34 CEST] <kierank> caps lock [21:31:13 CEST] <reynaldo> kierank: sec please, will ping you in a bit [21:45:46 CEST] <reynaldo> kierank: ok, here now. might take a minute or two to reply but go ahead [21:45:58 CEST] <kierank> reynaldo: can you explain how the spreadsheet works [21:46:10 CEST] <kierank> because there are candidates who haven't submitted anything who have a high score [21:46:20 CEST] <reynaldo> no no [21:46:50 CEST] <reynaldo> those "scores" you are seeing are just leftover data from the previous page of the spreadsheet where I copied this from [21:47:06 CEST] <reynaldo> just fill the non calculated fields for your intern and please ignore the rest [21:47:45 CEST] <reynaldo> remember you are supposed to be working on the second sheet, the first one is the previous opw/outreachy term [21:48:43 CEST] <kierank> oic [22:01:38 CEST] <reynaldo> kierank: coolio, let me know if you need help with anything else [22:01:41 CEST] <reynaldo> and thanks for handling this [22:01:54 CEST] <reynaldo> will you be around for the meeting latter ? [22:02:19 CEST] <reynaldo> its in one hour from now [22:02:36 CEST] <kierank> yes [22:02:41 CEST] <kierank> a bit late but i should be there [22:22:46 CEST] <Timothy_Gu> michaelni: can you backport 7ad27f1221562b037178d1fb605510ba349f04cc? [22:23:51 CEST] <Timothy_Gu> it would be cool if you can do that now cuz I manually fixed everything in fate.ffmpeg.org to form a proper display: http://fate.ffmpeg.org:8080/ [22:24:04 CEST] <Timothy_Gu> but then some new results came in and messed it up again. [22:38:37 CEST] <michaelni> Timothy_Gu, locally backported to 2.6 - 2.3, it doesnt apply cleanly to 2.2 [22:38:38 CEST] <Timothy_Gu> michaelni: also: diff -u <(curl -q 'http://fate.ffmpeg.org:8080/log/mips-ubuntu-qemu-gcc-4.4/20150421091735/comp [22:38:41 CEST] <Timothy_Gu> ile' | grep warning | sort) <(curl -q 'http://fate.ffmpeg.org:8080/log/mips-ubuntu-qemu-gcc-4.4/20150421171722/com…' | grep warning | sort) [22:38:45 CEST] <Timothy_Gu> michaelni: thx [22:38:51 CEST] <Timothy_Gu> ooh [22:39:31 CEST] <Timothy_Gu> diff -u <(curl -q 'http://fate.ffmpeg.org:8080/log/mips-ubuntu-qemu-gcc-4.4/20150421091735/com…' | grep warning | sort) <(curl -q [22:39:34 CEST] <Timothy_Gu> 'http://fate.ffmpeg.org:8080/log/mips-ubuntu-qemu-gcc-4.4/20150421171722/com…' | grep warning | sort) [22:39:37 CEST] <Timothy_Gu> wat [22:39:40 CEST] <Timothy_Gu> but you get the idea [22:40:21 CEST] <Timothy_Gu> http://sprunge.us/FHdE?diff [22:44:09 CEST] <michaelni> thx, will fix it in a moment [22:47:34 CEST] <jamrial> Timothy_Gu: that's looking really nice. glad to finally see branches separate from master :p [22:49:01 CEST] <Timothy_Gu> jamrial: yeah [22:50:42 CEST] <jamrial> there's a 2.2 slot listed under master, though [22:55:01 CEST] <cone-874> ffmpeg 03Michael Niedermayer 07master:a79cbc0b8e77: avfilter/vf_qp: Fix use of uinitialized variable [22:55:56 CEST] <Timothy_Gu> jamrial: see the discussion above. Michael didn't backport the commit that fixes it, so I had to manually fix all the summary files. And that result just came in so I didn't fix that one yet. [22:57:11 CEST] <Timothy_Gu> jamrial: that result fixed [22:58:51 CEST] <jamrial> ah ok [23:03:08 CEST] <GabrielYYZ> hello [23:03:36 CEST] <cone-874> ffmpeg 03Michael Niedermayer 07release/2.5:3f629c83b462: avformat/img2dec: do not rewind custom io buffers [23:03:37 CEST] <cone-874> ffmpeg 03Michael Niedermayer 07release/2.5:5fd5b8ef79c0: avformat/utils: Ensure that AVFMT_FLAG_CUSTOM_IO is set before use [23:03:38 CEST] <cone-874> ffmpeg 03Timothy Gu 07release/2.5:a2ad7fdb3a26: fate: Include branch information in the payload header [23:06:03 CEST] <GabrielYYZ> i don't know if you've noticed but building with hardcoded-tables enabled is broken, i did a git bisect and it seems commit 8f7b022 is the bad one [23:07:06 CEST] <kierank> how do I connect to the channel [23:08:06 CEST] <wm4> GabrielYYZ: nice, a merge commit that basically touches everything [23:09:35 CEST] <GabrielYYZ> wm4, i think (i'm guessing here) including internal.h in bitstream.c is the actual problem [23:10:08 CEST] <GabrielYYZ> but, again, that's just me guessing [23:12:40 CEST] <GabrielYYZ> the other alternative is qdm2_tablegen.c #defining hardcoded_tables to 0 unconditionally [23:16:08 CEST] <kierank> reynaldo: ping [23:16:32 CEST] <reynaldo> kierank: pong, -> ffmpeg-opw [23:16:35 CEST] <kierank> how do I join [23:16:41 CEST] <reynaldo> you are there already [23:16:53 CEST] <kierank> my client just says "connecting" [23:17:04 CEST] <reynaldo> switch channel window in your IRC client I guess [23:27:37 CEST] <kierank> lglinskih: do you understand the response I emailed [23:31:26 CEST] <lglinskih> kierank: =)) yes, now it's absolutely clear [23:31:33 CEST] <kierank> ok :) [23:59:24 CEST] <cone-874> ffmpeg 03Chris Watkins 07master:0703c44692d1: avformat/mov.c: Use %d to print an enum, not PRIu8 [00:00:00 CEST] --- Wed Apr 22 2015

1 0

ffmpeg.log.20150421
by burek 22 Apr '15

22 Apr '15

[00:01:40 CEST] <kyleogrg> I downloaded a .tar.gz of the latest ffmpeg source. I have it in a virtual linux machine, and I want to compile it *for windows* [00:02:02 CEST] <kyleogrg> I'm looking at https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [00:02:25 CEST] <kyleogrg> And it wants me to compile a cross-compiler [00:02:27 CEST] <kepstin-laptop> kyleogrg, you want to be looking at https://trac.ffmpeg.org/wiki/CompilationGuide/CrossCompilingForWindows [00:02:45 CEST] <kepstin-laptop> should be able to use the packaged mingw64 stuff in ubuntu [00:02:56 CEST] <kyleogrg> sorry, that's actually what i meant to paste [00:03:24 CEST] <DusteD> kyleogrg, you usually does not have to compile the cross compiler for windows yourself, mingw for 64 or 32 bit windows should be available in your linux distributions package repository [00:03:33 CEST] <kyleogrg> hmmm [00:03:35 CEST] <DusteD> So slow I am [00:03:54 CEST] <kyleogrg> this is fairly complicated to me [00:04:33 CEST] <kyleogrg> so since i'm using linux mint (which is ubuntu based), i don't need to set up anything with mingw64? [00:04:46 CEST] <seasc> c_14, nope that doesnt work, ALSA is unable to open slave... ?? [00:04:51 CEST] <kepstin-laptop> kyleogrg, you'll have to install it, it's not installed by default. [00:04:58 CEST] <kyleogrg> ok, how? [00:05:25 CEST] <c_14> seasc: Is an X program accessing alsa perchance? [00:05:34 CEST] <kepstin-laptop> I think it should be enough to install either mingw-w64-x86-64-dev or mingw-w64-i686-dev for win64 or win32 respectively [00:06:02 CEST] <kepstin-laptop> maybe just the 'mingw-w64' metapackage is enough [00:07:04 CEST] <seasc> c_14, root ps shows only: /usr/sbin/alsactl ... [00:07:05 CEST] <kyleogrg> ok, thanks. trying mingw-w64-x86-64-dev [00:07:43 CEST] <c_14> seasc: lsof /dev/snd/pcm* [00:08:32 CEST] <seasc> c_14, n/m/ i assume i borked my alsa build during my live test of a full ffmpeg re-build... i've got several alsamixer issues anyway, probably the same cause [00:08:39 CEST] <seasc> thank you [00:09:16 CEST] <kyleogrg> ok, got mingw-w64-x86-64-dev! [00:09:44 CEST] <kyleogrg> after that, how can i cross-compile for windows? [00:10:11 CEST] <kepstin-laptop> kyleogrg, read the section of the wiki page saying "compile ffmpeg" :) [00:10:13 CEST] <kyleogrg> i'm hoping to enable 10-bit libx265 and libfdk_aac [00:10:28 CEST] <kepstin-laptop> if you want x265 and stuff it's more complicated :/ [00:11:20 CEST] <kyleogrg> hmm, how much more complicated? I'm willing to try, if you have the time [00:11:22 CEST] <seasc> oh ya, writing at a script (linux) to build ffmpeg with several features... for 3 weeks now... [00:11:24 CEST] <kyleogrg> otherwise, it's fine [00:11:36 CEST] <seasc> good luck :) [00:11:53 CEST] <kepstin-laptop> kyleogrg, each of the dependency packages has to be crosscompiled separately (and their build systems are all different, so it's different commands for each) [00:12:13 CEST] <kepstin-laptop> then they have to be "installed", best to use some subdirectory of your home directory for that [00:12:35 CEST] <kepstin-laptop> then set the PKG_CONFIG_PATH to find the pkg-config files for the dependencies, and try building ffmpeg with the appropriate options [00:13:00 CEST] <kyleogrg> ok wow [00:13:09 CEST] <kyleogrg> this is not for beginners [00:13:29 CEST] <kyleogrg> still, if i put the time into it, i bet i can do it [00:13:43 CEST] <kyleogrg> I just wish it was legal to download a nonfree ffmpeg [00:14:46 CEST] <kyleogrg> but the newest ffmpeg comes with libx265 already, right? [00:14:48 CEST] <kepstin-laptop> it's not so much illegal to download as illegal for someone to distribute to other people. but still, yeah. [00:15:15 CEST] <kepstin-laptop> it's kind of annoying since it's all open-source software, just with incompatible licenses. [00:15:39 CEST] <kyleogrg> what if i asked a friend to compile it for me, then send it to me? is that considered distribution? [00:16:26 CEST] <kyleogrg> haha, or am i splitting hairs? [00:16:27 CEST] <kepstin-laptop> ask a lawyer. [00:16:32 CEST] <kyleogrg> yeah. [00:16:35 CEST] <DusteD> kyleogrg, why not just download the binaries from the website ? [00:17:02 CEST] <kyleogrg> they don't have libfdk_aac nor 10-bit capability for libx265. [00:17:12 CEST] <DusteD> oh, I see. [00:17:24 CEST] <kepstin-laptop> is there some reason you *really* need aac? [00:18:00 CEST] <kyleogrg> hmm, it's just the best version [00:18:01 CEST] <kepstin-laptop> i mean, if you're just archiving this for yourself, you could use opus or something, or even just mp3 at a higher bitrate. [00:18:08 CEST] <kyleogrg> right [00:18:26 CEST] <kyleogrg> what about 10-bit? i think it's supposed to be higher quality at the same bitrate. [00:19:22 CEST] <DusteD> How could it be? :) [00:19:29 CEST] <kyleogrg> i dunno [00:19:30 CEST] <DusteD> I guess it'd be higher quality at a higher bitrate though [00:19:45 CEST] <kyleogrg> someone said it was better quality [00:19:52 CEST] <kyleogrg> maybe not, though? [00:19:54 CEST] <seasc> with x265 you get better quality for same bitrate as x264 [00:20:24 CEST] <kyleogrg> sure, i know [00:20:28 CEST] <seasc> otherwise as DusteD said, thats simply different mechanics [00:21:06 CEST] <kyleogrg> so 10-bit won't necessarily provide a smaller file size? [00:21:17 CEST] <kyleogrg> what do you mean by different mechanics? [00:21:31 CEST] <kepstin-laptop> in theory, the 10bit stuff can give better encoding efficiency, depends on the source material. IIRC, it's because there's less accuracy loss in predicted frames. [00:21:46 CEST] <c_14> You also lose less to quantization [00:21:50 CEST] <kepstin-laptop> also, it makes gradients encode without banding, yeah [00:22:13 CEST] <kepstin-laptop> ^ a visual sideeffect of the less quantization loss ;) [00:22:24 CEST] <kyleogrg> Say my source video is NTSC DV-AVI (from a DV camera) [00:22:44 CEST] <kyleogrg> Will there be a noticable visual improvement with 10-bit? [00:23:16 CEST] <kyleogrg> or could that banding issue only show up in HD video, for instance...? [00:23:31 CEST] <kepstin-laptop> kyleogrg, probably not, particularly with sd resolutions and real video rather than artificial/animated. [00:24:01 CEST] <kyleogrg> yeah.... [00:24:03 CEST] <kyleogrg> ok then [00:24:55 CEST] <kepstin-laptop> like, if your video is somewhat noisy and you're encoding with enough bitrate to keep the noise, then you probably don't care much about the small gain that 10bit might give you. [00:25:31 CEST] <kepstin-laptop> although, if you could do it easily, you might as well [00:25:36 CEST] <kyleogrg> right [00:25:49 CEST] <kyleogrg> i would like to know how to build ffmpeg anyway [00:25:53 CEST] <kyleogrg> i may just invest the time [00:26:13 CEST] <kyleogrg> it's just surprisingly complicated [00:26:43 CEST] <kyleogrg> it seems the simplest way is to cross-compile for windows. do you agree? [00:27:19 CEST] <kepstin-laptop> thats how i generally do it, but mostly because I don't like using windows for development. [00:28:23 CEST] <kepstin-laptop> (as an amusing note, I found that the 'gdigrab' screen capture stuff is *faster* in wine on linux than on real windows when I was working on that) [00:28:37 CEST] <kyleogrg> hahaha [00:28:39 CEST] <kyleogrg> strange [00:34:24 CEST] <kyleogrg> builds.x265.eu [00:35:06 CEST] <kyleogrg> what does 64Bit-16bit mean? [00:35:28 CEST] <c_14> Probably a 64-bit build that encodes 16bit video [00:36:00 CEST] <c_14> The 64-bit being the processer architecture and the 16 bit being the video bit-depth [00:36:05 CEST] <kyleogrg> ok, but i thought the options were either 8-bit or 10-bit [00:37:41 CEST] <kyleogrg> so is 16-bit "better"? [00:39:05 CEST] <kyleogrg> yeah.. i think "16-bit" uses 10 bits per pixel [00:39:14 CEST] <c_14> x264 has 8 and 10 not sure what x265 has [00:39:19 CEST] <c_14> Haven't built it in a while. [00:39:21 CEST] <kyleogrg> so i *think* it's the same as 10-but [00:39:22 CEST] <kyleogrg> bit [00:39:23 CEST] <kyleogrg> sure [00:39:28 CEST] <klaxa> i'm pretty sure 8, 10, 12 and 14 so far [00:39:32 CEST] <klaxa> never heard of 16 [00:39:52 CEST] <klaxa> but i have no source for that handy [00:40:03 CEST] <c_14> I mean, technically the more bits the less loss during quantization, but I don't know how well/far that scales. [00:40:30 CEST] <klaxa> remove 14 and add 16 https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles [00:40:52 CEST] <kyleogrg> huh [00:41:09 CEST] <kyleogrg> so on that site, 16-bit probably really is 16-bit [00:41:43 CEST] <klaxa> i can imagine that 8-bit has some whacky hacks to be faster [00:42:17 CEST] <kyleogrg> yeah [00:43:10 CEST] <kyleogrg> supposing i just encoded an x265 stream with the x265 binary... [00:43:24 CEST] <kyleogrg> i wonder if it uses all cpu cores [00:44:24 CEST] <c_14> iirc x265 threads [00:44:38 CEST] <c_14> doesn't really make it fast though [00:44:52 CEST] <kyleogrg> but technically a little faster [00:44:53 CEST] <kyleogrg> right? [00:45:20 CEST] <kyleogrg> i mean, maybe like 2 frames a second instead of 0.25 frames a second [00:45:21 CEST] <kyleogrg> haha [00:46:12 CEST] <c_14> Haven't tested in a whiiile, but last time I tried I couldn't get 1fps on my system. Granted I think I used profile veryslow [00:47:15 CEST] <kyleogrg> yeah [00:47:54 CEST] <kyleogrg> if i could find a simple way to encode the audio with libfdk_acc, i could mux it with the x265 streams made with this binary [00:49:29 CEST] <kepstin-laptop> if you're running windows anyways and *really* want aac, you could even do something as silly as encode it with itunes. [00:50:20 CEST] <kyleogrg> hmm [00:50:35 CEST] <kyleogrg> well at any rate, the x265 encoding is by far the slowest part of the process [00:50:49 CEST] <kyleogrg> very interesting [00:50:52 CEST] <kyleogrg> i have to go now [00:50:54 CEST] <kepstin-laptop> or you could just use opus, which has very comparable quality to aac. [00:50:55 CEST] <kyleogrg> may be back later [00:51:03 CEST] <kyleogrg> hmm all rightyy [00:51:28 CEST] <klaxa> isn't opus supposedly even "better" than aac? [00:51:34 CEST] <kepstin-laptop> if you're doing 10bit x265 it's not like you're worried about whether other people can decode it anyways [00:51:44 CEST] <kyleogrg> yes, good point [00:51:55 CEST] <kyleogrg> klaxa: do some say it's better? [00:52:06 CEST] <kepstin-laptop> klaxa, it's very close; but most of the comparisons were done at pretty low bitrate. [00:52:27 CEST] Action: c_14 compared aac and opus at 8k today [00:52:28 CEST] <klaxa> most comparisons are probably also performed by opus advocates [00:52:29 CEST] <c_14> opus won [00:52:31 CEST] <c_14> my ears hurt [00:52:39 CEST] <kyleogrg> okay [00:52:44 CEST] <kyleogrg> well gotta go [00:52:45 CEST] <kepstin-laptop> I mean, once you hit >128kbit in either opus or aac stereo, it's hard for a human to tell them appart from lossless either way... [00:52:47 CEST] <c_14> But at higher bitrates there isn't _that_ much difference. [00:52:50 CEST] <klaxa> well here's a chart http://www.opus-codec.org/comparison/quality.svg [00:53:06 CEST] <kyleogrg> thanks [00:53:07 CEST] <klaxa> aac and opus are pretty close [00:53:11 CEST] <kyleogrg> see ya later, bye [00:54:50 CEST] <klaxa> still somewhat frustrated google said android 5.x has opus support but their MediaPlayer api doesn't play opus files [00:55:19 CEST] <kepstin-laptop> hmm. looks like most of the webrtc streams I'm looking at are around 40-50kbit mono, which is ridiculously high quality for a phone call :) [00:55:42 CEST] <kepstin-laptop> klaxa, i guess they support the opus format but not the ogg opus container spec? :/ [00:56:08 CEST] <klaxa> you mean i could try to put opus in ogg? [00:56:21 CEST] <klaxa> i haven't tried that yet, nothing to lose really [00:56:22 CEST] <kepstin-laptop> klaxa, a standalone ".opus" file is opus in ogg. [00:56:28 CEST] <klaxa> oh [00:56:43 CEST] <klaxa> what [00:56:47 CEST] <klaxa> why don't they support that [00:56:53 CEST] <kepstin-laptop> no idea. [00:57:04 CEST] <kepstin-laptop> the spec for it isn't final tho, it's still a draft :/ [00:57:18 CEST] <kepstin-laptop> but the basic stuff isn't gonna change at this point [00:57:54 CEST] <benbro1> can I use ffmpeg to write a C application that mixes live audio and video RTMP streams? [00:58:07 CEST] <benbro1> the streams will change dynimcally in a video conference [00:58:59 CEST] <kepstin-laptop> benbro1, you could use ffmpeg to handle portions of the work required, but you'll obviously have to write some of your own stuff too. [00:59:15 CEST] <benbro1> kepstin-laptop: how hard is it? [00:59:32 CEST] <benbro1> I was trying to use gstreamer that is supposed to be good at this stuff [00:59:40 CEST] <benbro1> but keep running into issues [00:59:45 CEST] <kepstin-laptop> that's one of those "if you have to ask, then..." questions. [00:59:49 CEST] <benbro1> so I thought maybe I can go to a lower level [01:00:17 CEST] <benbro1> I mean, do I need to understand about threads, mutex, queues, buffering... [01:00:32 CEST] <benbro1> or does ffmpeg have tools that do it for me [01:01:47 CEST] <kepstin-laptop> my understanding (i could be wrong) is that the ffmpeg filter chain stuff doesn't handle dynamic rearrangement well, so you'd end up probably using ffmpeg to do the decoding/encoding and streaming, and you'd do the actual video mixing in your app. [01:02:34 CEST] <benbro1> so I'll need to handle buffers, queues, threads, synching.... [01:02:57 CEST] <kepstin-laptop> using ffmpeg as a library is quite a bit different from using the command line tool; the tool handles a lot of things that you have to do yourself if you use the libraries. [01:03:47 CEST] <benbro1> it's such a powerfull tool that I would expect it to expose this power to us in a library :) [01:07:23 CEST] <klaxa> oh, looks like android supports opus in matroska [01:07:34 CEST] <klaxa> what the actual fuck [01:08:45 CEST] <kepstin-laptop> lol [01:08:53 CEST] <kepstin-laptop> does it work if you rename your .opus file to .ogg? [01:09:16 CEST] <klaxa> rename or remux? i mean ffprobe reports it as ogg anyway [01:09:28 CEST] <c_14> rename, probably [01:09:28 CEST] <kepstin-laptop> the matroska mapping for opus was under even more flux than the ogg mapping, since they had to add new stuff to matroska to handle the preroll required on seeking [01:09:59 CEST] <klaxa> renaming opus to ogg does not work [01:10:24 CEST] <kepstin-laptop> I think they might have put the opus in matroska stuff because they want to use opus+vp9 in the next webm version. [01:11:27 CEST] <klaxa> well it's not like i really care about containers as much as codecs [01:11:44 CEST] <klaxa> i'll just use matroska for the time being [01:12:23 CEST] <kepstin-laptop> I hope when they do make a new version of webm, they call it something different, otherwise people will be going "it's a webm, and this player says it does webm, why doesn't it work?" [01:13:00 CEST] <kepstin-laptop> half the point of the webm standard was to limit the codecs so much the files would be pretty much guaranteed to play. [01:13:43 CEST] <klaxa> mkv is 50 kb larger than ogg [01:13:47 CEST] <klaxa> i can live with that [01:14:12 CEST] <klaxa> >Duration: 00:03:37.14, start: 0.000000, bitrate: 126 kb/s [01:14:25 CEST] <klaxa> as a scale reference [01:14:47 CEST] <klaxa> >3475550 Apr 21 01:10 test.mkv [01:31:10 CEST] <hroi> hi [01:31:47 CEST] <hroi> someone suggested I use ffmpeg to encode my avi raw file over to H264 using the CRF option [01:32:08 CEST] <hroi> the suggestion is that the resulting file will play more smoothly on video players and youtube [01:33:09 CEST] <klaxa> youtube will re-encode your video multiple times anyway [01:33:43 CEST] <hroi> klaxa, ok, so essentially throwing the raw at youtube might be the best thing anyway [01:34:00 CEST] <hroi> klaxa, I hear that sending H264 to youtube will leave the encoding unchanged [01:34:11 CEST] <klaxa> they encoded my h264 videos anyway [01:34:13 CEST] <hroi> that must be a misunderstanding [01:34:21 CEST] <hroi> klaxa, ok. [01:34:46 CEST] <hroi> klaxa, hmm... so sending the raw to youtube will probably ensure best results by far [01:34:48 CEST] <c_14> As long as the FrankenFFmpeg that Youtube uses can decode the raw, that would probably be the best bet, yes. [01:35:10 CEST] <hroi> klaxa, c_14 : thanks for clearing that up [01:35:11 CEST] <klaxa> if you want to save bandwith you might also want to consider using a lossless format [01:35:18 CEST] <klaxa> but that will take a while to encode maybe [01:35:43 CEST] <hroi> my file is only 3GB in avi raw, so probably youtube wont complain [01:37:00 CEST] <hroi> insidentally... my raw is 3GB for 50s of video, but on my current linux install 4 core phenom II processor, vlc does not keep up with buffering the video [01:37:21 CEST] <c_14> It might be IO [01:37:24 CEST] <hroi> maybe that is expected, but I was hoping my computer was more powerful than that [01:38:46 CEST] <klaxa> it's like 500 mbps [01:38:51 CEST] <hroi> c_14, I think it is maybe not disk IO because vlc buffers up to 3GB of memory usage [01:39:00 CEST] <klaxa> how fast is ram? [01:39:05 CEST] <hroi> lol [01:39:14 CEST] <klaxa> actually should be faster than 500 mbps [01:39:15 CEST] <hroi> 1.3GHz [01:39:34 CEST] <hroi> dual channel 64bit data bus [01:39:39 CEST] <klaxa> i would still guess it's io [01:39:43 CEST] <hroi> or is it actually 128bit? [01:40:43 CEST] <hroi> klaxa, yeah seems like that -- oh well. I should run some benchmarks on my linux to test if all is ok [01:40:58 CEST] <hroi> thanks for advice! [01:41:06 CEST] <c_14> If it's really 3GiB for 50s, you can always just encode to a lossless format. [01:41:18 CEST] <c_14> s/format/codec/ [04:31:59 CEST] <kyleogrg> yo [04:32:04 CEST] <kyleogrg> help me out here please [04:32:07 CEST] <kyleogrg> https://web.archive.org/web/20140819201525/http://gcc.gnu.org/onlinedocs/gc… [04:32:55 CEST] <kyleogrg> My processor is: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz 2.20Ghz [04:33:28 CEST] <kyleogrg> Basically I can choose one of these presets in my ffmpeg build [04:34:08 CEST] <kyleogrg> Here's the ffmpeg autobuild tool I'm using: http://taer-naguur.blogspot.com/2013/10/ffmpeg-autobuild-tool-x64.html [04:34:35 CEST] <kyleogrg> And I have the option to optimize it by giving it a custom cpu type... any input? thanks [09:57:11 CEST] <livee> hello chan [09:57:27 CEST] <livee> still here with an audio/video desync [09:57:43 CEST] <livee> just to know if anyone would know how to help me [09:58:21 CEST] <livee> i give the link of the forum subject i posted but i try here because last time it was fast [09:58:33 CEST] <livee> sorry for my english [09:58:34 CEST] <livee> http://ffmpeg.gusari.org/viewtopic.php?f=11&t=2056 [10:22:25 CEST] <livee> up [12:11:46 CEST] <rszeno> i'm not sure if this is the right place to ask but i will, :) [12:13:26 CEST] <rszeno> i use ffmpeg to extract the video part from a movie and is bigger then the original. Is not compressed? [12:32:08 CEST] <BtbN> If you re-encode with a "higher" quality or use a less efficient container for the output, that's entirely possible. [12:33:19 CEST] <rszeno> i used only -sameq and -an flags [12:34:44 CEST] <rszeno> i use the libav port from debian in fact. From this point of view is any difference? [12:34:58 CEST] <BtbN> From this point of view you're in the wrong channel. [12:36:02 CEST] <rszeno> if ffmpeg, right? i didn't changed the name and actualy i found the difference accidentaly [12:37:36 CEST] <rszeno> but the question remain. if i use ffmeg and not libav, is any difference in size? [12:40:10 CEST] <BtbN> If you don't tell it to stream-copy, it will allways re-encode. And without furhter parameters, use the default ones, which might or might not result in a higher bitrate. [12:41:33 CEST] <rszeno> ok, thank you BtbN, :) [14:40:46 CEST] <ph8> hey all, i'm calling ffprobe from scala and getting an exit code of 1 - with no stderr and stdout just as {} - any idea how i can try and diagnose that? If i run the command from the CLI it's fine which is weird [14:43:20 CEST] <spaam> maybe you didnt sent any input to ffprobe ? [14:45:45 CEST] <cowai> Is it possible to apply fade in and fade out, video and audio, with stream copy on the parts of the video which are not edited? [14:46:00 CEST] <cowai> If not, can I do it in 3-4 commands and still be frame accurate? [14:50:56 CEST] <ph8> spaam, the command is: /usr/bin/ffprobe -v quiet -print_format json -show_format -show_streams "/home/george/repos/myproject/target/scala-2.11/test-classes/asset/testVideo.mp4" [14:51:10 CEST] <ph8> which works fine from the cmd line but not when executed in scala, it claims an error code of 1 came back [14:51:17 CEST] <ph8> and an output of {} which at least looks ffmpeg-y [14:51:25 CEST] <ph8> i just have no idea how to debug any further [14:51:49 CEST] <ph8> hahaaha got it [14:51:52 CEST] <ph8> removing -v quiet helped :) [14:51:57 CEST] <spaam> :) [14:52:03 CEST] <ph8> it doesn't appear to like the quotes in the directory [14:52:05 CEST] <ph8> which is mega odd [15:08:58 CEST] <ph8> what i'm finding odd now is that ffmpeg always outputs a header to stderr [15:08:59 CEST] <ph8> even on success [15:11:09 CEST] <urmumstty> ffmpeg shits almost everything (everything?) to stderr [15:11:27 CEST] <urmumstty> probably following the idea that there is no point in putting status information into stdout [15:12:11 CEST] <urmumstty> if you were piping video data out of ffmpeg you wouldn't want status info coming through [15:12:49 CEST] <seasc> urmumstty, try: ffmpeg -v quiet .... [15:12:59 CEST] <urmumstty> seasc: was responding to ph8 [15:13:12 CEST] <seasc> erm, me too i guess :p [15:13:58 CEST] <seasc> you want a silent ffmpeg with only the output you need/want? (on linux??) [15:14:01 CEST] <seasc> @ ph8 [15:14:27 CEST] <ph8> thanks [15:14:30 CEST] <ph8> i found a weird thing with ffmpeg [15:14:51 CEST] <ph8> sorry with scala [15:15:03 CEST] <ph8> and the way it treats quotes in command lines [15:15:15 CEST] <ph8> those double quotes were really confusing scala but obviously ran fine from my bash prompt [15:29:02 CEST] <__deivid__> Hi [15:32:23 CEST] <seasc> hi [15:39:29 CEST] <neXyon> hi [15:40:57 CEST] <neXyon> does -qp only work for h264 or other video codecs as well? [16:02:24 CEST] <t4nk264> How to deal with "double audio" on TGL's tops. [16:02:36 CEST] <t4nk264> Can you please point out some links [19:31:30 CEST] <kyleogrg> hey [19:31:56 CEST] <kyleogrg> I have an ffmpeg command ready to convert avis to mp4s [19:32:12 CEST] <kyleogrg> now i'd like to generate this command for every avi in a folder [19:33:09 CEST] <kyleogrg> let's say the command is: ffmpeg.exe -i myfile.avi -c:v libx264 -c:a libfdk_aac myfile.mp4 [19:33:42 CEST] <kyleogrg> How can I change the command to take every avi and output an mp4 with the same name? thanks [19:55:22 CEST] <RobotsOnDrugs> shells have syntax for that kind of thing [19:55:57 CEST] <kyleogrg> this looks helpful: http://forum.videohelp.com/threads/356314-How-to-batch-convert-multiplex-an… [21:04:59 CEST] <Fyr> guys, I need assistance with LameXP. [21:05:46 CEST] <Fyr> does anybody know something about this tool? [21:30:09 CEST] <Fyr> it happened that my question is really about refalac/qaac, not about lamexp. [21:56:04 CEST] <deb_> hi [00:00:00 CEST] --- Wed Apr 22 2015

1 0

ffmpeg-devel.log.20150420
by burek 21 Apr '15

21 Apr '15

[00:53:24 CEST] <BBB> nalply: yes [00:53:28 CEST] <BBB> (I guess hes gone) [00:58:06 CEST] <Compn> hmmm ... Unrecognized option 'er'. [00:58:25 CEST] <Compn> oh its -ec 0 [00:58:27 CEST] <Compn> nevermind [02:59:34 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:c253340ae6f7: log: Introduce a more verbose debug level [02:59:34 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:8e8219e0f072: Merge commit 'c253340ae6f74ffd8798bbd476e46d1b33a2d56e' [03:32:11 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:1a3eb042c704: Replace av_dlog with normal av_log at trace level [03:32:12 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:40d552dae657: Merge commit '1a3eb042c704dea190c644def5b32c9cee8832b8' [03:52:48 CEST] <rcombs> http://hlsvod-l3c.med3.hbonow.com/hls/2015/04/13/a5e6bd49-4d7f-4efd-8066-d9… has anyone been looking for an HLS SAMPLE-AES sample? [04:03:09 CEST] <rcombs> or, nope, it's something that claims to be SAMPLE-AES but apparently is actually FlashAccess [04:28:21 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:6a85dfc830f5: lavc: Replace av_dlog and tprintf with internal macros [04:28:22 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:8f7b022c8c2f: Merge commit '6a85dfc830f51f1f5c2d36d4182d265c1ea3ba25' [04:28:23 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:0a582aeee41d: avcodec: fix build with DEBUG/TRACE [04:28:24 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:dbd94b771f1b: avcodec/internal: Fix ff_dlog() define like av_dlog() [04:40:04 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:17aa81d94781: hqx: Merge invalid format check within switch block [04:40:05 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:ea031b75fb50: hqx: Move DSP related code to a separate file [04:40:06 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:73e6af9d7b56: Merge commit '17aa81d94781c6f62dc7d1dbd1f8891c020c9905' [04:40:07 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:d8b4e9adbb93: Merge commit 'ea031b75fb50c59196ccb654c9d143fb75365da9' [05:04:30 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:453642f8afe9: hqx: Store shareable data in main decoder context [05:04:31 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:55b866f61858: Merge commit '453642f8afe9f979fcc813a246b1ec656ec36a93' [05:18:48 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:5b5338f6d127: hqx: Implement slice-threaded decoding [05:18:49 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:1fa7d0902c3e: Merge commit '5b5338f6d1272526d2634501555cbaff4cdfb87b' [05:27:41 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:fcda30f2dcb7: fate: Prefix cllc tests with canopus [05:27:42 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:e6fb844f7b73: Implement shared parsing of INFO tag in Canopus family [05:27:43 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:f1db984288f2: Merge commit 'fcda30f2dcb744d89df9d5d1ec89ba55279cb83c' [05:27:44 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:fcca7671e29b: Merge commit 'e6fb844f7b736e72da364032d251283bce9e63ad' [05:51:52 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:22526c1f557a: Canopus HQ/HQA decoder [05:51:53 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:5a284d076ffd: Merge commit '22526c1f557a72b3285d295bd8b30c40eb65d437' [05:59:12 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:376589e5dd72: mov: Read alternate absolute path in dref alis [05:59:13 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:82d9c4e5789c: Merge commit '376589e5dd72aa2dd42500f456fca303fcdcad85' [06:13:57 CEST] <Zeranoe> ffmpeg.zeranoe.com is down right now because I added SSL and the IP changed. This should be reflected in the DNS shortly and it will be back up. [06:16:17 CEST] <Compn> ok [06:48:52 CEST] <hasher> whats the format of time in the vstats_file ? [07:03:38 CEST] <hasher> hello ! [07:04:42 CEST] <philipl> Th [07:07:05 CEST] <hasher> whats the format of time in the vstats_file ? [07:07:18 CEST] <hasher> can somebody explain please [07:10:16 CEST] <hasher> http://stackoverflow.com/q/29739674/3444930 [07:15:12 CEST] <jamrial> hasher: 1.000 is one second [07:16:24 CEST] <hasher> 23238.835 how about this? [07:18:44 CEST] <hasher> becuase the complete file is 20s [07:18:50 CEST] <hasher> only [11:11:38 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:9286de045968: mov: Double-check that alias path is not an absolute path [11:11:39 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:4d50d53a6d60: Merge commit '9286de045968ad456d4e752651eec22de5e89060' [11:14:06 CEST] <__Shimo__> ffmpeg doesn't support art embedding into m4a. [11:14:12 CEST] <__Shimo__> shame on you! [11:16:09 CEST] <deepak__> can anyone help me on how to build a command line option? [11:26:41 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:4d593896aaa8: vc1_pred: Always initialize px and py in ff_vc1_pred_mv_intfr() [11:26:42 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:127f7aa401c9: Merge commit '4d593896aaa81356def8993e8c52294bd8bb2797' [11:38:17 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:0251c9be5a9d: motion_est: Fix warning from zero_cmp() assignment [11:38:18 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:3d71b1f8f09f: mpegvideo_enc: Simplify picture allocation [11:38:19 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:924a77fb4e82: Merge commit '0251c9be5a9d79cb669e97086a82dc4d44a917b0' [11:38:20 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:fc83ff80b438: Merge commit '3d71b1f8f09fccea7158e868fb9bd81b81205449' [11:48:24 CEST] <cone-905> ffmpeg 03Andreas Cadhalpun 07master:09bd7ddf2002: aacdec: consistently use avctx for logging in decode_eld_specific_config [11:48:25 CEST] <cone-905> ffmpeg 03James Almer 07master:a1d58e3b386c: avutil: remove pointless bmi1 define [11:48:26 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:a22da5e66903: Merge commit '09bd7ddf2002562befa15a2a4d065b79ad14ed8e' [11:48:27 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:94914d690990: Merge commit 'a1d58e3b386cc0bfe16abd9ccee4eed182b7e354' [12:00:07 CEST] <cone-905> ffmpeg 03Himangi Saraogi 07master:88d1fb4e3f15: filtfmts: Avoid null pointer dereference [12:00:10 CEST] <cone-905> ffmpeg 03Eric Zimmerman 07master:eb31256f12bf: g2meet: Support G2M5 codec variant [12:00:11 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:57f49fa0edaf: Merge commit '88d1fb4e3f156d8fd5bb6cb3ba3a9ef1e6d6fb08' [12:00:12 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:0796a2ab4ff5: Merge commit 'eb31256f12bf0c85aded1612551ce9230356879e' [12:45:51 CEST] <cone-905> ffmpeg 03Federico Tomassetti 07master:336d2f0979b4: avplay: Free frame and graph when memory allocation fails [12:45:52 CEST] <cone-905> ffmpeg 03Federico Tomassetti 07master:617814b4a717: buffersrc: Fix resource leak on error [12:45:53 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:eb8756e4b7f9: Merge commit '336d2f0979b43a39bd11a047d798b7990d8b07c6' [12:45:54 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:0c9e78caf4ed: Merge commit '617814b4a717b38add5ccb8dd200dbb655f98f09' [12:45:55 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:a6df9ce61520: avfilter/buffersrc: Use correct, matching deallocation function [12:59:50 CEST] <cone-905> ffmpeg 03Federico Tomassetti 07master:386e2755aab7: jack: Check memory allocation [12:59:51 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:1c667626bbbf: Merge commit '386e2755aab73ae7075f78d92786cb5c5419597a' [13:23:03 CEST] <nalply> I am doing `make fate` on the most current version "N-71567-g1c66762" pulled directly from git. The test mapchan-6ch-extract-2 fails on my OS X Yosemite. As I said yesterday I would like to implement avdevice_list_devices() for OS X AVFoundation. [13:49:27 CEST] <BBB> nalply: yes I wrote ffvp9 (with ubitux) [13:49:57 CEST] <BBB> nalply: and the blog post also (with ubitux and nevcariel) [13:50:58 CEST] <BBB> nalply: if the test fails, its possible you dont have the samples, did you run make fate-rsync? [13:51:11 CEST] <BBB> and did you configure with --samples=/path/to/samples? [13:54:39 CEST] <nalply> BBB: I have a configuration mismatch, my bad. [14:37:29 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:09b0f227ce6f: avcodec/flacenc: also count wasted bits in subframe_count_exact() [14:37:30 CEST] <cone-905> ffmpeg 03Ludmila Glinskih 07master:be70c79af2bb: libavcodec: Add FLAC API test [14:37:31 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:2a00ef5d8181: avcodec/api-flac-test: clear callers context with close_* [14:57:30 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:42d6d249b0f9: avutil/mips/generic_macros_msa: volatile doesnt need __ [15:06:09 CEST] <kierank> erm [15:06:17 CEST] <kierank> I haven't actually reviewed the patch yet [15:06:30 CEST] <kierank> (it's not easy to review patches on a phone) [15:07:04 CEST] <wm4> the api test one? neither have I (the latest version of it) [15:07:41 CEST] <BBB> (whats the point of the api test anyway? [15:07:59 CEST] <wm4> to test the API [15:26:20 CEST] <Daemon404> BBB, api break happens all the time, but is never caught cause ffmpeg has workarounds or doesnt use the functionality [15:26:25 CEST] <Daemon404> it's a constant source of annoyance [15:26:38 CEST] <Daemon404> (especially with carl regurgitating "please only reproduce with ffmpeg cli" on the bug tracker) [15:27:12 CEST] <BBB> we have a public flac api? [15:27:37 CEST] <Daemon404> i mena in general. no idea about flac specifically. [15:27:43 CEST] <Daemon404> just telling you the idea behind it. [15:27:46 CEST] <BBB> right [15:27:48 CEST] <BBB> I know api tests [15:27:55 CEST] <BBB> I just dont udnerstand why we need a *flac* api test [15:27:56 CEST] <Daemon404> i always called them unit tests [15:27:59 CEST] <BBB> right [15:28:17 CEST] <BBB> (I worked in corporate america, Im all too familiar with all that cruft) [15:28:27 CEST] <BBB> (especially when people get overly zealous and forget the point of such tests) [15:28:32 CEST] <Daemon404> i think a small amount of unit tests are very good [15:28:37 CEST] <Daemon404> not TDD crap though [15:28:49 CEST] <nevcairiel> TDD is kinda fun [15:28:58 CEST] <BBB> the tests need to be written by knowledgeable people and need to be useful in that they catch anticipated breakages [15:29:11 CEST] <Daemon404> its kinda late for ffmpeg yes [15:29:13 CEST] <BBB> most such tests are written by idiots who see a coverage chart [15:29:21 CEST] <Daemon404> but if you start with a "new featuresn need tests" [15:29:23 CEST] <Daemon404> then its fine [15:29:24 CEST] <BBB> (in corporate america; not talking about ffmpeg here) [15:29:26 CEST] <rcombs> I enjoy when TDD is taken to the point where the resulting software passes the tests perfectly, but doesn't even try to handle any edge cases [15:29:47 CEST] <rcombs> "well it works for the test-case input" [15:29:48 CEST] <nevcairiel> then you did TDD wrong [15:29:49 CEST] <BBB> tdd is good if the test is good [15:29:54 CEST] <BBB> but anyway [15:29:57 CEST] <rcombs> "crashes if you give it anything else, but it works for the test input" [15:30:07 CEST] <BBB> hehe [15:30:36 CEST] <rcombs> nevcairiel: clearly, but it's still amusing [15:30:48 CEST] <nevcairiel> the whole point of TDD is to write down a test for every edge case once you think of it or find it, if you just write tests for "proper" input, then its a pointless undertaking =p [15:33:23 CEST] <BBB> nevcairiel: I thought you needed both [15:33:39 CEST] <BBB> e.g. write edge tests and write feature tests (like conformance tests [15:34:13 CEST] <BBB> since theyre sort of the same thing; a feature is an edge case you want to work; an bug is an edge case you dont want to crash or so [15:34:19 CEST] <nevcairiel> well of course, you start with a test for proper input, then write the function until it passes on proper input .. then write bad input, and fix the code until that gives you defined behaviour as well [15:45:07 CEST] <BBB> very corporate :) [15:45:34 CEST] <nevcairiel> corporate doesnt have time for TDD [15:45:52 CEST] <nevcairiel> corporate is "just write code" :p [15:46:06 CEST] <nevcairiel> "code failed after a month" - "lets write tests" [15:49:21 CEST] <BBB> I guess your corporate was different from mine :-p [15:50:22 CEST] <nevcairiel> maybe, my corporate doesnt have time for any best practices, or any practices really, just need to produce code fast, and only if stuff goes wrong you pretend to care about quality =p [15:50:50 CEST] <BBB> or just say its a feature [15:54:19 CEST] <kierank> BBB: flac is basically a nice place for a student to learn about the API [15:54:27 CEST] <kierank> but yes eventually it'll test things that ffmpeg.c can't test [15:54:35 CEST] <kierank> e.g draw_horiz_band, crazy seeking etc [15:54:49 CEST] <nevcairiel> what even uses draw_horiz_band, cant we just delete that =p [16:00:20 CEST] <BBB> I tihnk its useful for low-latency and for in-cache type use cases [16:00:29 CEST] <BBB> its not entirely crazy [16:00:52 CEST] <BBB> although obviously for modern codecs with delay like hevc/h264/mpeg it doesnt help much [16:01:49 CEST] <wm4> for low-latency, wouldn't it be better to have an API that can actually return a frame once it's decoded? [16:01:52 CEST] <wm4> instead of forced delay [16:01:58 CEST] <wm4> with frame threading [16:02:03 CEST] <wm4> (as I understand) [16:02:24 CEST] <nevcairiel> if you need low latency, you shouldnt have frame threading, even with such an API it will potentially have a higher latency [16:12:25 CEST] <BBB> wm4: avctx->flags |= CODEC_FLAG_LOW_DELAY; [16:12:34 CEST] <BBB> wm4: that already works for most codecs (not hevc though) [16:19:44 CEST] <kierank> nevcairiel: it's useful for example when I need to pack to v210 for hardware output [16:21:00 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:1ca805264059: avcodec/parser: Remove duplicate header inlcude [17:14:11 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:8a91ee783710: avformat/avidec: Do not call av_log() per byte, use ff_tlog() [17:14:12 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:d02b3e9bdbd7: avformat/utils: Provide context for av_log() where one is available [17:14:13 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:84b95715fa26: avformat/utils: Place timestamp trace logs under FF_FDEBUG_TS [17:50:05 CEST] <wm4> is there a way to make ffmpeg.c use different seek flags with -ss ? [17:50:13 CEST] <wm4> I guess not, fuck using ffmpeg.c for testing [18:29:11 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:e48a0a6c3fda: avformat/mov: remove per packet timestamp print trace, theres generic code doing this in utils.c [18:29:12 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:d4cf377947d6: avformat/mux: Place timestamp related trace av_logs under FF_FDEBUG_TS [18:29:13 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:57865a974780: avformat/mpeg: put timestamp trace av_logs under FF_DEBUG_TS [19:52:52 CEST] <BtbN> https://github.com/BtbN/FFmpeg/blob/master/libavfilter/vf_chromakey.c#L41 is there some problem with this calculation? I feel like i'm getting the wrong pixels [19:58:27 CEST] <wm4> hm, I don't see anything immediately wrong with it [19:59:03 CEST] <BtbN> It assumes YUV(A)420 [19:59:09 CEST] <wm4> "frame->data[3][frame->linesize[0] * y + x] = a * 255.0;" [19:59:14 CEST] <wm4> this does look wrong, though [19:59:32 CEST] <BtbN> oh, yeah. [19:59:44 CEST] <BtbN> Shouldn't matter too much for the outcome, but definitely wrong. [20:00:24 CEST] <BtbN> I'll just set the entire color to the distance i calculcated, maybe i'll be able to thinkg of what goes wrong then... [20:57:44 CEST] <kierank> michaelni: thanks for commiting opw patch without review [20:59:03 CEST] <michaelni> kierank, dont troll [21:00:10 CEST] <michaelni> kierank, as mentor its your job to review and you didnt do it so i did it as its a few hours before the deadline [21:00:23 CEST] <michaelni> and thats the "us asking for extension" deadline [21:00:33 CEST] <michaelni> the actual deadline was last friday [21:00:37 CEST] <michaelni> IIRC [21:02:14 CEST] <kierank> it can be reviewed without committing [21:02:24 CEST] <kierank> and if I wasn't on a phone I would review [21:04:09 CEST] <Daemon404> drama.jpg [21:04:14 CEST] <Daemon404> or rather, drama.flac [21:37:51 CEST] <wm4> michaelni: is that mp3 patch based on the one I sent earlier this day? because you changed the fate ref file [21:38:03 CEST] <michaelni> wm4, yes [21:38:15 CEST] <wm4> ah, ok [21:45:59 CEST] <cone-905> ffmpeg 03wm4 07master:bac7084fbd37: ffmpeg: add option not to offset seek position by start time [21:46:00 CEST] <cone-905> ffmpeg 03wm4 07master:1e2e22ec616b: fate: gapless: fix mp3 tests [21:52:39 CEST] <cone-905> ffmpeg 03Martin Storsjö 07master:2cc3936599b6: dashenc: Add a publishTime field in dynamic manifests [21:52:40 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:5a14fca9aaca: Merge commit '2cc3936599b6fc63143036659653d1be0624360f' [21:54:50 CEST] <Fyr> guys, I ought to say that ffmpeg doesn't support m4a metadata and it sucks. [21:55:53 CEST] <wm4> it should support that to some degree [21:56:01 CEST] <wm4> otherwise, send sample file or go away [21:56:13 CEST] <Fyr> cover image isn't supported. [21:56:21 CEST] <Fyr> maybe other tags are. [21:56:22 CEST] <wm4> sample file [21:56:30 CEST] <Fyr> ok [21:57:00 CEST] <Fyr> I'll post official bug report. [22:09:21 CEST] <cone-905> ffmpeg 03Thomas Guillem 07master:b18346817d57: flac: fix realloc loop with invalid flac files [22:09:22 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:a5379d6e68cb: Merge commit 'b18346817d57c96cc47811cf78b26653e96bd304' [22:18:42 CEST] <cone-905> ffmpeg 03Luca Barbato 07master:656e31ed8728: ogg: Forward errors further [22:18:43 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:3cd6f4546ad9: Merge commit '656e31ed8728b0c095d037dc9764fc8137c87200' [22:32:49 CEST] <cone-905> ffmpeg 03Luca Barbato 07master:d34039b171be: rmenc: Drop the temporary buffer for ac3 byteswap [22:32:50 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:d108820c2e20: Merge commit 'd34039b171bebe37bf723a1b03e5651267099739' [22:39:18 CEST] <cone-905> ffmpeg 03Timothy Gu 07master:3b1e35d46dc9: fate: Omit the results if the test passed [22:39:19 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:a570e81234f7: Merge commit '3b1e35d46dc910cef1d66f6964e6800cae5fc89b' [22:47:51 CEST] <cone-905> ffmpeg 03Diego Biurrun 07master:338ed3ed33c4: ffv1: Pass correct pointers to av_free() [22:47:52 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:e6831c087e49: Merge commit '338ed3ed33c412c2828446c4e2a76949161fec6a' [23:00:21 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:86e1a35802df: h264_ps: Return meaningful error codes and address a memory leak [23:00:22 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:037c9c25e621: Merge commit '86e1a35802df42f51337d3fed8d5d99d0898c8bf' [23:13:31 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:98cab3979861: lavf: Fix variables constness in ff_iso8601_to_unix_time() [23:13:32 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:5380c9afb9a2: Merge commit '98cab39798612dcaea4f9b6d1e7974bc60d84e13' [23:20:26 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:1746dc382ddb: hqxdsp.h: #include "stddef.h" [23:20:27 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:2f8f5027ad6f: Merge commit '1746dc382ddbf3f8a3f039815644f7eb9076110e' [23:29:29 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:bd5ad8b23d0f: hq_hqa: Fix reading hqa quantization matrix index [23:29:30 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:1a41415b2adc: Merge commit 'bd5ad8b23d0f7d469ca30d03deca879993eb0431' [23:50:29 CEST] <cone-905> ffmpeg 03Vittorio Giovara 07master:eaa2d123f0a6: log: Print a full backtrace along with error messages under Valgrind [23:50:30 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:954b5e340e8e: Merge commit 'eaa2d123f0a643664721593d248ece6bcd85f1e6' [00:00:00 CEST] --- Tue Apr 21 2015

1 0

ffmpeg.log.20150420
by burek 21 Apr '15

21 Apr '15

[03:58:58 CEST] <Muchoz> Can someone tell me why I'm getting "[swscaler @ 0x7f8c9d038600] deprecated pixel format used, make sure you did set range correctly" here: http://hastebin.com/igiqohuzif.bash [03:59:12 CEST] <Muchoz> Doesn't matter what I set it to, it doesn't change. [03:59:30 CEST] <Muchoz> And it's not outputting the file. [04:00:46 CEST] <Muchoz> I've literally searched for 2 hours now and I'm done, it's 4AM and I want to finish this before going to sleep so I can convert the videos while I sleep. [04:28:18 CEST] <jookiyaya> which aac encoder is best? [04:33:30 CEST] <dsl420> i use libfdk_aac [04:34:04 CEST] <jookiyaya> better yet, which audio encoder is best [04:36:50 CEST] <jookiyaya> and what is this? libtwolame [04:38:45 CEST] <dsl420> i would say it depends, but i like flac. lame might be mp3 stuff, afaik [04:39:40 CEST] <jookiyaya> libmp3lame [04:41:39 CEST] <dsl420> "enable MP2 encoding via libtwolame", easy to investigate though [04:44:21 CEST] <rcombs> Opus is supposed to be the best lossy codec around these days, for pretty much anything [04:44:43 CEST] <rcombs> as for AAC, Apple's is tops, then FDK [04:46:04 CEST] <jookiyaya> i don't see apple's aac on ffmpeg [04:46:50 CEST] <jookiyaya> what is lib name for apple-aac [04:47:13 CEST] <rcombs> ffmpeg doesn't support it [04:47:38 CEST] <rcombs> it's part of QuickTime; "qaac" is apparently what people use it via [04:47:52 CEST] <rcombs> FDK is a close second and far less of a pain to work with, though [04:48:09 CEST] <rcombs> (but it's nonfree so no redistributing binaries with it) [04:48:38 CEST] <jookiyaya> how come i never saw FDK-aac until recently [06:13:59 CEST] <Zeranoe> ffmpeg.zeranoe.com is down right now because I added SSL and the IP changed. This should be reflected in the DNS shortly and it will be back up. [06:47:47 CEST] <hasher> hello [06:48:07 CEST] <hasher> anybody know what is the format of FFMPEG --vstats_file [06:48:24 CEST] <hasher> i mean about the time format in there . [06:53:52 CEST] <hasher> whats the format of time in the vstats_file ? [07:10:20 CEST] <hasher> http://stackoverflow.com/q/29739674/3444930 [08:08:07 CEST] <abnegate> i'm trying to configure ffmpeg 2.6.2 to use jack as an output, but when i type "./configure --list-outdevs", jack is not listed [08:08:25 CEST] <abnegate> i have jack installed in a non-standard location, so maybe that's why ffmpeg is getting confused [08:08:51 CEST] <abnegate> how can i tell ffmpeg to build with jack support? and how to tell it about my non-standard jack location? [08:45:02 CEST] <gilbahat> Hi, has anyone here managed to compile ffmpeg with nvenc support? id love to try it, but the nvidia nvenc SDK is nothing short of broken and badly documented to boot. no obvious way to install it, no makefiles, no nothing... [08:59:08 CEST] <Karaliov> how does ffmpeg calculate pts values for PES packets? [09:00:45 CEST] <Karaliov> i have a stream which has avpacket->duration == 9000, but the actual differenes between PTS values in a video file fluctuate from 8600 to 9200 or so [10:29:32 CEST] <kevmitch> is there any way to tell ffmpeg to use dcadec by default without manuall specifying it for each input. [10:29:55 CEST] <kevmitch> ffmpeg -c:a dcadec -i file.mkv ... will break if there are non dts audio tracks [10:30:17 CEST] <kevmitch> so I'm forced to figure out specifically which are dts and specify them [10:30:28 CEST] <kevmitch> ffmpeg -c:1 file.mkv ... [10:30:54 CEST] <kevmitch> assuming that the stream 1 is dca [10:33:57 CEST] <kevmitch> sorry, the first command is "ffmpeg -c:a libdcadec file.mkv ..." [10:34:08 CEST] <kevmitch> and the the seconde "ffmpeg -c:1 libdcadec file.mkv ..." [10:40:26 CEST] <BtbN> ffmpeg should be able to figure out what codecs are in a container. [10:40:38 CEST] <BtbN> If it fails for some file, please upload a sample and open a ticket. [10:46:05 CEST] <kevmitch> so it's a bug that it overrides non-dts streams when I specificy -c:a libdcadec before the input file? [10:46:35 CEST] <kevmitch> i.e., Stream #0:1[0x1100]: Audio: truehd (AC-3 / 0x332D4341), 48000 Hz, 7.1, s32 (24 bit) [10:46:53 CEST] <kevmitch> becomes Stream #0:1[0x1100]: Audio: dts (AC-3 / 0x332D4341), 0 channels, s32p (24 bit) [11:03:09 CEST] <kevmitch> oh, if you mean that I shouldn't have to specify the input codec, libdcadec is a special case where I do since ffmpeg uses its internal (lossy) decoder by default [11:13:18 CEST] <__Shimo__> ffmpeg doesn't support art embedding into m4a. [11:13:21 CEST] <__Shimo__> shame on you! [11:13:33 CEST] <__Shimo__> sorry, wrong channel. [12:18:18 CEST] <doda> hi folks, i have some problem that i don't know how to formulate in a google search, i'm creating divx avi files from mkv h264 videos, and the first minutes of the clip are pixelated with bad quality then at once moment it gets fixed [12:28:03 CEST] <kevmitch> I remember the year 2000 [12:29:21 CEST] <kevmitch> doda: what command line? does the same thing happen if you increase the bitrate? [12:41:28 CEST] <doda> kevmitch: i tried with ffmpeg -i input.mp4 -vtag DIVX -f avi -vcodec mpeg4, will try that thanks [12:49:47 CEST] <doda> kevmitch: -qscale 0 solves the issue, thanks [13:20:11 CEST] <Anoia> does anyone know if AVI containers allow for a text overlay track without reencoding the contents? [15:00:49 CEST] <Baptiste_> hello there [15:01:43 CEST] <livee> i need some help with ffmpeg, i posted a message on http://ffmpeg.gusari.org/viewtopic.php?f=11&t=2056&p=5957#p5957 but i might think it can be quicker here :) [15:02:11 CEST] <livee> i have audio desync during a rtmp stream [15:06:11 CEST] <livee> if someone have faced this issue before [15:07:21 CEST] <livee> ou même si il y a des français [15:07:30 CEST] <livee> qui aurai eu ce problème [15:32:59 CEST] <livee> any help ? [15:33:12 CEST] <livee> any idea ? [15:34:38 CEST] <livee> no challenge ? [15:51:50 CEST] <FedoraUser> hi friends [15:52:06 CEST] <FedoraUser> i am trying to play stream for 5 seconds and then exit with ffplay [15:52:18 CEST] <FedoraUser> but it doesn't exit, am I doing something wrong? [15:52:37 CEST] <FedoraUser> this is the command 'ffplay -f alsa -i pulse -t 00:00:05.00 -autoexit' [15:53:21 CEST] <FedoraUser> the playback stops (it is just input from the mic for testing purposes) but ffplay doesn't close [17:33:59 CEST] <m3gab0y> hey all, any idea how to get icy-metadata from audio stream and draw it on the screen via drawtext? [18:37:19 CEST] <capradmar> Hi! when deployed on a non development machine (mac mini on osx 10.9.5), my application crash: http://pastebin.com/3mjJBKH4 [18:37:55 CEST] <capradmar> it happens during the ff_me_cmp_init_static function [18:38:07 CEST] <capradmar> any idea what could be the cause? [18:46:09 CEST] <DusteD> Hi, sorry for asking a question I'm sure has been asked before, but my google-fu fails me: I want to convert a 60fps video to 30 fps, I'd like to know if ffmpeg will "blend" the frames together or simply discard every second frame ? [18:48:46 CEST] <c_14> discard [18:53:10 CEST] <DusteD> c_14, alright, thanks :) [19:21:12 CEST] <Fyr> how to clean all the metadata during conversion? [19:21:25 CEST] <c_14> -map_metadata -0 should do it [19:21:32 CEST] <Fyr> thanks [19:22:24 CEST] <Fyr> I want to convert some files into wav and make md5sums of them to compare. wav has metadata. =)) [19:22:38 CEST] <c_14> hmm, might also have to create a negative mapping for stream/chapter metadata [19:24:46 CEST] <c_14> Might also want -flags bitexact in that case [19:25:19 CEST] <Fyr> c_14, why the lossless files are different? if I open the files, I see in one place "01" (converted from flac) and "1" (converted from alac)? [19:25:33 CEST] <c_14> +bitexact that is [19:25:34 CEST] <c_14> hmm? [19:25:55 CEST] <Fyr> ok, how do I clean all the metadata from a file? [19:28:04 CEST] <c_14> '-map_metadata -0 -map_metadata:s -0 -flags +bitexact' should do it [19:28:12 CEST] <Fyr> thanks [19:38:00 CEST] <Guest28031> Hello [20:31:17 CEST] <hroi> I have a video encoded using the ffmpeg library used by blender [20:31:36 CEST] <hroi> is H264 in an avi container [20:31:50 CEST] <hroi> but it runs not very smoothly on VLC and on youtube [20:31:54 CEST] <hroi> same problem [20:32:04 CEST] <hroi> see https://www.youtube.com/watch?v=qACY9n6ztnY#t=32 [20:32:35 CEST] <hroi> can anyone spot the problem, perhaps this is common problem with encoding/bitrate or other? [20:33:04 CEST] <hroi> the video is 100MB large 720p, 24 fps and 50s long [20:35:57 CEST] <spaam> hroi: why do you have h264 in .avi ? :S [20:36:07 CEST] <spaam> hroi: put it in .mp4 or .mkv [20:36:22 CEST] <hroi> spaam, yeah... I know -- you think that could be it? [20:36:36 CEST] <spaam> hroi: i dont know. maybe :) [20:36:39 CEST] <hroi> spaam, I read some stupid recommendation about youtube upload [20:36:55 CEST] <spaam> i know .avi and h264 is bit meh [20:36:59 CEST] <hroi> spaam, but I think the h264 was the main thing [20:37:18 CEST] <hroi> spaam, and isnt there webm also? [20:37:43 CEST] <hroi> richard stallmann can only be stored in webm [20:37:45 CEST] <spaam> yes. webm need vp8 video and vorbis for audio. [20:38:27 CEST] <hroi> maybe youtube is not webm friendly yet. [20:38:48 CEST] <hroi> ok I will try the difference, encode in h264 mkv [20:39:53 CEST] <hroi> then I was thinking, perhaps the background noise in the encoded images is of some type that causes the codec to work too hard or something [20:40:16 CEST] <hroi> perhaps there are other codecs that ignore difficult noise [20:48:24 CEST] <kyleogrg> Hey [20:48:35 CEST] <kyleogrg> I'd like to convert some DV AVIs to MP4 [20:49:15 CEST] <kyleogrg> What settings can you recommend to have a visually lossless (or nearly so) MP4? [20:51:25 CEST] <kepstin-laptop> kyleogrg, if you're using x264, just set a fairly low "-crf" value, maybe in the 12-18 range depending on taste. [20:51:26 CEST] <kyleogrg> Also -- is there a way to retain all of the date and time information which is embedded in some DV AVI files? Can this be transferred to maybe an MKV? Or an SRT? [20:51:42 CEST] <kyleogrg> kepstin-laptop: helpful as always [20:52:06 CEST] <kyleogrg> As for -preset, maybe veryslow? [20:52:52 CEST] <kepstin-laptop> set the preset as slow as you can tolerate. If you're just encoding it once for archiving, veryslow isn't a bad choice. [20:53:22 CEST] <kyleogrg> yeah [20:53:38 CEST] <kyleogrg> What do you think a sane, but good, deinterlace setting is? [20:54:24 CEST] <kepstin-laptop> interlaced HD camera source, right? [20:54:46 CEST] <kepstin-laptop> probably the most reasonable thing is to just use -vf yadif with the default settings. [20:55:02 CEST] <kyleogrg> The source is interlaced NTSC, SD footage. [20:55:05 CEST] <jarainf> There are different Filters to apply deinterlacing but using yadif is encouraged [20:55:38 CEST] <kyleogrg> well, for instance, i know i can use yadif with mcdeint and multiple reference frames, and this is super slow [20:55:48 CEST] <kepstin-laptop> hmm. I'm occasionally unhappy with some of the artifacts yadif has on certain sharp diagonal lines, particularly at SD resolutions, but there's really not much better [20:56:07 CEST] <kepstin-laptop> imo, mcdeint doesn't provide that much benefit over yadif. [20:57:14 CEST] <kyleogrg> maybe SOME benefit, but much slower? [20:57:23 CEST] <FedoraUser> the command 'ffplay -f alsa -i pulse -t 00:00:05.00 -autoexit' doesn't exit after 5 seconds, can I accomplish this without killall? :) [20:59:03 CEST] <kepstin-laptop> kyleogrg, been a while since i've tried comparing them, but I seem to recall that I couldn't tell the difference between yadif and yadif w/mcdeint. [20:59:13 CEST] <kyleogrg> ok, thanks [21:00:05 CEST] <kepstin-laptop> in particular, adding the mcdeint didn't clear up the artifacts on diagonal lines from yadif. [21:00:55 CEST] <kepstin-laptop> dunno, i might have just been using it wrong too :) [21:01:00 CEST] <kyleogrg> sure okay [21:01:07 CEST] <kyleogrg> i think yadif is enough for my purposes [21:01:30 CEST] <kyleogrg> do you happen to know if MKVs can have timecodes? [21:02:07 CEST] <kepstin-laptop> well, you can store pretty much arbitrary metadata in mkv. whether ffmpeg will copy timecodes and if there's a standard for them, i don't know. [21:02:15 CEST] <kyleogrg> Many of my source DV-AVIs have built in timecodes of when the scenes were recorded. I want to transfer this information. If possible it should be in a timecode stream of something, not just a subtitle file. [21:02:39 CEST] <kyleogrg> hmm ok, but not an official timecode format? [21:03:12 CEST] <kyleogrg> https://www.bunkus.org/videotools/mkvtoolnix/doc/mkvextract.html#mkvextract… [21:03:37 CEST] <kepstin-laptop> don't get confused, there's multiple things named "timecodes" [21:04:05 CEST] <kepstin-laptop> the "timecodes" files used by mkvextract/mkvmerge allow specifying variable-framerate pts values alongside a raw video stream. [21:04:21 CEST] <kepstin-laptop> nothing related to realtime. [21:04:56 CEST] <kyleogrg> ahh [21:05:37 CEST] <kyleogrg> ok, well i'm going to go now. i'll investigate this later [21:05:38 CEST] <kyleogrg> thanks [21:05:40 CEST] <kyleogrg> see ya [21:34:53 CEST] <kyleogrg> all right, all right, all right [21:35:16 CEST] <kyleogrg> I found a nonfree binary of ffmpeg somewhere [21:35:26 CEST] <kyleogrg> can i download and use it? [21:35:33 CEST] <kyleogrg> i want to use libfdk_aac [21:36:15 CEST] <kyleogrg> or are there legal issues [21:37:28 CEST] <durandal_1707> That is illegal [21:37:51 CEST] <kyleogrg> ok, but i can build it myself and that's legal, right? [21:38:33 CEST] <durandal_1707> Yes [21:39:03 CEST] <kyleogrg> is there a streamlined, straightforward way to build ffmpeg on windows? [21:39:16 CEST] <kyleogrg> I remember trying it many months ago and finding many complications [21:42:41 CEST] <kyleogrg> Is this a good method?: https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC [22:25:41 CEST] <seasc> can one use ffplay to play videos in linux VT (or multiuser target) ? [22:32:08 CEST] <kyleogrg> hey [22:32:39 CEST] <kyleogrg> So I may compile my own FFmpeg. If I want to enable 10-bit HEVC, how do I do this? [22:33:29 CEST] <seasc> afaik, 8 or 10bit hevc is the bitrate you pass to the codec, either x264 or x265 [22:34:09 CEST] <kyleogrg> hmm really? [22:34:25 CEST] <kyleogrg> from some searching, i got the impression that you had to build them differently [22:34:58 CEST] <seasc> thats why there is an ^afaik^ ;) not sure [22:35:02 CEST] <kyleogrg> haha sure [22:35:07 CEST] <seasc> as far as i know though [22:35:14 CEST] <kyleogrg> well how about this: https://ffmpeg.org/pipermail/ffmpeg-user/2012-July/008279.html [22:35:16 CEST] <seasc> Might wanna dig into git://git.videolan.org/x264.git http://hg.videolan.org/x265 [22:35:24 CEST] <kyleogrg> "If you want to use High10 Profile then compile a [22:35:24 CEST] <kyleogrg> 10-bit build of x264 and link ffmpeg to that." [22:36:40 CEST] <seasc> there you go: <<compile a [22:36:40 CEST] <seasc> > 10-bit build of x264>> [22:37:24 CEST] <seasc> its not actualy building ffmpeg, but yes, i'd assume there will be a toggle for the ./configure --help to enable the 10bit compiling [22:38:37 CEST] <kyleogrg> hmm ok [22:39:12 CEST] <kyleogrg> well thank you [22:39:19 CEST] <kyleogrg> later i may try this [23:04:20 CEST] <seasc> So, is one supposed to be able to play an audio or video file using ffplay in a VT on linux? [23:06:25 CEST] <c_14> Audio should work with -nodisp [23:06:38 CEST] <c_14> video won't [23:06:49 CEST] <c_14> unless you get SDL to work on the framebuffer [23:48:32 CEST] <kyleogrg> hey [23:48:58 CEST] <kyleogrg> for a 64-bit computer, is a 64-bit build of ffmpeg faster than 32-bit? [23:49:23 CEST] <BtbN> yes, it has way more cpu registers to work with. [23:50:01 CEST] <kyleogrg> will it use all cpu cores? [23:50:19 CEST] <BtbN> Depends on what "it" is exactly. [23:50:50 CEST] <kyleogrg> libx265 [23:55:09 CEST] <BtbN> Yes, it's multithreaded [23:55:12 CEST] <BtbN> But still slow [23:56:02 CEST] <kyleogrg> ok [00:00:00 CEST] --- Tue Apr 21 2015

1 0