Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

January 2016

1 participants
62 discussions

ffmpeg-devel.log.20160110
by burek 11 Jan '16

11 Jan '16

[00:32:58 CET] <cone-478> ffmpeg 03Timothy Gu 07master:53d6bf662773: avf_showspectrum: Silence "deprecated pixel format" warning [00:36:40 CET] <ubitux> tmm1: yeah please submit the remaining patches [00:36:55 CET] <ubitux> ah you just did, great, th [00:36:57 CET] <ubitux> thx [00:58:22 CET] <tmm1> thanks for the review and merges! [01:37:18 CET] <cehoyos> kierank; Hi, I am all for splitting patches, but this can also be done in one commit;-) [01:37:27 CET] <cehoyos> Can you comment on my smpte patch? [01:37:28 CET] <kierank> I was asked to have the patch split [01:37:37 CET] <cehoyos> Do you know what it is about? [01:38:03 CET] <kierank> I don't really know why there needs to be a smpte special mode [01:38:06 CET] <cehoyos> (Because I only know a user sent me such a file and claims it does something useful for him.) [01:38:17 CET] <cehoyos> Did you see the thread on -users? [01:38:23 CET] <cehoyos> For SDI [01:38:57 CET] <cehoyos> I suspect, the normal eac3-in-spdif mode has a too high bitrate (192kHz stereo) [01:39:21 CET] <kierank> I can send you the spec [01:39:30 CET] <cehoyos> Not IEC please [01:39:32 CET] <kierank> smpte [01:39:37 CET] <cehoyos> But if you have another one: Yes, please! [01:39:42 CET] <cehoyos> Cool! [01:39:57 CET] <cehoyos> I couldn't find the number the user mentioned. [01:40:01 CET] <kierank> it's 337 [01:40:04 CET] <kierank> he made a mistake [01:40:10 CET] <kierank> 337/338/339 are a series [01:40:52 CET] <cehoyos> In any case: You cannot test, can you? [01:41:42 CET] <kierank> no, I implemented it in our codebase and the scope just said "DOLBY" [01:42:08 CET] <kierank> I don't think I have the right licence to analyse the output [01:42:21 CET] <cehoyos> Concerning cineform: Did you test Bayer? [01:42:51 CET] <kierank> no I don't know how to decode that [01:42:53 CET] <kierank> bayer is not supported [01:43:40 CET] <kierank> If I have a sample that someone is sure is RGBA I can implement that [01:43:44 CET] <cehoyos> Bayer is supported or do I misunderstand? [01:43:48 CET] <atomnuker> kierank: calling malloc on every frame seems wasteful, perhaps use the init function (and reject or realloc if width or height change) [01:43:57 CET] <kierank> atomnuker: oh bugger forgot that bit [01:44:08 CET] <kierank> was mean to write that [01:44:12 CET] <kierank> cehoyos: no it is not supported [01:44:29 CET] <kierank> you say "support bayer" which is like saying "support yuv" or "support rgb" [01:44:33 CET] <kierank> there are lots of ways of storing bayer [01:44:45 CET] <cehoyos> You mean your decoder does not support four components or do you mean the Bayer support in FFmpeg is not compatible? [01:44:45 CET] <kierank> ffmpeg only supports a couple [01:45:00 CET] <kierank> I have no idea [01:45:06 CET] <kierank> because i don't know what the actual files are meant to look like [01:45:13 CET] <cehoyos> Can you explain how I can decode four components? I wasn't successful... [01:45:27 CET] <kierank> add an extra plane pointer I guess [01:45:43 CET] <cehoyos> I believe the user on trac can tell us / can provide useful samples. [01:45:52 CET] <cehoyos> As said, I failed;-( [01:50:23 CET] <kierank> basically change all the 3's into 4's in the decoder [01:50:51 CET] <kierank> but some files won't play afaik [01:50:55 CET] <kierank> they have more subbands that we support [02:00:03 CET] <cehoyos> Do you think that "aes3" would be a better name for the flag than "smpte"? [02:00:13 CET] <kierank> no it's a smpte mapping inside AES3 [02:00:28 CET] <cehoyos> I did confirm that "16" is indeed eac3 in S338 and Atrac in IEC [02:00:57 CET] <cehoyos> Both use identical Sync Words [02:02:08 CET] <kierank> yes it should be the same [02:02:15 CET] <kierank> but what pkt_offset does I dunno [02:03:40 CET] <kierank> ah [02:03:44 CET] <kierank> it's the repetition period [02:04:22 CET] <cehoyos> I am not sure my patch matches the spec but it matches the sample I have... [02:04:44 CET] <kierank> by my calculation the repetition should be 6144 [02:04:46 CET] <kierank> bytes [02:04:58 CET] <kierank> 24576 I have no idea what that means [02:05:00 CET] <cehoyos> The spec says "data bits in the burst_payload" [02:06:04 CET] <cehoyos> 24576 is spdif, 6144 is what I added for aes3/smpte [02:06:14 CET] <kierank> where does 24576 come from [02:06:27 CET] <kierank> seems like a random number [02:06:45 CET] <kierank> would be nice if these random numbers documented [02:06:51 CET] <kierank> 6144 = ( 1536 / 48000 ) * 48000 * 2 * 2 [02:06:57 CET] <cehoyos> It is the number now in spdifenc which is needed to mux eac3 to spdif [02:07:04 CET] <kierank> yes but it's plucked out of thin air [02:07:22 CET] <kierank> my calculation calculates the duration of an ac3 frame and thus the amount of space it takes up in pcm [02:07:28 CET] <cehoyos> No, you have to multiply 6144 by 4 because that is the IEC frame size or similar [02:07:38 CET] <cehoyos> But this is eac3 [02:07:44 CET] <kierank> same number of samples [02:07:49 CET] <kierank> afaik [02:07:54 CET] <kierank> iec frame size? [02:07:55 CET] <kierank> eh [02:07:59 CET] <cehoyos> In any case: I can tset spdif and it works. [02:08:03 CET] <cehoyos> I cannot test aes3 [02:08:11 CET] <kierank> yes but it's a number plucked from thin air [02:08:15 CET] <kierank> does 6144 not work with spdif? [02:08:46 CET] <cehoyos> But the aes3 spec requests "number of bits in burst_payload" and my patch writes "max bytes" [02:08:53 CET] <cehoyos> No, it does not work [02:09:12 CET] <cehoyos> Or I didn't find out how: But I have to specify 192kHz to have eac3 working [02:09:29 CET] <cehoyos> So you have to mulitply your above calculation with 4 iiuc [02:09:33 CET] <kierank> 48000 * 4 = 192 [02:09:37 CET] <kierank> so you have some bug somewhere [02:09:44 CET] <kierank> confusing bytes with 2 sample pairs [02:09:50 CET] <cehoyos> Please explain: Where is a bug? [02:09:59 CET] <kierank> random multiplications by 4 to make things work [02:10:00 CET] <cehoyos> Are you taliking of the existing code? [02:10:04 CET] <kierank> possibly [02:10:09 CET] <cehoyos> I would really like a comment about the new code from you! [02:10:18 CET] <cehoyos> That does not contain the number "24576" [02:10:29 CET] <kierank> " ctx->pkt_offset = 24576;" [02:10:37 CET] <cehoyos> That is not part of my patch! [02:10:45 CET] <kierank> yes but it's cargo cult programming [02:10:49 CET] <kierank> numbers that happen to work [02:10:49 CET] <cehoyos> ctx->pkt_offset = 6144; [02:10:54 CET] <kierank> yes again cargo cult [02:11:00 CET] <kierank> you have no idea where 6144 came from [02:11:02 CET] <kierank> until I said so [02:11:04 CET] <cehoyos> Feel free to send a patch to change it, I will test it. [02:11:16 CET] <cehoyos> I did no, sorry to tell you. [02:11:27 CET] <kierank> then why did you not comment it [02:11:30 CET] <cehoyos> I would just like to discuss new code, not (working) old code! [02:11:43 CET] <kierank> instead of in 10 years someone trying to figure out where the hell you got 6144 from [02:11:50 CET] <cehoyos> Because I did not know the spec at the time that does not explain the value! [02:11:56 CET] <atomnuker> kierank: 6144? that number is the exactm maximum amount of bits per frame allowed in aac [02:12:02 CET] <kierank> atomnuker: go away [02:12:06 CET] <kierank> totally irrelevant [02:12:20 CET] <atomnuker> just saying I recognize the number [02:12:25 CET] <cehoyos> I got it from the sample I have, the spec requires "ctx->length_code = ctx->hd_buf_filled*8" or similar [02:12:27 CET] <kierank> I recognise the number 5 as well [02:12:39 CET] <kierank> number of fingers on my hand [02:13:05 CET] <cehoyos> And it is the number of max bytes in a ac3 apdif frame and an eac3 aes3 frame. [02:13:32 CET] <kierank> yes but the point is you know but the code doesn't explain where random numbers from [02:13:54 CET] <atomnuker> 6144 comes directly from the specs in aac, maybe it's the same here? [02:14:07 CET] <kierank> no stop talking about nonsense atomnuker [02:14:12 CET] <kierank> it's a different codec [02:14:17 CET] <kierank> you are like Compn [02:14:20 CET] <cehoyos> It cames directly from the IEC spec. [02:14:24 CET] <cehoyos> (here) [02:14:44 CET] <kierank> what document [02:16:31 CET] <cehoyos> IEC 61937-2 [02:16:53 CET] <cehoyos> Table 2 [02:17:01 CET] <cehoyos> Could we get back at the topic, please? [02:17:51 CET] <cehoyos> If IEC defines "16" as ATRAC in spdif and SMPTE as eac3 in aes3, is it ok to add a flag "smpte" to activate the aes3 mode? [02:18:03 CET] <kierank> yes [02:18:52 CET] <cehoyos> Cool, hopefully the user is going to test it: I wonder if he was pissed because of my commet about smpte for defining identical numbers with different meaning... [02:19:02 CET] <kierank> not sure that's the case [02:19:57 CET] <kierank> but I don't have iec docs [02:19:58 CET] <cehoyos> For 16 it is... [02:20:37 CET] <cehoyos> eac3 in 21 in iec, but that is incompatible because it is 4 times bigger, they should have used another identifier. [02:22:10 CET] <kierank> ok [02:23:36 CET] <kierank> f [02:41:06 CET] <Compn> lol time to pile on kierank [02:41:13 CET] <Compn> kierank : delete system32 [02:41:27 CET] Action: Compn runs [02:54:07 CET] <kierank> so any volunteers to write cfhd simd? [03:04:06 CET] <atomnuker> is it not fast enough? [03:26:02 CET] <kierank> on some files, no [03:37:12 CET] <kierank> jamrial: how can i turn multiple statements into a switch [03:43:42 CET] <kierank> guess I could just make it an if else... [03:43:49 CET] <jamrial> if (abs_tag range check) { } else { switch (tab) } else if (abstag range check) { } else { switch (tab) } [03:43:52 CET] <jamrial> i think [03:44:10 CET] <jamrial> assuming those abstag checks must be where they are [03:45:33 CET] <jamrial> or maybe that wouldn't work, mmh... [03:48:31 CET] <jamrial> can't you just put every tag check together into a single switch statement, with the two abstag range checks inside the default case? [03:51:14 CET] <J_Darnley> kierank: i'll stick it on the bottom of my figurative todo list [04:35:45 CET] <dinux> i want to be a contributor to ffmpeg . But I am a new comer :) [04:36:30 CET] <J_Darnley> What do you want to do? What can you do? [04:36:54 CET] <Compn> dinux5 : can you do simd code optimizations ? [04:39:23 CET] <dinux5> can you tell me what it is about? [04:40:14 CET] <Compn> taking c code and writing asm from it [04:40:29 CET] <dinux5> J_Darnley: I am good at C/C++ :) [04:41:43 CET] <J_Darnley> That's a good start. [04:42:33 CET] <J_Darnley> If you want to learn assembly then I think writing SIMD functions is a god way to learn it. [04:42:47 CET] <jamrial> dinux5: best way to start would be familiarizing yourself with the code. look at existing codecs, formats and filters, see if you can improve/extend any or writing a new one [04:42:51 CET] <Compn> j-b : we need someone to help organize small projects for newcomer developers.... [04:43:02 CET] <jamrial> alternatively check http://trac.ffmpeg.org/ and see if you find a bug you can fix [04:44:10 CET] <jamrial> or yes, look at existing assembly files and try to learn how to write sse/avx SIMD code [04:45:15 CET] <dinux5> jamrial: alright.I will do it .Thank you for the link :) [04:45:32 CET] Action: J_Darnley goes to bed. [04:48:19 CET] <dinux5> Also if not confidential may i know if this summer ffmpeg will apply for opw? As I am interested in working on this :) [04:49:18 CET] <Compn> i think we would need a sponsor for opw, i'm not sure if one has been located yet [04:49:34 CET] <Compn> cant remember how opw works... [04:50:39 CET] <dinux5> yes there will be a sponsor most probably..thats right :o [04:52:11 CET] <cone-327> ffmpeg 03Michael Niedermayer 07master:42c54d4cc3ab: avcodec/codec_desc: Add ff_aac_profiles to aac_latm [04:53:31 CET] <Compn> dinux5 : if you can learn ffmpeg and maybe submit a patch to fix some code, that would increase your chances of getting picked, should ffmpeg be in opw anyway. at the very least you would learn open source software collaboration to which you could use those skills on any other opw project... [04:54:37 CET] <dinux5> Compn: that's true . [04:54:58 CET] <Compn> or if you've worked on open source projects before , then you dont need to do that :P [04:58:32 CET] <dinux5> Umm..i opened the link : http://trac.ffmpeg.org/ .. but where do i head to find a code containing a bug ? [04:58:58 CET] <dinux5> most of them are documentations [04:59:55 CET] <Compn> click "view tickets" [04:59:56 CET] <Compn> top right [05:00:05 CET] <Compn> or click http://trac.ffmpeg.org/report [05:00:17 CET] <Compn> er http://trac.ffmpeg.org/report/1 [05:02:46 CET] <dinux5> so here tickets implies issues ? is it so? [05:03:37 CET] <jamrial> bugs or feature request, usually [05:05:12 CET] <jamrial> the tickets are color coded based on priority (minor, major, etc), or if they are a feature request/enhancement [10:06:11 CET] <durandal_1707> how to call filter that do V-A using spectrogram to synth sound? [11:26:26 CET] <michaelni> spectrosynth ? [13:00:07 CET] <cone-578> ffmpeg 03Michael Niedermayer 07master:e273dade7894: avcodec/mss2: Check for repeat overflow [14:08:14 CET] <cone-578> ffmpeg 03Clément BSsch 07master:a43deea8614a: lavc/ccaption_dec: fix ASS tags [14:24:27 CET] <cone-578> ffmpeg 03Marton Balint 07master:fdb2d4b1084c: lavf/concatdec: do not access packet if av_read_frame returned error [14:26:53 CET] <cone-578> ffmpeg 03Carl Eugen Hoyos 07master:f587ed0cbbda: lavc/x264: Add compatibility values for coder options. [16:13:11 CET] <cone-578> ffmpeg 03Michael Niedermayer 07master:d86d7b2486cd: avcodec/mjpegdec: Fix negative shift [16:28:22 CET] <cone-578> ffmpeg 03Clément BSsch 07master:6d32628bf349: lavc/ccaption_dec: improve default style [16:31:35 CET] <cone-578> ffmpeg 03Clément BSsch 07master:79061bcec121: fate: fix sub-cc font [17:25:53 CET] <cone-578> ffmpeg 03Michael Niedermayer 07master:030c7f0309ec: avcodec/g2meet: Check for ff_els_decode_bit() failure in epic_decode_run_length() [17:29:45 CET] <durandal_1707> I did spectrumsynth and quality is good considering 8bit input, but I have clicks [17:57:38 CET] <cone-578> ffmpeg 03Michael Niedermayer 07master:93ac72a98dff: avcodec/dvdec: Fix "left shift of negative value -254" [19:50:11 CET] <cone-578> ffmpeg 03Michael Niedermayer 07master:590863876d14: avcodec/aacdec_template: Check id_map [23:11:17 CET] <ubitux> tmm1: so can't you handle the italic and underline with something like if (style & (1<<0)) av_bprintf(... "{\\i%d}", ...); if (style & (1<<1)) av_bprintf(... "{\\u%d}", ...) [23:11:18 CET] <ubitux> ? [23:51:04 CET] <durandal_1707> yes, I finally got it [23:56:02 CET] <jamrial> got what? [23:58:06 CET] <durandal_1707> jamrial: ifft in spectrumsynth [00:00:00 CET] --- Mon Jan 11 2016

1 0

ffmpeg.log.20160110
by burek 11 Jan '16

11 Jan '16

