Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

July 2014

1 participants
62 discussions

ffmpeg-devel.log.20140730
by burek 31 Jul '14

31 Jul '14

[00:43] <BBB> what is CNU in the init_values[] table in hevc_cabac.c? it seems to mean does not exist or has no meaning (since its for inter stuff in i-slices), but theres a real value of 154 associated with it, I wonder why [01:02] <smarter> context not used I think [01:03] <smarter> the associated value is 154 because that's what the HM uses, I don't think it matters [01:03] <BBB> Im about to wtf on cabac_init_state() [01:03] <BBB> is that also hm copypaste? [01:04] <smarter> what's wrong with it? [01:04] <BBB> I understand we hav 2 4 bit values and hardware people want to store them as such [01:04] <BBB> but we are not hardware people [01:05] <smarter> that's how it's defined in the spec, you could use tables yeah [01:05] <BBB> its obfuscated [01:05] <Daemon404> so is the spec [01:05] <BBB> nobody can figure out the meaning of these numbers [01:05] <BBB> plus its slow, to get the actual number you need multiplications, adds, shifts [01:05] <Daemon404> [00:05] <@BBB> nobody can figure out the meaning of these numbers <-- liek vp9*.c? [01:05] Action: Daemon404 runs [01:06] <BBB> vp9.c [01:06] <BBB> and ask [01:06] <smarter> it made more sense when these values where not fixed and it wasn't worth regenerating tables everytime they changed [01:06] <BBB> I actually udnerstant he vp9 spec pretty deeply [01:06] <BBB> hevc, not so much [01:06] <Daemon404> what spec [01:06] <Daemon404> i see no spec [01:06] <BBB> the one in my head :) [01:06] <BBB> fine, I agree, theres no spec [01:06] <BBB> I understand the vp9 bitstream format pretty deeply [01:06] <Daemon404> the yactually put a bitstream guide out under NDA [01:06] <BBB> ask [01:07] <Daemon404> why NDA i dunno [01:07] <Daemon404> i did ask during code review, but it was 'magic number' :P [01:07] <smarter> lawyers. [01:07] Action: Daemon404 is not actually interested [01:07] <BBB> ... [01:07] <BBB> anyway, the values in that hevc decoder that we engulfed& are & meaningless? [01:07] <smarter> the magic numbers are just probabilities that were determined based on experiments [01:07] <Daemon404> probably [01:07] <BBB> I cant make much of them, except magic :) [01:07] <smarter> both in vp9 and hevc [01:08] <Daemon404> smarter, the vp9 guide is just as bad (or worse) than vp8's [01:08] <Daemon404> or so im told [01:08] <BBB> but it seems slow to store them in 8bits and do calculations on them [01:08] <BBB> Id store them in 2x8 bits as actual offset and mltiplier [01:08] <BBB> I bet half of the qp multipliers are 1 [01:08] <BBB> but what do I know [01:08] <BBB> er& zero [01:08] <BBB> anyway [01:09] <smarter> Daemon404: I'm not convinced that MPEG-like specs are that much better [01:10] <Daemon404> at least they tend to actually match implementations. [01:10] <BBB> I just reverse engineer by reading ffmpeg code :) [01:10] <Daemon404> there is a good hevc writeup by the f265 people iirc [01:11] <Daemon404> http://www.f265.org/f265/static/txt/h265_companion.html [01:11] <smarter> I like " A short rant about the specification " [01:11] <Daemon404> yes [01:12] <BBB> is that the document thats really funny once you understand the h265 spec? [01:12] <BBB> I think I tried reading it once [01:13] <Daemon404> it contains useful translations to actual english [01:13] <Daemon404> it helped me a bit [01:15] <BBB> maybe I should sell myself off in public as (with ubitux) one of the only two people int he world that does not work at google and understands vp9 [01:15] <BBB> I wonder if thats worth any penny [01:15] <smarter> I think that guy understands vp9 alright too: http://forum.doom9.org/showthread.php?t=168947 [01:16] <BBB> shite, there goes that plan [01:17] <Daemon404> Occupation: Hardware video codec engineer [01:17] <Daemon404> (from his profile) [01:17] <smarter> Intel guy [01:18] <Daemon404> im surprised he didnt suddenly vanish under NDAs then [02:57] <kierank> smarter: mpeg specs are designed so n people can implement in secret [02:58] <kierank> whereas vp9 etc as far as I can tell is designed for people to implement in a more open atmosphere, warts and all [04:28] <cone-75> ffmpeg.git 03gerion.entrup(a)t-online.de 07master:f2855eb4d712: avformat/movenc: add m4b to list of ipod playable files [11:04] <cone-729> ffmpeg.git 03Carl Eugen Hoyos 07master:355121bcb5d9: lavf/mux: Fix a typo checking aspect ratios. [12:33] <nevcairiel> hrm, binutils 2.24 doesn't build with gcc 4.9.1 for me, some compile error, what a disappointment [13:10] <cone-729> ffmpeg.git 03Carl Eugen Hoyos 07master:ff9a154157ec: Add int64_t probesize2 instead of int probesize to AVFormatContext. [15:44] <cone-729> ffmpeg.git 03Nicolas George 07master:91244073fd8b: ffmpeg_filter: refuse to configure input without a decoder. [15:52] <saste> do you know if it is possible to use ffserver to stream directly from a browser? [15:52] <saste> at least using ffmpeg+ffserver+ffplay this seems possible, but things are tricky with working with browsers [15:52] <saste> for streaming i mean live video/audio [17:14] <ubitux> vf deshake question [17:14] <ubitux> there is a sad using the blocksize as height [17:14] <ubitux> this makes no sense to be because it is always 16-byte width [17:14] <ubitux> (sad[0]) [17:15] <ubitux> and btw, unless i'm mistaken sad[0] is likely the sse version [17:15] <ubitux> which can only work with aligned data [17:16] <ubitux> won't this cause troubles? [17:17] <ubitux> so 2 changes would sound relevant to me: fallback on the 8-byte width, at least for now, and then force the 8 height (or 16 height if we make a 16-byte-width working with unaligned addresses - which i'm working on) [17:17] <ubitux> does that make any sense? [17:27] <nevcairiel> kierank: i'm pondering on closed caption data from H.264 streams, didn't you talk about that some time ago? [17:32] <kierank> yes just a case of adding the same support that mpeg-2 has [17:33] <nevcairiel> does it use the same format internally? [17:35] <kierank> Similar [17:35] <kierank> See ETSI TS 101 154 [17:35] <nevcairiel> similar enough to use the same side data message? =) [17:35] <kierank> There are a couple of bytes you need to skip [17:35] <kierank> Yes [17:36] <nevcairiel> i was browsing the stuff, found the place where to hook it up in the decoder and everything [17:39] <kierank> What are you going to decode with? [17:39] <kierank> Decode the captions [17:40] <nevcairiel> so i skip the headers and just store the 3 byte * count in the side data, that seems to be what mpeg2 doe [17:40] <nevcairiel> does* [17:40] <nevcairiel> i'm not quite sure about that part yet, for now i'm hoping microsofts line21 decoder accepts the stuff [17:43] <nevcairiel> one step at a time [17:46] <cone-729> ffmpeg.git 03Diego Biurrun 07master:a8d803a320fb: vf_select: Drop a debug av_log with an unchecked double to enum conversion [17:46] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:7994c1cd7608: Merge commit 'a8d803a320fb08b3ad5db4fffc79abd401206905' [17:46] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:887d8d293fc3: avfilter/f_select: avoid using doubles for equals checks and casts to enums [17:53] <michaelni> ubitux, IIRC only one of the inputs to sad needs to be aligned [17:53] <michaelni> deshake takes steps of 16 for x [17:54] <michaelni> blocksize * 2 for y [17:55] <michaelni> but its sure possible deshake has bugs and it surely can be imroved and cleaned up [17:55] <ubitux> mmh ok i see [17:55] <ubitux> so 16 should be safe [17:56] <ubitux> yeah alright i see [17:56] <michaelni> also the ME used in libavcodec or x264 is surely alot better and faster than what deshake does [17:56] <ubitux> i was going to write 8x8 and 16x16 sad, with unaligned and aligned version [17:57] <ubitux> and i was wondering if the variable height was meaningful in any way [17:57] <ubitux> like sad 8xh and sad 16xh [17:57] <ubitux> i'm not sure i follow the concept here [17:57] <michaelni> 16x8 blocks exist in mpeg2 and h264 [17:58] <michaelni> also in interlaced 16x16 Mbs in mpeg4 [17:58] <michaelni> so 16x8 does make sense [17:58] <michaelni> iam not sure about unaligned [17:58] <ubitux> yeah alright 16x8 and 8x16 sure could be in [17:58] <ubitux> i'm just a bit uncomfortable about the need for an arbitrary height one [17:59] <michaelni> and 8x4 for chroma in 420 [17:59] <ubitux> again it's just a combination [17:59] <ubitux> not an arbitrary 8x123 [18:02] <ubitux> (afk ~1h) [18:53] <j-b> If you plan to come to VDD, I'd encourage you to register soon [19:18] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:bcbfb95b0e32: avfilter/f_select: Set var_values[VAR_KEY] correctly [19:18] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:6f622e5fcbe8: avfilter/f_select: avoid double->int in debug output [19:31] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:ba3e3311ef3f: avutil/frame: add av_frame_side_data_name() [19:31] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:547d64a49a87: ffprobe: print some basic information about avframe side data [19:43] <kierank> nevcairiel: what format does the l21 decoder take [19:44] <nevcairiel> CEA-608-B byte pair format [19:45] <nevcairiel> Or DVD GOP format, both are supposed to work [19:47] <kierank> ok [19:48] <kierank> you'll probably have to separate out the 608 [19:49] <nevcairiel> I got the stuff out of the h264 decoder, going to see about the decoding of the CCs tomorrow. Found all the specs in the Dropbox folder. :) [19:49] <kierank> well you can try it with mpeg-2 I guess [19:49] <kierank> or does it work already [19:50] <nevcairiel> It seems to work [19:50] <nevcairiel> But no way to test reliably [19:51] <wm4> a CC decoder? [19:51] <wm4> I once thought about porting the VLC one (and it even worked) [19:51] <nevcairiel> Just getting CC out of the h264 user data for now [19:51] <nevcairiel> Decoding is tomorrow [19:51] <nevcairiel> ;) [19:58] <kierank> wm4: how are going to make it fit into ffmpeg [19:58] <kierank> you could maybe do it in the parser I suppose [19:58] <kierank> and then let the decoder reorder it [19:58] <wm4> isn't that already done [19:58] <wm4> the decoder outputs CC data as side data [19:58] <kierank> no [19:58] <wm4> (yay side data) [19:58] <kierank> yeah but it's not a stream [19:59] <wm4> I was thinking libavformat could detect the CC via parser, and add dummy streams [19:59] <wm4> but the lib user has to feed back the packets from decoder to stream somehow [19:59] <wm4> but other than that detail, you could pretend CCs work like subtitle streams [20:00] <wm4> so what's needed is an API function that allows feeding CC data from the decoder to libavformat [20:01] <nevcairiel> Well if a avcodec decoder exists, API users could do the hook up manually [20:01] <wm4> yeah, that's what I'm thnking [20:01] <nevcairiel> Some containers can apparently even have cc data in streams, ie. mov [20:02] <wm4> already reordered? [20:02] <nevcairiel> I would assume so [20:02] <nevcairiel> Its like a normal subtitle stream [20:02] <wm4> sounds good [20:03] <wm4> so, for formats which have it in the video data, I'd suggest: [20:03] <wm4> 1. libavformat uses the parser to determine CC presence, and adds dummy streams [20:03] <wm4> 2. add a libavformat API that allows the user to feed back reordered CC data from the decoder to the demuxer [20:04] <wm4> 3. the demuxer outputs the dummy data as normal "subtitle" packets originating from the dummy streams [20:04] <wm4> so, expect for the user having to feed back the data, everything would appear to work like as with normal subs [20:06] <nevcairiel> Why bother with the fake stream, could just call the decoder directly [20:07] <wm4> I'm assuming this would require larger changes/hacks to the user application's architecture [20:12] <cone-729> ffmpeg.git 03Anton Khirnov 07release/2.2:f9204ec56a4c: eamad: use the bytestream2 API instead of AV_RL [20:12] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:357325603719: Merge commit 'f9204ec56a4cf73843d1e5b8563d3584c2c05b47' into release/2.2 [20:27] <cone-729> ffmpeg.git 03Reinhard Tartler 07release/2.2:12bbd819cbdf: Prepare for 10.3 Release [20:27] <cone-729> ffmpeg.git 03Martin Storsjö 07release/2.2:407912d17870: avplay: Handle pixel aspect ratio properly [20:27] <cone-729> ffmpeg.git 03Martin Storsjö 07release/2.2:b8e57113ecba: arm: Avoid using the 'setend' instruction on ARMv7 and newer [20:27] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:6135baa85bda: Merge commit '12bbd819cbdfdd2b41286c5ccabee7f5e5b6612a' into release/2.2 [20:27] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:f4e08695602b: Merge commit '407912d17870a53e8a8cc072f192cadf358bc155' into release/2.2 [20:27] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:92c497375221: Merge commit 'b8e57113ecba5494d4bf47c29634392ea5fdb17b' into release/2.2 [20:30] <cone-729> ffmpeg.git 03Reimar Döffinger 07master:04aec74f4569: mxfdec: add missing "const" to array declaration. [20:31] <cone-729> ffmpeg.git 03Reimar Döffinger 07master:1c84aad718f0: movdec: remove nonsensical snprintf. [20:45] <cone-729> ffmpeg.git 03Martin Storsjö 07release/2.2:f6b3dce952d6: librtmp: Don't free the temp url at the end of rtmp_open [20:45] <cone-729> ffmpeg.git 03Diego Biurrun 07release/2.2:01a550bda29e: vf_select: Drop a debug av_log with an unchecked double to enum conversion [20:45] <cone-729> ffmpeg.git 03Bernhard Übelacker 07release/2.2:b20a8ad619ac: video4linux2: Avoid a floating point exception [20:45] <cone-729> ffmpeg.git 03Diego Biurrun 07release/2.2:d396987c303b: fate: Add dependencies for dct/fft/mdct/rdft tests [20:45] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:f02221d65143: Merge commit 'f6b3dce952d66f87883a50d90d6e98416ee397df' into release/2.2 [20:45] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:75ff0e8c50d1: Merge commit '01a550bda29eb05fb230576e5223034974aa3396' into release/2.2 [20:46] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:9dc112e277fd: Merge commit 'b20a8ad619ac0e2631391b6311cc000de85d22bf' into release/2.2 [20:46] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.2:3ef8b4322cba: Merge commit 'd396987c303bdc4eea7d1a1ff6776475d9bbd9ea' into release/2.2 [21:13] <Daemon404> wm4, to answer your earlier question: you both are [21:13] <Daemon404> but he is a bigger one [21:13] <wm4> thought so [22:07] <michaelni> llogan, do we have some tweet about OPW donation need ? [23:08] <cone-729> ffmpeg.git 03Vittorio Giovara 07release/2.3:ab1ea597bd69: g2meet: allow size changes within original sizes [23:08] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.3:5411040802ac: tests/fate.sh: If cat *.rep fails try it with a for loop. [23:08] <cone-729> ffmpeg.git 03Janne Grunau 07release/2.3:6a250c858ebb: fate: support testing of release branches [23:08] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.3:c61ac696e56a: avcodec/avdct: Add avcodec_dct_get_class() [23:08] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.3:ea5bb5613f7f: MAINTAINERS: update list of releases i maintain [23:08] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.3:de9d3f22f06e: avdevice/pulse_audio_enc: use getter function for AVFrame.channels [23:13] <michaelni> Timothy_Gu, ubitux, others, should I use the 2.3 release notes in 2.3.1 or someone wants to update them ? [23:14] <ubitux> i think it should be changed [23:14] <ubitux> the release not is for the "branch" [23:14] <ubitux> no new features are added, that's just revisions [23:14] <ubitux> release note* [23:15] <ubitux> it should *not* be changed [23:15] <ubitux> meh. [23:20] <cone-729> ffmpeg.git 03Michael Niedermayer 07release/2.3:64bbbcd7b076: update for FFmpeg 2.3.1 [23:44] <cone-729> ffmpeg.git 03Diego Biurrun 07master:a0ce85ac7de0: configure: Globally add ZLIB_CONST to CPPFLAGS if zlib is enabled [23:44] <cone-729> ffmpeg.git 03Michael Niedermayer 07master:a99de9ca2ccb: Merge commit 'a0ce85ac7de098d3f9b53b51b77a09bad700a011' [00:00] --- Thu Jul 31 2014

1 0

ffmpeg.log.20140730
by burek 31 Jul '14

31 Jul '14

[05:21] <pnpbios> hello, is there a definitive example of using ffmpeg with x11grab and ffserver? I can never seem to configure my params right. [05:22] <pnpbios> http://pastebin.com/d8MhRNni -- this is what I am using to call ffmpeg [05:26] <pnpbios> can anybody help me, please? [05:56] <sec_> i want to hear some frames in mp3 file, how do that? [05:58] <pnpbios> you mean slice an mp3? [06:06] <sec_> pnpbios: yep [06:07] <pnpbios> have you looked at cutmp3? [06:08] <sec_> pnpbios: it is not showing frame no. [06:08] <pnpbios> @sec_ what do you mean by frame? [06:09] <sec_> struct MPEG_FRAME mf[0] 0h 180h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[1] 180h 240h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[2] 3C0h 1E0h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[3] 5A0h 150h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[4] 6F0h 180h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[5] 870h 180h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[6] 9F0h 180h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[7] B70h 240h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[8] DB0h 150h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[9] F00h 180h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[10] 1080h 1E0h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[11] 1260h 1E0h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[12] 1440h 1E0h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[13] 1620h 120h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[14] 1740h C0h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[15] 1800h F0h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[16] 18F0h 1E0h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[17] 1AD0h 1E0h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[18] 1CB0h 150h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[19] 1E00h 180h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[20] 1F80h 180h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[21] 2100h 240h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[22] 2340h 180h Fg: Bg: [06:09] <sec_> struct MPEG_FRAME mf[23] 24C0h 180h Fg: Bg: [06:09] <pnpbios> ok [06:10] <sec_> struct MPEG_FRAME mf[24] 2640h 1E0h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[25] 2820h 180h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[26] 29FCh 121h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[27] 2B5Eh 6C0h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[28] 3222h B7h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[29] 3341h 241h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[30] 3676h 4h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[31] 36C0h 180h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[32] 3840h 1E0h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[33] 3A20h 150h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[34] 3B70h 240h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[35] 3DB0h 1E0h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[36] 3F90h 1E0h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[37] 4170h 180h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[38] 42F0h 180h Fg: Bg: [06:10] <sec_> struct MPEG_FRAME mf[39] 4470h 240h Fg: Bg: [06:10] <sec_> ops [06:10] <sec_> sorry [06:10] <sec_> pnpbios: that is showing with 010 editor [13:13] <termos> why is my mpegts not constant for all bitrates? I can't see any reason why the header overhead from the ts segments should be any different for another bitrate. [13:13] <termos> All my segments are around 3s long [13:17] <Mavrik> what is not constant? [13:21] <termos> ah, the overhead that is calculated by apples mediastreamvalidator for my hls stream [13:22] <termos> Average segment structural overhead: 92.47 kbits/sec (16.76 %) for one of my streams, while for the other one it's 13.52 % [13:22] <feliwir> hey, has someone a code example where i get the bitmap from a avsubtitle as bitmap? (if type== SUBTITLE_BITMAP). I really have no clue how that palletized thing is supposed to work [13:22] <Mavrik> termos, of course, because the rate of insertion for PAT/PMT and other packets is constant [13:22] <Mavrik> and the packets are of constant size [13:23] <Mavrik> so if you lower the bitrate of actual video/audio the overhead in % will rise, right? basic maths :) [13:23] <Mavrik> feliwir, hmm, weren't you the guy I've pasted the conversion code awhile ago? :) [13:25] <Mavrik> fling, you have a pallette of colors of size rect->nb_colors on data[1] plane [13:25] <Mavrik> er, feliwir [13:25] <termos> hmm I don't quite get it still... each mpegts packet is 184 bytes or something where 4 bytes is the header [13:25] <Mavrik> and you have actual rect with just indexes of colors from the palette in data[0] plane. [13:25] <feliwir> ye i was that [13:25] <feliwir> but i didnt make any progress [13:25] <feliwir> it still looks like crap :D [13:26] <feliwir> the example in ffplay.c is so confusing :( [13:26] <termos> i can not understand why the overhead is more than those 4 bytes, which is the header data [13:26] <Mavrik> termos, yes? [13:26] <Mavrik> termos, read up on MPEG2-TS spec [13:26] <Mavrik> termos, you don't have ONLY video and audio packets [13:26] <Mavrik> termos, you also have packets carrying information about what's in the stream that have to be transmitted periodically [13:27] <termos> aha okey [13:27] <termos> guess i'll look up the spec :) so those extra packages are inserted more frequently for lower bitrates? [13:49] <feliwir> mavrik how do i use that palette of colors? [17:05] <kaotiko> hi [17:33] <Mista_D> any way to map PID values from input file to output please? [17:34] <naprac> how to simply record video and audio running on screen? with good quality no pixelation nor drag [17:34] <CrashSys> I have a bunch of jpegs in 1920x1080 format that i'm trying to generate a 480x270 (1/4 scale) video of. Is the best use of ffmpeg going to be this: ffmpeg -r 5 -s 480x270 -i 'jpeghere' -y 'mpeghere'? I'm trying to make the conversion as quick as possible. It's all CCTV footage so it doesn't need to be the highest playback quality just resonable. [17:36] <naprac> CCTV? isn't that like UK police surveillanca cameras? [17:36] <CrashSys> This is for a business [17:36] <CrashSys> they record to 1080p for a month, then want it archived to something more manageable storage wise after that [17:37] <CrashSys> It's internal security cameras of their jewelry store [17:37] <c_14> You'll want the -s after the -i [17:38] <CrashSys> ok [17:39] <CrashSys> should I specify anything for bitrate or will it figure out an optimal one on it's own? [17:40] <c_14> It'll use the defaults which are usually 'shitty but watcheable'. [17:41] <CrashSys> Works for me then :) [17:41] <naprac> c_14, you know about howto record video and audion from video running on screen? [17:41] <CrashSys> They do a full inventory every week so in their mind if they don't know they've been stolen from in a month then that's just what they get, or everyone is in on it and the manager probably deleted the video anyways [17:43] <c_14> naprac: https://trac.ffmpeg.org/wiki/Capture/Desktop [17:43] <Mavrik> CrashSys, you should always specify bitrate [17:43] <Mavrik> since ffmpeg defaults to something awfully terrible [17:43] <naprac> yes i tried that and it doesn't work [17:43] <Mavrik> you should also explicitly set a video codec or ffmpeg will probably choose something very dumb :D [17:44] <CrashSys> ok, i'm open to suggestions. Something that compresses quickly and is relatively supported on media players [17:44] <c_14> Mavrik: If you have ffmpeg built with libx264 it'll usually default to that with a crf of around 24 or so. Which is not _that_ bad. [17:45] <Mavrik> mhm, if it decides libx264 is a good choice which IIRC depends on extension... old experience makes me a bit vary always tho D [17:45] <c_14> CrashSys: https://trac.ffmpeg.org/wiki/Encode/H.264 <- always helpful [17:45] <Mavrik> CrashSys, ffmpeg -r 5 -i 'jpegs' -codec:v libx264 -crf 24 -vf scale=480:270 output.mp4 [17:46] <Mavrik> H.264 in MP4 container is pretty much playable everywhere [17:46] <CrashSys> portability is goog :) Now to see what kind of speed that gets [17:47] <Mavrik> CrashSys, you can always use -preset medium/fast/faster/veryfast/ultrafast to control the speed [17:47] <Mavrik> (with tradeoff of quality of course= [17:47] <CrashSys> Is that just modifying the crf? or is there more to it? [17:48] <Mavrik> CrashSys, no, that's modifying everything except crf/bitrate [17:48] <CrashSys> ahh, just got to that part on the webpage [17:48] <Mavrik> it controls speed vs. quality tradeoff [17:48] <CrashSys> ok :) [17:48] <Mavrik> target bitrate/quality doesn't change :) [17:48] <CrashSys> preset would be after the -i option? [17:49] <naprac> c_14, does that example work with ffmpeg version 0.8.7? [17:49] <Mavrik> CrashSys, yes, everything that sets encoding settings has to go after -i [17:49] <naprac> well, i mean it doesn't but maybe it's ment to newer one [17:49] <c_14> Mavrik: the tradeoff is speed vs filesize [17:49] <Mavrik> everything before -i sets INPUT properties [17:49] <c_14> not quality [17:49] <c_14> naprac: ehh, that ffmpeg version is probably too old [17:50] <Mavrik> c_14, depending on settings of course, in CRF mode is that indeed filesize, in vbv target bitrate mode it's quality [17:50] <CrashSys> ok cool [17:50] <c_14> yes [17:50] <Mavrik> but you are right, in this case it's filesize [17:50] <CrashSys> My ffmpeg is 2.2.4 for what that's worth [17:52] <naprac> ic, well it's the newest available ffrom slackbuilds [17:52] <c_14> You might want to build from source. [17:54] <CrashSys> when I try that command I get a warning about the jpg image already existing and it asks if I want to overwrite. I'm using this command: ffmpeg -r 5 -i ./00/*.jpg -codec:v libx264 -crf 24 -vf scale=480:270 /root/test.mp4 [17:55] <naprac> c_14, thats gonna take ages, if even works right? [17:56] <c_14> Nah, compiling shouldn't take that long. Depends what you activate and your pc of course, but it's not that bad. [17:56] <c_14> CrashSys: You'll probably want -f image2 [17:56] <c_14> https://ffmpeg.org/ffmpeg-formats.html#image2-2 [17:56] <naprac> configure, make, make install or should i set something? [17:58] <c_14> You'll at very least need to enable x11grab and pulse or alsa. [17:58] <c_14> Depending on what codec you want you'll need to make sure to enable that as well. [17:58] <Mavrik> CrashSys, that looks like something gets misparsed by your shell [17:58] <naprac> hmm configure didn't even run [17:58] <Mavrik> CrashSys, also I'm not sure if that's the correct syntax for multiple jpegs -_- [17:59] <CrashSys> I'm looking at the -f image2 webpage [17:59] <c_14> That isn't the correct syntax, you'll either need the concat demuxer or the image2 demuxer. [17:59] <CrashSys> Here we go: ffmpeg -r 5 -f image2 -i %03d-capture.jpg -codec:v libx264 -crf 24 -preset fast -vf scale=480:270 /root/test.mp4 [18:00] <CrashSys> that seems to be working. The images are zero padded up to 3 spaces [18:00] <CrashSys> so %03d should have given me 3 zero padding in the sequence [18:00] <naprac> isn't thre something like sane-defaults option? [18:01] <Mavrik> there's no such thing as sane defaults for what people do with ffmpeg [18:01] <Mavrik> also, video encoding is hard :/ [18:01] <naprac> lol [18:01] <CrashSys> ^ [18:01] <naprac> is there -all? [18:02] <c_14> naprac: Most things are enabled by default unless they need external libraries. [18:02] <c_14> Or are under gpl etc. [18:02] <c_14> Check ./configure --help [18:02] <naprac> why didny' the configure then run withput any options? [18:03] <CrashSys> Hmmm, the images are zero padded for 3 digits, but actually go up to 4 digits sequentially :| [18:03] <c_14> You can use the glob option. [18:03] <c_14> -pattern_type glob [18:04] <CrashSys> duration looks right according to ffmpeg -i though [18:04] <c_14> naprac: what was the error? [18:05] <naprac> no erro, it just hanged [18:05] <naprac> what wast the alsa option , cam't find it [18:06] <c_14> It might take a while. [18:07] <naprac> well i founf x11grap and it's no [18:07] <c_14> alsa might be on by default, it should be an indev [18:07] <naprac> so i need that, but can't find alsa, maybe using different name? [18:07] <c_14> --enable-indev=alsa or something [18:07] <c_14> But I think it's enabled by default. [18:08] <c_14> Yeah, it's an indev, it should be on by default. [18:09] <naprac> well x11 needed gpl, sigh well see if that was enough [18:09] <naprac> it doesn't run [18:10] <c_14> configure? [18:10] <c_14> Might take a few seconds. [18:11] <naprac> ok, now it gave at last lines: License: GPL version 2 or later Creating config.mak, config.h, and doc/config.texi... [18:11] <naprac> wonder if it finished went real fast though [18:12] <naprac> shouldn't it say that configured ok or somesuch? [18:13] <saste> anyone has experience with live streaming from ffserver to web browsers? [18:13] <saste> tried several combinations only very few seems working [18:13] <naprac> well it starts compiling [18:13] <c_14> As soon as it says creating it should be done [18:14] <naprac> lots of warning and depracated lines, doesn't look normal but no errors yet [18:15] <c_14> warnings and deprecations are normal [18:18] <naprac> is there a gui for ffmpeg? [18:18] <c_14> Probably, but I wouldn't know of one. [18:19] <CrashSys> Hmmm. The test video from that ffmpeg command looks good until I try to seek in windows media player, then I get green artifacts all over the place [18:20] <c_14> How about something that isn't windows media player? [18:21] <CrashSys> I guess it does that til it hits a keyframe or something? [18:21] <CrashSys> Yeah, loading up MPC [18:21] <c_14> Might be. [18:23] <CrashSys> yeah MPC works fine [18:23] <CrashSys> Although the jpegs are supposed to be 10 minutes long and the mp4 is 9m30s [18:24] <CrashSys> so not sure if that's just the whole thing getting shortened or what [18:25] <c_14> You might want to set the output fps, also switch from -r to -framerate on the input side. (it probably isn't breaking anything, but it's good practice) [18:25] <CrashSys> ok [18:26] <CrashSys> so specify -framerate 5 after -i? [18:27] <c_14> before -i, instead of -r 5 [18:27] <CrashSys> ok [18:29] <naprac> takes time to compile, went to a coffe and still isn't finished [18:30] <CrashSys> Oh nevermind it's right [18:30] <CrashSys> Thanks for all the help guys :) [19:18] <naprac> doesn't work with the new version either [19:20] <FrEaKmAn_> hi all... [19:21] <naprac> it started whining: Unrecognized option 'crf' then when i removed that from command Unrecognized option 'preset' remove that it says Unknown encoder 'libx264'<sigh> [19:21] <FrEaKmAn_> is there a different if I run ffprobe and one file reports Stream #0.0(und): Video: h264 (High), yuv420p, 640x360, 522 kb/s, 24 fps, 24 tbr, 12288 tbn, 48 tbc and other Stream #0.0(und): Video: h264 (High), yuv420p, 640x360 [PAR 1:1 DAR 16:9], 750 kb/s, 24 fps, 24 tbr, 12288 tbn, 48 tbc [19:21] <FrEaKmAn_> so no PAR and DAR [19:21] <c_14> naprac: You didn't compile with libx264 support (probably) [19:21] <FrEaKmAn_> because I'm trying to figure it out why if I concat these 2 files, it does not work [19:21] <naprac> probably and probably whatever else [19:22] <FrEaKmAn_> ok [19:22] <naprac> is there any *sure* way to record video and audio with this config i only enabled x11grab? [19:24] <c_14> Use a built in codec. [19:25] <c_14> ffmpeg -codecs [19:26] <naprac> that shows --enable-libx264 as configuration option? [19:27] <c_14> Can you pastebin your output? [19:27] <naprac> wait no [19:28] <FrEaKmAn_> c_14: http://pastie.org/private/8okpiwcu60khgtcqccglq [19:29] <naprac> now i have two ffmpegs, so it printet the old verions config [19:29] <naprac> okay, now with new one -codecs param what am i looking from this? [19:30] <FrEaKmAn_> c_14: the point is that video_flv.mp4 and video_mp4.mp4 work [19:30] <FrEaKmAn_> only when concat it fails and flv fails [19:30] <naprac> whats the name of builtin codecs? [19:32] <naprac> mpeg4? [19:33] <FrEaKmAn_> + I get Non-monotonous DTS in output stream 0:1; previous: 7561013, current: 5646397; changing to 7561014. This may result in incorrect timestamps in the output file. [19:33] <c_14> naprac: Just pick one you like in that list. [19:34] <FrEaKmAn_> it's looks like a bug https://trac.ffmpeg.org/ticket/3553 [19:35] <naprac> it doesn't accept anything i tried -vcodec mpeg4 and flv1 [19:35] <c_14> FrEaKmAn_: you can't just concat flv with h264, if that's what you're trying to do [19:35] <c_14> naprac: Just pastebin your whole cammand and output please [19:35] <FrEaKmAn_> c_14: but I converted it to mp4 [19:36] <c_14> mp4 is a format, not a codec [19:36] <FrEaKmAn_> with libx264 codec [19:36] <naprac> how do i recognice what is a codec from ffmpeg -codecs output? [19:37] <naprac> i.e. what is correct parameter to -vcodecs [19:42] <naprac> mayde if i reconpile it with old versions configure parameters? [19:52] <c_14> naprac: everything with an E and a V [19:53] <c_14> FrEaKmAn_: can you paste the comulete commandline and full output of the concat command [19:53] <naprac> i alrady started to recompile with options copied from old versions -codecs output ;) [19:56] <naprac> well mpeg4 has both e and v but -vcodec mpeg4 didn't work [19:57] <FrEaKmAn_> c_14: http://pastie.org/private/bzhc0jblbqdu169focq54g [19:57] <c_14> It doesn't look like it's erroring out, what's the problem. [19:57] <c_14> s/\./? [20:06] <naprac> what is the most simple form of command to record video and audion from screen? just using defaults something [20:09] <c_14> ffmpeg -f x11grab -i :0.0 out.mkv [20:10] <naprac> that takes audio too? [20:10] <c_14> No [20:10] <c_14> ffmpeg -f x11grab -i :0.0 -f alsa -i hw:0 out.mkv [20:10] <c_14> should [20:11] <c_14> But it depends on the hardware device you want to record [20:12] <TD-Linux> if you use pulse you want to record from a loopback device [20:13] <naprac> Unrecognized option 'i:0.0'. [20:13] <TD-Linux> you forgot a space [20:15] <davis> hello [20:15] <davis> i'm reading a book and trying to use it to learn ffmpeg. it has the following example usage: ffmpeg -f lavi -i rgbtestsrc -pix_fmt yuv420p -f sdl Example [20:16] <davis> it appears -f sdl no longer works. any workaround? [20:16] <sfan5> ffplay -f lavfi -i rgbtestsrc does the same [20:16] <sfan5> except that it doesn't convert to yuv420p pixel format before displaying [20:18] <davis> sfan5: i get an error with ffplay, it says unknown input format: lavfi [20:18] <sfan5> your ffmpeg might be outdated [20:19] <sfan5> I just tested using -f sdl [20:19] <sfan5> and "ffmpeg -f lavfi -i rgbtestsrc -pix_fmt yuv420p -f sdl -" works fine [20:19] <FrEaKmAn_> c_14: isn't Non-monotonous DTS in output stream an error? [20:20] <c_14> An error is something that causes ffmpeg to stop running. [20:20] <c_14> Everything else is a warning. [20:20] <davis> hmm. i just tried to update it. i guess this distro's stable version is old. I'm the latest version for this distro. i'll try to get a custom built one working. thanks. [20:21] <FrEaKmAn_> c_14: makes sense.. but output video is not playable [20:21] <FrEaKmAn_> at least the part where flv is [20:24] <c_14> The one from the flv is concated second? [20:24] <naprac> okay, this sort of works but the video is not good quality [20:25] <naprac> btw, why an earth isn't that command in the example page instead of the cryptic one that doesn't even work? [20:25] <FrEaKmAn_> c_14: first, second, in the middle [20:25] <FrEaKmAn_> everywhere same error [20:25] <FrEaKmAn_> when playing [20:25] <c_14> But only the one from flv doesn't play correctly? [20:26] <FrEaKmAn_> if flv is included in concat, then video is not playable [20:26] <c_14> naprac: because the one on the wiki shows all the options you can use with the format, and the quality - what codec did you use? [20:26] <FrEaKmAn_> actually, the other parts is [20:27] <FrEaKmAn_> and flv part is only few seconds [20:27] <FrEaKmAn_> so it's really confusing [20:27] <FrEaKmAn_> other parts are* [20:27] <naprac> i assume it uses mpeg4 i didn't specify any [20:27] <c_14> The only difference I can see in the ffprobes between the video from mp4 and the other ones is that the one from flv doesn't have a sar/dar listed. You might want to try setting that manually. [20:28] <naprac> Metadata: ENCODER : Lavf55.48.100 [20:28] <FrEaKmAn_> c_14: actually I updated the convert parameter and added -scala 16:9 [20:28] <FrEaKmAn_> only different I see is audio and I'm trying to convert to same bitrate and samplerate [20:28] <FrEaKmAn_> -scale* [20:29] <c_14> FrEaKmAn_: Do you mean -aspect or -s, I don't know of a -scale. [20:29] <FrEaKmAn_> yes sorry, -aspect 16:9 [20:29] <c_14> naprac: that's just the libavformat library version, either ffprobe the output file or do a ffmpeg -h muxer='whatever muxer you used) [20:29] <c_14> And that doesn't help? [20:29] <FrEaKmAn_> I'm getting confused with all of these parameters :) [20:30] <naprac> c_14, thats from ffprobe, i just don't know what to get from there ;) there is also Stream #0:0: Video: mpeg4 (Simple Profile), yuv420p, 1300x736 [SAR 1:1 DAR [20:31] <c_14> >mpeg4, it says right there [20:31] <FrEaKmAn_> c_14: is was audio problem.. it works now [20:31] <naprac> thats what i said in first place [20:31] <FrEaKmAn_> only problem is there is no sound [20:31] <FrEaKmAn_> :( [20:31] <naprac> so i assume mpeg4 compresses alot and therefor the video is blurry? [20:31] <naprac> which codec makes best quality? [20:32] <c_14> naprac: Something along those lines, yes. mpeg4 is not that great a codec. [20:32] <c_14> 'best quality' would technically be a lossless codec, but h.264 is usually considered a good choice for most video encoding if you don't want something lossless. [20:32] <FrEaKmAn_> naprac: I'm using libx264 with -crf settings [20:33] <naprac> that doesn't work for me it whines -crf not recogniced [20:33] <naprac> i need to use builtin codecs [20:33] <naprac> whuch one is best of those? [20:36] <FrEaKmAn_> naprac: are you using latest version of ffmpeg? [20:36] <naprac> yes [20:36] <naprac> but i didn't know what to compile in so i only have x11grab and cpl [20:36] <JEEB> if you want to compress, just get a binary that can use libx264 :P [20:36] <JEEB> nothing comes close [20:37] <c_14> JEEB: static builds don't have x11grab [20:37] <JEEB> yes, then he has to build himself [20:37] <JEEB> x264 is not exactly hard to compile [20:37] <naprac> i have it recompiling with libx264 in another window, but it takes time [20:37] <JEEB> --enable-static methinks for a static library to be installed in addition to the x264 command line app [20:37] <JEEB> for x264, that is [20:37] <JEEB> and then just --enable-libx264 --enable-gpl needed from ffmpeg [20:38] <JEEB> anyways, you can just put all of the lavc internal lossy encoders as something that won't get you a good compression ratio, and none of them have anything close to x264's preset system [20:40] <naprac> i used conf options from the old install not sure if all those are needed anymo: --disable-debug --enable-shared --disable-static --enable-pthreads --enable-libtheora --enable-libvorbis --enable-gpl --enable-version3 --enable-postproc --enable-swscale --enable-x11grab --enable-avfilter --arch=i486 --enable-libmp3lame --enable-libx264 [20:41] <JEEB> lol [20:41] <naprac> not good? [20:42] <JEEB> sounds like the usual "I copied this off of a compilation guide ages ago" [20:42] <FrEaKmAn_> any ideas why there is no sound? I'm using -ar 22050 -ab 32 when converting (full at http://pastie.org/9432258) [20:42] <JEEB> or well, reads like :P [20:42] <JEEB> and that's not even mingw, where you used to need some weird-ass parameters [20:43] <JEEB> let's just say that start from a clean slate, and then enable the things you need :P [20:43] <JEEB> also are you really running this on a 486? [20:44] <naprac> well thats from old versions ffmped -codecs output so i guess so, it was a version that came with os, it's old too [20:44] <c_14> FrEaKmAn_: Maybe try using a bitrate larger than 32bit/s ? [20:44] <naprac> this is an old puter too [20:44] <JEEB> yes, but is it a 486? [20:45] <naprac> what was the command to get cpuinfo? [20:45] <FrEaKmAn_> c_14: I need specify as {number}k [20:45] <JEEB> lscpu [20:45] <FrEaKmAn_> otherwise its just bits [20:46] <c_14> yes [20:46] <FrEaKmAn_> after so much work I think I solved it :) [20:46] <naprac> Architecture: i686 [20:46] <JEEB> yeah, I would be surprised if you had a 486 there :P [20:47] <JEEB> and most compilers either default to 686 or 586 [20:47] <JEEB> (32bit) [20:47] <naprac> well i don't think that means alot, or does it? [20:47] <JEEB> you can't use SSE f.ex. [20:47] <JEEB> heck, you can't use goddamn pentium instructions :P [20:47] <naprac> so i should change that to i686? [20:47] <JEEB> just leave it out [20:47] <JEEB> that's what I'm trying to say [20:48] <JEEB> basically start off a clean sheet [20:48] <JEEB> and enable the stuff you need [20:48] <naprac> what else to leave out? or even better what is a prober line for conf? [20:48] <JEEB> tell me what you need [20:48] <JEEB> from the build [20:48] <JEEB> other than "runs on my computer" [20:48] <onyx> Hey guys, I have an IP camera that has no audio, and Im feeding it into wowza to restream, it works fine in desktop but not im mobile, do you think I can transcode the video from the IP camera with FFmpeg and feeding that into wowza would work? [20:49] <naprac> record video from screen with audio and sometimes crab images from video or edit size of video or crab audio out of video to flac and increase volume of flac files [20:50] <naprac> hmm i think thats pretty much what i ever do with ffmpeg ;) [20:50] <JEEB> let's make it like this: most of the things internal are enabled by default, except for the GPL parts (of which there are very little in general) [20:50] <JEEB> GPL is generally needed by external libraries [20:51] <JEEB> most external libraries are encoders [20:51] <naprac> i was happy with the old ffmpeg until i today tried to record a video with audion from screen which instantiated all this ;) [20:52] <naprac> okay now i have new compilation ready [20:52] <JEEB> I will guess that you will want something like --enable-gpl --enable-x11grab --enable-libx264 for the screen capture and lossy video coding, and if you already have libvorbis and libmp3lame installed you might as well enable those too [20:53] <JEEB> everything else I see in that configuration is pretty much useless [20:53] <JEEB> esp. if you only want the ffmpeg command line app [20:54] <JEEB> postproc is not really used, avfilter and swscale are enabled by default. No idea about x11grab's license, but unless it is GPLv3 you don't need --enable-version3 (because all it does is switch you from GPLv2 to GPLv3 - mostly needed for apache v2 licensed things, as only GPLv3 is compatible with it) [20:54] <naprac> this is the current conf: --disable-debug --enable-shared --disable-static --enable-pthreads --enable-libtheora --enable-libvorbis --enable-gpl --enable-version3 --enable-postproc --enable-swscale --enable-x11grab --enable-avfilter --arch=i486 --enable-libmp3lame --enable-libx264 [20:54] <naprac> how would you change it? [20:54] <JEEB> what I just said [20:55] <naprac> no, can you edit that one [20:55] <JEEB> I did [20:55] <JEEB> those three for screen capture, and enable mp3lame and vorbis if you already have them installed as libraries [20:56] <JEEB> and if x11grab will fail at configuration, then maybe enable-version3. But I would be surprised if it needs GPLv3. [20:56] <onyx> Hey guys, I have an IP camera that has no audio, and Im feeding it into wowza to restream, it works fine in desktop but not im mobile, do you think I can transcode the video from the IP camera with FFmpeg and feeding that into wowza would work? [20:56] <FrEaKmAn_> c_14: btw, thanks! [20:56] <naprac> this is good?: --enable-libvorbis --enable-gpl --enable-x11grab --arch=i686 --enable-libmp3lame --enable-libx264 [20:57] <JEEB> leave the arch out [20:58] <naprac> you sure i don't need that other stuff libtheoras etc? [20:58] <JEEB> I've explained the uselessness of some of those [20:58] <JEEB> and theora is a case of "no-one but hardcore freetards uses this" [20:59] <JEEB> there's a theora decoder in lavc internally, and thus you only gain the encoder from it [20:59] <naprac> ic, ok, i compile third...and hopefully a final time ;) [20:59] <naprac> but lets 1st try with this one if it can do the example [21:02] <naprac> https://trac.ffmpeg.org/wiki/Capture/Desktop does the last example work with your install? [21:03] <naprac> it doesn't work with new with old options including libx264 either [21:03] <JEEB> I'm going to bet on the shared libraries [21:03] <naprac> yes [21:03] <naprac> error while loading shared libraries: libavdevice.so.55: cannot open shared object file: No such file or directory [21:03] <JEEB> just build with the settings we discussed [21:03] <naprac> okay [21:03] <JEEB> ffmpeg by default builds static libraries [21:04] <JEEB> you SPECIFICALLY disabled those and enabled shared library usage [21:04] <JEEB> shared libraries are nice when multiple apps use those libraries, and when they are installed to a globally available directory (default library loading path) [21:05] <JEEB> shared libraries are not nice when you "Just Want To Compile A Binary And Run It In Its Directory" [21:05] <naprac> beast of a program, have to say ;) [21:05] <JEEB> also don't forget to do make distclean between the compiles to clean the build directory up :P [21:05] <JEEB> clean up -> configure -> build [21:06] <naprac> now tou saying ;) [21:07] <naprac> well done, now 4th conf [00:00] --- Thu Jul 31 2014