[01:49:09 CET] <xintox> . [01:49:12 CET] <xintox> woops [01:49:17 CET] <xintox> #h4kr [02:10:48 CET] <JustinBieber> so to use rubberband filter I have to install librubberband ? is it separate library or it ships with ffmpeg ? I have ffmpeg-2.3 does it support rubberband ? [02:11:17 CET] <c_14> The rubberband filter is relatively new. [02:11:20 CET] <c_14> Probably only 2.8 up [03:05:51 CET] <Pinchiukas> Anyone can help me with http://video.stackexchange.com/questions/17371/random-errors-from-ffprobe ? [03:58:23 CET] <qxt> I need to encode video for some html5 sites I am working on. What format is the most supported by browsers? There is mp5, H.254 and webm. I [03:59:13 CET] <qxt> mp4 sry* A few years back I used vp8 and vorbis for stuff. Not sure how things are now. [04:00:30 CET] <qxt> I hear webm is not supported by Microsoft and Apple. Is this true? Have not used MS or Apple since about 1995 [04:03:49 CET] <qxt> mp4, h.264 and vp8 *this keyboard is way small* [04:16:15 CET] <Kieran> Hello everyone! [04:33:16 CET] <Uhkam> Hi, anyone able to give an assistance here? [04:44:20 CET] <Soni> any youtubers which use ffmpeg for editing their videos? [07:25:47 CET] <Logicgate> what should be the maximum size of a 7 second 720p video? [07:26:45 CET] <c_14> 39MiB [07:26:49 CET] <c_14> eh, ne [07:26:54 CET] <Logicgate> roughly right? [07:26:55 CET] <Logicgate> okay cool [07:27:06 CET] <c_14> 462MiB [07:27:29 CET] <c_14> That would be uncompressed [07:27:59 CET] <Logicgate> I thought it was roughly 2megabits per second no? [07:28:45 CET] <Logicgate> The H.264 standard defines maximum bit rates for 1280x720@30fps as between 14.000 and 42.000 kbit/s, depending on the profile (baseline, main, high etc.)? [07:29:41 CET] <c_14> You never told me what video codec you were using so I used uncompressed video as that is the maximum upper limit. [07:29:47 CET] <c_14> well [07:29:51 CET] <c_14> reasonable upper limit [07:31:22 CET] <Logicgate> what would be the reasonable upper file size limit? [07:31:42 CET] <Logicgate> 720x720 @ 25fps using H.264 with 128kbps audio [07:36:29 CET] <c_14> Depends on how high you push the bitrate [07:36:51 CET] <c_14> Anything from 1MiB to 400MiB [07:37:00 CET] <Logicgate> Lol jesus [07:37:18 CET] <Logicgate> Would giving users 50mb be reasonable? [07:37:37 CET] <c_14> probably [07:38:05 CET] <c_14> most streaming is between 2 and 5 thousand kb so for a 7s video that should be around 14-35MiB [07:38:14 CET] <c_14> eh [07:38:16 CET] <c_14> MB [07:40:05 CET] <Logicgate> Alright, thank you c_14 [07:52:48 CET] <jafa> are there docs or a recommended way to compile ffmpeg to work with qt5 on windows platform? [07:53:49 CET] <jafa> I tried compiling under msys2 configuring ffmpeg for target-os=mingw32 [07:54:27 CET] <jafa> compiles fine but crashes in weird ways at runtime [07:55:19 CET] <jafa> most commonly the app terminates and the qt debugger simply reports that the app terminated (no error) [08:43:45 CET] <jafa> if I use Zeranoe FFmpeg pre-compiled builds it works fine [08:51:42 CET] <jafa> ah, looks like they are cross-compiled from linux. will try [11:02:57 CET] <vapashos> hello everyone i'd like to ask a question about how to create an avc bitstream from a .yuv file using ffmpeg [12:34:57 CET] <relaxed> vapashos: look at ffmpeg -h demuxer=rawvideo , you have to tell the rawvideo demuxer how to handle the input [13:04:37 CET] <thetrueavatar> Hello [13:05:07 CET] <thetrueavatar> I need some help to encode in x265 with ffmeg and preset file. Can anybody help me please ? [13:07:08 CET] <thetrueavatar> here is my cli command: ffmpeg -i "Kyrielle montage tout OK.avi" -c:a copy -c:v libx265 -vpre veryslow "outFile.mkv" [13:07:26 CET] <thetrueavatar> and it says File for preset 'veryslow' not found [13:07:44 CET] <relaxed> change it to -preset veryslow [13:07:47 CET] <thetrueavatar> I have tried with -preset but it doesn't seems to use it [13:07:55 CET] <thetrueavatar> it only do quantizer 0 by default [13:08:01 CET] <thetrueavatar> whatever the string is used [13:08:04 CET] <relaxed> oh, it's x265 [13:08:34 CET] <relaxed> https://trac.ffmpeg.org/wiki/Encode/H.265 [13:08:52 CET] <thetrueavatar> indeed I didn't try to encode directly with x265 cli. Will read your link [13:09:07 CET] <relaxed> well, I meant libx265 [13:09:38 CET] <thetrueavatar> I'm working on linux so I have build all by myself [13:09:39 CET] <relaxed> from the wiki it looks like -preset should work. Which ffmeg version are you using? [13:09:46 CET] <thetrueavatar> 2.8.4 [13:10:06 CET] <thetrueavatar> I took the source code from the site [13:10:10 CET] <thetrueavatar> here is my configuraitoin [13:10:27 CET] <thetrueavatar> --prefix=/home/clibois/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/home/clibois/ffmpeg_build/include --extra-ldflags=-L/home/clibois/ffmpeg_build/lib --bindir=/home/clibois/bin --enable-gpl --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libvorbis --enable-libx264 --enable-libx265 --enable-nonfree [13:11:24 CET] <thetrueavatar> I don't have any error but quantizer is set to 0(lossless) [13:11:54 CET] <relaxed> try -x265-params preset=veryslow [13:11:58 CET] <furq> thetrueavatar: -x265-params crf=28 [13:12:33 CET] <furq> i'm not sure why the default would be lossless though [13:12:56 CET] <furq> afaik the default is -b:v 200k [13:12:58 CET] <thetrueavatar> ah wait I see [13:13:12 CET] <thetrueavatar> q=-0.0 [13:13:56 CET] <thetrueavatar> preset veryslow only set ration to 28 ? [13:14:20 CET] <furq> preset shouldn't affect the crf at all [13:14:43 CET] <furq> crf should (in theory) result in the same quality regardless of other settings [13:16:02 CET] <JEEB> no [13:16:07 CET] <JEEB> crf depends on preset [13:16:31 CET] <JEEB> because crf depends on the internals that switch between presets [13:16:33 CET] <thetrueavatar> maybe it just a display problem cause bitrate is rather slow for a quantizer 0. [13:16:58 CET] <thetrueavatar> there is a - before the 0.0 of the q=-0.0 [13:18:13 CET] <thetrueavatar> however bitrate of 200kbits seems rather low for a 1080p resolution.... [13:19:04 CET] <furq> thetrueavatar: 200k is the default if you don't specify a bitrate/crf/etc [13:19:18 CET] <furq> that doesn't mean it's a good default [13:19:47 CET] <thetrueavatar> well it start à 50 and ramp up progressively. Now I'm a t 321kbits/s [13:20:12 CET] <thetrueavatar> and I guess that's the role of the preset to define crf no ? [13:22:55 CET] <furq> thetrueavatar: http://x265.readthedocs.org/en/default/presets.html [13:24:47 CET] <thetrueavatar> According to your link don't see why I should set crf [13:24:56 CET] <thetrueavatar> ". When you use slower presets, x265 tests more encoding options, using more computations to achieve the best quality at your selected bit rate (or in the case of crf rate control, the lowest bit rate at the selected quality)." [13:25:11 CET] <thetrueavatar> ah [13:25:46 CET] <thetrueavatar> that's a bit weird that x264 doens't need any crf defintion and x265 should [13:25:56 CET] <furq> x264 defaults to crf 23 [13:26:11 CET] <furq> in ffmpeg, i mean [13:26:53 CET] <thetrueavatar> ok didn't know [13:27:10 CET] <furq> actually it looks like x264 itself does [13:27:32 CET] <thetrueavatar> will read a bit more about crf to fully understand how it works. Thanks [13:27:36 CET] <furq> which i guess explains why ffmpeg has a sensible default for x264 and not for most other codecs [13:28:54 CET] <thetrueavatar> well it's written that default crf should be 28 according to https://trac.ffmpeg.org/wiki/Encode/H.265 [13:29:38 CET] <thetrueavatar> ah maybe I misread. They say that in the example they will use default crf à 28... [13:31:25 CET] <thetrueavatar> Tried ffmpeg -i "Kyrielle montage tout OK.avi" -c:a copy -c:v libx265 -preset veryslow -x265-params crf=28 "outFile.mkv" [13:31:29 CET] <thetrueavatar> but still same result [13:33:30 CET] <thetrueavatar> frame= 366 fps=2.2 q=-0.0 size= 611kB time=00:00:14.90 bitrate= 335.7kbits/s [13:35:07 CET] <furq> that works for me [13:35:35 CET] <thetrueavatar> Here is the complete stack(in cas I missed something) [13:35:59 CET] <thetrueavatar> I will pm you with this cause it's a bit lonbg [13:36:13 CET] <furq> pastebin it [13:36:34 CET] <furq> i've never encoded x265 until about a minute ago to test if that command worked [13:38:30 CET] <thetrueavatar> http://pastebin.com/raw/XEktNCMe [13:38:40 CET] <thetrueavatar> http://pastebin.com/XEktNCMe [13:38:55 CET] <furq> x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60 [13:39:04 CET] <furq> that looks like it's working to me [13:39:25 CET] <furq> if it's a static title card or something then 400kbps is totally feasible for 1080p [13:39:25 CET] <thetrueavatar> indeed. [13:39:57 CET] <thetrueavatar> ok so there just a littlbe display bug in ffmpeg which is showing me q=-0.0 [13:40:40 CET] <furq> also it looks like -crf 28 works now [13:41:28 CET] <thetrueavatar> in fact it was working with preset only [13:41:52 CET] <thetrueavatar> I'm a begginer with ffmpeg and x265 cli. Used to encode with megui on windows :-) [13:42:09 CET] <furq> if you can figure out megui then ffmpeg should be simple [13:42:32 CET] <furq> megui's ui is loathsome [13:43:33 CET] <thetrueavatar> well I used to choose a preset in the ui so never really looked at each configuration checkbox [13:43:55 CET] <furq> i tried it again recently because i wanted to use an avisynth script (qtgmc) [13:44:00 CET] <furq> that was a waste of two hours [13:44:33 CET] <thetrueavatar> don't think that avisynth script still worth trying cause there is no more resizing and no more mpeg2 noise to filter. [13:44:50 CET] <furq> i was ripping a poorly deinterlaced dvd [13:45:00 CET] <thetrueavatar> ah indeed with that kind of source... [13:45:11 CET] <furq> i still technically am because i haven't ripped it yet [13:45:28 CET] <thetrueavatar> btw afair there was a nice gui tool for avisynth script [13:46:41 CET] <thetrueavatar> AVISynth UI if I remember well [13:46:52 CET] <thetrueavatar> there was a nice preview option [13:47:11 CET] <furq> i'm probably just going to wait for someone to add qtgmc to handbrake [13:47:22 CET] <furq> by which i mean add it to ffmpeg [13:48:22 CET] <thetrueavatar> qtmc is an avisynth editor ? [13:48:38 CET] <furq> it's a fancy deinterlace filter [13:49:03 CET] <thetrueavatar> ah ok [13:49:44 CET] <thetrueavatar> handbrake is using ffmpeg for encoding ? [13:50:04 CET] <furq> i think it uses libav* directly [13:50:25 CET] <furq> i only use it because it handles PGCs and chapters correctly [13:50:26 CET] <thetrueavatar> However i don't see any possibility to chosse an avisynth script [13:51:40 CET] <thetrueavatar> my little boy is crying. will have to leave. thanks for the help [14:00:04 CET] <grublet> what command line would i need to be able to split an audio file based on timecodes stored in a text file? [15:59:31 CET] <bazingirno> can x265 act as "drop in" where h.265 is used? Need to do some html5 stuff. [15:59:48 CET] <furq> did you mean h.264 [16:00:39 CET] <furq> if so then no [16:00:52 CET] <bazingirno> no mean the new stuff but I would think I am asking the same with x264 vs h264 [16:01:12 CET] <furq> x265 is an h265 encoder [16:01:17 CET] <furq> likewise with x264 [16:01:29 CET] <furq> but h265 isn't supported by any browsers yet [16:02:11 CET] <bazingirno> just tried some vp9 stuff and it worked nice with FF. But vp9 is not h265. [16:02:17 CET] <furq> it sure isn't [16:02:46 CET] <furq> for html5 video your choices are h264, vp9, vp8 or theora [16:02:55 CET] <furq> in descending order of how much you'd want to use them [16:03:17 CET] <bazingirno> wonder what the new standard will be for html5. vp9 did not work with Edge [16:03:30 CET] <bazingirno> in the past I would use vp8 and vorbis [16:03:34 CET] <furq> http://caniuse.com/#feat=webm [16:03:34 CET] <bazingirno> with webm [16:03:38 CET] <bazingirno> lol yeah [16:03:44 CET] <JEEB> MS is going to integrate libvpx or libavcodec for VP9 [16:03:45 CET] <furq> edge and safari don't support vp8 either afaik [16:03:45 CET] <JEEB> and opus [16:03:48 CET] <JEEB> for edge [16:04:00 CET] <JEEB> I would guess libvpx even though it's slower [16:04:11 CET] <JEEB> due to its license being less restrictive than lavc's [16:04:22 CET] <JEEB> (zomg I have to publish the source code for a library I use) [16:04:23 CET] <bazingirno> omgz... why cant MS and Apple stop being dicks and just work with ppl [16:04:30 CET] <JEEB> lol [16:04:35 CET] <JEEB> I'd push that straight onto google [16:04:43 CET] <JEEB> for making those formats behind closed doors [16:04:53 CET] <JEEB> there's a reason why they're not standard formats [16:05:01 CET] <bazingirno> Reason I no w only buy Nexus stuff [16:05:03 CET] <JEEB> because they were never made a standard [16:05:06 CET] <bazingirno> I now* [16:05:10 CET] <JEEB> or as a standard [16:05:20 CET] <JEEB> as a complete bystander I could register onto jct-vc mailing list [16:05:31 CET] <JEEB> and look through what they were and are doing with HEVC [16:05:36 CET] <furq> they're all as bad as each other [16:05:38 CET] <JEEB> (which is also known as H.265) [16:05:56 CET] <JEEB> meanwhile G is just doing it the way On2 was doing it, it seems [16:06:03 CET] <JEEB> no specs and the impplementation is the spec [16:06:29 CET] <JEEB> also doing On2 like marketing and thrusting non-technical topics into I think IETF (?) technical meetings [16:06:54 CET] <JEEB> I was really ready to give G a chance after VP8 until VP9 came out [16:07:01 CET] <JEEB> then they just did the same thing with VP9 [16:07:03 CET] <JEEB> and I went meh [16:07:22 CET] <JEEB> VP8 was inherited from On2 so I was OK with there being issues in how it was created etc [16:07:26 CET] <furq> i look forward to the new open media alliance codec and the exciting ways in which i won't be able to use it because of lack of support [16:08:18 CET] <bazingirno> Reading up a little on this as we speak. Seems MS is going to start using VP9 with Edge in the next big "update" or w/e they call it [16:08:33 CET] <furq> good luck getting apple to use anything other than h.264 [16:08:41 CET] <JEEB> they are not starting to use it, they're just going to enable support [16:08:53 CET] <JEEB> also rather than VP9 I'm more interested in how they're also going to enable Opus [16:09:03 CET] <JEEB> which is a pretty cool audio format [16:09:23 CET] <JEEB> but yes, your iOS devices will still not handle it and mobile devices in general have almost no available HW decoding for VP9/8 [16:10:19 CET] <JEEB> and of course for VPx to be used anywhere you have to have a working rate control, which IIRC libvpx doesn't still properly have [16:10:26 CET] <JEEB> because 'tube doesn't need it [16:10:36 CET] <JEEB> (they have their own wrapper that handles that) [16:11:45 CET] <bencoh> ondemand OTT streaming :] [16:12:02 CET] <JEEB> I fucking hate that wording [16:12:03 CET] <JEEB> so marketing [16:12:22 CET] <Soni> any youtubers which use ffmpeg for editing their videos? [16:12:38 CET] <bencoh> me too, but that's exactly what youtube is, and that's probably why they never bothered writing a working rate control [16:13:01 CET] <JEEB> bencoh: no they do have rate control... it's just not in the public [16:13:12 CET] <JEEB> which is why the public library doesn't have it :P [16:13:34 CET] <bencoh> JEEB: does it work, or is it just in the same state as the one in x265 (not really working)? ;) [16:13:53 CET] <bencoh> (not expecting you to answer since you dont have the source either :) [16:14:32 CET] <JEEB> pretty sure even with all the fuck-ups libx265's rate control works better than libvpx's [16:14:39 CET] <JEEB> (both being public) [16:15:01 CET] <JEEB> I think the main problem was that some options you'd expect to be wired weren't in the libavcodec wrapper [16:15:18 CET] <JEEB> so you had to input them in the straight-to-library key-value thing [16:15:33 CET] <bencoh> even with those, x265 rc didnt work properly [16:15:33 CET] <JEEB> that said, I haven't exactly tested the VBV too hard [16:16:19 CET] <bencoh> vbv was always a tad wrong and we had to drop a few packets here and there (strict cbr mux) [16:16:50 CET] <JEEB> ok [16:16:58 CET] <JEEB> glad someone is testing it [16:17:04 CET] <bencoh> I havent tried for 6 months though [16:17:10 CET] <Soni> how do I put a video stream over another video stream? [16:17:20 CET] <bencoh> (it was at previous $job) [16:18:02 CET] <JEEB> that sounds about right for me as well, although I had no intention of actually checking if the thing was exact [16:18:10 CET] <JEEB> as long as it was close enough [16:18:33 CET] <JEEB> my own private tests usually just poke at crf without VBV [16:21:03 CET] <relaxed> Soni: https://ffmpeg.org/ffmpeg-filters.html#overlay-1 [16:29:02 CET] <Soni> relaxed, thanks [16:29:11 CET] <Soni> any youtubers which use ffmpeg for editing their videos? [16:31:43 CET] <DHE> plenty. why? [16:37:22 CET] <Soni> cool [16:37:34 CET] <Soni> can I use ffmpeg for livestreaming? [16:38:07 CET] <DHE> well, yes, but it's a question of what other software goes with it. nginx-rtmp, or some dumb http server (apache or nginx again) for serving HLS or DASH are the open source options [16:39:12 CET] <DHE> ffmpeg does have ffserver but it's not really that great [16:41:53 CET] <Soni> I see [16:42:36 CET] <Soni> and how do I screen capture with ffmpeg? [16:47:56 CET] <paule32> Soni: use vlc [16:48:19 CET] <paule32> else x11grab, [17:30:56 CET] <ethe> Soni: which os? [17:45:24 CET] <Soni> ethe, linux [17:46:49 CET] <ethe> then as paule32 said, use x11grab. here's screen capture with ffmpeg (using x11grab): http://wiki.oz9aec.net/index.php/High_quality_screen_capture_with_Ffmpeg [18:53:03 CET] <thetrueavatar> I'm just back to transcoding for an almost 7 year's break. If you have any technical source to help me to fill the gap feel free ^^ [18:54:01 CET] <thetrueavatar> I found on doom9 the following Russian comparaison of most recent codec: http://compression.ru/video/codec_comparison/hevc_2015/MSU_HEVC_comparison_… [18:55:25 CET] <JEEB> x264 is still the thing to use except for testing and cases where you want to push rates so down that it would look bad with any format. You can do best scaling and colorspace conversions with anything based on the zimg library (which is used by the zscale filter in FFmpeg) [18:55:44 CET] <JEEB> libx265 will take a lot of time and still has issues with random detail drop even with relatively high rates [18:56:23 CET] <JEEB> also they haven't gotten the psychovisual optimizations done for the delicious part of HEVC, which is coding tree units bigger than 16x16 [18:56:59 CET] <JEEB> unless you are encoding for plastic hardware boxes, 10bit libx264 is a deffo recommendation [18:59:47 CET] <thetrueavatar> ok. By scaling your mean resizing(1080p->720p) ? [19:01:30 CET] <JEEB> and converting from 8bit YCbCr to 10bit or so etc [19:01:39 CET] <JEEB> or between BT.709 and BT.2020 or BT.601 [19:03:39 CET] <thetrueavatar> to be honest I don't know what's 8bit YCbr is [19:04:43 CET] <thetrueavatar> BTW if you have any teorical explanation about encoding(with math no problem) this will definitevly interest me [19:06:11 CET] <JEEB> something like http://lurkertech.com/lg/video-systems/ ? [19:06:34 CET] <JEEB> not exactly encoding, but video systems [19:07:19 CET] <furq> are there significant advantages to 10bit x264 with 8bit sources [19:07:39 CET] <thetrueavatar> that seems to be a good start. [19:07:40 CET] <JEEB> depends on your source, and the advantages are in compression anyways [19:07:46 CET] <thetrueavatar> thanks [19:07:51 CET] <furq> yeah i'm reading that it compresses better but i can't imagine it makes that big a difference [19:07:54 CET] <JEEB> since you start losing less in gradients and other similar things [19:08:03 CET] <furq> ah [19:08:15 CET] <JEEB> and in general makes a similar error smaller [19:08:18 CET] <JEEB> since you've got more bits [19:08:32 CET] <furq> let's see if i even have 10bit support [19:08:33 CET] <JEEB> depending on source it's somewhere around 5-10% or even more [19:08:40 CET] <JEEB> forget about it with hardware [19:08:48 CET] <furq> i meant in this build of ffmpeg [19:08:58 CET] <JEEB> it's there from around 2011 [19:09:09 CET] <thetrueavatar> is 10bit the defaut for x264 preset veryslow ? [19:09:11 CET] <furq> is it just -profile high10 [19:09:17 CET] <JEEB> unless you specifically disabled it which was created due to needs from the chromium project [19:09:31 CET] <JEEB> no, you can only encode 10bit with a 10bit libx264 and only 8bit with a 8bit one [19:09:37 CET] <JEEB> you don't have to specify anything [19:09:42 CET] <JEEB> thetrueavatar: no [19:09:49 CET] <furq> well yeah that's what i meant [19:10:04 CET] <thetrueavatar> you're working too on chromium ? [19:10:09 CET] <JEEB> no [19:10:24 CET] <JEEB> the reason why you can disable 10bit and some other features in lavc's AVC decoder is because of them [19:10:33 CET] <JEEB> because they wanted to minimize the binary size [19:10:47 CET] <JEEB> that said, almost no-one does that and I'm actually not sure if that patching got into upstream FFmpeg [19:11:14 CET] <furq> https://ffmpeg.zeranoe.com/blog/?p=435 [19:11:16 CET] <furq> oh neat [19:11:20 CET] <furq> i guess i'll give that a try then [19:11:50 CET] <JEEB> you'd probably want a build with zimg in it so you don't have to go through swscale [19:11:53 CET] <furq> i can't imagine player support is noticeably worse than for regular high profile [19:11:58 CET] <thetrueavatar> ok so I have to rebuild my ffmpeg to use 10bit decoder... [19:12:08 CET] <JEEB> thetrueavatar: yours is older than 2011? [19:12:19 CET] <thetrueavatar> no just build it yesterday [19:12:35 CET] <JEEB> then unless you specifically disabled features in the AVC decoder you have the decoder just fine [19:12:46 CET] <JEEB> it's the encoder which you can only have either bitness of linked in [19:12:59 CET] <thetrueavatar> I ment encoder [19:13:19 CET] <furq> i should probably figure out why compiling fdk-aac crashed msys2 and compile it myself [19:13:34 CET] <furq> but i've spent too much of my life fixing msys' bullshit [19:14:16 CET] <thetrueavatar> I'm trying to shrink the size of a 3000kbits 1080p personal videot(1h43) [19:14:26 CET] <JEEB> that's already relatively low bit rate [19:14:28 CET] <furq> 3000? [19:14:59 CET] <JEEB> 3 mbits is not that much given what kind of results the commercial or hardware encoders give [19:15:00 CET] <thetrueavatar> 3310 to be exact [19:15:09 CET] <furq> yeah that seems very low already [19:15:41 CET] <thetrueavatar> well that's 3.5gb and wanted to compress it because it seems to be to big for my dnla server [19:16:01 CET] <thetrueavatar> and btw I try to use x265 for fun [19:16:04 CET] <furq> downscaling to 720p is probably your best bet if you don't want to murder the image quality [19:16:26 CET] <JEEB> thetrueavatar: x265 is "OK" but very slow and can lose random details [19:16:42 CET] <thetrueavatar> that was one of my question. Is it better to downscale or to rise quantize ? [19:16:45 CET] <JEEB> definitely lacks the love that x264 got community-wise [19:17:00 CET] <furq> i guess you could try x265 veryslow if you have a couple of days to spare [19:17:13 CET] <thetrueavatar> that's exactly what I'm doing... [19:17:27 CET] <furq> personally i would downscale it, but then i downscale all my 1080p content [19:17:32 CET] <thetrueavatar> 10 minutes for a 6 hour encoding on a core I7 haswell [19:17:34 CET] <furq> i don't have any screens big enough to notice the difference [19:18:22 CET] <JEEB> well 1080p at 3mbits... there's probably not even enough details there :P [19:18:29 CET] <thetrueavatar> I'm a bit surprise that the bitrate is less than 1K [19:18:39 CET] <thetrueavatar> during x265 encoding. [19:18:41 CET] <furq> if the dlna server is choking on the filesize then you could try splitting it [19:18:42 CET] <JEEB> that's because you've set the rate control to what you've set [19:18:52 CET] <thetrueavatar> crf 28 [19:18:56 CET] <JEEB> nowadays encoders don't really struggle at hitting any target [19:18:57 CET] <furq> but if it can't handle a 3.5GB video file then you've got bigger problems [19:19:15 CET] <JEEB> (except maybe sub-audio-track rates with 1080p30 or so) [19:19:17 CET] <thetrueavatar> it's running on my nas [19:19:21 CET] <thetrueavatar> so cpu is... [19:19:27 CET] <furq> oh [19:19:45 CET] <furq> well x265 decoding takes more cpu than x264 [19:20:02 CET] <thetrueavatar> I know that's juste for the fun this encodig ^^ [19:20:02 CET] <furq> downscaling will definitely help if you're cpu-bound [19:20:15 CET] <JEEB> anyways, you should pick a few scenes (overall like 2500-5000 pictures with 24p) and decide which crf value to use [19:20:29 CET] <JEEB> after that you can do the long encode with that [19:20:41 CET] <JEEB> additionally I definitely recommend building x265 with high bit depth support enabled [19:20:47 CET] <JEEB> 10bit helps there as well [19:21:03 CET] <thetrueavatar> this is a private concert so there are a lot of dark part [19:21:36 CET] <JEEB> ugh, that sounds like the 3mbps "source" that you have is really bad to begin with [19:21:45 CET] <JEEB> concert and only 3mbps at 1080p [19:22:19 CET] <JEEB> of course downscaling to 720p would help there to alleviate the fact that there's not much crap left to encode [19:22:22 CET] <thetrueavatar> well that's stupid they made a 1080p h264 video with a small 256kbit mp3.... [19:22:44 CET] <thetrueavatar> I would have tought that dark would help encoding ? [19:23:00 CET] <furq> depends how dark [19:23:13 CET] <JEEB> well dark or not dark there probably at some point were details [19:23:15 CET] <JEEB> if not, sure [19:23:26 CET] <furq> if "private" implies that it was filmed with one static camera then that will help bitrate a lot [19:23:51 CET] <furq> also 256k mp3 is pretty good these days, especially LAME [19:24:13 CET] <furq> it wouldn't be my first choice though [19:24:16 CET] <thetrueavatar> yep you'r right I tought public would be completely black but no there are too many details [19:25:03 CET] <thetrueavatar> Well if I had to record a concert I would definitively try to get the best codec and bitrate for sound... [19:25:44 CET] <thetrueavatar> maybe in lossless mode [19:27:57 CET] <thetrueavatar> is it a special git branch for 10bit x264 ? [19:29:10 CET] <JEEB> no [19:29:13 CET] <JEEB> just a configure parameter [19:29:25 CET] <thetrueavatar> ah ok [19:29:44 CET] <thetrueavatar> we're talking of linux's configure ? [19:29:47 CET] <JEEB> same with x265 [19:29:54 CET] <JEEB> uhh, software configuration when you build it :P [19:31:03 CET] <thetrueavatar> so definitively ./configure on linux :p [19:31:39 CET] <JEEB> not limited to of course [19:31:46 CET] <JEEB> same scripts are also used on other systems [19:32:41 CET] <thetrueavatar> ok will sto my x265 encoding since anyway I must work with my latop tomorow ^^ [19:32:58 CET] <thetrueavatar> Will give a try with x264 10bit and 720p scaling [19:34:14 CET] <thetrueavatar> do I need to rebuild ffmepg or only libx264 ? [19:34:27 CET] <JEEB> both [19:34:39 CET] <thetrueavatar> ok ^^ [19:45:42 CET] <thetrueavatar> Nothing special to configure on ffmpeg build to support 10 bit ? Just build x264 with 10 bit enable ? [19:56:47 CET] <JEEB> and x265 with high bit depth support if you want to use that encoder as well [19:57:05 CET] <JEEB> also as I noted you'll want to build with the zscale filter enabled as well [19:57:09 CET] <JEEB> which bases on the zimg library [19:57:15 CET] <JEEB> https://github.com/sekrit-twc/zimg [20:09:59 CET] <thetrueavatar> oki thanks !! [20:10:23 CET] <thetrueavatar> there is no way to use avisynth script with ffmpeg ? [20:10:41 CET] <JEEB> sure is, but I'd rather use vapoursynth and vspipe myself [20:11:04 CET] <JEEB> native high bit depth support and all those goodies [20:11:18 CET] <thetrueavatar> ah that's new for me vapoursynth [20:11:27 CET] <thetrueavatar> replacement of avisynth ? [20:11:32 CET] <JEEB> that said if you're just rescaling and doing bit depth conversions zscale/zimg is also usable from FFmpeg [20:11:46 CET] <JEEB> a cross-platform similar thing that tries to fix a lot of the design issues in avs [20:12:03 CET] <JEEB> avs was very much bound to the VFW system's limitations [20:12:22 CET] <JEEB> and never had proper support for stuff like timestamps and high bit depth [20:12:40 CET] <JEEB> avs still has a bigger legacy, but I finally switched my (mostly test) encodes to vs last year [20:13:03 CET] <JEEB> there was quite a bit of work done to have the primary things available [20:13:42 CET] <JEEB> that said, vs or avs are just extra complexity if you are doing something simple :P [20:14:54 CET] <thetrueavatar> that's rigth since there is no need to clean grain from source as it used to be with mpeg2 [20:16:40 CET] <thetrueavatar> if source is 8 bit I need to convert it ? [20:17:01 CET] <JEEB> yeah [20:17:24 CET] <JEEB> also zimg does the image processing in higher bit depth in genera and tries to be as correct as possible [20:17:43 CET] <JEEB> I think the only negative thing was that the colorimetry metadata didn't get passed on so you'd have to set that in the encoder manually [20:18:14 CET] <JEEB> but that's an issue with the zscale filter in FFmpeg, not zimg itself [20:18:39 CET] <thetrueavatar> zscale is another thing to compile and configure or is it embedded in ffmpeg ? [20:18:51 CET] <JEEB> zimg is a library that the zscale filter uses in FFmpeg [20:18:58 CET] <JEEB> I linked the repo to zimg [20:19:10 CET] <thetrueavatar> ah ok [20:19:19 CET] <thetrueavatar> ok I have already build it [20:19:33 CET] <JEEB> then you just have to enable the zscale filter in your FFmpeg configuration [20:19:37 CET] <thetrueavatar> so there is no special configuration for build with zscale [20:19:42 CET] <thetrueavatar> ok ^^ [20:20:13 CET] <JEEB> I was happy recently as vapoursynth switched from swscale based scaling and colorspace conversion to zimg based [20:20:33 CET] <JEEB> no need to get scaling plugins for general scaling/colorspace conversion [20:20:44 CET] <JEEB> swscale being the old thing in FFmpeg [20:21:06 CET] <JEEB> made in a different time where doing realtime conversions on CPU was already a feat [20:21:44 CET] <thetrueavatar> do you know where I cand find documentation about configuration parameter ? [20:21:50 CET] <thetrueavatar> to build ffmpeg [20:22:00 CET] <JEEB> ./configure --help [20:22:05 CET] <thetrueavatar> lool [20:22:09 CET] <JEEB> although generally you don't need the kitchen sink [20:22:30 CET] <JEEB> you generally need just the stuff that gets enabled by default and maybe some very specific things that you might be using [20:22:49 CET] <JEEB> decoder-wise you should always be set, thus leaving pretty much encoders being the thing you require [20:23:01 CET] <JEEB> (and zscale nowadays as an exception) [20:24:07 CET] Action: llogan has yet to try zscale [20:24:53 CET] <JEEB> zimg should be rather well threadable etc, but I haven't done any calculations of how effective the libavfilter scaler is [20:25:00 CET] <thetrueavatar> Not sure to understand. You mean that I don't neeed zscale to scale down my source and convert it to 10bit ? [20:25:02 CET] <JEEB> also it'd be nice to get the colorimetry passed on [20:25:25 CET] <JEEB> thetrueavatar: it's not *required* , but if you're gonna build a new FFmpeg anyways, better take the better way :P [20:25:41 CET] <JEEB> swscale is what it is and I like using it less and less [20:25:50 CET] <thetrueavatar> ok. Sorry for all those questions. I'm really a newbie with ffmpeg :p [20:26:40 CET] <thetrueavatar> hum don't find any option to use zimg/zscale. only found an option to disable swscale :p [20:27:10 CET] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L275 [20:27:48 CET] <thetrueavatar> hum weird I didn't had this in my ./configure --help [20:28:06 CET] <thetrueavatar> or didn't see it ... [20:28:11 CET] <JEEB> then you're building an old version, most probably [20:28:28 CET] <JEEB> in FFmpeg the standard is that you look at the latest FATE results and use the latest git master that passes it [20:28:35 CET] <JEEB> (for your architecture(s)) [20:29:01 CET] <thetrueavatar> I have downloaded source from ffmpeg.org, I didn't took them from git ... [20:29:46 CET] <JEEB> then check what on earth you downloaded :) [20:30:09 CET] <thetrueavatar> well will take source from git... [20:30:30 CET] <JEEB> the github is just a mirror btw, the git.videolan.org one is the main repo atm [20:30:38 CET] <JEEB> just that it's prettier to link at it @ github [20:30:44 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=summary [20:31:05 CET] <thetrueavatar> https://github.com/FFmpeg/FFmpeg ? [20:31:23 CET] <llogan> the github may lag behind [20:31:52 CET] <thetrueavatar> http://ffmpeg.org/releases/ffmpeg-2.8.4.tar.bz2 << that's what I took [20:31:54 CET] <thetrueavatar> before [20:31:56 CET] <JEEB> well yeah [20:32:03 CET] <JEEB> that will not have among other things the zscale filter [20:32:23 CET] <JEEB> releases happen every now and then and the project is very moving [20:33:07 CET] <llogan> thetrueavatar: releases are targeted towards distributors and the paranoid. general users are encouraged to use a build from current git master if possible [20:33:37 CET] <llogan> releases don't usually get backports of new features that appear after the release [20:34:16 CET] <thetrueavatar> indeed with master source code I got the option [20:35:01 CET] <JEEB> generally you can see how broken FFmpeg currently is for your architecture/OS by looking at FATE results. but that is no different between releases and random versions from git [20:35:11 CET] <JEEB> FATE being http://fate.ffmpeg.org/ [20:35:27 CET] <JEEB> let's just say that a lot of stuff gets tested [20:36:00 CET] <thetrueavatar> fate is a kind of integration testing tools ? [20:36:19 CET] <thetrueavatar> like like hudson/jenkins in the java world ? [20:36:24 CET] <JEEB> not that much really, although there's nowadays tests run via the API [20:36:41 CET] <JEEB> a) do things build b) do specific tests pass on various architectures/OSs [20:38:29 CET] <thetrueavatar> well guess that on linux/X86 this should be ok [20:40:26 CET] <JEEB> yeah, the 64bit variety of that is most tested [20:41:12 CET] <thetrueavatar> you mean linux 64 bit ? [20:41:24 CET] <JEEB> intel arch 64bit linux, yes [20:41:45 CET] <thetrueavatar> I'm still on 32bit cause 3 years ago using 64 bit was a real nightmare for me [20:41:48 CET] <JEEB> I generally just check that the tests aren't currently failing when updating stuff for various purposes :) [20:42:18 CET] <thetrueavatar> you don't have an automatic mail that say "hey guys this man broke everything" ? :p [20:42:38 CET] <JEEB> people usually notice it pretty well :) [20:42:45 CET] Action: JEEB has only broken FATE once [20:43:31 CET] <thetrueavatar> there is not kind of unit testing done in this project ? [20:43:50 CET] <JEEB> well the newer API tests are closer to that [20:44:00 CET] <JEEB> generally it's testing of if specific input gives specific output [20:44:09 CET] <thetrueavatar> I'm working in the JAVA/JEE env so don't know how it works in the c world ^^ [20:44:14 CET] <xintox> what's the best way to restart ffmpeg without causing stream interruption? [20:44:50 CET] <BtbN> Well, don't restart it if you don't want to interrupt it. [20:45:18 CET] <JEEB> thetrueavatar: after you build stuff you can run `make fate` given that you have the FATE sample set somewhere [20:45:29 CET] <xintox> BtbN: i have to sometimes...but is there anyway to cause it to not drop? I don't care if it flickers or whatever, but right now all the players stop playing it completely. [20:45:43 CET] <thetrueavatar> ok. ffmpeg is in oo or pure c ? [20:45:51 CET] <JEEB> pure C, not like it stops OO though [20:45:57 CET] <JEEB> OO is just a paradigm [20:46:14 CET] <BtbN> xintox, you can't exit an application without it closing all its sockets. [20:46:17 CET] <thetrueavatar> yes I know just asking if it was c++ with oo [20:46:33 CET] <JEEB> C++ is not liked in the multimedia circles [20:46:40 CET] <JEEB> you will be accepted if your API is C though [20:46:50 CET] <JEEB> like zimg and some other things have [20:47:16 CET] <JEEB> the one time I broke FATE was due to output of a filter in between not being bitexact though, so I broke everything but optimized intel arch nîn [20:47:43 CET] <JEEB> (someone reviewing my patch told me to remove flags from tests which I didn't know of - one of which was bitexact) [20:47:47 CET] <thetrueavatar> well if you don't have any inheritance mechanism in the language I don't see how to do OO ^^ [20:48:14 CET] <JEEB> structs that have similar function pointers? [20:48:52 CET] <thetrueavatar> Ok forget that structure things. My level of c is close to zero tbh [20:49:31 CET] <JEEB> but yeah, C++ can in some things be useful, which is why some libraries use it. the main thing is that they have C interfaces that they can be used through [20:50:28 CET] <llogan> relaxed: looks like a user is having an issue with one of your builds: http://superuser.com/questions/1024300/ffmpeg-alsa-audio-capture-not-working [20:51:13 CET] <thetrueavatar> ok ffmpeg build with all the stuff. any documentation pointer to scaling - 10bit conversion ? [20:52:24 CET] <JEEB> -vf zscale=w=1280:h=720,format=yuv420p10 [20:52:25 CET] <thetrueavatar> found for zscale. Will look for 10 bit conversion [20:52:31 CET] <thetrueavatar> how nice ^^ [20:53:33 CET] <JEEB> the format is a separate filter but it's a funky one, it basically gives the requirement for the preceding filter. if it can't be done, it will plug in an swscale filter automagically [20:54:09 CET] <thetrueavatar> arf ffmpeg: error while loading shared libraries: libzimg.so.2: cannot open shared object file: No such file or directory [20:54:19 CET] <thetrueavatar> Id dit make install tough [20:54:28 CET] <JEEB> run ldconfig as root [20:54:49 CET] <thetrueavatar> nothing ... [20:54:59 CET] <JEEB> (I will implicitly think that you make installed into a directory which is indexed) [20:55:33 CET] <thetrueavatar> hum if I did it was totally unintended... :p [20:55:53 CET] <JEEB> if not you will have to either add the directory into /etc/ld.so.conf.d/ as a file (and run ldconfig) or use LD_LOAD_PATH (I think that was the env var) [20:56:10 CET] <JEEB> ok, it ws LD_LIBRARY_LOAD_PATH [20:56:29 CET] <JEEB> it's usually simpler to add things to /etc/ld.so.conf.d though if you have custom prefixes [20:56:30 CET] <c_14> Wasn't it just LD_LIBRARY_PATH? [20:56:43 CET] <JEEB> don't remember to be honest :P [20:56:53 CET] <JEEB> I switched to adding things to ld.so.conf.d recently [20:57:11 CET] <c_14> I just build statically or set LD_RUN_PATH before compiling [20:57:27 CET] <JEEB> yeah, static compilation is another thing I often do [20:57:33 CET] <thetrueavatar> I thinkg I forgot to mention --enable-static in the configure... [20:58:06 CET] <c_14> --enable-static doesn't help if one of the dependencies only has dynamic libraries [20:59:16 CET] <thetrueavatar> ok my library is in /usr/local/lib like the other... [21:02:20 CET] <thetrueavatar> ok nevermind probably due to my command line completely wrong(write -v:code instead of -c:v...) [21:02:55 CET] <thetrueavatar> ok encoding running. Thanks a lot for all this help [21:05:41 CET] <thetrueavatar> hum q=40.0 with ffmpeg -i "Kyrielle montage tout OK.avi" -c:a copy -c:v libx264 -preset veryslow -vf zscale=w=1280:h=720,format=yuv420p10 "Kyrielle montage tout OK.mkv" [21:05:46 CET] <thetrueavatar> what's the catch ? [21:06:14 CET] <thetrueavatar> I tougth default crf was 23 [21:07:35 CET] <c_14> 10-bit x264 might have a different default. At the very least the crf range is different [21:08:33 CET] <JEEB> the crf default is the same [21:08:40 CET] <JEEB> q value has nothing to do with it [21:08:45 CET] <JEEB> the crf range is different [21:08:51 CET] <JEEB> (goes to negative) [21:09:39 CET] <thetrueavatar> oki tought quantizer and crf was an exact matching [21:09:55 CET] <JEEB> nope [21:10:12 CET] <JEEB> the whole idea of CRF is to be more intelligent than "static" quantizers [21:10:16 CET] <thetrueavatar> is quantizer variable with a given crf ? [21:10:24 CET] <JEEB> of course [21:10:24 CET] <thetrueavatar> ah ok so quantizer is adaptive [21:10:38 CET] <JEEB> it's adaptive within the picture (AQ) as well as between pictures [21:11:05 CET] <furq> thetrueavatar: -qp is constant quantiser mode [21:11:18 CET] <JEEB> or -q:v [21:11:23 CET] <furq> i don't think anyone uses it outside of -qp 0 [21:11:31 CET] <JEEB> but you shouldn't use it for anything else but zero, which is lossless with all bit depths [21:11:36 CET] <JEEB> (with libx264/x265) [21:11:47 CET] <JEEB> yeah, it should only be used for development [21:11:47 CET] <furq> is that the only difference between -qp 0 and -crf 0 [21:11:51 CET] <JEEB> yes [21:12:00 CET] <thetrueavatar> btw is encoding an x264 video with an x265 lossless can be smaller ? Just theorical question [21:12:00 CET] <JEEB> crf 0 is only lossless when 8bit x264 is used [21:12:23 CET] <JEEB> the lossless value would be some negative value with >8bit [21:12:31 CET] <JEEB> so it's simpler to just use -q:v [21:13:05 CET] <thetrueavatar> is there any definition/explanation on how crf works ? [21:13:34 CET] <thetrueavatar> don't hesitate to tell me "just google it" if it's obvious [21:14:41 CET] <llogan> libx264 ignores -q:v [21:15:50 CET] <JEEB> really? [21:16:42 CET] <llogan> i think so. i didn't look at the code, but lazily did -f md5 [21:18:32 CET] <JEEB> ok, seems like only x4->cqp is looked [21:18:34 CET] <kepstin> tbh, i'm kind of surprised that crf wasn't mapped to -q:v in ffmpeg [21:18:54 CET] <kepstin> but whatever, too late to change that now :) [21:18:56 CET] <JEEB> I kind of understand the reason for it since back in the day -q:v was "the thing" for MPEG-4 Part 2 based encoders [21:19:28 CET] <JEEB> and some people truly thought it meant quality [21:20:59 CET] <thetrueavatar> JEEB: You told me quantizer was dynamically adapted but I see a constant q=40.0. Is q the quantizer ? [21:21:12 CET] <kepstin> thetrueavatar: 'crf' stands for 'constant rate factor'; the way 2-pass x264 works is that it analyzes the video to determine the "constant rate factor" necessary to get a video with constant perceptual quality throughout at the requested bitrate. [21:21:36 CET] <thetrueavatar> I tought crf was in one pass in fact... [21:21:37 CET] <kepstin> thetrueavatar: it just happens that it made a decent way to do quality-based 1-pass encodes too, so it was exposed for that [21:21:53 CET] <kepstin> but it's originally an internal implementation detail of 2-pass mode [21:22:02 CET] <jonascj> I fail at getting a ~10sec clip from a video: "ffmpeg -ss 00:06:10 -i input.mp4 -vcodec copy -acodec copy -to 00:06:25 output.mp4" gives me 6min of video, not 15sec. What am I doing wrong? [21:22:13 CET] <JEEB> thetrueavatar: you shouldn't look into the q value at all [21:22:37 CET] <JEEB> as long as you see that your selected crf value is used in libx264's output, that should be it [21:22:42 CET] <furq> jonascj: specify -ss as an output option or add -copyts as an output option [21:22:58 CET] <jonascj> furq: so specify -ss after -i? [21:23:16 CET] <furq> if the start point is already correct with -ss as an input option then use -copyts [21:23:22 CET] <furq> -ss as an output option is slower [21:23:24 CET] <kepstin> jonascj: when -ss is used as an input option, timestamps are rewritten to start at 0 (unless you use -copyts) [21:23:43 CET] <jonascj> oh, I see, that is why it fails. [21:23:53 CET] <jonascj> (or why I fail) [21:23:56 CET] <c_14> Or use -t instead of -to [21:23:56 CET] <thetrueavatar> VBR is only usefull to get a given average bitrate or a fixed size ? Right ? [21:24:22 CET] <furq> thetrueavatar: no? [21:24:24 CET] <c_14> You mean ABR or CBR? [21:24:44 CET] <kepstin> technically using x264 with -crf gives you vbr output... [21:24:54 CET] <furq> "technically" [21:25:23 CET] <jonascj> -ss after -i solved the problem. -t instead of -to did as well. [21:26:04 CET] <thetrueavatar> isn't vbr not always ABR ? Since it's adapt bitrate to get given size ? [21:26:56 CET] <furq> targeting a given size is abr [21:26:57 CET] <kepstin> vbr just means that individual frames/packets/whatever aren't constrained to be the same size [21:27:12 CET] <furq> if you're not targeting a given size (e.g. with -crf) then it's just vbr [21:27:39 CET] <thetrueavatar> ah ok it was misconception of mine [21:29:16 CET] <thetrueavatar> ok after all that knowledge transfer need to eat ^^ [22:36:12 CET] <thetrueavatar> still someone there ? Still got some questions ? [22:36:20 CET] <thetrueavatar> :p [22:38:07 CET] <thetrueavatar> Was wondering if there was a way to speed encoding with some kind of gpu hardware encoding ? For instance, I got a NAS with a dedicated chip for encoding/decoding [22:39:28 CET] <tdr> not unless you can feed that NAS code to execute [22:40:08 CET] <JEEB> do note that none of the ASIC encoders are there for high compression ratio encoding [22:40:21 CET] <JEEB> it's usually to get a some sort of picture out with low latency [22:42:58 CET] <furq> thetrueavatar: there are ways but you can't use them to speed up x264 encoding [22:43:18 CET] <furq> they use their own encoders which are generally (always?) of a lower quality [22:43:59 CET] <furq> you can do opencl lookahead in x264 now but that's of questionable utility [22:44:13 CET] <furq> and also i can't imagine you have a good enough gpu in your nas [22:44:23 CET] <thetrueavatar> there is a dedicated chip [22:44:39 CET] <thetrueavatar> intel evansport [22:44:44 CET] <JEEB> basically if you don't want high compression, sure. some ASICs are usable [22:44:58 CET] <JEEB> but as I noted, they're not there for high compression style of encoding [22:45:11 CET] <furq> yeah as JEEB said it's mostly useful for low latency encoding [22:45:15 CET] <furq> they're not really suitable for general use [22:45:21 CET] <thetrueavatar> that can transcode vc1-clip to h264 1080p [22:45:34 CET] <JEEB> do you even read what's being told? [22:46:00 CET] <furq> ignore the thing i said about opencl, i know you're talking about a dedicated asic [22:46:14 CET] <thetrueavatar> euh you'r talking to me ? [22:46:17 CET] <furq> yes [22:46:28 CET] <thetrueavatar> I was askinhg to JEEB ^^ [22:46:35 CET] <furq> i'm pretty sure he was as well [22:47:27 CET] <thetrueavatar> Not sure what you mean by High compression then. [22:47:52 CET] <JEEB> high compression ratios [22:48:08 CET] <JEEB> 23:41 < JEEB> do note that none of the ASIC encoders are there for high compression ratio encoding [22:48:11 CET] <JEEB> 23:41 < JEEB> it's usually to get a some sort of picture out with low latency [22:48:25 CET] <JEEB> as you noted there you were using a slow x264 preset I'm pretty sure what you were trying to do is that [22:49:05 CET] <JEEB> the ASICs can give you a good picture but the amount of bit rate they require is much more than even the faster presets of x264 (in general) [22:49:22 CET] <thetrueavatar> ok now I get it [22:49:24 CET] <furq> i'd expect it to be better than x264 ultrafast but not much [22:49:38 CET] <furq> does ffmpeg even support quicksync yet [22:49:44 CET] <JEEB> yeah [22:49:45 CET] <thetrueavatar> that's because there is a ffmpeg install by default on the nas [22:49:48 CET] <JEEB> also nvenc [22:50:01 CET] <c_14> quicksync is a pain though [22:50:06 CET] <c_14> nvenc is much easier to use [22:50:15 CET] <JEEB> on linux, that is [22:50:26 CET] <JEEB> anyways, those are generally there for the people who want throwaway encodes quickly [22:50:29 CET] <c_14> never tried on windows [22:50:31 CET] <furq> there's an open bug but it looks like it just refers to decoding and preprocessing [22:50:41 CET] <thetrueavatar> so I tought it could be mapped to the hardware chip. Didn't think chip had his own embedded encoder [22:51:03 CET] <furq> you're not doing x265 encoding on evansport are you [22:51:05 CET] <JEEB> would have to have much more traffic between the ASIC and the CPU then [22:51:10 CET] <thetrueavatar> no not that crazy [22:51:35 CET] <JEEB> although it depends, basically in theory you could outsource CABAC or so, but I'm really not sure if that's the bottleneck :P [22:52:00 CET] <furq> x264 is slow enough on my core 2 duo nas [22:52:13 CET] <JEEB> you'd only want to outsource things that aren't worse off than what you'd have in software basically [22:52:57 CET] <thetrueavatar> beside converting the concert of my wife, I wanted to automatically convert every video done by my camera but it was slow as hell [22:53:06 CET] <furq> x264 is pretty fast anyway [22:53:47 CET] <thetrueavatar> I wanted to automatically convert this video by my nas upon rsync my video with my sd card [22:54:20 CET] <thetrueavatar> I know I want to do a lot of things ^^ [22:54:28 CET] <furq> well yeah you can do that [22:54:39 CET] <furq> but you'll have to either encode on an atom or use quicksync's encoder [22:54:58 CET] <furq> neither of which sound like great options but ymmv [22:56:38 CET] <thetrueavatar> as said encoding with the atom cpu is slooooow. Will check if it's worth trying to dig into quicksync's encoder [00:00:00 CET] --- Mon Jan 11 2016

1 0

ffmpeg-devel.log.20160109
by burek 10 Jan '16

10 Jan '16

[00:05:41 CET] <ubitux> tmm1: did you read the README from the hackipedia.org link? [00:07:40 CET] <ubitux> anyway, 'night [00:57:37 CET] <tmm1> michaelni: can you revert fe225b113 to fix fate, and then i'll re-roll my patchset off master for ubitux to review tomorrow [01:02:31 CET] <cone-686> ffmpeg 03Ricardo Constantino 07master:be0f005da639: configure: Use libgcrypt-config's cflags [01:07:35 CET] <tmm1> or i'll just fix it and he can merge that in, i guess it doesn't matter [02:38:38 CET] <Compn> anyone want to burn the samples to a disc and mail them to guy requesting them ? [02:38:47 CET] <Compn> (someone asked webmaster@ for a copy of samples repo on disc) [02:39:21 CET] <Compn> theres at least 60gb , i'm guessing more like 80gb now), so that would be a dozen dvd or couple blurays [02:40:07 CET] <BtbN> One BR i think? [02:40:53 CET] Action: Compn only sees 25gb bluray discs [02:41:00 CET] <BtbN> There are 100GB ones [02:41:06 CET] <Compn> oh i see :) [02:41:22 CET] <BtbN> They are kinda rare and expensive though [02:41:31 CET] <BtbN> Might be cheaper to just by a 128GB SD card [02:41:35 CET] <BtbN> +u [02:41:59 CET] <BtbN> lol, yeah. _one_ 100GB BD-R is 50¬ [02:42:45 CET] <Compn> looks like $21 per disc, according to amazon shipping direct from japan :D [02:43:10 CET] <Compn> http://www.amazon.com/gp/offer-listing/B0041CJMRU/condition=new [02:43:37 CET] <BtbN> A 128GB micro-SD is 40¬ [02:43:48 CET] <nevcairiel> why would we bother to fullfill that request, he could easily find someone with internet and have them download it for cheaper =p [02:44:04 CET] <Compn> he said he would pay for it [02:44:14 CET] <Compn> some people like taking small jobs. i dunno ... [02:44:27 CET] <BtbN> Did he mention where in the world he is? [02:44:50 CET] <Compn> nope [02:45:05 CET] Action: Compn stalks internet [02:45:31 CET] <Compn> no, no idea [02:57:45 CET] <J_Darnley> Wait, which samples are we talking about? Fate is <1G [03:05:47 CET] <Compn> entire samples.ffmpeg.org [03:06:19 CET] <BtbN> why oO [03:06:51 CET] <Compn> we get many requests per year to grab all samples. many reasons, usually testing some video equipment they have made or purchased [03:08:28 CET] <Compn> national library of australia asked, utc aerospace employee, western digital tv employee.... [03:09:15 CET] <BtbN> And they can't just download it? Or are they just beeing polite about not wanting to stress the samples server? [03:09:22 CET] <Compn> china edu student asked so he could add it to "fuzzing corpus" [03:09:29 CET] <Compn> BtbN : http://samples.ffmpeg.org/00-README [03:09:39 CET] <Compn> our readme says to ask because it may stress the server, correct [03:11:09 CET] <J_Darnley> Well I can't make good on that offer. I would need to download it first. [03:12:07 CET] <Compn> its never been a problem, so everyone who has asked gets permission [03:14:01 CET] <BtbN> the bwlimit also seems kinda outdated [03:14:12 CET] <Compn> its an old message. [03:14:17 CET] <Compn> how long would 50g take at 50k/s ? [03:14:22 CET] <BtbN> couple days [03:23:55 CET] <Compn> 96G unified/ [03:24:01 CET] <Compn> ah yes. 96 gigs of samples now [03:30:16 CET] <J_Darnley> That would take 22 days at 50KB/s [03:32:09 CET] <Compn> lol [03:58:31 CET] <cone-686> ffmpeg 03Michael Niedermayer 07master:6e249466cc6b: avformat/movenc: Check that pkt duration is within 32bit range [05:10:20 CET] <tmm1> ubitux: looks like my assumptions were all wrong so i reverted the last few commits and started over: https://github.com/tmm1/ffmpeg/compare/master...upstream-cc-2 [06:51:28 CET] <ubitux> tmm1: ah, i like this better [06:52:45 CET] <ubitux> yay font styles [06:53:43 CET] <ubitux> is CCFONT_UNDERLINED_ITALICS really supposed to be in the enum? [06:54:06 CET] <ubitux> it really looks like CCFONT_ITALICS|CCFONT_UNDERLINED :p [06:54:19 CET] <ubitux> (1|2==3) [07:02:59 CET] <prelude2004c> hey, trying to get an answer on ffmpeg for the last few days..anyone here know the quick answer ? " hey everyone.. anyone know why when i record PVR my PVR STart TIME is a negative value ? something to do with -ss ? seeking ? how do i prevent it from being negative and make sure the recording always starts at 00:00:00 " [08:25:51 CET] <tmm1> ubitux: not sure [08:26:07 CET] <tmm1> probably doesnt belong lol [08:26:35 CET] <tmm1> ubitux: let me know if anything needs tweaking, i can rebase or edit before bed [08:26:45 CET] <tmm1> up for a little while longer [10:53:58 CET] <cone-809> ffmpeg 03Carl Eugen Hoyos 07master:836c79351471: lavc/libvpxenc: Improve documentation for option cpu-used. [10:56:25 CET] <ubitux> tmm1: i'm going to work on this now [10:56:37 CET] <ubitux> if you're available [12:33:38 CET] <cone-809> ffmpeg 03Aman Gupta 07master:23a50c8ab9fb: Revert "lavc/ccaption_dec: reap_screen is not necessary when clearing screen or buffer" [12:33:39 CET] <cone-809> ffmpeg 03Aman Gupta 07master:578b911b5ee1: Revert "lavc/ccaption_dec: implement "erase non displayed memory"" [12:33:40 CET] <cone-809> ffmpeg 03Aman Gupta 07master:2693275c02f8: Revert "lavc/ccaption_dec: reap_screen() is responsible for clearing output buffer and signaling screen_changed" [12:33:41 CET] <cone-809> ffmpeg 03Aman Gupta 07master:6049b15c0afc: lavc/ccaption_dec: combine ROLLUP modes as they are identical [12:33:42 CET] <cone-809> ffmpeg 03Aman Gupta 07master:8fd7f03c56f7: lavc/ccaption_dec: extract ass time base into constant [12:33:43 CET] <cone-809> ffmpeg 03Aman Gupta 07master:c75b86951626: lavc/ccaption_dec: rename screen_changed to buffer_changed [12:33:44 CET] <cone-809> ffmpeg 03Aman Gupta 07master:7def844be81b: lavc/ccaption_dec: centralize buffer_changed=1 into reap_screen [12:33:45 CET] <cone-809> ffmpeg 03Aman Gupta 07master:e521a32af273: lavc/ccaption_dec: clear buffer before populating with screen contents [12:33:46 CET] <cone-809> ffmpeg 03Aman Gupta 07master:080de371d8c0: lavc/ccaption_dec: extract capture_screen() for future use [12:33:47 CET] <cone-809> ffmpeg 03Aman Gupta 07master:811ce8f9c599: lavc/ccaption_dec: simplify by passing screen into write_char() [12:33:48 CET] <cone-809> ffmpeg 03Aman Gupta 07master:086093c77c71: lavc/ccaption_dec: simplify by incrementing cursor_column inside write_char() [12:33:49 CET] <cone-809> ffmpeg 03Aman Gupta 07master:b7e64be8fbf4: lavc/ccaption_dec: implement font styles [12:37:47 CET] <cone-809> ffmpeg 03Clément BSsch 07master:5ae07914d047: lavc/ccaption_dec: check for bprint completeness only at the end [12:37:48 CET] <cone-809> ffmpeg 03Clément BSsch 07master:d587fbb676a9: lavc/ccaption_dec: fix mixed declarations and code warning [12:39:01 CET] <cone-809> ffmpeg 03Clément BSsch 07master:31bff21d2c06: lavc/ccaption_dec: mark row and font as const in capture_screen() [12:41:26 CET] <cone-809> ffmpeg 03Clément BSsch 07master:22765140fa67: lavc/ccaption_dec: check for bprint completeness outside the loop [12:43:34 CET] <nevcairiel> so many commits for silly CCs [12:43:47 CET] <ubitux> :) [12:45:11 CET] <cone-809> ffmpeg 03Clément BSsch 07master:0948e0f553c0: lavc/ccaption_dec: simplify rollup cases [14:00:51 CET] <ubitux> rcombs: i need to patch ass_split [14:01:10 CET] <ubitux> you still have some pending stuff, right? [14:10:47 CET] <ubitux> nevcairiel: you used libzvbi sub decoder recently, didn't you? [14:13:19 CET] <ubitux> oh pkt duration is finally int64 nice [14:13:56 CET] <nevcairiel> i did not [14:17:31 CET] <ubitux> nevcairiel: ah... i thought there was some kind of timebase num/den + rescaling confusion [14:17:36 CET] <ubitux> well whatever [14:18:28 CET] <nevcairiel> atomnuker: the doc is clearly wrong, it says "profile: possible values: [...] aac_pred", which is clearly not a possible value for the profile, since no profile by that name exists, the profile is named aac_main [14:22:00 CET] <atomnuker> nevcairiel: grr, that was confusing [14:22:15 CET] <cone-809> ffmpeg 03Rostislav Pehlivanov 07master:ba4c2917ebee: doc/encoders: fix typo in AAC encoder documentation [14:22:17 CET] <nevcairiel> i should've just fixed =p [15:33:15 CET] <cone-809> ffmpeg 03Michael Niedermayer 07master:2039b3e7511e: avformat: Add integer fps from 31 to 60 to get_std_framerate() [16:03:46 CET] <ubitux> durandal_170: legend in showspectrumpic is pretty awesome [16:04:00 CET] <ubitux> for the lazy, http://b.pkh.me/rondo-spectrum.png [16:04:30 CET] <ubitux> 'love this (ffmpeg -i in.flac -lavfi showspectrumpic out.png) [16:05:39 CET] <J_Darnley> Impressive [16:05:49 CET] <nevcairiel> shouldnt frequency typically be on a log scale [16:06:09 CET] <ubitux> scale <int> ..FV.... set display scale (from 0 to 5) (default log) [16:06:16 CET] <ubitux> maybe the legend isn't correct ;) [16:06:18 CET] <J_Darnley> The markers on the axis could be more intelligently chosen I guess. [16:06:23 CET] <J_Darnley> *axes [16:06:35 CET] <nevcairiel> also your audio looks kinda crazy [16:06:41 CET] <nevcairiel> so many peaks in all sorts of frequencies [16:06:50 CET] <ubitux> yes that's curious [16:07:42 CET] <ubitux> http://b.pkh.me/april-spectrum.png [16:07:45 CET] <ubitux> here is another weird one [16:08:07 CET] <ubitux> maybe i should questioning my musical tastes [16:08:11 CET] <nevcairiel> haha [16:08:32 CET] <nevcairiel> you listen to full spectrum music, thats for sure =p [16:08:50 CET] <nevcairiel> audio up to 22kHz! [16:08:58 CET] Action: J_Darnley goes off to build [16:09:11 CET] <ubitux> http://b.pkh.me/feathers-spectrum.png [16:09:24 CET] <ubitux> i wonder if it's really correct [16:09:24 CET] <nevcairiel> i wonder if the output is really correct though [16:09:27 CET] <nevcairiel> heh [16:09:27 CET] <ubitux> :) [16:09:32 CET] <nevcairiel> that looks too weird [16:09:48 CET] <ubitux> yep [16:09:49 CET] <nevcairiel> shove a defined sine signal in it and see what happens [16:10:30 CET] <ubitux> http://b.pkh.me/sine-spectrum.png [16:10:40 CET] <nevcairiel> hm that looks as expected [16:10:40 CET] <ubitux> (-f lavfi -i sine=d=30 -lavfi showspectrumpic) [16:10:57 CET] <J_Darnley> Does ffmpeg have a sweep? [16:10:57 CET] <nevcairiel> a bit of aliasing, but that might just be lack of dithering [16:12:31 CET] <ubitux> you can get the flac i used by doing s/-spectrum.png/.flac/ [16:15:18 CET] <ubitux> (the only really weird one being april) [16:37:05 CET] <Compn> prelude2004c : you need to ask in #ffmpeg , not here. also you can probably fix it with one of the pts filters i forget the name either -vf genpts or -vf fixpts [16:38:02 CET] <durandal_170> vf compnts [16:52:59 CET] <cone-809> ffmpeg 03Sasi Inguva 07master:cbcc88c0393f: libvpx: Support setting color range for vp9. [17:13:00 CET] <BBB> jamrial: sorry about not pushing, I would have done it after 24 hrs but I was lazy [17:21:59 CET] <atomnuker> so what does the HAVE_FAST_64BIT flag indicate? [17:22:46 CET] <nevcairiel> if 64-bit integer math is fast [17:23:13 CET] <nevcairiel> in practice, if there are native 64-bit regs [17:24:01 CET] <nevcairiel> its generally used for optimizing bitmask shuffling and whatnot, so either one 64-bit value or two 32-bit ones, etc [18:58:08 CET] <kierank> so why does nonstatic tables crash frame threading? [19:27:55 CET] <kierank> fixed it seems [19:40:48 CET] <Timothy_Gu> J_Darnley: no but one can create one really easily with aevalsrc=sin(440*2*PI*t*t*t) [20:22:28 CET] <cone-637> ffmpeg 03Paul B Mahol 07master:cbad37e5bfe5: avfilter/avf_showspectrum: set color range to frame [20:45:51 CET] <tmm1> morning [20:48:10 CET] <tmm1> ubitux: looks like real time patch is still pending? [21:05:05 CET] <nevcairiel> so that guy posts the vaapi encoder patch agian, and none of the very obvious issues have been fixed [21:05:44 CET] <wm4> heh [21:07:07 CET] <fritsch> didn't he add sws_scale dependencies? [21:07:59 CET] <fritsch> perhaps someone should contact Bryan Christ if that guy even knows he is becoming a maintainer [21:08:01 CET] <nevcairiel> excuse me, he fixed one problem =p [21:08:14 CET] <fritsch> hehe [21:08:41 CET] <wm4> fritsch: yeah, seems to add libswscale deps (why) [21:08:51 CET] <wm4> not like it matters, but seems fishy [21:08:58 CET] <nevcairiel> because we told him his inline asm pixfmt conversion was a no go [21:09:00 CET] <nevcairiel> :D [21:09:07 CET] <fritsch> hehe [21:09:12 CET] <fritsch> exactly [21:09:43 CET] <fritsch> (const uint8_t * const*)frame->data [21:09:45 CET] <wm4> ... [21:12:04 CET] <durandal_170> just tell guy to forget about libVA [21:12:35 CET] <fritsch> that would be too easy [21:12:46 CET] <fritsch> if it really works, it would in deed be something nice for ffmpeg [21:12:51 CET] <fritsch> but only if it's maintainable of course [21:13:32 CET] <nevcairiel> vaapi works on which hardware, intel only? Just use qsv =p [21:13:38 CET] <fritsch> not really [21:16:54 CET] <rcombs> nevcairiel: but muh gpl [22:20:09 CET] <ubitux> tmm1: yes i wanted to discuss the flush patch first [22:20:19 CET] <ubitux> i think it's missing some stuff [22:20:47 CET] <ubitux> like, active_screen [22:21:07 CET] <ubitux> color and font maybe [22:21:30 CET] <ubitux> buffer_changed to 0 also maybe [22:21:49 CET] <ubitux> maybe they're not all relevant though [22:22:19 CET] <ubitux> also, for the ass thing, i don't think you can go up to 999 [22:22:35 CET] <ubitux> but if you look at the ml, there is a patchset to remove the timing from the payload [22:22:40 CET] <ubitux> so that won't be an issue anymore [22:24:06 CET] <ubitux> i'd be more comfortable if you send the real_time patch to the ml though [22:24:14 CET] <ubitux> some other ppl might want to discuss it [22:32:10 CET] <ubitux> tmm1: also, can't we have a realtime option that actually set the duration properly? [22:33:40 CET] <ubitux> (i mean additionally to the one you suggest) [22:40:06 CET] <tmm1> sure, i can send it to the list [22:40:43 CET] <tmm1> not sure how we would set duration though [22:44:14 CET] <tmm1> you need to buffer to know the end time, which means its not real time anymore [22:44:41 CET] <tmm1> ubitux: ill add color font and activescreen to flush [23:04:17 CET] <ubitux> tmm1: yes with buffering, it's fine [23:04:42 CET] <ubitux> but i'm curious about the effect of the text progressively appearing :p [23:05:04 CET] <ubitux> (even if it requires a first pass to extract the subs) [23:24:21 CET] <wm4> should a muxer be able to handle such events with unknown duration? [23:25:08 CET] <ubitux> depends on the muxer capabilities maybe [23:25:33 CET] <ubitux> subtitles are weird beasts anyway, to use nice words [23:28:16 CET] <wm4> yeah, it's like they consistently resist abstraction and elegance [23:31:54 CET] <kierank> yeah the most fucked up thing in multimedia [23:37:17 CET] <nevcairiel> (and thats saying something) [23:49:37 CET] <tmm1> ubitux: i pushed a new flush patch to my branch, moved it up ahead of the real_time one [23:51:24 CET] <tmm1> if that looks good could you merge, and i'll submit the last patch to the list [23:54:10 CET] <tmm1> i'll just push both to the list and you can merge whenever or leave comments there [00:00:00 CET] --- Sun Jan 10 2016

1 0

ffmpeg.log.20160109
by burek 10 Jan '16

10 Jan '16