1 0

ffmpeg-devel.log.20140729
by burek 30 Jul '14

30 Jul '14

[00:11] <cone-572> ffmpeg.git 03Bernhard Übelacker 07master:dc71f1958846: video4linux2: Avoid a floating point exception [00:11] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:25a20608909f: Merge commit 'dc71f1958846bb1d96de43a4603983dc8450cfcc' [00:17] <cone-572> ffmpeg.git 03Marc-Antoine Arnaud 07master:c9d982aa11a6: mxf: Detect Vanc/Vbi SMPTE-436M mxf track [00:17] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:4a4d0258eef2: Merge commit 'c9d982aa11a6267611c3770792f0e04b48438348' [00:26] <cone-572> ffmpeg.git 03Marc-Antoine Arnaud 07master:259fe7280d0b: mxf: Extract origin information from material and source track [00:26] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:8b1e920676f6: Merge commit '259fe7280d0b63dc7a8ff017d44f26d3a84cfde8' [00:34] <cone-572> ffmpeg.git 03Luca Barbato 07master:e4a462e3eafd: configure: Use require_pkg_config for Speex [00:34] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:621d4089a4cf: Merge commit 'e4a462e3eafdfe336f4d079c3ba72a9cdb4748b0' [00:40] <cone-572> ffmpeg.git 03Diego Biurrun 07master:4f8cf0dc4ef6: x86: build: Restore ordering of OBJS lines [00:40] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:a91c5ed00874: Merge commit '4f8cf0dc4ef6110174056df7edd9dc2f2a988b6d' [01:22] <cone-572> ffmpeg.git 03Diego Biurrun 07master:59ca29a560ba: dump: Use correct printf conversion specifiers for POSIX int types [01:22] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:60831f441db8: Merge commit '59ca29a560ba0cfe97457de8cedf77db434f0de4' [01:29] <cone-572> ffmpeg.git 03Diego Biurrun 07master:019a28cd6302: sanm: Use correct printf conversion specifiers for POSIX int types [01:29] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:d55d8229fb12: Merge commit '019a28cd630286ecb2b06ee62025a17c821b493e' [01:51] <cone-572> ffmpeg.git 03Diego Biurrun 07master:942269fd00cb: caf: Use correct printf conversion specifiers for POSIX int types [01:51] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:983109bbd999: Merge commit '942269fd00cb48328e4cffb6e21a0b691ce9f6bc' [02:03] <trn> Is there a separate channel for NUT discussion or just nut-devel list? [02:04] <beastd> trn: http://lists.mplayerhq.hu/mailman/listinfo/nut-devel [02:05] <kierank> sooo who is going to vdd? [02:07] <Compn> i might be there, just to annoy everyone again :) [02:07] <kierank> michaelni: are you going? [02:08] <beastd> kierank: Not me this year :( I will be in Shanghai at that time. [02:10] <Compn> i'd like to visit china one of these days [02:35] <trn> BTW, to get my wallclock timecode into NUT, I'm just using the v4 timestamped syncpoint feature. [02:36] <trn> Is there any sort of documentation as to the memory requirements or what not ... I'm looking at some streams up to 12 hours... [02:38] <Timothy_Gu> beastd: reallh? [02:38] <Timothy_Gu> really [02:39] <Timothy_Gu> I am from Shanghai [02:45] <Timothy_Gu> shoot beastd quitted [03:51] <cone-572> ffmpeg.git 03James Almer 07master:4f91bb0ff0bd: x86/hevc_deblock: use psignw instead of pmullw where possible [04:05] <cone-572> ffmpeg.git 03Christophe Gisquet 07master:65746bfbae3d: hevc_filter: run vertical and horizontal together [13:36] <cone-104> ffmpeg.git 03James Almer 07master:c74b08c5c60a: x86/hevc_deblock: remove some unnecessary instructions [14:04] <cone-104> ffmpeg.git 03James Almer 07master:88ba821f23cb: x86/hevc_deblock: improve luma functions register allocation [14:36] <cone-104> ffmpeg.git 03James Almer 07master:73c4f63ba5a3: x86/hevc_deblock: add add ff_hevc_[hv]_loop_filter_luma_{8, 10, 12}_avx [15:30] <ubitux> when will we be able to clic on hashes in the trac? [15:38] <ubitux> btw, does h264 have some kind of pyramidal MV structure? [15:38] <ubitux> like, saying a large zone is moving from one point to another [15:39] <ubitux> and inside MV are smaller vectors relative to that larger zone movement [15:39] <ubitux> ? [15:44] <mraulet> ubitux: is it x264 or h264? [15:46] <ubitux> well, i'm asking decode side [15:47] <ubitux> so h264 [15:52] <mraulet> so i dont get your question, the decoder is not guessing anything, it takes MV predictors and adds deltas on top of it (dmvx, dmy). Those 2 values are given by the parser. [15:52] <nevcairiel> he is just wondering if h264 has such a feature, a "semi-global" mv that gets "refined" by local mvs [15:59] <ubitux> mraulet: yeah as nevcairiel says, i'm asking if in the MV are stored in such structure [16:00] <ubitux> that actually reveals a larger motion [16:00] <kierank> are you talking about GMC? [16:00] <mraulet> the predictors are quite simple in H264 [16:04] <ubitux> kierank: not really [16:05] <ubitux> or at least i don't know [16:05] <ubitux> mraulet: so only a vector, not relative to another bigger one? [16:10] <mraulet> http://vc.cs.nthu.edu.tw/home/paper/codfiles/kcyang/200407191716/H.264_Moti… [16:10] <mraulet> slide 7 [16:34] <ubitux> mraulet: ok so the answer is... "no" i guess :p [16:34] <mraulet> :-) [16:36] <nevcairiel> wonder how complex detection that would be [16:36] <nevcairiel> i guess you could just look at all the MVs and try to "normalize" them [16:38] <ubitux> it's strange though [16:38] <ubitux> would that help to say half of the frame should go to the other half [16:38] <ubitux> and encode way smaller MV inside that? [16:38] <ubitux> i would have though h264 had that [16:39] <michaelni> "<ubitux> when will we be able to clic on hashes in the trac?", is there a plugin that does that or some configuration ? [16:40] <nevcairiel> ubitux: i would think it would help in something like pans, whole image pans, small parts move in other directions, but apparently it was never considered, maybe not as useful as we might think [16:42] <cone-104> ffmpeg.git 03Nicolas Martyanoff 07master:0c889da8cb53: avformat/hlsenc: fix cleanup after avformat_write_header() [16:45] <Plorkyeran> the standard git plugin for trac linkifies hashes [16:45] <Plorkyeran> you just need a local copy of the repository that's auto-synced [16:48] <Daemon404> x/g 42 [16:48] <Daemon404> urg [17:12] <ubitux> mmh [17:13] <ubitux> .alias = "gray8,y8" [17:13] <ubitux> :/ [17:23] <nevcairiel> Another hack to please someone's feelings about bad names [17:24] <Daemon404> AV_PIX_FMT_RACIAL_SLUR [18:28] <michaelni> ubitux, Plorkyeran i tried enabling git in trac but it doesnt work [18:30] Action: michaelni is an idiot [18:30] <michaelni> trac.versioncontrol.* = disabled [18:30] <michaelni> ill make a break and then ill retry :) [19:15] <Daemon404> always interesting bug titles [19:18] <michaelni> ubitux, Plorkyeran, enabling git in trac makes ticket load times increase 6 fold 0.4 sec ->2.4 sec (for ticket 3143 which AFAICS has 1 git hash in it) [19:19] <kierank> Daemon404: that's truly a mental feature [19:19] <michaelni> so i left it disabled ATM, unless someone has some idea [19:20] <Daemon404> kierank, is line 31 anythign special in broadcast land? [19:20] <Daemon404> i dont recall it being so [19:20] <kierank> probably he's measuring from a weird offset [19:20] <Daemon404> yeah cause teletext is not 31 [19:20] <michaelni> ubitux, Plorkyeran, that was with cached_repository = false, with it true its another 0.2 sec slower [19:20] <kierank> teletext is line 7-22 iirc [19:21] <michaelni> also repository_sync_per_request empty which AFAIK means disabled [19:22] <michaelni> ahh, hi beastd, trac+git sucks see above [19:22] <kierank> Daemon404: oh i think he's counting in literal lines [19:22] <kierank> and ignoring field 2 [19:22] <Daemon404> o [19:23] <kierank> that is truly a mental way of detecting subtitles [19:24] <kierank> isolate a line and run blackdetect on it [19:24] <Daemon404> :D [19:28] <beastd> michaelni: I do not remember it being that slow at work. It probably depends on the size of the git repo or sth. Need to check the settings and performance next week. [19:30] <michaelni> beastd, isnt important at all, we didt had it for 3 years, i just find it ridiculous how everyone manages to write software that is so slow, i mean if this was a 8bit cpu running at 5khz i could understand why doing a single hash table lookup would need a few milliseconds but hey modern multi ghz multi core cpu needing several seconds [19:32] <Daemon404> michaelni, trac is famously slow [19:33] Action: Daemon404 remembers it doing 10k db queries per page for one project [19:33] <michaelni> i know i did spend many hours trying to workaround that and trim all kinds of uneeded stuff away [19:33] <Daemon404> that doesnt sound fun [19:33] <Daemon404> its an old php codebase [19:34] <michaelni> it was more trimming config than looking at trac code [19:35] <JEEB> Daemon404, trac is python [19:35] <JEEB> not php [19:35] <michaelni> for example the search page load time is proportional to the number of columns displayed [19:35] <JEEB> but yes, it's very awful [19:35] <j-b> JEEB: no, trac is crap [19:35] <j-b> JEEB: not python [19:35] <Daemon404> oh youre right [19:35] <Daemon404> i keep thinking it is php [19:35] <Daemon404> because it is so terrible [19:36] <Daemon404> but less terrible tahn all the otehrs. [20:01] <jamrial> That Semel88 account also posted another spam attachment in the same ticket six weeks ago [20:07] <cone-631> ffmpeg.git 03Luca Barbato 07master:e253a9e2b3d6: avformat: Move av_probe_input* to format.c [20:07] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:e066f01539fd: Merge commit 'e253a9e2b3d683eb51db7c776326eb07de10ad4c' [20:31] <cone-631> ffmpeg.git 03Luca Barbato 07master:69e7336b8e16: avstring: Expose the simple name match function [20:31] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:31e0b5d3cb40: Merge commit '69e7336b8e16ee65226fc20381baf537f4b125e6' [21:10] <cone-631> ffmpeg.git 03Luca Barbato 07master:3a19405d574a: avformat: Use the mime type information in input probe [21:11] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:80a3a6611fe5: Merge commit '3a19405d574a467c68b48e4b824c76617fd59de0' [21:11] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:9694695a21d0: avformat: fix probe mime version checks [21:17] <cone-631> ffmpeg.git 03Luca Barbato 07master:02cf0c9e4296: aac: Register the mime type [21:17] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:8cad746093db: Merge commit '02cf0c9e42967de1e4d2803bee3573bc5b735fdd' [21:26] <cone-631> ffmpeg.git 03Luca Barbato 07master:fa38573cd9ce: matroska: Register mime types [21:26] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:92de4450347c: Merge commit 'fa38573cd9ce4ab727f86f57c03b113cfd4c9d0a' [21:32] <cone-631> ffmpeg.git 03Nidhi Makhijani 07master:ccbf370f2000: mpegvideo: move vol_control_parameters to the only place it is used [21:32] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:58eaa95116d9: Merge commit 'ccbf370f2000b9b27f4af259c23007d67f7ea46e' [21:56] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:6d69503883da: avformat/format: simplify ifdeffery [21:56] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:4182728c7873: avformat/format.c: remove duplicate include, put libavutil includes together [21:56] <cone-631> ffmpeg.git 03Michael Niedermayer 07master:d38edeee9b70: avformat/format: fix memleak and error code [23:11] <wm4> so, there's this nice function av_opt_set_from_string() [23:11] <wm4> but where's the equivalent for parsing into a AVDictionary? [23:11] <wm4> since since things like protocols for formats don't allow setting options directly, and you must pass an AVDictionary of options [23:47] <cone-631> ffmpeg.git 03Christophe Gisquet 07master:a507623bad7e: x86: hevc_mc: fix register count usage [00:00] --- Wed Jul 30 2014

1 0

ffmpeg.log.20140729
by burek 30 Jul '14

30 Jul '14