[00:10:13 CET] <podman> hey guys, hopefully quick question. I'm trying to create some files that I can segment for mpeg dash delivery [00:10:43 CET] <podman> i'm having a little bit of an issue setting up the keyframe interval. it seems like it should be the frame rate * the segment length [00:11:27 CET] <podman> so 2 second segments * 30fps would mean a keyframe interval of 60. what happens if i have a video with a fraction frame rate, like 23.98fps? I can't set the key frame interval to a fraction [00:15:12 CET] <TD-Linux> your segments should be slightly shorter t hen [00:15:23 CET] <TD-Linux> the important bit is that the segments start with a keyframe. [00:16:14 CET] <podman> TD-Linux: gotcha [00:16:29 CET] <podman> so, basically round down? [00:16:33 CET] <podman> or use a floor? [00:16:46 CET] <podman> 2*23.98 = 47.96... use 47? [00:17:08 CET] <TD-Linux> sure. your segments also don't all need to be the same # of frames [00:17:22 CET] <podman> That's true [00:17:42 CET] <podman> TD-Linux: I'm just going based on what the very limited number of tutorials seem to say about this [00:17:55 CET] <podman> i can't seem to find any particularly good ones [00:18:03 CET] <TD-Linux> there aren't any as far as I know :/ [00:19:05 CET] <podman> sad times [00:23:13 CET] <podman> TD-Linux: alright, I'm going to try this and see if that fixes things [00:24:55 CET] <podman> TD-Linux: thanks [07:02:22 CET] <prelude2004c> hey everyone.. anyone know why when i record PVR my PVR STart TIME is a negative value ? something to do with -ss ? seeking ? how do i prevent it from being negative and make sure the recording always starts at 00:00:00 [07:20:02 CET] <JustinBieber> is there some filter to slow down audio without chaning its pitch ? [07:20:43 CET] <JustinBieber> when I use mplayer there are keys: "[ and ] Decrease/increase current playback speed", but it changed its pitch so if I say slow down the voice becomes very deep, but I need to change just speed [07:20:47 CET] <JustinBieber> or can I do it with sox ? [07:43:14 CET] <kepstin> if it's enabled in your build, you can try http://www.ffmpeg.org/ffmpeg-filters.html#rubberband [08:01:09 CET] <mark4o> prelude2004c: did you try setpts/asetpts? http://www.ffmpeg.org/ffmpeg-filters.html#setpts [08:02:23 CET] <mark4o> JustinBieber: -af atempo=0.5 http://www.ffmpeg.org/ffmpeg-filters.html#atempo [08:28:22 CET] <durandal_170> JustinBieber: rubberband [08:52:44 CET] <prelude2004c> mark4o i dont know how to use that :( [08:58:07 CET] <mark4o> prelude2004c: -vf setpts=PTS-STARTPTS -af asetpts=PTS-STARTPTS [08:59:24 CET] <mark4o> that will make both video and audio start at 0, which may not be what you want if they started at different times and that is needed for them to be in sync. In that case figure out how much you want to adjust by and adjust them both by the same number of seconds. [09:01:04 CET] <mark4o> e.g. -vf setpts=PTS+120/TS -af asetpts=PTS+120/TS to adjust them both forward by 120 seconds [09:01:58 CET] <mark4o> if you already have a -vf option then just add ,setpts=... to that, same with -af and asetpts [09:04:51 CET] <prelude2004c> yup i did that [09:05:06 CET] <prelude2004c> but the playback of the recorded content still starts at end of recording... the start is a negative value [09:05:20 CET] <prelude2004c> and the playback player always starts at zero ( 0 ) [09:05:50 CET] <prelude2004c> i setpts and then i use the player for playback and it only plays the last few seconds of video and then it ends [09:06:17 CET] <prelude2004c> not sure why it is doing that. the player guys tell me its because the PVRSTARTTIME starts with a negative value.. which is what i am trying to work around [09:07:22 CET] <prelude2004c> i put it in like this ' -vf "field,setsar=1/1,setdar=16/9,setpts=PTS-STARTPTS" ' [09:09:05 CET] <mark4o> prelude2004c: well I don't know what PVRSTARTTIME is; that sounds like something outside of ffmpeg [09:09:39 CET] <prelude2004c> its an HLS thing .. but the .ts files that i am encoding with ffmpeg show a negative timestamp that is the issue [09:48:51 CET] <Betablocker> gruezie [10:02:26 CET] <waressearcher2> Betablocker: hallo und herzlich willkommen [10:18:20 CET] <Betablocker> hi waressearcher2 [10:18:26 CET] <Betablocker> danke dir - moin [10:22:02 CET] <t4nk168> Hi, I am trying to merge several videos together using ffmpeg. First, I am making all the videos to black & white by using '-vf hue=s=0 -vcodec libx264 -pix_fmt yuv420p' command & then merging it. Sometimes,Its noticed that in the final merged video, the audio&video gets out of sync when playing via Quicktime player,but is properly in sync while playing in VLC player. What could be causing this problem? [10:23:18 CET] <t4nk168> Has it anything to do with the pixel format that I am using?(im using -pix_fmt yuv420p ). [10:25:14 CET] <t4nk168> Any insights will be deeply appreciated. [10:46:40 CET] <Betablocker> someone ever dewarped 180° or 360° fisheye in realtime with ffmpeg ? VOD would be ok too& better than nothing& [13:14:12 CET] <t4nk939> Hi, I am trying to merge several videos together using ffmpeg. First, I am making all the videos to black & white by using '-vf hue=s=0 -vcodec libx264 -pix_fmt yuv420p' command & then merging it. Sometimes,Its noticed that in the final merged video, the audio&video gets out of sync when playing via Quicktime player,but is properly in sync while playing in VLC player. What could be causing this problem? [13:39:08 CET] <Pinchiukas> The command '$ ffprobe -hide_banner -show_programs -print_format json -timeout 10 rtsp://192.168.3.254:554/iptv/233.136.41.7:1234' gives me '[rtsp @ 0x9f6d140] Unable to open RTSP for listening' and 'rtsp://192.168.3.254:554/iptv/233.136.41.7:1234: Permission denied' even though that stream is really available and is there. [13:39:54 CET] <Pinchiukas> From the server side I see that the client isn't even trying to access the stream. [16:58:18 CET] <odinsbane> I encoded a video to webm, and the quality is not good. What options should I set to improve it? [16:58:36 CET] <furq> could you be less specific [17:00:00 CET] <furq> actually i guess if it's webm then you probably didn't set a bitrate or crf [17:00:18 CET] <furq> set -b:v appropriately [17:01:22 CET] <odinsbane> I didn't set anything. ffmpeg -i goo.avi goo.webm. Ill check the b:v option (there is now audio to this video.) [17:20:10 CET] <odinsbane> Worked great, it was defaulting to around 200K, I put it at 32000K and it works as expected. [17:21:07 CET] <furq> that seems needlessly high but sure [17:22:35 CET] <furq> for 1-pass encodes you're probably better off using -b:v 0 -crf 32 [17:22:42 CET] <furq> or whatever crf value works out best [17:23:35 CET] <odinsbane> better how? [17:25:05 CET] <furq> crf will try to target a particular image quality [17:25:44 CET] <furq> it should give roughly the same quality independent of video content, resolution, framerate etc [17:26:54 CET] <furq> using a target bitrate is only recommended if you're trying to hit a certain filesize (and then only in 2-pass mode) [17:31:25 CET] <odinsbane> It looks good this way, the file is a little larger than using an explicit bit rate. It also took longer to encode. [17:34:46 CET] <odinsbane> hmm, the speed might have been because of different computers or different encoders. [17:37:03 CET] <odinsbane> If I try to use a mutli-image tiff file, ffmpeg only finds one image. Is it possible to get ffmpeg to recognize the multiple frames? [18:22:34 CET] <renegaid> I am using this script to remux mkv to mp4 with aac audio but the processor is a little too slow [18:22:36 CET] <renegaid> conv = Converter(self.FFMPEG_PATH, self.FFPROBE_PATH).convert(inputfile, outputfile, options, timeout=None, preopts=['-fix_sub_duration'], postopts=['-threads', '4']) [18:23:00 CET] <renegaid> the developer told me to change threads from auto to 4 but that doesn't result in any changes [18:23:08 CET] <renegaid> the same 20% cpu use [18:23:58 CET] <c_14> That doesn't tell us anything. Either give us the complete commandline (and consolet output) or ask whoever wrote that wrapper [18:24:08 CET] <c_14> You might want something like -c:v copy [18:25:39 CET] <renegaid> the video is being copied [18:25:49 CET] <renegaid> it is not converting [18:26:41 CET] <furq> is there some reason you're not just calling ffmpeg directly [18:27:13 CET] <renegaid> https://github.com/mdhiggins/sickbeard_mp4_automator/blob/master/mkvtomp4.py [18:27:32 CET] <renegaid> i don't know anything about these things [18:28:49 CET] <renegaid> he told me to change line 579 to from auto but that didn't result in any difference. [18:28:53 CET] <furq> https://www.ffmpeg.org/ffmpeg-all.html#Advanced-Subtitle-options [18:28:59 CET] <furq> Note that this option will delay the output of all data until the next subtitle packet is decoded: it may increase memory consumption and latency a lot. [18:29:04 CET] <renegaid> is converting ac3 to aac multi threaded? [18:29:19 CET] <furq> nooh [18:29:21 CET] <furq> oh [18:29:22 CET] <furq> no [18:29:30 CET] <furq> i'm good at typing [18:29:43 CET] <renegaid> maybe that's the problem then [18:29:53 CET] <furq> probably [18:30:14 CET] <c_14> Converting ac3 to aac shouldn't be that difficulet. [18:30:15 CET] <c_14> -e [18:31:01 CET] <renegaid> it does not take long but I thought it could be faster with multi thread [18:31:05 CET] <c_14> getting about 316fps here [18:32:07 CET] <furq> mp4 can contain ac3 fwiw [18:32:18 CET] <furq> i wouldn't bother converting unless you're going to stream it [18:32:46 CET] <renegaid> I know. The ac3 is left and so is the dts but i want an aac track for comparability [18:33:06 CET] <renegaid> compatibility [18:33:26 CET] <c_14> What player plays aac but won't play ac3? [18:33:31 CET] <c_14> Even tvs should play that. [18:34:13 CET] <renegaid> ios devices for one. i don't think it can play ac3 but never checkwed [19:27:50 CET] <Bitterblue> Hi. [19:27:59 CET] <Bitterblue> I'm trying to extract some information from a DVD VOB, using av_parser_parse2, but the output is a bit off (by one frame). Am I doing it wrong? https://dpaste.de/8mad https://dpaste.de/zAbf [19:28:36 CET] <Bitterblue> Using ffmpeg 2.8.1. [21:19:21 CET] <Bitterblue> The off-by-one issue is solved by using PARSER_FLAG_COMPLETE_FRAMES. The first frame is no longer detected as type "question mark". [21:20:59 CET] <prelude2004c2> hey guys.. can anyone speak to this " http://pastebin.ca/3324305 " [21:22:41 CET] <Pinchiukas> This sucks... I point ffprobe to my IPTV provider stream URLs and I get all sorts of random errors. [22:56:48 CET] <CarlFK> https://trac.ffmpeg.org/ticket/1147 closed defect (needs_more_info) [22:57:42 CET] <CarlFK> I seem to be having some sort of memory problem [22:58:27 CET] <CarlFK> running this command https://github.com/voc/voctomix/blob/master/example-scripts/ffmpeg/record-m… [22:58:42 CET] <CarlFK> both are reading from -i http://... [22:59:12 CET] <CarlFK> I have used valgrind before, but under someone elses direction. [23:02:10 CET] <CarlFK> the server is https://github.com/voc/voctomix/blob/master/voctocore/voctocore.py [23:03:12 CET] <CarlFK> that is still under development, but has been used in production ... and is leaning on gstreamer so that bit should be stable [23:10:32 CET] <CarlFK> I would like to strip away most of that command so that it just reads from the network port and then discards [23:10:52 CET] <CarlFK> and then add back to it until it starts eating memory again [23:11:06 CET] <CarlFK> (or maybe we will find that just reading from a network port eats memory ) [23:46:46 CET] <xintox> any hackers? [23:47:04 CET] <xintox> /j #h4krs [00:00:00 CET] --- Sun Jan 10 2016

1 0

ffmpeg-devel.log.20160108
by burek 09 Jan '16

09 Jan '16

[00:08:15 CET] <cone-715> ffmpeg 03James Almer 07master:28d5a3a74aee: lavu: rename and move ff_parity to av_parity [00:12:05 CET] <cone-715> ffmpeg 03James Almer 07master:08339cdb6c8f: configure: remove unused bulitin check [00:14:12 CET] <ubitux> jamrial: thx, i can sleep peacefully now [00:14:18 CET] <jamrial> haha, you're welcome :p [00:14:45 CET] <jamrial> in any case i doubt it broke anything as is. the two files using ff_parity probably included common.h first [00:40:51 CET] <rcombs> so, apparently MOV has a mechanism to include chapter thumbnails as a video stream [00:41:01 CET] <rcombs> similarly to how chapter names can be a subtitle stream [00:42:27 CET] <rcombs> I was planning on just marking chapter name streams as opaque data (https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186748.html) but that's a little bit awkward with the images, since it could actually be useful to export those [00:42:35 CET] <rcombs> so maybe I really do need to add a new disposition [00:42:51 CET] <rcombs> (I also need a mechanism to identify whether or not a file has such a stream, since it breaks some players) [01:04:47 CET] <rcombs> nevcairiel: ^ see above MOV stuff; would it be crazy for chapter thumbnail streams to be both AV_DISPOSITION_ATTACHED_PIC and (a new) AV_DISPOSITION_TIMED_THUMBNAIL, or something like that? [01:05:39 CET] <nevcairiel> i have had people report issues with those chapter thumbnail streams, if we can somehow identify them that would be nice [01:05:53 CET] <nevcairiel> dont really care how you do it [01:07:09 CET] <rcombs> it's easy to identify them; `tref/chap` just contains an array of uint32_t stream IDs [01:07:39 CET] <rcombs> I'm trying to work out how best to export which are chapter streams and differentiate them from regular attached pics [01:08:04 CET] <rcombs> setting AV_DISPOSITION_ATTACHED_PIC would be nice for compatibility, since at least some software knows to ignore those if it doesn't want to handle them explicitly [01:08:25 CET] <nevcairiel> would be nice if you can also fill the attached pic struct with the first image [01:08:27 CET] <rcombs> and then pair that with an additional disposition saying "this is attached images, but they're timed" [01:09:06 CET] <rcombs> alternately, I could export the stream as opaque binary data and cram the images in the AVChapter dict [01:09:23 CET] <rcombs> though, uh, that probably wouldn't work since those are null-terminated [01:09:45 CET] <rcombs> and there's really no guarantee that the chapter-name stream and the chapter-image stream will line up [01:09:58 CET] <rcombs> but filling the attached pic struct with the first image should be easy [01:14:38 CET] <rcombs> nevcairiel: relatedly: does https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186748.html look sane (considering only chapter-name streams)? [01:26:40 CET] <nevcairiel> rcombs: not sure, seems slightly odd [01:27:09 CET] <rcombs> MOV chapters are slightly odd [02:23:50 CET] <cone-715> ffmpeg 03Ganesh Ajjanagadde 07master:2fbdc4faf1bc: lavfi/avf_showspectrum: replace pow(x, 0.25) by sqrt(sqrt(x)) [02:23:51 CET] <cone-715> ffmpeg 03Ganesh Ajjanagadde 07master:7ab37cae34b3: ffmpeg: check fclose return values [04:00:30 CET] <BBB> whats a local static array? [04:58:16 CET] <tmm1> ubitux: let me know if you want me to re-roll any of these patchsets or if theres anything else i can do to help get all the ccaption changes merged [07:47:02 CET] <ubitux> tmm1: yes, as i said, squash the whitespace/cosmetics commits, and change "libavcodec" to "lavc" in the subject message [07:47:10 CET] <ubitux> (and if you can rebase too..) [08:08:04 CET] <jamrial> "In Firefox, we've finally moved to use ffvp9 and ffvp8 in place of libvpx for video decoding" [08:08:09 CET] <jamrial> \o/ [08:25:09 CET] <ubitux> @_@ [08:39:21 CET] <tmm1> ubitux: ah i missed that, was that on irc earlier? [08:39:53 CET] <ubitux> yeah [08:46:24 CET] <tmm1> found the logs. i'll rebase the branch and squash/reword [08:46:50 CET] <ubitux> thx [08:47:42 CET] <tmm1> any thoughts on renaming calculate_duration to something else [08:49:27 CET] <ubitux> "compute_duration"? [08:50:29 CET] <ubitux> btw, i'll submit a patchset probably today so the duration doesn't end up in the payload [08:50:45 CET] <ubitux> so duration will be kept to -1 [08:50:51 CET] <ubitux> (or you can just decide to ignore it) [08:51:11 CET] <ubitux> but the problem isn't really about the duration, it's about the buffering.. [08:51:25 CET] <ubitux> real_time? [08:54:56 CET] <tmm1> yea i think real_time is best [08:56:42 CET] <rcombs> anyone else find their terminal screwy after a parallel `make fate`? [08:57:18 CET] <rcombs> I end up with input invisible and not advancing the cursor, and have to `reset` to get things back to normal [09:00:15 CET] <ubitux> no but i heard complains about ffmpeg messing the term on interupt recently, even with -nostdin -nostats [09:01:07 CET] <ubitux> which makes me wonder if we shouldn't disable term_init() when -nostdin and -nostats are passed [09:15:23 CET] <tmm1> ubitux: here you go: https://github.com/tmm1/ffmpeg/compare/master...upstream-cc-cleanups.patch [09:51:24 CET] <ubitux> tmm1: i'm going to comment on github, fine with that? [09:54:09 CET] <ubitux> or you can just resend the patchset on the ml [09:57:16 CET] <kierank> Hmm global thread pool... [09:57:24 CET] <kierank> He should hañdle that in his app [10:02:47 CET] <ubitux> kierank: given that firefox will probably end up (or is actually already?) using multiple processes (for isolation between tabs etc), he will have to anyway [10:02:50 CET] <ubitux> unless i'm mistaken [10:11:50 CET] <wm4> nevcairiel: what's the HEVC HDR mastering SEI useful for? [10:12:51 CET] <wm4> (saw it in your private ffmpeg repo) [10:13:01 CET] <rcombs> I haven't the foggiest actual idea but I'm going to say "marketing" like everything else with "HDR" in the name regarding video [10:13:01 CET] <wm4> I'm also going to fish out and try that hevc main 10 dxva patch [10:16:40 CET] <wm4> I think the idea is 1. standardizing brightness, and 2. going outside of the brightness range usually used today (note: brightness is a naive term, but I'm no damn color scientist) [10:18:45 CET] <rcombs> I thought it was just marketing-speak for 10bit BT2020 [10:23:39 CET] <kierank> No thats wcg [10:24:00 CET] <kierank> It's all bs anywau [10:24:05 CET] <kierank> Nobody will buy it [10:24:14 CET] <wm4> "One of the issues we've faced was with our reftest tests , with pages [10:24:14 CET] <wm4> creating hundreds of small video elements " [10:24:14 CET] <kierank> Other than nerds [10:24:18 CET] <wm4> I hate the web so fucking much [10:26:57 CET] <rcombs> wm4: &why would someone do that [10:27:15 CET] <wm4> actually it looks like they're doing that only for their tests [10:27:34 CET] <wm4> 1. write shitty tests, 2. force everyone else to change their software so that the tests run [10:37:43 CET] <ubitux> wm4: well, having webpages full of gif/webm is not that exotic [10:38:32 CET] <ubitux> http://giphy.com/ "imagine all these shit animated at the same time [10:39:04 CET] <ubitux> i think some tumblr pages actually do this [10:39:38 CET] <ubitux> https://www.tumblr.com/tagged/animated-gif [10:39:40 CET] <ubitux> here you go [10:41:13 CET] <wm4> give me an argument why browsers should optimize for being able to do the same with videos (or alternatively, why such small "videos" should use threaded decoding) [10:42:37 CET] <ubitux> enabling threading only for large video would make sense yes [11:05:29 CET] <wm4> kierank: what about SMPTE-ST-2084? (or is it related to the hevc hdr thing) [11:10:41 CET] <kierank> That's an HDR spec iirc [11:10:46 CET] <kierank> Dolby related [11:20:53 CET] <nevcairiel> wm4: the metadata specifies what brightness and gamut the mastering display had, so you can use that to convert the stream to the users display [11:21:31 CET] <wm4> yeah, but what uses it? [11:24:56 CET] <kierank> The tv [11:37:05 CET] <nevcairiel> We'll see if HDR sees adoption, HDR screens showing HDR content sure look nice though [11:40:23 CET] <kierank> it's a gimmick [11:40:28 CET] <kierank> most people won't notice or care [11:42:06 CET] <wm4> like 3D is a gimmick? [11:43:51 CET] <nevcairiel> 3D is just annoying because it needs f'ing glasses, if it worked well without glasses it might be more popular [11:44:22 CET] <nevcairiel> I won't pretend to know what the most people will notice or care about, but personally I find HDR to be a nice boost in quality on a good screen [11:45:27 CET] <nevcairiel> (also that there is barely any movies actually filmed in 3D making proper use of the tech, those movies converted to 3D afterwards just look bad) [11:46:38 CET] <kierank> I went to an HDR demo in a simulated living room and some geeks couldn't tell the difference [11:46:44 CET] <kierank> how the hell joe public is I don't know [11:46:53 CET] <kierank> the benefits of HDR are so minimal in the real world [11:46:55 CET] <kierank> same as 3D [11:47:42 CET] <wm4> I just wonder how "calibration" would work here [11:56:01 CET] <cone-686> ffmpeg 03Paul B Mahol 07master:08aec7c1bda4: avfilter/avf_showspectrum: add option to draw legend [12:03:12 CET] <cone-686> ffmpeg 03Hendrik Leppkes 07master:53ada3af62d5: x86/vf_w3fdif: 32-bit compatibility for w3fdif_simple_high [13:53:18 CET] <kierank> wm4: you're being a bit harsh on this guy [13:53:42 CET] <wm4> come on, hundreds of video elements [13:54:08 CET] <wm4> and the cause for action is that it fails on Windows XP? [13:54:31 CET] <wm4> but ok I'll try to be slightly less of a dumb asshole [13:54:51 CET] <kierank> thread pools are a good idea [13:55:07 CET] <wm4> even if they're global? [13:55:10 CET] <kierank> no [13:55:14 CET] <kierank> I said that's bad [13:56:24 CET] <wm4> that's why I suggested exposing thread pools as API object [13:58:41 CET] <J_Darnley> OMFG! You need 1 video element on a page because you should be showing 1 video at a time. (Fucking webdevs). [13:59:14 CET] <wm4> J_Darnley: I think the intention is that it replaces gif elements [13:59:36 CET] <wm4> which is why I ridiculed it with some geocities comment [13:59:46 CET] <J_Darnley> :) [14:00:16 CET] <wm4> (but even if they did that, they should make invisible elements inactive anyway) [14:00:50 CET] <J_Darnley> But then how would advertisers blast you with hidden audio ads? [14:02:36 CET] <wm4> there's the <audio> element for that? I think... [14:03:14 CET] <J_Darnley> But you want to show video when the user scrolls into position or changes tab. [14:11:52 CET] <kierank> wm4: web devs are morons [14:12:01 CET] <kierank> worse than broadcast people [14:15:26 CET] <nevcairiel> thats mostly because web dev is cool and everyone thinks they can do it [14:16:06 CET] <J_Darnley> CPU power and memory are infinite, unused resources after all. [14:16:16 CET] <qeed> the infinity machine? [14:16:24 CET] <wm4> meanwhile firefox is the process that uses most memory on my machine [14:17:12 CET] <nevcairiel> browsers are hard to count these days, they split themself into many processes all taking up memory :D [14:17:30 CET] <J_Darnley> (good browsers don't) [14:17:36 CET] <qeed> what are good browsers [14:17:41 CET] <J_Darnley> Pale Moon [14:18:08 CET] <nevcairiel> the whole concept of doing that is a good idea tbh, it allows proper security sandboxing, the web is a bad place [14:18:23 CET] <nevcairiel> and all these firefox off-shoots are just silly [14:18:48 CET] <J_Darnley> No Firefox is silly for Australis and now dropping Extensions [14:19:28 CET] <wm4> dropping extensions? [14:19:52 CET] <Compn> yes firefox dropping extensions [14:19:53 CET] <nevcairiel> i think firefox wants to go towards chrome-style extensions and dropping their own extension thing [14:20:00 CET] <Compn> probably because of pressure against ad blockers haha [14:20:59 CET] <J_Darnley> That means their olive branch of the "old UI extension" will probably also not work. [14:21:24 CET] <wm4> uh [14:21:34 CET] <wm4> I'm still using tons of extensions to undo their UI changes [14:21:52 CET] <wm4> (not all of them, it's not like I reject them blindly) [14:23:52 CET] <J_Darnley> Their plan hasn't made it into the main releases yet (I don't even know if its in their nightlies) [14:25:11 CET] <wm4> by the way, why does Intel broadwell appear to support HEVC 10 bit decode on DXVA? (probably hybrid) [14:25:42 CET] <nevcairiel> yeah its hybrid [14:25:52 CET] <nevcairiel> just like skylake [14:26:33 CET] <wm4> eh [14:26:54 CET] <wm4> so, 8 bit on skylake is native, on broadwell it's hybrid? [14:26:58 CET] Action: Daemon404 wonders if it may be a good idea to put a big fat warning on the wiki about it being user-created [14:27:02 CET] <Daemon404> and not official documentation [14:27:10 CET] <Daemon404> (because its full of wtf / wrong stuff) [14:27:18 CET] <nevcairiel> skylake definitely has native 8-bit, but i dont know if broadwell also had that [14:27:31 CET] <nevcairiel> so many different generations to remember [14:27:32 CET] <wm4> is there a way to find out? [14:27:38 CET] <nevcairiel> run it, check cpu usage =p [14:29:11 CET] <wm4> enabling dxva on broadwell with 8 bit seems to half CPU usage (from ~17% to ~9%) [14:29:54 CET] <nevcairiel> broadwell should be hybrid 8-bit from what I can find [14:30:20 CET] <nevcairiel> probably still faster than cpu decoding considering how slow avcodec is [14:30:29 CET] <wm4> seems so [14:30:53 CET] <wm4> regarding your dxva patch: you're worried that the API user now needs a profile check for HEVC [14:31:11 CET] <wm4> but h264 needs a profile check anyway, so at least the API users has to be aware of the potential problem? [14:32:28 CET] <nevcairiel> even for h264 the need for a profile check is rare, the only type of content that would need it is lossless 420 8-bit, which is rare enough as it is [14:32:38 CET] <nevcairiel> so some dumb app could be doing fine without it [14:33:34 CET] <wm4> then I'd suggest adding a private option [14:34:28 CET] <Daemon404> can someone give me a quick gist of that big threadpool ML thread [14:34:45 CET] <Daemon404> i dont think it's a terrible idea [14:34:52 CET] <Daemon404> i have hit thread limits, on linux, due to the same problem [14:34:56 CET] <Daemon404> albeit on large transcoding servers. [14:35:16 CET] <Daemon404> especially considering each thread, by default, uses 2-4mb stack space. [14:35:43 CET] <nevcairiel> its probably hard to properly setup though, since we wouldnt want global state, and we dont have a "master" context concept right now to shove something like this in [14:35:54 CET] <Daemon404> yes of course [14:36:09 CET] <Daemon404> im sayign the idea is OK [14:36:13 CET] <Daemon404> if they do the work properly [14:36:14 CET] <Daemon404> etc [14:36:43 CET] <Daemon404> a cursory glance of the thread seems like the usual drive to make new cntributers go away [14:37:01 CET] <wm4> now this guy compares pthread with firefox-internal thread pool APIs [14:44:04 CET] <kierank> Daemon404: only the global part is contentious [14:44:34 CET] <Daemon404> kierank, keyword: properly [14:44:40 CET] <Daemon404> it doesnt need to be some global state [14:45:28 CET] <Daemon404> although the easiest way may just be to use/allow some trheading library [14:45:39 CET] <Daemon404> similar to how we allow user-provided alloc libs [14:46:07 CET] <kierank> yeah and make w32threads use that api [14:46:31 CET] <Daemon404> eh w32threads is unrelated [14:46:39 CET] <Daemon404> it could just override everything [14:46:42 CET] <Daemon404> itst he user's problem [14:46:46 CET] <Daemon404> if they provide a lib [14:46:53 CET] <kierank> ok [14:54:13 CET] <cone-686> ffmpeg 03Mats Peterson 07master:13d02d3dc81a: lavf/mov: Audio and fourcc 0x00000000 [14:54:14 CET] <cone-686> ffmpeg 03Mats Peterson 07master:6f1466dc5272: lavf/matroskadec: A_QUICKTIME and fourcc 0x00000000 [14:54:15 CET] <cone-686> ffmpeg 03Michael Niedermayer 07master:47cd85e1e5b1: avformat/mov: Simplify format checking code [14:59:43 CET] <cone-686> ffmpeg 03Paul B Mahol 07master:b7b4d99a1837: avfilter/avf_showfreqs: fix possible null pointer dereference [15:02:29 CET] <durandal_1707> clang crashed by libpostproc, lib that nobody touch [15:02:57 CET] <Daemon404> clang HEAD? [15:05:17 CET] <durandal_1707> 3.7.0 [15:05:39 CET] <wm4> fix clang then, and be grateful to postproc for being a good test case [15:06:00 CET] <Daemon404> i tried to get 3.7 to self-host on my pandaboard [15:06:17 CET] <Daemon404> but it cant build its own tablegen properly [15:06:20 CET] <Daemon404> gets SIGBUS'd [15:07:03 CET] <durandal_1707> libpostproc should be moved/replaced by lavfi [15:07:16 CET] <Daemon404> good luck with that [15:07:44 CET] <Daemon404> my personal opinion is that postproc actually has no value in 2016 [15:08:46 CET] <wm4> durandal_1707: isn't there a lavfi wrapper [15:12:08 CET] <durandal_1707> yes, but I mean functionality like lgpl deblocking and deringing [15:12:35 CET] <Daemon404> there are a lot of avs/vs deblock/dereing filters on doom9 [15:12:41 CET] <Daemon404> but they don't use MB-level info [15:34:56 CET] <tmm1> ubitux: github comments are fine [15:44:47 CET] Action: J_Darnley must not troll on the dev mailing list [16:23:30 CET] <ubitux> fmt_ctx->max_analyze_duration = -1; [16:23:33 CET] <ubitux> best hack ever [16:23:55 CET] <ubitux> (sets a negative value outside allowed range, so it doesn't actually do expensive probing) [16:24:17 CET] <wm4> wut [16:24:31 CET] <ubitux> i have an issue here, on embedded devices [16:25:00 CET] <ubitux> i'm basically using the ffmpeg to probe and demux, and sends the pkt to an accel [16:25:21 CET] <ubitux> but the find_stream_info on an mp4/h264 file will actually start decode the h264 stream [16:25:34 CET] <ubitux> which will cause a peak of 15-20M of heap alloc [16:25:48 CET] <ubitux> and will slow down the startup significantly because of the ffh264 decoding [16:26:01 CET] <Daemon404> do you know the file is always h264? [16:26:10 CET] <Daemon404> just skip the find_stream_info entirely if so [16:26:12 CET] <ubitux> i don't, but issue is the same anyway [16:26:15 CET] <ubitux> no i can't [16:26:17 CET] <Daemon404> ah. [16:26:20 CET] <ubitux> i need some timebase stuff [16:26:28 CET] <ubitux> context is half broken if i don't call it [16:26:53 CET] <Daemon404> i manually decode 1 frame of audio and video to fill stuff in [16:26:55 CET] <ubitux> anyway, unfortunately, max_analyze_duration is in [0;+inf], so i can't use avoption (0 is default and means sth like 5 seconds for video) [16:26:56 CET] <Daemon404> and keep my own frame queue [16:26:59 CET] <wm4> Daemon404: you can't do that in the general case, even if your API usage can handles it in theory [16:27:15 CET] <Daemon404> wm4, general case being unknown format? [16:27:17 CET] <Daemon404> of cours.e [16:27:18 CET] <ubitux> but fmt_ctx->max_analyze_duration = -1 works really well :] [16:27:22 CET] <wm4> yeah [16:27:32 CET] <Daemon404> wm4, i do it our DASH and HLS packager [16:27:35 CET] <Daemon404> which always gets h264/aac [16:27:45 CET] <wm4> then you're in luck [16:27:45 CET] <Daemon404> and must run on-the-fly [16:27:48 CET] <Daemon404> it's a big speedup. [16:28:17 CET] <ubitux> http://b.pkh.me/guess-where-is-the-probing.png [16:29:28 CET] <ubitux> then with the hack: http://b.pkh.me/negative-max-analyze-duration.png [16:29:30 CET] <ubitux> \o/ [16:29:42 CET] <ubitux> (not the same scale) [16:30:08 CET] <ubitux> we should probably have -1 being the default [16:30:13 CET] <ubitux> and allow 0 [16:30:37 CET] <Daemon404> changing the analyze duration default will piss of unlimited numbers of people [16:30:41 CET] <Daemon404> it's a massive behavior change [16:31:02 CET] <ubitux> it won't change anything [16:31:24 CET] <Daemon404> i cant see how it wouldnt [16:31:51 CET] <ubitux> default value should be -1 instead of 0, and -1 would mean the same fallback (5s video 30s sub ...) as 0 is currently [16:31:56 CET] <ubitux> except that 0 will be allowed too [16:32:21 CET] <ubitux> so unless you force 0 (which would make no sense since it's the default currently), it won't change for you [16:33:26 CET] <Daemon404> perhaos i misunderstand [16:33:30 CET] <Daemon404> [15:23] <@ubitux> (sets a negative value outside allowed range, so it doesn't actually do expensive probing) [16:33:39 CET] <Daemon404> that differs from what you just said. [16:34:18 CET] <ubitux> i was describing the hack [16:34:41 CET] <Daemon404> you were descri bing teh behavior of setting -1 [16:34:43 CET] <Daemon404> afaict? [16:34:52 CET] <Daemon404> why would it act differently if it is default [16:35:05 CET] <Daemon404> first you sya it wont probe [16:35:10 CET] <Daemon404> then you say itll have 5s [16:35:27 CET] <ubitux> Daemon404: http://b.pkh.me/0001-lavf-allow-null-max_analyze_duration.patch [16:35:55 CET] <ubitux> then i could do av_opt_set_int(fmt_ctx, "analyzeduration", 0, 0); instead of my hack [16:36:06 CET] <ubitux> and that won't change anything for anyone [16:36:40 CET] <Daemon404> ah. i hadnt understood that you inded to change your own code to not use -1 after. [16:37:08 CET] <Daemon404> although that patch needs to have the -1 default added then [16:37:45 CET] <ubitux> -1 default added? that's in the patch [16:38:16 CET] <Daemon404> ubitux, isnt it also a context member [16:38:19 CET] <jamrial> "if (!max_analyze_duration < 0)" that's clearly not right :p [16:38:38 CET] <ubitux> jamrial: heh yeah, that's a prototype ;) [16:38:53 CET] <ubitux> (fixed) [16:39:25 CET] <ubitux> Daemon404: i dont understand [16:39:26 CET] <Daemon404> ubitux, does that properly set max_analyze_duration/max_analyze_duration2 in the afctx? [16:39:32 CET] <Daemon404> by changing just teh opt table [16:39:47 CET] <ubitux> {.i64 = -1 } [16:39:50 CET] <ubitux> this is the default value [16:39:54 CET] <ubitux> i supposed these are populated [16:40:26 CET] <Daemon404> the offset is for max_analyze_duration [16:40:30 CET] <Daemon404> i'd confirm max_analyze_duration2 is also set [16:40:31 CET] <Daemon404> im sure it is [16:40:44 CET] <ubitux> max_analyze_duration2 doesn't exist [16:40:56 CET] <ubitux> (anymore) [16:41:15 CET] <Daemon404> wait what the fuck [16:41:25 CET] <Daemon404> it used to exist, and max_analyze_duration was deprecatwed [16:41:27 CET] <ubitux> it was probably renamed in a major bump or some shit [16:41:36 CET] <Daemon404> ... you should NEVER reuse names [16:41:39 CET] <Daemon404> even if you bump [16:41:54 CET] <ubitux> yes, but i'm not the responsible :X [16:41:56 CET] <Daemon404> seems thats what happened [16:41:58 CET] <Daemon404> that's awful. [16:42:05 CET] <Daemon404> api compatible and will silently break [16:42:07 CET] <ubitux> max_analyze_duration is int64 so that's probably what happened yes [16:42:18 CET] <Daemon404> yes i just checked [16:42:26 CET] <nevcairiel> see it this way: it wasnt re-used, the size was just changed [16:42:34 CET] <nevcairiel> we have changed types of variables often enough in a bump [16:42:37 CET] <nevcairiel> this is no different [16:43:00 CET] <ubitux> you should use avoption to set/get it anyway :-° [16:43:17 CET] <Daemon404> nevcairiel, no the unit changed [16:43:22 CET] <Daemon404> behavior has changed [16:43:25 CET] <Daemon404> nto just type [16:43:39 CET] <nevcairiel> only the type changed afaik [16:44:17 CET] <nevcairiel> to allow for bigger values [16:44:23 CET] <Daemon404> hmm confusing [16:44:29 CET] <Daemon404> becauses max_analyze_duration2 mentioned timebase units [16:44:32 CET] <Daemon404> max_analyze_duration mentiones no units [16:44:36 CET] <Daemon404> seems i got confused [16:44:38 CET] <Daemon404> due to lack of any doc [17:48:48 CET] <durandal_1707> ubitux: nlmeans status? [17:50:58 CET] <ubitux> no progress since last time, maybe this week end [17:51:33 CET] <ubitux> going to submit some subtitles stuff tonight, and will go back to it [18:03:35 CET] <cone-686> ffmpeg 03Paul B Mahol 07master:a69cf50dca51: avfilter/avf_showspectrum: add cool color map [18:22:02 CET] <ubitux> durandal_1707: where are you getting all these color maps? [18:23:31 CET] <durandal_1707> from other software [18:24:11 CET] <durandal_1707> fruit is inspired by default one in sonic visualizer [18:24:37 CET] <durandal_1707> fire from nugen [18:24:55 CET] <durandal_1707> Rainbow from speek [18:25:32 CET] <durandal_1707> cool is based on parula, used in matlab IIRC [18:26:16 CET] <ubitux> ok :) [18:26:37 CET] <durandal_1707> fiery from other spectrogram soft [18:28:03 CET] <durandal_1707> there is also web page with over millions palletes, mostly useless for filter [18:28:21 CET] <ubitux> durandal_1707: why is overlap=[0;1) going faster but overlap=1 slow again? [18:29:27 CET] <durandal_1707> overlap 1 doesn't make sense so it picks one recommended by win function [18:29:34 CET] <ubitux> ok [18:30:49 CET] <durandal_1707> using big overlap makes sense only if fps is low, with big fft window [18:45:43 CET] <Compn> why add new hacks to playback old broken ffmpeg mov/mkv when we can just make user use old ffmpeg? :P [18:46:47 CET] <iive> Compn: please, use the proper sarcasm tag. [19:27:59 CET] <kurosu> Is anyone able to use gdb with msys2 64bits? I either get "Cannot access memory at address" or the breakpoint doesn't actually trigger [19:34:23 CET] <tmm1> morning [19:35:53 CET] <tmm1> ubitux: i can resubmit to the list too if you prefer [19:59:53 CET] <ubitux> tmm1: i'm finally free, i'm going to look at github, no woryr [20:03:41 CET] <ubitux> tmm1: "avc/ccaption_dec: reap_screen() is responsible for clearing output buffer and signaling screen_changed [20:03:46 CET] <ubitux> what does this commit do? [20:06:50 CET] <cone-686> ffmpeg 03Aman Gupta 07master:b261749f7071: lavc/ccaption_dec: clean up whitespace [20:07:23 CET] <cone-686> ffmpeg 03Aman Gupta 07master:5695c8533294: lavc/ccaption_dec: remove unused return value from internal functions [20:10:53 CET] <tmm1> ubitux: just moves the screen_changed bit and the bprint_clear into the reap_screen so its centralized in one place [20:11:14 CET] <ubitux> can you rework the commit message to say that? [20:11:19 CET] <ubitux> it's not obvious reading it [20:11:41 CET] <ubitux> you can then push force and i'll continue the merging [20:12:46 CET] <tmm1> sure [20:14:26 CET] <tmm1> pushed [20:15:58 CET] <cone-686> ffmpeg 03James Almer 07master:7f520524f67a: x86/float_dsp: remove len check from ff_butterflies_float_sse [20:16:00 CET] <cone-686> ffmpeg 03James Almer 07master:4ee38ed7f903: x86/float_dsp: zero extend len from ff_butterflies_float_sse implicitly [20:16:01 CET] <cone-686> ffmpeg 03James Almer 07master:dc79824deb6a: x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse [20:22:09 CET] <J_Darnley> That is explicit not implicit. [20:24:43 CET] <nevcairiel> explicit was using an extra instruction for it, now its implicit by acting on a dword sized reg =p [20:26:28 CET] <J_Darnley> Sorry [20:26:40 CET] <J_Darnley> I did read those + and - backwards [20:26:52 CET] <cone-686> ffmpeg 03Aman Gupta 07master:53ee84f811c3: lavc/ccaption_dec: reap_screen() is responsible for clearing output buffer and signaling screen_changed [20:26:54 CET] <cone-686> ffmpeg 03Aman Gupta 07master:26abdd61a397: lavc/ccaption_dec: implement "erase non displayed memory" [20:27:45 CET] <ubitux> tmm1: any idea why screen reaping was done on erase? [20:31:18 CET] <tmm1> ubitux: not sure, but it's definitely not correct [20:31:36 CET] <tmm1> in all the samples i tried the stream will send explicit EDM when it wants you to erase, and EOC when it wants you to display [20:32:04 CET] <tmm1> the previous code called EDM from EOC which seemed to work but wasn't technically right [20:32:24 CET] <tmm1> i think that was because "erase non-displayed memory" wasn't implemented before, so that extra erase was required [20:38:31 CET] <cone-686> ffmpeg 03Ricardo Constantino 07master:e990d746d051: configure: Use libgcrypt-config if available [20:40:00 CET] <ubitux> tmm1: ok [20:40:43 CET] <ubitux> tmm1: do you have samples with tab offset? [20:41:16 CET] <ubitux> can it be implemented easily with injecting some ass positionning? [20:41:41 CET] <cone-686> ffmpeg 03Aman Gupta 07master:fe225b113b05: lavc/ccaption_dec: reap_screen is not necessary when clearing screen or buffer [20:42:44 CET] <ubitux> if you want to ignore them for now, can you at least set a specific debug info printing the settings or something? [20:44:10 CET] <tmm1> i put that in there to quelch the debug output, because it was generating a lot of noise [20:44:18 CET] <tmm1> one of the samples i put up did tab offset commands [20:44:38 CET] <ubitux> one you uploaded? remember the name? [20:44:47 CET] <tmm1> i'm not sure how easy it is to implement, because the screen buffer is just characters and doesn't let you record any other information that would later be required to translate into ass positioning [20:45:16 CET] <ubitux> so the sample was repositionning after every character? [20:45:21 CET] <tmm1> if you want to skip that commit that's fine by me, its only noisy if you have debug loglevel enabled [20:45:32 CET] <ubitux> it's ok, i was just curious [20:45:54 CET] <tmm1> not after every character, maybe after every EDM. i can check which one it was [20:47:18 CET] <ubitux> 80df4b0 breaks fate [20:47:27 CET] <ubitux> can you make fate-sub-cc GEN=1 and check if the diff is correct? [20:47:46 CET] <ubitux> if it is, include the chunk in the commit and push force again please [20:50:13 CET] <tmm1> sure [20:51:42 CET] <tmm1> music.ts has the tab offset commands [20:53:24 CET] <ubitux> noted, thx [20:53:25 CET] <tmm1> also has "0x11 0x37" which is supposed to render a musical note glyph, but i wasn't sure how to put that in the char* buffer either [20:54:19 CET] <ubitux> print the utf-8 code? [20:54:30 CET] <ubitux> ass is supposed to support unicode [20:55:38 CET] <tmm1> yea but Screen uses a uint8_t *characters [20:56:31 CET] <ubitux> aren't you supposed to write them in the av buffer thing? [20:57:03 CET] <tmm1> chars are written into the screen, and then reap_screen pulls them into the buffer [20:57:16 CET] <tmm1> because all the commands are row/column based so the screen is a representation of that [20:57:24 CET] <ubitux> so if you print sth like "\xe2\x99\xac" will it work? [20:57:24 CET] <tmm1> 15x32 [20:57:25 CET] <J_Darnley> Up with j. Down with #. [20:58:49 CET] <tmm1> there's three optional character tables defined on the wikipedia page, so ideally we'd implement all of them and probably add another table to Screen that holds the character encoding for each row/column [20:59:07 CET] <tmm1> then in reap_screen it can emit the equivalent utf-8 into the buffer [20:59:20 CET] <tmm1> anyway, they're optional so its ok for now. i can do some follow up patches [20:59:35 CET] <ubitux> sure [21:00:09 CET] <tmm1> looking at this fate thign, do you have the failure handy? [21:01:58 CET] <ubitux> make fate-sub-cc [21:02:01 CET] <ubitux> it will fail [21:02:08 CET] <ubitux> (you need to have samples etc) [21:02:26 CET] <ubitux> see https://ffmpeg.org/fate.html [21:02:52 CET] <ubitux> (just need to read point 2) [21:08:35 CET] <cone-686> ffmpeg 03James Almer 07release/2.4:030fed62f4cf: x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse [21:08:36 CET] <cone-686> ffmpeg 03James Almer 07release/2.5:4bcbeaa337ea: x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse [21:08:37 CET] <cone-686> ffmpeg 03James Almer 07release/2.6:b90796ab8627: x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse [21:08:38 CET] <cone-686> ffmpeg 03James Almer 07release/2.7:34c5f6685a86: x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse [21:08:39 CET] <cone-686> ffmpeg 03James Almer 07release/2.8:3e3aa25afa10: x86/float_dsp: zero extend offset from ff_scalarproduct_float_sse [21:10:19 CET] <tmm1> found an old fate-samples dir, updating now [21:24:07 CET] <tmm1> ubitux: what sample file corresponds to sub-cc [21:24:27 CET] <ubitux> tmm1: try make fate-sub-cc V=1 [21:24:35 CET] <ubitux> you'll see what command is run [21:24:39 CET] <tmm1> gotcha thanks [21:29:06 CET] <philipl> BtbN: it sounded like you were doing vaapi-vp8. Actually true? My skylake nuc just arrived so I'll look at it if you're not. [21:35:20 CET] <tmm1> ubitux: force pushed [21:35:28 CET] <tmm1> added another fate test for the new realtime mode as well [21:39:15 CET] <ubitux> why did one dialog disappear? [21:41:21 CET] <ubitux> tmm1 ^ [21:42:05 CET] <tmm1> ubitux: because the sample dosen't have the second NEWLINE command, so its buffered but never emitted [21:42:20 CET] <ubitux> what about emiting in flush? [21:43:56 CET] <tmm1> not sure that would work correctly when seeking then.. [21:44:20 CET] <ubitux> ok ok [21:44:20 CET] <tmm1> is flush called on both seek and eof? [21:44:30 CET] <ubitux> i think so [21:44:39 CET] <ubitux> can you add a comment in the commit to explain the fate change? [21:44:52 CET] <tmm1> yes [21:47:31 CET] <tmm1> done [21:50:07 CET] <ubitux> cool, thx, i continue the merge then [21:50:20 CET] <ubitux> how long are you going to be available? [21:52:07 CET] <ubitux> mmh [21:53:42 CET] <tmm1> i'm here for a few hours [21:54:38 CET] <ubitux> ok cool [21:54:52 CET] <ubitux> i'm a bit confused at this bprintf you added in the commit [21:54:57 CET] <ubitux> which wasn't present before [21:56:01 CET] <ubitux> also, 2 small comments on "ctx->prev_string = av_strdup(ctx->buffer.str);": 1. unchecked malloc 2. you should check if av_bprint_is_complete() [21:56:38 CET] <tmm1> the bprintf is part of ff_ass_add_rect_bprint [21:57:13 CET] <tmm1> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/ass.c#L183 [21:57:30 CET] <tmm1> i switched to ff_ass_add_rect() so i need to do the \r\n [21:58:28 CET] <ubitux> ah, missed that [21:58:35 CET] <ubitux> mmh [21:58:36 CET] <ubitux> ok [21:59:59 CET] <tmm1> i'll add a av_bprint_is_complete() check [22:00:28 CET] <tmm1> i think prev_string can perhaps be ignored? because the next time around the loop it will see its null and not do anything [22:00:40 CET] <tmm1> or should i just ENOMEM as well [22:03:24 CET] <ubitux> git grep -A1 av_bprint_is_complete confirms ENOMEM is relevant [22:03:44 CET] <BtbN> philipl, I started, but didn't have time over christmas/new year, and didn't finish it yet. [22:03:45 CET] <ubitux> is it ok to print \r\n when it doesn't enter the prev_string check? [22:04:23 CET] <BtbN> philipl, https://github.com/BtbN/ffmpeg/tree/vaapi_vp8 if you want to pick it up. It's nearly done, there are some variable mapping from the ffmpeg vp8 structs to the VAAPI ones missing. [22:04:38 CET] <BtbN> The biggest problem are the weird data offset values VAAPI wants [22:04:42 CET] <tmm1> ubitux: no, because the other branch still uses ff_ass_add_rect_bprint() which would cause double \r\n [22:04:44 CET] <BtbN> ffmpeg has nothing that's even close to them. [22:05:05 CET] <tmm1> i could do it before and switch to use the non-_bprint in both cases [22:05:05 CET] <BtbN> Because it parses the bitstream fundamentaly diffrent from gst, which vaapi is designed around [22:05:33 CET] <tmm1> but then the third real time branch gets confusing [22:06:03 CET] <ubitux> tmm1: sorry i'm still after the same commit, so there is only one [22:06:35 CET] <BtbN> philipl, but I'm not sure if VP8 hwaccel is worth it anymore. From testing with gst, the ffmpeg software decoder uses less CPU than VAAPI "accelerated" decoding. [22:06:51 CET] <tmm1> originally i was trying to use a prev_buffer, but i didn't see an easy way to copy ctx->buffer to prev_buffer [22:07:00 CET] <tmm1> so i ended up with the char* and strdup [22:07:47 CET] <ubitux> ok [22:08:00 CET] <ubitux> i'm starting to get confused but ok, i'll probably recheck everything at the end [22:08:19 CET] <tmm1> i can fixup the commit with ENOMEM [22:08:23 CET] <philipl> BtbN: Maybe you'd see a benefit for 4k streams :-P [22:08:25 CET] <ubitux> i have my pending branch where i rework that shit, it would be more convenient to have only ff_ass_add_rect_bprint() though :D [22:08:28 CET] <philipl> I'll take a look over the weekend [22:08:28 CET] <ubitux> but whatever :) [22:08:32 CET] <ubitux> tmm1: please do :) [22:08:39 CET] <philipl> It's also possible that gst lameness is burning cpu. That happens. [22:09:48 CET] <BtbN> The hwaccell hooks are done, at least I think so. [22:09:55 CET] <tmm1> ubitux: pushed [22:09:59 CET] <BtbN> Not 100% sure where the hook calls should be placed, but it should work [22:10:14 CET] <philipl> BtbN: Matches what I came up with before. So I believe it :-) [22:12:13 CET] <ubitux> tmm1: libavcodec/ccaption_dec.c:527:40: error: buf undeclared (first use in this function) [22:12:50 CET] <ubitux> tmm1: can you also squash "rename calculate_duration to real_time" into the "add calculate_duration option" one? [22:14:56 CET] <tmm1> oof, that's embarassing [22:14:57 CET] <ubitux> tmm1: also, "Do not buffer closed captions to calculate durations. Emits subtitle events in real-time for display." please make one sentence, with no capitalize nor period, for consistency [22:17:38 CET] <tmm1> how about "emit subtitle events as they are decoded for real-time display" [22:18:17 CET] <tmm1> i guess it should mention missing duration too [22:19:16 CET] <tmm1> "emit subtitle events in real-time without calculating durations" [22:20:39 CET] <ubitux> tmm1: i like 2nd one [22:21:38 CET] <tmm1> ok let me do this rebase, i'll have to ammend a bunch of the follow up commits that refer to the old option [22:21:59 CET] <ubitux> sorry :) [22:22:30 CET] <ubitux> the fate test is frightening btw [22:23:05 CET] <ubitux> like, the subtitle really is supposed to appear character by character every 1.5s? [22:24:31 CET] <ubitux> the duplicated last event is curious too [22:24:39 CET] <tmm1> yea in rollup mode [22:24:53 CET] <tmm1> in painton its buffered off screen and shows up as the person starts speaking [22:25:06 CET] <tmm1> rollup is more common for sports and news where its being live transcribed [22:25:29 CET] <ubitux> so that's actually live timed with a keyboard? [22:25:49 CET] <ubitux> or it's a karaoke-of-the-poor? [22:25:56 CET] <tmm1> i'm not sure how they do it, there's specialized equipment for it supposedly [22:26:00 CET] <ubitux> in which case, maybe a \k ass event would be appropriate? [22:26:50 CET] <tmm1> yea that could be better, but then you're still buffering and by the time you emit the event it's too late [22:27:03 CET] <ubitux> yep, i see [22:27:12 CET] <ubitux> and with the buffering mode, would it make sense? [22:27:49 CET] <tmm1> it might look better but the end result is the same [22:28:09 CET] <tmm1> it essentially appears like a popon caption, where the text all shows up when the person begins speaking [22:28:23 CET] <tmm1> which is totally fine if you're converting caps to webvtt or something and playing after the fact [22:31:14 CET] <ubitux> tmm1: btw, here is a present for you: http://hackipedia.org/ATSC/EIA-608%20samples/EIA-608%20character%20set%20te… [22:34:39 CET] <ubitux> but in your realtime example, the text appears progressively, right? [22:35:34 CET] <ubitux> that's going to be slightly weird at playback [22:37:47 CET] <tmm1> nice [22:38:43 CET] <ubitux> if we support the raw, it might be relevant to add it to fate [22:38:48 CET] <ubitux> since it's small [22:39:42 CET] <tmm1> phew, rebase done [22:39:46 CET] <tmm1> i moved the simpler commits to the top [22:42:27 CET] <ubitux> tmm1: don't you leak prev_string somehow? [22:42:47 CET] <ubitux> like, the last one [22:42:56 CET] <tmm1> yes, good catch [22:44:10 CET] <tmm1> ubitux: fixed [22:46:43 CET] <ubitux> i feel like the flush is incomplete [22:46:57 CET] <ubitux> like maybe missing a free of prev_line, resetting prev_cmd too [22:47:08 CET] <ubitux> and maybe some more [22:49:34 CET] <ubitux> also, sorry to go back to that timestamp fix one [22:49:54 CET] <tmm1> i can move flush further down the patchset and include those [22:50:03 CET] <ubitux> but the timing of the dialogue changed from 0:00:12.36 0:00:40.83 to 0:00:40.83 0:00:59.07 [22:50:07 CET] <ubitux> is it really correct? [22:50:22 CET] <tmm1> ubitux: that sample has no audio so i can't tell [22:50:34 CET] <tmm1> but in all the samples i've tested, the new timestamps are correct [22:50:47 CET] <ubitux> they were completely broken previously? [22:50:49 CET] <tmm1> you can try it with movie.ts for instance, that one is very apparent [22:51:30 CET] <ubitux> why wasn't it detected before? [22:51:48 CET] <ubitux> i mean... 30s is kind of a large gap :p [22:51:52 CET] <ubitux> anyway ok.. [22:52:33 CET] <tmm1> i asked the same question, then spent two weeks rewriting this decoder =) [22:52:40 CET] <ubitux> :D [22:53:03 CET] <tmm1> i wish that sample did have audio [22:53:21 CET] <ubitux> i think there was a larger sample [22:53:25 CET] <ubitux> and it was cut down several time [22:53:30 CET] <ubitux> i can dig up the ml [22:55:47 CET] <ubitux> one is here, but might not be this one http://samples.ffmpeg.org/MPEG2/subcc/ClosedCaptions/subccItalic.mpg [22:56:17 CET] <ubitux> more here: [22:56:19 CET] <ubitux> http://samples.ffmpeg.org/MPEG2/subcc/ClosedCaptions/Starship_Troopers.vob [22:56:20 CET] <ubitux> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1482/NCIS.wtv [22:56:21 CET] <tmm1> looks different, has separate subtitle track [22:57:04 CET] <tmm1> dvd_subtitle tracks on the second as well [22:59:55 CET] <tmm1> ubitux: also that sample in fate is only 4s so i dunno how we're pulling 60s of subs out of it [23:00:27 CET] <ubitux> tmm1: http://gsocdev.ccextractor.org/~anshul/test_video/ [23:00:29 CET] <ubitux> here it is [23:00:44 CET] <ubitux> Closedcaption_atsc_rollup.ts probably [23:01:29 CET] <ubitux> tmm1: ok ok [23:02:04 CET] <tmm1> yep that's it [23:02:12 CET] <tmm1> watching now, the word "Safety" starts at 40s in [23:02:38 CET] <tmm1> seems to match the realtime output, S shows up at :43 [23:03:18 CET] <ubitux> but doesn't match the buffered one at all [23:03:25 CET] <ubitux> unless i'm missing something [23:03:41 CET] <tmm1> oh i used Closedcaption_rollup.ts [23:04:25 CET] <tmm1> ugh yea the non-buffered looks wrong [23:05:12 CET] <tmm1> it must be a difference between popon and rollup then [23:06:50 CET] <tmm1> if i run my ffmpeg on both those ts files, even in buffered mode, the output is correct [23:06:55 CET] <tmm1> there's something different about the fate version [23:07:13 CET] <ubitux> yeah iirc it's truncated more or less savagely [23:07:25 CET] <ubitux> so you might be missing essential events [23:07:41 CET] <ubitux> we'll probably need a better test [23:07:53 CET] <ubitux> (the raw i pasted might be good if we can feed it to the decoder) [23:09:31 CET] <tmm1> http://pastie.org/10678449 [23:10:29 CET] <ubitux> can you paste a diff -u? [23:10:48 CET] <ubitux> no diff with Closedcaption_rollup.ts ? [23:11:02 CET] <tmm1> the timestamps are different on each line [23:11:12 CET] <tmm1> they're shifted down by one [23:11:30 CET] <tmm1> it seems plausible my patch is incorrect for rollup [23:12:07 CET] <tmm1> i was testing primarily with movie.ts, which is popon and was definitely off-by-one in the current decoder [23:13:02 CET] <tmm1> so for POPON, when EOC comes in that's when the cc is first shown, hence the sub->pts should match the pts of the EOC [23:13:28 CET] <tmm1> but in ROLLON, since the cc is being shown progressively, the sub->pts is actually the pts of the *previous* NEWLINE [23:16:20 CET] <ubitux> so i still wait for merging this commit? [23:16:34 CET] <tmm1> yes i need to redo it [23:17:14 CET] <ubitux> ok, i'm going back to my stuff then [23:17:15 CET] <tmm1> thanks for finding that sample [23:17:18 CET] <ubitux> poke me anytime [23:17:23 CET] <tmm1> cheers [23:17:27 CET] <ubitux> i might go to sleep soon though [23:19:58 CET] <ubitux> anyone getting that "http: No trailing CRLF found in HTTP header." with twitch streams? [23:20:07 CET] <ubitux> like, every 1-3s [23:20:17 CET] <ubitux> is this warning really geniune? [23:21:13 CET] <BtbN> Sounds like something Twitch would do. [23:22:12 CET] <BtbN> They also broke their IRC, so that you could not connect without giving a PASS line. Even when you didn't want to login, you had to send an empty line instead, because their parser was bad... [23:23:27 CET] <nevcairiel> ubitux: if your ffmpeg is slightly old, it may have been a bug that was fixed [23:23:31 CET] <nevcairiel> or maybe the fix was never pushed [23:23:32 CET] <nevcairiel> idk [23:24:25 CET] <ubitux> it's probably using ff 2.8.4 from my system (mpv) [23:26:18 CET] <nevcairiel> fix might be nwer than that [23:26:21 CET] <nevcairiel> i dont remember exactly [23:26:35 CET] <ubitux> ok ok, didn't notice a fix [23:28:08 CET] <c_14> Should be this one https://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=f00ec7eb1b94b31f… [23:28:30 CET] <ubitux> ah great [23:28:31 CET] <ubitux> thx [23:33:26 CET] <Compn> you can get in twitch chat via irc ? [23:33:33 CET] <nevcairiel> barely [23:33:38 CET] <nevcairiel> their IRC emulation sucks terribly [23:33:40 CET] <Compn> for each channel ? [23:33:48 CET] <Compn> or whatever they call it [23:35:35 CET] <cone-686> ffmpeg 03Michael Niedermayer 07master:5c8467a07c65: avformat/ivfenc: fix division by zero [23:35:49 CET] <BtbN> It's not IRC emulation [23:35:58 CET] <BtbN> It actualy is IRC, their official client also uses it that way [23:36:15 CET] <nevcairiel> if anything its "IRC" [23:36:17 CET] <BtbN> You can even see it complaining about now knowing a bunch of IRC commands if you open the debug console [23:36:29 CET] <nevcairiel> its like a homebrew version of IRC that happens to work with some clients [23:36:47 CET] <BtbN> Except for their Whisper-System it's fully IRC compliant. [23:36:56 CET] <BtbN> They even support a bunch of IRCv3 stuff [23:37:08 CET] <nevcairiel> except you need to do some trickery to even login [23:37:17 CET] <Compn> oh theres a twitch irc guide [23:37:18 CET] <Compn> thx [23:37:25 CET] <BtbN> It doesn't behave like your usual IRC server, but it does fully comply with the IRC protocol. [23:37:39 CET] <nevcairiel> the protocol also defines behavior =p [23:37:55 CET] <BtbN> You just connect to irc.twitch.tv with your username and an oauth token. [23:37:58 CET] <BtbN> as PASS [23:38:11 CET] <BtbN> It's unencrypted, so they don't want you to use your normal password [23:53:40 CET] <Compn> chinese smiley faces in vp9 huh [23:53:50 CET] <Compn> and using ffmpeg to display these in mozilla firefox? [23:54:00 CET] <Compn> sounds like a disaster waiting to happen (libstagefrieght anyone?) [23:55:38 CET] <Compn> wm4 : good try , trying to get web developers to not be stupid. i fully agree with the theory, just not the reality :( [23:55:59 CET] <atomnuker> I like the idea of caching frames for looping videos [23:56:16 CET] <atomnuker> but I doubt anyone would like browsers to consume any more memory than they already eat [23:57:17 CET] <TD-Linux> I would be happy with actually seamless looping in firefox for starters :) [00:00:00 CET] --- Sat Jan 9 2016

1 0

ffmpeg.log.20160108
by burek 09 Jan '16

09 Jan '16