[04:52] <troy_s> michaelni: Got the one up. [04:53] <troy_s> michaelni: Going to test the second again. My values are theoretically ideal floats. Poynton's have the (rather silly) multiplied versions. [04:53] <troy_s> michaelni: Needless to say, I want to test to be certain. [05:03] <ogrgkyle> hello [05:03] <ogrgkyle> anyone use rtmpdump? [05:34] <michaelni> troy_s, the bug you reported is about +-1 differences, that is for all we know it might be a difference in the rounding [05:35] <troy_s> michaelni: Absolutely. I'm a little more concerned about the full range version. [05:35] <michaelni> but what you post says no word about the rounding [05:35] <troy_s> michaelni: Because I have no clue where the deviation is coming from. [05:35] <michaelni> deviation to what ? [05:35] <troy_s> michaelni: To the theoretical. [05:35] <troy_s> (As in proper via a calc, then rounded.) [05:36] <michaelni> you will not get the same rounding between fixed and floating point implementations normaly [05:36] <michaelni> noone does rgb <->ycbcr in float [05:38] <michaelni> not to mention why would float be better [05:38] <troy_s> michaelni: Well float is pretty typical in most industrial imagers, and most use matrices to calc the YCbCr. So it isn't a stretch. [05:38] <troy_s> michaelni: Just keeps the quantization errors to a minimum up to the round. [05:39] <michaelni> everyone with a brain used fixed point [05:39] <troy_s> michaelni: Two different design sets of needs. [05:39] <michaelni> the need is to have no brain ? [05:39] <troy_s> The reality of needing performance for a playback situation versus the need for accuracy for image extraction. [05:39] <troy_s> LOL [05:39] <michaelni> float is less accurate [05:39] <michaelni> for this [05:39] <troy_s> Not 32 bit float. [05:39] <michaelni> than 32bit fixed point would be [05:40] <troy_s> (Which is again where all industrial imagers live.) [05:40] <troy_s> Does the intermediate depth sit fixed in FF? [05:40] <troy_s> Or is it based on various context? [05:41] <troy_s> (And really, this ultimatley boils down to quantization errors and the variance between input to output on a round trip. That's probably the best baseline we can have.) [05:43] <michaelni> what intermediate depth ?, the one in the matrix multiply? see the code [05:43] <michaelni> i mean we move 100% in circles here none of these questions move us forward [05:44] <troy_s> Well the deviations are large enough to impact the round trip as they stand. [05:45] <troy_s> If there is a clean way to improve them, it might be worth exploring. (Assuming we can get a round trip down clean.) [05:45] <michaelni> troy_s, if you have a testcase that shows any of this please provide that testcase [05:45] <troy_s> I've shown the variance between the theoretical and the output. If we assume we see two sets of that (one for an encode, one for a decode) I think it is pretty safe that the round trip will be off. [05:46] <troy_s> (And there's no real reason it should at 444 full range.) [05:46] <troy_s> Fair point? [05:47] <michaelni> troy_s, ive asked since days for a testcase and you provided nothing solid [05:47] <troy_s> I have the PNG! [05:47] <troy_s> That's the test. That's direct dumps of the channels. [05:47] <troy_s> I'm not sure I can do any better within the limited realm of my understanding. [05:47] <michaelni> you made the PNG [05:47] <troy_s> (Entirely plausible I'm a dimwit however and missing the goal here.) [05:48] <troy_s> I generated one off of a 32 bit float reference EXR, and generated an 8 bit equivalent with rounded values. [05:48] <troy_s> I also generated the raw YCbCr out of ffmpeg and dumped those channels into a PNG as well. [05:49] <troy_s> So we have theoretical and ffmpeg, and the deviation tells us that we are already drifting in some manner, which is not really plausible given 8 bit 444 at full range. [05:49] <michaelni> if you say that the roundtrip is suboptimal then a testcase is to show that rgb24-> ycbcr24 -> rgb24 is worse than it could be, iam sure it is but to fix it we need a testcase [05:50] <troy_s> michaelni: Although you can help on the re-encode version - what is the correct syntax for an encode from raw YCbCr ("yuv" in ffmpeg's busted phrasing) to an RGB output using the scale flags? [05:50] <troy_s> Ok. [05:50] <troy_s> So I need that command (in terms of the best knowledge, of which I am quite certain you are the highest qualified expert to answer) [05:51] <troy_s> (I can conduct the round trips painlessly to and fro using the math and other tools, but not ffmpeg.) [05:51] <troy_s> (And to be fair to ffmpeg, the studio range dump only shows errors inthe gradient, which is rather impressive, but still i think we can aim higher.) [05:52] <troy_s> (And apologies for seeming pedantic on this, but the only way we can move onward to tackling the codec level is to assert with 100% certainty that the transforms are as accurate as they possibly can be.) [05:52] <michaelni> troy_s, IMHO your reference is very far away from optimal output [05:53] <michaelni> round to nearest is not optimal, you would need some dither or noise shaping [05:53] <michaelni> and iam just assuming you did round to nearest, i think you never stated that [05:54] <michaelni> also which was x+0.5 is rounded is also something that might differ [05:55] <michaelni> do the specs even say how to round? or what precission the coefficients should have ? [05:56] <troy_s> michaelni: I took a round to nearest because that's the RGB image. [05:56] <troy_s> We don't want to futz the round trip, so dither would make no sense. [05:56] <troy_s> (Certainly for perceptual or something, but not in this context.) [05:57] <troy_s> michaelni: The coefficients can go as deep as one wishes. [05:57] <troy_s> (Based off of the white point and primaries, you can take it to as far as is required. In some instances, deeper can hold the integrity of the data where needed.) [05:58] <troy_s> (and yes, regarding the offset for full range, the theoretical is directly in the middle of the Cb or Cr axis, which is 0.5. I've got an email to Poynton on that subject coincidentally. Shall see how he responds, but all of his literature suggests the theoretical.) [05:59] <troy_s> I think the most logical baseline is that if we encode an 8 bit sRGB image, and round trip it through 444 full range YCbCr, we should expect 1:1 back as an ideal. [06:00] <michaelni> troy_s, no [06:00] <troy_s> ? [06:00] <troy_s> That's a pretty reasonable baseline. [06:00] <troy_s> Example, encoding to ProRes from a master [06:00] <troy_s> or DNxHD. [06:00] <troy_s> Very reasonable. [06:01] <troy_s> Suggesting that there is a necessary degredation of image quality at equivalent models and depths (eg 8 bit RGB at 444 YCbCr 8 bit) is reasonable. [06:01] <troy_s> (The extreme edge cases of quantization aside.) [06:01] <troy_s> (Not sure what the theoretical count of those is, but I'm guessing it is extremely slight if any.) [06:02] <troy_s> (And should diminish as we increase our bit depths.) [06:03] <troy_s> Do you happen to know the single frame encode from rawvideo in ffmpeg? [06:03] <michaelni> troy_s, you have 2^24 RGB values but they are mapped on fewer than that ycbcr values as not the whole 2^24 cube of ycbcr 444 values is used thus its not possible to be 1:1 [06:03] <troy_s> (Using the newer scale commands) [06:03] <troy_s> Again, that's the edge of quantization. [06:03] <troy_s> Given that I can get a perfect 1:1 using outside tools passing to ffmpeg to encode [06:03] <troy_s> I'm thinking it's pretty reasonable. :) [06:04] <michaelni> troy_s, talking with you is hard as you use very odd terminology [06:04] <michaelni> at least for me [06:04] <troy_s> Apologies. [06:05] <troy_s> The mapping is indeed different, but we are talking some very minute adjustments. We can't even get to the encode though. [06:05] <michaelni> of course if you mutiply a matrix by its inverse you get the original but not when you quantize to 8bit in the middle [06:05] <troy_s> I'm doing all of this as an 8 bit stop. [06:05] <troy_s> (in the middle) [06:05] <troy_s> but I still need to know ffmpeg's single frame encode syntax from the rawvideo format. [06:05] <troy_s> Then I can do the conclusive end comparison. [06:06] <troy_s> (Which I've already done comparing against the source RGB) [06:06] <troy_s> (Using again, different tools to perform the transform.) [06:08] <michaelni> troy_s, google and our docs explain how to use ffmpeg, its 6o clock in the morning, i need to sleep, also iam sure others can explain how to encode a image from a video with ffmpeg [06:08] <troy_s> Okie. I've searched high and low and none have the new scale syntax. [06:08] <troy_s> (Hence why I'm asking.) [06:08] <troy_s> but get some sleep. [06:08] <troy_s> We can chat tomororw. [06:09] <michaelni> what is "new scale syntax" and how is that related to your question about "single frame encode syntax from the rawvideo format." [06:10] <troy_s> -vf scale="in_range/out_range/in_color_matrix/out_color_matrix" [06:11] <troy_s> That's the syntax I'm using for encodes, so I want to be sure the identical code paths are crossed. [06:12] <troy_s> michaelni: Sleep. [06:12] <troy_s> Night. [06:12] <troy_s> (It can wait until tomorrow.) [06:51] <ersatzbeardr> hum am i rgiht in thinking i could set up an ffmpeg worker with libav's filter graph and fire data straight out of my rasterizer (another machine) across zmq into the worker [11:17] <sspiff> Hi! I have a problem with dvb subtitle decoding. The spec states that if no Display Definition segment is present, the subtitle should be assumed to be rendered at 720x576 and upscaled accordingly. [11:18] <sspiff> However, the subtitle resolution is not something that FFMpeg exposes, and ffplay doesn't upscale the subtitles in a sample I have that expects this (standard) behavior [11:19] <sspiff> Currently, I plan on working around this by accessing the private data in the AVCodecContext and determining if a DDS is present or not, but this is not the best solution I can imagine. [11:19] <sspiff> However, I suppose that exposing this kind of information in a generic way requires some reworking in the AVSubtitle API [13:00] <Mavrik> sspiff, yes, I doubt TS input currently parses DDS [13:00] <Mavrik> but so far on all broadcasted streams I've encountered, persuming that DVB subitltes are PAL works well [13:08] <sspiff> Mavrik, a client of ours is apparently muxing Chinese and Korean subtitles as a DVB subtitle PID into an HD signal, and the subtitles are not correctly upscaled. [13:09] <sspiff> If you want, I can send you a capture. [13:10] <Mavrik> hmm, possibly [13:10] <sspiff> the dvbsubdec.c parses the DDS, not the TS demuxer or dvbsub parser. [13:10] <Mavrik> well, sending me capture really won't accomplish anything :) [15:06] <jeffreylevesque> I updated my Ubuntu 11.04 to Ubuntu 14.04. I couldn't install ffmpeg as the system suggested me to install avconv [15:08] <jeffreylevesque> could someone assist me with the equivalent code in 'avconv' - https://github.com/jeff1evesque/audio-analyzer/issues/357 [15:08] <sacarasc> Read that, also the avconv channel is #libav. [15:29] <drwx> hi, i pressed a key or something and ffmpeg outputs tons of messages like this: http://sprunge.us/HdgN how can i stop it? [15:37] <sfan5> you enabled verbose logging [15:38] <sfan5> try pressing d [18:31] <drwx> thanks sfan5, where is that documented? [18:37] <diegoviola> hi [18:37] <diegoviola> will ffmpeg replace libav in Debian? [18:47] <sfan5> drwx: pressing ? while encoding shows the help [18:47] <sfan5> diegoviola: I'd suggest asking the debian maintainers about that [18:47] <diegoviola> ok thanks [19:00] <sythe> So, why does it seem like ffmpeg is ultra fast compared to video editors? [19:00] <sythe> (when encoding) [19:01] <sythe> Regardless of how few edits are made to a video [19:02] <sacarasc> sythe: If you run ffmpeg without any commands, it will tell you. [19:02] <sythe> Hyper fast [19:02] <sythe> HEh [19:02] <sythe> *heh [19:03] <sythe> Does Kdenlive use ffmpeg? [22:56] <invintus> I would like to find a way to use a reference video to copy it's codec settings for a transcode. convert a.mp4 to b.mp4 using c.mp4's codec settings [22:57] <Mavrik> Unless the encoder wrote it's settings into the video... you're doing something that needs trial and error. [22:59] <llogan> also re-using certain settings such as bitrate on a completely different video is usually not recommended. [23:01] <invintus> as I have the workflow laid out (no code written yet) if the video container does not have enough info. i just convert it to x settings.. the reason for this is to create consistency for video that needs to be edited then concatenated. [23:02] <llogan> you can use ffprobe to get info about a video [23:02] <invintus> I was just hoping for a more elegant way to use a refrenece video for the settings [23:02] <llogan> https://trac.ffmpeg.org/wiki/FFprobeTips [23:03] <invintus> thanks. already down the ffprobe parsing rabbit whole. [23:03] <llogan> there is no option in ffmpeg to look at a video and attempt to re-use whatever settings were used to encode it. not that all of them are possible to know. [23:04] <Mavrik> also, using CRF for example in x264 will keep constant quality, which is probably what you want for intermediate representation [23:04] <invintus> I just thought I would ask since it already does something similar to the input video with -vcodec copy ect.. [23:05] <llogan> that is to stream copy (re-mux). to me it seemed like you wanted to re-encode [23:07] <llogan> if you need to re-encode for whatever reason (for the editor comaptibility?), and want to edit the output, then a lossless intermediate may be the way to go. depending on your editor that may be using the encoders: utvideo, huffyuv, libx264 (lossless mode), ffv1, among a few others [23:07] <invintus> i do need to re-encode. The first video that someone uploads, I need to convert each successive video as close to the original as possible so the concatenation works. otherwise I have to do concat another more painful way [23:07] <llogan> sound like you plan on using the concat demuxer [23:08] <llogan> concat filter may be a better option [23:08] <llogan> but you'll have to experiment [23:08] <invintus> I am using now, realizing that my own probe parsing is not getting close to whats needed for consistency for the reset of the clips [23:08] <Mavrik> yep that sounds like the usecase for concat filter. [23:09] <Mavrik> you do know ffprobe has JSON and other types of outputs to ease parsing? :) [23:09] <invintus> Yeah I am using -pretty and the json [23:09] <llogan> it means that the original will also be re-encoded, but big deal, it's probably worth the tradeoff of being (possibly) easier to implement and likely to provide a more "stable" output [23:09] <invintus> right now I am using the concat with just a list of files, I think i need to use the filter diffrently [23:10] <invintus> agreed [23:11] <invintus> thanks folks! off to hours of debugging.. :) [23:11] <llogan> come back if you need help building the filter_complex [23:12] <invintus> Oh i will hehe.. I went the easy road. now here i am at your good graces. [23:18] <sine0_> hi [23:18] <sine0_> ok. 14.04 amd64. whats my best skype solution [23:19] <sine0_> wehoops [23:19] <sine0_> wrong channel lol [00:00] --- Wed Jul 30 2014

1 0

ffmpeg-devel.log.20140728
by burek 29 Jul '14

29 Jul '14

[00:00] <BBB> vp9 is pretty good [00:00] <BBB> googles PR is terrible [00:00] <BBB> Im like the only person in the world blogging about vp9, and thats only because I dont work at google [00:00] <Timothy_Gu> and cabac/cavlc/rc are all lossless right? [00:00] <BBB> (anymore) [00:00] <BBB> yes, range coders such as rac/cabac are all lossless [00:00] <Timothy_Gu> PR? [00:00] <BBB> press [00:01] <Timothy_Gu> are cabac/rac better than huffman? [00:01] <BBB> yes [00:01] <BBB> huffman is like a poor-mans version of trying to be a little bit like range-coding but not really getting it [00:02] <BBB> like, its not a bad idea, but range-coding is just theoreitcally much better [00:02] <BBB> or more granular,if you will [00:02] <BBB> if youre lucky, one of the x264 people can explain the deep internals of range coding to you, maybe michaelni understands it too [00:03] <BBB> I understand it at a more basic level but not completely mathematically [00:03] <Timothy_Gu> but is range coding slower than huffman? [00:03] <BBB> yes [00:03] <BBB> huffman is like this [00:03] <BBB> lets say I have a tree of modes, 3 options [00:03] <BBB> A B or C [00:03] <BBB> then I could create a coding tree where first bit zero means A [00:03] <BBB> first bit 1, second bit 0 means B [00:04] <BBB> and 11 means C [00:04] <BBB> right? [00:04] <BBB> thats a coding tree [00:04] <Timothy_Gu> ya [00:04] <BBB> now, what if A happens much less frequently than B or C? [00:04] <BBB> A is coded most efficiently [00:04] <Timothy_Gu> wait, why is C 11 and not 10 [00:04] <Timothy_Gu> ? [00:04] <BBB> (1 bit, versus 2 bits for the others) [00:04] <BBB> 10 is B [00:04] <Timothy_Gu> derp [00:05] <BBB> 0 is A, 10 is B, 11 is C [00:05] <BBB> so were wasting bits by making A the preferred token in the tree [00:05] <BBB> we adjust that dynamically by huffman coding these things, which means the token with higest occurence will get the shortest tree node [00:05] <BBB> so B would become 0, C 10, and A 11 [00:05] <BBB> this is all dynamic and automated, and works because encoder and decoder agree [00:06] <BBB> you can also code it in a frame header as an init pattern [00:06] <BBB> but that sucks, because I said B and C both occurred a lot, and A didn't [00:06] <BBB> so only B is efficient, not C [00:06] <BBB> range-coding makes hit smore fine-grained and allows subbit resolution [00:06] <BBB> so B/C get 0.8 bits and A gets 4 bits or so [00:07] <wm4> so you never encode when the symbols switch? [00:07] <wm4> and it's implicitly from what's encoded/decoded? [00:07] <BBB> you could encode it [00:07] <BBB> its up to the codec to allow that in the frame header or not [00:07] <kierank> 11:02 PM <"BBB> if youre lucky, one of the x264 people can explain the deep internals of range coding to you, --> the ian richardson book explains it well [00:07] <BBB> most, if not all, formats allow coding it int he ehader [00:07] <BBB> ah, cool [00:07] <BBB> Timothy_Gu: so there you go, a book :-p [00:08] <mraulet> nice book for beginners [00:09] <Timothy_Gu> http://www.amazon.com/H-264-Advanced-Video-Compression-Standard/dp/04705169… this one? [00:09] <JEEB> yeah [00:10] <Timothy_Gu> that's pretty expensive... [00:10] <mraulet> I know more this one [00:10] <mraulet> http://books.google.co.uk/books/about/H_264_and_MPEG_4_video_compression.ht… [00:10] <JEEB> that's the older version [00:10] <JEEB> of the same thing [00:10] <JEEB> the newer one just has MPEG-4 Part 2 removed [00:11] <JEEB> for obvious reasons [00:11] <wm4> what reasons? [00:11] <JEEB> MPEG-4 Part 2 isn't really /that/ interesting while it was a nice academic experiment [00:12] <mraulet> I think it is good to have an introduction with MPEG-4 part 2 [00:12] <mraulet> it is easier to understand new standards [00:13] <JEEB> I don't disagree with that, just that if you're going to grab the book it's most useful to grab the newest one [00:13] <JEEB> which just happens to have had MPEG-4 Part 2 removed [00:13] <JEEB> otherwise you'd have to grab both :P [00:13] <mraulet> life is like this [00:13] <JEEB> granted, I guess not that much has changed between the versions otherwise (I guess) [00:13] <Timothy_Gu> at what age did you guys first read this kind of book? [00:14] <JEEB> don't worry, I still haven't finished it and I'll be 30 in three years :P [00:15] <kierank> mraulet: nah mpeg-4 part 2 has crazy stuff [00:15] <kierank> he explains crazy things in there [00:15] <kierank> mpeg-2 is a nice place to start [00:15] <mraulet> not in this book [00:15] <mraulet> they are just explaining the simple part of it [00:15] <mraulet> what xvid divx did extrat from the standard [00:16] <mraulet> not the crazy « other » stuff [00:17] <BBB> lol mpeg4 [00:17] <BBB> rotational predictors, no? [00:17] <BBB> and other wtfy stuff [00:17] <BBB> Timothy_Gu: I wrote my first decoder 6 years ago or so, so youre well ahead of the curve [00:18] <BBB> Timothy_Gu: this stuff isnt hard, just takes some sitting down and let it all come together (thats what some people use their PhD for) [00:19] <Timothy_Gu> ok, thank you all. [00:19] <Timothy_Gu> gotta go though [00:20] <trn> Is there some standard way of encoding per-frame metadata in any native container format, or maybe another stream in a NUT or FFM container? [00:21] <wm4> maybe if NUT supports packet side data? [00:22] <trn> Right now I'm abusing PTS by offsetting it based on wall clock time at the start. [00:23] <trn> There are lots of disadvantages to that I can already see myself running up against. [00:24] <michaelni> nut should support side data [00:24] <trn> I start this on Monday. [00:25] <michaelni> as well as per packet metadata [00:25] <trn> A similar commercial solution uses an empty MJPEG straem with Exif data. [00:27] <kierank> in TS there is plenty of space for that [00:27] <trn> Yeah, they are using ts for it [00:27] <trn> But there has to be a better way [00:31] <trn> Thankfully I don't need wall clock, GPS, etc. every frame. A few ms would be good enough, as long as the operator can put two live streams side-by-side without visible desync. [00:32] <trn> GPS is also for sports, so the operator can set notifications to themselves for when a received stream is in or out of a certain boundry. [00:33] <trn> For example, a GoPro sending a live stream on a mountain biker. [00:33] <trn> So you can automatically alert when he's in the area and it'll put the cloest available scene cameras somehow easily avaialble to the operator. [00:35] <trn> I can't rely on setting the PTS offset in these cases because of the latency introduced by the gopro live itself, the phones 4g/lte, etc... before it gets to the server to be timestamped. [00:36] <wm4> you could abuse subtitle streams (lol) [00:36] <wm4> would make a pretty simple solution that works with common tools [00:38] <trn> Hrrm, could work, sure :) lol [00:39] <trn> I'm not famaliar with them at all, are they all image formats like DVD or SVCD? [00:40] <trn> I can RTFM, sorry :) [00:44] <Mavrik> uh [00:44] <Mavrik> isn't TimeCode what you're looking for? O.o [00:45] <trn> Mavrik: I need actual wallclock time, which might not be monotonic by design. [00:45] <trn> DST adjustments, leap seconds, and all. :b [00:46] <Mavrik> Yes, isn't TimeCode used for that? That is, synchronizing video to realtime. [00:46] <Mavrik> or did I mix something up badly? :) [00:47] <cone-621> ffmpeg.git 03Mickaël Raulet 07master:3b777db13200: hevc: remove non necessary parameters to ff_hevc_set_qpy [00:47] <trn> I'm a total noob when it comes to this sort of stuff, I might be reinventing the wheel without know it. [00:48] <trn> Mavrik: I also need to implement multiple time stamps that can be added by anything that does a remux of the stream along the way. [00:49] <trn> Application of this is to provide endpoints with estimation of latency. [00:49] <kierank> Mavrik: no [00:49] <kierank> timecode is not wallclock [00:50] <Mavrik> yeah, just read up on SMTPE spec [00:50] <Mavrik> ignore me then :) [00:50] <Mavrik> *SMPTE [00:50] <trn> Yeah, timecode is also monotonic by spec [00:51] <trn> Wikipedia says otherwise from what I quickly googled: https://en.wikipedia.org/wiki/SMPTE_timecode#Discontinuous_timecode.2C_and_… [00:53] <cone-621> ffmpeg.git 03Mickaël Raulet 07master:772f7f4eddbc: hevc: fix skip_flag [01:02] <trn> Final noob questions - is there some sort of easy way to determine what sort of latency I'd be introducing during a remuxing process using ffmpeg's libraries? [01:06] <cone-621> ffmpeg.git 03Anton Khirnov 07master:77ef9fd1e938: hevc: eliminate unnecessary cbf_c{b,r} arrays [01:07] <trn> And is there somewhere where it's commonly know what latency ffmpeg or it's libraries introduce in libavfilter or libavformat? [01:08] <Compn> trn : depends on options, there are ways to get ultra low latency live encodings [01:08] <trn> Like, what sort of latency does the fillin code add, etc? [01:08] <Compn> people keep those things secret it seems [01:08] <trn> hehe [01:09] <Compn> because they build business models around it [01:09] <trn> Compn: Yeah, famaliar with Streambox Avenir? :) [01:10] <Compn> for example, gaikai, online video gaming cloud service. play games in your web browser... you know how much latency you have to have to get that working ? :) [01:10] <trn> That is competition, but my trick isn't to make custom stuff on layer 2/bonding they do, or their custom codecs. [01:11] <trn> If I can know the latency ahead of time that certain things introduce, and reduce it where I can, and have good latency estimation, I can use latency hiding techniques ... [01:12] <trn> Compn: Like for a live interview with three seconds of latency... Instead of asking a short question, make sure the interviewer and interviewee know the latency and you can send a signal along with the video. [01:12] <trn> ask question, press button, answer question, press button ... [01:13] <kierank> they don't use custom codecs [01:13] <Compn> its x264 (h264) :P [01:13] <Compn> you mean like send the questions ahead of time ? [01:13] <trn> Yes, correct. :) [01:13] <Compn> trn : or encode two streams, one low quality that streams faster than the hd stream ? :P [01:14] <Compn> probably reporters couldnt handle such tech. hard part is training them not to trip over the cable on the floor [01:14] <trn> Really? I failed trying to figure out what Streambox sends out. [01:14] <trn> 9300.. they call it ACT-L3 [01:14] <Compn> to answer your question, no i dont know streambox stuff [01:15] <trn> Anyway tho, this isn't for reporters, this is to allow smaller and smaller teams to cover sporting events, church events, for live production. [01:15] <Compn> ah [01:15] <trn> With pan/zoom remote IP cameras, gopro w/wifi, etc. [01:16] <trn> and a operator who works on a laptop [01:17] <trn> Using location data and stream metadata allows tons of stuff to be automated... [01:17] <Compn> oh , so studio in a box type thing ? [01:17] <trn> Essentially. [01:18] <trn> Once it works it's going to be free "on the cloud" kind of thing which can accept input via HLS/RTMP/RTP/etc and stream the video back all via HTML5. [01:19] <trn> latency will be unacceptable for live production but you can pay me for a local hardware box :) [01:20] <Compn> press button eh? why not have mic-activated video mixing , so whoever is talking gets on screen or auto splitscreen ? :D [01:20] <Compn> plus remote control for adv users [01:20] <trn> I imagine a car race, for example. With 10 cameras positioned around the track... and camera in the car w/GPS. [01:20] <trn> with the known locations of the 10 cameras, you can tell the track cameras to follow the car based on location. [01:20] <trn> and it'll cut them in and out automatically, etc. [01:20] <Compn> ah [01:22] <trn> so being able to accurately estimate the latency is important. [01:23] <Compn> just have to run the ole benchmarks yourself after its setup :) [01:23] <trn> Yeah, I was hoping that it would all be documented someplace. :) [01:23] <Compn> i dont think any of us have those benchmarks available in doc [01:24] <Compn> only people who are using ffmpeg for broadcast stuff [01:24] <Compn> which ... are keeping it a secret [01:24] <Compn> maybe ask the dirac guys [01:24] <trn> I've now got the stream switching, combining, mixing all done. [01:24] <Compn> you need any venture capital ? :p [01:24] <trn> I've also got most of the logic done for the operator. [01:24] <trn> Now I just need to get timestamps into the streams, etc. :) [01:24] <trn> Compn: You offering? :) [01:25] <Compn> always looking for investments [01:25] <trn> I'm probably not the guy to invest with just yet to be honest. [01:25] <Compn> i know, sounds a bit niche right now :P [01:26] <trn> I work 10 hours a day on the phone selling roofing and construciton stuff and work on this on weekends and nights. [01:26] <Compn> gopro is on the walmart commercials now so maybe its going to get bigger [01:26] <trn> I used to do computer stuff professionally however, but now it's starting to come together. [01:26] <Compn> youtube needs to add more support for live broadcasters [01:26] <trn> Once I get a first working minimal-feature web version up, I'll remember you. [01:28] <trn> I also don't have an Apple dev account yet either, but android stuff is easy to work with. [01:29] <trn> I mainly just need phones for GPS, etc. Sports is going to be my primary focus at first. [01:29] <trn> Produce a great live broadcast with multiple cameras, side-by-side support, etc. [01:30] <trn> And then if you saved the original streams, you'll be able to reproduce the live broadcast later from the script file it writes, tweak it, fix stuff, and then export a better edited replay. [01:31] <trn> So you can live broadcast then upload a slightly corrected version to youtube or whatever. [01:32] <wm4> [FFmpeg-devel] Reintroducing FFmpeg to Debian [01:32] <j-b> wm4: while I don't see an issue with that, some facts are a bit distorted... [01:33] <trn> I'm extensively using ffmpeg stuff for all of this, so if I end up making any money on it, ffmpeg will get my donations. [01:33] <wm4> j-b: which ones? I didn't switch on my lawyer mode (since it's broken), but all in all it looks correct... [01:34] <Compn> whoa thats a long mail [01:35] <j-b> wm4: mostly the "more codecs" part showing 3 propres decoders (WTF) and introducing more HW-codecs [01:36] <j-b> wm4: but I don't really care, since VLC compiles fine (of course) [01:36] <wm4> I don't see any about that in that mail [01:38] <Compn> prores isnt in the mail, although there are a lot of debian bug urls [01:38] <j-b> it is [01:38] <j-b> link 4 [01:38] <j-b> and the first arguement [01:38] <Compn> thats what wm4 was saying [01:38] <Compn> its in a link nto in a mail [01:39] <wm4> haha [01:39] <j-b> but it's the number one argument [01:39] <Compn> lol [01:39] <Compn> i didnt write it :P [01:39] <j-b> I know [01:40] <Compn> theres a few codecs but yeah i dont remember any big things [01:40] <Compn> probably wise not to mention prores situation :\ [01:43] <Compn> just more of the same ego wars [01:43] <wm4> big things are of course merged back by libav [01:44] <Compn> didnt realize crystalhd was removed ? [01:44] <wm4> what is that even [01:45] <Compn> its a little pcie? card that decodes h264 [01:45] <Compn> or mpcie something like that [01:45] <Compn> kind of an add-on for mac puters that didnt have hwaccel gpu [01:46] <Compn> few years ago [01:46] <Compn> also works on other os too of course [01:49] <Compn> i just like to pick on mac computers :) [01:54] <BBB> ffmpeg should just remove all of its prores decoders except the one it thinks is best [01:54] <BBB> the whole having 3 decoders is too ridiculous for words [01:54] <BBB> or encoders [01:56] <Compn> take benchmarks, quality, compatability samples between the three and submit which one is best. then we'll kill the other two? [01:57] <Compn> also which one is still maintained ? [01:57] <Compn> because some devels have stopped working on them... i think [02:08] <trn> I can understand having multiple encoders if some are better than others in a particular cirumstance. [02:09] <trn> About the NUT format... I notice there is libnut in ffmpeg/mplayer git, and also an internal NUT support. [02:09] <wm4> AFAIK libnut is deader than dead [02:09] <trn> OK, I had much better luck with internal so I disabled libnut. [02:17] <Compn> no one picked up libnut , so its more of an internal format at this point [02:17] <trn> Is there any documentation for the zeromq support other than the source? [02:18] <Compn> which means any editing software wont support it... [02:18] <Compn> only ffmpeg [02:18] <Compn> and anything that uses lavf, which is a lot [02:19] <trn> Compn: I'm using NUT as an internal transport format myself, so I'm fine with that, I just hope it doesn't disappear. :) [02:19] <trn> If it does I can look into FFM. [02:21] <Compn> nut isnt going anywhere :) [02:21] <Compn> i think a few people use nut internally. [02:28] <trn> Compn: Final thing before I get back to coding ... [02:28] <trn> I think there might be an issue with how ffmpeg writes segmented MPEG2-TS where it won't pass Apple's HLS test. [02:31] <trn> VLC made me notice, It's resetting the continuity counter between segments produced. [02:32] <trn> I will probably file a bug for that. [02:32] <Compn> you are using latest git ffmpeg ? [02:32] <Compn> there were hls changes recently , although i dont remember the details [02:32] <trn> Yes, from today. [02:33] <Compn> then yes report bug [02:34] <trn> Hrrm, already reported, I just checked. :b [02:34] <trn> https://trac.ffmpeg.org/ticket/2828 [02:34] <trn> Hasn't been updated, I'll isolate the minimal case and add some info if I can. [02:37] <Compn> post a request for that guys new patch :P [02:38] <trn> Might save me a little work, at least. [02:38] <trn> I have completely rewritten the m3u8 segment stuff, btw, but it's horrible code. [02:39] <trn> Generally you can specify the same output m3u8 file out multiple outputs, and it writes 1 merged output file that is suitable for adaptive bitrate streaming. [02:42] <trn> Properly done, it would add the extended hints such as BANDWIDTH, CODECS, and RESOLUTION based on outpuit. [02:42] <trn> Right now I just write it based on an option. :) [02:44] <trn> Compn: In the meantime, there is a workaround for the TS discontinuity thing. [02:44] <trn> Adding a EXT-X-DISCONTINUITY between each media file, nornmally used serve advertisements. [02:44] <trn> But it's in the spec per apple and a valid workaround. [02:47] <trn> Compn: I also have a patch that implements MPEG-2TS AES-128 encryption per apple, but it depends on openssl. [02:48] <trn> Sort of interesting, anything that uses Apple HLS which is everything has like no real DRM at all. [02:49] <trn> Unless they are using PlayReady which they can. [02:49] <trn> But the AES method passes the key location via the playlist and it's accessed via HTTPS. [02:50] <trn> The only real secure way is to use client certificates so that a client connecting to the key server can't just grab them, but almost no real applications ever do such a thing. [02:51] <trn> So I use my VPN, mitmproxy, and squid and a little program I wrote that sends any HLS video to my chromecast. :) [02:51] <trn> bbl [03:10] <jamrial> michaelni: regarding versions, the RELEASE file in the master branch should be updated [03:11] <jamrial> not sure what's proper, if 2.3.git or 2.4.git as Timothy_Gu suggested the other day [03:16] <Compn> trn : neat. tell me when i can rip hulu again :P [03:16] <Compn> i think most people are using adobehds.php [03:16] <Compn> er thats for adobe [03:16] <Compn> durr [03:16] Action: Compn brain hurts [03:16] <Compn> hulu was just using rtmp [03:17] <michaelni> jamrial, dunno, ill change it to 2.3 for now, we can always chage to 2.4 if thats preferred [03:17] <michaelni> 2.2 is certainly wrong though [03:17] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:a7762384cf9b: RELEASE: update, we are after 2.3 not 2.2 [05:22] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:2f717be22a93: avcodec/avdct: Add avcodec_dct_get_class() [05:23] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:cab8fc624b40: avfilter/vf_scale: fix log message category [05:23] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:a06c14a48ee9: avfilter/vf_spp: support setting dct avoptions from the filter graph string [06:28] <michaelni> anyone has any comments about the "frame-mt: hevc: implement and use step progress API" patchset ? [06:29] Action: michaelni falls asleep [09:26] <plepere> good morning [09:50] <ePirat-> morning [10:54] <ePirat-> ubitux, discovered that I cannot really guess content type, since I only can do the checks when the headers are already sent [10:55] <ePirat-> (I have no stream data in the open function, only when writing) [10:55] <ubitux> what about assuming and setting "audio/ogg" when content_type is not set and mount_point ends with "ogg"? [10:55] <ubitux> or just "application/ogg" [10:55] <ubitux> most icecast version only stream audio [10:55] <ubitux> i think some icecast forks are able to play with flv, but that's a limited usage [10:56] <ePirat-> nope [10:56] <ePirat-> icecast can stream nearly anything [10:56] <ePirat-> and ogg video and webm is officially supported [10:57] <ePirat-> yes I can assume ogg but if I notice then later on it's actrually not ogg I would have to say: Hay I guessed ogg but hey I guessed you don't stream ogg actually [10:57] <ePirat-> which seems stupid [10:59] <ePirat-> I could remove the doublecheck at all of course and just guess based on file extension [10:59] <ePirat-> but then I had no way to know if I guessed right [10:59] <ePirat-> and if not things will just break without user knowing why [11:00] <ePirat-> thats a very complex problem and I have tought a long time about it [11:01] <ePirat-> I could of course only open the connection in the read function but that would be a bit of a hack& [11:04] <ePirat-> I will guess it based on file extension and warn about it. [11:04] <ubitux> ePirat-: you can print a warning and make a guess [12:29] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:5003b8b9c3ba: MAINTAINERS: update list of releases i maintain [12:45] <cone-572> ffmpeg.git 03Anton Khirnov 07master:c5fca0174db9: lavc: add a property for marking codecs that support frame reordering [12:45] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:2e5c8b06491b: Merge commit 'c5fca0174db9ed45be821177f49bd9633152704d' [12:51] <cone-572> ffmpeg.git 03Anton Khirnov 07master:4b169321b845: codec_desc: fix some typos in long codec names [12:51] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:c11255ae8b1a: Merge commit '4b169321b84502302f2badb056ebee4fdaea94fa' [13:01] <cone-572> ffmpeg.git 03Anton Khirnov 07master:e36a2f4c5280: hevc: eliminate an unnecessary array [13:01] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:453224f10b37: Merge commit 'e36a2f4c5280e2779b0e88974295a711cf8d88be' [13:08] <cone-572> ffmpeg.git 03Anton Khirnov 07master:53a11135f2fb: hevc: simplify splitting the transform tree blocks [13:08] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:2fb8aa9b10fc: Merge commit '53a11135f2fb2123408b295f9aaae3d6f861aea5' [13:15] <cone-572> ffmpeg.git 03Anton Khirnov 07master:0daa2554636b: hevc: do not store the transform inter_split flag in the context [13:15] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:0a1ffc57882c: Merge commit '0daa2554636ba1d31f3162ffb86991e84eb938a8' [14:01] <cone-572> ffmpeg.git 03Anton Khirnov 07master:4aa80808bcc2: hevc: eliminate unnecessary cbf_c{b,r} arrays [14:01] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:4a73fa19ca7a: Merge commit '4aa80808bcc2a30fcd7ce5b38594319df3a85b36' [14:19] <cone-572> ffmpeg.git 03Anton Khirnov 07master:e76f2d119704: hevc: eliminate the last element from TransformTree [14:19] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:e0492311c854: Merge commit 'e76f2d11970484266e67a12961f2339a5c2fccf9' [14:26] <cone-572> ffmpeg.git 03Anton Khirnov 07master:a5c621aa8525: hevc: rename variable in boundary strength to b more explicit [14:34] <cone-572> ffmpeg.git 03Mickaël Raulet 07master:42ffa226f9a5: hevc: clean up non relevant TODO [14:34] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:772dfd5f6e5d: avcodec/hevc: add some const to cbf arrays [14:39] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:243236a6f589: avcodec/hevc: fix "discards const qualifier from pointer target type" warning [14:50] <cone-572> ffmpeg.git 03Michael Niedermayer 07release/2.3:fcc6568a1025: avcodec: add avdct [14:50] <cone-572> ffmpeg.git 03Michael Niedermayer 07release/2.3:8f53d32dfbe2: avfilter/vf_spp: use AVDCT [14:50] <cone-572> ffmpeg.git 03Christophe Gisquet 07release/2.3:65259b4d687a: x86: hevc_mc: replace one lea by add [14:50] <cone-572> ffmpeg.git 03Michael Niedermayer 07release/2.3:2f71aeb30161: remove VERSION file [14:50] <cone-572> ffmpeg.git 03Michael Niedermayer 07release/2.3:ee606fd0317d: version.sh: Print versions based on the last git tag for release branches [15:50] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:f3158c3f29cd: version.sh: Print versions based on the last git tag for release branches [18:08] <trn> Hello guys. [18:09] <trn> I added a comment at https://trac.ffmpeg.org/ticket/2828#comment:16 as requested, thought better to report here since I see this bug was already reported. [18:10] <trn> I did my last git pull 12 hours ago, but nothing has changed in that time. [18:15] <trn> Compn: About ripping hulu, I think that you actually can do it if you have Hulu Plus. Unless it uses PlayReady. [18:16] <trn> Compn: http://www.microsoft.com/playready/licensing/list/ shhows Hulu LLC as a licensee, so it probably does. I don't have Hulu Plus, so I can't use iOS Hulu to intercept the delivery stream. [18:19] <trn> But Hulu+ content is delivered via HLS for sure to iOS devices. [18:34] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:d554d004a67c: tests/fate.sh: If cat *.rep fails try it with a for loop. [18:53] <`md> trn?! [18:57] <Compn> trn : oh interesting. i wasnt sure if H+ and ios used different transports [18:57] <trn> `md: Why hello there. As you see, I'm still alive, but last few months weren't so great and I didn't end up on the plane :b [18:57] <trn> Gotta catch up! [18:58] <trn> First time on IRC in months! [18:59] <trn> Compn: Apple states that pretty much everything has to be HLS when video is streamed to an iOS device, if it's more than some trivial size or length. [19:01] <trn> And all HLS streams are interceptable other than PlayReady stuff because the AES keys are delivered via the m3u8, and if you are using something like mitmproxy, you can easily impersonate the session authentication to revieve the key. [19:02] <`md> trn: uhm, yea, i noticed, lol :D [19:04] <trn> Also, most iOS apps and streaming servers suck and do not do really any authentication at all. Sometimes they rotate the key every nn segments, but the keyfile path as specified by the m3u8 isn't protected from retrieval. [19:05] <trn> `md: Sadly trying to make money with ffmpeg now. :b [19:06] <`md> :O [19:06] <llogan> i did it, and now i'm a thousandaire. [19:07] <`md> trn: hope you at least caught the livestream? [19:07] <`md> llogan: what currency? i hope btc... :D [19:07] <trn> `md: Parts of it. [19:07] <llogan> `md: Ameribucks [19:07] <`md> trn: well it's all available as vod on youtube [19:07] <`md> llogan: oh :( [19:08] <trn> `md: Long story short, my mother had a stroke combined with diabetes complications. [19:08] <`md> ah fuck [19:08] <trn> She's OK, but I had to sell her car and deal with getting her medical coverages in order and ended up having to pay tons out of my own pocket, cover her mortgage, etc. [19:09] <trn> And I'm an asshole for not keeping in touch, but honestly I've been in a daze for a few months trying to get things all straightened out. [19:10] <`md> it's alright, family comes first [19:10] <trn> Yeah, sucks when I had tickets and all. :b [19:10] <`md> uh yea! [19:10] <`md> well at least you supported the eventy [19:10] <`md> *event [19:11] <trn> `md: So you're an ffmpeg dev now or something :) [19:11] <`md> heh :D [19:11] <`md> not really no [19:11] <`md> i've always been here [19:12] <`md> lurking [19:12] <`md> one of these days tho! [19:12] <Compn> large number of multimedia lurkers in the channels [19:13] <trn> ffmpeg libav* stuff is quite easy to get into once you figure out the basics. [19:16] <Compn> trn : consider writing some docs so others can ease into it. we have many complaints from devels who cant figure things out :p [19:17] <Compn> maybe the api is so large. i dont know if the complaints are legit or not as i'm no programmer. [19:21] <trn> Compn: I got started by looking at https://github.com/chelyaev/ffmpeg-tutorial myself. [19:28] <trn> `md: New project is a (imho) rather innovative live broadcast studio and broadcast dealyed editing suite. [19:30] <`md> oho [19:31] <trn> `md: Finding a way to unobtrusively remove video and maintain the buffer is part of my secret sauce. :) [19:32] <trn> Works well for sports and such, for something that would be way to jarring with a cut discontinuity, it can revert to standard audio bleeping or user-placed video pixelization :) [19:38] <trn> Has anyone looked into support OpenH264 in ffmpeg? [19:44] <Compn> as a lib wrapper ? [19:45] <trn> I'd be interested in seeing how well it works compared to x264 in realtime. [19:47] <trn> It's limited to baseline, but you need baseline for iPhone 3 support. [19:48] <iive> x264 have standalone application , doesn't openh264 have one too? [19:48] <Compn> yes afaict [19:49] <Compn> the better question is, is there anything we can steal to make ffmpeg faster/better :P [19:49] <Compn> probably x264 already did such an audit [19:49] <Compn> for the encoding side [19:50] <wm4> isn't the only reason openh264 exists licensing bullshit? [19:51] <trn> I'm not sure it's the only reason, but Cisco does cover the MPEG-LA license on the binary redistributable. [19:54] <Compn> trn : if you just want to get out of having your software pay the mpegla license by using cisco binary, thats fine [19:54] <Compn> and ffmpeg would accept such an openh264 wrapper for that purpose [19:54] <Compn> but most users i think probably wouldnt need it... [19:57] <jamrial> kurosu: you forgot to attach the patch in "[PATCH] x86: hevc_mc: fix register count usage" [20:01] <kurosu> jamrial, thanks [20:07] <`md> trn: shouldnt ffmpeg look into offloading encoding to a gpu for live stuff? [20:07] <`md> i can already do that just fine for live streaming on windows [20:07] <trn> Compn: Problem with the live stuff w/ OpenH264 is baseline profile only for encoding. [20:09] <trn> `md: Using the ultrafast or similar x264 presets and asm optimizations, I have no issues with live encoding on a server. [20:10] <trn> `md: But a GPU isn't always available, because eventually I want to get something setup similar to a Streambox Avenir. [20:10] <`md> trn: sure i can also encode at fast profile up to 720p50 or 1080p25 [20:10] <`md> on the cpu [20:10] <`md> but offloading it to a gpu or several gpus is a bit nicer [20:10] <kierank> trn: lol building a streambox avenir [20:11] <kierank> `md: sure a nice way to waste energy [20:11] <trn> kierank: Not building an avenir, no :) [20:11] <`md> some servers would have capable intel integrated graphics, and some have pcie slots that you could use [20:11] <`md> kierank: waste? [20:11] <kierank> yes [20:11] <`md> is energy something that matters? [20:11] <trn> kierank: I have no need for any sort of the things they do loike link aggregation or what not, use case involves mainly local streams. [20:11] <kierank> some decent low power cpus out there that are better [20:12] <kierank> trn: and you want to do this with nut [20:12] <kierank> ... [20:12] <`md> kierank: better than what? [20:12] <kierank> `md: than wasting cycles encoding on the gpu [20:12] <kierank> better quality, less power [20:12] <kierank> less marketing though [20:12] <`md> well it frees up the cpu to do other stuff [20:12] <`md> like deinterlacing or stuff like that [20:12] <kierank> buy another cpu [20:13] <kierank> uses less power [20:13] <kierank> gpu encoding is only there for marketing purposes [20:13] <`md> if you have a dual cpu board, sure [20:13] <kierank> buy a more powerful cpu [20:13] <kierank> all scenarios will use less energy, cost less money and give a better picture [20:14] <`md> even the most powerful cpus are still struggling with handling x264 at really good quality at 1080p50 while also deinterlacing it with something like yadif [20:14] <`md> just saying [20:14] <`md> i DO agree with you [20:14] <kierank> "really good quality" [20:14] <kierank> good luck getting that from a gpu [20:14] <`md> i am not [20:14] <`md> but at least i am getting something [20:15] <kierank> you'll get something on a cpu as well [20:15] <`md> comparable to what the cpu would output [20:15] <kierank> 1080p50 is doable on 1-2 cores [20:15] <`md> depends on the profile you use and the cpu of course [20:15] <kierank> sigh [20:15] <cone-572> ffmpeg.git 03Michael Niedermayer 07master:1e51af13c753: avdevice/pulse_audio_enc: use getter function for AVFrame.channels [20:15] <kierank> can't win against the gpu tards [20:15] <`md> 20:14:30 < `md> i DO agree with you [20:15] <kierank> anyway i look forward to your ffmpeg gpu patch [20:16] <kierank> 7:07 PM <`md> trn: shouldnt ffmpeg look into offloading encoding to a gpu for live stuff? [20:16] <kierank> 7:07 PM <`md> i can already do that just fine for live streaming on windows [20:16] <`md> yes... [20:17] <`md> i am not even sure any of the gpu vendors even have an api yet on linux for it [20:17] <`md> they and their stupid closed source driver bullshit [20:18] <trn> Honestly on a local LAN configuration, I can do raw/PCM at 720p over the wire at 270Mbps, that's 33.75MB/s. [20:19] <iive> doesn't radeons (and intel) have some specialized silicon for encoding video? [20:19] <`md> nvidia too.... [20:19] <kierank> trn: do your maths correctly [20:19] <`md> and they all have nice marketing names for it [20:19] <iive> it's not like using graphic shaders. [20:19] <trn> So that's about 3 streams on 1000BaseT in reality. [20:20] <kierank> trn: 1280*720*2*30 is not 270mbps [20:20] <`md> what colourspace? [20:20] <`md> 4:2:0? [20:21] <trn> kierank: I am very sure I did... 1280x720, 4:2:0, 24fps and PCM audio plus muxing overhead ~= 270,000kbps [20:21] <trn> Let me verify. [20:21] <kierank> lol 24fps [20:22] <kierank> ok for 24fps you're right... [20:22] <kierank> enjoy your blur [20:22] <trn> Yep ... and 24fps is fine for my application, because the output is TV and film mainly. [20:22] <`md> kierank: why so negative tonight? [20:22] <kierank> tv is not 24fps [20:22] <trn> TV is mostly 25fps and file is 23.96fpm ... [20:22] <kierank> `md: lot of BS being spouted in this channel [20:23] <trn> kierank: Explain? [20:23] <`md> kierank: oh and that angers you? [20:23] <kierank> tv is 25fps and 30fps with some places 50fps and 60fps [20:23] <kierank> if it's 720p it's the latter [20:23] <`md> true [20:24] <trn> kierank: I pretty much do exactly what the broadcast equipment I'm famaliar with does. [20:24] <kierank> 720p24 isn't even a broadcast format [20:24] <`md> well the tv channels deal with input that is mostly 24fps [20:24] <`md> they either speed it up or use telecine [20:24] <trn> kierank: Capture 24p then stretch to 23.975 for NTSC conversion, or speed up to 25fps for PAL/SECAM. [20:24] <`md> to get it to 25 or 30fps [20:24] <`md> so yea [20:24] <kierank> input is a wide variety of formats [20:25] <`md> sure [20:25] <trn> That is industry standard everywhere I've worked. [20:25] <kierank> 720p24 isn't a standard [20:25] <kierank> anywhere [20:25] <kierank> it's kiddy web standard sure [20:26] <`md> kierank: dont underestimate netflix and such... [20:26] <`md> far from being kiddy anymore [20:26] <trn> kierank: I'm working on prosumer level stuff, yes. [20:27] <kierank> `md: sure i can go to one of the conferences and hear about how the entire audience of these web services is the same as one channel I encode [20:27] <trn> kierank: Panasonic AG-DVX100 and similar are standards there... megachurch stuff uses HVX200's ... [20:27] <kierank> oh it's changing the world [20:27] <kierank> OTT [20:29] <trn> The standard is mostly DVCPRO HD which is 960×720 ... [20:29] <trn> It's unusual to see higher than that in the target segment. [20:30] <kierank> wouldn't even pass QC on my side... [20:30] <kierank> except maybe for news [20:32] <trn> kierank: That's the target, providing live-streams of events, target is web broadcast motorsports, house of worship stuff, gopro3/4 wifi-backpack streams, etc. [20:32] <kierank> ok [20:32] <trn> kierank: Most of that is using DV. [20:35] <trn> The point is with cheap gigE you can already do 3 streams at equal or higher quality to what is commonly in use in this segment. [20:35] <trn> So even the most rudimentary compression would be enough to give enough cameras to cover most events. [20:36] <kierank> makes more sense as to why you would use nut [20:36] <kierank> but I would use rtp [20:39] <trn> kierank: I'm going to look into it actually. [20:40] <trn> kierank: But to get something quick and working and remember the 'freemium' [20:40] <trn> version runs on (uugh) "the cloud". [20:41] <trn> So it's easier to get TCP where I need it vs UDP [20:41] <trn> NAT and such [20:41] <trn> And using NUT makes it much easier to play with different formats. [21:06] <ubitux> kierank: xiph, .doc? seriously? [21:06] <kierank> ubitux: etsi rules [21:06] <kierank> has to be a doc [21:06] <ubitux> ._. [21:07] <ubitux> fear, ok [21:07] <kierank> ubitux: better than ietf imo [21:07] <kierank> they draw graphs using ascii art... [21:07] <ubitux> fine with me [21:07] <kierank> makes my eyes bleed [21:08] <ubitux> i do that as well actually :p [21:08] <ubitux> antiword seems to support you .doc, perfect [21:08] <ubitux> your& [21:09] <kierank> not very well [21:10] <kierank> derf had to use a windows VM to edit it =p [21:10] <ubitux> antiword is just for reading [21:10] <ubitux> http://b.pkh.me/ETSI_TS_opus-v0.1.2-draft.txt [21:10] <kierank> hmm it did the tables as well [21:10] <kierank> not too badly either [21:11] <ubitux> you couldn't write it in whatever sane format, make a screenshot, and paste it in the doc? [21:11] <ubitux> i used to do that @ school [21:12] <ubitux> (until i realized they couldn't differenciate adobe reader from word) [21:13] <kierank> I would have done it in LaTeX [21:13] <JEEB> > standardization bodies > LaTeX [21:13] <JEEB> all the things are in doc [21:33] <kierank> ubitux: if you have any thoughts please feel free to make them [21:54] <cone-572> ffmpeg.git 03James Almer 07master:f137876182f6: x86/hevc_idct: add a colon to labels [22:06] <cone-572> ffmpeg.git 03James Almer 07master:664e9e433119: x86/hevc_deblock: load less data in hevc_h_loop_filter_luma_8 [23:24] <kurosu> jamrial, looks like some of the MASKED_COPY could use SWAP instead of mova in hevc_deblock.asm [23:25] <kurosu> I can't understand why it doesn't work, so I guess I'll look at it with a fresher mind tomorrow [23:26] <cone-572> ffmpeg.git 03Carl Eugen Hoyos 07master:63c0b41904bc: Fix standalone compilation of the adts muxer. [23:39] <trn> OK. I have a quick patch for ticket #2828 but it involves three new data fields in AVFormatContext struct. [23:39] <trn> Not sure if that is acceptable. [23:40] <trn> Probably the same as the other guys patch.. should I send to mailing list anyway? [23:43] <michaelni> what "others guys patch" ? [23:43] <michaelni> but without really knowing anything about the specific case, sending patches to the ML is always a good idea [23:43] <ubitux> http://git.libav.org/?p=libav.git;a=commitdiff;h=942269fd ???? [23:44] <trn> michaelni: https://trac.ffmpeg.org/ticket/2828#comment:12 <- he described it but didn't include it. [23:45] <trn> michaelni: It's rather obvious after reading the whole thread. I included full debug output from latest git head and full command-lines to replicate the issues by using ffmpeg directly. [23:45] <trn> I'll send the patch along anyway. It just seems like it should be handled another way. [23:47] <trn> Or like I mention in comment #17, a workaround is adding EXT-X-DISCONTINUITY hint to M3U8 output which should make the ffmpeg output pass Apple validation. [23:48] <trn> That would at least not require adding new entires to AVFormatContext struct. [23:48] <michaelni> well, i cant comment without seeing the patch [23:48] <michaelni> that tis is about [23:52] <trn> I'll try to send two tonight, one that patches AVFormatContext and one that just adds EXT-X-DISCONTINUITY to M3U8 output (but that is trivial). [23:52] <trn> I'm just not sure how AVFormatContext struct is used and if adding new fields to it would break ABI. [23:54] <michaelni> you can add fields at the end, i mostly wonder if the fields wouldnt belong elsewhere [23:55] <michaelni> also if the fields are to be accessed from outside libavformat that needs MAKE_ACCESSORS [23:59] <trn> leaving work, thanks again guys. [00:00] --- Tue Jul 29 2014

1 0

ffmpeg.log.20140728
by burek 29 Jul '14

29 Jul '14

[00:00] <c_14> You'll need to use the concat filter. [00:01] <sythe> Can I convert one to the other? [00:02] <sythe> c_14: I think I tried that [00:02] <c_14> sure, but you could just use the concat filter and not worry about it [00:02] <c_14> !by sythe [00:02] <c_14> sorry Scall [00:02] <c_14> sythe: pastebin the command + output please [00:04] <trn> Anyone here famaliar with Streambox stuff? [00:04] <trn> I'm sort of wondering how they do it, or if anyone has reverse engineered their codec? [00:06] <trn> Because I'd love to be able to process Avenir output directly ... [00:07] <trn> http://www.streambox.com/products/avenir-mini-2-0 [00:09] <trn> The big three cable news networks here in the US use this exclusively. [00:18] <sythe> Ok, c_14 [00:18] <sythe> c_14: What command should I do? [00:18] <sythe> I've tried concat before [00:23] <c_14> ffmpeg -i file1 -i file2 -filter_complex '[0:a][0:v][1:a][1:v]concat=n=2:v=1:a=1[v][a]' -map '[v]' -map '[a]' out [00:48] <sythe> thanks [00:50] <sythe> c_14: "Stream specifier ':a' in filtergraph description [0:a][0:v][1:a][1:v]concat=n=2:v=1:a=1[v][a] matches no streams." ? [00:50] <c_14> Does one of your files not have an audio stream? [00:50] <sythe> both have audio [00:51] <c_14> Can you pastebin the full command and complete output? [00:52] <sythe> https://www.irccloud.com/pastebin/cs2Ag51F [00:52] <sythe> c_14: ^ [00:53] <sythe> c_14: I got it working using a script I found on the wiki [00:53] <sythe> But it took like...an hour [00:53] <sythe> Literally, an hour [00:55] <c_14> try replacing the 'a's with '1's and the 'v's with '0's in the first 4 [] groups. You'll also probably want to replace out with out.mp4 or something. [00:56] <c_14> And if you're using mp4 it'll default to aac so you'll need -strict -2 or a different audio codec. [00:56] <c_14> And you might want to tune the crf for x264 to get the quality you want. [01:02] <sythe> c_14: I just want the source quality [01:02] <sythe> c_14: Is there any chance of FFMPEG dropping FPS when converting it? [01:03] <c_14> There is the chance, iirc ffmpeg should detect the output fps from the input fps, but you can force it with -r fps or with the fps filter. [01:04] <sythe> Stream specifier ':1' in filtergraph description [0:1][0:1][1:0][1:0]concat=n=2:v=1:a=1[v][a] matches no streams. [01:04] <sythe> :( [01:04] <c_14> ehh [01:05] <c_14> It lists them right there... [01:06] <c_14> I don't think it'll help, but can you try it with one of the static builds just to make sure? [01:06] <sythe> c_14: How do I check my kernel version? [01:07] <c_14> uname -r [01:07] <k0k> is there a way to -cropleft -cropright -croptop -cropbottom? [01:07] <c_14> Look at the crop filter? [01:07] <k0k> every site i go to to get help keeps mentioning them [01:08] <c_14> The manpages don't even list those options, might be deprecated. [01:10] <k0k> thought so, but how can i achieve the same effect with the new ones? the only thing similar i saw was "crop=in_w-2*10:in_h-2*20" but the crop area I need isn't even, an it doesn't seem to let me jut go "crop=in_w-20:21:in_h-20:21" or something like that [01:11] <k0k> and* just* [01:11] <c_14> What are you trying to do? [01:11] <sythe> c_14: Same error [01:11] <sythe> Running ./ffmpeg from the dir [01:12] <k0k> crop 168 left, 60 top, 68 bottom, and 120 right [01:12] <c_14> sythe: ffprobe clearly lists both streams in each file? [01:13] <c_14> k0k: crop=w=iw-288:h=ih-128:x=168:h=60 [01:13] <c_14> not sure if crop counts from the top or bottom with heigh, you might need y=68 [01:13] <c_14> that last h is actually a y in disguise. [01:14] <k0k> how'd you get 288? [01:14] <k0k> er i mean [01:14] <k0k> if i put in 288 it'll go over the edge on one side [01:14] <c_14> 168+120 [01:14] <c_14> =288 [01:15] <k0k> wait i get it [01:15] <k0k> ok thank you [01:15] <k0k> i'll try it out [01:20] <sythe> c_14: Yes, it does [01:21] <c_14> Then I have no clue anymore. [01:21] <sythe> This is ridiculous [01:21] <sythe> c_14: I used a script that did it successful, but it took nearly an hour [01:21] <sythe> Can I link the output? [01:21] <c_14> sure [01:22] <sythe> https://www.irccloud.com/pastebin/U90H3mzV [01:22] <sythe> c_14: ^ [01:22] <sythe> I'd like to just reverse-engineer that [01:22] <sythe> So I can use it w/o it taking an hour [01:23] <sythe> Although maybe it took an hour because it brute-forced it, or something? [01:23] <sythe> The end result file was 1/2 the size of the original [01:25] <c_14> what you could try is a similar approach to what the script does [01:26] <c_14> extract the audio track from each of the files to another separate file [01:26] <c_14> ie: ffmpeg -i file -c:a copy out.mp3 [01:26] <sythe> c_14: Wouldn't that take the same amount of time as the script? [01:26] <c_14> that script does weird things [01:26] <c_14> I have not gotten it to work on any of my computers. [01:26] <sythe> Also, can I check the FPS of a file with ffmpeg? [01:27] <c_14> And the last person I helped in here who used it had to edit some lines in the script. [01:27] <c_14> ye [01:27] <sythe> how? [01:27] <c_14> ffprobe, look in the video line [01:27] <c_14> $number fps [01:29] <sythe> That's odd [01:29] <sythe> My settings are at 30 FPS [01:29] <sythe> But the video files are 17 FPS [01:29] <c_14> only the first one, the second is at 30 [01:30] <c_14> endslate-new.mp4 that is [01:30] <sythe> Yeah, that's the end slate [01:30] <sythe> Not the actual footage [01:30] <sythe> ugh [01:32] <sythe> Well, thanks [01:32] <sythe> I'm going to try recording with different settings [01:32] <sythe> c_14: Is there anything I could remove from that script to speed things up? [01:33] <k0k> @c_14 the cropping works, kind of convoluted compared to the old one but i guess it's just addition [01:33] <k0k> thank you for the help [01:33] <c_14> np [01:33] <c_14> sythe: You can try changing preset medium to preset ultrafast in EXTRA_OPTIONS [01:33] <c_14> You can also change the crf and audio bitrate there [01:33] <sythe> c_14: Does that result in a drop in quality? [01:34] <c_14> Not if you're encoding with crf, it'll just make the file larger for the same quality. [01:34] <sythe> ah, awesome, thanks! :) [03:44] <fling_> I have a bunch of videos from a security cam. [03:44] <fling_> How to split them in parts with and without movement? [03:44] <fling_> I only want to keep videos containing movement [05:59] <limiteddi> Hello [06:00] <limiteddi> trying to compile ffmpeg from the instructions on the website and for some reason I get ERROR: libx264 not found [06:00] <limiteddi> i've compiled before with no issues, never had this issue before [06:02] <limiteddi> how can I fix this? [06:06] <limiteddi> on it, give me 1 minute [06:06] <limiteddi> ahh, it just configured. I added --extra-libs=-ldl -> but i never had to do this for any of the ubuntu 14.04s i installed it on [06:07] <limiteddi> do you still want to see an log uploaded to see what tje issue [06:07] <limiteddi> the issue was with the config procedure from the web? [06:13] <sacarasc> You followed https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu ? [06:27] <limiteddi> yes [09:29] <Wintershade> hey guys, anybody alive around here? I have a few questions for the skilled people... [09:34] <sfan5> Wintershade: just ask, if someone can answer they will [10:09] <Wintershade> well anyway... does anyone know how to do a dynamic range compression on audio tracks? like the DRC in Handbrake. since I'm downmixing multichannel to stereo (using libmp3lame), and my audio ends up way too quiet in some places, and way too loud in other. any way to correct that? thanks [12:01] <Alina-malina> hello all [12:01] <Alina-malina> how to setup this ffmpeg on windows xp and convert video to remove the sound and leave only mp4 video? [12:02] <Mavrik> you download a windows static build [12:02] <Alina-malina> ok downloading [12:02] <Alina-malina> then next what? [12:02] <Alina-malina> how to remove the sound from video? [12:02] <Mavrik> and then run "ffmpeg <input>.mp4 -codec:v copy -an output.mp4" [12:02] <Mavrik> and then you read the manual if you want more ;) [12:03] <Alina-malina> ok let me try:) thanks alot [12:03] <Alina-malina> videos are the weak part for me [12:03] <Alina-malina> so i get stress and panic when i need to work with those [12:06] <Alina-malina> Mavrik, erm [12:06] <Alina-malina> i get error Not overwriting - exiting [12:07] <Alina-malina> File 'P1070132.MP4' already exists. Overwrite ? [y/N] n [12:07] <Wintershade> Alina-malina: type -y instead of -n [12:07] <Mavrik> no. [12:07] <Mavrik> wth [12:07] <Mavrik> Alina-malina, why are you writing OVER your input file? [12:07] <Mavrik> and, of course, ffmpeg will stop if you tell it to not write over your input file :) [12:07] <Alina-malina> i do this: ffmpeg P1070132.MP4 -codec:v copy -an output.mp4 [12:07] <sfan5> Alina-malina: you forgot an -i [12:07] <Alina-malina> :-/ [12:08] <Mavrik> yes, -i at the beginning [12:08] <sfan5> ffmpeg -i P1070132.MP4 -c:v copy -an output.mp4 [12:08] <sfan5> that one should work [12:08] <Alina-malina> yes hehe [12:08] <Alina-malina> it is doing something [12:08] <Alina-malina> hehe [12:08] <Alina-malina> it is 500MB fiel [12:08] <Alina-malina> file* [12:08] <Alina-malina> i hope it will not take too long [12:08] <Alina-malina> WONDERFUL! [12:08] <Alina-malina> I <3 FFMPEG! [12:09] <Alina-malina> thank you everyone [12:10] <sfan5> it didn't take long because it was just copying the video [12:12] <Alina-malina> heh right [13:41] <xlinkz0> how can I use an android phone's camera as input? [13:42] <xlinkz0> i want to encode using the phone's hardware video encoder and save the stream with ffmpeg [13:42] <jewels> hi there. I have "swf" files which contains a single frame. I need to convert this single frame into a picture (jpg or png image format). How can I do it with ffmpeg? I've tried to use ffmpeg -i image.swf image-%d.jpg but I receive this error: Failed to uncompress one bitmap [13:43] <brontosaurusrex> jewels, afaik there are swf decompilers which should return the pic as well [13:43] <xlinkz0> jewels: after the input file use '-f image2' [13:45] <jewels> xlinkz0: ffmpeg -i slide-1.swf -f image2 slide-1-%d.jpg produces the same error [13:46] <jewels> I also receive this error: slide-1.swf: could not find codec parameters [13:48] <ersatzbeardr> jewels: swf files aren't video files, they are more like zip files with a lot of metadata, you need to use something that decodes the swf in a way you find meaningful to feed into ffmpeg [13:49] <ersatzbeardr> what i've done in the past is create another swf file that loads the first one then outputs the contents of it as a bitmap [13:50] <jewels> ersatzbeardr: how can I do it using ffmpeg? [13:51] <ersatzbeardr> i don't think new ffmpegs include a swf disassembler [13:51] <ersatzbeardr> and i don't think there are any free disassemblers / unpackers [13:51] <ersatzbeardr> http://www.swftools.org/ [13:52] <ersatzbeardr> so maybe try swfextract ^ and then feed that into ffmpeg if you have to [13:52] <ersatzbeardr> i'll say it again: a swf file isn't really a video stream container in a classic sense [13:53] <vladtv> hello, Can I use the technology intel quick sync in linux for video encoding x264? [13:55] <sacarasc> If you get the SDK and code it, probably. I don't know of anything that does it, though. [14:03] <xlinkz0> libav was working on a quick sync module [14:03] <sacarasc> Oh, neat. [14:03] <sacarasc> Which means it would be in ffmpeg after its finished, too, I guess. [14:05] <vladtv> xlinkz0: os it use in ffmpeg? [14:05] <vladtv> is* [14:06] <Mavrik> afaik unless you actually use quicksync for full pipeline it's not worth it [14:06] <xlinkz0> i don't think ffmpeg has that functionality yet [14:11] <vladtv> I want transcode 1080i in 240p,360p,480p,720p but cpu load very big without hardware acceleration [14:14] <sacarasc> Which CPU do you have? [14:14] <vladtv> i7-2600k [14:15] <Mavrik> CPU load will always be big. [14:15] <sacarasc> Do you do it all as one ffmpeg command, or as 5, vladtv? [14:17] <vladtv> as 5) [14:18] <sacarasc> I think if you do it as 1, you just have to decode the video once, so it should be less time. [14:18] <sfan5> it wouldn't make sense for ffmpeg to decode the video 5 times if it's just one command [14:41] <Wintershade> hey guys, would anyone take care to look at my ffmpeg libxvid command line? http://pastebin.com/Z212XRD5 the problem I have with it is that it's painfully slow (less than ~10 FPS on pass 2), and I'd like to speed it up with as little quality loss as possible. thanks! [14:42] <Wintershade> the raw script is here, you can easily paste it into a text editor and run it with any video file you may have. http://pastebin.com/raw.php?i=Z212XRD5 [14:55] <relaxed> Wintershade: does -threads 0 do anything with libxvid? I thought 0 only applied to libx264 [14:55] <relaxed> look at `htop` [14:56] <Wintershade> relaxed: I thought -threads 0 meant automatic threads detection. [14:56] <Wintershade> relaxed: will look at htop now. hang on for a moment. any leads to what I'm looking for? [14:56] <relaxed> for libx264, but again, look at htop [14:56] <relaxed> to see if it's using multiple threads [14:58] <Wintershade> relaxed: okay, I see a number of threads... like 13? that can't be right... [14:59] <relaxed> at the top of htop you'll see each of your cores gets a number [14:59] <relaxed> are they all running at 100% [14:59] <Wintershade> let's try that again... [15:01] <Wintershade> relaxed: they're almost at ~100%... soon enough they get up to 100% [15:03] <relaxed> ok, at least you know they're all being used [15:03] <Wintershade> lol, that helps a lot :D [15:03] <relaxed> try -threads 3 [15:03] <Wintershade> I'll try with a different -threads value. since I only have 2 cores, and I see ~10 open threads, that might be slowing it down... [15:03] <Wintershade> let's see. [15:04] <relaxed> you might get better speeds using the native mpeg4 encoder [15:05] <Wintershade> nope, tried it. plus the quality sucks compared to libxvid :( or I'm not proficient with using it. [15:05] <Wintershade> hey, I need to dash for an hour or so. will you be here later? [15:05] <relaxed> I live here [15:06] <Wintershade> relaxed: I'll ping you when I get back. [15:20] <Hammad_> Can someone tell me if there's an error in this code. ffmpeg -i rtmp://91.xxx.5.xxx -rtmp_app live -rtmp_playpath livestream -rtmp_pageurl http://xxx-xxx.net -rtmp_swfurl http://xxx-xxx.net/player.swf -rtmp_live 1 -re -isync -vcodec copy -acodec copy -f output.mp4 [15:20] <Hammad_> I keep getting this. [rtmp @ 0x641e40] Unknown connect error (unsupported authentication method?) [15:20] <Hammad_> [rtmp @ 0x641e40] Server error: [ Server.Reject ] : Invalid uri : rtmp://91.xxx.5.xxx:1935/ [15:20] <Hammad_> rtmp://91.xxx.5.xxx/: Unknown error occurred [15:22] <spaam> try adding -rtmp options before -i [15:22] <xebra> hi, what protocol should I use (if it is actually possible) for live streaming? (by "live" I actually mean in real time, like skype, without increasingly growing lag). Thanks [15:23] <Hammad_> spaam, [15:23] <Hammad_> Unrecognized option 'rtmp'. [15:23] <Hammad_> Error splitting the argument list: Option not found [15:34] <c_14> move the rtmp_{app,playpath,pageurl,swfurl,live} options in front of the i [16:05] <joselo> Hi there! [16:06] <joselo> I'm having trouble copying a live stream here is the command I'm using and the result: http://pastebin.com/jepC4r7y [16:06] <joselo> I'm new using ffmpeg so I'm not sure if I'm missing something [16:09] <c_14> try adding -fflags +genpts [16:20] <joselo> I tried it [16:20] <joselo> it doesn't work [16:20] <joselo> the same error appears [16:24] <c_14> Did you add it as an input or an output option? [16:24] <joselo> as an output [16:24] <joselo> should it be at the input? [16:25] <joselo> ok as an input option it works [16:26] <joselo> now the thing is that at 1:04 it stops the process [16:26] <joselo> always [16:29] <c_14> Ah, I remember you. [16:29] <c_14> You've been here before. [16:30] <c_14> It doesn't error out, it just stops, right? [16:32] <Wintershade> relaxed: hey man, still here? [16:34] <joselo> c_14: yeah its me, sorry I've took a while to respond [16:37] <c_14> joselo: if you add a -ss 20 or something as an input option, does it still die after 1:04? [16:37] <joselo> yeah it just stops no errors, look at this: http://pastebin.com/MPJESdfr [16:39] <joselo> whith the -ss option it died at 44 secs [16:39] <joselo> -ss 20 [16:39] <c_14> ok, let's try -ss 65 [16:39] <Wintershade> joselo: did you try using the fully -ss syntax? like -ss 00:00:20 for 20 seconds? [16:39] <Wintershade> *full -ss syntax [16:40] <c_14> Wintershade: I'm pretty sure there is no difference between giving seconds and giving the full timestamp since that's handled by the utils. [16:40] <Wintershade> c_14: I know, but this is ffmpeg :D the syntax changes from one version to another, who knows what they did now. [16:41] <Wintershade> (didn't mean that as a bad thing, mind you) [16:41] <c_14> joselo: In case you're wondering, I'm trying to seek past the failure point to see what happens. [16:42] <Wintershade> c_14: have you tried converting the video to another container? perhaps the failure happens due to a broken container. [16:42] <c_14> He had tried using mp4 before. Didn't work there either iirc. [16:42] <Wintershade> try using mkv or (even better) ogm. ogm is my personal favourite for such stuff, because it's the most robust of all (from my experience). [16:43] <c_14> He is using mkv. [16:43] <Wintershade> so mp4 --> mkv? [16:43] <c_14> rtsp -> mkv [16:43] <Wintershade> oh dear. [16:44] <Wintershade> oh I see. [16:45] <joselo> well seeking past the point of failure just stops the process as soon at it gets to the seeking position [16:45] <c_14> Have you tried playing the stream with a video player such as ffplay,mpv/mplayer or vlc? [16:45] <joselo> yeah [16:45] <c_14> And it can play more than 1:04? [16:45] <Wintershade> joselo: try xine. if xine breaks, it means your file is broken :D [16:52] <joselo> I tried playing with realplayer and also with mplayer, mplayer stops at 1:04, realplayer plays past this point [16:53] <Wintershade> joselo: have you tried mplayer with another video output driver? [16:53] <joselo> how could I try that? [16:53] <Wintershade> joselo: if you're using vdpau or some forms of gl output, those are very good but tend to break when issues occur [16:53] <Wintershade> joselo: well [16:54] <Wintershade> joselo: the simplest way would be to install smplayer (a graphical mplayer frontent), which gives you this as an option in it's Preferences window [16:54] <Wintershade> joselo: if you're using any binary Linux distro (Ubuntu, openSUSE, Fedora, etc.) you should be able to install it in no time, all repos have it [16:55] <joselo> ok, i have MplayerX [16:55] <Wintershade> joselo: I don't know anythign about MplayerX. if you have some sort of preferences there, try locating an option that sounds like "video driver". [16:56] <brontosaurusrex> joselo, there should be a mpv for mac [16:57] <Wintershade> joselo: oops, you're on a Mac? sorry, didn't catch that :( [16:58] <brontosaurusrex> no i don't know, but i think mplayerX is mac stuff [16:58] <Wintershade> oh. [16:58] <Wintershade> ...that would explain why I never heard of it :-/ [16:58] <joselo> yeah MplayerX is for mac [16:58] <joselo> im running mac osx [16:59] <joselo> mplayer x is pretty similar to mplayer in ubuntu [16:59] <Wintershade> ...then scratch everything I said. I have no idea about video output drivers on mac. I know Linux has a wealth of them (too many, imho), but I don't know about Mac [17:00] <joselo> maybe i will try setting up a ubuntu vm to try all this, I feel a little trapped in my mac env [17:00] <Wintershade> lol [17:01] <brontosaurusrex> joselo, mpv is working fine, i have it on both of my macs [17:01] <Wintershade> joselo: just a quick question. in a nutshell, what are you trying to accomplish? [17:02] <joselo> ok so no problem with mpv, [17:02] <joselo> Wintershade: I'm trying to save a live stream (from an ip camera) to a file into my disk [17:03] <joselo> I would prefer an mp4 file but as long as it works for more than a minute 4 secs i dont mind if it is mkv [17:03] <Wintershade> joselo: I suppose you already tried just making a direct stream copy to another container. right? [17:03] <joselo> I need to save for at least an hour [17:04] <Wintershade> joselo: like, ffmpeg -i <your input file> -codec:a copy -codec:v copy -y <output file>.mkv [17:04] <c_14> That's what he's been trying. [17:04] <Wintershade> ok. how many streams are in the file? [17:04] <Wintershade> just one audio and one video? [17:04] <Wintershade> no subtitles or such stuff? [17:05] <c_14> As far as I can see, yes. [17:05] <Wintershade> what does ffmpeg -i <input file> say? got a pastebin link or something? [17:05] <c_14> http://pastebin.com/MPJESdfr [17:06] <Wintershade> let's see [17:07] <Wintershade> hmm. a stupid idea - have you tried just copying the file to your hard disk first? [17:07] <c_14> The sdp file? [17:07] <Wintershade> yes [17:07] <Wintershade> like "cp <path to sdp file> ." [17:08] <joselo> What will I accomplish copying that file? [17:09] <c_14> The sdp file is just a metadata file, it only contains things like the stream url. [17:09] <c_14> iirc [17:09] <joselo> Wintershade: look at this one http://pastebin.com/7Gr6YQmm [17:09] <c_14> What you could try is grabbing the stream with curl... [17:10] <Wintershade> good idea! [17:10] <Wintershade> that's what just sprang to my mind. [17:11] <Wintershade> also, there should be an ffmpeg option to ignore errors... in case you haven't tried it yet... [17:12] <c_14> You mean -fflags +discardcorrupt ? [17:13] <Wintershade> c_14: that and -f_err_detect +ignore_err [17:13] <Wintershade> also... [17:13] <Wintershade> joselo: have you tried a concat as an input, rather than raw stream? [17:14] <Wintershade> joselo: like ffmpeg -i concat:/path/to/file... [17:14] <joselo> no I havent tried that [17:14] <joselo> also maybe a stupid question but how could I grab the strem with curl? [17:14] <joselo> stream** [17:15] <Wintershade> joselo: curl <path to your stream> [17:15] <c_14> try curl -o out rtsp://foobar [17:15] <Wintershade> joselo: ...I think :D [17:15] <Wintershade> joselo: that. what c_14 says. [17:15] <Wintershade> curl is a beautiful app with a tl;dr-ish manpage... [17:16] <joselo> ok thanks, I have a lot of ideas from what you say, right now I have to leave but will be around here to update the status [17:16] <Wintershade> joselo: good luck! [17:18] <Wintershade> so... anyone have any ideas on how I should do a dynamic range compression on my audio in ffmpeg? [17:19] <Wintershade> i.e. my audio is too quiet in several places, and too loud in other. I want to make the quiet bits louder, and quiet down the loud parts a tad bit. [17:29] <c_14> I'm guessing the compand filter can be used for that. [17:31] <Wintershade> c_14 yeah... that's what scares me. it's the first filter I've seen so far that actaully scares me. [17:31] <c_14> The attacks and decays I understand. But the points... [17:39] <Wintershade> c_14: I understand those too. perhaps I should just be ballsy and leave everything at default, touching just the stuff I understand... [17:39] <Wintershade> c_14: ...which leaves me with a lot of defaults :D [17:41] <c_14> I think I kind of understand the points now, but I'd probably do that too. [17:48] <Wintershade> c_14: got any ideas on which parameters I should use? e.g. I want to amplify the quiet bits by ~30-40% and limit the loud bits to say ~95% of normal audio [17:48] <Wintershade> c_14: I know it shouldn't be that hard, but my brain is farting, I've had way too little coffee, and even less smokes, and I haven't slept enough :( I'm currently as cliché as you can get. [17:58] <c_14> probably something like -60/-45|-40/-30|-20/-20|0/-5 ? [17:59] <c_14> If my understanding is correct that should boost quiet audio by 10%<x<100%, boost medium quiet audio by 10% keep normal audio normal and chop loud audio by 0<x<10% [17:59] <Wintershade> c_14: thanks, I'll try them out and play around. I have to go now, thanks a lot to everyone. [20:27] <ersatzbeardr> hey guys, i'm not sure what to look at in the docs / google for, i want to build a stream that is made up of 3 png images that display for various time slices, but otherwise is just a fill color [20:28] <ersatzbeardr> so 0s..5s:white, 5s..7s:1.png, 7s..12s:white etc [20:29] <c_14> Look at the color video source. [20:29] <ersatzbeardr> would i just generate a collection of different sized videos then concatinate them together [20:30] <c_14> https://ffmpeg.org/ffmpeg-filters.html#color_002c-haldclutsrc_002c-nullsrc_… [20:30] <ersatzbeardr> okay will take a look [20:31] <c_14> Either put 3 of those in a filter_complex and then concat with the concat filter, or use them as lavfgi inputs and concat those. [20:32] <ersatzbeardr> thanks c_14 this looks good [20:32] <c_14> *lavfi [22:32] <ersatzbeardr> c_14: man that's great [22:32] <ersatzbeardr> i should have learned filters ages ago [22:32] <ersatzbeardr> thanks [22:32] <c_14> np [22:54] <xebra> hi, are the static builds available at the links on the ffmpeg website... without support for x11grab? I just tried them, and I get "Unknown input format: 'x11grab' [22:54] <sacarasc> Correct. [22:55] <xebra> nooooo :( [22:59] <sacarasc> Which distro are you on? [23:03] <xebra> Windows Vista! I'm kidding... Xubuntu. [23:09] <sacarasc> And you don't want to compile yourself? [23:11] <beastd> xebra: If you decide for compiling yourself you can consult our wiki for help: http://trac.ffmpeg.org/#CompilingFFmpeg [23:11] <xebra> I'm reading about it right now [23:11] <beastd> xebra: Building yourself should be fairly easy and take not too much time. [23:13] <beastd> xebra: OFFTOPIC: There is still hope there will be Ubuntu Packages again at some day in the future: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#787 [23:14] <xebra> Yeah. Maybe it's about time I learn some stuff about compiling. I'm especially interested in static builds and creating packages (deb). "Classic" compilation has always seemed "dirty" to me. [23:17] <beastd> xebra: Well if you will learned about building Deb packages, you can try to build the debs from the source packages we prepared for Debian. Not sure what is needed if anythingy to make them work on Ubuntu. The git repo with the package sources (currently on alioth collab-maint) is mentioned in the link I gave you before. [23:18] <beastd> xebra: Though building static binaries from FFmpeg source should be much easier than building the Debian packages for a start. [23:39] <LinManHD> Yo [00:00] --- Tue Jul 29 2014

1 0

ffmpeg-devel.log.20140727
by burek 28 Jul '14

28 Jul '14

[00:00] <cone-621> ffmpeg.git 03Anton Khirnov 07master:73bb8f61d48d: hevcdsp: remove an unneeded variable in the loop filter [00:01] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:226b290f9f73: Merge commit '73bb8f61d48dbf7237df2e9cacd037f12b84b00a' [00:27] <cone-621> ffmpeg.git 03Pierre Edouard Lepere 07master:1a880b2fb845: hevc: SSE2 and SSSE3 loop filters [00:27] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:706f81a2c275: Merge commit '1a880b2fb8456ce68eefe5902bac95fea1e6a72d' [00:36] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:d4a9e89b2796: avcodec/x86/hevcdsp_init: make license header consistent [00:36] <cone-621> ffmpeg.git 03James Almer 07master:bfb3b2b7a6ec: x86/hevc_idct: add 12bit idct_dc [01:24] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:8b1d54ba40ff: doc/examples/muxing: free swr context at the end [01:25] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:a98cadef7fe1: doc/examples/muxing: Move samples_count to OutputStream [01:25] <cone-621> ffmpeg.git 03Anton Khirnov 07master:22e9fe06ebb6: doc/examples/muxing: add alloc_audio_frame() and use it to simplify code. [01:30] <J_Darnley> Well clang still can't compile ffmpeg here. [01:30] <J_Darnley> I don't know why I was so disappointed though. [01:56] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:fbd46e2f1cae: doc/examples/muxing: Always use swr, simplifies code slightly [01:56] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:d1ce43a3e8fe: doc/examples/muxing: mark correct frame as writeable [02:23] <cone-621> ffmpeg.git 03Diego Biurrun 07master:7215fcf84032: avformat: Mark AVOutputFormat argument in avformat_query_codec as const [02:23] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:57e7d9d92978: Merge commit '7215fcf84032118ecd9fb54fb14154d69fea638d' [02:29] <cone-621> ffmpeg.git 03Mickaël Raulet 07master:29228dbd24fd: fate/hevc: add BUMPING bitstream test [02:37] <michaelni> mraulet, about adcdabb4dd062694fb8de6df0faecaad1c36ba33, is it completely useless to test the older files ? [02:38] <michaelni> because that seemed to remove them [02:50] <cone-621> ffmpeg.git 03Mickaël Raulet 07master:7bb3e70c06ea: fate/hevc: add flags unaligned [02:50] <cone-621> ffmpeg.git 03Mickaël Raulet 07master:e97f5bef95a2: fate/hevc: adding CONFWIN_A conformance test [03:57] <cone-621> ffmpeg.git 03Chris \"Koying\" Browet 07master:ad91bf854b55: avcodec/h264_mp4toannexb_bsf: fix issue when sps/pps are already in the bistream [10:02] <ubitux> michaelni: sad & diff_pixels are needed externally currently or not yet? [11:59] <michaelni> ubitux, "libavfilter/vf_deshake.c: #define CMP(i, j) deshake->c.sad[0](NULL, src1 + cy * stride + cx, \" [11:59] <michaelni> ubitux, libavfilter/vf_mpdecimate.c: pdsp->diff_pixels(block, [12:04] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:c437765be762: doc/examples/muxing: Exchange tmp_frame and frame [12:36] <cone-621> ffmpeg.git 03Anton Khirnov 07master:541427ab4d5b: eamad: use the bytestream2 API instead of AV_RL [12:36] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:c2ef844aa74c: Merge commit '541427ab4d5b4b6f5a90a687a06decdb78e7bc3c' [12:46] <ubitux> michaelni: i don't consider them external [12:46] <michaelni> well ABI wise they are external [12:47] <ubitux> accessing them through avpriv is not ok? [12:48] <ubitux> currently that what we do, unless i'm mistaken [12:48] <michaelni> i really dont care, but you pile up APIs that must be maintained for years [12:49] <michaelni> i mean avpriv in libavutil, then if its used externally add av and then whatever libav will use [12:49] <ubitux> i just wanted to make sure it wasn't that urgent to export sad & friends properly [12:49] <ubitux> so i can do that properly [12:49] <ubitux> you were talking about the debian packaging; by that you were talking about dct stuff for mplayer typically, no? [12:49] <michaelni> no [12:50] <ubitux> :( [12:50] <ubitux> i don't understand the issue & hurry then [12:50] <michaelni> libavfilter is AFAIK a seperate package in how libav is packaged and how the various ffmpeg debian packages are packaged but i didnt double check [12:51] <michaelni> so libavfilter is external as far as debian & ubuntu are concerned [12:52] <ubitux> it's external but they can access avpriv symbols nevertheless [12:52] <ubitux> so basically avpriv_dsputil_init() should still be accessible [12:52] <ubitux> i guess the concern is about ABI stability? [12:54] <michaelni> yes, didnt i say this in my patch? [12:55] Action: michaelni has the feeling people had only the goal to flame and didnt care beyond that [12:55] <michaelni> "This provides a public sustainable API/ABI for DSP functions." [12:56] <michaelni> the goal was to add something that can be kept compatible and can be extended long term [12:56] <michaelni> i understand people dont like its "dsputil look" [12:56] <michaelni> but that sadly is the easiest way to do it [12:57] <ubitux> there is nothing that hard in exporting it properly, but yes i requires some little more amount of time [12:57] <ubitux> i was just wondering about the urgency [12:57] <michaelni> it should have been fixed years ago really [12:59] <michaelni> but IMO fixing it before 2.4 is pretty much mandatory [13:00] <ubitux> sure [13:00] <ubitux> when is 2.4? [13:00] <michaelni> in the past we didnt notice as it worked in practice, but now as we noticed we should not leave such ABI issue unfixed [13:00] <ubitux> really i was just asking if i need to submit a patch tonight or if i have one week or two to make things clean [13:01] <michaelni> a week should be fine [13:01] <ubitux> ok [13:01] <ubitux> (note: i'm just working on the lavu/pixelutils one) [13:01] <ubitux> (with the different sad & diff) [13:02] <michaelni> but note, if by the time of 2.4 release i have no other solution then i will push the one we have as i refuse to release with such a bug in the ABI [13:02] <ubitux> can you do the AVDCT one? [13:03] <michaelni> i sure can rename the stuff [13:03] <michaelni> and remove non dct [13:04] <michaelni> about radically changing API to fast/slow style i have no idea how to do that [13:04] <michaelni> removing arch specific identifiers i can do too but i see only disadvantages from that [13:05] <michaelni> it would make debuging harder [13:05] <michaelni> if we ever need to debug [13:05] <iive> are you talking about dct? [13:06] <michaelni> yes [13:06] <iive> fast/slow is wrong metrics... a number of algorithms have specific error tolerance that is needed for properly decoding some samples [13:07] <michaelni> the suggestion was fast vs accurate [13:08] <iive> well, float dct is the most accurate, but when you have used old mpeg2 butchering fdct, it have introduced errors, that must be matched by the decoding one. [13:08] <iive> you are well aware of the early xvid green tilting. [13:08] <michaelni> yes, but the idcts probably (but who knows) wont be used for decoding [13:09] <iive> ? [13:09] <ubitux> the important thing is just to not export the cpu-specific option names for dct names [13:09] <ubitux> FF_IDCT_SIMPLEMMX, FF_IDCT_ALTIVEC, ... [13:09] <ubitux> this should not be visible to the user [13:09] <michaelni> iive, its about exporting (i)dcts properly so libavfilter and libmpcodecs can use them through proper public API/ABI [13:10] <michaelni> ubitux, user should use avoptions [13:10] <ubitux> yes, but not "simplemmx" or "altivec" [13:10] <iive> if there is proper api, somebody would come with the idea to use it for decoders too. [13:10] <michaelni> there are entries in the AVOption table for "simplemmx" or "altivec" currently IIRC [13:10] <ubitux> you don't want to pick the cpu optimization at idct level [13:11] <iive> the question here is, e.g. is idct_simple_C and idct_simple_MMX produsing same output? [13:11] <ubitux> you have the av cpu_flags stuff for that [13:11] <michaelni> iive, no [13:11] <iive> and what could match the altivec dct. [13:12] <ubitux> iive: if not, then "optimized", "nonoptimized" or stuff like that [13:12] <michaelni> also nothing matches the xvid sse one if you dont have sse [13:12] <ubitux> maybe just "simple+bitexact" for C [13:12] <michaelni> IIRC [13:12] <ubitux> "simple" for simple with optim (mmx/altivec/whatever) [13:12] <michaelni> and some of the simple arm ones differ in values from C simple [13:12] <michaelni> ubitux, mmx simple == permutated C simple [13:13] <michaelni> mmx is bitexact IIRC just permuted differently than C simple [13:13] <ubitux> whatever fills correct [13:13] <ubitux> but please something understand for the user and not a cpu flags soup with different behaviour exported to the users [13:13] <ubitux> it's insane [13:13] <BBB> I dont think it has to match (simplemmx vs. simplec), the swscale mmx isnt bitexact either [13:14] <BBB> so using -cpuflags for selecting simplec vs. simplemmx is fine [13:14] <ubitux> exactly [13:14] <michaelni> ok so what about the xvid IDCT ? [13:14] <ubitux> "xvid" [13:14] <michaelni> FF_IDCT_XVIDMMX [13:15] <michaelni> theres no C version [13:15] <ubitux> "xvid" + warning if "bitexact" or !intel cpu [13:15] <ubitux> >? [13:15] <iive> how about keeping the internal number, but also providing a table so the applications could pick dct on their own. e.g. the table would have cpu_flags for capabilities, error ranges and stuff like that. [13:16] <ubitux> remember, it's something we show to the user: if you want to change it later it will be incredibly harder because of the deprecation process [13:16] <ubitux> so we better get it right, or at worse not complete for a start [13:17] <michaelni> well, i guess we could just leave the idct and dct_algo options out [13:17] <ubitux> yes, better export only the needed bits, and make possible to add later [13:18] <michaelni> and once some volunteer implemented their favorite API and added themselfs to MAINTAINERs we can allow people to select the (i)dct they want for the external API [13:19] <michaelni> should i leave the *_algo in there under #if 0 or remove completely ? [13:22] <michaelni> ubitux, also if *dct_algo is removed its no longer possible to select bitexact (i)dcts [13:23] <iive> you don't like the idea with the table? [13:26] <michaelni> iive, iam happy about anything, but as i dont understand what people are trying to fix i cant help/choose how to fix it [13:26] <michaelni> that is i dont understand what wrong people see in the AVDSP API [13:28] <michaelni> the *dct_algo allows selecting the implementation, one could conceivable wrap that under some other system but for debuging i need to know the impleentation and want to select it i dont think it would help a developer if he had to select an implementation by using a set of speed/permutation/aan/float flags [13:28] <michaelni> it might appear prettier of course [13:29] <michaelni> iive, a table of attrbutes for the implementations would make sense for sure [13:31] <michaelni> if such a table is wanted (BBB & ubitux ?) i could look into it but it feels a bit orthogonal to the API question but maybe i misuderstood [13:33] <ubitux> as i said, i have 2 concerns: having AVDSP with a lot of unrelated stuff (but this will be fixed with having only a AVDCT API), and the fact that we have CPU-specific flags at this user-idct-level feels extremely wrong [13:33] <ubitux> and in both cases, removing stuff from either of the two in the future will be extremely hard [13:33] <ubitux> because it is a public api [13:34] <ubitux> (and in both cases we *will* need to remove them to make a decent interface) [13:34] <michaelni> ubitux, ok if i leave idct_algo with "auto" and "simple" options so we can at least select bitexact mode ? [13:35] <michaelni> aka force simple idct [13:35] <ubitux> of course, we can have "auto" (whatever than means), "simple", "bitexact", or even "xvid" [13:35] <ubitux> i just don't want "mmx" or "altivec" in them :p [13:36] <ubitux> (because it's handled at another level with -cpuflags) [13:36] <ubitux> what's "auto" btw? [13:36] <michaelni> do what the user would prefer [13:36] <michaelni> works 99.9999% of the time for decoders [13:37] <michaelni> like if cpu has MMX and its a xvid file use xvid mmx idct [13:37] <michaelni> otherwise pick the fastest [13:37] <ubitux> wouldn't that just be the default value for AVOption? [13:37] <michaelni> auto would be default [13:38] <michaelni> but auto isnt bitexact [13:38] <ubitux> > and its a xvid file [13:38] <ubitux> how is that defined with the current interface? [13:38] <michaelni> isnt [13:38] <ubitux> then there is no need for a "auto"? [13:39] <michaelni> auto does more [13:39] <michaelni> <michaelni> otherwise pick the fastest [13:39] <ubitux> you just need a dct type option, and a dct flags option, right? [13:40] <michaelni> or rather "fastest which is good quality" for decoders [13:40] <ubitux> like dct->{default,simple,xvid} flags->{bitexact,fast,...}? [13:41] <michaelni> where do simple with and without permutation fall in that ? [13:41] <ubitux> (fast being assumed with ~bitexact actually, and dct->defautl could be dropped with a default value on simple) [13:41] <michaelni> and where does the arm simple one with IIRC different rounding ? [13:41] <ubitux> flags +permutation ? [13:42] <ubitux> arm current cpu optim if ~bitexact? [13:42] <ubitux> (and if the dct and flags option are inconsistent, we can just warn) [13:44] <michaelni> ubitux, ok but what use case does this fix ? [13:44] <ubitux> it makes a simple and clean interface for users [13:44] <michaelni> no user ever used it [13:44] <ubitux> because it was messy [13:44] <ubitux> (and private?) [13:45] <michaelni> we lacked support for setting it from filters i think [13:45] <michaelni> but let me ask differently, why does a user want to change the (i)dct algo for a filter ? [13:46] <ubitux> no idea, but you seemed to be willing to make it possible for the user to customize it [13:46] <ubitux> i was going to suggest something like "dct": ["simple","aan","xvid"], "flags": ["permuted","bitexact"] [13:46] <michaelni> i wanted a way to debug code i maintain [13:46] <ubitux> (actually, "dctint" so we could have floats ones later) [13:46] <iive> I actually like the idea of having the idct_algo and the only publicly defined option set to auto. [13:47] <ubitux> "dct_algo": ["simple","aan","xvid"], "idct_algo": ["simple","aan","xvid"], "flags": ["permuted","bitexact"] ? [13:48] <ubitux> we can of course have only "simple" exported as a start [13:48] <ubitux> assuming that's what we only need [13:48] <michaelni> ubitux, i probably wont use this for debuging [13:48] <ubitux> debugging is not for the users [13:48] <michaelni> for debuging i need to select the algorithm used and cycle through them maybe to see which works if one doesnt [13:49] <ubitux> i don't mind a mess internally [13:49] <michaelni> yes, so i asked why a user wants to change that option [13:49] <ubitux> well, he probably doesn't [13:49] <michaelni> and what sense xvid or aan makes to a user in a filter [13:49] <michaelni> like spp [13:49] <ubitux> (but in that case why are you exporting everything in the first place?) [13:50] <michaelni> <michaelni> i wanted a way to debug code i maintain [13:50] <ubitux> by having everything exported to the user? [13:50] <ubitux> sorry i don't follow you here [13:52] <michaelni> what do you suggest ? put it under #if DEBUG ? [13:53] <ubitux> if it's just for you, why isn't avpriv just fine? [13:55] <michaelni> the *dct API is for filters which are used by users, selecting the (i)dct implementation is something i as maintainer of the (i)dcts and filters using them would like to be able to do [13:56] <ubitux> ok [13:56] <ubitux> then what about having first fields as public as following ones as private in the AVDCT (heap allocated) context? [13:56] <ubitux> s/as following/and following/ [13:57] <michaelni> ubitux, how does that work ? [13:57] <ubitux> and you can customize the idct type and stuff by hitting those fields while debugging [13:57] <michaelni> how do i select the (i)dct algorithm from the command like with private fields in a struct ? [13:58] <ubitux> avdct->idct_tpe = whatever in your filter [13:58] <ubitux> you're debugging, so you can just add a line in the code, no? [13:58] <michaelni> "debuging" might be due to a user telling me he sees wierd artifacts in a filters output, so i run ffmpeg and cycle trough the idcts to check if it makes a differece [13:59] <michaelni> if i have to change the code to select the IDCT what use is any API to me ? [14:00] <iive> i just want to point out few things. 1. selecting dct cannot be done by signle criteria. 2. it must be extensible without breaking api [14:00] <iive> that's why I think it is best to have idct_algo that uses the same values as internal ffmpeg. but don't expose these values through the public api. [14:01] <iive> have a different method for selecting them. e.g. table or avoptions. [14:01] <iive> this way for debugging a power user might try giving different numbers to it, without knowing what these numbers represent. [14:02] <wm4> I never understood why DSP functions need a "context", but oh well [14:02] <ubitux> michaelni: well and the (i)dct_algo + flags options would not be fine for that? [14:03] <ubitux> if so, i would not like it at all but you could just mark the current avoptions as "advanced/expert/unstable/warning/dontlookatit" whatever so we can change them whenever we feel the need to [14:05] <BBB> that sounds useful [14:05] <ubitux> but really, having meaningful option to implicit the selection would feel saner [14:05] <BBB> but yes, my primary concern was to not have AVDSP, but instead something more contained, like AVDCT [14:06] <michaelni> iam happy with anything with which i can simply and quickly cycle through the (i)dcts from the command line or select a specific one [14:07] <BBB> I like ubitux idea of marking the values were currently arguing about (simple$cpu) as experimental so we can change them [14:07] <michaelni> thats perfectly fine with me, they all can be marked as experimental or debug [14:08] <ubitux> is it really hard to drop the "mmx" and "altivec" and replace it with a ±bitexact flag? [14:09] <michaelni> it can probably be done [14:21] <BBB> ubitux: we can do that later, as long as its not a baked-in part of the API [14:22] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:b051a1bbb965: avcodec/arm/idctdsp_init_arm*: Only select non bitexact IDCTs by default when bitexact is not set [14:37] <ubitux> BBB: avoption are exported to the user [14:37] <ubitux> if you change them it's technically an api change [14:38] <ubitux> it these options are not meant to be used to the user we need to explicit it in order to change them later [14:42] <BBB> right, so mark them as experimental, we have a flag for that in AVOptions, right? [14:45] <michaelni> i dont think we have a flag for that, we could add one (but some user apps wont know about it then) or add it to the help text [14:46] <BBB> up to you guys [14:46] <BBB> has anyone done subidct tries for hevc? like what ffvp9 does [14:46] <BBB> given the 4x4 forced scanorder, it should work even better for hevc in some cases than it does for vp9 [14:52] <kurosu> BBB: I think openhevc does it for 32x32, using 16x16 [14:53] <kurosu> from what mraulet told me [14:53] <kurosu> rather, from what I interpreted from something mraulet said [14:55] <kurosu> on the other hand they haven't implemented intermediate count of coeffs between dc-only and full [14:56] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:fbeb634e4dda: avcodec/ppc/idctdsp: Only select non bitexact IDCTs by default when bitexact is not set [15:48] <ubitux> michaelni: s/expermintal/experimental/g [15:49] <ubitux> michaelni: s/debuging/debugging/g [15:49] <michaelni> both fixed [15:56] <ubitux> except a few nits i'm fine with that [15:56] <ubitux> michaelni: don't forget a stdint.h in the header [15:57] <ubitux> otherwise checkheaders will break [15:57] <ubitux> mmh, maybe it's included in the opt.h though [16:02] <michaelni> ubitux, opt.h uses intXY_t so it has to be [17:19] <BBB> kurosu: thats a code structure thing, not a speedup [17:19] <BBB> kurosu: a speed up would be to do the topleft (half in each dimension) sub16x16 for 32x32 [17:19] <BBB> thats different from doing a 16x16 idct [17:22] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:932ff7095696: avcodec: add avdct [17:22] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:e3fac208246f: avfilter/vf_spp: use AVDCT [17:50] <cone-621> ffmpeg.git 03Christophe Gisquet 07master:36284ae98153: x86: hevc_mc: replace one lea by add [19:16] <cone-621> ffmpeg.git 03Christophe Gisquet 07master:81943a10b500: x86: hevc_mc: load less data in epel filters [19:26] <michaelni> ubitux, whats the status of "Jul 23 08:02:28 <ubitux> (michaelni: i'll test the icecast thing so please don't apply in a hurry ;))" ? [19:26] <ubitux> ah yeah, i wanted to do that [19:26] <ubitux> give me an hour or two [19:27] <michaelni> ubitux, sure, also dont hesitate to review or apply if you consider the code ready [19:53] <ubitux> ePirat: ping [19:53] <ePirat> ubitux? [19:54] <ubitux> i'm currently testing the icecast patch, but i'm not able to make it work [19:54] <ePirat> ubitux, why? what error do you get? [19:54] <ubitux> i can start pushing, and after something like 2 seconds of push (i see a few data set) it's like the connexion is closed [19:54] <ubitux> without any message [19:54] <ePirat> which icecast version? [19:55] <ubitux> 2.4.0 [19:55] <ubitux> i should probably enable the logs though [19:55] <ePirat> yes please do so and give me the output of error log [19:55] <ePirat> without this I have no way to discover whats going on [20:01] <ubitux> ePirat: your patch strip the last character of the password [20:01] <ePirat> o_O [20:01] <ubitux> with that fixed it works fine [20:02] <ePirat> I have no Idea how it is possible that the last character is removed [20:02] <ubitux> going to look [20:03] <ePirat> did the password contain : or @ ? [20:03] <ubitux> standard ascii [20:03] <ePirat> provided in the url or using the option? [20:04] <ubitux> url [20:04] <ePirat> please try specifying it using the option [20:04] <ePirat> if it works then I know better what to look for [20:07] <ubitux> av_strlcpy(s->pass, p, strlen(auth) - user_len); this one is incorrect [20:07] <ubitux> you have a off by one [20:07] <ePirat> I wonder why& [20:07] <ubitux> the latest character gets replaced with a 0 [20:08] <ubitux> you can't reproduce? [20:09] <ePirat> no [20:09] <ePirat> just a second [20:09] <ubitux> i'm using the latest patch (that doesn't compile) on ffmpeg-devel [20:09] <ubitux> (you have a missing ");" on one of the av_log line) [20:10] <ePirat> wtf [20:11] <ePirat> I see& [20:11] <ubitux> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-July/160181.html [20:11] <ubitux> + av_log(h, AV_LOG_WARNING, "Streaming ogg but appropriated content type NOT set!\n" [20:11] <ePirat> thats weird& [20:11] <ubitux> i fixed that because it was obvious but well [20:12] <ubitux> anyway, try with "login:password@..." [20:12] <ubitux> you'll get user=[login] pass=[passwor] [20:12] <ubitux> even though auth=[login:password] [20:12] <ePirat> ok just a second [20:20] <ePirat> you are right& [20:21] <ubitux> you just miss a +1 in the pass len [20:21] <ubitux> but make sure it works as expected with 0 or 1 character len for either pass or login or both [20:22] <ubitux> "", "a:", ":b", "a:b" need to work :p [20:22] <ePirat> weird is: exactly the same code for the auth stuff works on avconv [20:23] <ubitux> is "auth" including the "@" in avconv? or maybe their strlcpy has an issue? [20:24] <ubitux> (or it's a bug on our side?) [20:25] <ePirat> ah wait seems it's broken there too& must have been when applying some of the recommended changes that I missed the +1 [20:28] <ubitux> ePirat: btw, you should automatically guess the content_type [20:29] <ePirat> it is impossible [20:29] <ubitux> you can use the mount point extension [20:29] <ePirat> no, as this can be anything [20:29] <ubitux> and you're able to guess what we are streaming [20:30] <ePirat> I cannot guess if video or audio [20:30] <ubitux> aren't you able to suggest the correct content_type in the warning? [20:30] <ubitux> at least try to automatically set it to this [20:30] <ubitux> with a warning "-content_type not set, assuming foo/bar" [20:31] <ePirat> Ok [20:31] <ePirat> my way of guessing it is _very_ lazy [20:31] <ubitux> it's good enough [20:31] <ePirat> can you maybe help me with the password problem? [20:32] <ubitux> yes of course [20:32] <ePirat> I have no idea why I would need a +1 since the user_len already has a +1 for the \0& but it seems I need it& [20:32] <ubitux> because of the ':'? [20:34] <ePirat> ah right [20:34] <ubitux> why aren't you doing strlen(p) instead btw? [20:34] <ubitux> actually... [20:34] <ubitux> you could just do s->pass = av_strdup(p); [20:34] <ubitux> after the p++ [20:35] <ubitux> you could even replace the ':' with a '\0' and do the same for the login [20:37] <ubitux> ePirat: so... sep=strchr(auth,':'); if (sep) { *sep=0; login=av_strdup(auth); pass=av_strdup(sep+1); } [20:37] <ubitux> with just a if (!login || !pass) return AVERROR(ENOMEM) [20:37] <ubitux> and you're good [20:37] <ePirat> ah& let me try. would be great [20:38] <ePirat> I would still need the memory allocated, right? [20:38] <ubitux> that's what av_strdup does [20:38] <ePirat> oh great [20:39] <ubitux> btw, unrelated, but for the cat_header() function, please use AVBPrint [20:39] <ubitux> it exists for exactly that purpose [20:39] <ePirat> what does it do? [20:39] <ubitux> it's an api for growing texts [20:40] <ePirat> ah I think I looked at it but it seemed very complicated [20:40] <ubitux> basically, you would just do av_bprint(bp, "%s: %s\r\n", key, value); [20:40] <wm4> yes this AVBPrint thing could be simpler [20:40] <wm4> it confuses me too [20:41] <ubitux> it's not really complex... [20:41] <wm4> let's just call it odd API design [20:41] <wm4> and whatever is up with this FF_PAD_STRUCTURE thing [20:41] <ubitux> you don't need to look at that [20:41] <wm4> (also probably UB strictly speaking) [20:42] <ePirat> ubitux, how would I need to initialized the login var when using av_strdup? [20:42] <ubitux> ? [20:42] <wm4> ubitux: well you have to "initialize" and "finalize" it [20:43] <ePirat> char *login = NULL; login=av_strdup(auth); ? [20:44] <ubitux> s->user = av_strdup(auth); ? [20:44] <ePirat> i removed user from the context, since it is only needed in the open function [20:45] <ubitux> so... what's your problem? [20:47] <ePirat> just unsure how to initialize the variable [20:47] <ubitux> why do you want to initialize it? [20:49] <ePirat> it is needed? [20:50] <ubitux> i'm sorry i don't know what you're asking me :p [20:50] <ePirat> :P I will just try if it works how I am thinking it works [20:52] <ubitux> btw [20:52] <ubitux> ./ffmpeg -re -i ~/samples/audio/rondo.flac -content_type application/ogg -method PUT ... [20:53] <ubitux> this works for me to push on icecast [20:57] <ePirat> yes I know [20:59] <ePirat> wow thanks ubitux [20:59] <ePirat> simplified my auth code _a lot_ [21:00] <ubitux> it's too bad the protocol hasn't access to the AVFormat [21:00] <ubitux> +Context [21:00] <ePirat> yes :/ [21:00] <ePirat> I am suprised no protocol needed this before [21:01] <ubitux> because you could have used the metadata for the name/description/... [21:02] <ePirat> 13 lines instead of 30 for splitting the auth string \o/ [21:03] <wm4> <ePirat> I am suprised no protocol needed this before <- there are plenty of protocols which are not implemented as protocols, but directly as avformats [21:04] <ubitux> ePirat: why do you need to split that btw? [21:05] <ePirat> ubitux, password can be specified using command line argument, most times it is not needed to set a username. [21:05] <ePirat> and a lot users do not even know what username they should use [21:06] <ePirat> ubitux, how do I do error handling with av_bprint(bp, "%s: %s\r\n", key, value); ? [21:07] <ubitux> you don't [21:07] <ubitux> you will at the finalize step [21:08] <ePirat> using av_bprint_is_complete() ? [21:09] <ubitux> yes [21:09] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:f285056810e6: doc/examples/muxing: fix "-flags" option [21:09] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:3d93ba562243: configure: fix memalign hack auto detection [21:10] <ePirat> ubitux, is there an example somewhere? I don't get how to init the buffer [21:11] <ubitux> av_bprint_init(&bp, 0, AV_BPRINT_SIZE_UNLIMITED); should be fine [21:12] <ePirat> what is bp? [21:12] <ubitux> AVBPrint bp; [21:12] <ePirat> ah [21:12] <ePirat> I was afraid using this [21:12] <ePirat> I tought it be might too much for my usecase :P [21:13] <ubitux> it will simplify your code [21:14] <ePirat> how do I get the string at the end? [21:14] <ubitux> you can use bp.str [21:14] <ePirat> ah [21:15] <ubitux> you can also finalize into a buffer [21:15] <ubitux> iirc [21:16] <ubitux> (so you can close the context right away and get a persistent allocated string) [21:18] <ePirat> these things are so hard to find [21:19] <ePirat> already had 3 things that I could replace with already in place av functions [21:20] <ubitux> btw, you could move the NOT_EMPTY check in your header-growing function [21:21] <ePirat> ? [21:22] <ubitux> instead of if (NOT_EMPTY(val)) headers = cat_header(headers, key, val); [21:22] <ubitux> move the NOT_EMPTY(val) into cat_header [21:22] <ubitux> so you gain a few lines [21:28] <ePirat> ubitux, ok [21:29] Action: ePirat wonders if it will work :P [21:29] <ubitux> :) [21:35] <ePirat> kawoom [21:35] <ePirat> I get "variable has incomplete type 'struct AVBPrint'" [21:37] <ePirat> and av_bprintf() does not seems to exist [21:37] <ubitux> ? [21:38] <ubitux> #include "libavutil/bprint.h" [21:38] <ePirat> oh& *derp* [21:45] <Timothy_Gu> ubitux, db0company: new fateserver: http://i.imgur.com/7zjjM9w.png [21:46] <ubitux> awesome yellow :)) [21:47] <Timothy_Gu> it really took me a while to find this new color... [21:48] <ubitux> "yellow"? [21:48] <Timothy_Gu> more: http://i.imgur.com/X1U9vfy.png http://i.imgur.com/iLNndy8.png [21:48] <Timothy_Gu> yeah. [21:48] <Timothy_Gu> I need to darken it enough to be fit with the new website, but not dark enough so that it isn't yellow anymore. [21:49] <ubitux> what about some orange? [21:49] <ubitux> probably less aggressive on a dark design [21:49] <Timothy_Gu> Mobile-on-desktop view: http://i.imgur.com/IIGX0UZ.png http://i.imgur.com/IvJRF4P.png [21:50] <Timothy_Gu> <ubitux> probably less aggressive on a dark design what do you mean? [21:50] <ubitux> this yellow is extremely violent [21:51] <ubitux> orange would be less aggressive for the eyes [21:51] <Timothy_Gu> ok. Can you try to find a color? It takes me 15 minutes to find one color... [21:51] <Timothy_Gu> Test bed is http://4aa17da1.ngrok.com/ [21:52] <ubitux> http://paletton.com [21:52] <ePirat> ubitux, uh I get a segfault now& dunno why& [21:53] <ubitux> Timothy_Gu: dunno, try #ffb700 maybe [21:54] <Timothy_Gu> http://i.imgur.com/QYpxBnE.png [21:54] <ubitux> sounds better [21:55] <ubitux> ePirat: can't guess what it is [21:58] <Timothy_Gu> ubitux: found #ffe010 [21:59] <ubitux> don't like #ffb700? [21:59] <Timothy_Gu> no [21:59] <Timothy_Gu> looks like cr* [21:59] <Timothy_Gu> http://i.imgur.com/piFh14i.png [21:59] <Timothy_Gu> ^ this is mine [22:00] Action: ubitux prefers orange [22:05] <michaelni> Timothy_Gu, do you have time/interrest to add branch support to fate.ffmpeg.org ? [22:08] <cone-621> ffmpeg.git 03Janne Grunau 07master:42eb9154a83e: fate: support testing of release branches [22:08] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:7f53f1136346: Merge commit '42eb9154a83e9a7aedb1168b2f1112af765cf2b5' [22:09] <michaelni> Timothy_Gu, that is the server side for the last commit [22:27] <Timothy_Gu> michaelni: not really, sorry [22:28] <michaelni> ok, anyone else ? (iam no perl developer so it should be alot less work for someone who knows perl a bit) [22:28] <Timothy_Gu> fateserver is supposed to be open source (ISC), but Libav doesn't even give a dang [22:29] <Timothy_Gu> by the way I didn't know perl either and I learned it as I fix fateserver ;) [22:31] <michaelni> mraulet, commit adcdabb4dd062694fb8de6df0faecaad1c36ba33 removes some fate tests, is that intended ? [22:33] <michaelni> Timothy_Gu, ill find someone to update it or ill do it myself, my todo list just is a bit long so if someone reading this knows perl, please ping me/reply [22:33] <mraulet> michaelni, yes [22:34] <wm4> in ffprobe, how do I disable a stream and then seek? [22:34] <mraulet> those tests have been removed from jctvc conformance test suite [22:34] <mraulet> and the other one have been added [22:34] <michaelni> mraulet, i understand but we want to support everything also older files [22:35] <michaelni> but i dont know if they maybe just excercise things that are already covered by others [22:37] <mraulet> when the numbering increases, it is supposed to be a new bitstream with same features [22:38] <mraulet> but anyway in the commit I forgot to delete golden references [22:40] <mraulet> we can keep both they are still passing [22:40] <mraulet> through the decoder [22:43] <michaelni> i suggest we keep both, but you know this stuff so ill do what you prefer [22:43] <michaelni> mraulet, if its keeping both i already have a diff for that locally [22:44] <mraulet> you can keep both [22:44] <BBB> whats the difference between avpriv_find_start_code and hevc_find_frame_end, conceptually? [22:44] <BBB> theyre both looking for 0x000001nn sequences, no? [22:45] <mraulet> I have yuv checking here and it is still correct [22:45] <mraulet> yes [22:45] <mraulet> oops BBB yes [22:45] <mraulet> too many thread at the same time :-) [22:45] <BBB> Im just backreviewing a decoder... [22:45] <BBB> so I randomly ramble [22:53] <cone-621> ffmpeg.git 03Mickaël Raulet 07master:449e3c8515a5: fate/hevc: update fate with 9 bitstreams - all of them testing HEVC version 1 [22:56] <ePirat-> ubitux, got everything to work, I will send in a new patch tomorrow, need to check things and do some cleanup. [23:09] <trn> Hello there. [23:09] <Timothy_Gu> trn: hi [23:10] <Timothy_Gu> michaelni, ubitux: do you guys think the texi patches are OK to be applied to FFmpeg tree? [23:10] <Timothy_Gu> michaelni: and also you didn't respond to my last email about the installation of makeinfo. [23:12] <trn> I'll make a long story short, I have a proposed patch/idea. [23:14] <cone-621> ffmpeg.git 03Carl Eugen Hoyos 07master:6898c14959d6: Fix standalone compilation of the legacy mpegvideo decoder. [23:15] <trn> Timothy_Gu: Original issue: pastebin.com/h35TPp5N - I fixed it by adding a new option that adds AVFMT_TS_DISCONT flag via the ffmpeg command-line. [23:15] <michaelni> Timothy_Gu, ill look into makeinfo install but noz sure when, might be a week or 2 before i do it, dont hesitate to ping me about it if i havt done it in a week [23:15] <trn> Timothy_Gu: A similar patch was added do the same for FLV, and my use comes up using NUT or FFM as an internal stream format. [23:16] <trn> I see Michael N added a similar patch for Live FLV via NGIN, situation in the same here, but unlikely to be seen in the wild. [23:16] <trn> Oh, Mr. N is here :) [23:16] <trn> michaelni: Awesome project BTW. [23:19] <michaelni> trn, patches should be submitted to the ffmpeg-devel mailing list, and if you have a bug report that should go to trac, but AVFMT_TS_DISCONT for nut sounds wrong without knowing excatly what the issue is about [23:20] <trn> michaelni: I'm abusing NUT essentially for something it isn't designed for. [23:21] <trn> Where a stream is constructed from 5 or 6 fragments, where each fragment will start with 0 DTS. [23:21] <trn> Other than resetting the DTS is otherwise monotonically increasing. [23:23] <trn> The fragments that produce the final streams are constructed on the fly by multiple machines and they don't have any knoweldge of other machines in the cluster, and the streams may or may not be infinite in length. [23:23] <trn> So I can't come up with any effective strategy to avoid having to reset DTS input. [23:24] <iive> save them in separate tracks? [23:24] <trn> Not possible as they aren't usually saved anywhere except being buffered. [23:25] <iive> sorry, I didn't understand what you are doing. [23:25] <BBB> can anyone explain me the mp4 and annexb format? Im sure this is documented somewhere but our code is so & undocumented& thats its just easier to ask [23:25] <BBB> so mp4 is extradata: sps+pps, and frame data is actual slice nals [23:26] <trn> live: Essentially an application that accepts input as multiple streams, presents an operator a way to edit the streams on a short time-delay to cut segments or switch between them, and then an output stream that is constructed after the operator... [23:26] <BBB> but isntead of having start codes, they have length field markers, which are 2 bytes (BE) for sps/pps extradata, and N-bytes (1-4) for the slice nals, where N is coded in the first data byte of the extradata, right? [23:26] <BBB> (first 2 bits infact) [23:26] <trn> Then users are connecting and based on device capabilities it decides watch formats and codecs to encode to to stream the output. [23:27] <trn> Real life: 15 input cameras -> human to switch them or beep bad-language -> output stream to TV and/or live streaming connecting clients [23:27] <BBB> so what I dont understand is, why does sps/pps have 3x0,1 as a startcode, instead of 2x0,1? [23:27] <iive> trn: you know that you can have multiple audio streams in a single file, each with different language (for example). you can also have multiple video streams. [23:28] <ubitux> Timothy_Gu: i don't know, i'm a bit overbooked currently [23:28] <Timothy_Gu> ok, no problem. [23:28] <cone-621> ffmpeg.git 03Carl Eugen Hoyos 07master:54326e0c5016: Fix standalone compilation of the legacy mpegvideo decoder. [23:28] <cone-621> ffmpeg.git 03Carl Eugen Hoyos 07master:bcb7220d1cf9: Fix standalone compilation of the webm_dash_manifest demuxer. [23:28] <trn> live: Well aware, we're actually using 4 video and 8 audio streams [23:29] <iive> e.g. like dvd angle. it makes much more sense to save the streams as separate tracks that interleave them into a single video stream. [23:29] <mraulet> BBB I dont think there is any rules on the number of zeros before a SPS and a PPS or whatever nalu type [23:29] <trn> iive: The problem is that the streams are all live input. [23:29] <mraulet> you can go into the HEVC spec for that [23:30] <mraulet> you dont need ISO base media file format aka mp4 [23:30] <iive> trn: why is that a problem? [23:30] <trn> iive: Because if the stream disconnects and reconnects, DTS is reset. [23:30] <ubitux> BBB: mp4 specs can be found @ http://standards.iso.org/ittf/PubliclyAvailableStandards/c061988_ISO_IEC_14… [23:30] <ubitux> (BBB: can't help you much more sorry) [23:30] <iive> aha, there are holes in reception.. [23:31] <trn> iive: Exactly. [23:31] <trn> Or there shouldn't be, but it isn't a perfect world. :) [23:31] <Timothy_Gu> does anyone know if you can distribute ISC-licensed software without a license? [23:32] <BBB> mraulet: so if you have 0x00 0x00 0x01, thats a valid start code right? [23:33] <BBB> and the 4th byte is the naltype I suppose? [23:33] <mraulet> yep [23:34] <BBB> ok got it [23:34] <mraulet> but you can have a number of infinte 0 before a start code [23:35] <mraulet> so the most important zeros are the last ones [23:35] <mraulet> to sync the decoders [23:37] <trn> iive: Funny too that using a 900kbps video stream with x264 high profile 4.1 for TV output hasn't caused a single complaint when using massaging the incoming stream with ffmpeg hqdn3d before compressing :) [23:38] <trn> Makes me wonder what Netflix is doing to look so bad. Sometimes they look worse than our 1Mb H.264 baseline 3.0 stream. [23:38] <mraulet> BBB: do you have a VP9 sample similar to those available here? ftp://ftp.kw.bbc.co.uk/hevc/hm-10.0-anchors/bitstreams/ [23:39] <trn> Anyway, I'll send my patch over to the mailing list. It's simple enough I don't mind keeping it local in case it isn't found appropriate. [23:39] <mraulet> by chance [23:39] <BBB> mraulet: theyre on the google server [23:39] <BBB> download libvpx and run ... [23:39] <BBB> (looking) [23:40] <iive> my test shows that using -nr 150 or 200 produces almost the same compression gain for far less cpu. and almost no visible loss. [23:40] <BBB> make testdata [23:40] <BBB> thatll download them all in your current directory [23:41] <trn> BBB: Do you know if there is any AVS or HVEC 4K/8K test streams available? [23:41] <BBB> mraulet: theres a few longer samples here: https://people.gnome.org/~rbultje/vp9/ [23:41] <BBB> 4k? not that I know, I went only up to 1080p in my tests [23:42] <BBB> 4k is easy to encode yourself if you have a sample [23:42] <BBB> but I dont think any are provided by google [23:42] <trn> BBB: I know I 4K sample at http://www.elecard.com/en/download/videos.html [23:42] <trn> I don't know any 8K. [23:42] <BBB> mraulet: ok just use the provided settings from my dir and encode your own 5-frame sample then (if thats enough) [23:43] <mraulet> 500 :-) [23:43] <trn> Since I'm working on a live editing system, I know sports people are going to be demanding 4K and more soon. [23:44] <BBB> uh... [23:44] <BBB> ok [23:44] <BBB> that might take you a day with my settings [23:44] <mraulet> 10sec video decoding just to compare with hevc [23:44] <BBB> use a higher speed=X setting [23:44] <BBB> or wait a day [23:44] <mraulet> ok [23:44] <BBB> or ask google to use their datacenter [23:44] <mraulet> i ll check with tos [23:44] <mraulet> there are hevc samples [23:45] <Timothy_Gu> trn: I know there are some 4K samples here: http://xhmikosr.1f0.de/samples/2160p/ [23:45] <trn> mraulet: HEVC samples at http://www.elecard.com/en/download/videos.html have 1920x1080 and a few 4K HEVC. [23:45] <trn> Timothy_Gu: Cool, thanks. [23:47] <cone-621> ffmpeg.git 03Lou Logan 07master:db0578a0e783: doc/decoders: mention native Opus decoder [23:50] <Timothy_Gu> BBB: do you think VP9 is better than HEVC? I know it's a pretty lame question, but just wanna know. [23:50] <BBB> I expect it to be competitive [23:50] <BBB> sometimes better, sometimes worse [23:50] <BBB> depends on the sample [23:51] <BBB> overall itll be about the same, I expect, but thatll depend a lot on the encoder more so than the format [23:51] <BBB> that is, if you get a great encoder that can encode quickly and still get most quality similar to the ref encoder (or better) [23:51] <BBB> than thatll win you any contest [23:53] <Timothy_Gu> OK. Another question is how can VP9 decoding _ever_ be faster than H.264 or VP8, like it does here at one thread: http://blogs.gnome.org/rbultje/files/2014/02/etv_decspeed.png [23:55] <mraulet> because he did a great job [23:55] <mraulet> :-) [23:55] <BBB> Timothy_Gu: how not [23:55] <BBB> Timothy_Gu: I do comparisons by _same quality_ [23:55] <wm4> and libvpx doing a terrible job... [23:56] <BBB> Timothy_Gu: thats a really important distinction [23:56] <BBB> wm4: its comapred to ffh264 and ffvp8, not libvpx [23:56] <Timothy_Gu> oh ok [23:56] <wm4> isn't the orange line libvpx? [23:56] <BBB> wm4: yes, but he meant compared to ffh264/vp8, not libvpx [23:56] <wm4> sure [23:56] <BBB> Timothy_Gu: ok, so a few basics in video profiling - esp. at high bitrate, most time is spent in coefficient decoding [23:56] <mraulet> in HEVC cabac is taking a lot of time [23:57] <wm4> sorry my statement was confusing [23:57] <BBB> Timothy_Gu: in hevc, thats cabac, in vp9, thats rac [23:57] <BBB> Timothy_Gu: those take an enormous amount of time and cannot really be efficiently parallelized (simd'ed) [23:57] <BBB> you can, in hardware, but not really on x86, imo [23:57] <Timothy_Gu> what does RAC stand for? [23:58] <BBB> Timothy_Gu: so, if you can, for same quality, reduce bitrate (=~ number of coefficients), then it means you only have half coefficients, and thus half time spent on coefficient decoding (relatively) [23:58] <BBB> RAC = something artichmetic coder [23:58] <BBB> I forgot what the r stands for [23:58] <mraulet> but if you remove twice the bitrate as it is the case for hevc then you are going faster [23:58] <BBB> range [23:58] <mraulet> seconding what BBB is saying [23:58] <BBB> Timothy_Gu: as mraulet says, basically [23:59] <BBB> mraulet: so, I can spent twice the time in more complicated prediction, idcts of higher resolution, etc. - but if most of my time is coefficient decoding and I slashed that by half, I still win [23:59] <BBB> oops [23:59] <BBB> Timothy_Gu: ^^ that was for you [23:59] <BBB> Timothy_Gu: thats why vp9 for same-quality beats vp8/h264 in decoding time (sometimes) [23:59] <Timothy_Gu> so vp9 is better than I thought [00:00] --- Mon Jul 28 2014

1 0

ffmpeg.log.20140727
by burek 28 Jul '14

28 Jul '14

[00:01] <FrEaKmAn_> I have no idea [00:28] <LanDi> anyone know how to record my mic on a skype conversation ? [03:39] <YaMoonSun> It's such a pain when even wording the question is a hard.. How do I make the perfect DVD rip? I've got a 1.3GB .mp4 that's flawless (seemingly) and a 3.4GB .mkv (exact copy) / Should I preserve the mpeg2/ac3, or go with x264/aac? I'm trying to save space without losing quality. [03:40] <sacarasc> How much time do you want to put into it? [03:40] <sacarasc> (Both learning and encoding.) [03:42] <YaMoonSun> I have unlimited of both [03:42] <YaMoonSun> Like seriously [03:43] <YaMoonSun> I had to duel-boot Mint to get a terminal so I could actually use ffmpeg - cmd was being a bitch [03:44] <sacarasc> Ah, because I was going to recommend mostly Windows tools. :D [03:44] <YaMoonSun> I'm on Windows 7 right now, but unless there's another version of cmd I can ingegrate I may have to swap over, cause I can't scroll up to read all of the command help [03:49] <sacarasc> The basics, though, ffmpeg -i input.mkv -c:a copy -c:v libx264 -crf 18 -preset:v veryslow output.mkv [03:49] Action: sacarasc is a little distracted at the moment, sorry. [03:50] <c_14> https://trac.ffmpeg.org/wiki/Encode/H.264 [03:50] <c_14> I'd personally keep the audio in AC3, but if you want AAC: https://trac.ffmpeg.org/wiki/Encode/AAC [03:51] <sacarasc> For a perfect rip, I'd not use ffmpeg. [03:51] <c_14> I think he has a rip and wants to make it smaller. [03:51] <c_14> If I read the question correctly. [03:51] <sacarasc> The latter one sounds like it was just a remux. [03:52] <c_14> Is a remux not a rip? [03:53] <sacarasc> I suppose so. [03:56] <YaMoonSun> Esstentially I want to copy the codecs from the .mkv and just reduce the bitrate to make a smaller file size (hopefully without fucking up the quality) [03:57] <klaxa> i suggest trial and error [03:57] <YaMoonSun> You've seen a YIFI rip? I want that quality/size from a DVD rip. His Spirited Away rip had like 4 lanaguges and it wasn't even 600mb [03:58] <klaxa> and reading stuff [03:58] <Hello71> lel yify [03:58] <Hello71> 1. you didn't spell it right. [03:58] <sacarasc> You say perfect, then say them... [03:58] <Hello71> 2. they encode audio at like aac 80 kb/s [03:58] <klaxa> i only heard bad things about yify so i avoid them [03:58] <Hello71> although spelling it like that is what I would expect [03:59] <Hello71> their rips aren't bad per se, just low quality [03:59] <klaxa> i guess doom9 and doom10 forums are the right places to look for information on dvd encoding [03:59] <Hello71> everyone on the public trackers is like v10 a10 [04:00] <sacarasc> And they're banned on most private trackers. \o/ [04:00] <sacarasc> I mean, I don't know. [04:01] <YaMoonSun> I mean, the .mp4 I produced, I was satisfied with at first. I just feel like I can reduce the video bitrate somehow without losing too much quality, and then swap the aac to ac3 and maybe save a tad bit more room even then. I heard it's better to encode using divx for DVDs as they use mpeg2, but I have no idea if I'll get the same quality as a x264 [04:02] <klaxa> x264 will give the best quality at the lowest filesize for now [04:03] <c_14> If you _really_ want the smallest file you can, (and you want mp4) encode the audio to AAC at the lowest bitrate you can stand and then try a 2-pass x264 and target the filesize you want. [04:04] <sacarasc> And use -preset:v veryslow or maybe placebo, to get the last bits of quality you can from it at the bit rate. [04:05] <c_14> And use recent versions of x264 and ffmpeg (preferably git head or the latest release). [04:05] <c_14> And libfdk_aac, but all that stuff should be on the wiki pages I linked before. [04:06] <sacarasc> You'd probably want to compile yourself to get libfdk_aac. [04:15] <YaMoonSun> Let's say I I'm open to more container options so long as I can keep the audio quality - The original is 224kbps ac3, and my .mp4 is 300+ kbps (nearly twice the size) [04:16] <c_14> Matroska can handle ac3 so you can copy the audio stream, that'll give you the identical audio quality as in the original file but will not compress it (more than it already is anyway). [04:16] <klaxa> try opus [04:16] Action: klaxa ducks [04:16] <c_14> Opus has admirable quality at low and very low bitrates. [04:18] <YaMoonSun> I have an .mkv of it too, but the video stream is ridiculous in it... Can I just take the .ac3 codec and use it to replace the .aac codec in the .mp4? [04:19] <klaxa> yes [04:19] <c_14> IIRC mp4 does not support AC3 audio. [04:19] <c_14> klaxa: Does mp4 support ac3? [04:19] <klaxa> uh... dunno [04:19] <YaMoonSun> Not much room saved, but a start. Then.. idk.. a mpeg2 being encoded into an mpeg2 to be put into the .mp4 should be smaller than the original presumably, right? [04:19] <klaxa> wikipedia says yes [04:20] <klaxa> wh-what? [04:20] <klaxa> you want to re-encode mpeg2 to mpeg2? [04:20] <klaxa> you're bound to lose quality [04:20] <klaxa> also h264 offers a lot more quality for less bitrate [04:21] <klaxa> mpeg2 is so 1996 [04:21] <YaMoonSun> You've tried this, or read this? I mean, I presume the encoding will take less time, and take up less space, but yeah, may be very well wrong. [04:22] <c_14> There is a reason that mpeg2 has been superseded as a codec. [04:22] <klaxa> if you don't give a damn about compatibility and only care about storage place and don't even want to watch the movie, try h265 [04:23] <c_14> H.264 is the current jack-of-all-trades allround decent codec. [04:23] <klaxa> s/place/space [04:23] <klaxa> it's late [04:25] <Hello71> ffmpeg -c:a libmp3lame -f wav mp3.wav [04:25] <klaxa> wat [04:25] <YaMoonSun> How do you predetermine the audio quality of a DVD without making an .mkv? Just open in VLC or something? [04:25] <Hello71> "predetermine the audio quality" [04:25] <Hello71> ??? [04:25] <klaxa> what do you mean? determine the audio quality? [04:25] <c_14> Open it in something that can print bitrates. (as much as a bitrate can tell you about audio quality notwithstanding) [04:26] <YaMoonSun> The kbps and Hz rate [04:26] <Hello71> Hz rate. [04:26] <YaMoonSun> inb4 -,- [04:26] <klaxa> you can use ffprobe for example [04:26] <Hello71> sure, if that's what you want to call it. [04:27] <YaMoonSun> Sexy, never heard of it - Looking into it now. [04:27] <klaxa> but depending on the encode, high bitrate and high sampling rate may not reflect what you want to know [04:28] <YaMoonSun> Give me an article as to why so you don't have to waste you time explaining it? Sounds like it would take more than a sentence. [04:28] <klaxa> because maybe the person encoding was incompetent [04:28] <klaxa> quality is a subjective measurement [04:28] <klaxa> listen to audio, watch a video [04:28] <c_14> subjectivity \o/ [04:29] <klaxa> that's how you determine quality [04:30] <YaMoonSun> I'm giving myself a headache. I had an arguement, but I foresaw your reply, and I'm already in checkmate, so yeah. If I reencode a ac3 to ac3 I will be losing more quality, no? So just use audio copy to get the exact version.. [04:31] <klaxa> basically every non-lossless encode will always lose quality [04:31] <klaxa> that's why they are called lossy [04:32] <klaxa> if you want to reduce the filesize re-encoding is fine, but be aware that you will lose quality [04:32] <klaxa> it may be so little that you can't tell the difference, then that's a good trade-off [04:33] <YaMoonSun> So if I rip a 320kbps 41kHz .mp3 from a .flac and then keep reencode it to .mp3 again, and make another .mp3 from it's copy, and continue that process, eventually I'll have nothing? [04:33] <klaxa> you will eventually have noise [04:34] <c_14> White noise iirc. [04:35] <YaMoonSun> Ac3 encoding vs ac3 passthrough? The passthrough is lossless? (As lossless as it's going to get) [04:36] <c_14> Passthrough should be not reencode but just copy. (but it might depend on the program and how they define things) [04:37] <YaMoonSun> Much appreciated; All of you. Even the sarcasm, lol - I'm going to go try a few things and I'll let you know the outcome. (Cause I'm sure you care ;) ) [04:37] <YaMoonSun> Ttyl, and thanks again. [05:30] <ac_slater> hey all. Looking through libavformat's sources for mpeg2ts, I cant figure out if it's possible to ADD an arbitrary stream as a separate stream with a different program ID (PID). [06:45] <onyx> Hey guys, Im running this cron job that records a live stream for 5 mins in the hours of 5am till 7pm [06:45] <onyx> * 5-19 * * * /usr/local/bin/ffmpeg -i http://serverip/live -acodec copy -vcodec copy -t 5:00 /destination-folder/ -$(date +\%d-\%H).mp4 > /dev/null 2>&1 [06:45] <onyx> is working great [06:45] <onyx> how do I go about creating thumbnails for those videos? [06:47] <sacarasc> Add something like (I will probably mess this up, so be prepared to work on it) this after the .mp4: -ss 2:30 -vframes 1 /destination-folder/ -$(date +\%d-\).png [06:48] <onyx> ok [06:55] <onyx> shouldnt be -ss 00:02:30.000 [06:55] <onyx> ? [06:55] <onyx> acording to this https://trac.ffmpeg.org/wiki/Create%20a%20thumbnail%20image%20every%20X%20s… [07:04] <sacarasc> Shouldn't your -t be similar, then? ;p [07:05] <onyx> idk [07:05] <onyx> LOL [07:05] <onyx> trying now... [07:07] <onyx> nope it didnt work [07:13] <onyx> Unable to find a suitable output format for 'vframes' [07:13] <onyx> vframes: Invalid argument [07:13] <onyx> omg... I forgot the "-" [07:13] <onyx> LOL [11:22] <FrEaKmAn_> wow.. when cutting the file, the parameters order is important [11:22] <FrEaKmAn_> can someone explain why? [11:35] <Mavrik> the parameter order is always important. [11:44] <FrEaKmAn_> didn't know [11:44] <FrEaKmAn_> because the different in my situation was that video/audio were out of sync [12:37] <jnvsor> Do x264 presets do anything if I'm specifying the bitrate manually and not using a crf? [12:37] <JEEB> yes [12:37] <JEEB> presets do not affect rate control [12:37] <JEEB> they just set the speed vs compression [12:38] <jnvsor> Allrighty, thanks! [15:04] <jeffreylevesque> i just installed ubuntu 14.04 (was using 11.04). ffmpeg is no longer available in apt-get. SHould i get a PPA, what's going on here [15:07] <JEEB> jeffreylevesque, debian/ubuntu switched to Libav, you can get a similar tool to current FFmpeg with avconv (since FFmpeg merged the command line changes it's similar in usage except for some FFmpeg-only features) [15:08] <JEEB> if that one doesn't work, you can either grab some static FFmpeg builds or compile it yourself [15:08] <jeffreylevesque> JEEB, are conversion times the same? S [15:10] <jeffreylevesque> sorry got disconnected [15:10] <JEEB> jeffreylevesque, yes [15:11] <JEEB> conversion times are mostly controlled by the encoder, and thus it's more dependant on libx264 than FFmpeg/Libav [15:11] <JEEB> as an example [15:11] <jeffreylevesque> JEEB, do you recommend ffmpeg, or avconv? [15:12] <JEEB> there shouldn't be a large difference unless something you need is only in FFmpeg [15:13] <JEEB> and given that you came from 11.04 I guess you don't at least right now have any needs regarding that [15:13] <JEEB> you'll have to get used to the new command line stuff that elenril made anyways, and that's in both [15:14] <JEEB> in case you happen to end up needing an ffmpeg binary, then you can always either grab one of the static builds, or build one yourself [15:14] <JEEB> (since f.ex. the best AAC encoder right now can't be distributed in binary form as it's not compatible with GPL, and some of the encoder libraries are GPL) [15:14] <jeffreylevesque> thank you [15:28] <khali> hi there [15:28] <sfan5> hello [15:30] <khali> ffprobe incorrectly reports MPEG Layer 2 audio streams as "mp3" [15:30] <khali> I think it used to be correct, I don't know when it broke exactly [15:31] <sfan5> I'd suggest reporting a bug at the bug tracker [15:33] <khali> sfan5: yes, I'll do that [15:42] <FrEaKmAn_> I'm trying to concat 2 files (http://pastie.org/private/tuonakgfbsteyqrwvh8rg) [15:42] <FrEaKmAn_> but the video is totallly distorted [15:42] <FrEaKmAn_> the only difference I see is video size [15:42] <FrEaKmAn_> could this be a problem? [15:43] <khali> FrEaKmAn_: definitely [15:43] <khali> you just can't concatenate videos with different frame sizes [15:43] <khali> you'll have to scale one of them first, using -vf scale [15:45] <FrEaKmAn_> ok [15:53] <FrEaKmAn_> khali: yup [15:53] <FrEaKmAn_> works now [15:54] <FrEaKmAn_> just when I concat the video, scale gets changed [15:58] <khali> FrEaKmAn_: in which way? [15:59] <FrEaKmAn_> it's squeezed [15:59] <FrEaKmAn_> I think one of my videos is strange [16:24] <khali> FrEaKmAn_: size is one thing, DAR is another [16:24] <khali> both must match [16:48] <FrEaKmAn_> I solved it [16:49] <FrEaKmAn_> but what is DAR? [17:01] <c_14> Display Aspect Ratio [17:11] <FrEaKmAn_> ow [17:12] <FrEaKmAn_> I'm using scale='if(gt(a,16/9),1280,-1)':'if(gt(a,16/9),-1,720)' [17:12] <FrEaKmAn_> as described here https://trac.ffmpeg.org/wiki/Scaling%20(resizing)%20with%20ffmpeg [17:12] <FrEaKmAn_> if I define 1280/720 it works [17:12] <FrEaKmAn_> but if I define 640/360 it doesnt [17:20] <FrEaKmAn_> ideas? [17:22] <c_14> Not really, you want to scale the video down to 640x360 while keeping aspect ratio so that you can concat, right? [17:23] <c_14> You might need to add a pad filter after that scale. [17:24] <FrEaKmAn_> c_14: yes [17:24] <FrEaKmAn_> and all videos need to have aspect ratio [17:27] <c_14> You said that it's not working. What 'it' exactly? The scaling or the concat after the scale? [17:28] <FrEaKmAn_> the video is gray [17:28] <c_14> The video resulting from the scale? [17:28] <FrEaKmAn_> with few color pixels [17:28] <FrEaKmAn_> concat [17:28] <c_14> ffprobe the video that was outputted from the scale [17:28] <c_14> The aspect ratio might be off [17:29] <FrEaKmAn_> one second [17:37] <FrEaKmAn_> c_14: sorry.. I guess I was concatenating wrong files [17:37] <FrEaKmAn_> seems to work now with 640x360 [17:37] <FrEaKmAn_> feeling excited until next problem [18:08] <FrEaKmAn_> well then I try to scale video with 1280x718 to 640x360 I get Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [18:08] <FrEaKmAn_> ideas? [18:08] <FrEaKmAn_> but to scale to 1280x720 it works great [18:09] <c_14> You're using x264? [18:09] <FrEaKmAn_> c_14: yes [18:10] <c_14> What could be happening is that the scale from 1280x718 to 640x360 is giving you an odd height, H.264 doesn't like that, but paste your command and output like sacarasc said and we can check. [18:10] <FrEaKmAn_> one second [18:12] <ersatzbeardr> hey is ffmpeg the right tool to place a series of pngs (with transparency) over various time signatures in a mpeg4 file, should i just produce blank frames for the ones i don't need or what [18:17] <FrEaKmAn_> c_14: http://pastie.org/9424883 [18:17] <FrEaKmAn_> it's true [libx264 @ 0x33b0120] height not divisible by 2 (640x359) [18:18] <maslen1> Could anyone point me to a sample MKV file that includes Cues ? [18:18] <FrEaKmAn_> must I use pad? to upscale video? [18:19] <c_14> You can either pad to make it even, or add a short round to your scale. [18:21] <c_14> scale="trunc(iw/2)*2:trunc(ih/2)*2" will make sure both height and width are even numbers [18:26] <FrEaKmAn_> c_14: but I want to scale it to 640x360 [18:26] <FrEaKmAn_> so I have to do 2 runs or can change my code scale="'if(gt(a,16/9),640,-1)':'if(gt(a,16/9),-1,360)'" [18:27] <c_14> You can replace iw with (if(gt(a,16/9),620,-1 and analog with ih [18:27] <c_14> Just set the parenthesis corretly. [18:28] <FrEaKmAn_> ok [18:28] <FrEaKmAn_> lets me try [18:36] <FrEaKmAn_> c_14: we are getting close [18:36] <FrEaKmAn_> http://pastie.org/9424911 [18:37] <FrEaKmAn_> but the output video has incorrect scale [18:37] <FrEaKmAn_> 640x718 [18:37] <FrEaKmAn_> 718 did not change [18:40] <c_14> ah, eh: trunc(-1/2)*2 = 0 [18:40] <c_14> ... [18:41] <FrEaKmAn_> yes [18:41] <c_14> New plan [18:42] <c_14> scale="'if(foobar):if(barfoo)'",scale='trunc(iw/2)*2:trunc(ih/2)*2" [18:42] <c_14> That should work. [18:42] <c_14> Hopefully. [18:42] <FrEaKmAn_> foobar? [18:42] <c_14> foobar is that whole if(gt(a,..... expression [18:43] <c_14> I didn't feel like typing it. [18:43] <FrEaKmAn_> ok [18:47] <FrEaKmAn_> c_14: it produces 640x358 [18:48] <FrEaKmAn_> I think I need to pad and then scale [18:48] <c_14> Either pad and then scale or scale and then pad. [18:48] <FrEaKmAn_> can I put pad in same command? [18:49] <c_14> ye [18:50] <FrEaKmAn_> I have this scale="'if(gt(a,16/9),640,-1)':'if(gt(a,16/9),-1,360)',scale='trunc(iw/2)*2':'trunc(ih/2)*2',pad=width=640:height=360:x=0:y=0:color=black" [18:50] <FrEaKmAn_> any good tricks to center the video? [18:51] <c_14> x=(ow-iw)/2:y=(oh-ih)/2 [18:52] <c_14> And if you're padding to an even height/width then you can get rid of the second scale. [18:52] <c_14> Since all that ensures is that it's even. [18:52] <FrEaKmAn_> ok [18:55] <FrEaKmAn_> seems ok [18:55] <FrEaKmAn_> ffprobe reports right scale [19:12] <onyx> so yesterday cron didnt work [19:13] <onyx> is there a command to create thumnails for all the files in the folder that dont have thumbnails? [19:13] <FrEaKmAn_> c_14: thanks for your help! [19:16] <c_14> np [19:16] <c_14> onyx: That looks like the job of a bash script and some scaling. [19:20] <Nitori> does "ffmpegsource" have anything to do with ffmpeg? [19:20] <ersatzbeardr> actually maybe i was going about this wrong, can i use ffmpeg to add an mpeg as an alpha to another mpeg then composit it with a third mpeg [19:20] <ersatzbeardr> i'm trying to get one video over another video with the alpha coming from somewhere else [19:24] <Nitori> (nevermind) [22:15] <sythe> "Failed to open bitstream filter aac_adtstoasc for stream 0 with codec copy: Not yet implemented in FFmpeg, patches welcome" [22:15] <sythe> :( [22:16] <sythe> Hmm [22:16] <sythe> I'll try combining the mp3 of the file with the video [22:34] <sythe> Hey rcombs [22:34] <sythe> I'm trying to append a video to another [22:35] <sythe> But it has an AAC audio track [22:35] <sythe> How can I remove the AAC track? (so I can replace it with an mp3 track) [22:36] <sfan5> try using -map [22:36] <sythe> sfan5: Can you elaborate? [22:37] <Hello71> the unixy way is to do -c:a none - | ffmpeg -i - -i input.mp3 [22:37] <sfan5> use -map to only use the inputs that are not the aac track [22:37] <sfan5> do you use -f concat? [22:37] <sythe> Yeah [22:38] <sfan5> what error message do you get? [22:39] <sythe> Scroll up [22:39] <sfan5> ah [22:39] <sythe> It combines it, but all the audio is gone [22:39] <sfan5> did you try first removing the aac track of the first video? [22:40] <sythe> The video doesn't have an AAC track [22:40] <sythe> The first one, that is [22:40] <sythe> The second one does [22:40] <sfan5> did you try first removing the aac track of the second video? [22:42] <sythe> I don't know how to do that [22:42] <sythe> " <sythe> How can I remove the AAC track? " [22:43] <sythe> sfan5: ^ [22:43] <relaxed> -map the streams you want in the output [22:43] <sfan5> ^ [22:44] <sfan5> e.g. if there are 3 streams (some video, some audio and aac) you want to do ffmpeg -i input.mp4 -map 0:0 -map 0:1 -c copy output.mp4 [22:44] <relaxed> sythe: https://trac.ffmpeg.org/wiki/How%20to%20use%20-map%20option [22:45] <trn> In case anyone cares, I was able to fix my problem, but it required a source patch. [22:46] <relaxed> how can that guide not include an example with multiple inputs :/ [22:46] <sfan5> developers usually don't like to document stuff [22:47] <trn> I added a -force-ts-discont command which adds AVFMT_TS_DISCONT to .flags in AVInputFormat. [22:47] <relaxed> reading the docs on the new website makes me want to claw my eyes out. [22:47] <sfan5> you probably want to send that patch to ffmpeg-dev [22:48] <trn> sfan5: It's sort of a hack, I'm not sure it's the appropriate solution, but it works in my case. [22:48] <trn> Also I switched from using NUT internal container format to pass streams around inside the application to using FFM2. [22:49] <sythe> relaxed: How do I list the streams of a file? [22:49] <sfan5> sythe: either ffmpeg -i file or ffprobe file [22:50] <sythe> thanks [22:50] <relaxed> sythe: read --> man ffmpeg-all | less +/' -map' [22:50] <llogan> relaxed: i would have preferred a white or at least a light background [22:50] <trn> sfan5: I just noticed this on the mailing list... http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-June/158513.html [22:51] <trn> sfan5: It essentially does the exact same thing in the exact same scenario as what I did, except I added a flag to turn the flag on for whatever format. [22:52] <sythe> I don't see the AAC stream listed [22:52] <trn> Because technically that "live_flv" is just an abuse of flv just like my use of FFM/NUT transport in segments is sort of an abuse as well. [22:52] <sfan5> maybe it's in the other file? [22:52] <trn> But it doesn't make sense to create a totally new transport container format just for my application. [22:53] <trn> sfan5: You think I should still send it? [22:53] <relaxed> llogan: What was the motivation for the change? I thought the old style was fine. [22:54] <llogan> i don't know. i guess people thought it was too 2004. [22:55] <sfan5> trn: I don't think it's needed if there is already a patch that does it differently [22:55] <sythe> Hey [22:55] <sythe> How do I concatenate and mix two files? [22:55] <trn> sfan5: That patch only does it for FLV, but I need it for NUT and/or FFM. [22:55] <sythe> When I add a video file to another [22:55] <sythe> Both with MP3 streams [22:56] <trn> sythe: concat filter, etc. [22:56] <sythe> And both h.264 mp4s [22:56] <sythe> The audio is lost [22:56] <sythe> Well, it appears in the stream list [22:56] <sythe> But it's not there [22:56] <sfan5> trn: in that case it would make sense to send it [22:56] <llogan> sythe: show "ffmpeg -i input0 -i input1 -i input2" etc if you're using concat demuxer and also... [22:57] <sythe> ffmpeg -i "concat:intermediate1.ts|intermediate2.ts" -c copy -bsf:a aac_adtstoasc episode4-upload.mp4 [22:57] <llogan> use the demuxer [22:57] <sythe> IDK what that is [22:57] <trn> OK, will do when I get to work on Monday. [22:57] <sfan5> sythe: https://trac.ffmpeg.org/wiki/How%20to%20concatenate%20(join,%20merge)%20med… [22:57] <llogan> https://trac.ffmpeg.org/wiki/How%20to%20concatenate%20%28join,%20merge%29%2… [22:58] <sythe> llogan: Extract the audio? [22:59] <llogan> ffmpeg -i input -c:a copy ouput [23:01] <sythe> I'll use that script [23:01] <sythe> Looks good [23:02] <llogan> i don't know what you're trying to do [23:03] <sythe> Add another video file (with audio) to the end of one [23:05] <trn> Also do you think the mailing list would want patches to work with older versions of some optional libraries? [23:06] <trn> They aren't as clean but I can patch autoconf stuff for it if it's needed. [23:06] <trn> Mainly because RHEL provides older versions with backported security and bug fixes and I wanted ffmpeg to work with the system libraries where it wasn't actually using functionality provided by the newer libraries. [23:07] <sfan5> just send the patches and you'll notice soon enough if nobody wants/needs them [23:07] <trn> OK, I don't want to be a PITA or nothing. [23:09] <sfan5> asking in the -devel channel might also be an option [23:09] <trn> Ah, will do. [23:09] <trn> Thanks. :) [23:28] <sythe> Ok, the script you guys linked... [23:28] <sythe> Is taking AGES [23:29] <sythe> Also, does FFMPEG do lossless conversion? [23:29] <sythe> Since I saw something about FPS [23:29] <sythe> And I don't want FFMPEG downscaling the FPS to 15 [23:40] <llogan> sythe: the concat demuxer will " Add another video file (with audio) to the end of one". [23:40] <llogan> ffmpeg supports several lossless encoders [23:42] <sythe> llogan: I didn't see anything about that on that link [23:44] <sythe> llogan: Ok [23:44] <sythe> Nvm [23:44] <sythe> I see [23:44] <sythe> I'll try it [23:55] <sythe> llogan: It worked-ish [23:55] <sythe> all the audio is there [23:55] <sythe> The second video is just a gray screen [23:56] <c_14> The 2 videos have to have the same codec. [23:57] <sythe> Video: h264 (Constrained Baseline) and Video: h264 ([33][0][0][0] / 0x0021) [23:57] <sythe> are those not the same, c_14 ? [23:59] <c_14> I'm not versed in the hex representation of h264 profiles, but they look different to me. [00:00] --- Mon Jul 28 2014

1 0

ffmpeg-devel.log.20140726
by burek 27 Jul '14

27 Jul '14

[00:00] <mraulet> correct extensions here https://dl.dropboxusercontent.com/u/588600/hevc_bitstreams.zip [00:04] <mraulet> some x86 12bits assembly commits 3fcb7a4595a6f40100a22110a5805e3b7510c0fd 97d46afe320c7d61d7b9525e5f5588355cde4bb0 a3f7282eaa6f1ab0524fb966c6eade50c3025f99 [00:09] <mraulet> michaelni: if we have in fate reference a bitstream with a wrong reference we can correct it? [00:09] <mraulet> ie https://github.com/OpenHEVC/FFmpeg/commit/903236292f066bc321080e3e2192b64f8… [00:15] <michaelni> mraulet, if the bitstream was used by a previous ffmpeg make fate, we can very likely not fix it [00:15] <michaelni> it would break bisecting with make fate [00:15] <mraulet> so this bitstream has another version number [00:16] <mraulet> we can use another version number and use it into hevc.mak and remove the old one [00:16] <mraulet> ? [00:17] <michaelni> we can add files to the rsync server and we can stop using files from the server in make fate, yes but we cant remove files from the server unless they where never used [00:18] <mraulet> ok [00:18] <michaelni> should i upload the files from the zip ? [00:18] Action: michaelni just double checking [00:19] <mraulet> yes [00:19] <mraulet> I will add one more [00:22] <mraulet> https://dl.dropboxusercontent.com/u/588600/RAP_B_Bossen_2.bit it has the same md5 hash than RAP_B_Bossen_1.bit [00:23] <mraulet> I will fix the commit tommorrow once bitstreams are uploaded on fate [00:24] <michaelni> if it has the same hash why should it be uploaded ? [00:24] <BBB> I think he means the output of ffmpeg was wrong [00:25] <mraulet> exactly [00:25] <mraulet> jctvc (MPEG/ITU) provided wrong key before [00:26] <mraulet> this commit fixes it according to the hash provided by the experts [00:26] <mraulet> https://github.com/OpenHEVC/FFmpeg/commit/903236292f066bc321080e3e2192b64f8… [00:27] <mraulet> *according to the new hash [00:29] <michaelni> if the ffmpeg output was wrong, there should be no need to reupload the same file [00:32] <mraulet> ok [00:32] <mraulet> so then the commit is ok [00:44] <michaelni> bitstreams uploaded [00:52] <mraulet> got them thanks [01:16] <cone-217> ffmpeg.git 03Michael Niedermayer 07master:a06fac353ce2: avformat/mux: ignore delayed vp8/9 packets in max_interleave_delta calculation [01:55] <cone-217> ffmpeg.git 03Mickaël Raulet 07master:7bdcf5c934f0: x86/hevc: add 12bits support for deblocking filter [01:55] <cone-217> ffmpeg.git 03Mickaël Raulet 07master:7df98d8c4d97: x86/hevc: remove unused constant in deblocking filter [02:00] <cone-217> ffmpeg.git 03Mickaël Raulet 07master:bd0f2d316fae: x86/hevc: add 12bits support for MC [02:10] <llogan> are there any significant differences between using native nut and libnut for demuxing and/or muxing? [02:16] <cone-217> ffmpeg.git 03Mickaël Raulet 07master:f6e218a02d6f: hevc: fix RAP_B_Bossen [02:34] <cone-217> ffmpeg.git 03Diego Biurrun 07master:ff85334375c6: mpegvideo: Drop unused MPEG_BUF_SIZE and CHROMA_444 defines [02:34] <cone-217> ffmpeg.git 03Michael Niedermayer 07master:0a9bab5be64f: Merge commit 'ff85334375c6733c6116ea3686f128b4a11f33e7' [02:37] <Timothy_Gu> llogan: yes. libnut is broken, nut is working. [02:45] <cone-217> ffmpeg.git 03Diego Biurrun 07master:4fbb62a21bd0: mpegvideo: Move ME_MAP_* defines to the only place they are used [02:45] <cone-217> ffmpeg.git 03Michael Niedermayer 07master:8b395315a5e7: Merge commit '4fbb62a21bd04bf261da2382d5ba6c249c702af8' [02:54] <cone-217> ffmpeg.git 03Diego Biurrun 07master:d8520d3ee032: mpegvideo: Move QMAT_SHIFT* defines to the only place they are used [02:54] <cone-217> ffmpeg.git 03Michael Niedermayer 07master:7295ee7f51d9: Merge commit 'd8520d3ee032bf18f28897e0109f44b405caf5e3' [03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:0f09436a4329: avfilter/vf_pullup: use ptrdiff_t as stride argument for dsp functions [03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:97ccf31ecebc: avfilter/x86/vf_pullup: fix old typo [03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:31b1589097cd: avcodec/hevc: Use av_malloc(z)_array() [03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:969d8b9d60c1: avformat/utils: do not wait for packets from discarded streams for genpts [03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:ab6dd7fea97f: avformat: add av_stream_get_parser() to access avformat AVParser [03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:27375c25d9c8: ffmpeg: Use av_stream_get_parser() to avoid ABI issues [03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:5302fa522bcf: avcodec/hevc_ps: do not loose all reference to pointers still in use [03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:0bb71a85c398: avcodec/hevc_ps: prevent stale pointer in malloc failure case [03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:b7638af9425a: avcodec/hevc: treat current_sps like sps_list [03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:eb1e5cf818b9: avformat/dv: implement fallback in dv_extract_pack() [03:21] <cone-217> ffmpeg.git 03Alessandro Ghedini 07release/2.1:aa09543659d8: vc1: Do not return an error when skipping b frames [12:29] <cone-621> ffmpeg.git 03Christophe Gisquet 07master:036f11bdb565: x86: hevc_mc: replace simple leas by adds [12:39] <mraulet> michaelni: support for bumping process f1e1ab74f6295d2ac3add2d19075c29739bc2945 [12:40] <mraulet> michaelni: fate for bumping process (new bitstream from yersterday) d4d61a071f087db2a4bc2b49559d40dd350a841e [12:40] <mraulet> michaelni: fate for new bitstreams commits adcdabb4dd062694fb8de6df0faecaad1c36ba33 3b69a2dc469160ee87367191e630e8398e832227 [13:01] <cone-621> ffmpeg.git 03Lukasz Marek 07master:9a6ca20ef675: configure: replace pulse-simple with pulse [13:04] <ubitux> > So that [13:04] <ubitux> "-mno-red-zone" is not some "optional guideline". It's a hard and [13:04] <ubitux> harsh requirement for the kernel, and gcc-4.9 is a buggy piece of shit [13:04] <ubitux> for ignoring it. [13:04] <ubitux> https://lkml.org/lkml/2014/7/24/584 [13:06] <ubitux> speaking of this gcc-4.9.1 is broken on my box as jamrial pointed out :( [13:14] <J_Darnley> I've just been reading that too. [13:22] <iive> it is always entertaining to read Linus [13:32] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:c0a586d9d5cd: reintroduce avpriv_dsputil_init() to maintain ABI until next soname bump [13:43] <wm4> ubitux: older versions are also affected, they just don't trigger in this specific case [13:43] <wm4> older than 4.9, AFAIK [13:43] <JEEB> "The bad compiler versions are 4.5.0 (when debug_insn came in) to 4.8.3 and 4.9.0 and 4.9.1." [13:44] <ubitux> wm4: do you know what bug it is? [13:44] <wm4> gcc really should focus a little on correctness [13:44] <ubitux> i'm not sure it's actually related to what's mentioned in the lkml mail [13:44] <wm4> ubitux: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904 [13:45] <ubitux> right, but how do you know the aac failure is related to this? [13:45] <wm4> what aac failure [13:45] <ubitux> ah, seems it's now fixed for some random reason [13:46] <wm4> the red zone bug is a kernel-only issue [13:46] <wm4> probably [13:46] <ubitux> wm4: i was refering to all my fate instances being yellow after the upgrade from 4.9.0 to 4.9.1 because of a failing aac test [13:46] <ubitux> but they disappeared [13:47] <ubitux> seems it was unrelated [14:38] <BBB> so for hevc/h264, that startcode escaping, thats just to prevent 0x00000[012] sequences in the actual bitstream right? is that always done, even in already-packetized streams (rtp, mp4, etc.)? [14:43] <kierank> iirc it is still done in mp4 etc [14:47] <mraulet> BBB: always done [14:47] <BBB> why [14:49] <mraulet> you are speaking about AEB? or start_codes only? [14:49] <mraulet> Anti Emulation Bytes [14:50] <BBB> ABE is the escaping right? [14:50] <BBB> 0x00000[0123] becomes 0x0000030[0123] [14:50] <mraulet> you need to remove AEB before decoding the bitstream [14:50] <mraulet> in all formats [14:50] <mraulet> yes at the encoder side [14:51] <BBB> so theres no format where the length is coded directly in the bitstream? [14:51] <mraulet> it is with AEB [14:51] <mraulet> in mp4 [14:51] <BBB> right, so thats my question [14:52] <BBB> why, in mp4, if the length is known, do we need AEB [14:52] <BBB> is it just because thats what people do? or is there some real reason why you want to escape startcode-like sequences in the bitstream because otherwise something would go wrong? [14:53] <BBB> it seems to me you dont need startcodes (and likely dont have startcodes) in mp4, since you already know the length, no? [14:53] <BBB> (Im not asking implementation; Im asking spec, design here) [14:54] <kierank> probably for hrd purposes [14:54] <kierank> so that the vbv doesn't change when moving from one to another [14:54] <kierank> (then again it breaks with 3-byte startcodes and sps/pps) [14:56] <BBB> Im going to have to question the sanity of this committee of old gray men that designed this spec [14:57] <JEEB> mp4-sys is mostly controlled by le apple [14:58] <mraulet> mr mp4 dave singer [14:58] <JEEB> yup [14:59] <mraulet> you can also ask Jean Le Feuvre from TelecomParis Tech [14:59] <kierank> they'll tell you to look at gpac :) [14:59] <kierank> since gpac is the reference to mp4 =p [14:59] <Paranoialmaniac> lulz [15:00] <kierank> Paranoialmaniac: are you going to vdd? [15:00] <mraulet> Paranoialmaniac: you might have the answer for BBB [15:01] <Paranoialmaniac> kierank: i haven't decided yet [15:07] <mraulet> looking at the standard, it is to be agnostic from any containers [15:07] <Paranoialmaniac> i think kierank's thought is reasonalble about AEB. 14496-15 even cares about hrd for filler data [15:09] <mraulet> it is also forbidden in H.264 and HEVC to have startcodes inside a RBSP [15:11] <Paranoialmaniac> well, it seems the spec of editors is confused about rbsp and ebps :P [15:11] <Paranoialmaniac> NALUnitLength indicates the size of a NAL unit measured in bytes. The length field includes the size of both the one byte NAL header and the RBSP payload but does not include the length field itself [15:11] <Paranoialmaniac> . NALUnit contains a single NAL unit. The syntax of a NAL unit is defined in the appropriate specification (e.g. ISO/IEC 1449610) and includes both the one byte NAL header and the variable length encapsulated byte stream payload. [15:13] <Paranoialmaniac> you see the spec has a contradiction of the definition of NALUSample [15:18] <BBB> it seems to me that the spec authors went out of their way to make .h264 output data (non-containerized) a well-supported use case, and they forgot that in the real world, nobody gives a fuck [15:19] <BBB> and it just adds complexity [15:25] <JEEB> there's a whole shitload of stuff in mpeg-4 systems that nobody but academics/GPAC has ever used [15:25] <JEEB> I'm just thankful they're not thinking of doing similar shit with anything else yet [15:51] <cone-621> ffmpeg.git 03Mickaël Raulet 07master:23480da0aa70: hevc: add support for bumping process [15:59] <BBB> bump? [15:59] <BBB> odd name [15:59] Action: BBB goes take kids out [18:29] <cone-621> ffmpeg.git 03James Almer 07master:1ace9573dce5: x86/hevc_idct: replace old and unused idct functions [18:41] <smarter> BBB: I think it's just to make transcoding easier [19:05] <ubitux> michaelni: the scope of "AVDSP" is not well defined [19:06] <ubitux> as BBB says it will end up being filled with a bunch of stuff [19:06] <ubitux> you probably want to split them, and actually move them to avutil [19:07] <ubitux> (to avoid some lavc dep in lavfi notably) [19:11] <michaelni> ubitux, you suggest that we move all idcts, dcts and other related functions to libavutil ? [19:11] <ubitux> maybe [19:11] <ubitux> i'm actually planing to add an fdct/idct in dctdnoiz [19:11] <ubitux> but well [19:12] <michaelni> ubitux, do you volunteer to do this ? [19:12] <ubitux> but appart from fdct/idct that could stay in lavc, i think a few optimized utils could end up in lavu [19:12] <ubitux> typically the sad or avg or stuff like that [19:12] <ubitux> because they can be used a lot in filters as well [19:12] <ubitux> but if you do that, it should be split from the fdct/idct anyway [19:13] <ubitux> to me, it's different utils [19:13] <ubitux> and it needs to be split [19:13] <ubitux> not a whole "AVDSP" with all kind of ± shared shit [19:13] <michaelni> you put alot of work on my sholders you realize this ? [19:13] <ubitux> i'm really sorry :) [19:14] <ubitux> but the point is too keep lightweight dep [19:15] <michaelni> ubitux, if you want this, you should do it [19:15] <michaelni> we can disable the filters that need it when shared libs are enabled [19:16] <ubitux> well, i don't want to do that right now, but if you need to push a fix soon, at least don't make it public [19:16] <ubitux> so it can be fixed later without too much trouble [19:16] <michaelni> ubitux, this is prerequesite for debian packages [19:16] <michaelni> its not a we can do it in a month thing [19:17] <michaelni> its needed now [19:17] <michaelni> so its either a volunteer doing that split, or we have to disable the filters [19:17] <ubitux> ok, let me grasp the issue you're trying to really fix [19:17] <michaelni> ABI [19:18] <michaelni> filters need the dsp code, other packages like mplayer need it too [19:18] <michaelni> it must be public [19:18] <michaelni> and its ABI/API must be stable [19:19] <michaelni> iam happy with any solution but it cant just be left as is [19:19] <ubitux> what's get_pixels()? [19:22] <michaelni> 8x8 8bit ->16bit [19:22] <ubitux> what's the usage? [19:22] <ubitux> pre-dct? [19:22] <michaelni> yes [19:23] <michaelni> one can argue it and diff_pixels belong to fdct [19:23] <ubitux> why diff_pixels? [19:23] <ubitux> ah because of only residual being coded? [19:24] <ubitux> then i'd have a lavc AVDCT with get_pixels/idct/fdct, and lavu AVDSPUtils with diff_pixels and sad [19:25] <ubitux> (and eventually diff_pixels being instanciated in AVDCT) [19:25] <ubitux> diff_pixels and sad should be in lavu because they're useful in a bunch of filters [19:25] <ubitux> and it's "generic" [19:26] <ubitux> about ME i don't know [19:26] <ubitux> it seems there is only sum_abs_dctelem to put somewhere, but with the "dctelem" it doesn't sound like it would belong to AVDSPUtils in lavu [19:26] <ubitux> unless it's actually a generic func and could be renamed to sub_abs_16 or something [19:27] <michaelni> make it int16 [19:27] <michaelni> instead of dctelem [19:27] <michaelni> its not as if the asm would work if it was somethning else [19:28] <ubitux> ah, sad is actually this [19:28] <ubitux> ah, no [19:29] <ubitux> michaelni: ok so i guess you want me to rush an API somehow with this? [19:29] <michaelni> "rush" is the wrong word IMHO [19:30] <michaelni> we just need these functions available and that need isnt new [19:32] <michaelni> i am not against spliting it between libavutil (for common usefull functions) and libavcodec for more codec specific ones [19:33] <ubitux> ok so, what about we start by creating a AVPixelsUtils with a scope being defined as "Generic simple pixels utils for usage in codecs and filters", with sad, diff_pixels, (get_pixels ?), and sub_abs_int16? [19:34] <ubitux> and we take this opportunity to remove the lavc dep completely for a bunch of filters doing this [19:35] <ubitux> then there is fdct/idct, which would actually be move in a lavc "AVDCT" context [19:35] <ubitux> i'm not sure where the ME remaining bits would stand [19:36] <michaelni> ubitux, so you suggest i should rename AVDSP -> AVDCT and drop non dct stuff ? [19:36] <ubitux> yes [19:36] <michaelni> AVDCT8x8 rather [19:36] <michaelni> because its just 8x8 [19:36] <ubitux> i don't know exactly [19:36] <ubitux> not sure how useful a "DCT" context could be [19:37] <ubitux> like, we have all kind of possible DCT algorithm with different types, speed and numerical stabilities [19:37] <michaelni> AVPixelsUtils sad is used by ac3enc [19:37] <ubitux> it doesn't matter it's in lavu [19:37] <ubitux> lavu is basically accessible from everywhere [19:38] <ubitux> what do you want AVDCT to become? [19:38] <ubitux> only a very specific 8x8 DCT? [19:39] <ubitux> i mean, i'm actually looking at a 16x16 DCT for dctdnoiz [19:39] <ubitux> it could belong here too [19:39] <michaelni> my plan was to introduce AVDSP and add to it what we need from external applications and libavfilter [19:39] <michaelni> but you and BBB dont like that [19:39] <michaelni> so its MUCH more complex [19:39] <ubitux> i'm afraid of having a context with everything into it [19:40] <ubitux> we just need to define the scope properly [19:40] <michaelni> its harder for us and its harder for our users [19:40] <michaelni> iam ok with it but i dont want to have to do the work [19:40] <ubitux> i'll try to do something tonight [19:40] <ubitux> but i want to define first what we want [19:41] <michaelni> sure [19:41] <michaelni> but thats not so easy [19:41] <ubitux> i'm unsure about the DCT/iDCT currently [19:41] <michaelni> one can go as generic or specific with that as one wants [19:42] <ubitux> i plan to write a very specific doxy above the struct [19:42] <ubitux> so it doesn't evolve randomly [19:42] <ubitux> anyway [19:42] <ubitux> should i start with the sad & friends first? [19:43] <michaelni> whatever you like [19:43] <ubitux> ok [19:43] <michaelni> just tell me if i should rename AVDSP remove non *dct and resubmit ? [19:44] <michaelni> but can wait too i have other ffmpeg work iam working on atm [19:44] <ubitux> mmh so rename to what? [19:44] <ubitux> it's only the JPEG DCT? [19:44] <michaelni> yes [19:44] <ubitux> well then... AVJPEGDCT? :p [19:44] <michaelni> i really thin thats a bad name [19:45] <ubitux> why? [19:45] <michaelni> dct("jpeg") or dct(8,8) ? [19:45] <ubitux> isn't jpeg dct implicitely 8x8? [19:46] <ubitux> i'm fine with AVDCT8x8 ofc [19:46] <michaelni> it is but but why add indirection in the name [19:46] <ubitux> because all other codecs have a different DCT for 8x8? [19:46] <michaelni> no [19:46] <ubitux> or do you plan to move the VP9 DCT into that context as well? [19:48] <michaelni> i dont plan to, and i dont see the need to, but then i also dont see a reason why not if that would be what user apps want [19:48] <michaelni> for example if its faster and can be used as substitute in some algo [19:49] <ubitux> btw, do you plan to move the few (jpeg) float DCT 8x8 into it? [19:50] <michaelni> all 8x8 dcts and idcts from the current contexts are available through AVDSP and would stay available in AVDCT* [19:50] <michaelni> most user apps would want the fastest no matter which simd implementation or permutation type [19:52] <BBB> michaelni: this isnt novel [19:52] <BBB> michaelni: see e.g. AVFFT [19:52] <BBB> thats a well-defined, very limited-scope public api [19:52] <BBB> in fact, its not even direct function wrappers, its an api on top of that so you call functions, not function pointers [19:53] <BBB> michaelni: why dont you try to model it after that, but call it AVDCT [19:53] <ubitux> we mostly agreed on AVDCT [19:53] <ubitux> i wasn't sure if it was too generic or should be more specific [19:53] <ubitux> but i guess that's fine [19:53] <BBB> Im not sure I like the idea of function pointers in a public API& AVFFT is not like that [19:54] <BBB> well& its a DCT [19:54] <ubitux> BBB: what about the permutations? [19:54] <michaelni> what about SIMD [19:54] <BBB> AVFFT has simd [19:54] <BBB> check how it does it [19:54] <BBB> Im not against function pointers btw, just pointing out differences [19:55] <BBB> if you feel function pointers is fine, Im moderately ok with that [19:55] <BBB> as for permutations, as longas its self-contained, its fine in the struct [19:56] <michaelni> i dont mind which way its done, i just dont want to do this redesign because i dont "belive" in it improving anything [19:56] <BBB> ubitux: so this is a model DCT, right? its a relatively high-precision dct with no specific application to any particular codec (like DHT/DWT/vp9-DCT/vp8-DCT/hevc-DCT, which are all bitexactly defined and basically slight variations on the model DCT) [19:56] <ubitux> so i'm fine with lavc (with permutations it doesn't belong in lavu) AVDCT with only the DCT stuff [19:57] <ubitux> but the permutations are very JPEG/MPEG specific, and the context will stays like this [19:57] <iive> mpeg-DCT sounds like reasonable variant. [19:57] <ubitux> PEGDCT [19:57] <ubitux> alias PeggyDCT [19:58] <ubitux> BBB: "this"? you mean the dct in the current patch? [19:58] <ubitux> it looks like very JPEG specific with ± accurate integer op [19:59] <ubitux> michaelni: why would you export the FF_API* stuff into it? [19:59] <ubitux> why are the arch optim as option? [19:59] <BBB> its a whole collection of DCTs right? [19:59] <BBB> its not a bitexactly defined DCT [19:59] <michaelni> whole collection, yes [19:59] <BBB> just some relatively high-precision variants that are approximately identical and optimized per-arch (with slight rounding differences) [20:00] <BBB> or even precision differences, whatever works best for that arch [20:00] <ubitux> i don't understand the need for the "mmx" and similar options [20:00] <michaelni> the filters that use it like spp are very dependent on its speed so tehy need the fastest [20:00] <BBB> its not bitexact to the C one [20:00] <BBB> so you can specify that you want the fastest, or the best, or (for testing) a specific one (e.g. MMX) [20:00] <BBB> same like we do -cpuflags for testing of all optimizations [20:00] <ubitux> yeah but it needs another name then no? [20:01] <ubitux> like what happens if i pick "simplearmv5te" on my intel? [20:01] <michaelni> yes, the *dct_algo is quite finegrained [20:01] <BBB> same thing as when you happen to use -cpuflags mmx on arm [20:01] <BBB> nothing good ;) [20:01] <ubitux> it should be something like "fast", "simple", "accurate" or whatever [20:01] <ubitux> the cpu flags are at another level [20:01] <ubitux> we have an api for that [20:01] <BBB> we didnt have that back then [20:02] <BBB> I agree its kind of weird [20:02] <ubitux> right, but i'm looking at the patch introducing this [20:02] <BBB> and then theres xvid, etc. routines [20:02] <ubitux> in a brand new exported public api [20:02] <BBB> which are optimized to match the fdct in the encoder [20:02] <ubitux> so i'm a bit uncomfortable [20:02] <BBB> do we need that at all? [20:02] <BBB> why not hide that inside lavc [20:02] <BBB> and export it without that [20:02] <ubitux> yes please :) [20:03] <BBB> I mean were not using this as a xvid filter [20:03] <BBB> its a denoise filter etc. [20:03] <BBB> they will never use this stuff [20:03] <ubitux> btw [20:03] <ubitux> BBB: 19:33:46 <@ubitux> ok so, what about we start by creating a AVPixelsUtils with a scope being defined as "Generic simple pixels utils for usage in codecs and filters", with sad, diff_pixels, (get_pixels ?), and sub_abs_int16? [20:03] <ubitux> do you mind this? [20:03] <BBB> (unless the user is pressing buttons he shouldnt press) [20:03] <BBB> as long as its not exported, sure [20:03] <ubitux> ?? [20:03] <BBB> if its exported, Ill frown a little [20:03] <ubitux> it will [20:03] <BBB> hm... [20:03] <ubitux> in lavu [20:03] <BBB> I guess its ok [20:03] <ubitux> for lavc and lavfi [20:04] <BBB> make sure its disabled in decoder-only builds [20:04] <BBB> then its fine [20:04] <ubitux> it's "pixels utils", so not codec specific [20:04] <ubitux> just a bunch of useful diff/sum stuff [20:04] <BBB> right but you dont want that in chrome [20:04] <BBB> (in fact, that returns us to lets make lavu pieces build-configurable) [20:04] <ubitux> not already the case? [20:05] <BBB> yes, but lets not make it worse [20:05] <BBB> I spent some time making dsputil not needed for chrome [20:05] <BBB> it was a big thing, like, really big [20:05] <ubitux> the context could return NULL when not available [20:05] <BBB> it saved several 100kb on a 20-mb package [20:06] <BBB> so do we _need_ this in lavu? [20:06] <ubitux> diff pixels are typically very useful in filters [20:06] <BBB> I dont mind lavfi depending on such tools in lavc [20:06] <ubitux> same for sad [20:06] <ubitux> yeah but it's not very codec specific [20:07] <BBB> I suppose... [20:07] <BBB> I cant think of anything better, so sure, feel free to put it in lavu [20:07] <ubitux> BUT [20:07] <ubitux> :) [20:07] <ubitux> in lavfi we could probably process them as line [20:07] <ubitux> or something [20:07] <BBB> depends how you use the results [20:07] <BBB> if you use the results for a dct, you want it block-based [20:08] <BBB> if you dont, then & sure [20:08] <ubitux> sad, pix_abs and stuff are currently in ME code [20:08] <ubitux> i think it really belongs in a pixel utils context [20:08] <BBB> well the most typical use case for sad is ME, yes [20:09] <BBB> the set of tools are basically RD and ME tools [20:09] <ubitux> it's used in select (for scene detection) and it seems relevant for deshake [20:09] <ubitux> (in lavfi) [20:09] <BBB> deshake is basically ME, isnt it? [20:09] <BBB> so that only fits [20:09] <BBB> I dont know what select does [20:09] <ubitux> scene detection [20:10] <ubitux> (it's in select filter so you can pick only the frame when it differs a lot from the previous one) [20:10] <ubitux> (typically useful to pick thumbnails) [20:11] <BBB> oh I see, sure, yeah [20:11] <ubitux> so, a lavu/AVPixelsUtils with sad & friends, and optional at build time (in which case av_get_pixels_utils_ctx() would return NULL) [20:11] <ubitux> ? [20:11] <BBB> sure, sounds ok to me [20:12] <BBB> AVDCT stays in lavc? [20:12] <ubitux> (do we have already configurable items in lavu like this?) [20:12] <BBB> no [20:12] <BBB> :-p [20:12] <ubitux> ah.. :) [20:12] <ubitux> ok [20:12] <ubitux> AVDCT should stay in lavc [20:12] <ubitux> it has permutation stuff [20:12] <ubitux> which is codec specific [20:12] <BBB> ok [20:13] <BBB> but idct_type will stay private (i.e. not part of AVDCT), right? [20:13] <BBB> I dont think theres any need for that ATM [20:13] <BBB> (given the uses) [20:13] <ubitux> currently all the options are exported as is [20:14] <BBB> code can be removed [20:14] <ubitux> but i believe there should be translated to "fastint", "int" [20:14] <ubitux> not sure what's the diff between "fastint" and a "fast"+arch [20:15] <ubitux> actually, even int could probably be dropped [20:15] <ubitux> i'm not sure how much variants needs to be accessible [20:15] <ubitux> we just want a "accurate" and a "fast" one [20:15] <ubitux> that should be the only exported bits [20:15] <BBB> kinda like -flags +fast? [20:15] <ubitux> so as option, only dct={accurate,fast} and idct={accurante,fast} [20:15] <BBB> or -flags +bitexact [20:16] <ubitux> yeah it's set through avoptions [20:16] <BBB> ok [20:16] <BBB> michaelni: ok? [20:16] <BBB> has anyone played with subidcts in hevc? [20:16] <BBB> they gave massive gains in vp9, i only see dc_add optimizations so far [20:17] Action: ubitux afk a bit, will work on lavu/AVPixelsUtils ASAP [20:18] <michaelni> fast, accurate hmm, theres also no permutation vs permutation [20:18] <ubitux> do you need that exported? [20:18] <michaelni> some user apps might want "no permutation" [20:19] <ubitux> when do we actually ever need the permutation outside lavc? [20:20] <michaelni> vf_spp [20:20] <michaelni> and theres the fast int (AAN) FDCT that requires postscaling [20:20] <michaelni> squishing that in accurate vs fast seems tricky [20:21] <ubitux> ok [20:21] <michaelni> and we have a float based FDCT, which leads to the question of where to put that speed wise related to int [20:21] <michaelni> the float AAN one is probably the most accurate but id have to recheck [20:21] <ubitux> well, as long as you remove the arch specific option names [20:21] <ubitux> i'm fine with whatever granularity [20:22] <ubitux> gtg, bb sson [20:22] <michaelni> ubitux, sure bye [20:26] <michaelni> "<BBB> michaelni: ok?", iam really fine with any solution people like [21:13] <cone-621> ffmpeg.git 03Anton Khirnov 07master:884f7c975f0a: output example: set the stream timebase [21:13] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:1c0c19f8bd4b: Merge commit '884f7c975f0af25febe86660e87bf3b2165a0309' [22:42] <ubitux> what are the "sse" functions in lavc/me_cmp.c? [23:02] <ubitux> does it make sense to have a configurable height for sad8/sad16? [23:05] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:9ccb9c8df256: doc/examples/muxing: move swr context to OutputStream [23:05] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:ead22f42f4fc: doc/examples/muxing: pick a supported channel layout if stereo isnt supported by the encoder [23:05] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:5d2cf1ae8642: doc/examples/muxing: select a supported sample rate for the encoder, favor 44100 [23:05] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:7cf086555177: doc/examples/muxing: Support setting flags, for example for setting bitexact [23:12] <michaelni> ubitux, sse = sum of squared error [23:12] <ubitux> mmh ok, thx [23:38] <cone-621> ffmpeg.git 03Anton Khirnov 07master:56f98e340fca: output example: convert audio to the format supported by the encoder [23:38] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:371cb96414bb: Merge commit '56f98e340fca894a76d1ddbe33118b8d8c4db34a' [23:42] <ubitux> if (INLINE_SSE2(cpu_flags) && !(cpu_flags & AV_CPU_FLAG_SSE2SLOW) && avctx->codec_id != AV_CODEC_ID_SNOW) { [23:42] <ubitux> c->sad[0] = sad16_sse2; [23:42] <ubitux> cfe675269bf44c49590e9076b5d2cd2503804f98 [23:42] <ubitux> why snow would use a sad16 (sad[0] is the 16 px width version) [23:43] <ubitux> if it hasn't 16-bytes available? [23:43] <ubitux> or is the sse2 version needing more that 16-bytes at once? [23:43] <ubitux> (i'm asking just to make sure the sad16_sse2 requirements are indeed just a 16-byte width constraints) [23:44] <michaelni> snow uses OBMC so 16x16 blocks overlap and dont always start at 16byte multiplies [23:45] <ubitux> but the read are unaligned [23:45] <ubitux> (or maybe not?) [23:46] <michaelni> yes [23:46] <ubitux> would psadbw be expected aligned pointers? [23:46] <ubitux> expecting* [23:47] <michaelni> basically all SSE* instructions expect aligned data except the unaligned moves [23:47] <ubitux> what about mmx? [23:48] <michaelni> mmx works with unaligned data [23:48] <ubitux> mmh ok [23:49] <ubitux> so basically, all C/MMX/MMXEXT are safe for unaligned access, but the SSE+ will require aligned data, at least for the second source [23:50] <michaelni> C is safe within the data types [23:50] <michaelni> so int64_t may need 8byte alignment [23:50] <michaelni> mmx/mmxext should be safe [23:50] <ubitux> no worry about C, it's a byte-per-byte diff afaict [00:00] --- Sun Jul 27 2014

1 0

ffmpeg.log.20140726
by burek 27 Jul '14

27 Jul '14

[00:02] <zybi1> Unknown encoder 'libfdk_aac' ?? [00:02] <c_14> You don't have libfdk_aac compiled in. [00:11] <zybi1> how can i re-encode from flac to wav [00:11] <c_14> ffmpeg -i flac wav [00:12] <c_14> ffmpeg -i blah.flac blah.wav [00:12] <zybi1> i mean within video reencoding sorry [00:13] <zybi1> ffmpeg -i INPUT.mkv -profile:v baseline -level 3.0 -c:v libx264 -preset slow -crf 18 -c:a output.mp4 [00:13] <c_14> wav is a format, not a codec [00:14] <llogan> i doubt you can put most? pcm ("wav") in mp4. [00:19] <zybi1> so what would be the command line then? [00:20] <zybi1> I rebuilt ffmpeg and now the man-page is all messed up [00:24] <llogan> zybi1: what audio format do you want to use? [00:24] <llogan> or do you want to just re-mux it? [00:25] <zybi1> actually i wanna make a mac/apple compliant video file not too large [00:25] <zybi1> from a mkv 70mbit lossless with flac audio [00:38] <c_14> You'll probably want to use x264 and aac (if you're fine with lossy audio). If you know how big "not too big" is you can use 2-pass encoding. [00:40] <zybi1> but i got this ac-3 library problem ffmpeg being not built with it [00:41] <c_14> ac3 or aac, there's a difference [00:42] <llogan> zybi1: which devices do you want to support, exactly? [00:42] <zybi1> any kind of mac osx system [00:42] <zybi1> or the most possible [00:42] <llogan> also, when you encounter an issue you should always include a link to pastebin showing your command and complete console output [00:45] <zybi1> llogan: http://www.pasteall.org/53077 [00:55] <llogan> zybi1: your build does not support the encoder libfdk_aac. use "-c:a aac -strict experimental" instead. [00:56] <llogan> also add "-pix_fmt yuv420p" as an output option since Apple stuff needs 4:2:0 [01:15] <zybi1> thanks llogan [01:33] <cbrugh> hello, we have an issue with running the following command... on freebsd 8 machine this command runs without problems, on freebsd 9.1 this command generates the errors below. We are using ffmpeg 1.2.7 on both servers with libx264 compiled in examply the same. [01:33] <cbrugh> ffmpeg -i 'in.mp4' -c:v libx264 'out.mp4' [01:34] <cbrugh> [h264 @ 0x803c9d120] Cannot use next picture in error concealment [01:34] <cbrugh> [h264 @ 0x803c9d120] concealing 3454 DC, 3454 AC, 3454 MV errors in P frame [01:34] <cbrugh> get those errors over and over on the fbsd 9.1 machine [01:35] <relaxed> 1.2.7 is fairly old. which version is now in /usr/ports ? [01:35] <cbrugh> relaxed: well on the fbsd 9.1 machine I did install the latest 2.3 [01:35] <cbrugh> same results [01:36] <cbrugh> on the fbsd 8 machine this command runs just fine... I have the same compile and everything between the two [01:36] <relaxed> you compiled it yourself? [01:36] <cbrugh> yeah [01:37] <relaxed> how large is in.mp4? [01:37] <cbrugh> 31MB [01:38] <relaxed> can you put it up somewhere? [01:38] <cbrugh> sure [01:39] <cbrugh> http://www.drivetrainspecialists.com/in.mp4 [01:39] <relaxed> pastebin the ffmpeg command and all console output too [01:40] <cbrugh> pastebin console output: http://pastebin.com/5pBsY4GQ [01:40] <cbrugh> you can download the mp4 with the link above [01:42] <relaxed> So you're saying ffmpeg exits with a nonzero exit status? [01:43] <relaxed> I'm running the same command and it's dropping a shit ton of frames. [01:45] <relaxed> but its exit status is zero [01:45] <relaxed> cbrugh: ^^ [01:49] <trn> If anyone wouldn't mind looking at my info and question, it's on pastebin: http://goo.gl/m3p9Gs ... need guidance on DTS/PTS stuff. [01:49] <trn> It's the one part of the application prototype that isn't working right. I've already went through and successfully converted most of it to C already actually. [01:52] <trn> BTW, I give the ffmpeg props, the code actually is pretty decent where it matters and the libraries are great. [01:53] <trn> I actually tried to use libav stuff and had enough random issues over three days to never want to touch it again. [01:55] <relaxed> It would probably help if you could isolate your problem to something smaller than a 1000 line pastebin post. [01:55] <trn> relaxed: The first 780 lines are configuration and such beyond the first block of text. [01:56] <relaxed> widdle it down to something small and repeatable [01:57] <trn> relaxed: It's just a small part of a very large clustered application that runs on several clusters of thousands of nodes and can have 5000 or more ffmpeg library functions active at a time, and we produce 300MB of logs per hour. [01:58] <cbrugh> relaxed: let me run it all the way thru [01:58] <trn> relaxed: It really is the smallest I can do, it's more a lack of my knowledge of what to do, it isn't a problem per-se. :) [01:59] <llogan> i don't have any answers, but line 785 looks bad. (using cpu capabilities: none!) [01:59] <trn> relaxed: Lines 728 through 1020 is the absolute repeatable issue. [01:59] <relaxed> cbrugh: before you do that, I recommend you install the latest version through /usr/ports and have it use gcc-4.8 as the compiler. [02:00] <trn> llogan: Yeah, that is something to do with the virtualization but it isn't a problem, just a performance issue. [02:00] <cbrugh> relaxed: ok [02:01] <trn> llogan: I just need to know how to have the reading processes that take streams as input not drop frames up to the point where the last decoding stopped. [02:03] <trn> [videosource] -> [processing/splitting] -> [decode and normalize to 2 stream raw yuv4 and 2-ch PCM] -> [split again] -> cluster nodes receiving here ... [02:03] <trn> The nodes then encode to attached client preferred sources, and encoders and initialized and destroyed based on consumers attached. [02:04] <trn> The problem is when videosource is swapped to a new stream without closing the chain. [02:04] <trn> The raw/PCM muxed as NUT has a timestamp which is always increasing, lets say the original stream stops at frame 2000. [02:05] <trn> The encoders receiving mux'd NUT data will drop all frames until frame 2001. [02:05] <trn> So I really need to rewrite the timestamps in the libav* receiving end. [02:07] <trn> Like if the new source PTS starts over, then rewrite as current PTS = previous input PTS+current PTS. [02:08] <trn> So it'll see frame 4001 and immediately begin decoding again, instead of dropping 2000 frames first since they are read at framerate. [02:08] <trn> Am I making any sense? [02:08] <llogan> i don't know how to do that. [02:09] <trn> I also have some technical questions on the nut container and I'm hoping someone knows rather than having to fully understand the sources :) [02:09] <trn> Because I'm using the ffmpeg included nut but I also have mplayer/ffmpeg libnut available, and was wondering if one implementation or another is preferred or more robust or if they are equivilant. [02:09] <relaxed> trn: It sounds like you need https://www.ffmpeg.org/consulting.html [02:10] <trn> relaxed: You are probably right, heh. :) [02:11] <trn> Probably more than the standard end-user question, I know. [02:11] <relaxed> It never hurts to try :) [02:13] <trn> relaxed: full logs from the stream processing part of the application can be 300MB or more per hour of live input across all nodes too. [02:14] <trn> So it's not practical to post everything, but I just hope I can be believed when I say this is the subset where I don't know how to adjust the timestamps as I would need to :) [02:15] <trn> And I managed to turn it into two concurrent standard ffmpeg commands attached via named unix pipes with exact same behavior as the application. [02:15] <trn> So it's not a ffmpeg issue, I just don't know how to do what I need to do :) [02:16] <trn> And I don't want to tell the boss I've got it 98% working, now pay someone real money for the last 2%. [02:20] <trn> I did have it fully working using a homebrew messaging API using segmented MP4 as the transport standard, and using some propriatary vendor-not-to-be-named libraries. [02:21] <trn> It just ended up having very poor performance when it came to error handling, which would cause audio/video desync issues when running for long periods. [02:22] <trn> The ffmpeg timestamp stuff is much better than the commercial offering, fyi. The problem here is it is *too* conservative. [02:22] <trn> And assumes output DTS simply can't be < encoded output DTS, except in this case it can be under certain circumstances. [02:23] <trn> sorry input DTS can't be less than encoded output DTS. [02:24] <trn> Also, a certain other vendor uses 32-bit integers in places that have no business using them, causing overflow issues after a few days. [02:25] <trn> And random memory leaks that I bet they never noticed because most people use the encoder for 2-4 hours of input, not 200-400 hours. [02:26] <trn> And things like tables that just keep growing for things like indexes that we never use and no public way to enable them. [02:26] <trn> When I get his working I'm going to donate to ffmepg for sure, for what its worth. [02:26] <trn> *disable them. [02:26] <trn> anyway blah [02:50] <msuth> Hi guys i have 1 question [02:52] <msuth> i have url where it has different bitrate how to download the 1 only i want [02:52] <msuth> it has 1080P, 720P, 480P [02:53] <msuth> how to select 720P to download only is always downloading the 1080P [02:53] <sacarasc> This isn't an ffmpeg question? [02:54] <msuth> ya i am downloading m3u8 with ffmpeg [02:54] <sacarasc> m3u8 files are plain text, remove the streams you don't want. [02:54] <msuth> ffmpeg -i url -c copy output [02:56] <msuth> i tired that but i couldn't load the m3u8 after saving it to my computer [02:57] <msuth> so i was thinking when getting the m3u8 from the url can i insert something to download only 1 bitrate [02:58] <sacarasc> Download the playlist, take the stream URL from it, use that directly? [03:00] <trn> OK, I'm actually working with m3u8 and rewrote the whole ffmpeg code for that yesterday :) [03:00] <trn> sacarasc: ffmpeg already enumerates them as different streams and they act normally. [03:00] <trn> Like if you don't specify which stream, it falls back on the standard ffmpeg heuristics. [03:00] <msuth> yea tru TRN [03:01] <msuth> how can i specify stream [03:01] <msuth> or program ID [03:01] <trn> sacarasc: Use standard -map [03:02] <msuth> can you please specify this is [03:02] <msuth> Duration: 02:06:21.00, start: 0.700000, bitrate: 0 kb/s [03:02] <msuth> Program 0 [03:02] <msuth> Metadata: [03:02] <msuth> variant_bitrate : 3560000 [03:02] <msuth> Stream #0:0: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1920x1080 [03:02] <msuth> [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc [03:02] <msuth> Metadata: [03:02] <msuth> variant_bitrate : 3560000 [03:02] <msuth> Stream #0:1: Audio: aac ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp, 51 [03:02] <msuth> kb/s [03:02] <msuth> Metadata: [03:02] <msuth> variant_bitrate : 3560000 [03:02] <msuth> Program 1 [03:02] <msuth> Metadata: [03:02] <msuth> variant_bitrate : 1640000 [03:02] <msuth> Stream #0:2: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [03:02] <trn> I don't know the cli, but in av+_find_best_stream is the function if you want to see the heuristics. [03:02] <trn> hmmm lemme think for a sec [03:03] <msuth> see it has like program 0 and 1 [03:03] <msuth> program 0 is 1980 and program 1 is 1270 [03:03] <msuth> 1920** [03:03] <msuth> 1280** [03:03] <trn> Not sure how to do it via cli, but I can check. [03:04] <msuth> please if you have time [03:04] <msuth> i'll wait here [03:04] <trn> msuth: I actually use Trinity Broadcasting's headend streams like http://acaooyalahd2-lh.akamaihd.net/i/TBN01_delivery@186239/master.m3u8 for my testing. [03:04] <msuth> i tired google last nite full couldnt make it to work [03:04] <trn> msuth: Check out how many they provide :) [03:05] <trn> msuth: I recently wrote a module that lets you specify multiple segment outputs as the same m3u8 playlist, and 1 input. [03:05] <msuth> [http @ 0000000002c8f220] HTTP error 404 Not Found [03:05] <msuth> http://acaooyalahd2-lh.akamaihd.net/i/TBN01_delivery@186239/master.m3u8 -c copy [03:05] <msuth> nallun2014.mp4: Input/output error [03:06] <msuth> i am getting error with that url u provided [03:06] <trn> So instead of stream_high and stream_low m3u8's you will get stream.m3u8 which uses the correct hints for clients that support adaptive streaming. [03:08] <trn> msuth: hmm... what happens if you just do ffmepg -i and that URL? I know it will take awhile to sync but it does.... [03:10] <msuth> just getting error [03:10] <msuth> but it has program ID up to 11 [03:11] <msuth> 320kb/s audio file [03:13] <trn> I just did a ffmepg -i url -c copy out.mkv and it works [03:15] <msuth> it works but how to download just 1 of the files inside [03:15] <msuth> ? [03:15] <trn> Relevant was Stream mapping: ····· [03:15] <trn> Stream #0:24 -> #0:0 (copy) ····· [03:15] <trn> Stream #0:1 -> #0:1 (copy) ····· [03:16] <trn> soooo, lets see ... [03:17] <msuth> ok i got the map option to work [03:17] <msuth> thanks buddy [03:17] <msuth> and 1 more question when downloading with the m3u8 i am getting 103fps [03:17] <msuth> how to increse [03:17] <msuth> i have 17 4770 [03:17] <msuth> 32gb ram [03:18] <trn> Example: ffmpeg -i http://acaooyalahd2-lh.akamaihd.net/i/TBN01_delivery@186239/master.m3u8 -map 0:18 -c:v copy····· [03:18] <trn> -map 0:32 -c:a copy test.mkv [03:18] <trn> works here [03:18] <sacarasc> Downloading usually bottlenecks at your connection speed. [03:18] <trn> sorry for my paste issues there :) [03:18] <trn> But yeah, the programs aren't exposed via separate enumeratation in the ffmepg cli. [03:19] <trn> It's just sequential streams starting 0 through the end. [03:19] <msuth> ya [03:19] <msuth> i did like this [03:19] <trn> The C API is nicer honestly :) [03:19] <msuth> ffmpeg -i "url" -map 0:4 -map 0:5 -c copy un2014.mkv [03:19] <trn> But yeah, m3u8 handling in ffmpeg is fantastic compared to that other inferior project :) [03:19] <msuth> but is slow downloading [03:20] <msuth> i have 1gbps line dedicated [03:20] <msuth> and is slow downloading [03:20] <sacarasc> Could be rate limited at the other end. [03:20] <trn> msuth: It might be just the pipe inbetween, also it could be ffmpeg too. [03:20] <trn> msuth: Is this a full m3u8 with all segments or a window-only live file? [03:21] <msuth> huh i dont get it [03:21] <trn> With the windowed file, that's normal, it'll grab as many segments as possible then refresh the m3u8 and when new segments are added it'll grab them. [03:22] <trn> The only performance increase I've found possible is using HTTP keepalive to the server, so when you pull down the m3u8 you aren't having to open a new connection every time. [03:22] <msuth> is there ffmpeg multithreaded version [03:22] <trn> I'm not sure if ffmpeg does this or not. Default ffmepg is threaded, if you add -threads 0 it will use as many as should be optimal. [03:23] <msuth> oh k [03:23] <msuth> kool [03:24] <trn> When I first read m3u8 docs I wanted to hang myself. [03:24] <trn> But honestly it's one of the better hacks to come out of Apple. [03:24] <msuth> lol [03:24] <msuth> have u tired adobe-hds [03:26] <trn> I'm only famaliar with streaming MP4 files and HLS myself, really. And I only started even caring about this stuff last week. :) [03:26] <trn> I do have tons of past experience with telephony stuff, so it's all vaguely related. :) [03:28] <msuth> thanks bro iam off now [03:28] <trn> heh [03:28] <trn> at least I'm good for something [03:39] <trn> I even wrote a quick script that lets me use the VPN function of an iPhone to connect to my network, and I use mitmproxy for ssl unwrapping and transparent squid for HTTP... [03:40] <trn> intercept HLS requests and any associated AES keys, and then I can get that into ffmpeg to save the streams to disk. [03:41] <trn> So when I want to watch sports, I turn on the VPN, start the app (since every app that does streaming in the App Store is HLS), then just confirm it's recording to disk and watch it later. [03:41] <trn> Or send it to Chromecast where the original apps don't support it yet. :) [04:58] <trn> Lovely. I thought I broke something on my server, it's in Dallas, TX. Getting 8K/s at best. [04:58] <trn> But no, ran a speedtest using another two different Dallas servers and I'm getting 8-14K/s. [04:59] <trn> On my LTE or a non-Dallas server, 10+Mbps. [05:00] <trn> Actually getting 108 kbps down, 382 kbps up. Lovely. That means I go to sleep now. [05:08] <trn> yay 75% packet loss at mai-b1-link.telia.net [05:10] <sythe> Hey [05:10] <sythe> I have an MP4 with audio [05:10] <sythe> And an MP3 with different audio [05:10] <sythe> How can I combine them all into one MP4 with both audio channels? [05:21] <rcombs> ffmpeg -i in.mp4 -i in.mp3 -map 0 -map 1 -codec copy out.mp4 [05:23] <sythe> I think I tried that [05:24] <sythe> ffmpeg -i episode-test-4.mp4 -i episode3-final-voiceover.mp3 -map 0 -map 1 -codec copy episode2.mp4 [05:24] <sythe> I tried that [05:24] <sythe> It didn't work [05:24] <sythe> rcombs: ^ [05:24] <sythe> It only kept one audio stream [05:24] <rcombs> pastebin the console output? [05:24] <sythe> I mean, it produced an mp4 [05:24] <sythe> It just only had the original mp4's channel [05:25] <rcombs> (keep in mind, "stream" and "channel" are different things; here, we want to add an audio *stream*) [05:26] <sythe> IDK [05:26] <sythe> I have two audio sources, then [05:26] <sythe> One with a voiceover, one with background sound [05:26] <sythe> The one with background sound is already part of the video file [05:26] <rcombs> again, I need to see the console output [05:27] <sythe> Ok, pastebinning [05:27] <sythe> Once it finishes [05:27] <sythe> Since I've rebooted since the first time [05:28] <sythe> https://www.irccloud.com/pastebin/TCEsmUml [05:28] <sythe> rcombs: ^ [05:29] <rcombs> sythe: that definitely shows the audio streams from both files being merged into the output. Did you mean that you wanted to mix the two streams into a single one? [05:30] <sythe> rcombs: Whichever allows playback to play both streams at once, lol [05:30] <sythe> When I open it in VLC, I only hear the original audio from the source video [05:31] <rcombs> sythe: alright, then you want the "amix" filter [05:31] <rcombs> sythe: you just want this for VLC playback, not for distribution or mobile device playback, yeah? [05:31] <sythe> I want to upload it to Youtube [05:31] <rcombs> ah, gotcha [05:31] <sythe> :) [05:32] <sythe> rcombs: So, what command? [05:32] <rcombs> what audio codecs does your ffmpeg build support? [05:32] <sythe> It says right there in the pastebin [05:32] <sythe> Doesn't it? [05:32] <sythe> :P [05:32] <rcombs> ah, I forgot the configure header :D [05:32] <rcombs> just a sec [05:33] <rcombs> ffmpeg -i episode-test-4.mp4 -i episode3-final-voiceover.mp3 -map 0:0 -vcodec copy -filter_complex '[0:1][1:0]amix[out]' -map '[out]' -acodec libmp3lame -ab 320k episode2.mp4 [05:33] <rcombs> ^ the audio quality might be able to be improved a bit, but that should definitely work with YouTube, at least [05:34] <sythe> Thanks :) [05:35] <rcombs> what we're doing there is passing the two audio streams through the `amix` filter and encoding as MP3, but copying the input video untouched [05:35] <sythe> :D Sweet [05:35] <sythe> Hope it works [05:36] <sythe> rcombs: Is there way to have ffmpeg auto-truncate an mp3 until audio begins? [05:36] <sythe> E.g., it would only copy once silence stopped? [05:38] <sythe> rcombs: It worked! :D [05:38] <rcombs> I don't think there's a way to do that builtin, but if you can figure out exactly when the silence ends, you could put `-ss <seconds to skip>` before the -i for the audio file [05:38] <sythe> The second -i? [05:38] <rcombs> yeah [05:39] <sythe> Sweet [05:39] <sythe> rcombs: Is there an opposite of that? [05:39] <rcombs> and you could use `ffmpeg -i episode3-final-voiceover.mp3 -af silencedetect -acodec pcm_u8 -f null /dev/null` to figure out how long the silence is [05:39] <rcombs> sythe: to delay the audio, you mean? [05:39] <sythe> Yeah [05:40] <rcombs> note that https://www.ffmpeg.org/ffmpeg-filters.html is an excellent resource on this [05:40] <sythe> Basically, I start recording one audio source, then alt-tab to start recording the other [05:40] <sythe> So it's always 2-3 seconds delayed [05:40] <rcombs> OK, so take a look at our current `-filter_complex` arg [05:40] <sythe> rcombs: Thanks, but...these are like the only two I need to do [05:40] <sythe> :/ [05:40] <rcombs> '[0:1][1:0]amix[out]' <-- think you can identify what each of these 4 parts does? [05:41] <rcombs> (don't worry, I'll get from here to audio delaying) [05:41] <sythe> Well, the first two are media stream IDs, I think [05:42] <rcombs> yup, good [05:42] <rcombs> and then we have the filter name ("amix") and a name for our output ("out") [05:42] <rcombs> we make sure our "out" stream ends up in the output file with `-map '[out]'` [05:43] <rcombs> our inputs currently are [0:1] ("first file, second stream" [because these are zero-indexed]) and [1:0] ("second file, first stream") [05:43] <rcombs> so, we want to apply an "adelay" filter to our voiceover stream, which is [1:0] [05:45] <rcombs> that filter will look something like this: '[1:0]adelay=1500[delayed]' [05:45] <sythe> 1500 is 1.5 seconds, right? [05:45] <rcombs> here I'm using 1500ms (1.5 seconds) for the delay; you'd fill in whatever you wanted [05:45] <rcombs> yup! [05:45] <sythe> :) [05:46] <rcombs> so, if we add that filter, then we have a stream called "delayed" [05:46] <rcombs> and now we want to use that delayed stream as an input for the "amix" filter from earlier [05:46] <rcombs> so together, it'd be '[1:0]adelay=1500[delayed];[0:1][delayed]amix[out]' [05:46] <rcombs> make sense? [05:47] <sythe> ffmpeg -i episode-test-4.mp4 -i episode3-final-voiceover.mp3 -map 0:0 -vcodec copy -filter_complex '[0:1][1:0]adelay=1500[delayed];[0:1][delayed]amix[out]' -map '[out]' -acodec libmp3lame -ab 320k episode2.mp4 [05:47] <sythe> ? [05:48] <sythe> I think I put it in the wrong place [05:48] <rcombs> looks good to me [05:49] <sythe> Strange [05:49] <rcombs> erm, wait [05:49] <rcombs> not quite [05:49] <sythe> Thought so [05:49] <rcombs> you've just got an extra [0:1] in there [05:49] <rcombs> adelay only takes one input, and we only want to delay one of the streams anyway [05:49] <sythe> The first one? [05:49] <rcombs> yeah [05:50] <sythe> ffmpeg -i episode-test-4.mp4 -i episode3-final-voiceover.mp3 -map 0:0 -vcodec copy -filter_complex '[1:0]adelay=1500[delayed];[0:1][delayed]amix[out]' -map '[out]' -acodec libmp3lame -ab 320k episode2.mp4 [05:50] <sythe> ? [05:50] <rcombs> we only want to use [0:1] as an input to amix, not to adelay [05:50] <rcombs> yeah, that should be better [05:50] <sythe> ahhh [05:50] <sythe> Thanks [05:50] <sythe> I shall test this [05:51] <rcombs> congrats, you've learned a bit about ffmpeg filtering! [05:52] <sythe> Very strange [05:53] <sythe> I never thought I would [05:54] <sythe> Let's see if a 3.8 second delay works... [05:54] <trn> rcombs: Hrrm, you might have helped me as well! [05:54] <sythe> FAQ! [05:54] <sythe> lol [05:56] <rcombs> trn: I try! [05:57] <trn> rcombs: Well, once Telia is fixed, I'll try it, and then I've got to figure out how to translate a working command to libavfilter ... [05:57] <rcombs> ah, heh [05:58] <rcombs> check out http://www.ffmpeg.org/doxygen/trunk/group__lavfi.html#ga6c3c39e0861653c71a2… [05:58] <trn> So far the libraries have been very easy to use! [05:59] <trn> See, too easy. [06:00] <trn> rcombs: http://goo.gl/m3p9Gs [06:00] <trn> Last time I spam it here, promise. [06:00] <sythe> Thanks again, rcombs :) [06:01] <sythe> I can finally record and upload gameplay videos on Linux w/o pain [06:01] <trn> But yeah, that's where I'm at now, replicated my application behavior with the ffmpeg tool. [06:02] <trn> And now that lavfi message re async seems to be much more ominous now, considering the nature of my problem! [06:09] <rcombs> maybe try an actual concatenateable format for the intermediate, like .ts? [06:09] <sythe> rcombs: For seconds to skip, it would be -ss 1000 for 1 second, eh? [06:10] <rcombs> sythe: no, -ss is given in seconds, not milliseconds [06:10] <sythe> Ok, thanks [06:10] <rcombs> sythe: you can specify with greater precision by doing e.g. 1.024 or something (for 1024ms) [06:10] <trn> rcombs: NUT is perfect for that because of the overhead, without the index no tables that grow, and fastest recovery from errors. [06:12] <trn> And NUT is concatenteable :) And passsed every raw torture test I threw it at, regarding error recovery in the least number of frames ... [06:15] <rcombs> or, if you [06:15] <rcombs> 're using raw video, why not just use yuv4mpegpipe [06:16] <trn> rcombs: Mainly because I'm transporting 2-ch PCM mux'd with the video right out of ffmpeg appropriate decoder. [06:17] <trn> Which I'm doing in an attempt to keep A/V sync issues at a minimum and avoid the possibility that a segment of a stream being moved around internally goes missing. [06:18] <rcombs> have you checked if it works with MPEG-TS? [06:18] <trn> But I admit I was rathe naive when I started, but the idea was to keep the two mux'd together for purposes of A/V sync ... [06:19] <trn> rcombs: Not lately, no :) I will give it a shot once telia fixes the network issues enough that I can send a stream here to my house in realtime :) [06:19] <trn> But I actually see a solution here. [06:20] <rcombs> the `-shortest` arg can probably help avoid issues with one stream ending before another in an input file [06:21] <trn> I can have the decoding side of things send a message to it's input provider (easy to do here actually) with the PTS value of the most recently received frame. [06:21] <rcombs> also, ffserver may or may not be worth looking at, depending on exactly what you're trying to do [06:22] <trn> That way when another input connects, rather than starting to dump data with a new PTS of 0, it can request what PTS to start at, and then using setpts becomes easy. [06:23] <trn> A tiny delay for internal message passing isn't a big deal if the frame provider has to reconnect anyway, or I wouldn't imagine it would be. [06:29] <sythe> rcombs: I'm watching my own gameplay video [06:29] <sythe> And I'm entertained. [06:29] <sythe> >.< [06:29] <sythe> #FFMPEGFTW [06:34] <trn> Hrrm. :) [06:34] <trn> demuxer+ffmpeg -> ist_index:1 type:audio pkt_pts:776021 pkt_pts_time:17.5968 pkt_dts:776021 pkt_dts_time:17.5968 off:0 off_time:0 [06:34] <trn> encoder <- type:audio frame_pts:775168 frame_pts_time:17.5775 time_base:1/44100 [06:34] <trn> encoder -> type:audio pkt_pts:771072 pkt_pts_time:17.4846 pkt_dts:771072 pkt_dts_time:17.4846 [06:34] <trn> muxer <- type:audio pkt_pts:771072 pkt_pts_time:17.4846 pkt_dts:771072 pkt_dts_time:17.4846 size:253 [06:34] <trn> then I broke the stream. [06:35] <trn> Then I connected a new input. [06:36] <trn> encoder <- type:audio frame_pts:848896 frame_pts_time:19.2493 time_base:1/44100 [06:36] <trn> encoder -> type:audio pkt_pts:844800 pkt_pts_time:19.1565 pkt_dts:844800 pkt_dts_time:19.1565 [06:36] <trn> muxer <- type:audio pkt_pts:844800 pkt_pts_time:19.1565 pkt_dts:844800 pkt_dts_time:19.1565 size:295 [06:36] <trn> demuxer -> ist_index:1 type:audio next_dts:19285781 next_dts_time:19.2858 next_pts:19285781 next_pts_time:19.2858 pkt_pts:850503 pkt_pts_time:19.2858 pkt_dts:850503 pkt_dts_time:19.2858 off:0 off_time:0 [06:36] <trn> demuxer+ffmpeg -> ist_index:1 type:audio pkt_pts:850503 pkt_pts_time:19.2858 pkt_dts:850503 pkt_dts_time:19.2858 off:0 off_time:0 [06:36] <trn> etc. [06:39] <rcombs> I haven't looked closely enough at all of that to know if it looks good [06:41] <trn> ah ha! It is good. [06:41] <rcombs> :D [06:41] <trn> Because when I turn on debug and cause the error it's the automatic filters added by async :) [06:41] <trn> [graph 1 aresample for input stream 0:1 @ 0x1088d20] [SWR @ 0x103c9e0] discarding 772679 audio samples [06:41] <trn> *** dropping frame 411 from stream 0 at ts 100:17.41 bitrate=N/A [06:41] <trn> *** dropping frame 411 from stream 0 at ts 2 [06:41] <trn> *** dropping frame 411 from stream 0 at ts 3 [06:46] <trn> now I'm thinking how to fix :) [06:55] <trn> It might be fixed now, but I can't tell until the fix the interweb tubes. :) [06:57] <trn> I'll need to write a script that does bad things to the streams for hours and then I'll know when I see how well they are sync'd up [07:23] <trn> rcombs: BTW, can't do raw/PCM in MPEG2TS unless there is a way to force it. [07:24] <trn> A sender: [07:24] <trn> Stream #0:24 -> #0:0 (h264 (native) -> rawvideo (native)) [07:24] <trn> Stream #0:1 -> #0:1 (aac (native) -> pcm_s16le (native)) [07:24] <trn> Receiving demuxer: [07:24] <trn> [mpegts @ 0x18cc2a0] Could not find codec parameters for stream 0 (Unknown: none ([6][0][0][0] / 0x0006)): unknown codec [07:24] <trn> Stream #0:0[0x100]: Unknown: none ([6][0][0][0] / 0x0006) [07:24] <trn> Stream #0:1[0x101]: Audio: aac ([6][0][0][0] / 0x0006), 12000 Hz, 4.0, fltp, 396 kb/s [14:50] <tbj> Hi, I have problem with ffserver - http://pastebin.com/byfmVyBC [16:53] <kaotiko> hi [17:18] <jusss> how to combine a srt file and a mp4 file? [17:19] <jusss> let it be hardsub [17:47] <tbj> kaotiko: Hi [17:55] <sacarasc> jusss: I think you have to use -vf ass=blah.srt [17:55] <ubitux> subtitles=blah.srt or ass=blah.ass [18:02] <tbj> ubitux: Can you help me with enabling libx264, libx265, libfaac and libmp3lame? I tried these codecs, but I got some errors. Here is logfile: http://pastebin.com/byfmVyBC [18:02] <ubitux> you don't have libfaac [18:02] <ubitux> or at least the headers [18:04] <tbj> ubitux: I have it, I installed it, but it doesn t work. And how I can add headers? [18:04] <ubitux> if you're on a debian like that's probably in a libfaac-dev or something [18:05] <JEEB> tbj, rather use libfdk-aac than faac, both are not compatible with x264 and non-distributable, but fdk is much better [18:05] <JEEB> uhh [18:05] <JEEB> s/x264/GPL/ [18:05] <JEEB> :V [18:05] <tbj> I have Ubuntu 14.0.4 (I think) [18:06] <JEEB> https://github.com/mstorsjo/fdk-aac [18:06] <tbj> JEEB: Hi, thank for answer. I will try it- [18:06] <JEEB> this is fdk-aac :3 [18:10] <tbj> JEEB: I tried fdk-aac and libfdk-aac, but it doesn t work [18:10] <JEEB> what doesn't work? [18:11] <tbj> First I tried modify it in ffserver.conf [18:12] <JEEB> oh, so you built it and linked it into your ffmpeg? [18:12] <JEEB> ffmpeg -codecs |grep "fdk" [18:12] <JEEB> that should show the avcodec internal name [18:14] <tbj> Now I tried to clone and install it from github, but no file makefile is there. [18:15] <JEEB> it's an automake based project [18:15] <JEEB> autoreconf -fiv [18:15] <tbj> No result... [18:15] <JEEB> creates them [18:15] <JEEB> then you get a configure file and the main makefiles created [18:17] <tbj> still no usable result in ffmpeg -codecs | grep "fdk" [18:17] <JEEB> well yes, if you haven't built and installed and compiled ffmpeg with it :P [18:17] <JEEB> just like you have to compile ffmpeg with faac if you want faac [18:17] <JEEB> see the configure --help output of ffmpeg for the option to enable [18:17] <JEEB> ./configure --help |grep "fdk" for ffmpeg's configure [18:19] <tbj> of course... Please wait [18:25] <slowguy> http://ur1.ca/hu2u9 i am using this command ..but ffmpeg says No such filter 'trim' [18:25] <slowguy> is trim filter now available now? [18:25] <slowguy> not* [18:29] <slowguy> [AVFilterGraph @ 0x1496660] No such filter: 'trim' [18:29] <slowguy> strange :( [18:36] <tbj> Error: libfaac not found [18:37] <slowguy> ubitux: i already did that [18:37] <ubitux> > and the COMPLETE console output. [18:37] <slowguy> okay [18:38] <slowguy> just a sec [18:39] <slowguy> http://ur1.ca/hu2xc [18:39] <slowguy> ubitux: ^ [18:40] <ubitux> > ffmpeg version 1.2.6 [18:40] <ubitux> too old probably [18:40] <ubitux> we are in 2.3 currently [18:40] <slowguy> ubuntu does not provide ffmpeg ? i had to add some launchpad ppa [18:40] <slowguy> and then i downloaded it [18:40] <ubitux> it doesn't [18:41] <ubitux> you can grab a static build here or use the fork [18:41] <ubitux> or build it yourself [18:41] <slowguy> static build = direct download and run the binary? [18:41] <ubitux> yes [18:41] <slowguy> right let em try [18:46] <slowguy> ubitux: got it thank you [18:47] <slowguy> ubitux: another thing..i wanted a very fast method to crop commercials from the serial without re-encoding ..am i doing right in your i opinion? or is there a faster way? [18:47] <ubitux> it's re-encoding with your method [18:48] <slowguy> yeah i noticed that :( [18:48] <ubitux> use -ss and -t to extract, and concat demuxer to concat [18:48] <slowguy> how can i prevent re-encoding? [18:48] <slowguy> u mean separate ffmpeg commands? [18:50] <slowguy> you mean first create multiple parts and then cocat them in the last? [18:51] <slowguy> or is it possible using a simgle commands? [18:52] <slowguy> i was searching on net but could not find how i can use multiple -ss -t in a simgle command [19:01] <slowguy> ubitux: please give me a hint in the form of command..then i will find the rest myself..i will not bother you more for this simple thing [19:02] <ubitux> ffmpeg -ss 123 -i input -t 45 -c copy -map 0 output0 [19:02] <ubitux> ffmpeg -ss 150 -i input -t 10 -c copy -map 0 output1 [19:02] <ubitux> etc [19:02] <ubitux> then create a concat demuxer file with all the outputs [19:02] <ubitux> and run the command [19:02] <ubitux> look at the faq for concat [19:02] <ubitux> and look for concat demuxer [19:03] <slowguy> okay thank you so much [19:03] <ubitux> http://ffmpeg.org/faq.html#Concatenating-using-the-concat-demuxer [19:03] <tbj> Next question: How to protect stream using AES? I want to protect live stream. [22:35] <MachinaeWolf> Are there any aac or faac/faad flags to emable aac support that I should be aware of? [22:36] <c_14> What are you trying to do? [22:37] <MachinaeWolf> Get moc to play my .m4a music files, it was compiled with ffmpeg support so I thought maybe ffmpeg might need those kinds of flags enabled too? [22:37] <MachinaeWolf> because moc with the aac and related flags aren't doing it :( [22:37] <c_14> You mean when compiling ffmpeg? [22:37] <MachinaeWolf> yes [22:38] <c_14> The decoder should be in by default so long as you don't disable anything iirc. [22:39] <MachinaeWolf> ah [22:39] <MachinaeWolf> Are you good with moc then lol? [22:40] <c_14> I have no idea what that is. [22:40] <MachinaeWolf> ok, just thought I'd ask [23:24] <FrEaKmAn_> hi all.. [23:25] <FrEaKmAn_> I convert a file with -vcodec libx264 -acodec aac -strict -2 to mp4 [23:25] <FrEaKmAn_> now when I want to cut it, audio and video are not synced [23:25] <FrEaKmAn_> if I do -c copy [23:29] <c_14> try adding -vsync 0 [23:31] <FrEaKmAn_> strange [23:31] <FrEaKmAn_> actually audio is ok, but video is incorrect [23:31] <FrEaKmAn_> is libx264 good codec? [23:31] <c_14> Define "good codec". [23:32] <FrEaKmAn_> something that gives the best quality and can be easily cut and concatenated [23:32] <FrEaKmAn_> easily == fast [23:35] <c_14> h264 should do that, except for the "best quality" part which is subjective. [23:36] <c_14> Can you pastebin your commands and their outputs? [23:36] <FrEaKmAn_> ok [23:37] <iive> FrEaKmAn_: have in mind that video is always cut at keyframe, so having small keyframe interval helps for precise cutting. [23:38] <FrEaKmAn_> c_14: http://pastie.org/9423416 [23:38] <FrEaKmAn_> iive: ok [23:39] <FrEaKmAn_> so based on the code, if I specify vcodec with cutting it works [23:39] <FrEaKmAn_> but afaik, the original video should already have libx264 codec [23:39] <c_14> What about the output? [23:39] <c_14> Also, you can do the cutting in the first step. [23:39] <iive> sorry, i mean when you -c copy, it cuts at keyframe. [23:39] <FrEaKmAn_> so vcodec copy should be same as vcodec libx264 [23:39] <c_14> Also, try moving -ss and -t to the input side from the output side. [23:40] <iive> when you reencode, you can start at any frame. [23:40] <c_14> FrEaKmAn_: It isn't. -vcodec copy copies the stream, -vcodec libx264 reencodes the stream. [23:40] <FrEaKmAn_> ow [23:41] <iive> keyframes are like jpeg pictures, the p and b frames add only the difference from the already decoded frames. [23:41] <iive> if you don't start decoding at keyframe, you would be getting quite funny result. [23:41] <FrEaKmAn_> so I have to define vcodec everytime? [23:41] <c_14> Until the next keyframe anyway. [23:41] <c_14> No. [23:42] <c_14> Unless you want to reencode. [23:42] <FrEaKmAn_> I dont [23:42] <FrEaKmAn_> just want to cut the file [23:43] <FrEaKmAn_> so what do you suggest? [23:44] <c_14> You could just change your first command to ffmpeg -i video.mp4 -t 20 -c:v libx264 -c:a aac -strict -2 -y video_out.mp4 [23:44] <c_14> Assuming you want to reencode in that step. [23:44] <c_14> If you don't, use: ffmpeg -i video.mp4 -t 20 -c copy -y video_out.mp4 [23:45] <iive> first cut, then reencode. [23:45] <c_14> you can reencode and cut in the same step. [23:47] <FrEaKmAn_> ok [23:47] <FrEaKmAn_> the point is I want to encode only once [23:47] <FrEaKmAn_> and cut multiple times [23:47] <FrEaKmAn_> and cutting has to be fast [23:48] <FrEaKmAn_> if I cut and reencode, then it's kinda slow [23:48] <FrEaKmAn_> I just don't understand [23:48] <FrEaKmAn_> c_14: If you don't, use: ffmpeg -i video.mp4 -t 20 -c copy -y video_out.mp4 [23:48] <FrEaKmAn_> video.mp4 is already encoded? [23:49] <FrEaKmAn_> or I must encode video_out.mp4? [23:49] <iive> then set -keyint 25 to have keyframe every second. compression would suffer, but you'd have 1sec precise cutting points. [23:52] <FrEaKmAn_> hm.. same results [23:53] <FrEaKmAn_> http://pastie.org/private/tceebf77bsv6zsdidixlg [23:55] <c_14> hmm, can't see why it would desync [23:56] <FrEaKmAn_> me2 [23:56] <FrEaKmAn_> as I said, audio is ok [23:56] <FrEaKmAn_> video is totally incorrect [00:00] --- Sun Jul 27 2014

1 0