[00:00:21 CET] <JakeJ> libfdk_aac, libfaac, and aac, seems to just ignore my commands and convert to either 7.1, 6, or 5 channel files [00:47:18 CET] <Wat> Is there anyway to use a videos duration as a value for the drawtext function? Trying to generate posters with the videos duration on them, and google isn't brining up much. [01:17:50 CET] <Pinchiukas> I know this might be a weird question for this channel but: can anyone suggest an alternative on Linux that would give me the details of an MPEG stream? [01:25:08 CET] <JakeJ> Pinchiukas - do you mean like mediainfo details? [01:25:21 CET] <Pinchiukas> JakeJ: Yeah, I think so. :) [01:25:28 CET] <JakeJ> try mediainfo [01:25:39 CET] <JakeJ> https://mediaarea.net/en/MediaInfo [01:25:53 CET] <JakeJ> i use that for all platforms [01:30:24 CET] <Pinchiukas> That's a nice alternative. Though it looks like it doesn't support streams which I'm doing. :) [01:34:22 CET] <JakeJ> what type of streams? mpeg should be fine [01:34:35 CET] <JakeJ> i haven't found a stream it doesnt get the info from yet [01:36:54 CET] <Pinchiukas> MPEG-TS [01:37:09 CET] <Pinchiukas> It doesn't seem it has a mechanism for streaming at all. [01:39:30 CET] <JakeJ> oh yea [01:39:47 CET] <JakeJ> anything for HLS / MPEG-DASH ts files i dont think it works with [01:39:56 CET] <JakeJ> i haven't really found anything for those files yet [01:40:11 CET] <Pinchiukas> I guess I'm kind of stuck with ffprobe... [01:44:46 CET] <Pinchiukas> I can't make it shut up about the versions of libraries that it's using. [01:48:25 CET] <klaxa> isn't there -hide_banner? [01:48:43 CET] <klaxa> Pinchiukas: ^ [02:17:59 CET] <kingron> greetings [02:18:47 CET] <kingron> I would like to convert my mpg's (no adio track) to ogv (with a silent audio track) [02:18:57 CET] <kingron> I use: ffmpeg -ar 48000 -ac 2 -f s16le -i /dev/zero -i input.mpg -c:v libtheora -c:a libvorbis -q:v 10 -q:a 4 -shortest -strict experimental -y out.ogv [02:20:12 CET] <kingron> but the duration of video/audio are not the same as I expected [02:20:22 CET] <kingron> (checked with mediainfo) [02:21:08 CET] <kingron> video: 4s 4ms, audio: 3s 947ms [02:21:45 CET] <Pinchiukas> klaxa: seems I have an old version that pretty much sucks. [02:25:38 CET] <waressearcher2> kingron: hallo und helzlich willkommen [02:25:50 CET] <kingron> hi :D [02:26:07 CET] <waressearcher2> kingron: wie geht's es dir ? [02:26:22 CET] <TD-Linux> kingron, that's a really small mismatch, does it cause problems with playback? [02:26:31 CET] <kingron> yes [02:26:42 CET] <kingron> in loop it lags [02:26:49 CET] <kingron> not nice [02:27:21 CET] <kingron> 4s 67ms [02:27:30 CET] <kingron> 4s 63ms [02:27:42 CET] <kingron> is another one [02:28:18 CET] <TD-Linux> hmm. maybe ffmpeg is not correctly putting exact vorbis sample lengths in [02:29:34 CET] <kingron> I think it's caused by -shortest, is there anything else I could try? [02:29:48 CET] <TD-Linux> do you need an audio track? [02:30:28 CET] <TD-Linux> it sounds like a ffmpeg bug, what you're doing should work [02:31:00 CET] <kingron> hmmm [02:31:49 CET] <TD-Linux> if you don't actually need audio, browsers should play a ogv without audio (-an) [02:32:26 CET] <kingron> well I need audio, because the game engine expect an audio track [02:32:35 CET] <kingron> for sync purpose [02:32:55 CET] <kingron> can I set the lenght manually? [02:36:18 CET] <TD-Linux> you could encode the vorbis separately at the exact length and then do -c:a copy, maybe that would work [02:41:06 CET] <c_14> Or try getting rid of -shortest and use -t <length> might work [02:44:00 CET] <TD-Linux> yet another option is to convert video to y4m intermediate, audio to wav, and use theora_encode [02:44:29 CET] <TD-Linux> (theora_encode can read from a pipe so the y4m can be streamed out from ffmpeg) [02:48:05 CET] <JakeJ> anyone around that knows much about complex aac audio filters? i'm trying to make an 8 channel octagonal audio filter in aac and having issues libfdk_aac, libfaac, and aac, seems to just ignore my commands and convert to either 7.1, 6, or 5 channel files [03:41:05 CET] <t4nk971> Hi - I am trying to use ffmpeg and pass the equivalent arguments to ffmpeg as the below in iSkysoft. [03:41:10 CET] <t4nk971> Video Codec: H.264 Resolution: 1280*720 Frame Rate: 30 fps Bit Rate: Custom 3000 kbps Audio Codec: AAC Channel: Smart Fit Sample Rate: Smart Fit Bit Rate: Smart Fit [03:41:21 CET] <t4nk971> this is my first attempt [03:41:25 CET] <t4nk971> ffmpeg -i /0001.mp4 -acodec aac -ar 48000 -ab 128k -strict -2 -coder ac -vcodec libx264 -threads 0 -deinterlace -s 1280x720 -b:v 3000k -cmp +chroma -g 250 -partitions +parti4x4+partp8x8+partb8x8 -i_qfactor 0.71 -keyint_min 25 -b_strategy 1 -r 30 -movflags faststart /0001new.mp4 [03:41:44 CET] <t4nk971> but the size of the files is about double in ffmpeg...I am hoping to find out where I am mistaken [08:37:39 CET] <k_sze> Does ffmpeg automatically use multiple threads to decode FFV1 when possible, regardless of the slices? [09:05:14 CET] <k_sze> And if I run ffmpeg without specifying -threads, how do I know how many threads it's actually using? [09:07:48 CET] <pinPoint> you don't i guess but it should automagically just go. [09:08:29 CET] <pinPoint> libvpx is the only one you have to specify and even after that it does not move fast enough. [09:09:02 CET] <pinPoint> check your processor scaling speed on task manager or a widget that tracks cpu usage [09:09:53 CET] <pinPoint> from my observation at least. [09:16:41 CET] <furq> k_sze: the default is -threads auto which lets the encoder decide [09:16:45 CET] <furq> the encoder will usually decide to use 1 [10:33:07 CET] <k_sze> And why is it that if I encode as ffv1 level 3 and then decode it, I get a whole bunch of invalid SAR 0/0 messages? [10:33:15 CET] <k_sze> It's slightly worrying. [10:33:55 CET] <k_sze> I mean ffv1 level 3 with 4 or more slices [11:29:58 CET] <ealdeguer> Hi all, I'm streaming with ffmpeg a udp stream to a rtmp server, all worked fine for month, but I just receive that error, and I don't understand it : av_interleaved_write_frame() broken pipe [11:29:58 CET] <ealdeguer> no more output streams to write to, finishing [11:30:01 CET] <ealdeguer> can you help ? thx [13:27:17 CET] <Zucca> Hi. I have played a bit around with VP9. Is there s switch to set the "compression level" using libvpx-vp9? I mean the same way like with libx26{4,5} -preset <preset level>. libvpx-vp9 doesn't seem to take -preset. Right? [13:30:08 CET] <furq> Zucca: -speed [13:30:32 CET] <furq> 4 is fastest, 0 is slowest (iirc) [13:30:52 CET] <Zucca> furq: Ah. Thanks. [16:58:08 CET] <Akerus> Hi there, I got a problem with ffmpeg. When I run ffmpeg (without any parameters) in the terminal, I get a segmentation fault in the ld-2.13.so library. It happens immediatly and everytime. ffprobe does not work as well... anybody can help? [17:06:18 CET] <c_14> Distro? [17:06:24 CET] <c_14> FFmpeg version? [17:06:33 CET] <c_14> Did you build it yourself? [17:07:19 CET] <Akerus> debian 7, and the ffmpeg version i can not find out... it won't tell me [17:07:46 CET] <c_14> Where did you get it from? debian repos? [17:08:43 CET] <Akerus> that could be... was a few years ago... it has to be an older version but it worked at some point [17:09:37 CET] <c_14> wheezy doesn't have ffmpeg from FFmpeg. try using a static build [17:09:39 CET] <c_14> http://johnvansickle.com/ffmpeg/ [17:10:11 CET] <Akerus> we have a second server, wheezy as well, there it works just fine [17:10:27 CET] <c_14> sure it's the same binary? [17:10:35 CET] <c_14> same ld version etc [17:11:18 CET] <Akerus> it should be the same version, one is integration server and one is production server [17:13:23 CET] <c_14> Compare the checksums of the binaries on each server [17:13:26 CET] <c_14> check ldd output [17:15:51 CET] <Akerus> the ffmpeg binaries have different file sizes [17:15:57 CET] <Akerus> so they're not the same [17:17:37 CET] <Mavrik> And you're not using new static binaries you have control over for that? :- [17:17:39 CET] <Mavrik> :/ [17:18:55 CET] <Akerus> on production we are running 1.2.12 [17:21:32 CET] <Akerus> ok, I'm trying to get it from the same source for integration server. [17:49:02 CET] <Akerus> Ok, reinstalled FFMPEG 1.2.12 and the libraries. Same error still happening. Any ideas? [17:53:40 CET] <Akerus> [3656326.178705] ffmpeg[12816]: segfault at 8 ip 00007f8dbb6b0113 sp 00007fffec157650 error 4 in ld-2.13.so[7f8dbb6a5000+20000] [17:53:50 CET] <Akerus> with gdb: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7de8113 in ?? () from /lib64/ld-linux-x86-64.so.2 [17:53:58 CET] <podman> yo [17:57:00 CET] <fritsch> that's not even nearly a proper backtrace [17:57:40 CET] <DHE> that's not a backtrace, it's just one line. I'd say install the debuginfo packages but as a non-debian user I'm just walking away slowly [17:57:55 CET] <fritsch> DHE: i rather think his glibc is from stoneage [17:57:57 CET] <fritsch> if I see this right [17:58:06 CET] <DHE> 2.13 isn't THAT bad... [17:58:11 CET] <Akerus> I'm just running ffmpeg without parameters... could there be anything interesting in the backtrace? [17:58:22 CET] <fritsch> Akerus: how did you get this ffmpeg? [17:58:35 CET] <fritsch> i can copy a whole lot of binaries that do the same on your system :-) [17:58:48 CET] <Akerus> wheezy-backports [17:58:55 CET] <fritsch> -> #debian [17:59:01 CET] <fritsch> will help you [17:59:12 CET] <fritsch> no one besides debian knows what they packaged this time [17:59:49 CET] <Akerus> we have another server, also wheezy and ffmpeg 1.2.12 where it runs just fine... [18:00:13 CET] <fritsch> yeah - then blame the server? :-) [18:00:53 CET] <fritsch> Akerus: apt-get install ffmpeg-dbg [18:00:59 CET] <fritsch> gdb /path/to/ffmpeg [18:01:08 CET] <fritsch> set logging on mylog.txt [18:01:09 CET] <fritsch> run [18:01:15 CET] <fritsch> thread apply all bt [18:01:24 CET] <fritsch> press return until no output [18:01:25 CET] <fritsch> quit [18:01:33 CET] <fritsch> post the mylog.txt to e.g. paste.debian.org [18:01:45 CET] <fritsch> and provide the link [18:03:55 CET] <Akerus> a college of mine thinks it could be a kernel problem... he currently looks into that, i have to wait [18:04:20 CET] <Akerus> *colleague [18:06:16 CET] <fritsch> i don't think so - for me it seems that this was a pre wheezy server before [18:06:21 CET] <fritsch> and upgraded in a wrong way [18:36:23 CET] <danjanz> exit [18:40:32 CET] <Akerus> fritsch: did the gdb run: http://pastebin.com/7kRD4b0g [18:40:42 CET] <Akerus> quite short and not very much information [18:40:59 CET] <fritsch> you did not install ffmpeg-dbg right [18:41:37 CET] <fritsch> though it really seems you are running an ffmpeg package not matching your libc6 [18:41:46 CET] <Akerus> what should it look like? [18:41:55 CET] <fritsch> it should not segfault [18:42:55 CET] <fritsch> Akerus: dpkg -l |grep ffmpeg | pastebinit [18:42:58 CET] <relaxed_> Akerus: why not install a recent version on both servers? http://johnvansickle.com/ffmpeg/ [18:43:03 CET] <fritsch> Akerus: apt-cache show ffmpeg | pastebinit [18:43:26 CET] <fritsch> relaxed_: yeah, that's even much better [18:43:46 CET] <fritsch> Akerus: download what he said and put the ffmpeg binary to /usr/local/bin and stop caring [18:44:09 CET] <Akerus> nope too much testing required for raising the ffmpeg-version [18:44:17 CET] <Akerus> that will be the last resort [18:46:29 CET] <relaxed_> was ffmpeg even in wheezy? [18:46:48 CET] <furq> no [18:48:05 CET] <furq> there's an ffmpeg package but it's libav in disguise [18:49:23 CET] <furq> it's not in wheezy-backports either [18:49:30 CET] <Delta706> I am trying to convert a ts file with 2.8.4 but I am getting the error "could not find codec parameters" [18:50:05 CET] <relaxed> I hope it's not from that repo where they lost the domain name and some other party took it over. [18:50:12 CET] <furq> https://www.deb-multimedia.org/dists/oldstable-backports/main/binary-amd64/… [18:50:15 CET] <furq> you mean this one [18:50:19 CET] <furq> from the version number i'm going to say it is [18:51:04 CET] <relaxed> yeah, that's scary [18:51:42 CET] <relaxed> Delta706: pastebin.com the command and all console output [18:52:24 CET] <furq> "Conflicts: ffprobe" what [18:52:51 CET] <furq> oh nvm apparently that used to be a standalone package [18:54:47 CET] <Akerus> fritsch: first command: http://pastebin.com/zmJFBxBP [18:55:09 CET] <furq> good guess furq [18:55:44 CET] <Akerus> fritch: and the second one: http://pastebin.com/cZ2acVBy [18:56:34 CET] <Delta706> http://pastebin.com/xBwiNNJq [18:58:07 CET] <relaxed> Delta706: your ffmpeg lacks libvpx support, needed for webm. try http://johnvansickle.com/ffmpeg/ or recompile with libvpx and libvorbis support [19:03:51 CET] <relaxed> Delta706: https://trac.ffmpeg.org/wiki/Encode/VP9 [19:06:00 CET] <Delta706> okay I am building now [19:06:39 CET] <micechal> are "128k" and "128K" the same in ffmpeg? if so, is it 131072, or rather 128000? [19:12:35 CET] <micechal> when used like "ffmpeg -i in.flac -c libopus -b:a 128k out.opus" it seems to resolve to 128000 [19:12:35 CET] <DHE> it uses SI/standardized units. 'k' should lower case [19:12:51 CET] <DHE> use ki for 1024-based units [19:13:05 CET] <micechal> as in kibibytes? [19:14:51 CET] <micechal> do you think it could make some difference to the quality of encoding? I mean, I know 128 kib is a bit more than 128 kb, and the file will be bigger as well, but do you think the encoder could somehow do better quality-per-filesize when using powers of 10 or powers of 2? [20:21:17 CET] <Delta706> relaxed: I have done some more experiments and it seems that my problem is an input problem. If I convert from mp4 to mkv, all is well. If I convert from ts to mkv, I get the error. I looked at the output from ./configure but cannot determine which item to include to allow me to decode ts [20:30:29 CET] <DHE> there are some h264 differences between mp4 and ts. maybe ffmpeg doesn't handle them right... [20:31:54 CET] <Delta706> the error is "could not find codec" which suggests that my build of ffmpeg does not know how to handle this type at all [20:53:10 CET] <Delta706> okay I have downloaded a ts file. and this file, it converts [22:32:13 CET] <JakeJ> anyone around that knows much about complex aac audio filters? i'm trying to make an 8 channel octagonal audio filter in aac and having issues libfdk_aac, libfaac, and aac, seems to just ignore my commands and convert to either 7.1, 6, or 5 channel files [22:33:36 CET] <iive> atomnuker might know something about aac... just a feeling [22:34:00 CET] <JakeJ> help me atomnuker, you are my only hope [22:35:40 CET] <atomnuker> yeah, non-standard channel mapping in AAC is only possible with encoders that support Programmable Channel Elements [22:36:18 CET] <atomnuker> ours doesn't and faac doesn't and I don't think libfdk does either [22:39:20 CET] <atomnuker> and I think only a few decoders actually support those (but I doubt they correctly map every channel) [22:49:34 CET] <JakeJ> yea the only method i can find for getting aac to work with 8 channel audio is using afconvert on mac with an octagonal flag [22:49:58 CET] <JakeJ> but that means hopping from linux to mac in our pipeline or dedicate our entire pipeline to mac [22:55:06 CET] <atomnuker> JakeJ: I did find this thread: http://webcache.googleusercontent.com/search?q=cache:nVZqeYjyDn4J:forum.vid… [22:58:03 CET] <JakeJ> yea thats me [22:58:06 CET] <JakeJ> lol [00:00:00 CET] --- Sat Jan 9 2016

1 0

ffmpeg-devel.log.20160107
by burek 08 Jan '16

08 Jan '16

[02:01:51 CET] <cone-509> ffmpeg 03Michael Niedermayer 07master:13f266b50cc7: avcodec/mpegvideo_enc: Clip bits_per_raw_sample within valid range [02:01:52 CET] <cone-509> ffmpeg 03Michael Niedermayer 07master:0869ff7e9d17: avcodec/utils: Check bits_per_raw_sample on video encoder open [03:31:31 CET] <doublebackslash> hello! Got what I hope to be a quick question about audio filters and audio sync [03:32:12 CET] <doublebackslash> I'm working on a filter, my first one, and when I use it the audio is randomly out of sync. Always late relative to video. It does take multiple audio streams [03:32:49 CET] <doublebackslash> I suspect that I'm doing something horrible with the pts but I'm not sure what. I attempted to mimick the af_mix filter, but I may have missed something [03:33:12 CET] <doublebackslash> Not sure where would be a good place to look. Any thoughts would be appeciated [05:40:27 CET] <cone-717> ffmpeg 03Ganesh Ajjanagadde 07master:369b161d8e6d: ffmpeg: replace log2 by av_log2 [10:00:43 CET] <cone-150> ffmpeg 03Paul B Mahol 07master:9f17d4ae7e83: avfilter/formats: fix leak of formats on error [10:46:26 CET] <wm4> why is everyone suddenly so interested in closec captions? [10:47:04 CET] <wm4> also lol at #5057 [10:57:53 CET] <rcombs> heh, what a saga [10:58:30 CET] <rcombs> maybe do what every other piece of software does and actually build against a major version [10:58:45 CET] <rcombs> this is how library dependencies work [11:02:14 CET] <wm4> they're dynamically loading - maybe to run on systems that don't have libavcodec installed? [11:03:42 CET] <wm4> oh, and of course they want to work with Libav too [11:11:59 CET] <nevcairiel> they want to provide binary distributions in the fragmented linux world [11:12:02 CET] <nevcairiel> no wonder thats painful [11:14:43 CET] <wm4> not as painful as on windows [11:14:59 CET] <wm4> where you need to depend on a 20 year old unmaintained dll [11:18:18 CET] <nevcairiel> nah on windows you just distribute the things you need yourself [11:19:25 CET] <nevcairiel> and if you are referring to msvcrt.dll, thats actually not true, thats the same DLL the entire OS uses as the C runtime, how old it is depends on how old your OS is [11:29:10 CET] <wm4> well it's not like firefox couldn't just redistribute libavcodec [11:29:22 CET] <nevcairiel> apparently they dont want to [11:29:39 CET] <nevcairiel> they go through this big hack crap to avoid just that [11:29:59 CET] <nevcairiel> noone would want to build binary compat with a wide range of versions if it can be avoided, its just painful [11:42:35 CET] <rcombs> either vendor it or build for the distro's shipping version [11:42:56 CET] <rcombs> (Chrome vendors it) [11:43:24 CET] <nevcairiel> apparently its a common use-case for people to just download a firefox binary of the website, and they dont want to offer 100 versions, which is understandable [11:43:37 CET] <nevcairiel> but then trying to support system libraries on 100 distributions is just crazy :D [11:47:25 CET] <rcombs> do they only do this for ffmpeg [11:47:30 CET] <rcombs> oh, I bet it's some patent bullshit [11:48:02 CET] <nevcairiel> no idea [11:48:12 CET] <nevcairiel> many other libraries are much more stable in their interface [11:48:21 CET] <nevcairiel> mostly because they just dont change anymore [11:48:45 CET] <rcombs> lav*'s interface instability is in part because its interface is large [12:04:32 CET] <wm4> nevcairiel: what's the status of HEVC main 10 dxva? [12:04:58 CET] <wm4> doesn't seem to be in yet? [12:05:09 CET] <wm4> there was also some sort of API problem? [12:05:59 CET] <nevcairiel> there is no "problem" as such, I am just undecided what to do about the issue with naive user code that might break when its pushed [12:06:23 CET] <wm4> well I'd say just let the downstreams deal with the regression [12:07:12 CET] <nevcairiel> i should push some of the preparation patches, like p010 for lavu and sws [12:07:21 CET] Action: nevcairiel goes to send them [12:07:44 CET] <wm4> there's no p010 yet? huh [12:11:38 CET] <nevcairiel> there, senbd [12:12:01 CET] <nevcairiel> -b [12:14:33 CET] <nevcairiel> if someone really wants to use the sws p010 support, someone should probably SIMD it based on the nv12 simd [12:14:37 CET] <nevcairiel> otherwise its crawling slow [12:16:55 CET] <wm4> is there a way to actually test these pixdesc things? [12:17:25 CET] <nevcairiel> i tested it by 10-bit decoding, no idea otherwise :D [12:19:27 CET] <nevcairiel> there is some basic test in fate for the pixdescs, but no clue what it really tests for [12:19:43 CET] <nevcairiel> there is an automated test if a pixfmt supports input and output in sws [12:19:51 CET] <nevcairiel> but since p010 doesnt support output yet, thats not used [12:20:05 CET] <nevcairiel> (writing output support in sws is far harder than input <.<) [12:21:38 CET] <wm4> even though it's just 16 bit nv12 (which we support?) with a shift applied [13:53:41 CET] <atomnuker> BBB: thanks for the review [13:53:54 CET] <atomnuker> yeah, there's still some float logic left in the PVQ system [13:54:11 CET] <atomnuker> but the overhead should be minimal [13:54:39 CET] <atomnuker> the casting to (uint8_t) when calling anything in the dsp is because nothing's been templated already [13:56:06 CET] <atomnuker> the output of the dequantizer is 8 bits or 8 bits + 4 bits (coeff_shift) in case of FPR [13:56:17 CET] <atomnuker> so yeah, 16 bit wide integers should be enough [13:59:04 CET] <atomnuker> for the coefficients that is, with 32 bits for intermediaries in the iDCT [14:38:00 CET] <BBB> atomnuker: thats what I thought [14:38:08 CET] <BBB> atomnuker: so, 16bits will have huge advantages when writing simd [14:38:24 CET] <BBB> atomnuker: and I fully udnerstand that for 10/12bpp, youll probably need 32bit coeffs, but the templating logic should help with that [14:39:04 CET] <BBB> atomnuker: did you find the libavcodec/bit_depth_template.c macros helpful? or not at all? [14:39:20 CET] <BBB> atomnuker: and for floats, is it intended to disappear in daala sometime soon? [14:39:31 CET] <BBB> atomnuker: I particularly find the log/sqrt/pow/& stuff kind of strange [14:39:36 CET] Action: Daemon404 wonders if nevcairiel is planning to add w3fdif to lav [14:39:39 CET] <BBB> but thats probably daala, not you [14:39:45 CET] <atomnuker> BBB: I would have used them but they lacked a RENAME function [14:39:55 CET] <atomnuker> yeah, that's Daala, though I did remove a few [14:40:12 CET] <BBB> FUNC()? [14:40:22 CET] <BBB> or FUNCC() for _c suffix [14:40:39 CET] <atomnuker> ah, missed those [14:40:49 CET] <BBB> \o/ [14:47:12 CET] <wm4> I have to say pixdesc doesn't make too much sense to me [14:47:37 CET] <wm4> for example, AV_PIX_FMT_MONOWHITE has the component shift field set to 7 [14:48:14 CET] <wm4> why? because it'd expand it to 8 bit? but why 8 bit? what about properly setting the lower bits, instead of just shifting in zeros for the MSBs? but this makes no sense either way... [14:49:51 CET] <wm4> nevermind, that's not what it's supposed to do [14:50:34 CET] <Daemon404> every time i read pixdesc i need to stare at it for an hour [14:50:40 CET] <Daemon404> then i forget how it works immediately [14:52:04 CET] <wm4> yeah, and I was also stupid enough to extract major bits of information out of pixdesc in my code [14:52:24 CET] <nevcairiel> i wondered about using it, but i never bothered [14:52:33 CET] <nevcairiel> i have a long list to map av pixfmts to my internal ones instead =p [15:01:47 CET] <Daemon404> thats mroe tedious but probably saner [15:04:02 CET] <nevcairiel> and yes Daemon404, its definitely a consideration, it seems faster and better or higher quality than yadif [15:04:35 CET] <durandal_1707> it all looks same to me [15:19:14 CET] <wm4> kierank: do you have anything that decodes to NV20? [15:20:09 CET] <kierank> It is x264s native format for 8-bit 422 [15:20:52 CET] <wm4> isn't NV20 10 bit per component? well maybe I'm reading pixdesc wrong again [15:20:56 CET] <nevcairiel> wouldnt that be NV16 [15:21:13 CET] <nevcairiel> 8bit 422 has 16bit per pixel [15:21:27 CET] <wm4> NV16 is 8 bit per component, 4:2:2 [15:22:11 CET] <wm4> NV20 looks like the same but 2 bytes per component, with padding in the MSB [15:22:35 CET] <nevcairiel> and 10 bit data? [15:22:39 CET] <wm4> yeah [15:22:51 CET] <nevcairiel> odd format [15:23:03 CET] <wm4> kierank added it [15:23:32 CET] <kierank> Sorry 10-bit [15:23:48 CET] <wm4> so how can I test it? [15:32:46 CET] <kierank> can't remember how I tested it [15:32:49 CET] <kierank> but iirc I fed a file into x264 [16:11:12 CET] <kierank> I will be writing a v210 to nv20 converter in the next weeks [16:31:39 CET] <kierank> poor nevcairiel having to work on swscale [16:32:17 CET] <nevcairiel> input support wasnt too bad, output support l ooked like crazy magic, hence not done =p [16:33:43 CET] <kierank> yeah [16:39:33 CET] <wm4> wasn't libswscale recently refactored to make this kind of thing easier? [16:49:00 CET] <durandal_1707> nope, wait for avscale [16:52:51 CET] <JEEB> why not zscale? [16:53:37 CET] <durandal_1707> its in c++ IIRC [17:54:21 CET] <atomnuker> (BBB) how does using uint8_t cause random odd side effects and slowdowns [17:54:30 CET] <atomnuker> are compilers messing it up or? [17:54:46 CET] <BBB> uint8_t gives guarantees about the data range in a register [17:54:52 CET] <BBB> so it ands 255 the value at every call [17:54:56 CET] <BBB> just so its C compliant [17:55:10 CET] <BBB> (not at the call, but at the position where a function call occurs in the C code) [17:55:57 CET] <atomnuker> also what did you mean by using "fastdiv"? [17:57:07 CET] <atomnuker> as in the macro? [18:09:47 CET] <jamrial> BBB: is the av_clip patch ok to push? [18:12:00 CET] <BBB> yes [18:12:07 CET] <BBB> atomnuker: yes [18:12:07 CET] <kierank> wm4: hmm i was wrong I'm going to write a v210 to uyvy422 (10-bit) decoder [18:12:11 CET] <kierank> so that won't go into ffmpeg [18:12:14 CET] <BBB> jamrial: yes [18:13:10 CET] Action: wm4 mumbles something about useless pixel formats [18:14:04 CET] <kierank> but yeah nv20 is a bit useless [18:26:18 CET] <Daemon404> depends if you define useful as actually useful or "useful to hardware developers" [18:26:24 CET] <cone-715> ffmpeg 03James Almer 07master:f4c1a4848378: x86/intmath: add sse optimized av_clipf and av_clipd [22:09:38 CET] Action: Daemon404 sees ganesh suggesting gnulib [22:09:47 CET] Action: Daemon404 prepares to launch tactical nuclear missile [22:09:49 CET] <JEEB> iä iä [22:10:05 CET] <wm4> lol [22:10:09 CET] <Daemon404> to fix an "issue" [22:10:29 CET] <wm4> the fclose thing? [22:10:35 CET] <Daemon404> yes [22:11:32 CET] <Daemon404> oh the slides he linked are from the maintainer of gnulib. [22:13:47 CET] <J_Darnley> What? If there's errors using standard streams how will anything else work? [22:20:40 CET] <cone-715> ffmpeg 03Clément BSsch 07master:84a967df034b: lavu/common: fix FF_CEIL_RSHIFT() range comment [22:32:51 CET] <rcombs> Daemon404: bahahaha [22:34:48 CET] <cone-715> ffmpeg 03Clément BSsch 07master:90cd02059b6f: lavfi/deshake: use FF_CEIL_RSHIFT() [22:34:49 CET] <cone-715> ffmpeg 03Clément BSsch 07master:5fbe57c027d0: lavf/uncodedframecrcenc: use FF_CEIL_RSHIFT() [22:34:50 CET] <cone-715> ffmpeg 03Clément BSsch 07master:04826b7ff02f: lavu/common: add an explanation to FF_CEIL_RSHIFT() [22:34:56 CET] <Daemon404> gnulib contibuters go to the special hell [22:34:57 CET] <Daemon404> a la firefly [22:36:40 CET] <rcombs> pls add more giant monolithic dependencies [22:37:10 CET] <TD-Linux> please it's 2016, they are "frameworks" [22:37:17 CET] <wm4> gnulib is awesome, it's intended to make programs more portable, but actually makes them less portable [22:37:23 CET] <wm4> it does so by being an ifdef hell [22:37:29 CET] <durandal_1707> so where to contribute? [22:37:37 CET] <wm4> and accessing the internals of obscure libcs etc. [22:38:42 CET] <nevcairiel> speaking of special hell, sometimes these days I feel like it might be worthwhile to discuss merging of the libav changes again (or stopping of the same), the quality of their commits has gone down quite a bit IMHO, and more often than not its just fixes that we already have in a different shape or form, so maybe it might be worth it thinking about cherry-picking the interesting parts instead [22:39:25 CET] <wm4> cherry-picking sounds kind of cleaner [22:39:46 CET] <wm4> and I'm wondering if git really provides any advantages in our case with merges [22:40:04 CET] <nevcairiel> cherry picking would work equally well [22:41:02 CET] <nevcairiel> except you cant easily track anymore which commits are merged and which are not [22:41:06 CET] <durandal_1707> I mentioned that years ago [22:44:49 CET] <wm4> publicly reviewing the ported commits would be a big advantage over just having someone push "something" directly to git master [22:45:31 CET] <cone-715> ffmpeg 03Clément BSsch 07master:d64fe951c2ee: lavc/ccaption_dec: fix always true condition [22:47:13 CET] <durandal_1707> I even opened bug for that one [22:49:33 CET] <kierank> Daemon404: [22:49:34 CET] <kierank> https://github.com/Netflix/vp9-dash/blob/master/Downloads/VPCodecISOMediaFi… [22:49:35 CET] <kierank> hahahahaha [22:50:09 CET] <nevcairiel> vp9 in isom? [22:50:59 CET] <TD-Linux> yup! [22:50:59 CET] <kierank> yeah [22:51:24 CET] <J_Darnley> Are they just making stuff up now? [22:52:00 CET] <TD-Linux> a lot of people wanted a vp9 in mp4 mapping [22:52:09 CET] <nevcairiel> wtf is MPEG VCB [22:52:20 CET] <cone-715> ffmpeg 03Clément BSsch 07master:2ce29d17656f: lavu: add ff_parity() [22:52:21 CET] <cone-715> ffmpeg 03Clément BSsch 07master:00e96613f3e0: lavc/ccaption_dec: use ff_parity() [22:52:22 CET] <cone-715> ffmpeg 03Clément BSsch 07master:a1136ca973e3: lavc/g729dec: use ff_parity() [22:54:04 CET] <kierank> it's a good iea [22:54:08 CET] <kierank> mkv sucks [22:54:19 CET] <TD-Linux> nevcairiel, MPEG's standardization of vp8 [22:54:46 CET] <wm4> at least mkv can be actually streamed [22:54:53 CET] <wm4> instead of using stupid web hacks [22:54:58 CET] <nevcairiel> honestly all containers suck to some degree [22:55:08 CET] <wm4> without doubt [22:55:41 CET] <nevcairiel> mkv is underspecified and overimplemented with crazy features for anime people =p [22:56:04 CET] <TD-Linux> CELLAR is now trying to fix that [22:56:27 CET] <J_Darnley> nevcairiel: no better people! [22:56:44 CET] <kierank> wm4: true [22:56:52 CET] <kierank> but inaccurate timestamps, no DTS [22:56:53 CET] <kierank> ... [22:56:53 CET] <nevcairiel> I wonder if they are really going to try to offer a clean documentation of the codec mappings to any useful degree in CELLAR [22:56:54 CET] <rcombs> the biggest actual complaint I've seen about the MKV format (as opposed to other [reasonable] complaints about it being underspecified or having dumb anime features) is that timestamps aren't precise enough [22:57:18 CET] <wm4> kierank: I really hate the inaccurate timestamps, but they happen in "good" containers too [22:57:21 CET] <nevcairiel> you can nanosecond precision, its just that most muxers dont write them [22:57:23 CET] <TD-Linux> nevcairiel, well mappings for ffv1 and flac are clearly within the charter. I don't know about any others [22:57:43 CET] <TD-Linux> nanosecond precision is part of the problem [22:57:53 CET] <nevcairiel> TD-Linux: i was thinking more about mainstream use, not their archival codecs :D [22:57:53 CET] <wm4> nevcairiel: I doubt it, likely they'll only map ffv1 and raw video [22:58:07 CET] <kierank> nevcairiel: again not good enough [22:58:22 CET] <wm4> kierank: doesn't mpegts use 90khz [22:58:23 CET] <kierank> a / b [22:58:32 CET] <kierank> didn't say mpegts was a good container [22:58:40 CET] <wm4> but it's used for TV [22:58:51 CET] <kierank> exactly and TV is a 100 year of hacks [22:58:55 CET] <nevcairiel> isom probably has timebase-based timestamps [22:59:02 CET] <kierank> yup [22:59:20 CET] <TD-Linux> I think other codec mappings could fall under CELLAR, someone would just have to do them. [22:59:58 CET] <nevcairiel> and then there is the wide range of arcane mkv features that are not documented at all and if anyone asks the usual answer is "implement them so they work like Haali" =p [23:01:37 CET] <TD-Linux> anyway, mp4 is royalty free, and if mapping royalty free codecs into it increases their adoption, I'm all for it [23:01:56 CET] <nevcairiel> no mpeg patents on mp4/isom? [23:02:08 CET] <kierank> probably are [23:03:07 CET] <TD-Linux> nevcairiel, well it's hard to ever know for sure, but that seems to be the generally accepted view [23:03:47 CET] <nevcairiel> patents in software world are so silly [23:03:53 CET] <TD-Linux> DASH was also supposed to be royalty free and that's why it's based around MP4 and not ts [23:04:22 CET] <nevcairiel> you can never be actually "safe", even if you lock yourself in a room and write everything entirely from scratch, chance is you will use some concept someone patented before =p [23:04:44 CET] <fritsch> that's only an issue in the us [23:04:45 CET] <fritsch> then [23:04:46 CET] <TD-Linux> yup. but you can certainly make an effort to be safer [23:05:06 CET] <durandal_1707> what happened with nut standardization? [23:05:10 CET] <fritsch> where someone has patented: " way to connect to mysql with php" ... [23:05:11 CET] <TD-Linux> fritsch, no, go look at one of MPEG-LA's list of patents and the countries they are issued in... [23:05:19 CET] <wm4> sw patents are nothing but legal racketeering [23:05:29 CET] <fritsch> and invalid in germany [23:06:02 CET] <wm4> maybe the problem is simply that judges and law makers don't understand software [23:06:33 CET] <nevcairiel> the problem is that the big companies have money to pay lobbyists and the free developers like us do not [23:07:00 CET] <nevcairiel> company interests always win in this world [23:07:20 CET] <durandal_1707> Dolby may sue [23:07:32 CET] <fritsch> if they start in google play store ... [23:07:36 CET] <fritsch> nothing will be left :-( [23:07:46 CET] <fritsch> there are a lot applictions with ac3 decoders [23:08:05 CET] <fritsch> sort mediaplayers by download and sue those with > 3 million users :-) [23:08:22 CET] <philipl_> fritsch: DTS did this very aggressively. [23:08:40 CET] <nevcairiel> dont they get enough money from encoders and hardware licenses, they should be happy if people can play content in their format, it might make it more popular [23:09:19 CET] <fritsch> nevcairiel: do such people ever get _enough_ money? [23:09:41 CET] <fritsch> hehe at least vlc / kodi / some others also do ac3 transcoding :-) [23:10:15 CET] <philipl> fritsch: I'm actually surprised that DTS hasn't come after Kodi in the android store. [23:10:29 CET] <fritsch> philipl: as long as vlc has twice the number of downloads :-) [23:10:32 CET] <fritsch> we are safe, hehe [23:10:34 CET] <fritsch> at least for now [23:10:47 CET] <fritsch> but i am also very surprised [23:10:54 CET] <TD-Linux> nevcairiel, well H.264 was pretty loosely enforced, so apparently some had that idea [23:11:03 CET] <fritsch> and in fact we are working on a "free" version of kodi in playstore [23:11:07 CET] <fritsch> free as in: plays nothing [23:11:09 CET] <fritsch> :-( [23:11:12 CET] <wm4> maybe they're still trying to sort out who to sue [23:11:23 CET] <wm4> lol [23:11:26 CET] <philipl> fritsch: theora/ogg is all you need [23:11:30 CET] <fritsch> we try to use mediacodec itself [23:11:32 CET] <nevcairiel> TD-Linux: sure, but dolby and dts seem to be more aggressive about that [23:11:34 CET] <fritsch> in the future [23:11:41 CET] <fritsch> so that we can decode what the "box vendor" bought for [23:11:56 CET] <philipl> wm4: Funnily, when DTS first started going after people, there was no way to licence DTS decoding from them. [23:12:10 CET] <philipl> It was a couple of years before they had a licence you could buy [23:12:18 CET] <TD-Linux> nevcairiel, yup. and being in the position of "people can sue me but haven't because I don't have enough money yet" isn't so great either [23:12:25 CET] <fritsch> i think as long as kodi does not cost a single cent - they perhaps won't do anything [23:12:41 CET] <fritsch> but the very moment someone charges "one dollar" (not planned at all) [23:12:48 CET] <fritsch> or someone screams: we got .... donations [23:12:55 CET] <fritsch> i think they are highly interested [23:13:14 CET] <nevcairiel> TD-Linux: yeah ... it makes opensource projects somewhat safe, I mean, who is going to sue me and my little project, i dont make a single cent with it, but for companies trying to develop a small player based on open-source decoders ... not so much fun [23:13:26 CET] <TD-Linux> fritsch, well also someone using kodi might then not need to buy a bitstreaming receiver with dolby decoder [23:13:54 CET] <fritsch> TD-Linux: that's fully right - yes [23:14:12 CET] <nevcairiel> screw those HDMI devices, they have caused me nothing but trouble [23:14:19 CET] Action: nevcairiel switched to an external USB DAC [23:14:31 CET] <TD-Linux> also for some reason the audio camp in general seems to be much more intense about enforcement [23:14:53 CET] <TD-Linux> traditionally many audio codecs have been trade secrets. you had to buy a hardware dongle to encode/decode them [23:15:03 CET] <jamrial> ubitux: i thought you were going to use a generic c version of ff_parity instead of using av_popcount with non gnu compilers [23:15:13 CET] <jamrial> ubitux: as i said, you really don't need the configure check [23:16:00 CET] <ubitux> ah, my bad [23:16:08 CET] <jamrial> just an AV_GCC_VERSION_AT_LEAST check for the builtin version, and ideally a generic c version instead of popcount&1 for anything else [23:17:10 CET] <ubitux> well, i didn't know when gcc added it, and where it was efficient [23:17:53 CET] <ubitux> i thought it was better to give the opportunity to all compiler supporting the builtin to provide asm they consider good [23:18:19 CET] <ubitux> about the generic c, it can be done now, but given its limited usage it didn't look like a priority [23:18:33 CET] <ubitux> i couldn't use my generic c code bc u8 only :p [23:22:18 CET] <jamrial> ah, i see [23:22:55 CET] <jamrial> ubitux: anyway, looks like since gcc 3.4, so better remove the configure check and check for that version instead [23:23:09 CET] <ubitux> how did you get that gcc 3.4 info? [23:23:14 CET] <jamrial> google :p [23:23:22 CET] <ubitux> it wasn't documented in the builtin gcc page :( [23:23:55 CET] <jamrial> yeah, no mention of what version introduced anything there [23:24:15 CET] <jamrial> i see a lot of checks for 3.4 in our tree, so seems like a version where tons of builtins were added [23:25:22 CET] <ubitux> ok, well, feel free to change, but it might be relevant to add a smart c version [23:25:32 CET] <ubitux> because if clang ends up being not so dumb, it will be penalized [23:26:01 CET] <ubitux> also, it makes all other potential compilers aside [23:26:13 CET] <ubitux> not sure if any other relevant one uses __builtin_xxx [23:26:20 CET] <jamrial> icc [23:26:58 CET] <jamrial> anything that defines __GNU__ basically, so clang, gcc and icc [23:37:02 CET] <jamrial> ubitux: looks like av_popcount may not be defined at all in intmath.h if you don't include through common.h [23:37:14 CET] <jamrial> since av_popcount_c is in common.h [23:38:13 CET] <ubitux> fuck [23:38:36 CET] <ubitux> safe to include common.h from here? [23:39:03 CET] <jamrial> don't think so [23:39:52 CET] <ubitux> dammit [23:39:58 CET] <jamrial> how about moving this to common.h, renaming it to av_parity and making it work like av_popcount and many others? [23:40:56 CET] <jamrial> or just find a way to add a proper generic c version instead of using av_popcount :p [23:41:59 CET] <ubitux> could do both [23:43:40 CET] <jamrial> if we can add a generic c version then there's no need to move it to common.h [23:43:47 CET] <jamrial> otherwise yeah, probably no other way [23:44:21 CET] <ubitux> jamrial: http://b.pkh.me/0001-lavu-rename-and-move-ff_parity-to-av_parity.patch [23:44:23 CET] <ubitux> opinion? [23:47:51 CET] <ubitux> going to apply soon [23:48:10 CET] <jamrial> you can remove the configure check and add the builtin from intmath.h under a gcc check [23:48:48 CET] <ubitux> and do what for when it's not avail? [23:49:15 CET] <ubitux> i mean i'm ok to remove the configure check later, i'm just not comfortable doing it before we provide a nicer c impl [23:49:22 CET] <jamrial> something like http://pastebin.com/ezeSat6u [23:50:05 CET] <jamrial> the builtin will be used in the same cases as with the configure check [23:51:30 CET] <ubitux> but if icc or clang tmr provides a nicer parity, they won't be used [23:51:49 CET] <jamrial> AV_GCC_VERSION_AT_LEAST checks __GNU__, which clang, gcc and icc define. no other compiler defines it or use any __builitin_* afaik [23:52:07 CET] <jamrial> clang an icc will use it [23:52:11 CET] <ubitux> ah [23:52:13 CET] <ubitux> ok [23:52:21 CET] <ubitux> well then sure ok, fine with me [23:52:58 CET] <ubitux> do you want to do that on top of the fix i suggested? [23:53:07 CET] <ubitux> or you want to do altogether? [23:53:33 CET] <ubitux> (i'm going afk in a few minutes) [23:53:35 CET] <jamrial> i'll do it altogether [23:53:51 CET] <ubitux> ok, well feel free to push soon :p [23:54:06 CET] <ubitux> i don't like to let my shit broken like this [23:54:10 CET] <jamrial> sure :p [00:00:00 CET] --- Fri Jan 8 2016

1 0

ffmpeg.log.20160107
by burek 08 Jan '16

08 Jan '16

[09:10:27 CET] <tapas> I am trying to broadcast a silent audio stream using "ffmpeg -ar 10000 -f s16le -acodec pcm_s16le -ac 2 -i /dev/zero -acodec libmp3lame -f flv rtmp://xxxx" [09:11:24 CET] <tapas> but my ubuntu is showing that above command is using outgoing bandwidth of 200 kilo bytes per sec which is very high [09:11:47 CET] <tapas> any idea how can i broadcast a 10kbps silent audio stream using ffmpeg ? [09:11:52 CET] <tapas> anyone online here ? [09:12:34 CET] <tapas> any one online here ? [09:13:47 CET] <furq> tapas: put -re before -i [09:14:11 CET] <tapas> furq: thank you. let me try quickly [09:17:03 CET] <tapas> furq: it worked [09:18:15 CET] <tapas> furq: but it is still taking 60kbps-100kbps (kbps = kilo bits per sec) speed ..i want to broadcast at 10kbps speed [09:18:21 CET] <tapas> furq: how do i do that ? [09:18:31 CET] <furq> -b:a 10k [11:33:14 CET] <t4nk159> welcome everyone [11:33:20 CET] <t4nk159> hope someone can help me [11:33:25 CET] <t4nk159> anyone? [11:34:50 CET] <t4nk159> anyone can help me? [11:41:11 CET] <Betablocker> ^ [16:48:34 CET] <paule32> hello [16:49:28 CET] <paule32> is it possible to start and stop a mp3 song/file at ffmpeg runtime/streaming without restart? [16:58:21 CET] <furq> paule32: ^Z and fg [17:00:58 CET] <kadiro> Hello, I have a problem to copy stream with ffmpeg I got errors like: [NULL @ 0xaf9de40] illegal reordering_of_pic_nums_idc 13 and [NULL @ 0xaf9de40] illegal aspect ratio ..[NULL @ 0xaf9de40] AVC: nal size 1296047848 and so on, the result is only 6.5M compared to the source file have 31M, the players can play the source file fine [17:02:37 CET] <kadiro> tryed with -c copy and -c:v copy -c:a copy got same result [17:07:26 CET] <paule32> i have screen 1024x728 as input, can i scale it down to 800x600 before stream? [17:50:43 CET] <JamEngulfer221> Hey there. Im trying to speed up a simple sine wave using this command here: ffmpeg -i sine.ogg -filter:a "atempo=1.7" sine2.ogg but it doesnt seem to be working. Im on Mac OSX with the latest ffmpeg version [17:51:31 CET] <JamEngulfer221> Console output here: http://pastebin.com/755KBQRp [17:58:27 CET] <JamEngulfer221> Oh wait, it did work, it just didnt increase the pitch as Id hoped :/ [18:06:12 CET] <JamEngulfer221> In that case, is there any way to increase the speed of an audio file whilst also increasing the pitch? [18:10:11 CET] <kadiro> It seem this channel is died [18:21:22 CET] <durandal_1707> read docs [18:23:23 CET] <ffmpeg_noob> hey [18:23:37 CET] <ffmpeg_noob> i am trying to convert FLAC to ALAC [18:23:40 CET] <ffmpeg_noob> this works: [18:23:41 CET] <ffmpeg_noob> ffmpeg -i song.flac -c:a alac song.m4a [18:23:46 CET] <ffmpeg_noob> but how can i output to pipe? [18:24:16 CET] <ffmpeg_noob> i tried this: [18:24:20 CET] <ffmpeg_noob> ffmpeg -i song.flac -c:a alac - [18:24:25 CET] <ffmpeg_noob> but i get error "Unable to find a suitable output format for 'pipe:'" [18:26:30 CET] <kepstin> you have to use the '-f' option to specify the format when outputting to a pipe, since it can't be guessed from the filename [18:27:00 CET] <ffmpeg_noob> like -f m4a ? [18:28:13 CET] <ffmpeg_noob> :( Requested output format 'm4a' is not a suitable output format [18:28:21 CET] <kepstin> try 'mp4' [18:28:34 CET] <kepstin> (m4a is just a file extension used for mp4 files which only have audio) [18:29:37 CET] <ffmpeg_noob> Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument [18:32:04 CET] <kadiro> [17:01:30] <kadiro> Hello, I have a problem to copy stream with ffmpeg I got errors like: [NULL @ 0xaf9de40] illegal reordering_of_pic_nums_idc 13 and [NULL @ 0xaf9de40] illegal aspect ratio ..[NULL @ 0xaf9de40] AVC: nal size 1296047848 and so on, the result is only 6.5M compared to the source file have 31M, the players can play the source file fine [18:32:05 CET] <kadiro> [17:03:09] <kadiro> tryed with -c copy and -c:v copy -c:a copy got same result [18:33:19 CET] <ffmpeg_noob> kepstin: http://pastie.org/10676404 [18:33:46 CET] <kepstin> ffmpeg_noob: oh, right, forgot about that. your actual error is in the output: [mp4 @ 0x7fc122800600] muxer does not support non seekable output [18:33:53 CET] <ffmpeg_noob> http://pastie.org/10676408 [18:33:54 CET] <kepstin> ffmpeg_noob: you can't write mp4 to a pipe [18:34:17 CET] <ffmpeg_noob> oh we can't [18:34:19 CET] <ffmpeg_noob> darn [18:35:50 CET] <kadiro> sorry If my question is so hard [18:38:09 CET] <corw> hi [18:38:23 CET] <kadiro> Hi corw how are you? [18:38:33 CET] <corw> fine thanks [18:38:42 CET] <kadiro> Good to hear [18:40:54 CET] <corw> i'm tryng to compile ffmpeg (i'm on linux amd64), which are the normal configure options, i've tried --enable-gpl --enable-nonfree and got very big ffmpef ffprobe ... [18:42:09 CET] <kepstin> corw: the default build statically links the libav* libraries into the ffmpeg command line too, which is why they're big. [18:42:14 CET] <kepstin> command line tool* [18:43:38 CET] <corw> yes :-) , now i was trying, --enable-shared and --disable-static [18:45:50 CET] <corw> one (of many) thing that is not clear for me: have I to add --enable-libxvid , or is automatically included? [18:46:41 CET] <kepstin> in general, features that use external libraries aren't enabled unless you add the option for it. Check the output of configure see see. [19:05:18 CET] <kadiro1> so any answer to my question? [19:05:52 CET] <kadiro1> [18:32:36] <kadiro> [17:01:30] <kadiro> Hello, I have a problem to copy stream with ffmpeg I got errors like: [NULL @ 0xaf9de40] illegal reordering_of_pic_nums_idc 13 and [NULL @ 0xaf9de40] illegal aspect ratio ..[NULL @ 0xaf9de40] AVC: nal size 1296047848 and so on, the result is only 6.5M compared to the source file have 31M, the players can play the source file fine [19:05:52 CET] <kadiro1> [18:32:36] <kadiro> [17:03:09] <kadiro> tryed with -c copy and -c:v copy -c:a copy got same result [19:06:10 CET] <kadiro1> repeat of the repeated question ^ [19:07:01 CET] <kadiro1> !ffmpeg [19:07:17 CET] <kadiro1> !avc [19:08:18 CET] <kadiro1> good idea hop this times got an answer [19:09:56 CET] <furq> 17:45:50 ( corw) one (of many) thing that is not clear for me: have I to add --enable-libxvid , or is automatically included? [19:10:03 CET] <furq> you only need libxvid if you want to encode xvid [19:10:15 CET] <furq> there's a builtin mpeg4 decoder which handles xvid [19:11:14 CET] <kadiro1> http://dpaste.com/07JWNZR [19:12:18 CET] <kadiro1> the output ^ [19:14:43 CET] <kadiro1> full output frm terminal ==> http://dpaste.com/07JWNZR [19:17:15 CET] <c_14> kadiro1: have you tried reencoding the video? [19:17:49 CET] <kadiro1> c_14, No I think that will cause lost of quality [19:18:37 CET] <kadiro1> I need the output be avi, if possible good video and dx50 [19:21:37 CET] <kadiro1> ah thank you c_14 I think I must rencode it the size is big i need only 352x240 [19:22:17 CET] <kadiro1> c_14, How I can do the DX50 tag ? [19:27:48 CET] <c_14> -vtag DX50 afaik [19:28:04 CET] <kadiro1> c_14, without any other parameter? [19:28:31 CET] <c_14> I think so [19:32:17 CET] <kadiro1> I got info: [avi @ 0x9bdfaa0] non-interleaved AVI and the picture is horrible [19:32:26 CET] <kadiro1> from ffprobe [19:32:36 CET] <c_14> set a bitrate [19:38:42 CET] <kadiro1> wow the size of it is bigger then the source but not better also sound looks run before the picture I just did -c:a copy to see with -b:v 2000k [19:40:43 CET] <kadiro1> anyway thank you c_14 may be i must download all the stream from youtube rather then using the online tool for it [19:51:55 CET] <paule32> i have old DSL connection (6000 kb down/600 kb up - is it enough to stream screen 800x600 + audio? [19:52:30 CET] <c_14> stream to somewhere? [19:52:51 CET] <furq> yes [19:52:57 CET] <furq> whether it'll look good is a question i can't answer [19:54:31 CET] <kadiro1> https://wiki.archlinux.org/index.php/FFmpeg#Screen_cast [19:55:20 CET] <paule32> c_14: to my stream server [19:55:27 CET] <paule32> into internet [19:58:52 CET] <paule32> kadiro1: thx, i know how to stream, but i have no expierences, how much data is held, and how much visitors can watch stream by a nginx server [19:58:56 CET] <paule32> root server [19:59:22 CET] <c_14> You should be able to stream, might not look that great though (depending on video content) [19:59:27 CET] <c_14> The more motion the worse it'll look [20:01:26 CET] <furq> paule32: if your server is 100mbit then you should be good for 150+ viewers [20:01:44 CET] <paule32> oh, ok [20:02:35 CET] <c_14> So I just tried, and it looks fine. [20:02:49 CET] <c_14> I used 10bit H.264 though, not sure how it'll look with 8bit H.264 [20:02:56 CET] <furq> like i said it's impossible to answer [20:03:01 CET] <furq> it depends what's on the screen [20:03:24 CET] <furq> fortunately there's a good way you can find out whether streaming your screen at 600kbps will look good [20:03:54 CET] <paule32> the problem is a little bit in buffering [20:04:07 CET] <paule32> i cant do real live streaming [20:04:18 CET] <paule32> 5 - 10s latency [20:04:38 CET] <furq> are you sure that's not introduced by the player [20:04:59 CET] <furq> most players default to a buffer of at least 5 seconds [20:05:05 CET] <paule32> ehm, yes [20:05:41 CET] <paule32> i have heard, that flash is died, and html5 is the future [20:05:51 CET] <paule32> death [20:05:52 CET] <paule32> sorry [20:07:11 CET] <furq> it sure is [20:07:20 CET] <furq> that's why the nginx rtmp module will output to hls and dash [20:07:25 CET] <furq> although i'm told the dash muxer is broken [20:07:39 CET] <paule32> hmm [20:07:50 CET] <furq> i use it for hls and it works fine [20:07:55 CET] <furq> although the latency is even worse than for rtmp [20:08:30 CET] <paule32> real time media proto - rtmp - not good? [20:09:14 CET] <furq> it's good enough [20:09:18 CET] <paule32> give it a solution, to see stream and chat with visitors? [20:09:29 CET] <paule32> or html topic? [20:09:44 CET] <furq> rtmp only works with flash [20:09:58 CET] <paule32> :( [20:10:02 CET] <furq> on the web, i mean [20:10:09 CET] <furq> obviously VLC et al can play it [20:10:16 CET] <paule32> ah fine [20:12:44 CET] <paule32> i use ffmpeg to stream desktop, vlc can do it, too, so what it better - command line or vlc (2 monitors - one for vlc[test stream] - one for recording) [20:14:09 CET] <paule32> the pro on command line is, that i can move the console window to other monitor and watch the stream by output - the cons are the many options [20:15:01 CET] <paule32> yesterday i download obs, compile it, but can't run it, because symbols are undefined [20:41:44 CET] <Betablocker> netsplit rockz ! [21:13:08 CET] <DHE> Betablocker: wouldn't be freenode without a weekly split [21:33:17 CET] <TD-Linux> paule32, if you want really low latency, like videoconferencing latency, you're going to need RTP instead, like WebRTC [21:34:05 CET] <paule32> webrtc? a linux application? [21:36:43 CET] <TD-Linux> webrtc is a Javascript API, as well as a set of network protocols [21:37:18 CET] <TD-Linux> as far as I know though, ffmpeg does not support webrtc [21:37:30 CET] <Pinchiukas> Anyone can help me figure out how to get the name of an MPEG-TS stream? And maybe languages too. :) [21:38:54 CET] <kepstin> I think specifically, ffmpeg might not support the dtls encryption on the rtp media stream required for webrtc :/ [21:40:02 CET] <DHE> Pinchiukas: just point ffprobe at it. there's a 3-character language field on the audio. [21:45:48 CET] <Pinchiukas> Cool! Thanks DHE! [21:45:52 CET] <TD-Linux> kepstin, yup. to be precise dtls-srtp [23:59:02 CET] <JakeJ> hey, anyone around that knows much about complex aac audio filters? [23:59:21 CET] <JakeJ> i'm trying to make an 8 channel octagonal audio filter in aac and having issues [00:00:00 CET] --- Fri Jan 8 2016

1 0

ffmpeg-devel.log.20160106
by burek 07 Jan '16

07 Jan '16

[01:12:56 CET] <jamrial> fun, i started getting spam in the form of paypal invoces for the amount of $0.00 [01:13:14 CET] <jamrial> clever way to circumvent gmail's spam detector [01:13:17 CET] <nevcairiel> i just got one of those as well [01:13:23 CET] <nevcairiel> second in two weeks [01:13:29 CET] <rcombs> I've been getting some weird and different types of spam today [01:13:45 CET] <atomnuker> yeah, just got one too [01:13:55 CET] <rcombs> apparently people have been signing me up for accounts places, and I've been getting confirmation emails [01:14:11 CET] <rcombs> no paypal account here, though [01:14:16 CET] <rcombs> so I miss out on that fun [01:15:11 CET] <rcombs> some idiot's prediction for 2016: "Slack will become so pervasive inside of enterprises that spam will become a problem and third party Slack spam filters will emerge." [01:15:23 CET] <atomnuker> Its probably the MPEG-LA wanting some cash [01:15:32 CET] <jamrial> you don't need a paypal account to get invoces [01:16:05 CET] <rcombs> oh, guess I might have to mark PayPal as spam wholesale if they start showing up then [02:21:26 CET] <Compn> rcombs : i got about a dozen "confirm your account" emails, even at playstation network hah [02:21:38 CET] <rcombs> guess it's not just me then [02:21:53 CET] <Compn> and this is from an email i am not registered on any mailing lists [03:19:11 CET] <atomnuker> BBB: had time to take a quick look at my decoder yet? [03:19:16 CET] <BBB> no :( [03:19:25 CET] <BBB> I wanted to do it today but didnt find time :( [03:19:51 CET] <BBB> like I said in original reply, its o to push w/o review [03:19:55 CET] <BBB> but Illr eview later anyway :) [03:22:12 CET] <atomnuker> well, fixed quite a few things [03:23:06 CET] <atomnuker> I'll send a final patch in a few mins (if no objections I'll push) [03:32:30 CET] <jamrial> atomnuker: so it currently can decode samples created with libdaalaenc git HEAD, and the idea is to update it as the format develops? [03:36:03 CET] <atomnuker> yep, that's pretty much it [03:36:35 CET] <atomnuker> (patches sent to this decoder will be sent upstream with the author's permission) [03:37:27 CET] <BtbN> Maybe wait until after tha upcoming release, but I'm not sure if that matters at all for an experimental decoder. [03:38:32 CET] <atomnuker> it's probably not going to be included in the release (unless the release is a raw snapshot of git master) [03:38:52 CET] <BtbN> Well, it is? [03:39:08 CET] <BtbN> I don't think 3.0/2.9 was branched yet [03:39:44 CET] <atomnuker> okay then [03:42:11 CET] <atomnuker> anyone knows when the branch will be made? [03:43:13 CET] <BtbN> michaelni usualy does that [04:09:13 CET] <cone-228> ffmpeg 03Ganesh Ajjanagadde 07master:a956840cbcf8: ffmpeg: check return value of avio_closep for progress report [04:09:13 CET] <cone-228> ffmpeg 03Ganesh Ajjanagadde 07master:fc703f53cf3b: lavfi/af_compensationdelay: replace pow(x,0.5) by sqrt(x) [04:55:53 CET] <philipl> BtbN: so how effective does the intel hybrid vp9 seem to be? I've got skylake hardware arriving in the next week so I can finally poke at it. [05:04:42 CET] <jamrial> seems to be good for 1080p content only last time he tested it. anything above that and it lags/crashes [05:06:07 CET] <jamrial> you'll however have no trouble with ffmpeg software decoder and 4k vp9 with that cpu [05:18:53 CET] <philipl> Yeah, I expect so. [05:19:24 CET] <philipl> I see that Intel have pushed code to their driver that confirms broxton will have full hardware vp9 decode. [05:19:46 CET] <philipl> I'm half tempted to change my mind and return the nuc when I get it and hold out another year. [05:20:48 CET] <J_Darnley> :) [05:21:00 CET] <J_Darnley> Then there will be some other feature you want to waitfor. [05:21:37 CET] <philipl> Yeah. It's futile. My mediacentre is an ivy bridge nuc right now, so it's had a good run. [10:03:07 CET] <ubitux> michaelni: i'll deal with the cc patches [10:03:48 CET] <ubitux> tmm1: 2 general comments; can you change "libavcodec" to "lavc" in the patch message, and can you squash all the whitespaces changes together? [10:04:06 CET] <ubitux> also, if you have a public git repo, it will be simpler for me to merge [10:15:03 CET] <mateo`> am I blind or does the NDK MediaCodec API *not* provide a way for the user to know the {dec,enc}oder name (so we can deal with broken decoders/encoders that lie about the format they output) ? [10:18:30 CET] <durandal_1707> ubitux: avcodec it is, not lavc [10:19:17 CET] <ubitux> durandal_1707: well i though we decided lavc/lavf/lavfi/lavu [10:19:39 CET] <durandal_1707> nope, let's vote [10:20:16 CET] <ubitux> as you wish... mind to send the [DECISION] mail? [10:22:22 CET] <durandal_1707> [RULES] [10:51:56 CET] <wbs> mateo`: apparently not; originally there wasn't such a method in java either, but I contributed it and it got included in API level 18 [10:53:33 CET] <wbs> mateo`: if you want to do codec blacklisting/whitelisting, you probably need to use MediaCodecList anyway, and that's not in the NDK afaik [10:54:15 CET] <wbs> mateo`: note that originally (in android 4.1), using createDecoderByType was pretty dangerous, since it crashed the whole process if you tried to create a codec that didn't exist (so you'd have to check with MediaCodecList first to be safe anyway) [10:54:48 CET] <wbs> mateo`: (which still didn't stop some manufacturers from e.g. listing that they had a vp8 decoder in MediaCodecList, which actually didn't exist, so trying to create that would kill your process as well) [11:01:30 CET] <mateo`> so even if we go with the C API we will still need some jni to handle the different broken cases ... [11:01:52 CET] <mateo`> suddently it feels pointless to use the C API ... [11:02:33 CET] <wm4> at least we get the satisfaction of knowing that Google is losing money due to having to pay Oracle for the java crap [11:08:37 CET] <mateo`> really, I wanted to avoid as much as possible of this bullshit ... but it's even possible even with android >= 21. One of the phone i've tested the code against reported a color format of YCbCr (422) and is ... actually ~nv12 [11:11:10 CET] <mateo`> wbs: also, the NDK MediaCodec API does not let you retreive the codec index needed by MediaCodecList :( [11:13:29 CET] <wm4> what, they somehow set the wrong format on returned frames? [11:15:37 CET] <mateo`> yes [11:16:40 CET] <wm4> that sounds like the sort of bugs you need blacklists with vendors and driver versions to work around... [11:17:08 CET] <wbs> mateo`: indeed, so createDecoderByType is essentially useless - you need to instead look through the list and manually pick one [11:17:23 CET] <wbs> mateo`: as for incorrect pixel format - that sounds very strange [11:17:29 CET] <wbs> mateo`: there used to be lots of those before 4.3 [11:17:52 CET] <wbs> mateo`: but since 4.3, there's a CTS test that is mandatory for a device to be shipped, which enforces them to return sensible values [11:18:11 CET] <wbs> mateo`: there are a bunch of loopholes in it though (e.g. it's ok for a decoder to return an opaque format, like qualcomm does) [11:18:53 CET] <wbs> see https://android.googlesource.com/platform/cts/+/master/tests/tests/media/sr… [11:19:12 CET] <durandal_1707> michaelni: can you look at patch that fixes leaks on failure for avfilter? [11:19:16 CET] <wbs> ah, so if (!isRecognizedFormat(colorFormat)) -> instant pass in the test [11:19:41 CET] <mateo`> I'm aware of those tests [11:20:01 CET] <wbs> yes - I just wanted to get clarity in why devices can ship with wrong chroma despite them [11:20:02 CET] <mateo`> but i'm pretty sure i'm facing this one ... http://lists.freedesktop.org/archives/gstreamer-commits/2013-June/072118.ht… [11:20:33 CET] <wbs> (but since the test doesn't recognize COLOR_FormatYCbYCr it can pass just fine) [11:24:29 CET] <durandal_1707> does this foo guy have real name? [11:24:44 CET] <nevcairiel> everyone does [13:33:21 CET] <ubitux> wm4: would you like the idea of av_opt_set(avctx, "sub_ass_format", "no_timing", 0)? [13:33:28 CET] <ubitux> i'm pretty much done [13:33:49 CET] <ubitux> (the option would become the default in the future) [13:34:59 CET] <kierank> wm4: what is the problem with closed caption displaying? [13:35:05 CET] Action: kierank doesn't understand the issue [13:35:36 CET] <wm4> kierank: supposed you have a line of text at timestamp A, and another one at timestamp B (and it doesn't change until then) [13:35:48 CET] <wm4> then the current CC decoder will buffer the event for timestamp A until timestamp B [13:36:04 CET] <kierank> why [13:36:17 CET] <wm4> because ASS is a timed format [13:36:31 CET] <wm4> and the decoder tries to output a single ASS event for each line of text [13:36:44 CET] <kierank> ass doesn't have the concept of display until something else happens? [13:36:53 CET] <JEEB> nope [13:36:56 CET] <JEEB> it's multi-layered [13:36:58 CET] <wm4> no [13:37:04 CET] Action: kierank cries [13:37:05 CET] <JEEB> and you can have multiple entities on the same layer even [13:37:21 CET] <JEEB> well, it just lives to its name :P [13:37:24 CET] <ubitux> with my current patch it won't be much of an issue anymore [13:37:27 CET] <kierank> ok looks like I'll have to write my own cc decoder or steal VLCs perhaps [14:00:17 CET] <wm4> kierank: well, it's not like it can't be solved, but using ASS as markup bites us a bit here [14:00:19 CET] <J_Darnley> What a mess of a ticket. [14:00:23 CET] <wm4> on the other hand, all alternatives were even worse [14:00:47 CET] <wm4> (generic supersets, markup ASTs etc.) [14:01:38 CET] <kierank> for display thankfully I don't think anyone will notice if they are not frame accurate [14:02:20 CET] <ubitux> https://github.com/ubitux/FFmpeg/compare/ass-2016 [14:02:31 CET] <ubitux> this should be passing fate-subtitles pretty soon [14:02:39 CET] <ubitux> then i'll add an option and i'm done [14:02:49 CET] <ubitux> no more timing shit in the decoded form [14:02:59 CET] <kierank> I am nervous about incorporating ass into my stuff, feels like i could open a world of pain [14:03:12 CET] <ubitux> and as a side effect, should fix all the timing rounding crap [14:08:55 CET] <wm4> ubitux: heh, that rounding was a big problem (but is effectively worked around now) [14:10:32 CET] <ubitux> anyway, after this, you can call subtitle decode with every sub packet [14:10:41 CET] <ubitux> and feed sub->rects[N]->ass to libass directly [14:11:26 CET] <ubitux> if the decoder is ass, whole dialog is just copied, for other decoders ass markup is computed as usual and the readorder is simply incremented in the context (and reset to 0 in cases of flush) [14:11:58 CET] <wm4> there's just one problem: I don't want to clear the libass event list when seeking [14:12:09 CET] <wm4> it would also mean to reconvert all subtitles when seeking [14:12:22 CET] <wm4> (but I'm not sure myself what's the best way to handle this) [14:12:28 CET] <ubitux> it's reset to 0 only for decoders where the read order doesn't matter [14:13:03 CET] <ubitux> maybe a flag would be present [14:14:21 CET] <ubitux> wm4: why don't you want to clear the list btw? [14:16:42 CET] <wm4> it has 2 advantages: avoiding to reconvert, and seeking or adjusting subtitle delay by event [14:17:04 CET] <wm4> the latter just requires the player to know at which times subtitle events happen [14:17:19 CET] <ubitux> since convert is done incrementally,why does it matter? [14:18:59 CET] <wm4> that would require some logic to prevent packet ahead reading (for external subtitles) [14:20:04 CET] <wm4> I wonder if I should just make some sort of wrapper that makes a srt demuxer behave like a srt demuxer to work around these issues [14:20:19 CET] Action: ubitux confused [14:20:21 CET] <wm4> that makes a srt demuxer behave like an ass demuxer [14:20:45 CET] <ubitux> the srt and ass demuxer behave the same afaik [14:21:06 CET] <wm4> that'd be annoying for muxed srt subs though (the converter would have to be at two levels) [14:21:10 CET] <ubitux> the whole file is read, and events/packets put in a seekable internal queue [14:21:34 CET] <wm4> I know [14:23:30 CET] <ubitux> i still don't understand the problem [14:24:02 CET] <ubitux> anyway, this patchset should clearup a bit the garbage pile [14:24:14 CET] <ubitux> it will be a saner base [14:24:48 CET] <wm4> ubitux: my own code just feeds packets to libass (converts them before that if the source is e.g. srt) [14:25:05 CET] <wm4> then, some features use ass_step_sub() [14:25:25 CET] <wm4> which finds the next/previous subtitle at a given timestamp (this is used for subtitle seek, or adjusting subtitle delay) [14:25:50 CET] <ubitux> subtitle seek = seek playback to next sub event? [14:25:58 CET] <wm4> yes [14:26:10 CET] <wm4> for subtitles interleaved with video, this works only with already seen subs [14:26:18 CET] <wm4> a bit annoying, but mostly unavoidable [14:26:41 CET] <wm4> for plain subtitle files, it means all packets have to be added to libass on init or so [14:30:20 CET] <ubitux> right, so the only thing that will change here is simply that instead of feeding packets to libass or convert them (and then remove the dialogue crap if you used lavc), you will just always decode the packet (in case of ass it's a simple copy of the payload), and feed sub->rects[N]->ass to libass [14:30:41 CET] <ubitux> rest should remain unchanged [14:32:19 CET] <wm4> ubitux: this is what I do: https://github.com/mpv-player/mpv/blob/master/sub/sd_ass.c#L237 [14:32:38 CET] <wm4> lavc_conv_decode() is merely a wrapper around avcodec_decode_subtitle2() [14:32:49 CET] <ubitux> ok [14:33:24 CET] <wm4> check_packet_seen() is some sort of replacement for the ReadOrder check [14:33:48 CET] <wm4> it uses the file byte position as unique ID, which happens to work for all demuxers [14:33:55 CET] <ubitux> mmh [14:34:13 CET] <ubitux> yeah, until it's a >4G file [14:34:40 CET] <wm4> it uses a int64_t [14:34:45 CET] <ubitux> i guess you don't forward it to libass? [14:35:27 CET] <wm4> no, because this is the code path for the "old" packet format, which doesn't have a readorder field at all [14:35:38 CET] <ubitux> ok [14:36:10 CET] <ubitux> i thought many demuxer were not setting the position [14:36:39 CET] <wm4> so check_packet_seen() is my replacement for ReadOrder in the srt case, which means I can handle srt/ass and standalone/muxed subtitles fully equivalent [14:47:08 CET] <cone-366> ffmpeg 03Mats Peterson 07master:6a975cb07f40: lavf/matroskadec: correct codec_tag for "SMI" SVQ3 files [14:57:08 CET] <wm4> I wonder why the pad filter has to do such elaborate obscure things [14:57:15 CET] <wm4> which, guess what, break [14:58:25 CET] <durandal_1707> wm4: what breaks? [15:02:17 CET] <wm4> I don't know what the ticket above is about, but there was also a patch on the ML to fix vf_pad in certain cases [15:05:11 CET] <wm4> actually maybe this is unrelated to what I was thinking about, so never mind [15:54:09 CET] <ubitux> wth is he talking about [15:54:40 CET] <Daemon404> i have no idea [15:54:47 CET] <ubitux> we should also stop allowing markup in the trac [15:54:59 CET] <ubitux> it's useful, but these dumbass make it unreadable [15:55:00 CET] <Daemon404> i think having a code tag is good [15:55:11 CET] <Daemon404> i hate reading non-monospaced console output [15:55:23 CET] <ubitux> well it could be all monospaced [15:56:18 CET] <ubitux> seriously i read its 3 first sentence several times, i don't have a clue what he's talking about [15:56:22 CET] <prelude2004c2> hey everyone good day.. having an issue with playback... ( see http://pastebin.com/XAVQL9bz ) ... basically when i record something from the live stream and i try to playback it always plays the end of the stream and not from the beginning. I am told it is because the start time of the recording has negative value and the system can't play something with a negative value.. can anyone point me in the right direction [15:56:22 CET] <ubitux> his* [15:56:47 CET] <ubitux> prelude2004c2: #ffmpeg [15:57:03 CET] <prelude2004c2> ehh yes.. well i missed the -devel :( [15:57:04 CET] <prelude2004c2> sorry [15:57:44 CET] <ubitux> no worry [15:57:57 CET] <prelude2004c2> let's hope someone is chatty there :P haha [15:58:56 CET] <wm4> Daemon404: just kill stagefright already [15:59:17 CET] <Daemon404> ill wait af ew hrs [15:59:23 CET] <Daemon404> i dont wnat revert wars [15:59:26 CET] <Daemon404> or butthurt yelling [15:59:43 CET] <Daemon404> for once, im tyring to be diplomatic [15:59:46 CET] <Daemon404> unlike me, i know. [16:43:56 CET] <cone-366> ffmpeg 03Andrey Turkin 07master:149b1f7ccafa: avfilter/vf_pad: fix direct padding [17:25:23 CET] <BBB> Daemon404: what did you do to the real Daemon404 [17:25:36 CET] <Daemon404> ;) [17:25:38 CET] <Daemon404> gonna push now [17:25:43 CET] <BBB> ah there he is [17:25:45 CET] <BBB> ok [17:33:39 CET] <wm4> now someone send stagefright wrapper to Libav, so cehoyos gets a heart attack [17:33:52 CET] <nevcairiel> hahaha [17:33:53 CET] <wm4> well, after it's pushed [17:36:38 CET] <Daemon404> just waiting for a dist-upgrade to finish before [17:37:51 CET] <kierank> wm4: wow that's brilliant [17:43:48 CET] <cone-366> ffmpeg 03Derek Buitenhuis 07master:72673ad7eae2: avcodec: Remove libstagefright [17:44:03 CET] <kierank> !!!!!!!!!!!!!!!!!!!!!!!!1 [17:44:04 CET] <atomnuker> SEE THIS SHIT^^ [17:44:06 CET] <atomnuker> SEE IT [17:44:21 CET] <nevcairiel> i'm surprised there was no big outcry on the ML from someone, carl must not care about android =p [17:44:40 CET] <Daemon404> nevcairiel, i doubt he sees many tracker thinsg about it [17:44:45 CET] <Daemon404> since nobody can figured out how to use it. [17:44:45 CET] <mateo`> woo ooo ~~ [17:45:28 CET] <kierank> ONE SMALL STEP FOR (A) MAN [17:45:32 CET] <kierank> ONE GIANT LEAP FOR MANKIND [17:46:32 CET] <atomnuker> next time I hear one of you say shit never gets removed I'm linking this [17:47:00 CET] Action: atomnuker wonders if wm4 will remove the tons of FUD from the mpv wiki now [17:47:23 CET] <kierank> it's the first time shit was removed [17:47:25 CET] <kierank> EVER [17:47:42 CET] <wm4> lol [17:47:54 CET] <kierank> <clarkson>IN THE WORLD</clarkson> [17:48:06 CET] <Daemon404> kierank, mpcodecs was remove [17:48:07 CET] <Daemon404> d [17:48:08 CET] <wm4> atomnuker: anyone can edit that wiki [17:48:08 CET] <nevcairiel> unless someone crazy shows up, we'll replace the dca decoder in a while without duplicating it [17:48:39 CET] <wm4> but in reality, only 1 unknown account edited it, using the commit message "Enjoying your "No Michael Niedermayer allowed" tree-house, Libav devs?" (was reverted as vandalism) [17:48:52 CET] <kierank> Daemon404: "removed" [17:49:55 CET] <atomnuker> wm4: oh yeah, I forgot about that [17:51:28 CET] <ubitux> kierank: "absorbed" [17:51:30 CET] <ubitux> ;) [17:56:41 CET] <ubitux> nevcairiel: the threading in ffmpeg is reworked, you might want to keep the support for platforms with no threading [17:56:47 CET] <ubitux> ffmpeg cli* [17:57:13 CET] <Daemon404> what platforms are those anywya [17:57:44 CET] <ubitux> maybe platforms were a pthread compat implementation exist [17:57:49 CET] <ubitux> not sure if there are any [17:57:50 CET] <nevcairiel> ubitux: i probably wouldnt have merged that anyway, it seems like one of those "cba to fix, disable" things [17:58:17 CET] <Daemon404> it seems to provide a very dubious benefit [18:00:06 CET] <kierank> Daemon404: yeah but avconv is getting threading [18:00:09 CET] <kierank> so hurr durr [18:00:14 CET] <jamrial> kierank: not true. i was able to remove a non pkgconfig configure check once [18:00:17 CET] <Daemon404> ... for the progress report [18:00:34 CET] <Daemon404> was it removed or kept as a fallback jamrial [18:00:42 CET] <jamrial> removed [18:00:49 CET] <Daemon404> wow [18:01:27 CET] <jamrial> carl wanted to keep it as fallback, i said no because it was never in a release to begin with so he can't claim regression [18:02:13 CET] <Daemon404> ... x264 has never had a release, and always (afaik) had pkg-config [18:02:13 CET] <Daemon404> so. [18:02:15 CET] <Daemon404> <_< [18:02:19 CET] <Daemon404> yet we kept its fallback [18:02:34 CET] <Daemon404> in fact the minimum supported x264 version has pkg-config. [18:02:41 CET] <Daemon404> (or did we ever even push pkg-config support?) [18:03:02 CET] <ubitux> yes, to make sure it's picking the one you don't want to on your system when you messed up your PKG_CONFIG env [18:03:06 CET] <ubitux> instead of failing properly [18:03:08 CET] <ubitux> :( [18:03:14 CET] <Daemon404> that sounds retarded [18:03:20 CET] <Daemon404> and very very error prone [18:03:25 CET] <jamrial> i mean ffmpeg release [18:03:29 CET] <Daemon404> jamrial, o [18:06:23 CET] <jamrial> if say ffmpeg 2.8 detects a library without pkgconfig and then suddenly 2.9 does it and without fallback, people with broken environments could theoretically have issues [18:06:36 CET] <jamrial> that's the argument carl used every time we had to keep a fallback in place [18:06:41 CET] <Daemon404> i dont call that an issue [18:06:50 CET] <Daemon404> i dont think supporting broken envs should be a goal [18:06:54 CET] <Daemon404> if anything, breaking it helps them fix it [18:07:20 CET] <jamrial> it isn't, and we shouldn't, but people bitch on trac and carl wants to close the ticket with something else than "wont fix" [18:09:38 CET] <jamrial> Daemon404: you could have added some reviewed-by lines to the commit [18:10:04 CET] <Daemon404> jamrial, nobody reviewed [18:10:06 CET] <Daemon404> everybody acked [18:10:07 CET] <Daemon404> i almost did [18:10:12 CET] <Daemon404> but that would be like 8 acked-by [18:10:20 CET] <Daemon404> and thats pretty sill [18:10:50 CET] <jamrial> it would work as ammunition in case people show up complaining about the removal :p [18:11:12 CET] <Daemon404> the ML has an archive [18:11:15 CET] <Daemon404> for this reason [18:30:31 CET] <jamrial> "[PATCH] avconv: Depend on pthreads directly" they are nuts [18:54:35 CET] <wm4> jamrial: why [18:55:24 CET] <jamrial> avconv wouldn't work on windows anymore unless you use one of the many pthreads emulation libraries [18:55:52 CET] <wm4> like ffmpeg/libav has one? [18:56:07 CET] <nevcairiel> no, that one specifically is not used [18:56:11 CET] <nevcairiel> they depend on pthreads directly [18:56:12 CET] <jamrial> we don't. we have a wrapper for a subset of pthreads [18:56:26 CET] <wm4> surely that's just an accident [19:07:32 CET] <prelude2004c2> hey been waiting for help on ffmpeg for 3 hours.. not a single reply in the channel.. can anyone here hep ? [19:07:34 CET] <prelude2004c2> help* [19:07:43 CET] <prelude2004c2> probably something very simple [19:09:27 CET] <prelude2004c2> new udpated code : http://pastebin.com/NTF2pjKC [19:10:45 CET] <mark4o> prelude2004c2: wrong channel; try #ffmpeg [19:11:01 CET] <prelude2004c2> i have been :) .. no chat in the channel for 3 hours now [19:11:03 CET] <prelude2004c2> and counting [19:11:03 CET] Action: J_Darnley skiggers [19:11:37 CET] <J_Darnley> What was the problem? [19:12:41 CET] <J_Darnley> All I see is a load of weird options [20:32:00 CET] <durandal_1707> anybody wants to add visualizations from lavfi to ffplay [21:22:37 CET] <prelude2004c2> hi darley [21:22:46 CET] <prelude2004c2> sorry it took me a while to respond [21:23:10 CET] <prelude2004c2> the issue is that when i use a PVR option they say the recording start time is a negative value.. i guess it has to do with key frames or whatever and the seeking options [21:23:18 CET] <prelude2004c2> i have been trying to play with it but nothing i do seems to work :( [21:28:34 CET] <cone-653> ffmpeg 03Vicente Olivert Riera 07master:6282bdc2bf36: mips: display a warning message when using an unknown CPU [21:42:46 CET] <ubitux> tmm1: so do you have your cc tree in a public repo? [22:17:29 CET] <cone-653> ffmpeg 03Michael Niedermayer 07master:23679d82f69c: configure: use warn() for mips unknown cpu warning [23:19:56 CET] <cone-509> ffmpeg 03Aman Gupta 07master:55ca79f5268f: libavcodec/ccaption_dec: clean up and standardize white space [23:19:56 CET] <cone-509> ffmpeg 03Aman Gupta 07master:3ec5d8fe0ff1: libavcodec/ccaption_dec: rewrite packet handler as case statement; remove COR3 macro [23:27:52 CET] <tmm1> ubitux: i don't but i can push it up [23:29:48 CET] <tmm1> ubitux: https://github.com/pyrot/ffmpeg/compare/master...upstream-cc-cleanups [23:29:58 CET] <tmm1> hrm [23:30:08 CET] <tmm1> that's not public, one sec [23:31:09 CET] <tmm1> https://github.com/tmm1/FFmpeg/compare/master...upstream-cc-cleanups [00:00:00 CET] --- Thu Jan 7 2016

1 0

ffmpeg.log.20160106
by burek 07 Jan '16

07 Jan '16

[00:21:38 CET] <drooly> i have some flac files to transcode to ogg. it seems their enbedded thumbnails are encoded as a videostream with an insanely high framerate. [00:22:30 CET] <drooly> in any case, when i transcode to ogg (libvorbis), i cannot seek (fast forward/backward) anymore. [00:22:55 CET] <drooly> discarding video with -vn helps, but i would like to salvage the thumbnail/coverart images. [00:23:47 CET] <drooly> i am not quite sure if these images are supposed to be an actual videostream, or somehow part of the metadata. [00:24:12 CET] <drooly> the latter, i tried with https://stackoverflow.com/a/18718265 but failed. [00:26:12 CET] <drooly> i can salvage one image from the stream, but how can i put it back into the transcoded ogg? i'd also like to be able to script it since i have quite many flacs [00:29:33 CET] <TD-Linux> maybe try oggenc? see if it does the right thing [00:30:18 CET] <drooly> TD-Linux: yes, i stumbled over that. trying it now. [00:30:20 CET] <TD-Linux> normally coverart in ogg is stored in the comment metadata [00:45:53 CET] <drooly> TD-Linux: oggenc seems to discard the video, and i cannot add the image back in. [00:46:16 CET] <TD-Linux> drooly, it doesn't keep the album art? it should. what are you using to see the album art? [00:47:02 CET] <TD-Linux> hmm maybe not. I know opusenc does [00:53:42 CET] <drooly> i'm looking/listening at the files with vlc and mpv, the result is always the same: the flac works, the ogg either doesn't display coverart and works, or displays coverart and is unseekable. [00:54:02 CET] <c_14> drooly: you can make it seekable, but it would still be a video stream [00:54:16 CET] <c_14> ffmpeg doesn't support writing image metadata (at least converting an image to image metadata) [00:54:40 CET] <c_14> you can do it manually by taking the image and I think base64 encoding it and then setting it as a certain metadata tag, but I forget how [00:54:43 CET] <c_14> plus it's a pain [00:55:14 CET] <c_14> If you're fine with it being a separate video stream add something like -vf fps=25 [00:55:17 CET] <drooly> i actually might have to retract my previous theory about the image being a video stream; at least in vlc it displays just fine as metadata. [00:55:32 CET] <drooly> and no video stream. [00:55:42 CET] <TD-Linux> if you application can handle opus rather than vorbis, opusenc does handle it correctly [00:55:57 CET] <drooly> in vlc's handy messages window [00:56:12 CET] <c_14> drooly: but it's still not seekable? [00:56:40 CET] <TD-Linux> drooly, is ffmpeg encoding it as a theora video track or something? [00:56:54 CET] <drooly> the original flac is always seekable, the ogg is only seekable when i see no folder art. [00:57:21 CET] <c_14> Can you check the output of the conversion that produces the one with folder art? [00:57:21 CET] <drooly> and no, it's audio only. i think my previous theory was wrong. [00:57:35 CET] <c_14> If it has something like (0:v -> theora) [01:08:48 CET] <drooly> i just put together a file with some info, will post a link in a second... [01:10:19 CET] <drooly> http://89.27.2.34/stuff/ffmpec-flac2ogg-problems [01:10:50 CET] <drooly> so, first the command i used for transcoding. [01:11:01 CET] <drooly> then some info about the original flac. [01:11:13 CET] <c_14> yeah, it's encoding it as a separate theora video stream [01:11:15 CET] <drooly> then some info about the resulting ogg [01:13:03 CET] <drooly> btw, result is the same if i remove "-c:v theora" from the command [01:14:02 CET] <c_14> yeah, ffmpeg treats image metadata as a separate image stream in the input and then encodes it as video output [01:15:45 CET] <drooly> hmm. if you look further down, both the original flac and the resulting ogg have a seperate video stream - so this actually isn't the same as metadata? [01:15:55 CET] <drooly> or is it because ffplay does the same? [01:16:06 CET] <drooly> when playing the files? [01:16:35 CET] <drooly> decodes the albumart metadata to a video stream? [01:16:50 CET] <c_14> yes [01:18:49 CET] <drooly> basically this means that all my music has been encoded with ffmpeg, which transformed metadata thumbnails into a video stream... [01:24:27 CET] <drooly> why can't i just tell ffmplay to not create these video streams, and leave the metadata as it is? [01:27:28 CET] <drooly> and, more importantly, why does it make my file unseekable?? [01:34:04 CET] <c_14> Because there's only 1 video frame and most players have trouble seeking then [01:35:41 CET] <TD-Linux> if anyone feels like writing code, opusenc's album art stuff could be ported to oggenc. Or there are probably other tools which do it correctly [01:37:29 CET] <drooly> ah yes, opusenc. what file extension does opus audio have usually? [01:38:35 CET] <furq> .opus [01:38:49 CET] <furq> it's an ogg container though [01:47:55 CET] <drooly> thanks for your help. i guess i'll just extract the images to external files. good night. [06:03:12 CET] <prelude2004c> Hey guys. . Can someone point me in the right direction. . Stb company tells me that when they record pvr stuff from content I am encoding the ext-e-pvrstarttime is less than zero. . How did I do that? [07:55:15 CET] <kichigaimentat> Hello, I've got these H.264 streams encoded by a bunch of knuckleheads that I have no intention of ever interacting with ever again who encoded some stuff at H.264/High Profile/Level5.1 and yet the actual content probably better fits Main/3.1. Any way to redefine the header, even as something like High/4.0? [07:55:47 CET] <kichigaimentat> As I understand it the Profile (High) defines encoding optimizations, Level defines the bitrates, and the Level is *way* overkill in this case. [08:05:43 CET] <waressearcher2> kichigaimentat: und bis bald [10:10:23 CET] <mitch31> hello. please anyone can help me! I use windows to stream my webcam. I stream video to server live.webm but chrome is loading infinite and it is no video. stat says WAIT_FEED [10:13:53 CET] <k_sze> Does ffmpeg's ffv1 encoder default to level 1 if I don't specify -level? [10:17:58 CET] <durandal_1707> yes [10:20:51 CET] <k_sze> I see. So level 3 can be sliced and encoded in a multithreaded way. But how about decoding? Does the level affect whether it can be decoded in a sliced/multithreaded way? [10:45:27 CET] <k_sze> And what are the pros and cons of using a large context vs a small context for ffv1? [10:45:37 CET] <k_sze> (the -context argument) [11:38:36 CET] <matham> I was wondering whether there's a way to set the loglevel specific to a particular AVFormatContext? and similarly codec contexts [11:39:11 CET] <matham> They all start with a AVClass, so I'm thinking this should be possible? [11:39:44 CET] <matham> but I don't see any clear api for this. And I couldn't tell whether the AVClass class is shared or specific to the context [13:29:17 CET] <volar> hi all [14:34:06 CET] <kynlem> hey [14:34:51 CET] <kynlem> how come "ffmpeg -i ~/Desktop/VideoForCutting.mp4 -ss 0 -t 60 -vcodec copy -acodec copy ~/Desktop/newchunk00.mp4" produces a video of 1799 frames? [14:35:22 CET] <kynlem> isn't the first frame always and I-frame? why would it stop 1 frame short (the video is 30 fps)? [14:35:30 CET] <kynlem> always an* [14:37:24 CET] <dibalaj> Hello, can anyone help me? I have some issues when restreaming RTSP to YouTube (RTMP). [14:40:08 CET] <dibalaj> Here is link to ffmpeg forum, if you can please look at it, many thanks! http://ffmpeg.gusari.org/viewtopic.php?f=11&t=2569 [14:56:34 CET] <andy`> kynlem: 60*30/1.001=1798.2 [15:02:29 CET] <Betablocker> dibalaj: take a look at my query please [15:02:42 CET] <Betablocker> i love this shit :D [15:22:43 CET] <termos> is there a way to specify the -re flag when using libFFmpeg? [15:24:33 CET] <kynlem> Betablocker: where does 1.001 come from? [15:24:34 CET] <JEEB> there's no libffmpeg [15:24:48 CET] <JEEB> and there probably is an avoption for it :P [15:24:55 CET] <JEEB> time to grep what the re option sets :P [15:26:14 CET] <kynlem> andy`: where does 1.001 come from? [15:27:11 CET] <termos> libav? seems like it's not part of the library, only part of ffmpeg.c [15:27:16 CET] <kynlem> and is there a way to just tell ffmpeg to cut 1800 frames, or do i *have* to specify it in seconds? [15:28:19 CET] <kynlem> not a big deal, but would just feel better to have a holy number of frames rather than unorthodox number of seconds (ocd, i'm looking at you) [15:28:35 CET] <furq> kynlem: ntsc video is usually 30/1.001 fps [15:28:52 CET] <furq> or 29.97 if you prefer [15:30:52 CET] <kynlem> k, i'll try to split video into 60.06-second chunks and see how it goes [15:30:56 CET] <kynlem> thanks, guys [15:33:08 CET] <dibalaj> @Betablocker what query do you mean? [15:34:30 CET] <Betablocker> ;) [15:57:07 CET] <prelude2004c2> hey everyone good day.. having an issue with playback... ( see http://pastebin.com/XAVQL9bz ) ... basically when i record something from the live stream and i try to playback it always plays the end of the stream and not from the beginning. I am told it is because the start time of the recording has negative value and the system can't play something with a negative value.. can anyone point me in the right direction [19:09:47 CET] <prelude2004c2> hey everyone good day.. having an issue with playback... ( see http://pastebin.com/NTF2pjKC ) ... basically when i record something from the live stream and i try to playback it always plays the end of the stream and not from the beginning. I am told it is because the start time of the recording has negative value and the system can't play something with a negative value.. can anyone point me in the right direction [19:27:33 CET] <DHE> prelude2004c: playback from the beginning will happen if the stream finishes and the X-EXT-ENDLIST (exact name?) label is added [19:27:53 CET] <DHE> also with -hls_list_size 5 you only have the last ~30 seconds of content available anyway [21:29:20 CET] <lumidee> hi if i want to record a video of my computer screen for a 800x600 VGA beamer, should i change the resolution from 1920x1080p to 1024x768 to have the 4:3 ratio or does it not matter when my LCD is 16:9 anyways [21:29:52 CET] <lumidee> also iam not sure if a higher resolution will also mean higher quality though i play it at a 800x600 beamer [21:32:12 CET] <waressearcher2> lumidee: hallo und herzlich willkommen [21:32:27 CET] <lumidee> waressearcher2, servus [21:38:17 CET] <DHE> that would make the most sense, changing resolutions. otherwise you will have a distorted image [21:38:32 CET] <DHE> or would need to crop [22:19:16 CET] <jafa> seeing an odd problem... invoking avcodec_decode_video2() to decode mpeg2 - I get out a sequence of frames with increasing pts values however the frames seem out of order [22:19:40 CET] <jafa> if I feed it through a filtergraph it works - frames are in order [22:20:27 CET] <jafa> pts going into avcodec_decode_video2 jump around following the encoded frame order as expected [22:21:04 CET] <jafa> pts coming out of avcodec_decode_video2 is in order but the frames don't seem to be [22:23:23 CET] <Mavrik> jafa, uhm. [22:23:32 CET] <Mavrik> You should probably feed frames in DTS not PTS order to decoder. [22:25:18 CET] <jafa> feeding them in natural order from the source [22:25:47 CET] <Mavrik> "natural order"? [22:25:58 CET] <jafa> no reordering of data going into the codec [22:26:20 CET] <jafa> so should already be dts order [22:27:09 CET] <jafa> ie all jumbled up as per normal mpeg2 [22:27:43 CET] <jafa> works great if I use a filterfraph [22:28:14 CET] <Mavrik> hrmf, no idea, it should JustWork(tm) [22:28:22 CET] <Mavrik> Maybe you're looking at a wrong PTS field? [22:28:42 CET] <Mavrik> there's the av_guess_pts call or whatsit that properly sets PTS on a frame. [22:29:36 CET] <jafa> using av_frame_get_best_effort_timestamp() [22:30:07 CET] <jafa> I could use a filtergraph set to "copy" (this works)... not sure what the cost is [22:30:17 CET] <Mavrik> There has to be some other issue then, worked just fine for my code at least in 2.0 - 2.5 [22:45:49 CET] <jafa> when a filtergraph is set to "copy" does it handle it by reference count or does it actually copy the data? [00:00:00 CET] --- Thu Jan 7 2016

1 0