Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

January 2016

1 participants
62 discussions

ffmpeg-devel.log.20160105
by burek 06 Jan '16

06 Jan '16

[00:06:11 CET] <cone-546> ffmpeg 03Michael Niedermayer 07master:1edf129cbc89: swscale/utils: Use normal bilinear scaler if fast cannot be used due to tiny dimensions [00:19:12 CET] <michaelni> rcombs, did you see https://trac.ffmpeg.org/ticket/5090 (regression since 4ab56667594842283dc5ae07f0daba2a2cb4d3af according to the ticket) [00:32:13 CET] <rcombs> hmm, I'll take a look [01:27:06 CET] <cone-546> ffmpeg 03Michael Niedermayer 07master:7cc01c25727a: avcodec/h264_slice: Fix integer overflow in implicit weight computation [02:25:23 CET] <cone-546> ffmpeg 03Ganesh Ajjanagadde 07master:43624a669b70: lavc/pcm_tablegen: slight speedup of table generation [02:56:55 CET] <cone-546> ffmpeg 03Michael Niedermayer 07master:eb8a67de75ef: avcodec/dxv: Check idx in CHECKPOINT() [03:35:45 CET] <cone-546> ffmpeg 03Michael Niedermayer 07master:68eb20801d69: avcodec/dxv: Check idx in dxv_decompress_dxt5() [10:32:20 CET] <Franciman> Hello, is there a way to know how many samples does an audio stream contain without reading all data from it? [10:36:28 CET] <av500> Franciman: depends on the container [10:36:37 CET] <av500> what file format is your stream in? [10:36:44 CET] <av500> or is it a real "stream" [10:37:46 CET] <wm4> in general it's not possible without reading and decoding the whole stream, but some formats might allow you to make a pretty good guess [10:43:31 CET] <Franciman> av500, uh I don't have a fixed format [10:43:44 CET] <av500> so what do you have? [10:44:47 CET] <Franciman> I want to accept as many formats as ffmpeg supports [10:45:21 CET] <Franciman> btw, my objective was to add a progress bar that tracks the reading and decoding process of the stream [10:45:35 CET] <Franciman> maybe I could use the duration in AVCodecContext [10:45:41 CET] <av500> if its a real "stream", like a TS file, then no [10:45:46 CET] <Franciman> and pts_time in AVFrame [10:45:48 CET] <Franciman> ? [10:46:01 CET] <av500> if you read a WAV or MP4 file, then yes you know how many samples there are [10:46:08 CET] <nevcairiel> if it doesnt need to be entirely accurate, you could use the file position for a "progress" bar [10:46:16 CET] <av500> if you have a file size, you can of course guess the position [10:46:19 CET] <nevcairiel> ie. check pkt->pos returned from av_read_frame [10:46:23 CET] <Franciman> yeah, doesn't have to be accurate [10:46:28 CET] <av500> so use file pos [10:46:37 CET] <av500> unless you have duration and/or samples [10:46:56 CET] <Franciman> what you mean by samples? [10:47:18 CET] <av500> same as duration [10:47:39 CET] <av500> if you have sampling freq and duration, you have number of samples [10:47:43 CET] <Franciman> oh right [10:47:45 CET] <Franciman> :P [10:48:05 CET] <Franciman> but it's not guaranteed that I have them for all types of stream? [10:48:15 CET] <av500> correct [10:48:16 CET] <nevcairiel> no, in fact most wont have that [10:48:53 CET] <av500> if the file is constant bitrate you can use the file pos to know the time [10:49:03 CET] <av500> if its variable bitrate, then no [10:49:22 CET] <av500> if its just for a progress bar, then you can use file pos / total size [10:49:28 CET] <Franciman> you're right [10:49:35 CET] <Franciman> thanks a lot for your help [10:49:40 CET] <Franciman> both of you [10:49:41 CET] <Franciman> :) [10:50:07 CET] <Franciman> ah just the last thing [10:50:44 CET] <Franciman> for the file size do I use some ffmpeg related thing or use C library? [10:50:51 CET] <wm4> I wouldn't use pos/size for a progress bar (although I do for transport streams) [10:50:52 CET] <Franciman> C std library* [10:51:24 CET] <Franciman> uhm [10:51:32 CET] <Franciman> ok then, I'll just add an Extracting... [10:51:47 CET] <Franciman> and if I have duration and sample rate, also add a progress percentage [10:52:13 CET] <nevcairiel> wm4: why not, if its just a progress bar and not a seek bar, you get an OK approximation of progress anyway [10:52:55 CET] <Franciman> just progress bar [10:55:35 CET] <wm4> for some files it could in theory go backwards (mov) [10:55:51 CET] <av500> for files with large index at the end, it wont reach 100% [10:55:56 CET] <wm4> or not progress at all (things which don't set the packet pos, because it makes no sense) [10:55:57 CET] <av500> but in both cases you should have duration [11:03:08 CET] <Franciman> I see, ok thanks again [11:03:49 CET] <av500> so basically try for duration first, if that fails fall back to pos [11:04:17 CET] <Franciman> yes, thanks [14:51:41 CET] <wm4> nevcairiel: so why is codec->sample_rate set to a "wrong" value when muxing? [14:55:06 CET] <kierank> so for various *reasons* I might need a bitrate of > 2gbit/s - is this something ffmpeg might support? [14:55:38 CET] <J_Darnley> Didn't bitrate just get bumped up to a 64-bit int? [14:56:03 CET] <J_Darnley> (the restof the code I don't know about) [14:56:08 CET] <kierank> yeah but it doesn't let you encode more than 2gbit [14:57:17 CET] <J_Darnley> Is that just because the option's max value wasn't increased? [14:59:20 CET] <kierank> probably [15:17:47 CET] <cone-763> ffmpeg 03Paul B Mahol 07master:0d3b31ae898f: avfilter/avf_showspectrum: add yet another color map [15:17:47 CET] <cone-763> ffmpeg 03Paul B Mahol 07master:c31fa1d7b44c: avfilter/avf_showspectrum: use av_clip/lrintf [15:17:47 CET] <cone-763> ffmpeg 03Paul B Mahol 07master:c13216ac0801: avfilter/window_func: add tukey window function [15:17:47 CET] <cone-763> ffmpeg 03Paul B Mahol 07master:206f65b06d0f: avfilter/avf_avectorscope: add line drawing support [15:22:06 CET] <nevcairiel> wm4: its not "wrong", but opus has a nominal sample rate of 48kHz, and apparently the spec wants the padding to always be in 48kHz units [15:24:13 CET] <wm4> the demuxer uses the codec->sample_rate field (which I suppose reflects the same EBML element in the mkv file) [15:29:27 CET] <nevcairiel> I think Opus is a bit special when it comes to sample rates, from what I understand, the decoder can kind of choose at which sample rate to decode a file, and 48kHz is the nominal case [15:30:01 CET] <nevcairiel> and it only contains "informational" metadata what the input sample rate once was [15:31:18 CET] <nevcairiel> hence metadata like the trim info always relating to the 48kHz case [15:31:52 CET] <BtbN> so kind of like those image formats where you can decode only the beginning and get a thumbnail? [15:40:15 CET] <nevcairiel> From my basic understanding its simpler than that, opus consists of two codecs, CELT and SILK, and it appears CELT always decodes to 48kHz, while SILK can change sample rate (between 8000, 12000 and 16000) depending on content needs, so in effect a decoder could always just output 48kHz and no harm would be done [15:40:22 CET] <nevcairiel> in fact the ffmpeg decoder deos just that, as it seems [15:41:26 CET] <nevcairiel> (to combine these two parts of the stream, the SILK part is internally upsampled to 48000Hz) [15:42:11 CET] <ubitux> durandal_170: *p = lrintf(av_clipf(s->combine_buffer[3 * y + plane], 0, 255)); why not av_clip_uint8(lrintf(s->combine_buffer[3 * y + plane]))? [15:44:20 CET] <durandal_170> Is there difference? [15:44:36 CET] <nevcairiel> in effiency only [15:44:50 CET] <nevcairiel> efficiency* [17:06:22 CET] <ubitux> i have a weird thing while decoding jpeg with ffmpeg [17:06:45 CET] <ubitux> decoding the first packet decodes 994202/994295 bytes [17:07:27 CET] <ubitux> strangely, doesn't call again the decode function with the remaining 93 bytes (while i do with the api, leading to an error) [17:07:47 CET] <ubitux> ffmpeg cli* doesn't [17:07:56 CET] <wm4> it doesn't have to [17:08:01 CET] <ubitux> why? [17:08:09 CET] <ubitux> packet is not fully consumed [17:08:15 CET] <ubitux> no EOF is reached [17:08:21 CET] <ubitux> and a frame was outputed [17:08:33 CET] <wm4> because it's not required for video [17:09:11 CET] <ubitux> i thought there were some streams like this? [17:09:20 CET] <wm4> no, the parsers take care of this [17:09:28 CET] <ubitux> mmh [17:09:40 CET] <ubitux> can this still be considered a bug from the decoder? [17:09:48 CET] <ubitux> (as in, not saying it consumed the whole packet) [17:09:55 CET] <wm4> probably... but couldn't the remaining data just be junk? [17:10:35 CET] <ubitux> i'll check [17:10:48 CET] <bencoh> what happens if you flush the decoder (call with NULL packet)? [17:11:21 CET] <wm4> bencoh: its internal state is reset and remaining buffered frames and data is discardedc [17:11:24 CET] <wm4> -c [17:11:50 CET] <bencoh> hm [17:12:22 CET] <bencoh> (I was talking about the jpeg one in this case) [17:12:37 CET] <bencoh> (but I guess it wouldnt be different) [17:12:41 CET] <wm4> oh ok [17:13:14 CET] <wm4> I mean it's just 93 bytes [17:13:17 CET] <wm4> what could it be? [17:13:39 CET] <nevcairiel> Jpeg doesn't sound like a decoder with delay, hence no NULL flushing [17:14:21 CET] <wm4> nevcairiel: hm, there was at least 1 image codec which you had to flush to get a frame [17:14:26 CET] <wm4> was it jpg or png [17:15:30 CET] <ubitux> wm4: http://pastie.org/pastes/10671477/text [17:15:33 CET] <ubitux> this is the junk [17:15:35 CET] <ubitux> :( [17:15:55 CET] <ubitux> (unrelated by wth is av_hex_dump*() in avformat and not avutil) [17:17:16 CET] <nevcairiel> Technically it's a bug when a video decoder doesn't consume the entire packet, but in general its not required to send data again for video [17:17:27 CET] <nevcairiel> While it is requires for audio [17:17:55 CET] <wm4> ubitux: what's the packet from? [17:18:04 CET] <ubitux> a jpeg [17:18:23 CET] <wm4> just a file? not too surprising then [17:18:35 CET] <wm4> isn't it perfectly normal to prepend or append random trash [17:18:42 CET] <wm4> like with mp3 [17:18:58 CET] <ubitux> yes just a file [17:19:04 CET] <ubitux> taken from a random android a while ago [17:19:55 CET] <ubitux> nevcairiel: soon for subtitles too [17:20:04 CET] <wm4> w-what [17:20:23 CET] <nevcairiel> What subtitle format could ever require that [17:20:25 CET] <wm4> flushing doesn't make sense for subtitles [17:21:11 CET] <ubitux> (flushing will make sense for resetting the read order in the decoder after a seek) [17:21:24 CET] <nevcairiel> That's what avcodec flush is for [17:21:26 CET] <ubitux> nevcairiel: dunno yet, but i assume it could happen [17:21:30 CET] <ubitux> nevcairiel: sure [17:21:35 CET] <nevcairiel> Not NULL packets [17:21:41 CET] <wm4> yeah, mixed terminology [17:21:45 CET] <ubitux> i'm not talking about null packets :p [17:21:47 CET] <ubitux> anyway [17:22:09 CET] <wm4> some subtitle decoders already require avcodec_flush [17:22:15 CET] <ubitux> http://b.pkh.me/blue-sky.jpg [17:22:18 CET] <ubitux> here is the jpeg btw [17:22:28 CET] <wm4> ubitux: btw. we added an API to libass to ignore readorder for deduplication [17:22:41 CET] <ubitux> ok [17:22:57 CET] <ubitux> i'm going to try to submit the sub patchset asap [17:29:24 CET] <ubitux> if (strstr(name, "image2") || strstr(name, "_pipe")) { [17:29:26 CET] <ubitux> guess what i'm doing [17:29:28 CET] <ubitux> :( [17:29:55 CET] <ubitux> can't use stream->nb_frames unfortunately :( (since 0) [17:30:19 CET] <wm4> I do that too [17:30:51 CET] <wm4> (actually I check for "image2pipe", and "image2" doesn't work due to custom IO) [17:31:11 CET] <ubitux> but don't you get jpeg_pipe or stuff like that? [17:31:12 CET] <wm4> and "_pipe" of course [17:31:21 CET] <wm4> maybe a flag would be nice here [17:31:31 CET] <wm4> but then, image formats can be ambiguous, like gif or apng [17:31:45 CET] <ubitux> well technically, image2 could be a stream [17:31:48 CET] <ubitux> jpeg as well [17:32:00 CET] <ubitux> like if you're trying to play img%4d.jpg [17:32:38 CET] <wm4> broken concept etc. [17:32:48 CET] <ubitux> something annoying is that the demuxer actually set a duration for that [17:32:48 CET] <wm4> (the % pattern matching I mean) [17:32:58 CET] <ubitux> yeah well it's actually pretty useful [17:33:05 CET] <ubitux> many people use it (me the first) [17:33:06 CET] <wm4> what framerate does it assume? [17:33:18 CET] <ubitux> 25 iirc but you can specify your own [17:33:22 CET] <wm4> sure, it's useful, but it shouldn't interpret characters in random URLs [17:33:37 CET] <ubitux> don't we have different pattern matching engines? [17:37:11 CET] <wm4> (not sure what you mean) [17:37:34 CET] <nevcairiel> We do [18:21:36 CET] <cone-763> ffmpeg 03Aman Gupta 07master:e7271e6d078a: libavcodec/ccaption_dec: remove unnecessary include [18:21:37 CET] <cone-763> ffmpeg 03Michael Niedermayer 07master:5b4da8a38a5e: avcodec/motion_est: Fix mv_penalty table size [18:48:17 CET] <prelude2004c2> hey guys.. pulling in a source with ffmpeg " skipping 1 segments ahead, expired from playlist" i get those errors and my frame rates start to drop below 25fps ...i get freezing and stuff but yet when i play the same source with VLC i don't have any issues... anyone know why ? [21:37:09 CET] <cone-763> ffmpeg 03Carl Eugen Hoyos 07master:c3c22bee6362: lavf/matroskaenc: Assume 48kHz sample rate for Opus initial padding. [21:37:54 CET] <ubitux> i wonder why the "redundant commands" are ignored in ccaption decoder [21:49:06 CET] <ubitux> lo >= 0x40 || lo <= 0x5f [21:49:23 CET] <ubitux> is it me or || should be &&? [21:49:27 CET] <ubitux> (or sth like that?) [21:50:16 CET] <ubitux> where is the specs... [21:50:17 CET] <durandal_170> yes [21:50:29 CET] <ubitux> where is anshul [21:51:01 CET] <ubitux> :(( [21:51:36 CET] <ubitux> i wonder why this weird condition wasn't detected by any static analyzer [22:39:45 CET] <cone-763> ffmpeg 03Andreas Cadhalpun 07master:fa74cdc60d19: parser: add av_assert1 to make sure the codec matches [22:39:46 CET] <cone-763> ffmpeg 03Andreas Cadhalpun 07master:da3c3c446cb4: avpacket: fix size check in packet_alloc [22:49:40 CET] <Timothy_Gu> lol at reimplementing cbrt() [22:51:47 CET] <tmm1> ubitux: i wondered that too [22:52:02 CET] <tmm1> lots of questionable code in that decoder [22:52:19 CET] <tmm1> i fixed a number of bugs last night [22:56:17 CET] <ubitux> i really don't like this command caching [22:56:35 CET] <ubitux> i feel like it's a workaround for a bug [22:56:57 CET] <ubitux> anyway, i'm translating all the commands to the appropriate masks right now [22:58:30 CET] <wm4> so, what about this event buffering the CC decoder does? [23:01:58 CET] <tmm1> ubitux: i'm not sure the masks are more readable, esp when comparing to the spec or wikipedia docs [23:02:28 CET] <tmm1> wm4: i'm working on a patch that fixes the buffering issue [23:02:36 CET] <ubitux> tmm1: do you have the specs? [23:03:34 CET] <tmm1> not the official one, no. using wikipedia and other random resources on google [23:08:34 CET] <ubitux> oh wikipedia indeed has some good doc [23:08:54 CET] <tmm1> yea its all there [23:09:49 CET] <tmm1> i can try to remove this redundant check, that will allow us to kill the buffering as well [23:10:29 CET] <ubitux> if you have a small sample which cover the code well that would be welcome [23:10:44 CET] <ubitux> i can add a fate test if you don't feel like it (but i'll need the sample) [23:10:55 CET] <ubitux> (there is already one but for 2 small events) [23:11:11 CET] <ubitux> so i don't trust it much [23:11:18 CET] <tmm1> yea i have a couple, for painton and rollup [23:32:02 CET] <tmm1> sliced up a few samples, uploading now [23:32:15 CET] <tmm1> ubitux: https://s3.amazonaws.com/tmm1/ccaptions/movie.ts [23:34:33 CET] <tmm1> also uploaded news.ts, news2.ts, sports.ts and music.ts to the same dir [23:36:23 CET] <tmm1> btw i exchanged some emails with anshul last month, but haven't been able to get in touch since the new year [23:40:54 CET] <ubitux> cool, thx [23:41:10 CET] <ubitux> they're quite large though, they won't make it to fate [23:41:21 CET] <ubitux> (around 500k would be ideal) [23:41:25 CET] <ubitux> (or less) [23:41:36 CET] <ubitux> but i'm grabbing them for personal testing :p [23:41:44 CET] <tmm1> ah, they're 30s so you can trim them down to 5s or so [23:41:58 CET] <ubitux> yeah but then you probably fucked up a bunch of events [23:42:44 CET] <tmm1> seemed to be fine when i cut down to 30s, could also perhaps re-encode the video quality down but leave the sidedata intact [23:43:47 CET] <tmm1> do you think this whitespace cleanup patch will be merged? [23:43:54 CET] <tmm1> not sure what to base further bugfix patches on [23:45:16 CET] <ubitux> i could push the patch, but right now i'm going afk, so maybe tmr [23:45:28 CET] <tmm1> ok, thanks [23:45:47 CET] <tmm1> i'll submit another patchset assuming that will be merged [00:00:00 CET] --- Wed Jan 6 2016

1 0

ffmpeg.log.20160105
by burek 06 Jan '16

06 Jan '16

[00:33:48 CET] <cluelessperson> hi all, is there a way to take a single png image, use it for 360 frames, each rotating the color hue by 1 degree? [00:38:27 CET] <Krampus> Can ffmpeg output to a virtual video source of some sort? I want to do something where I have a webcam on one computer and the audio/video stream shows up on another as if it was local to that computer. [00:43:21 CET] <DHE> not really, but ffplay can do sdl-based video playback instead [00:45:49 CET] <Krampus> Hm... not sure if that'll cover what I'm doing. My goofy scenario is I have a linux dev workstation and a windows email/lync laptop. I use remote desktop to connect to the laptop. Making calls like that is kinda problematic and being able to connect the camera / microphone locally might improve things. [00:46:07 CET] <Krampus> Or severely complecate them. I haven't quite decided. :) [01:01:30 CET] <c_14> Stream the audio/video to the other computer via tcp/udp/another streaming protocol? [03:13:04 CET] <yongyung> Does resampling from 48khz to 44.1khz cause any data loss below 20khz sounds at all? [03:13:26 CET] <TD-Linux> no. [03:35:35 CET] <klaxa> data loss, yes but quality-wise it should not be perceivable [03:35:53 CET] <klaxa> data is obviously lost because you have less samples per second [03:43:45 CET] <yongyung> klaxa: That's not how it works, actually. The quality, as in precision to the "actual sound", is defined by the bit-depth. Sample frequency only determines the highest sound frequency you can represent. I just wasn't sure if the conversion is lossless. [03:44:19 CET] <klaxa> it determines how many points you have to recreate the actual signal [03:44:24 CET] <klaxa> and 44.1k is less than 48k [03:44:43 CET] <yongyung> klaxa: I assume you don't really know how signal processing works, do you? ;) [03:44:43 CET] <klaxa> the bit-depth defines the range of those points [03:44:50 CET] <klaxa> apparently not? [03:45:35 CET] <klaxa> i thought i did, but now i'm not sure anymore [03:45:55 CET] <yongyung> Think of it like this... the sound waves are curves, and the DAC (digital to analog converter) recreates those curves from samples. If you have a parabola, you only need two points to perfectly recreate it [03:46:29 CET] <klaxa> oh wait, if everything is below 20khz it shouldn't make a difference really [03:47:07 CET] <klaxa> because you still have enough samples to accurately represent everything [03:47:38 CET] <yongyung> Well if you record it at the same time to 44.1khz and to 48khz it definitely doesn't make a difference, but I wasn't sure if the conversion is generally lossless or not. Apparently it is. [03:48:20 CET] <klaxa> i'm still not sure about the lossless thing, i mean you end up with different samples [03:52:04 CET] <TD-Linux> klaxa, yeah the key bit there was "below 20khz" [03:52:47 CET] <klaxa> i would rather say there is no information loss then, because there will be less data [03:54:14 CET] <TD-Linux> digital resampling might not be implemented in a perfectly reversible manner though. e.g. if you go 44.1k to 48k and back again a bunch of times you might start to accumulate error, depending on how you resample [03:55:03 CET] <yongyung> TD-Linux: Well that was my question, can I do that or not? :p (with wav pcm files, obviously) [03:56:18 CET] <TD-Linux> you need to be careful to select the same, reversible resampling filter. [03:56:52 CET] <TD-Linux> in the absence of quantization that's easy. but with quantization a bit more difficult [03:59:00 CET] <yongyung> Alright, different question, I have an nvidia shadowplay recorded file, which is supposed to be 60 fps, but vlc shows 59.993276 fps instead. Do you think it'd cause audio desync issues if I reencode it with -framerate 60? [03:59:45 CET] <c_14> You mean with -vf fps=60 or -r 60 as an output option? [04:00:41 CET] <c_14> Or with -r as an input option? [04:01:31 CET] <klaxa> isn't -framerate always preferred over -r? [04:01:38 CET] <c_14> No [04:01:41 CET] <c_14> They don't do the same thing. [04:01:57 CET] <yongyung> Uhh, I'm not sure. Just tell me what to use :p I guess -vf fps=60 as output option would be preferred? [04:01:59 CET] <klaxa> ah right i forgot [04:02:01 CET] <c_14> If you ie have a file that you know is 60fps but is detected as something else, use -r [04:02:50 CET] <c_14> (as an input option) [04:03:00 CET] <c_14> In your case you probably want -vf fps=60 [04:03:34 CET] <c_14> This will cause an audio desync [04:03:39 CET] <c_14> minor though [04:03:49 CET] <c_14> (you can use the asetrate audio filter to get rid of it) [04:04:02 CET] <c_14> (there will be a minor change in pitch though) [04:04:06 CET] <relaxed> you could use -framerate 60 on a raw h264 file to speed it up without encoding [04:04:09 CET] <c_14> (if the change in pitch is too much, use atempo) [04:04:57 CET] <relaxed> no, I meant -r 60 [04:05:34 CET] <relaxed> (as an input option) [04:08:54 CET] <relaxed> because I think -r as an input option only works with raw formats, not containers [04:11:22 CET] <c_14> I think it should work for containers too, at least according to the docs it just regenerates the timestamps of the input file. Never tested it though. [04:16:02 CET] <relaxed> hmm, I could have swore the man page said something about raw formats [04:16:12 CET] Action: relaxed drinks coffee faster [04:43:19 CET] <yongyung> c_14, relaxed: If -vf fps=60 causes a slight audio desync but needs reencoding, where's the point of using it instead of just using -r? [04:44:17 CET] <c_14> the filter will duplicate frames to get to the desired framerate, -r will speed up the video [04:44:22 CET] <c_14> pick your poison [04:45:12 CET] <yongyung> Hmm alright [04:46:18 CET] <c_14> oh, -vf fps shouldn't cause audio desync [04:46:24 CET] <c_14> because the video length stays the same [05:38:46 CET] <xintox> anyone stream in here? [06:41:27 CET] <yongyung> Can anyone here speculate why the youtube encoding guidelines state that 96 or 48khz audio is preferred, when every video you download from them is 44.1khz? The video guidelines seem weird to me, too [06:42:06 CET] <furq> the best explanation i have is that the youtube encoding guidelines are not very good [06:42:27 CET] <yongyung> Oh I forgot to link them https://support.google.com/youtube/answer/1722171?hl=en [06:42:43 CET] <furq> recommended audio bitrate of 384kbps for stereo [06:42:48 CET] <yongyung> furq: Yeah... maybe. On the other hand they seem so specific. It's just weird [06:44:11 CET] <furq> it's probably just defensively high to help minimise how much youtube's reencoding will ruin it [06:44:48 CET] <furq> stuff like putting the moov atom at the front of the file is completely worthless when that file will never appear on youtube [06:45:06 CET] <furq> unless maybe it makes the reencoding process faster [06:46:25 CET] <yongyung> furq: That actually helps because youtube will start encoding while your file is still uploading [06:46:47 CET] <furq> that makes sense then [06:46:52 CET] <yongyung> But 48khz, 2 consecutive B frames, closed GOP, I can't make sense of those things [07:01:09 CET] <TD-Linux> yongyung, they've switched to opus which is 48khz [07:02:04 CET] <TD-Linux> and yeah basically you want a high quality source for their transcodes. moov at front means they can start transcodes while the upload is still in progress [07:04:07 CET] <yongyung> TD-Linux: They've switched to opus? I've never seen a YT file use opus... I guess if they plan to switch and keep the source files it might make sense [07:04:34 CET] <TD-Linux> yongyung, nearly all Chrome YT plays are Opus now [07:05:07 CET] <yongyung> Not sure what that means, can you link to a video that uses Opus? [07:06:00 CET] <TD-Linux> https://www.youtube.com/watch?v=6H1rPYkRyjE [07:06:35 CET] <TD-Linux> er I could probably link to one less than 2 hours if you want to youtube-dl it :) [07:06:49 CET] <furq> just to remind everyone that you can remove youtube videos from your watch history [07:07:09 CET] <yongyung> TD-Linux: Yeah I was about to ask lol [07:07:51 CET] <TD-Linux> https://www.youtube.com/watch?v=OZpBMfA9lZs [07:08:10 CET] <TD-Linux> furq, I am pulling these videos from my watch history :) [07:08:52 CET] <TD-Linux> but just youtube-dl -F will tell you if it has opus, and most videos uploaded in the last year or many views will have opus [07:09:58 CET] <furq> yongyung: https://www.youtube.com/watch?v=LfJTcP87hsU [07:10:02 CET] <furq> enjoy [07:13:04 CET] <yongyung> TD-Linux: Uhh... Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 125 kb/s (default) [07:15:02 CET] <TD-Linux> yongyung, umm your video downloader is picking the wrong stream then? [07:15:26 CET] <TD-Linux> it has opus streams @ 50, 70, and 160 kbps [07:16:00 CET] <TD-Linux> youtube's javascript certainly picks opus first [07:16:09 CET] <furq> yongyung: youtube-dl -f webm [url] [07:16:29 CET] <yongyung> TD-Linux: I use clipconverter.cc usually, and picked the 1080p option. I don't think they're transcoding anything? [07:16:49 CET] <TD-Linux> no, but youtube also has 128k aac available on most videos. [07:17:18 CET] <yongyung> Hmm that's certainly interesting [07:17:52 CET] <TD-Linux> for youtube on potatoes [07:19:31 CET] <furq> it defaults to avc/aac here [07:19:39 CET] <furq> at 720p [07:20:20 CET] <furq> maybe because of firefox's excellent dash support, although iirc it's had webm dash support for longer than mp4 [07:23:06 CET] <yongyung> The hell is vp9 [07:23:08 CET] <yongyung> 303 webm 1920x1080 DASH video 4754k , vp9, 60fps, video only, 104.18MiB [07:23:33 CET] <yongyung> and youtube has audio-only? it's like a whole new world [07:24:07 CET] <yongyung> They didn't have all this fancy stuff when I wrote my youtube downloader :D [07:25:14 CET] <yongyung> So they basically only have separate audio and video streams now and just put them together after the fact [07:31:55 CET] <yongyung> TD-Linux: So since YT uses Opus I guess we solved the 48khz mystery, any ideas about "2 consecutive B frames" and "Closed GOP. GOP of half the frame rate."? Do you think encoding with exactly those explicit settings would give any benefit? [07:32:12 CET] <furq> i can only assume it lets them decode it faster [07:32:44 CET] <TD-Linux> my guess is people with awful encoders really wanted to feel good that they put the right numbers in [07:32:54 CET] <yongyung> furq: Considering they actually re-encode it I don't think they care about decoding speed... [07:33:18 CET] <TD-Linux> those settings will give you the best results with a JM derived encoder [07:33:42 CET] <furq> by them i mean their encoder [07:34:32 CET] <furq> speaking of youtube uploads, i wonder if they accept flac in mkv yet [07:34:45 CET] <TD-Linux> yongyung, YT uses MSE now so it delivers video and audio tracks separately to the browser [07:35:05 CET] <TD-Linux> and VP9 is their newest video codec [07:40:05 CET] <yongyung> Why is youtube-dl default selecting h264 and vorbis, and where the hell did it even get vorbis from Oo [07:45:03 CET] <TD-Linux> older YT videos have vorbis as well. I dunno, youtube-dl's selection is kind of wonky [07:45:51 CET] <furq> it always picks h264/aac for me [07:46:12 CET] <furq> i can't say i've used it much since dash started working in firefox though [07:46:24 CET] <furq> s/dash/mse/ [07:46:26 CET] <yongyung> Hmm interesting, some videos have even substantially higher bit rates for vp9 than for h264 [07:46:47 CET] <yongyung> like, 5554k vs 7031k [07:51:21 CET] <TD-Linux> yeah. I'm not sure exactly but I think they set a higher quality target for their VP9 encodes than H264. so easily compressible videos are quite a bit smaller, and hard videos get bigger [07:53:00 CET] <furq> probably helps with public perception of VP9 [07:53:22 CET] <TD-Linux> here's an example where VP9 is a lot smaller https://www.youtube.com/watch?v=_Q6J2_nvLSI [07:55:40 CET] <TD-Linux> furq, maybe, though most users don't know what video codec they are using [08:01:05 CET] <yongyung> TD-Linux: Can I somehow tell youtube-dl to download two specific format codes (video and audio) and merge them into an mkv file? [08:02:16 CET] <yongyung> Okay so a comma seperated list works, let's see if I can get it to merge [08:04:49 CET] <jafa> hi guys, decoding mpeg2 video (720p60) and feeding it into a filter graph set to "copy" with a pixel format of NV12... the profiler is saying the filter graph is using more CPU (just) than the mpeg2 decode [08:05:06 CET] <jafa> which seems crazy [08:05:25 CET] <jafa> what pixel format does the mpeg2 decoder natively spit out? [08:05:52 CET] <jafa> figure I will compare the profiler results with the filtergraph not changing the pixel format [08:06:04 CET] <furq> yongyung: -f 123+456 [08:07:18 CET] <TD-Linux> jafa, probably planar YUV [08:07:18 CET] <jafa> (filtergraph set to "copy" is because this code is common and the filter string is set differently depending on the input video properties) [08:10:00 CET] <jafa> ok, yeah - seeing a linesize of 1280, 640, 640 [11:38:32 CET] <hepek> Hello everybody. [11:39:20 CET] <waressearcher2> hepek: hallo und herzlich willkommen [11:39:33 CET] <hepek> danke [11:40:01 CET] <hepek> Is there a list of av codecs patented in the US? Some people at my company are concerned that LGPL version of ffmpeg that we use for one of our projects can get us sued by some megacorp for patent infringement. [11:41:00 CET] <hepek> If there is no such a resource, what would be the best way to check? go to patent.google.com and search for each codec in ffmpeg? [11:41:44 CET] <hepek> We already pay for h264, mpeg* and aac, for other products. What else could be there? [11:48:47 CET] <DHE> h265 would be similarly encumbered [11:50:01 CET] <DHE> the other way to look at it is that the codecs google tries to push for youtube (vp9 and opus) should be either non-patented or royalty-free. do your own research though as opus is technically patented for example [11:57:05 CET] <hepek> thanks DHE [12:07:17 CET] <furq> The Opus license automatically and retroactively terminates for any entity that attempts to file a patent suit. [12:07:20 CET] <furq> ha [14:13:13 CET] <JonG> I want to use ffmpeg to access my webcam. I tried "ffmpeg -f v4l2 -i /dev/video0 ~/output.mp4", but I am getting an error: "Unknown input format: 'v4l2'". Same with "video4linux2" instead of "v4l2". I therefore assume my build of ffmpeg is missing v4l2. I see that there is a configure option "--enable-libv4l2" (https://ffmpeg.org/ffmpeg-all.html#vi [14:13:13 CET] <JonG> deo4linux2_002c-v4l2). I added this to my configuration, but running configure I get the error: "libv4l2 not found using pkg-config". How do I add this to my build? I am following the guide at https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu with some modifications. I can add my full configure line if helpful? [14:27:23 CET] <DHE> depending on your distro you may need a "-devel" package. eg: centos has libv4l-devel [14:35:45 CET] <JonG> Thanks. has a package libv4l-dev. Installing it with sudo apt-get doesn't seem to affect my issue though. I can see "/usr/lib/x86_64-linux-gnu/pkgconfig/libv4l2.pc", which I guess is the file I need. Maybe I just need to point the ffmpeg / pkg-config to it in the configure options? [14:35:58 CET] <JonG> Ubuntu has** [14:39:43 CET] <JonG> Something like: PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig:/usr/lib/x86_64-linux-gnu/pkgconfig" ./configure ... ? (Doesn't work) [15:34:08 CET] <squeegily> I'm trying to set the audio output sink for playing audio, but setting -f pulse "$(sink)" as indicated at https://ffmpeg.org/ffmpeg-devices.html#Examples-12 is firstly not recognized by ffplay, and secondly it does NOT set the output device, just the "friendly" stream name as reported by pavucontrol. I could set it to "spiedermane" and it wouldn't make a difference. [15:39:13 CET] <squeegily> Specifically, I want to play a 358kHz audio file on the non-default sound card (48kHz), but Pulse has a hardcoded 192kHz limit which it doesn't properly report to programs. fftools have this limit hardcoded, but MPV (my default media player) has no such workaround, and VLC has an awful resampler by default, so I have to use ffplay for this. But I can't figure out how to change the audio output sink. [15:40:13 CET] <BtbN> Use ffmpeg instead [15:40:23 CET] <squeegily> I can't find the way to do it with ffmpeg [15:40:55 CET] <BtbN> Just use the pulse output and set whatever parameters you want. [15:41:10 CET] <squeegily> But how do I change the output sink? [15:41:24 CET] <BtbN> It propably has an option for that. [15:41:28 CET] <bencoh> man ffmpeg-devices [15:41:36 CET] <BtbN> Or just move it in pavucontrol after it has started. [15:42:04 CET] <squeegily> I don't want to do that since that saves a permanent override for ffmpeg [15:42:22 CET] <squeegily> And I've been digging around in the manpages since Saturday [15:42:44 CET] <bencoh> so what doesnt work with ffmpeg -i foobar -f pulse ? [15:42:58 CET] <BtbN> It saves the output sink permanently anyway [15:43:01 CET] <squeegily> that works... for the default audio device [15:43:11 CET] <bencoh> isn't there a "device" option? [15:43:20 CET] <squeegily> Nothing that I could find [15:43:57 CET] <BtbN> You're bad at searching then. [15:43:58 CET] <squeegily> https://ffmpeg.org/ffmpeg-all.html#Options-57 is where it would be if it existed [15:44:02 CET] <BtbN> http://ffmpeg.org/ffmpeg-all.html#pulse-1 [15:44:04 CET] <squeegily> pulse output options [15:44:07 CET] <squeegily> nothing there [15:44:15 CET] <squeegily> "name" is not the output device [15:44:24 CET] <BtbN> That's the pulse input you just linked. [15:46:02 CET] <squeegily> So, from that page you sent the link to [15:46:08 CET] <squeegily> what flag controns the output device [15:46:16 CET] <bencoh> the "device" one? [15:48:22 CET] <squeegily> Thanks.. I don't know how I missed that [15:49:24 CET] <squeegily> So the -device option is completely missing from ffplay, with nothing to replace it? [15:50:10 CET] <BtbN> ffplay is, basicaly, just ffmpeg with some default output settings [15:50:27 CET] <squeegily> And the really nice spectroscope and volume controls [15:50:49 CET] <bencoh> -option, maybe [15:51:19 CET] <squeegily> Failed to set value 'device' for option 'option': Option not found [15:51:55 CET] <durandal_170> ffplay spectroscope is limited use ffmpeg [17:54:36 CET] <prelude2004c> hey guys.. quick question if i may..doing some transcoding with ffmpeg... one of the players is complaining that when they use the PVR function and record something the "#EXT-E-PVRSTARTTIME" is smaller than 0. I have no idea why that is but it seems that on playback it always plays starting with the last file instead of the first file :( .. Strange right ? is there something i am doing wrong ? [18:29:42 CET] <cluelessperson> has anyone tested FFSERVER in a LARGE distribution? [18:29:47 CET] <cluelessperson> 1000+ streams at a time? [18:39:49 CET] <DHE> ffserver is a borderline hack for doing streaming. if you're doing large scale you want something else. nginx with the rtmp module maybe? (depends on your needs obviously) [18:45:54 CET] <prelude2004c2> hey guys.. pulling in a source with ffmpeg " skipping 1 segments ahead, expired from playlist" i get those errors and my frame rates start to drop below 25fps ...i get freezing and stuff but yet when i play the same source with VLC i don't have any issues... anyone know why ? [18:46:01 CET] <prelude2004c2> is there any param i can set to not tod htat ? [18:50:28 CET] <DHE> sounds like it's not playing fast enough, or it's playing from the first chunk of a live playlist [18:50:42 CET] <DHE> you start 3rd from the end (typically) for a live playlist [18:53:21 CET] <prelude2004c2> kind of strange [19:00:22 CET] <prelude2004c2> is there some way to fix that ? i mean.. it can't play fast enough and files are vanishing in the source before they can be downloaded [19:01:18 CET] <DHE> hls is the output from ffmpeg? [21:02:23 CET] <nadermx> I'm currently trying to convert a flv stream to stdout so I can stream the file as a downloadable mp4 [21:03:19 CET] <nadermx> the issue I'm having is I can get the file to show framerate, but the time of the file is not complete [21:03:48 CET] <nadermx> 'ffmpeg -i "%s" -r 30 -vcodec libx264 -s 640x480 -pix_fmt yuv420p -acodec libmp3lame -f ismv -' [21:04:09 CET] <nadermx> is what i've tried, also tried chaning the ismv to mov, and quickstart as well, I can't seem to get ac ombination that works [21:07:33 CET] <DHE> I suppose you want 'mp4' as an output, but officially it's corrupted unless you write it to a file so ffmpeg can seek and fix it when it's done... [21:08:05 CET] <nadermx> yeah, but I saw you can move the moov to the front [21:13:24 CET] <kepstin> yeah, but you can only do that if you can write the file and then go back and move the moov afterwards [21:16:00 CET] <ChocolateArmpits> well you can't really call it moving, more like rewriting the file completely [21:16:10 CET] <nadermx> would be it possible to make it a h.246 and rename it to a .mp4, so by the time the file is fully loaded the mp4 container can go and read it fully [21:17:37 CET] <kepstin> ChocolateArmpits: I think there's an option to pre-allocate some space to use for it to avoid the rewrite? or maybe I'm confusing it with the webm index [21:18:03 CET] <ChocolateArmpits> kepstin: no such thing for mp4 that I know of [21:20:35 CET] <kepstin> nadermx: if you want to stream mp4 to a client as it's being encoded, you pretty much have to use a chunk-based streaming method like HLS or DASH. [21:21:03 CET] <kepstin> (in which case, you have a minimum latency equal to the length of a chunk) [21:21:45 CET] <nadermx> @kepstin and I could make this downloadable file? [21:23:39 CET] <kepstin> if you want a downloadable file, just encode to a file then serve it, don't bother with trying to stream it as it encodes. [21:24:17 CET] <nadermx> but this takes way too long on very large files [21:24:35 CET] <nadermx> and I'm trying to avoid having to store a significant amount of the file as its being encoded [21:24:55 CET] <nadermx> I'm fine with some latentacy [21:25:12 CET] <kepstin> well, you're just hitting the limitations of the mp4 format. it's simply not designed to handle this. [21:25:54 CET] <nadermx> hrmm, so then as you said if I try and use DASH [21:26:21 CET] <DHE> or a streamable format, like mpegts [21:26:39 CET] <DHE> (which has a fair amount of overhead but is very streaming-friendly) [21:27:02 CET] <kepstin> dash is usable for live-streaming to a browser or player, but it doesn't make a file that can be downloaded/saved to hd. [21:29:18 CET] <nadermx> @DHE alright, mpegts maybe? wouldn't the ISMV also be somewhat useable? [21:30:17 CET] <DHE> don't know enough about it to be sure. just know that it's Yet Another(tm) variant of .mp4 [21:30:25 CET] <kepstin> depends on your player support requirements, really [21:30:37 CET] <kepstin> have to research what players you support and what formats work with them [21:31:34 CET] <DHE> mpegts tends to be highly supported. it's what over-the-air broadcasts are encapsulated in [21:33:17 CET] <kepstin> hey, if you're doing downloadable files only and know people have fairly good players, you could just go for mkv with an end-of-file index. [21:34:57 CET] <TD-Linux> kepstin, actually dash can be used with a single fragmented mp4 file. just hope your player supports fragmented mp4. [21:35:07 CET] <TD-Linux> or use matroska/webm [21:36:13 CET] <nadermx> could I do a m4v with audio? [21:37:08 CET] <TD-Linux> m4v is just another extension for mp4 [21:37:47 CET] <nadermx> right, but my logic is the mp4 isn't going to become a mp4 till the file is fully downloaded on the users machine, at which point the entire file is there. [21:39:00 CET] <nadermx> When i try converting on the fly to m4v the video plays with no audio [21:39:22 CET] <ChocolateArmpits> m4v is a video-only format [21:39:32 CET] <ChocolateArmpits> m4a is an audio equivalent [21:40:15 CET] <nadermx> ah ok [21:42:17 CET] <nadermx> @kepstin not sure what most users will be on and figure mp4 is most widely supported [22:09:55 CET] <Betablocker> released a tool today on github - the goal is very easy h264 video streaming for everyone on websites without streaming provider - you are welcome to test it https://datarhei.github.io/restreamer/ :) [22:38:31 CET] <TD-Linux> Betablocker, neat! I'd make it more clear on the website that the external stream providers in the pic are optional [22:40:44 CET] <Betablocker> ok thank you for the hint TD-Linux [22:42:01 CET] <Betablocker> there is optimization potential on the website & we will update it in the next weeks. but the software is working and the installation should be clear [22:50:44 CET] <nadermx> seems pretty cool [22:53:51 CET] <nadermx> can you write the metadata duration to the file? [22:57:14 CET] <Betablocker> not out of the box yet but ffmpeg is runnig under the engine hood - so it should work with a tiny hack [22:58:56 CET] <nadermx> Mind sharing that hack? [00:00:00 CET] --- Wed Jan 6 2016

1 0

ffmpeg-devel.log.20160104
by burek 05 Jan '16

05 Jan '16

[00:01:28 CET] <cehoyos> I prefer to call them thieves and liars but some seem to dislike this;-) [00:02:45 CET] <durandal_170> stop talking nonsense [00:03:05 CET] <rcombs> the dark side of the force [00:03:14 CET] <rcombs> (we have cookies!) [00:03:24 CET] <cehoyos> What nonsense? [00:03:38 CET] Action: rcombs gives cehoyos a cookie [00:03:45 CET] <cehoyos> Thx! [00:04:38 CET] <durandal_170> you are brown side [00:05:09 CET] <rcombs> it's sort of a grey area [00:05:27 CET] <durandal_170> :) [00:05:39 CET] <cehoyos> The copyright violations? Or the claims on their homepage? Or the MPlayer infrastructure? [00:06:07 CET] <rcombs> the cookies [00:06:51 CET] <durandal_170> trocadero [00:08:20 CET] <durandal_170> I see nothing wrong with foo decoder [00:38:13 CET] <Compn> is it the uk requiring cookies [00:38:15 CET] <Compn> or the whole eu ? [00:38:17 CET] <Compn> anyone know? [00:38:25 CET] <Compn> because i'm pissed at these cookie notices on all these websites [00:38:39 CET] <Compn> its how the internet has worked for hte last 18+ years you damn cookie monsters [00:38:43 CET] <Compn> REEEEEEEEEEEEEEEEEEEEEEEEE [00:39:32 CET] <J_Darnley> It was the EU we can thank for that. [00:39:49 CET] <Compn> great. [00:40:17 CET] <atomnuker> so what, no one can touch you if you don't show the notice [00:40:30 CET] <Compn> too many double negatives atomnuker [00:41:04 CET] <atomnuker> double negatives enhance the negative effect in many languages [00:42:05 CET] <atomnuker> also, MEGA just dumps the file into browser cache and you browser then copies the file from there AFAIK [00:42:10 CET] <Compn> i know [00:42:21 CET] <atomnuker> so that's far worse than cookies yet no notices or anything [00:42:22 CET] <Compn> that mega cache is tasking the memory leaks in many web browsers hahah [00:42:32 CET] <Compn> web browser can barely hang on :D [01:48:28 CET] <Compn> wm4 : does audio over hdmi work in mpv ? [01:48:31 CET] <Compn> linux [01:48:57 CET] <Compn> asking for a user, i should probably get some hdmi equipment... [01:49:04 CET] <Compn> sitting here back in 2003. :p [01:50:45 CET] <atomnuker> if your HDMI output appears as a separate sound card output (which it should) it'll work with anything [01:53:05 CET] <Compn> should work, yes [01:53:12 CET] <Compn> betting on linux audio? mmm [01:54:40 CET] <atomnuker> pulse and alsa never failed me [01:56:22 CET] <Compn> never? [01:56:35 CET] <Compn> do you watch films with a media player (if so which one?) [01:57:16 CET] <atomnuker> mpv [01:57:50 CET] <atomnuker> I've tried to remember an instance where pulseaudio broke (and it wasn't mine or my distro's fault) and I can't [01:59:22 CET] <philipl> Compn: yes, it works. It's how I use it. [01:59:25 CET] <philipl> the app doesn't care. [01:59:49 CET] <Compn> cool [02:45:25 CET] <cone-301> ffmpeg 03Michael Niedermayer 07master:4da2ac5c7a49: avcodec/h264: Fix regression caused by removial of default_ref_list [03:43:14 CET] <cone-301> ffmpeg 03Mats Peterson 07master:bf42a7ef6d07: lavc/qtrle: Use AV_PIX_FMT_PAL8 for 1-bit video [03:43:15 CET] <cone-301> ffmpeg 03Mats Peterson 07master:b6c61b7d43fa: lavf/qtpalette: Ignore greyscale bit in certain cases [03:45:46 CET] <jamrial> huh, it made it in [04:00:02 CET] <Compn> persistant, i would have given up long ago :D [04:28:43 CET] <RiCON> i'd have given up right at the trac ticket [09:39:41 CET] <j-b> 'morning [09:58:41 CET] <durandal_170> 'evening [10:48:19 CET] <mateo`> hello o/ [10:49:43 CET] <wm4> michaelni: is there any deeper reason why yadif doesn't support nv12? [11:17:30 CET] <ubitux> [11:17:35 CET] <ubitux> oups [11:18:35 CET] <nevcairiel> wm4: other than the code not being written for it ? :D [11:20:18 CET] <michaelni> wm4, no deep reason [11:24:51 CET] <wm4> it somehow supports some 10/16 bit per channel formats, so it can't be just restrained to 1 byte per pixel [11:25:08 CET] <wm4> but I have trouble seeing how it actually works [11:25:28 CET] <nevcairiel> the interleaving probably needs some extra magic to be supported [11:32:08 CET] <cone-546> ffmpeg 03Anton Khirnov 07master:9d74012761bc: h264: improve behaviour with invalid reference lists [11:32:08 CET] <cone-546> ffmpeg 03Maxym Dmytrychenko 07master:a43905f4ae26: qsvenc_hevc: improve the default settings [11:32:08 CET] <cone-546> ffmpeg 03Maxym Dmytrychenko 07master:3b6473b43eb6: qsvdec: properly handle the warning from MFXVideoCORE_SyncOperation [11:32:08 CET] <cone-546> ffmpeg 03Hendrik Leppkes 07master:1fec347ef56b: Merge commit '9d74012761bc3ee676fe43321d5699e4877fde5b' [11:32:08 CET] <cone-546> ffmpeg 03Hendrik Leppkes 07master:ad53c94d8fe0: Merge commit 'a43905f4ae261bdde87c300901d867b31961f57b' [11:32:09 CET] <cone-546> ffmpeg 03Hendrik Leppkes 07master:9507f68deb66: Merge commit '3b6473b43eb69fc3faaf69f7fd0b83b51db7607f' [11:32:58 CET] <cone-546> ffmpeg 03Diego Biurrun 07master:58170b027144: lavc: Add missing #includes for ff_dlog() [11:33:00 CET] <cone-546> ffmpeg 03Hendrik Leppkes 07master:3e337f0e4014: Merge commit '58170b027144f4840018c7a60fb8d07924cc6242' [11:34:20 CET] <ubitux> nevcairiel: not sure if it's because of a recent merge, but did you see http://fate.ffmpeg.org/log.cgi?time=20160104090113&log=compile&slot=x86_64-… ? [11:41:10 CET] <cone-546> ffmpeg 03Diego Biurrun 07master:2080bea4a74b: h264_refs: Remove broken trace debug code [11:41:11 CET] <cone-546> ffmpeg 03Hendrik Leppkes 07master:e1c5170c638e: Merge commit '2080bea4a74b6b1598caa806a11ea807ba546f94' [11:41:19 CET] <nevcairiel> ubitux: ^^ [11:41:38 CET] <ubitux> lol ok thanks [12:21:21 CET] <kurosu> hi [13:08:30 CET] <cone-546> ffmpeg 03Andreas Cadhalpun 07master:e7a7b3135a4e: vorbisdec: reject rangebits 0 with non-0 partitions [13:21:28 CET] <cone-546> ffmpeg 03Andreas Cadhalpun 07master:d7d37c479fa7: brstm: make sure an ADPC chunk was read for adpcm_thp [13:21:29 CET] <cone-546> ffmpeg 03Andreas Cadhalpun 07master:bcf4ee26a0a1: brstm: also allocate b->table in read_packet [13:49:28 CET] <cone-546> ffmpeg 03Andreas Cadhalpun 07master:1cb2331eca0d: brstm: fix missing closing brace [14:07:36 CET] <cone-546> ffmpeg 03Paul B Mahol 07master:6defda1cdb41: avfilter/avf_showspectrum: add option to set gain for calculating color intensity [18:30:11 CET] Action: Daemon404 pokes ubitux [18:30:23 CET] <ubitux> yup? [18:30:39 CET] <Daemon404> do you have a comment on carl's decimate change [18:31:13 CET] <ubitux> i need to look more closely, it's been a long time [18:31:27 CET] <ubitux> i need to "sync" it with upstream since a long time [18:31:55 CET] <ubitux> i'll check tonight (in ~3h probably) [18:32:07 CET] <ubitux> but feel free to push if it's urgent [18:32:11 CET] <Daemon404> it's not [18:59:33 CET] <cone-546> ffmpeg 03Matthieu Bouron 07master:44913d19457d: swscale/arm/yuv2rgb: fix typo [18:59:34 CET] <cone-546> ffmpeg 03Matthieu Bouron 07master:e4e9b9454e97: swscale/arm/yuv2rgb: add ff_yuv422p_to_{argb,rgba,abgr,bgra}_neon_{16,32} [20:52:32 CET] <nevcairiel> I found a 32-bit FLAC file, which apparently libFLAC reference cant even decoder, but FFmpeg can .. wonder who or what produced this file [20:53:24 CET] <ubitux> grep -i lavc bla.flac? :) [20:53:42 CET] <nevcairiel> the metadata claims libflac encoded it [20:53:49 CET] <nevcairiel> but why cant it decode it then [20:54:27 CET] <TD-Linux> 32 bit flac files are not a thing [20:54:46 CET] <nevcairiel> this one would disagree with you [20:54:55 CET] <TD-Linux> how are you even determining that it is 32 bit? [20:55:09 CET] <nevcairiel> the file encoded the bitdepth in the header [20:56:30 CET] <TD-Linux> ah OK I see it is actually possible. [20:59:28 CET] <nevcairiel> yeah streaminfo says 32-bit [20:59:57 CET] <nevcairiel> now to figure out why the libflac decoder fails [21:00:00 CET] <nevcairiel> maybe my wrapper is wonky [21:00:17 CET] <J_Darnley> Did ffmpeg once mark 24-bit as 32-bit because it couldn't hold 24-bits from the input? [21:00:38 CET] <J_Darnley> The reference only supports 24 bit [21:00:45 CET] <TD-Linux> nevcairiel, I don't think libflac supports 32 bit. which doesn't explain the metadata. [21:00:47 CET] <J_Darnley> (up to 24 that is) [21:01:10 CET] <TD-Linux> from google, flake is the only encoder I could find that can output 32 bit [21:01:12 CET] <nevcairiel> TD-Linux: they wouldnt be as crazy as supporting 32-bit encoding but not decoding, would they [21:01:35 CET] <TD-Linux> nevcairiel, maybe it's someone's hacked up libflac? [21:02:21 CET] <nevcairiel> TD-Linux: i suppose thats a possibility, but if the reference cant even decoder it, handing out such files would feel odd [21:03:13 CET] <nevcairiel> apparently its from some crazy website that sells these in s ome form [21:03:47 CET] <TD-Linux> nevcairiel, indeed. I originally said 32-bit flac files weren't a thing because I knew libflac didn't support them [21:04:07 CET] <TD-Linux> I suspect the standardization of flac in CELLAR will explicitly ban them [21:04:11 CET] <nevcairiel> Yeah I remembered that about libflac, but ffmpeg flac decoder supports it [21:04:18 CET] <nevcairiel> sounds fine at least [21:04:21 CET] <nevcairiel> no clue if lossless [21:06:53 CET] <nevcairiel> 32-bit integer audio for distribution is just silly anyway [21:07:04 CET] <nevcairiel> but you know, users of a media player expect their media to play [21:07:34 CET] <wm4> nevcairiel: that's such a cliched and outdated point of view [21:07:43 CET] <wm4> media players should be able to browse the web [21:07:57 CET] Action: wm4 goes trolling somewhere else [21:08:10 CET] <Compn> winamp actually has winamp browser [21:08:11 CET] <Compn> :D [21:08:44 CET] <fritsch> wm4: haha - sadly with all the cripled DRM content out there ... open source media centers sadly need to do that - to play that stuff with chrome html5 drm and so on [21:08:59 CET] <wm4> reality trolls better [21:13:06 CET] <jamrial> nevcairiel: header aside, is it truly 32bit? [21:13:23 CET] <nevcairiel> who knows [21:13:53 CET] <nevcairiel> its encoded as such in any case, if it outputs full 32-bit audio information i couldnt tell you [21:14:02 CET] <nevcairiel> but my real problem is that libflac fails on it anyway :) [21:14:15 CET] <wm4> why do you care about libflac? [21:16:53 CET] <nevcairiel> because thats what work uses for flac handling [21:17:15 CET] <wm4> you can't use libavcodec? [21:18:00 CET] <nevcairiel> need libflac anyway for tagging, then using avcodec for decoding would be awkward [21:19:17 CET] <nevcairiel> http://files.1f0.de/samples/big/Flac32.flac if someone is curious [21:24:29 CET] <J_Darnley> I'm curious but not 200M curious. [21:26:32 CET] <jamrial> BBB_: for some reason my last email was sent to you alone instead of the ml [21:26:39 CET] <jamrial> guess it's becase you cc me [21:27:56 CET] <BBB> weird [21:27:59 CET] <BBB> sorry about that [21:56:14 CET] <cone-546> ffmpeg 03Michael Niedermayer 07master:9434ec5f767c: avcodec/h264_refs: Fix and add back trace code removed in e1c5170c638e39a8017827339ac687c5f6ff9b35 [22:10:01 CET] <atomnuker> Daemon404: it's been like a day and no one has responed against removing libstagefright [22:10:15 CET] <Daemon404> atomnuker, im catching a tarsatlatnic flight tonight [22:10:18 CET] <Daemon404> ill give it 1-2 more days [22:10:26 CET] <Daemon404> so nobody yells at me [22:10:35 CET] <atomnuker> yeah, I'd wait a little bit longer too [22:11:29 CET] <J_Darnley> Today was only the first business day of new year. Waiting is probably a good idea. [22:15:23 CET] <atomnuker> good luck on your tarsatlatnic flight, hope not many kids to go tarsatlatnica this time of the year [22:19:32 CET] <Daemon404> tarsatlatnica is great this time of year though [22:19:47 CET] <Compn> we are always at war with tarsatlatnica. [23:16:11 CET] <llogan> FFmpeg (2.9|3.0) "Tarsatlatnic" [23:16:43 CET] <Daemon404> lulz [23:35:18 CET] <Compn> seems like a good start to the year, trolling hardcore. [00:00:00 CET] --- Tue Jan 5 2016

1 0

ffmpeg.log.20160104
by burek 05 Jan '16

05 Jan '16

[04:36:12 CET] <Deihmos> is there a way to make ffmpeg run full speed without usinga command line? [04:36:52 CET] <Deihmos> i am using a python script to auto convert mkv to mp4 but it takes so long to remux a video with aac [05:07:47 CET] <Deihmos> how can i get ffmpeg to use 4 cores by default [05:52:41 CET] <PhoenixBR> Hi everyone! Is there anyone here that worked with dummynet? [10:23:51 CET] <C0nundrum> hello [10:24:39 CET] <C0nundrum> When saving this stream in the flv container, i get no audio [10:24:43 CET] <C0nundrum> http://pastebin.com/tX0seBzY [10:29:26 CET] <relaxed> C0nundrum: pastebin the command and all output [10:32:54 CET] <C0nundrum> ffmpeg src -vcodec copy -acodec copy -bsf:a aac_adtstoasc -f flv dest [10:35:53 CET] <relaxed> omit -bsf:a aac_adtstoasc [10:39:18 CET] <C0nundrum> hm ok [11:07:50 CET] <C0nundrum> if i do that i get Malformed AAC bitstream detected: use audio bitstream filter 'aac_adtstoasc' to fix it ('-bsf:a aac_adtstoasc' option with ffmpeg) [11:07:50 CET] <C0nundrum> av_interleaved_write_frame(): Invalid data found when processing input [11:09:16 CET] <relaxed> odd, is the source container mp4? I tested it and it worked fine for me. [11:13:29 CET] <C0nundrum> its f4v_aac [11:14:23 CET] <relaxed> it really helps if you pastebin.com the complete command and and all console output [11:22:41 CET] <C0nundrum> http://pastebin.com/UW4CVF9e [11:26:51 CET] <relaxed> right, with this command the output container is mp4, not flv. Also your ffmpeg version is alomst 3 years old (which is ancient) [11:32:52 CET] <relaxed> C0nundrum: latest ffmpeg version will do the correct -bsf by default. get the latest static build here http://ffmpeg.zeranoe.com/builds/ [11:34:20 CET] <C0nundrum> ok i'll try updating [12:06:53 CET] <C0nundrum> same problem [12:55:10 CET] <phed> I am quite sure I could do this before; but I have a video that I want to mux with audio. I want to skip in only the audio, but not the video. Eg mux a 1 minute video with 1 minute from the audiofile, but skip the first 20 minutes. [12:57:40 CET] <DHE> specify your options before the "-i audiofile.wav" options to have them apply to that audio file [13:11:10 CET] <phed> DHE: ugh i thought i've tried that combination already. it kept skipping the video file, but i must have been looking wrong all the time. there's some weird heuristics where it will skip into the previous -i, but that might be only after the last input i guess [13:11:52 CET] <phed> DHE: thanks [14:16:56 CET] <kynlem> is there an orthodox way to split a video file into independent one-minute chunks (not for streaming)? [14:18:34 CET] <kynlem> i just have a bunch of two-gigabyte videos from my action camera [14:18:47 CET] <kynlem> and smaller files are easier to deal with [14:19:28 CET] <kynlem> i want to keep them as close to the original as possible, hence they don't have to be precisely one-minute long (don't want to reencode) [14:19:57 CET] <DHE> there is a "segment" output format you can use [14:20:36 CET] <kynlem> yeah, tried that one, but the videos it produces seem to have "false length" when i open them in vlc [14:20:58 CET] <kynlem> eg. the fourth video appears to be 4-minute long, and i can't navgate through it [14:21:07 CET] <kynlem> (in reality each video is one minute long) [16:27:09 CET] <rjp421> how do i make ffmpeg not exit when encoding to mjpg to http and the client disconnects? [16:30:16 CET] <rjp421> 'ffmpeg -loglevel info -r 5 -s 176x144 -f video4linux2 -i /dev/video2 -listen 1 "http://0.0.0.0:1236/webcam.mjpeg"' [16:32:23 CET] <claw> hello i try to get almost same encoding speed as '-preset ultrafast' of x264 but with vp8 or vp9 [16:33:17 CET] <claw> heres what i've tried '-cpu-used 0 -preset ultrafast -qmin 25 -qmax 63 -speed 8 -deadline realtime' [16:33:22 CET] <vsibilla> dear users, can I explaine my question? [16:34:07 CET] <vsibilla> I need to import my MXF file, created with ffmpeg, Sony Content Browser, but it doesn't work [16:34:35 CET] <vsibilla> I tried with the last release of FFmbc and it works (please visit: https://github.com/bcoudurier/FFmbc/commit/a9cc593546280c8aba4d4340be884fc8…) [16:34:40 CET] <claw> vp8: ~60fps , vp9: ~70fps, x264: ~90fps [16:34:43 CET] <vsibilla> how can help me? [16:37:19 CET] <sfan5> claw: the webm docs say that cpu-used works the other way around: "Setting a value of 4 or 5 will turn off "rate distortion optimisation" which has a big impact on quality, but also greatly speeds up the encoder." [16:37:32 CET] <sfan5> http://www.webmproject.org/docs/encoder-parameters/#2-encode-quality-vs-spe… [16:38:51 CET] <claw> sfan5: setting it to 5 makes it a bit slower for vp8 and vp9 aswell [16:40:10 CET] <claw> sfan5: using -deadline realtime sets cpu-used anyway i guess [16:41:30 CET] <sfan5> possibly [16:43:00 CET] <vsibilla> anyone can help me? [16:45:48 CET] <shincodex> i open up a cgi stream/http thats in mjpeg format and it says invalid data instream... Yet vlc opens it which is a layer ontop of avcodec collection and it works. [16:46:02 CET] <shincodex> makes me think i configured and -disabled something that i shouldnt have [16:49:30 CET] <rjp421> how do i make ffmpeg not exit when encoding to mjpg to http and the client disconnects? [16:58:11 CET] <rjp421> i dont see it in the help [16:58:24 CET] <shincodex> this library has a help? [16:58:27 CET] <shincodex> holy crap [18:10:26 CET] <BLZbubba> hi guys i have an mp4 that is missing chapters, and I have the chapter times in a text file. what is the best way to add them? e.g. is there a file format to use or can i run a separate command to add each chapter [18:11:44 CET] <BLZbubba> i hope I don't have to go this route but this is a good hack: http://www.kgarner.com/blog/archives/2010/05/24/addings-chapters-to-an-exis… [18:29:05 CET] <BLZbubba> it worked using: MP4Box -chap chapters.txt blah.mp4 [18:29:08 CET] <BLZbubba> fyi [21:33:04 CET] <rjp421> http://ftp.tuebingen.mpg.de/pub/kyb/towolf/raspberry-camera-streaming/ [21:33:52 CET] <Disturbed1> good day everyone... [21:34:02 CET] <rjp421> how do i make ffmpeg not exit when encoding to mjpg to http and the client disconnects? [21:39:23 CET] <Betablocker> you could try with this @rjp421 instead of the ftp.tuebingen link http://datarhei.github.io/restreamer/ [21:40:36 CET] <rjp421> neat ty [21:42:08 CET] <Disturbed1> quick question.... i got nvenc to work with ffmpeg, (pulled tesla qty 4x c870 cards out of s870 chassis and replaced with 1 geforce gtx 650 ti & 1 geforce gt 640) with driver 358.09 installed... nvidia-smi shows both... (cuda sdk) deviceQuery and bandwithTest see both and work... [21:42:23 CET] <Disturbed1> my question is, with ffmpeg i plan to use Transcoding / repeating, how do i tell ffmpeg which gpu to use??? [21:42:36 CET] <c_14> iirc the option is called -gpu [21:43:10 CET] <Disturbed1> ka thx c_14.... will test... [21:43:42 CET] <Disturbed1> i stole my friends geforce cards last night... muhahah [21:53:56 CET] <Disturbed1> c_14: yup, that was it, nice and simple... wish everything could be that way.... :) [22:56:21 CET] <PhoenixBR> Hi everyone! Is there anybody who already worked with any network emulator (netem, dummynet) ? [23:02:00 CET] <C0nundrum> Hi Why When saving this stream in the flv container, i get no audio http://pastebin.com/UW4CVF9e ? [23:15:20 CET] <waressearcher2> PhoenixBR C0nundrum hallo und herzlich willkommen [23:18:23 CET] <llogan> C0nundrum: you're telling it to use the flv muxer, then naming it mp4. [23:19:11 CET] <llogan> also, your build is old and unsupported [23:23:34 CET] <C0nundrum> The same thing hapeens with the latest build and when specifying the -f i was under the assumtion that it doesn't look at the name extension ? [23:24:21 CET] <llogan> you don't need -f [23:25:53 CET] <C0nundrum> ok, buy it doesn't explain why the audio doesn't work in an flv container [23:26:56 CET] <C0nundrum> I provided a pastebin which shows the input and output types O.o [23:27:55 CET] <llogan> that was a different command and (and hopefully) different ffmpeg build [23:28:29 CET] <squeegily> Would it be possible to add an example to the documentation for ffplay on how to select the output sink? [23:28:57 CET] <squeegily> I see that -sources pulse will LIST the available sinks, but I can't figure out where I'm supposed to plug those in to [23:46:10 CET] <llogan> squeegily: http://ffmpeg.org/ffmpeg-devices.html#Examples-12 [00:00:00 CET] --- Tue Jan 5 2016

1 0

ffmpeg-devel.log.20160103
by burek 04 Jan '16

04 Jan '16

[01:23:21 CET] Action: michaelni gets a new kind of IRC spam: http://pastebin.com/yGkwmf1g [01:25:27 CET] <BtbN> I have disabled incoming queries entirely because of way too much spam [01:25:50 CET] <nevcairiel> i dont get s uch spam at all on freenode [01:26:00 CET] <nevcairiel> but i'm not in big public channels [01:26:12 CET] <BtbN> I'm in way too many channels I guess [01:30:14 CET] <michaelni> i get very little spam via IRC (Freenode/OFTC/GIMPNet) i maybe on the order of one per week or so [01:32:43 CET] <kierank> I get even less [01:32:49 CET] <kierank> usually highlight spam [01:35:55 CET] <BtbN> Looking through my ZNC logs, it blocked 23 incoming queries in the last 14 days, and on a quick look, only 2 of them are not spam. [02:02:35 CET] <atomnuker> dirac has some really primitive quantization which can make some cool effects: https://0x0.st/owK.jpg [02:03:01 CET] <atomnuker> all it does is it divides the coefficients for every slice by a value which gets transmitted beforehand [02:03:25 CET] <atomnuker> then it just golomb encodes in to the bitstream [02:04:55 CET] <atomnuker> I don't think I actually mentioned I have a working Dirac HQ encoder in libavcodec [02:06:11 CET] <atomnuker> the cool thing is you can have separate quantization values per slice [02:06:50 CET] <atomnuker> so you can just scan the highest level HH orientation and decide what quantizer to use based on the total energy in that block/slice [02:07:40 CET] <atomnuker> though if it's completely empty and the image is soft you'd have to go down to a lower HH level to pick out details [02:32:39 CET] <atomnuker> though the default quantization matrix defined by the standard gets it wrong and allocates too many bits for the higher levels IMO [02:34:07 CET] <atomnuker> thankfully the format does allow you to transmit a custom quantization matrix to define per level per orientation quantization (the slice quantization level just tweaks the values in the matrix) [04:49:11 CET] <BBB> atomnuker: omg the banding is real :D [06:13:01 CET] <cone-870> ffmpeg 03James Almer 07master:35b0c7efda52: x86/vf_stereo3d: remove a few unnecessary movas [06:33:32 CET] <prelude2004c> hey guys. having trouble with vdpau... someone told me to decode using " vc ffh264vdpau " . not sure where to put that.. i am using ffmpeg [06:33:53 CET] <prelude2004c> mpeg2video sources seem to decode ok and then i can transcode it to something else.. but h264 sources don't seem to decode at all [06:33:59 CET] <prelude2004c> i am using M4000 card [06:34:07 CET] <prelude2004c> running latest 258.16 version [07:33:58 CET] <prelude2004c> anyone ? [09:35:29 CET] <j-b> 'morning [10:19:11 CET] <ubitux> https://fgiesen.wordpress.com/2016/01/02/end-of-buffer-checks-in-decompress… [12:20:23 CET] <Franciman> Hi [12:21:40 CET] <Franciman> Does the AVPacket used for flushing in audio decoding need to be initiated with av_init_packet [12:21:58 CET] <Franciman> or is it enough to just set packet.data = NULL; and packet.size = 0; ? [12:24:18 CET] <nevcairiel> you should always init a packet [12:24:44 CET] <Franciman> ok, thank you [12:53:49 CET] <ubitux> so, if i understand well, closed captions and teletext can typically output multiple subtitles for 1 packet [12:54:16 CET] <ubitux> question is: will they always have the same ts and duration? [12:54:36 CET] <ubitux> or do we need to have some time offseting mechanism in the rectangle itself? [12:56:22 CET] <ubitux> at least for ccaption it seems the pts is constant (no idea why it's passed all around for no apparent reason) [12:57:01 CET] <ubitux> i'm interested in random ccaption samples if anyone has some btw [13:08:06 CET] <ubitux> tmm1: lol indeed wtf is this pktbuf [13:11:22 CET] <wm4> ubitux: if they need different timing for different parts of the rectangle, you can just use the minimum duration of all rectangles for the whole AVSubtitle [13:11:34 CET] <wm4> instead of introducing per-rectangle durations (which would be very fucked up) [13:16:34 CET] <wm4> actually that's what happens with PGS too (I'm not sure though if PGS can actually time separate rectangles independently) [13:37:58 CET] <Compn> ubitux : https://trac.ffmpeg.org/ticket/2933 [13:38:30 CET] <Compn> ubitux : https://trac.ffmpeg.org/ticket/3172 [13:39:35 CET] <Compn> ehe [13:40:32 CET] <wm4> "They're essentially just base64'ing the raw cc608/cc708 data wrapped in some transport stream-type packets." [13:40:35 CET] <wm4> holy fuck what [13:41:26 CET] <Compn> ubitux : or if you want to make a demuxer for mxf smpte captions, https://trac.ffmpeg.org/ticket/726 [13:41:40 CET] <Compn> wm4 : its flv, they can do whatever they want :P [13:41:57 CET] <wm4> Compn: we're talking about proper closed captions, not ridiculous non-stabdard hacks employed by a single streaming site [13:42:02 CET] <Compn> oh bah :P [13:42:23 CET] <wm4> standard even (though stab-art would fit too) [13:44:48 CET] <Compn> we have a lot of samples of cc in odd formats, wtv for example, https://trac.ffmpeg.org/ticket/1482 [13:49:29 CET] <Compn> youtube has an interesting page on closed captions [13:49:30 CET] <Compn> https://support.google.com/youtube/answer/2734698?hl=en [13:50:01 CET] <Compn> says they support all of these external cc formats .scc .stl .tds .cin .asc .cap [13:50:12 CET] <wm4> and how is that related to anything [13:50:22 CET] <Compn> ubitux : can use kierank's google filesearch util to grab those filetypes ? [13:51:11 CET] <Compn> we also have .scc in trac [13:51:19 CET] <Compn> dont remember seeing the rest of those though [13:51:41 CET] <Compn> wm4 : you are too quick for me this morning :) [13:53:06 CET] <Compn> heres that google filesearch util https://github.com/subho007/python-downloader [13:53:17 CET] <Compn> it does bing too [13:54:12 CET] <Compn> guess i should install that and add to our sample repo... [13:54:54 CET] <JEEB> hmm, I like how people generally don't tend to first read stuff into a buffer, and then parse that [13:55:21 CET] <JEEB> makes looking at possible file formats simpler when you can see exactly what kind of reads are being made to which offsets [13:56:41 CET] <Compn> instead of probing the first xx kb of a file and then parsing, they do little offsets first... yes that would make reverse engineering easier [13:57:04 CET] <JEEB> yup [13:57:26 CET] <Compn> should put that into a howto RE guide :P [13:57:39 CET] Action: Compn runs before wm4 calls it "utterly obvious" [13:58:08 CET] <JEEB> yeah, I kind of decided to look at my issue with this DRM thing from another side [13:58:24 CET] <JEEB> esp. since I somehow got around its rootkit and got the license files [13:58:36 CET] <Compn> what drm format ? [13:58:42 CET] <JEEB> cypherguard for movie [13:58:49 CET] <JEEB> used by some Japanese vendors [13:58:51 CET] <Compn> oh, not wmv then [13:58:55 CET] <Compn> something new, i see. [13:58:59 CET] <JEEB> it can be whatever [13:59:14 CET] <JEEB> it's basically a crypted file and they use Media Foundation through WMP.dll [13:59:23 CET] <JEEB> in their crappy, crappy player [13:59:29 CET] <Compn> haha [13:59:33 CET] <JEEB> while their rootkit burns your machine alive [13:59:48 CET] <Compn> thats why drm fails, the rootkits and crappy player annoys some hacker into breaking it :D [14:00:04 CET] <Compn> if only they gave you a good player, it wouldnt offend so many people :P [14:00:28 CET] <JEEB> also I'm pretty sure this shit is worse than the DVD [14:00:32 CET] <JEEB> which has much less DRM in it [14:01:38 CET] <JEEB> now I just have to find the spots where it touches these license files in the binaries I dumped (because of course they used off-the-shelf obfuscation) [14:01:49 CET] <JEEB> (asprotect) [14:04:07 CET] <durandal_1707> what it does? [14:04:44 CET] <Compn> rot13 obfuscation! :P [14:06:19 CET] <JEEB> nah, it does employ some things that require script to get around [14:06:25 CET] <JEEB> (or dumping the binaries from memory) [14:06:36 CET] <JEEB> *scripting [15:54:42 CET] <cone-807> ffmpeg 03Nicolas George 07master:962727acb4e3: lavfi/vf_decimate: do not compare the first frame to itself. [16:05:46 CET] <nevcairiel> michaelni: do you want to push the h264 ref list revert? or waiting for more comments? [16:07:38 CET] <michaelni> wanted to wait a bit, yes [16:08:01 CET] <nevcairiel> ok [16:10:02 CET] <cone-807> ffmpeg 03Michael Niedermayer 07master:97c162add7f3: avformat/ffmdec: Add {} to nested if/else [16:10:22 CET] <jiggunjer> so what forums do ffmpeg devels frequent? they ever visit doom9 and such? [16:10:34 CET] <nevcairiel> some do [16:10:50 CET] <michaelni> ill probably push it later today though if i dont forget and noone commented and i dont run into a reason to wait more [16:45:21 CET] <durandal_1707> jiggunjer: what's there? [16:46:52 CET] <kierank> nevcairiel's club of fanbois is there :) [16:47:22 CET] <durandal_1707> something recently? [17:19:11 CET] <jiggunjer> durandal_1707: nah just curious [17:22:46 CET] <wm4> durandal_1707: there are people who use avisynth [17:22:59 CET] <wm4> and other windows-only legacy fun [17:23:14 CET] <wm4> (the "legacy" bit is a troll, don't mind) [17:27:27 CET] <jiggunjer> wm4: I think vapoursynth seems pretty cool. I just can't install it :p [17:33:45 CET] <Daemon404> why not? [17:34:26 CET] <Daemon404> also doom9 is also full of "special" people [17:34:34 CET] <Daemon404> on some forums [17:34:41 CET] <Daemon404> one guy wrote a webserver in avisynth [17:43:16 CET] <durandal_1707> It sucks [18:05:25 CET] <durandal_1707> atomnuker: do time and frequency axis legends needs to go in power of 10 or any number may be used? [18:10:19 CET] <atomnuker> linear for the time legend (0 secs, 10 sec, 20 sec, etc.) and -inf to 0 dB for the amplitude [18:12:22 CET] <atomnuker> sorry, I mean linear for the frequency as well (the amplitude is the color) [18:27:32 CET] Action: Compn finally installs that google downloader and realizes its kind of crap. bunch of html files downloaded, how useful... [18:34:56 CET] <ubitux> Compn: i'm interested in decoding working samples, not stuff isn't supported yet, but thx [18:35:11 CET] <ubitux> wm4: yeah i'm just wondering about stuff that needs different timing for rectangles [18:35:26 CET] <ubitux> but i guess the decoder could just consume part of the packet and out multiple sub [18:35:30 CET] <ubitux> juste like the other codecs [18:35:37 CET] <wm4> yeah [18:35:48 CET] <wm4> so even if the need for it arises, we'll be fine [18:36:02 CET] <ubitux> alright, well i think i can submit sth soon then [18:36:11 CET] <ubitux> i'm just a bit annoyed by the zvbi stuff [18:36:27 CET] <wm4> what does zvbi do? [18:36:32 CET] <Daemon404> nothing of value [18:36:35 CET] <wm4> well, teletext [18:36:53 CET] <wm4> (why does it still exist) [18:37:22 CET] <Daemon404> purely to make kierank's life more fun [18:42:50 CET] <kierank> People use teletext [18:43:01 CET] <kierank> In Nordic countries it is more popular than the web [18:43:32 CET] <JEEB> well, used to be [18:43:42 CET] <JEEB> heck, you could even get ASCII art boobs from there [18:43:54 CET] <JEEB> (all those adult phone nr ads) [18:45:23 CET] <Daemon404> JEEB, i thought nordic countries were supposed to be livign in the future [18:45:25 CET] <Daemon404> not the past [18:45:38 CET] <JEEB> well as I said, used to be [18:45:44 CET] <JEEB> until internets became prevalent [18:45:57 CET] <JEEB> I think I last used them in the very early 2000s [18:46:18 CET] <JEEB> because I still had a 56,600bps modem and thus going online cost every second [18:46:36 CET] <atomnuker> teletext can be considered retr-ofuturistic [18:46:56 CET] <Daemon404> like bbs and green-on-black vecotr maps? [18:47:00 CET] <Daemon404> vector* [18:47:45 CET] <atomnuker> yeah, like those and MIDI music [18:47:59 CET] <JEEB> kierank: in finland at least the official thing was DVB subs, as there was no requirement for them to be text-to-speech'able. of course, in 2001 the capabilities of DVB subtitle renderers were... not exactly perfect [18:48:07 CET] <JEEB> so in the end a lot of the channels just hardcoded the subs [18:48:12 CET] <JEEB> except the public broadcaster [18:48:19 CET] <JEEB> which stayed with its DVB subtitles [18:50:03 CET] <BtbN> Text-To-Speechable Subtitles? [18:50:13 CET] <BtbN> Aren't they Speech-To-Text anyway? [18:50:45 CET] <JEEB> well the US requires the captions to be in text [18:51:03 CET] <JEEB> for text-to-speech reasons [18:51:38 CET] <Daemon404> [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec. [18:51:41 CET] <Daemon404> drama taimu [18:53:00 CET] <JEEB> cool [18:53:20 CET] <jamrial> Alexandra had already ported the needed bits to get bitexact xll decoding working [18:54:50 CET] <JEEB> yeah, now it's time to discuss which way is the one people want to go with. [18:55:11 CET] <j-b> Can we stop this madness? [18:55:17 CET] <Daemon404> $5 says ffmpeg ends up with 2 decodrs again [18:55:21 CET] <atomnuker> 7000 lines for an audio decoder [18:55:29 CET] <JEEB> Daemon404: hopefully not :P [18:55:36 CET] <JEEB> we only need one working one :D [18:56:05 CET] <Daemon404> j-b, might not be too bad [18:56:12 CET] <Daemon404> foo86 is an exceedingly reaosnable person. [18:56:23 CET] <JEEB> yeah, that's the image I've gotten of him [18:56:30 CET] <nevcairiel> libdcadec is far more feature complete with a knowledgeable maintainer, so if thats any consideration [18:56:53 CET] <jamrial> yeah, i'd replace the current dca decoder for this port foo86 wrote of libdcadec [18:56:56 CET] <atomnuker> then why did it take them so long to make a stable release [18:57:11 CET] <JEEB> atomnuker: x264 never made any stable releases vOv [18:57:15 CET] <jamrial> he was awol for months for some reason [18:57:17 CET] <Daemon404> jamrial, ditto, but it's not going to be Politically COrrect [18:57:42 CET] <nevcairiel> screw that [18:57:46 CET] Action: BBB winks @ j-b [18:57:50 CET] <BBB> j-b: can you fix us please? [18:58:15 CET] <Daemon404> BBB, i dont knwo if j-b owns a shotgun [18:58:17 CET] <j-b> Full rewrites are never a good idea, IMHO [18:58:26 CET] <Daemon404> j-b, have you seen avidec? ;) [18:58:27 CET] Action: Daemon404 runs [18:58:37 CET] <BBB> Daemon404: I hear shotguns are easy to buy in the US [18:58:45 CET] <j-b> and then people ask why we have our own demuxers. [18:58:47 CET] <jamrial> "Performance wise, this decoder used to be around 10% slower than pure floating point version of existing native DCA decoder." [18:58:49 CET] <jamrial> "However, after native DCA decoder has been partially converted to fixed point, this decoder became 5% faster than native one" [18:59:03 CET] <jamrial> well, that's a point in foo86's favor [18:59:18 CET] <nevcairiel> thats mostly because there used to be float simd which was deleted [18:59:18 CET] <nevcairiel> :D [18:59:47 CET] Action: BBB begs j-b to fix us [18:59:58 CET] <nevcairiel> the recent dca patches are practically copying parts of libdcadec [19:00:11 CET] <nevcairiel> so instead of doing that, why not just use the entire thing which is feature complete [19:00:23 CET] <jamrial> ^ [19:00:36 CET] <wm4> <Daemon404> $5 says ffmpeg ends up with 2 decodrs again <- 3 [19:00:48 CET] <Daemon404> i thiught the otehr guy vanished [19:00:52 CET] <Daemon404> loltypos. [19:01:07 CET] <nevcairiel> there is no reason to keep the old one if this one goes in, it has zero arguments for keeping it [19:01:09 CET] <wm4> the libdcadec wrapper will remain, even if foo86's patches are included [19:01:34 CET] <nevcairiel> that depends if he plans to continue it or abandons it if it goes in [19:01:55 CET] <Daemon404> wm4, why [19:02:02 CET] <nevcairiel> but the wrapper is tiny in comparison to a real decoder [19:02:05 CET] <wm4> Daemon404: because madness [19:02:10 CET] <Daemon404> nevcairiel, abadoning it makes no difference [19:02:11 CET] <jamrial> we still have wrappers for libnut and other seemingly dead libraries, though [19:02:12 CET] <Daemon404> libutvideo [19:02:17 CET] <Daemon404> doesnt even BUILD on linux anymore [19:02:20 CET] <Daemon404> you have to use a random fork [19:02:22 CET] <Daemon404> to use it with ffmpeg [19:02:23 CET] <BBB> libnut [19:02:26 CET] <Daemon404> and yet it remains [19:02:26 CET] <BBB> muhahahahahhahahhahaha [19:02:29 CET] <BBB> omg [19:02:30 CET] <BBB> nut [19:02:38 CET] <Daemon404> BBB, nut is not bad for specific usecases [19:02:44 CET] <Daemon404> specifically, piping rawvideo with real timestamps. [19:02:53 CET] <wm4> but the libnut wrapper has no reason to exist anyway [19:02:58 CET] <Daemon404> of course [19:03:05 CET] <wm4> you can't even make up reasons [19:03:08 CET] <wm4> yet it will remain [19:03:19 CET] <wm4> (I want out if here) [19:03:33 CET] <Daemon404> i could probably remove libutvideo*.cpp if i was so inclined tbh [19:03:39 CET] <Daemon404> if i added 10bit support to the native decoder [19:03:42 CET] <Daemon404> but i just dont care. [19:04:24 CET] <j-b> performance point is debatable, if you discuss SIMD'd versions vs non-SIMD'd ones [19:04:37 CET] <nevcairiel> both are non-simd now [19:05:02 CET] <atomnuker> I keep telling people to stop whining about <X> being useless anymore, submit a damned patch and complain if it's not accepted damnit [19:05:24 CET] <Daemon404> atomnuker, eh ive submitted 2-3 patches to remove libutvideo [19:05:26 CET] <j-b> "uses assembly optimized version of synth_filter" [19:05:28 CET] <Daemon404> rejected every time [19:05:36 CET] <wm4> my patches to remove stuff just cause drama [19:05:38 CET] <wm4> nothing else [19:05:44 CET] <j-b> resubmitting rejected patches is rude. [19:05:56 CET] <atomnuker> no it's not, it's necessary [19:06:08 CET] <nevcairiel> j-b: lets just say they use the same amount of simd [19:06:16 CET] <Daemon404> 'rejected' by carl, because "it's a feature" [19:06:20 CET] <wm4> and "why u remove it doesn't harm" type of replies [19:06:42 CET] <atomnuker> I haven't seen a single patch to remove a feature in the last 5 months [19:06:52 CET] <Daemon404> atomnuker, because we all gave uo [19:06:53 CET] <Daemon404> long ago [19:06:59 CET] <atomnuker> times change [19:07:05 CET] <Daemon404> carl doesnt change [19:07:08 CET] <wm4> the vdpau decoder is still in [19:07:17 CET] <atomnuker> he learns to understand however [19:07:18 CET] <j-b> +1 [19:07:21 CET] <Daemon404> atomnuker, ok you have inspired me [19:07:22 CET] <j-b> vdpau... [19:07:29 CET] <Daemon404> i will send a patch to remove libstagefright [19:07:31 CET] <Daemon404> wish me luck [19:07:33 CET] <j-b> lol [19:07:39 CET] <j-b> stagefright is useful [19:07:44 CET] <wm4> (and for the log, I mean the deprecated legacy vdpau wrapper, not the proper hwaccel) [19:07:49 CET] <atomnuker> Daemon404: not stagefright, doon't fuck with android/embedded people [19:07:59 CET] <Daemon404> j-b, inside ffmpeg? where you cnat even build it without special incantations the only one man knows? and specific versions? [19:08:10 CET] <j-b> Daemon404: it's a JOKE, man [19:08:24 CET] <j-b> Daemon404: I've asked for xvmc, vdpau, and stagefright to go away [19:08:24 CET] <Daemon404> j-b, poe's law is strong in this community [19:08:25 CET] <Daemon404> ffs [19:08:27 CET] <wm4> atomnuker: well we should have mediacodec support instead, but unfortunately that got killed with drama/bikeshed by myself [19:08:34 CET] <wm4> (java etc.) [19:08:37 CET] <j-b> and everyone, mostly Carl and ubitux jump on my throat [19:08:52 CET] <ubitux> ? [19:08:55 CET] <j-b> mediacodec has a JNI API [19:09:07 CET] <atomnuker> wm4: doesn't mediacodec actually depend on libavcodec? [19:09:17 CET] <Daemon404> atomnuker, stagefright also does [19:09:20 CET] <nevcairiel> mediacodec is just an API [19:09:25 CET] <j-b> atomnuker: why would it depend on libavcodec? [19:09:27 CET] <wm4> I suppose many multimedia frameworks do [19:09:30 CET] <nevcairiel> what comes behind that is of no consequence for us [19:09:35 CET] <wm4> (in form of plugins) [19:09:44 CET] <j-b> most mediacodec versions don't use libavcodec [19:09:59 CET] <ubitux> j-b: i never said xvmc,vdpau and stagefright should stay; the only thing i probably said was that it needs to be discussed [19:10:24 CET] <iive> do you mean the whole vdpau? [19:10:31 CET] <ubitux> probably the old implementation [19:10:58 CET] <atomnuker> what's wrong with VDPAU anyway, it's just another hardware decoder anyway [19:11:39 CET] <iive> I don't mind triggering the FF_API_XVMC, have in mind this won't remove xvmc, it would just remove some backward compatibility. [19:12:01 CET] <iive> i might even send patches for that. [19:12:25 CET] <Daemon404> btw you guys forgot teh best thing thaty wasnt removed [19:12:26 CET] <Daemon404> sonic. [19:12:32 CET] <Daemon404> the lossless audio codec which makes files bigger. [19:13:34 CET] <j-b> Daemon404: you can't do that! Because that' would mean that libav was right. [19:14:01 CET] <wm4> Daemon404: encoder? [19:14:08 CET] <Daemon404> indeed [19:14:14 CET] <Daemon404> ... holy what... [19:14:15 CET] <Daemon404> tools/build_libstagefright [19:14:20 CET] <Daemon404> the fact this exists is just sad [19:15:14 CET] <wm4> Daemon404: the fact that nobody ever updated it is also telling [19:15:18 CET] <JEEB> lol [19:15:29 CET] <atomnuker> just let the embedded people live in their own little isolated unhappy depressing world [19:16:10 CET] <kierank> or perhaps let them fix it [19:16:18 CET] <kierank> instead of just leaving crap in our codebase [19:16:36 CET] <j-b> there is a lot of crap already [19:16:38 CET] <Daemon404> ... the file started as build.sh in / [19:16:39 CET] <Daemon404> wtf? [19:16:47 CET] <Daemon404> how was that ever accepted [19:17:08 CET] <j-b> because feature-competition-with-libav [19:17:23 CET] <j-b> but, once again, I'm going to be attacked by ubitux, on this. [19:17:42 CET] <ubitux> you're such a martyr [19:17:50 CET] <j-b> not really [19:18:25 CET] <ubitux> i never opposed to the drop of stagefright [19:18:27 CET] <j-b> but you attacked me quite strongly, not long ago, on just this part. [19:19:09 CET] <j-b> and explained again how useful it must be, if people still sent patches. [19:19:09 CET] Action: wm4 orders 10 kilotons of popcorn [19:19:30 CET] <ubitux> again, i never said stagefright must be kept [19:19:40 CET] <ubitux> nor did i for xvmc, vdpau etc [19:21:00 CET] <wm4> j-b: I disagree with you though, ubitux was never someone who actually blocked cleanups, but rather someone who stressed the need for discussion [19:21:38 CET] <j-b> wm4: sorry, that's not what my emails/IRC logs say. [19:23:15 CET] <ubitux> maybe read them again then [19:23:25 CET] <j-b> In fact, I just did. [19:23:49 CET] <ubitux> and so i said stagefright must be kept? [19:25:26 CET] <Daemon404> [master 030c77b] avcodec: Remove libstagefright 7 files changed, 1 insertion(+), 659 deletions(-) [19:25:32 CET] <Daemon404> RFC coming [19:26:02 CET] <jamrial> don't send a patch with ~700 lines being removed. crop it please :p [19:26:06 CET] <iive> may i ask something. [19:26:13 CET] <Daemon404> j-b, there is -M or whatever [19:26:15 CET] <iive> do you have good reason to remove the code? [19:26:16 CET] <Daemon404> er, jamrial [19:26:25 CET] <Daemon404> iive, yes i have included my reasonin [19:26:30 CET] <Daemon404> it is an RFC [19:26:34 CET] <j-b> Daemon404: 5.0, 5.1 and 6.0, yes. [19:26:34 CET] <Daemon404> thats the point. to discuss. [19:26:37 CET] <jamrial> I thought -M detects renames, not removals [19:27:37 CET] <Daemon404> jamrial, yes reading man git right now [19:28:03 CET] <atomnuker> Daemon404: don't send it as RFC, but please list reasons for those of us unaware [19:28:26 CET] <Gramner> JEEB: oh but x264 does releases - one for each commit ;) [19:28:29 CET] <atomnuker> just a normal PATCH to avoid discussions to discuss stuff [19:28:36 CET] <JEEB> Gramner: lol [19:29:06 CET] <iive> Daemon404: i don't see the mail yet. could you summarize ? [19:29:58 CET] <Daemon404> jamrial, -D [19:30:03 CET] <Daemon404> iive, i am sending now [19:30:07 CET] <jamrial> cool [19:30:27 CET] <Daemon404> i am also CCing it's 'maintainer' [19:30:42 CET] <atomnuker> Daemon404: make sure to include reasons and drop the RFC [19:30:46 CET] <Daemon404> yes. [19:31:01 CET] <nevcairiel> -D is not actually applyable though, but not that this matters [19:32:56 CET] <iive> well, I just hope that the reasons are better than "it's ugly, I don't like it, it is maintenance burden(tm), nobody uses it" [19:34:28 CET] <atomnuker> don't forget the whole stagefright font security fisco too [19:35:28 CET] <iive> tbh, i have no idea what stagefright is. And I don't think i've heard of the font security fiasco either. [19:36:13 CET] <nevcairiel> maybe you should refrain from commenting then :D [19:37:49 CET] <Daemon404> sent. [19:44:36 CET] <Daemon404> urg, if mails are sent to both mailing lists by someone, gmail deduplicates it [19:44:43 CET] <Daemon404> and the filters just put it in a random folder [19:44:51 CET] <Daemon404> depending on the order of the emails in To: [19:45:51 CET] <iive> the first paragraph sound quite convincing to me. [19:46:52 CET] <Daemon404> aside from my usual typos [19:47:51 CET] <philipl> Daemon404: so what's our recommended way to use mediacodec? [19:48:49 CET] <Daemon404> via its JNI api, i'd assume [19:49:16 CET] <ubitux> you have a c api but for 5+ only, so covering a small subset [19:49:31 CET] <philipl> Sorry, I mean - we're saying that you shouldn't try and use mediacodec through libavcodec. [19:49:43 CET] <Daemon404> philipl, you use avcodec through mediacodec [19:49:52 CET] <philipl> Ok. [19:50:10 CET] <philipl> As opposed to an hwaccel on top of mediacodec existing, which someone could, theoretically, write. [19:50:27 CET] <Daemon404> j-b probably has opinions on that [19:50:32 CET] <Daemon404> i dont [19:50:36 CET] <ubitux> mediacodec buffering is a bit annoying though, mateo might want to talk about it (iirc he's working on it) [19:50:49 CET] <philipl> Anyway. I'm fine with removing stagefright regardless of the answer to that question. [19:50:55 CET] <wbs> Daemon404: "use avcodec through mediacodec", no, that's completely unrelated [19:51:07 CET] <Daemon404> is it? [19:51:11 CET] <wbs> yes [19:51:15 CET] <Daemon404> in pratcical effect how does it differ [19:51:17 CET] <Daemon404> ok [19:51:24 CET] <wbs> and your list of reasons is partially kinda confused [19:51:35 CET] <Daemon404> tbh i was hoping you would show up [19:51:37 CET] <wbs> (but I wholeheartedly agree that it should be remoed and purged with fire) [19:52:03 CET] <Daemon404> im a resident troll/annoying guy, youre the android knowledge here [19:52:27 CET] <Daemon404> im fine with being a bullet sponge. [19:52:28 CET] <wbs> first, definitions of some names: "stagefright" is the name of the android media framework; MediaCodec is the only supported public API to this framework [19:52:44 CET] <wbs> the current "libstagefright" decoder uses the C++ OMXCodec class interface to stagefright [19:53:16 CET] <wbs> atomnuker also said "due to the recent stagefright vulnerabilities, this should be removed" - this is a completely unrelated argument; there were vulns in stagefright's mp4 demuxer iirc [19:53:37 CET] <wbs> but whether those exist or not is kinda unrelated to whether avcodec should use android hwaccels for decoding [19:53:44 CET] <atomnuker> doesn't matter, still discredits stagefright [19:53:51 CET] <Daemon404> everybody has sec vulns [19:54:05 CET] <atomnuker> those were major because +billion devices [19:54:07 CET] <Daemon404> i know youre not exactly an ffmpeg guy, but a reply from a knowledgable person could certain clarify stuff [19:54:13 CET] <Daemon404> @ wbs [19:54:15 CET] <wbs> yes, but if you want to have hw accel decoding on android, you _have_ to go through stagefright [19:54:34 CET] <wbs> Daemon404: sure, I'll just rehash it here first :P [19:54:39 CET] <nevcairiel> but its better to do that indirectly through another favored API, isnt it [19:54:44 CET] <Daemon404> wbs, lol ok [19:54:46 CET] <j-b> or through Mediacodec [19:54:48 CET] <wbs> nevcairiel: yep [19:54:54 CET] <philipl> The main reason to drop it is that it's not the supported public API and if someone wanted to do an hwaccel implementation on top of mediacodec they could, and our stagefright code is so limited that removing it shouldn't depend on mediacodec support existing. [19:54:54 CET] <Daemon404> j-b probably knows a bunch too [19:54:59 CET] <wm4> the situation on android seems to be complicated... [19:55:03 CET] <wbs> it still goes through "stagefright" as general framework though [19:55:06 CET] <wbs> philipl: exactly [19:55:13 CET] <Daemon404> philipl, i should have listed that, yes [19:55:35 CET] <wbs> Daemon404: also you said "Both stagefright and mediacodec have avcodec backends and this is the correct way to use it" - no [19:55:50 CET] <Daemon404> that became clear a few paragraphs up [19:56:09 CET] <wbs> some vendors, like some third party firmwares, have avcodec as stagefright backend [19:56:26 CET] <wbs> so you can decode whatever codec in the stock system player that uses stagefright/mediacodec [19:56:26 CET] <j-b> well, omx backends :) [19:56:29 CET] <Daemon404> maybe i should use this as an example of misinformation / cargo culting / whatever spreading [19:56:32 CET] Action: Daemon404 hides [19:56:57 CET] <j-b> stagefright uses mediacodec, that uses OMX, which can have a libavcodec backend. [19:57:10 CET] <wbs> so think of stagefright/mediacodec as gstreamer, it can have any plugin, the real decoder plugin backend could be avcodec, or could be the real hw [19:57:37 CET] <Daemon404> apps cnat ship their own plugins, unlike gst [19:57:39 CET] <Daemon404> afaict [19:57:49 CET] <wbs> correct [19:57:59 CET] <j-b> which is great, because we can have avcodec using stagefright, using mediacodec and OMX, which can use avcodec [19:58:06 CET] <wbs> and using stagefright/mediacodec is the only way of accessing hw decoders [19:58:54 CET] <Daemon404> gotcha; get it now [19:59:03 CET] <j-b> only "standard" way :) [19:59:06 CET] <wm4> so I'm confused, is using libstagefright actually a proper approach? [19:59:15 CET] <Daemon404> wm4, it's not public api [19:59:23 CET] <Daemon404> mediacodec is [19:59:24 CET] <wbs> now the only limitation is that to access hw codecs, it has to go through the mediaserver process, which requires you to use some part of the stagefright apis - either two of the old private, abi unstable APIs (IOMX or OMXCodec) [19:59:38 CET] <wbs> wm4: no, it uses private APIs [19:59:56 CET] <wm4> wait, so you have to use stagefright _and_ omx? [20:00:01 CET] <wbs> the current code reequires you to build a separate libavcodec.so for each major android versions you want to target, if you'd use the libstagefright code [20:00:13 CET] <wbs> wm4: no [20:00:24 CET] <wbs> wm4: you'd have to use "stagefright as in the framework, in some form" [20:00:52 CET] <wbs> wm4: the _real_ limit is that the only process that is allowed to talk to the hw codecs (say /dev/qdsp* on qualcomm) is the mediaserver process [20:01:11 CET] <wbs> wm4: now you need to talk to the mediaserver to ask it to do the decoding for you, via one form of IPC API or another [20:01:35 CET] <wbs> wm4: before there were any public API, I (and others) figured out which internal APIs one could use, which were kinda-stable-ish enough to use [20:01:48 CET] <wbs> these still were ABI unstable, so you'd have to build a separate .so for each targeted android version [20:02:09 CET] <wbs> so at runtime, check which android version you're running on, load the right .so, and hope things go well [20:02:37 CET] <wbs> (we implemented this pretty neatly, with only a very small, a few KB .so that is target dependent, within VLC, but in a generic thing like avcodec, it's be hell) [20:03:09 CET] <wbs> now currently there's (at least) three APIs in use, IOMX, OMXCodec and MediaCodec [20:03:09 CET] <wm4> ok [20:03:38 CET] <wm4> what's the difference between the two OMX things? I thought OMX is a standardized thing by khronos [20:03:47 CET] <wbs> all three technically are "stagefright", they all access the stagefright framework, and all talk to the mediaserver process to let you do hw decoding [20:03:56 CET] <j-b> wm4: the difference is how you speak to the mediaserver [20:03:59 CET] <rcombs> wbs: yeah, what blocks direct use of OMX? [20:04:13 CET] <wbs> IOMX is a C++ IPC version of plain OMX, pretty straightforward [20:04:24 CET] <j-b> rcombs: only one process has access to it, the mediaserver [20:04:38 CET] <wm4> wbs: sounds disgusting [20:04:41 CET] <rcombs> joy [20:04:48 CET] <j-b> lol [20:04:58 CET] <j-b> disgusting? like this was the worse thing of Android. [20:05:01 CET] <BtbN> Also nice if there is some flaw in that process. You get free root access, aparently. [20:05:06 CET] <wbs> on top of IOMX you either have OMXCodec, which is their own legacy API, which also is C++ [20:05:19 CET] <wbs> OMXCodec is pretty highlevel, or really highlevel [20:05:20 CET] <rcombs> wbs: j-b: last I heard, the media server couldn't be accessed from a plain C/++ program because it requires some Java "Binder" IPC to be running in the calling process [20:05:34 CET] <wbs> this is what the "libstagefright" code uses [20:05:37 CET] <wm4> and for mediacodec, isn't there both a java and c++ API? [20:05:39 CET] <rcombs> have you seen the NDK C API for all this? [20:05:44 CET] <wbs> the "new" stuff internally in stagefright uses a class called ACodec [20:05:54 CET] <rcombs> (it's a thin public wrapper around the MediaCodec C++) [20:06:08 CET] <wbs> ACodec isn't public API either [20:06:23 CET] <wbs> but MediaCodec is on top of ACodec, and that's public API [20:06:26 CET] <rcombs> something about needing to be spawned from zygote [20:06:30 CET] <j-b> wm4: yes, there are. [20:06:43 CET] <wbs> rcombs: yes, I've seen it [20:07:03 CET] <wbs> it probably doesn't work in a purely plain native app (like commandline stuff) [20:07:24 CET] <rcombs> `NdkMediaCodec.h` [20:07:30 CET] <rcombs> wbs: yeah, apparently requires spawning from zygote [20:07:32 CET] <wbs> rcombs: iirc there's a oneline call you can do within your code to make it start up the necessary stuff [20:07:33 CET] <rcombs> which is some bullshit [20:07:39 CET] <rcombs> oh? [20:07:53 CET] <wm4> rcombs: what does that even mean [20:07:53 CET] <rcombs> also, there doesn't seem to be a way to get it to return opaque buffers [20:07:57 CET] <rcombs> so have fun doing memcpy [20:08:15 CET] <rcombs> wm4: Android apps are spawned by fork()ing from a single parent process and then _not_ doing execve() [20:08:27 CET] <rcombs> that parent being "zygote" [20:08:54 CET] <j-b> rcombs: well, yes, you can get an opaque buffer, and then display it. [20:08:54 CET] <wbs> rcombs: in practice this is a non-issue though, all real apps will be launched that way anyway, it's only an issue if you want to do debugging on plain commandline binaries [20:08:54 CET] <wm4> and exec "destroys" it? [20:09:08 CET] <wbs> rcombs: hmm, I don't remember if the NDK interface to mediacodec is complete or not in this regard [20:09:24 CET] <wbs> rcombs: android::ProcessState::self()->startThreadPool(); [20:09:50 CET] <wbs> rcombs: that was enough for me to have working binder/IPC [20:09:55 CET] <rcombs> j-b: is it possible to get an opaque buffer from the decoder, then _encode_ it? [20:10:05 CET] <rcombs> wbs: hmm, interesting [20:10:14 CET] <j-b> rcombs: yes. [20:10:25 CET] <rcombs> j-b: which API? OMXCodec directly? [20:10:40 CET] <prelude2004c2> hey guys. having trouble with vdpau... someone told me to decode using " vc ffh264vdpau " . not sure where to put that.. i am using ffmpeg [20:10:43 CET] <prelude2004c2> mpeg2video sources seem to decode ok and then i can transcode it to something else.. but h264 sources don't seem to decode at all [20:10:45 CET] <prelude2004c2> i am using M4000 card [20:10:52 CET] <prelude2004c2> running latest 258.16 version [20:10:54 CET] <wbs> rcombs: no, forget OMXCodec [20:10:57 CET] <j-b> rcombs: MC. [20:11:08 CET] <j-b> rcombs: I mean, everything now can have MC [20:11:13 CET] <wbs> OMXCodec is a dead end, their own old internal API which they haven't used since 2010 or so [20:11:26 CET] <rcombs> isn't MediaCodec on top of OMXCodec? [20:11:31 CET] <wm4> how are android drivers implemented? [20:11:35 CET] <wm4> I thought they used OMX [20:11:46 CET] <j-b> in 6.0, supposedly, MediaCodec can be totally decorelated from OMX [20:11:49 CET] <wbs> no [20:11:59 CET] <j-b> but I've not seen that yet. [20:12:04 CET] <wbs> everything is on top of IOMX [20:12:18 CET] <wbs> wm4: yes [20:12:33 CET] <wbs> you have IOMX <- OMXCodec - this chain is EOL and only for old codepaths [20:12:53 CET] <wbs> then separately there's IOMX <- ACodec <- MediaCodec [20:12:53 CET] <wbs> MediaCodec is public [20:13:08 CET] <wbs> but much of the stagefright framework's high level player classes use ACodec directly [20:13:14 CET] <Daemon404> this sounds liek such epic pain compared to avfoundation on ios [20:13:23 CET] <wbs> wm4: yes, the drivers are OMX [20:13:26 CET] <rcombs> public, but with the headers in AOSP instead of NDK, yeah? [20:13:37 CET] <wbs> wm4: but the "OMXCodec" API is a wart one shouldn't be touching [20:13:40 CET] <j-b> wbs: didn't they say that starting from 6.0 they allowed drivers that were not OMX based? [20:13:44 CET] <rcombs> (which is mildly inconvenient but not a huge deal) [20:13:48 CET] <j-b> especially for TV? [20:13:50 CET] <wm4> ok, so conclusion: OMX is interesting only for android driver devs [20:14:01 CET] <wbs> Daemon404: not really [20:14:07 CET] <wbs> Daemon404: the thing is, with android, one can poke into these things already before the public API existed [20:14:16 CET] <wbs> Daemon404: which people impatiently did, like me [20:14:26 CET] <Daemon404> wbs, well also the fact that for ios you only usually worry about a few versions at most [20:14:28 CET] <wm4> so what does VLC use these days? [20:14:29 CET] <Daemon404> not 900 [20:14:35 CET] <wbs> Daemon404: publicly, there only exists one thing, MediaCodec, with Java and C interfaces [20:14:53 CET] <wbs> Daemon404: sure, that helps [20:15:01 CET] <j-b> wm4: we use Mediacodec-C, MediaCodec-Java and IOMX, depending on the version. [20:15:51 CET] <wbs> wm4: yes, the OMX layer should only be touched if you're implementing a driver, more or less. and as j-b says, one might not need to do it then either [20:16:06 CET] <wbs> rcombs: no, MediaCodec's headers exist in the public NDK [20:16:29 CET] <wm4> IOMX only for older versions? [20:16:35 CET] <wbs> rcombs: the subset you're supposed to use that is, the public C frontend functions. the internal C++ implementation of the MediaCodec class is only in AOSP of course, and that's also private/ABI unstable [20:16:35 CET] <rcombs> wbs: where? [20:16:39 CET] <wm4> and meciacodec-c for the newest? [20:16:43 CET] <j-b> wm4: yes [20:16:47 CET] <rcombs> ah, NdkMediaCodec.h [20:16:56 CET] <wbs> yes [20:17:03 CET] <rcombs> wbs: so is it possible to get that to throw around opaque buffers instead of lots-o'-memcpy? [20:17:11 CET] <j-b> Seriously, the solution is Mediacodec-C and if you want, do a wrapper to mimick it, for older versions. [20:17:16 CET] <wbs> wm4: yes [20:17:22 CET] <j-b> rcombs: yes, that's what we do in VLC. [20:17:28 CET] <rcombs> how? [20:17:48 CET] <wm4> <j-b> Seriously, the solution is Mediacodec-C and if you want, do a wrapper to mimick it, for older versions. <- so why has nobody copied google's mediacodec-c and ported it back to older androids for application use? [20:17:52 CET] <rcombs> or, just point me at the relevant source? [20:17:58 CET] <j-b> wm4: don't ask me. [20:18:14 CET] <Daemon404> wm4, because j-b doesnt need mroe libraries to personally maintain ;) [20:18:23 CET] <wm4> ok, so hopefully there's no deeper reason why this would be impossible [20:18:24 CET] <j-b> wm4: not that I haven't seen proprietary code that does it... [20:18:54 CET] <j-b> wm4: the reason is mostly because of the management of JNIEnv* and JavaVM* pointers [20:19:06 CET] <wm4> rcombs: the VLC source tree is easy to navigate, just keep in mind most is under modules/ [20:19:24 CET] <wm4> j-b: urgh, forgot about this [20:19:29 CET] <wbs> wm4: the mediacodec C API is a plain C frontend on top of the internal native MediaCodec class [20:19:38 CET] <j-b> rcombs: in some cases, with specific hardware, we can even use tuneled-playback [20:19:40 CET] <rcombs> https://github.com/videolan/vlc/blob/master/modules/codec/omxil/mediacodec_… looks like this [20:19:44 CET] <j-b> been there, done that. [20:20:04 CET] <wbs> wm4: but if you want compat with the older versions where mediacodec was only in java, you need a few extra API hooks for the java env stuff [20:20:16 CET] <rcombs> j-b: is this actually documented anywhere? (or should I just use the VLC code as reference) [20:20:29 CET] <j-b> rcombs: depends, why do you need that? :D [20:20:33 CET] <j-b> rcombs: just use libvlc :) [20:20:49 CET] <rcombs> j-b: I'd like to do full-hardware transcoding on Android in ffmpeg [20:20:59 CET] <wm4> libavcodec/libvlc.c [20:21:12 CET] <j-b> rcombs: clean ffmpeg first :) [20:21:21 CET] <rcombs> lolrecursion [20:21:50 CET] <j-b> rcombs: it is doable, jokes asides, but it's a bit hard. [20:21:54 CET] <wbs> rcombs: doing zerocopy-transcoding with mediacodec is possible but a bit hard-ish; in general, first look at the java API of MediaCodec [20:22:04 CET] <j-b> rcombs: we're going to work on this on VLC soon. [20:22:09 CET] <wbs> rcombs: the java version is more complete and has got way more docs and explanations [20:22:17 CET] <j-b> rcombs: IIRC, there were some part useful, that were missing in the C code. [20:22:23 CET] <rcombs> wbs: and everything there does map to the C version? [20:22:36 CET] <rcombs> wbs: I looked at this a while ago and didn't see a clear way to do it [20:22:58 CET] <wbs> rcombs: well as long as there is a C version [20:22:59 CET] <rcombs> but it could just be because it's in e.g. `setInt32` flags that I couldn't find docs for [20:23:08 CET] <wbs> rcombs: in general, just think of the C version as a convenience [20:24:06 CET] <wbs> rcombs: but basically, you need to request a Surface from the encoder, then pass this surface to the decoder as output during configure [20:24:23 CET] <wbs> rcombs: I don't remember exactly if this setup is possible or not but I'd think it [20:24:38 CET] <wbs> rcombs: the more complete version is to set up a GL ES rendering context on the encoder input surface [20:25:14 CET] <wbs> rcombs: then "render" the decoded output surfaces into GL textures within this same context, and "blit" them to the encoder surface context in order to feed them to be encoded [20:25:32 CET] <wm4> wtf [20:26:26 CET] <wbs> well the thing is, in general, buffers are tied to a specific codec, so you can't take a decoder output buffer and pass it to the encoder [20:26:36 CET] <wbs> the encoder can only take input in buffers owned by the encoder [20:27:06 CET] <wbs> and the decoder can only output into the decoder's own output buffers, or onto an opaque surface that is configured during the decoder setup [20:27:41 CET] <wbs> the opaque output surface can be a GL texture, and the encoder input surface can be a GL rendering context [20:28:08 CET] <wbs> so the "copying" from decoder to encoder shouldn't really hit the CPU [20:29:41 CET] <wbs> now all of this is possible to do. but the examples are java, and some of the surface management for decoding into gl textures and all that might be java-only [20:29:45 CET] <j-b> wbs: that's what tguillem tried, IIRC [20:29:57 CET] <wbs> so the correct way of learning it is to first figure out how it actually works in the platform's own real apis, i.e. java [20:30:08 CET] <j-b> wbs: and I'll need him to look at this more, because of ChromeCast :) [20:30:17 CET] <wbs> then once you understand it, you can try to reduce it back down to C [20:30:50 CET] <wbs> j-b: yep :-) [20:31:11 CET] <wbs> j-b: I haven't touched this much at all myself, only tried decode->glrender->encode once, to do transcoding with GL effects inbetween :P [20:31:24 CET] <j-b> wbs: GL effects? neat. [20:31:55 CET] <rcombs> scaling and deinterlacing would be useful to do there [20:32:15 CET] <rcombs> maybe overlay (e.g. subtitle) rendering [20:32:46 CET] <wbs> yep [20:33:47 CET] Action: rcombs shudders at the thought of fitting OpenGL into libavfilter [20:34:01 CET] <wbs> j-b: http://martin.st/temp/gl-video.mp4 (one effect at 10 to 20 secs, another from 20 to 30 secs in the file) [20:34:12 CET] <rcombs> (though it's something I've thought of before, but the context sharing, amongst other things, is ~complicated~) [20:34:48 CET] <wbs> rcombs: http://bigflake.com/mediacodec/ - in case you want to learn it in general [20:36:46 CET] <rcombs> wbs: much appreciated [20:36:47 CET] <j-b> wbs: neat. You're a genius. [20:38:01 CET] <wbs> rcombs: ah sorry btw, the android::ProcessState::self()->startThreadPool(); line I posted is private internal API btw (back from when I meddled with the private APIs for this); dunno if there is any public API for it. for real app code it doesn't matter of course, only if you'd want to do this in a commandline './ffmpeg' binary on android [20:38:30 CET] <rcombs> wbs: I do, but in this case using private APIs might not be out of the question [20:38:39 CET] <cehoyos> Hi! Is the libdcadec author around? [20:38:53 CET] <Daemon404> i dont think he is on irc [20:39:08 CET] <rcombs> cehoyos: that guy's hard enough to get ahold of _off_ IRC [20:39:18 CET] <cehoyos> Does anybody know how the decoder was written? [20:39:22 CET] <cehoyos> Is there a specification? [20:39:40 CET] <cehoyos> Or in other words: Why does it not have any copyright at all? [20:40:27 CET] <wbs> Daemon404: actually, the only thing I want commented on your post is that the "... have avcodec backends already and is the correct way to use it", just remove this from the commit message and the rest should be kinda fine-ish [20:40:34 CET] <rcombs> you mean copyright headers? [20:40:43 CET] <cehoyos> I mean copyright notices [20:40:50 CET] <Daemon404> wbs, eh ok [20:40:59 CET] <cehoyos> I don't think the files can be committed without... [20:41:02 CET] <rcombs> probably neglected to do so [20:41:07 CET] <j-b> cehoyos: why not? [20:41:33 CET] <Daemon404> as opposed to all the other fake/missing copyright we have? [20:41:38 CET] <wm4> rcombs: context sharing for just one platform (android) might not be so hard [20:41:41 CET] <cehoyos> Who gives you the right to use, modify etc. the file? [20:41:44 CET] <rcombs> wm4: yeah [20:41:53 CET] <j-b> cehoyos: the author. [20:41:56 CET] <cehoyos> But again: How was it written? [20:42:01 CET] <j-b> not the copyright notice. [20:42:11 CET] <cehoyos> But who is the author that gives you the right? [20:42:29 CET] <j-b> Usually, the one who is on the author line [20:42:37 CET] <Daemon404> cehoyos, by that logic we should remove all code from wm4, and "elvis", etc. ;) [20:42:45 CET] <Daemon404> just sayin'. [20:42:45 CET] <j-b> Daemon404: no. [20:42:46 CET] <wm4> D: [20:42:48 CET] <cehoyos> That is definitely wrong°! [20:42:49 CET] <cehoyos> ! [20:42:57 CET] <j-b> Daemon404: because we really know who wm4 and 'elvis' are. [20:43:00 CET] <cehoyos> j-b: Could you point me to the author line? [20:43:14 CET] <rcombs> author of the commits? [20:43:16 CET] <j-b> From: foo86 <foobaz86(a)gmail.com> [20:43:21 CET] <Daemon404> j-b, there's plenty of mplayer-era code by anonymous people too [20:43:24 CET] <Daemon404> thats still around [20:43:37 CET] <Daemon404> or random <fakename.ffmpeg(a)gmail.com> [20:43:40 CET] <j-b> wm4 and "elvis" are pseudonyms [20:43:40 CET] <Daemon404> that oens popular. [20:43:45 CET] <cehoyos> But he himself claims that he is not the author of the decoder or am I wrong? [20:43:53 CET] <rcombs> huh? [20:43:58 CET] <jamrial> cehoyos: foo86 is the author [20:43:59 CET] <cehoyos> pseudonyms are of course no problem. [20:44:03 CET] <Daemon404> cehoyos, libdcadec is foo86. he is the author. [20:44:13 CET] <cehoyos> Then why does he not claim copyright? [20:44:20 CET] <Daemon404> ceause he doesnt care? [20:44:23 CET] <j-b> Daemon404: of course, why do you think I complain ALL the time, when you guys let people commit anonymously? [20:44:27 CET] <Daemon404> :P [20:44:29 CET] <rcombs> because he didn't think to do so? [20:44:34 CET] <j-b> cehoyos: you don't claim copyright. [20:44:36 CET] <rcombs> because nobody told him to [20:44:45 CET] <cehoyos> If he doesn't care how can he give us the right to do something with the code? [20:44:46 CET] <jamrial> probably because foo86 is a pseudonym and he didn't want it in the copyright headers [20:44:48 CET] <rcombs> (and yeah copyright is automatic in the US at least) [20:44:59 CET] <j-b> cehoyos: it does not work like that. [20:45:04 CET] <cehoyos> Pseudonyms are of course ok (many books use it). [20:45:05 CET] <j-b> cehoyos: he has rights. [20:45:11 CET] <j-b> and you cannot remove them. [20:45:17 CET] <rcombs> cehoyos: he owns the copyright on his own works automatically, and explicitly grants a license in the header of each file [20:45:28 CET] <cehoyos> So stop this and allow me to repeat: How was this decoder written? [20:45:35 CET] <kierank> how do you think [20:45:40 CET] <rcombs> probably with a text editor [20:45:48 CET] <rcombs> *rimshot* [20:45:50 CET] <kierank> the ceo of dts called him up and explained the codec to him [20:45:53 CET] <j-b> exactly what rcombs said, except that he gave rights, not copyright. [20:46:01 CET] <cehoyos> rcombs: He can only grants rights (and licenses) if he actually claims the copyright, I am not saying his code is (anywhere) in the public domain. [20:46:05 CET] <jamrial> cehoyos: foo86 wrote libdcadec, a standalone library to decode dca [20:46:16 CET] <j-b> cehoyos: no. [20:46:17 CET] <jamrial> he then ported it to a native libavcodec decoder [20:46:23 CET] <rcombs> cehoyos: he can only grant rights if he _owns_ the copyright, regardless of any "claims" [20:46:27 CET] <j-b> cehoyos: one doesn't claim copyright. [20:46:36 CET] <j-b> it's by default. [20:46:37 CET] <cehoyos> But he does not claim he owns the copyright... [20:46:43 CET] <j-b> he does. [20:46:48 CET] <j-b> he claims the author rights. [20:46:55 CET] <j-b> Which is the correct thing to do. [20:47:01 CET] <cehoyos> So why is there no copyright notice? Without it, the license below is of course void. [20:47:06 CET] <j-b> cehoyos: of course not. [20:47:10 CET] <Daemon404> ... thats not how the law works [20:47:12 CET] <rcombs> says who [20:47:13 CET] <durandal_1707> ubitux: I think the showspectrum should use fft instead, because it doesn't have enough dynamic range for log scaler [20:47:21 CET] <jamrial> there's plenty of files with no copyright notice in the tree, cehoyos [20:47:31 CET] <cehoyos> And that is bad, so don't add more! [20:47:43 CET] <j-b> cehoyos: the ONLY correct way to know the author on a line is to use git blame [20:48:11 CET] <cehoyos> Why can nobody explain how the decoder was written? This is the more important question imo and will likely answer my other question. [20:48:18 CET] <jamrial> i said it above [20:48:19 CET] <rcombs> copyright notice hasn't been required since March 1, 1989 [20:48:28 CET] <j-b> rcombs: of course. [20:48:39 CET] <durandal_1707> ubitux: even with flattop window I see leakage which isn't actually there with sine wave [20:48:41 CET] <cehoyos> j-b: You know very well that git blame can be fooled and cannot be used to the author of code. [20:48:47 CET] <jamrial> he wrote it first as libdcadec: https://github.com/foo86/dcadec [20:48:59 CET] <j-b> cehoyos: sorry, but no, you are incorrect. [20:49:02 CET] <durandal_1707> stealers [20:49:10 CET] <j-b> cehoyos: git blame will give you the author line. [20:49:24 CET] <j-b> which is more important than the BS the copyright line of the file say. [20:49:34 CET] <cehoyos> There is not copyrigh line... [20:49:38 CET] <j-b> especially in authorship countries. [20:49:59 CET] <cehoyos> j-b: atm we are not talking about the thieves... [20:50:08 CET] <rcombs> affect all copyright notice does for you is inform the public of the copyright owner and year, which prevents an innocent-infringement defense [20:50:09 CET] <jamrial> because he didn't want to add one. how are we still discussing this absurdity? [20:50:16 CET] <jamrial> It's his code. he wrote it, he submitted it [20:50:20 CET] <cehoyos> So how was it written? [20:50:28 CET] <j-b> he wrote a library over 3 years [20:50:36 CET] <jamrial> how about you follow the above link? [20:50:37 CET] <wm4> cehoyos: with a text editor and a brain [20:50:40 CET] <rcombs> (with a text editor) [20:50:44 CET] <wm4> hands were probably also involved [20:50:45 CET] <rcombs> oh yeah that too [20:50:47 CET] <cehoyos> sorry, I hadn't realized this, let me see. [20:51:00 CET] <wm4> j-b: 3 years? [20:51:01 CET] <rcombs> probably some amount of reverse-engineering and reading of existing code and documentation [20:51:08 CET] <j-b> wm4: maybe less, who cares? [20:51:14 CET] <jamrial> the guy wrote a standalone decoder, ported it to libavcodec and now submitted it in a patch [20:51:16 CET] <wm4> the original code was in D [20:51:17 CET] <j-b> but seriously, copyright lines are useless. [20:51:19 CET] <rcombs> the library is 7 years hand drawn [20:51:23 CET] <jamrial> he didn't want to add a "copyright me" because he didn't want to [20:51:26 CET] <jamrial> end of the discussion [20:51:31 CET] <wm4> then he converted it to C after I told him how much D sucks [20:51:37 CET] <j-b> what is important is authorship [20:51:37 CET] <cehoyos> The first commit I see was in March, how do you know it was three years? [20:51:45 CET] <j-b> cehoyos: it was in D, before. [20:51:56 CET] <cehoyos> Can you point me to the repo? [20:52:12 CET] <jamrial> he deleted it [20:52:27 CET] <jamrial> it was also in that github account, but removed it once he ported it to c and renamed it to dcadec [20:52:35 CET] <wm4> maybe you still can find it on github as a fork [20:52:52 CET] <wm4> or, you know, just ask him [20:53:49 CET] <jamrial> it was called xlldec when it was written in D i think [20:54:04 CET] <cehoyos> Has anybody seen the reference decoder? Kieran? [20:54:18 CET] <j-b> https://github.com/foo86/xlldec [20:54:25 CET] <j-b> Kieran and Kostya [20:54:41 CET] <cehoyos> kierank? [20:55:04 CET] <cehoyos> j-b: Do you still have the repo? [20:55:06 CET] <j-b> cehoyos: you're afraid that there are copyright infringement in this decoder? [20:55:18 CET] <cehoyos> Afraid is the wrong word. [20:55:28 CET] <j-b> very afraid? [20:55:31 CET] <jamrial> this is absurd [20:55:32 CET] <cehoyos> But I want to avoid FFmpeg becoming avconv [20:55:38 CET] <wm4> wat [20:55:39 CET] <jamrial> this is beyond absurd [20:55:52 CET] <cehoyos> You forgot all the copyright violations already? [20:56:22 CET] <kierank> cehoyos: I have not seen the reference decoder [20:56:24 CET] <kierank> meuuh has probably [20:56:29 CET] <jamrial> cehoyos, the guy wrote the decoder long ago, made it public on his github repo, and now ported it as a native libavcodec decoder [20:56:32 CET] <jamrial> you're paranoid [20:56:46 CET] <j-b> Seriously, Carl, one day, I must explain you what is the copyright violation. [20:57:03 CET] <cehoyos> That's really good to hear, I am just surprised that I had never heard about the decoder before March. [20:57:19 CET] <j-b> and notably about Urheberrecht [20:57:26 CET] <jamrial> because that's when he ported it to C and created the libdcadec repo [20:57:36 CET] <cehoyos> j-b: That is exactly the issue with you: You believe what a bunch of liars tell you! [20:57:54 CET] <jamrial> .... [20:57:57 CET] <j-b> cehoyos: no. A contrarion from you, I did studies of IP law. [20:58:02 CET] <cehoyos> jamrial: Where can I see that it was written long ago? [20:58:11 CET] <j-b> A contrario from you, I worked with lawyers, many times. [20:58:30 CET] <j-b> and gave talks about copyrights, licensing and patents [20:58:33 CET] <jamrial> google xlldec. maybe it was forked [20:58:38 CET] <j-b> it was not [20:58:47 CET] <cehoyos> I am not talking about the law (that I also studied) but about known copyright violators you still support after years, which I consider a pity [20:58:51 CET] <jamrial> or as wm4 said, just ask the guy for it [20:58:59 CET] <j-b> cehoyos: show me one copyright violation. [20:59:02 CET] <j-b> cehoyos: show me one. [20:59:06 CET] <durandal_1707> atomnuker: postimage.org/image/xaqqq1ji7 [20:59:06 CET] <cehoyos> I am curious how you knew about it. [20:59:09 CET] <rcombs> if copyright notices would make you feel better I'm sure he'll add them [20:59:39 CET] <j-b> copyright notices are useless. [21:01:47 CET] <rcombs> I wonder how many of the files in ffmpeg have copyright that actually matches their notices [21:01:53 CET] <rcombs> very few, I'd expect [21:02:41 CET] <j-b> of course [21:02:41 CET] <rcombs> since most are collaborative works with authors who aren't listed, amongst other discrepancies [21:02:47 CET] <j-b> exactly. [21:02:51 CET] <jamrial> tons of files still mention fabrice bellard [21:03:09 CET] <j-b> FFmpeg is a collaborative work, based on Author-rights. (not copyright) [21:03:22 CET] <wm4> I keep wondering what's the point of names in copyright headers, but I'd also be afraid to remove them [21:03:26 CET] <rcombs> I wonder if any credit people who didn't actually contribute because of copypaste [21:03:29 CET] <rcombs> in new files [21:03:44 CET] <cehoyos> 4f979418c723652ad4e43115118c57a44bd46b52 comes to mind... [21:03:56 CET] <atomnuker> durandal_1707: looks nice (if you swap the time and frequency axis) [21:04:01 CET] <j-b> wm4: it's to make people afraid when they take one file. [21:04:35 CET] <j-b> in all files, you should put "Copyright the FFmpeg project" [21:04:44 CET] <durandal_1707> atomnuker: that's with horizontal orientation like baudline [21:06:20 CET] <cehoyos> j-b: There is no "FFmpeg project" [21:06:28 CET] <atomnuker> btw if the width and height of avctx can change during decoding could the pixel format change as well? [21:06:38 CET] <cehoyos> It can. [21:06:40 CET] <j-b> cehoyos: write "FFmpeg authors" then [21:06:56 CET] <wm4> atomnuker: yes [21:07:08 CET] <atomnuker> thanks [21:13:45 CET] <wm4> j-b: can I ask a random copyright question? I want to relicense mpv to LGPL, but being MPlayer based maybe this is too hard... what if I write a new player from scratch (potentially copy some lines of code I've written for mpv), and add back some bits of LGPL (re-)licensed mplayer code, is that a copyright violation? [21:14:12 CET] <j-b> wm4: of course it's not. [21:14:49 CET] <wm4> copyright is strange [21:14:53 CET] <j-b> It is not. [21:14:57 CET] <j-b> wm4: it's very simple. [21:15:23 CET] <j-b> it just goes against what we, coders, think of it. [21:15:23 CET] <cone-301> ffmpeg 03Andreas Cadhalpun 07master:713654d9d3a6: get_bits: add get_bitsz for reading 0-25 bits [21:15:23 CET] <cone-301> ffmpeg 03Andreas Cadhalpun 07master:43ff4aed26cb: lavc: use get_bitsz to simplify the code [21:15:23 CET] <cone-301> ffmpeg 03Andreas Cadhalpun 07master:40eb2531b279: ffmdec: reset packet_end in case of failure [21:15:27 CET] <rcombs> collaborative works are complicated! [21:15:38 CET] <wm4> (they say the same about differential equations) [21:15:45 CET] <j-b> wm4: first, in FFmpeg and MPlayer, copyright is of NO MATTER. [21:16:03 CET] <cehoyos> wm4: If mpv is based on MPlayer (I don't know if it is), I don't think relicensing will be possible: There were too many authors and you will not be able to reach them all. [21:16:10 CET] <rcombs> and international differences in copyright/author's rights law is weird! [21:16:19 CET] <j-b> Because France, Austria, Switzerland and Germany are Authorship-countries. [21:16:25 CET] <cehoyos> Nico is an example of an author who in the past was against relicensing. [21:16:46 CET] <wm4> cehoyos: I know, but I guess there's only 20% of mplayer code left in mpv (although I'd prefer relicensing mplayer itself) [21:16:48 CET] <rcombs> so rewrite all his code? [21:17:05 CET] <j-b> And some rights are untransferable. [21:17:17 CET] <Compn> i like all of those countries that deny the ability to transfer a copyright [21:17:24 CET] <cehoyos> wm4: This is the "usual" misconception (I don't think anybody of the dark side really believes this, but this is how they argue): [21:17:24 CET] <Compn> which means 'public domain' cannot exist [21:17:31 CET] <wm4> cehoyos: the most significant part seems to be that mpv still follows some basic structure/architecture of mplayer [21:17:34 CET] <cehoyos> It doesn't matter how many percent were rewritten;-( [21:17:56 CET] <wm4> cehoyos: it matters for relicensing effort [21:18:00 CET] <j-b> wm4: if you base your code from another one, _even_ if you rewrite everything, it's not enough. [21:18:15 CET] <wm4> j-b: so ffmpeg is european? [21:18:18 CET] <j-b> wm4: yes. [21:18:42 CET] <rcombs> cleanroom! [21:18:50 CET] <cehoyos> No: If code is based on MPlayer author, the original authors would have to be asked. [21:18:57 CET] <cehoyos> And I doubt you can reach them all. [21:19:04 CET] <j-b> cehoyos is correct here. [21:19:11 CET] <cehoyos> Remember what happened when they wanted to relicense x11grep: [21:19:16 CET] <rcombs> so how'd it work for VLC? [21:19:22 CET] <j-b> rcombs: read my blog. [21:19:29 CET] Action: rcombs re-reads [21:19:34 CET] <wm4> well my approach would have been: write a new code base until the most basic things work (but I'd cheat and reuse some code _I_'ve written within mpv), and then copy back larger LGPL based parts (this would for example be the opengl renderer, which is already LGPL) [21:19:40 CET] <jamrial> i remember a similar issue relicensing yadif [21:19:50 CET] <j-b> wm4: yes, that would work. [21:20:15 CET] <j-b> but I'd suggest be really clear about splitting the parts you import. [21:20:26 CET] <cehoyos> They asked everybody including Goofy, Waldorf and Statler and me but not the original authors... [21:20:45 CET] <cehoyos> It was different with yadif though: *Everybody* was asked and answered. [21:20:47 CET] <wm4> cehoyos: michael? [21:20:53 CET] <j-b> because original authors can claim you took some ideas. [21:21:03 CET] <cehoyos> What about him? [21:21:08 CET] <wm4> j-b: yes, that's the part that worries me [21:21:16 CET] <wm4> that such abstract things are copyrightable [21:21:18 CET] <j-b> wm4: also remember something: "there is no trivial contribution" [21:21:36 CET] <cehoyos> This is what happened for libswscale and delayed it for more than a year iirc. [21:21:38 CET] <j-b> a one-liner can be protected. [21:21:49 CET] <wm4> j-b: doesn't it depend on the legislature? [21:21:54 CET] <j-b> wm4: no. [21:21:56 CET] <cehoyos> The dark side disagrees (heavily) [21:22:08 CET] <wm4> the US knows fair-use and such [21:22:16 CET] <rcombs> >And then, I deleted some code, reverted some commits, rewrote some and or isolated code from them in a separate files to reduce the future impact. [21:22:42 CET] <cehoyos> wm4: What about Michael? [21:22:49 CET] <j-b> wm4: fair-use does not apply in software code, except education and such. [21:23:08 CET] <j-b> wm4: still, a rewrite would be better. And then you import very defined parts. [21:23:11 CET] <wm4> cehoyos: I thought you talked about yadif, of which he's the author [21:23:18 CET] <cehoyos> No, x11grep [21:23:53 CET] <wm4> j-b: ok... what about Mozilla, who said only 95% of all contributors matter? [21:24:02 CET] <wm4> (other projects used this too) [21:25:14 CET] <ubitux> even for a bug fix a one liner can be protected? what if it's a necessary rename of symbol use because of api changes for example? [21:25:18 CET] <wm4> "UPDATE 2007-02-04: Someone who works with many lawyers on free software copyright issues later told me that it is not necessary to get permission from 100% of the copyright holders. It would suffice if there was permission from the copyright holders of 95% of the source code and no objections from the holders of the other 5%." [21:25:55 CET] <Compn> <jamrial> tons of files still mention fabrice bellard <~~~ whats your problem with fabrice? :P [21:26:05 CET] <wm4> j-b: also, the interesting question is: what if the one-liner is later removed? what if it's rewritten by 50%? what if it got rewritten step by step so that nothing is left? [21:26:11 CET] <Compn> tons of files still have his commits (or did before cosmetics) [21:26:20 CET] <wm4> Compn: nothing, it's just that he did nothing since over a decade or so [21:26:22 CET] <wm4> *for [21:26:38 CET] <Compn> wm4 : copyright does not expire (at least in usa) until 90 years after author death lol [21:26:42 CET] <wm4> but I admit sometimes when git blaming, I still end up at one of his commits [21:27:14 CET] <rcombs> the Copyright Ship of Theseus [21:27:55 CET] <Compn> i studied many copyright cases over the years, from SCO v linux to napster to google books v publishers to riaa vs everyone... [21:28:06 CET] Action: rcombs replaces the right side of an assignment statement, then replaces the left side of the statement, then retypes the = sign [21:28:07 CET] <Compn> i'm no expert :P [21:28:21 CET] <rcombs> >riaa vs everyone [21:28:24 CET] <rcombs> not even an exaggeration [21:28:42 CET] <rcombs> Petition for Class Action against All You Fuckers [21:29:11 CET] <wm4> if I commit something non-trivial, and it reappears somewhere else without credit to me, is that a copyright violation? [21:29:23 CET] <wm4> probably yes, but the same with something more trivial? like a single word? [21:29:27 CET] <rcombs> Notice to Fuck this Court and everything It stands for [21:29:30 CET] <Compn> they have sued a magnitude of people. [21:29:35 CET] <wm4> what about a single character? [21:29:46 CET] <wm4> I can only conclude copyright has nothing to do with text/pattern matching [21:29:51 CET] <durandal_1707> ubitux: so fine to switch to fft? [21:29:55 CET] <rcombs> wm4: in the former case it depends on the license [21:30:01 CET] <wm4> rather, it's up to the judge's mood [21:30:03 CET] <ubitux> durandal_1707: no opinion, probably [21:30:10 CET] <ubitux> durandal_1707: iirc i just ported code from ffplay [21:30:15 CET] <rcombs> ~everything's a remix~ [21:30:30 CET] <rcombs> ~fair use is poorly-defined~ [21:30:30 CET] <jamrial> Compn: none, just saying that the copyright line has in a lot of cases no meaning regarding the contents of each file [21:30:32 CET] <ubitux> durandal_1707: yeah code is initially from ffplay rdft code [21:30:35 CET] <wm4> spam? https://trac.ffmpeg.org/wiki/MaintainingFFmpeg?action=diff&version=6 [21:30:35 CET] <Compn> wm4 : someone said once that equasions could not be copyrighted. likewise tables (only the number tables we are talking about) or machine generated tables... something like that. but yes up to a judge haha [21:30:40 CET] <j-b> wm4: yes, that's why it's hard. [21:31:22 CET] <j-b> wm4: Mozilla is a different case, because they have an entity, and thus a collaborative work [21:31:42 CET] <jamrial> wm4: yeah, looks like spam [21:31:48 CET] <Compn> jamrial : sure. i'm guessing those are left in for "historical purposes" [21:32:04 CET] <Compn> like naming a hospital after someone. [21:32:06 CET] <j-b> wm4: but yes, the 95% rules is BS, and is easily attackable. [21:32:23 CET] <wm4> it's often cited [21:32:31 CET] <j-b> It does not make it right. [21:32:37 CET] <smarter> j-b: didn't you only get approval from 99% of of the authors or something for VLC ? [21:32:47 CET] <j-b> smarter: nope. 100%. [21:32:52 CET] <smarter> wow [21:33:01 CET] <j-b> smarter: which is why some parts are not LGPL [21:33:02 CET] <Compn> j-b had to rewrite parts of vlc that did not get authors permission. [21:33:07 CET] <Compn> iirc [21:33:11 CET] <j-b> like the BDA module [21:33:20 CET] <j-b> and as Compn says, I did stuff like that. [21:33:27 CET] <smarter> okay [21:33:35 CET] <Compn> and by 'rewrite' i mean 'write from scratch' not just mess about with the old code :P [21:33:37 CET] <smarter> so what about dead people? Do you have to rewrite their code? [21:33:40 CET] <rcombs> ^CLEANROOM^ [21:33:42 CET] <j-b> Like: clean room reimplementation of a function, with witnesses, and with 3 people coding. [21:33:55 CET] <j-b> and them, not having internet access. [21:33:59 CET] <Compn> smarter : yes. [21:34:12 CET] <smarter> copyright sucks [21:34:15 CET] <j-b> smarter: I had to go to see one dad, who had lost his child [21:34:17 CET] <Compn> their code is their property, estate, goes to probate court (in usa) [21:34:24 CET] <j-b> to ask him to relicensiate. [21:34:29 CET] <j-b> it was horrible. [21:34:29 CET] <smarter> damn [21:34:38 CET] <Compn> wow. [21:34:48 CET] <j-b> the guys thought I was going to make millions out of his son's code. [21:35:13 CET] <Compn> j-b : you have nt made millions off vlc yet? :P [21:35:13 CET] <j-b> that was sad. [21:35:23 CET] <j-b> Compn: if I wanted to make money, I would have. [21:35:33 CET] <Compn> youtube is making money off mencoder :D [21:35:37 CET] <j-b> it's more fun to be poor and troll with you guys. [21:35:44 CET] <smarter> j-b: <3 [21:36:09 CET] <j-b> Compn: seriously. Imagine installing Chrome or the Ask toolbar when you install VLC. [21:36:17 CET] <j-b> opt-out. [21:36:30 CET] <rcombs> I really should go to VDD this year [21:36:38 CET] <Compn> its fun, go [21:36:40 CET] <smarter> j-b: and opt-out everytime you upgrade VLC! [21:37:08 CET] <Compn> j-b : i dont know how much the opt-out stuff nets a person. it must be a lot though. mozilla does it, flash player does it [21:37:25 CET] <smarter> mozilla does it? [21:37:28 CET] Action: rcombs opts out of flash player [21:37:34 CET] <wm4> ads during video playback, yummy [21:37:37 CET] <Compn> mozilla does it with the default search engine, yes [21:37:55 CET] <smarter> okay, that's a bit different [21:38:01 CET] <Compn> is it really ? [21:38:13 CET] <rcombs> that's a setting, not a piece of crapware [21:38:19 CET] <j-b> Compn: it was 1$/install. [21:38:21 CET] <cehoyos> 6c1df1f2 is the example I searched for, sorry for the delay. [21:38:23 CET] <Compn> yahoo search is pretty crap :P [21:38:25 CET] <cehoyos> But that makes two;-) [21:38:27 CET] <rcombs> and you can change it once and it doesn't get reset on reinstall [21:38:46 CET] <rcombs> erm, on upgrade [21:38:58 CET] <wm4> cehoyos: "sgi: encode images with 4 channels at 8 and 16 bits" [21:38:59 CET] <wm4> ? [21:39:26 CET] <cehoyos> Yes, the other one is better because it was an intentional copyright violation, this one is more "avconv has no reviews" [21:39:35 CET] <Gramner> you should add opt-out with double-negative phrasing of a dozen dubious programs/toolbars. on page 7 after 6 legit "i agree" pages [21:39:53 CET] <wm4> cehoyos: well we don't care about your hate-obsession with Libav [21:40:00 CET] <j-b> Gramner: yes. [21:41:38 CET] <cehoyos> Sorry, j-b asked... [21:41:49 CET] <j-b> wm4: you should fork from VLC, it'd be easier :) [21:42:10 CET] <cehoyos> But at least it is based on reciprocity;-) [21:45:01 CET] <wm4> j-b: actually, before I forked mplayer2, I considered using/improving vlc, but it somehow didn't work out [21:53:07 CET] <prelude2004c> hey guys.. this make any sense " [h264 @ 0x26bcd20] Hardware accelerated decoding with frame threading is not supported " [21:53:09 CET] <prelude2004c> what does that mean ? [21:53:39 CET] <wm4> prelude2004c: set the thread count to 1 [21:53:52 CET] <wm4> -threads 1 on ffmpeg CLI maybe [21:57:42 CET] <J_Darnley> Someone with a trac account: I think some spam just added here https://trac.ffmpeg.org/wiki/MaintainingFFmpeg?action=diff&version=6 [21:59:28 CET] <rcombs> I'll get it [22:03:25 CET] <rcombs> though I don't think I can ban the user [22:07:59 CET] <cehoyos> I removed the user [22:16:26 CET] <J_Darnley> Yeah! Justice! [22:21:49 CET] <cehoyos> I wonder why the change can't be undone instead of reverted... [22:23:54 CET] <prelude2004c> hey guys. having trouble with vdpau... someone told me to decode using " vc ffh264vdpau " . not sure where to put that.. i am using ffmpeg mpeg2video sources seem to decode ok and then i can transcode it to something else.. but h264 sources don't seem to decode at all i am using M4000 card running latest 258.16 version . anyone have any ideas ? [22:24:57 CET] <cehoyos> Should be undone now;-) [22:25:29 CET] <J_Darnley> prelude2004c: is that supposed to be -vcodec on the command line? [22:28:10 CET] <prelude2004c> yes i run that in a script [22:28:19 CET] <prelude2004c> my source is a UDP:// source [22:28:58 CET] <J_Darnley> then you put it before the "file" you want to use it with [22:31:40 CET] <prelude2004c> what -vcodec do i put ? [22:32:08 CET] <J_Darnley> Are we going in circles? What did you just say? [22:38:13 CET] <prelude2004c> ahh i get what you said .. but i tried to use " Unknown decoder 'ffh264vdpau' " [22:38:25 CET] <prelude2004c> its used in ffmpeg ? [22:43:03 CET] <philipl> That's the mplayer codec name. [22:54:06 CET] <prelude2004c> yup correct.. so i dont know why darnley thought i should use it [22:54:15 CET] <prelude2004c> anyways, i am super super stuck [22:54:26 CET] <prelude2004c> i don't know what to do :( [22:58:18 CET] <cone-301> ffmpeg 03Carl Eugen Hoyos 07master:ae9f2e6f2813: lavfi/drawtext: Fix microsecond display. [23:12:22 CET] <cone-301> ffmpeg 03Paul B Mahol 07master:14caf9667e3f: avfilter/avf_showspectrum: switch to FFT [23:12:23 CET] <cone-301> ffmpeg 03Paul B Mahol 07master:0a451082c774: avfilter/avf_showspectrum: finally fix log scaler [23:19:16 CET] <Compn> prelude2004c : upgrade all vdpau libs [23:19:31 CET] <Compn> and u pgrade your distro, because i'm assuming you are on an old ubuntu version [23:19:42 CET] <Compn> and update your nvidia binary driver [23:21:10 CET] <fritsch> Compn: i told him > 10 days ago ... [23:26:34 CET] <Compn> prelude2004c : are you listening ? [23:41:45 CET] <durandal_170> cehoyos: what are you talking about, what dark side? [23:46:05 CET] <cone-301> ffmpeg 03Andreas Cadhalpun 07master:b4b13848dec5: vorbisdec: reject channel mapping with less than two channels [00:00:00 CET] --- Mon Jan 4 2016

1 0

ffmpeg.log.20160103
by burek 04 Jan '16

04 Jan '16

[00:15:11 CET] <t4nk767> hey guys another quesiton [00:15:28 CET] <t4nk767> is it possible to stream with ffmpeg a folder with a lot of videos [00:15:30 CET] <t4nk767> randomly [00:41:16 CET] <c_14> yes, but it's a pain [00:41:26 CET] <c_14> and requires at least mild scripting [00:44:38 CET] <t4nk767> is there any guide [00:44:40 CET] <t4nk767> somewhere [00:45:09 CET] <c_14> It's basically the concat demuxer and some scripting for the shuffling [00:45:14 CET] <c_14> https://trac.ffmpeg.org/wiki/Concatenate [00:46:21 CET] <t4nk767> ok and for the shuffeling is there anything online [00:46:52 CET] <t4nk767> or any tip [00:47:52 CET] <c_14> ls | shuf [00:48:32 CET] <t4nk767> but it takes as input a txt file [00:48:51 CET] <c_14> ffmpeg -f concat <(ls | shuf) [00:48:53 CET] <t4nk767> i guess it can be auto generated with grep somehow, but how to dynamically change it [00:49:00 CET] <t4nk767> aha [01:02:19 CET] <t4nk767> its working somehow :) [01:02:26 CET] <t4nk767> after the playlist finishes [01:02:30 CET] <t4nk767> deos it loop? [01:04:14 CET] <c_14> no [01:04:57 CET] <Deihmos> I am using ffmpeg binaries for a project I found on github that converts videos [01:05:10 CET] <Deihmos> problem is ffmpeg runs slow as molasses [01:06:01 CET] <Deihmos> taking forever to remux a video. Other programs can do it in less than a minute. Is there something i can do to make it run full speed? [01:06:07 CET] <Deihmos> cpu use is like 10% [01:07:42 CET] <c_14> depends, what's the command? [01:08:25 CET] <Deihmos> i have no clue [01:08:37 CET] <Deihmos> i don't see this info [01:08:42 CET] <Deihmos> let me check the logs [01:10:34 CET] <t4nk767> @c_14 , sorry to ask again but, this concatenate just finishes the videos transcoding and thats it, I am looking more on a solution to create a channel from videos inside a folder. Any ideas on how to do that, maybe? [01:10:49 CET] <c_14> channel? [01:11:09 CET] <t4nk767> yes from a folder that has music videdos lets say, I want to loop those randomly all the time [01:11:23 CET] <t4nk767> and stream them to a server [01:12:51 CET] <c_14> t4nk767: to loop, you can put the ls in a while true loop [01:12:59 CET] <c_14> Otherwise it's just regular streaming. [01:14:01 CET] <t4nk767> yes but ffmpeg is just converting the video from what I see at 5x speed. I need it to play at normal speed and broadcast it [01:14:10 CET] <c_14> add -re before -i [01:14:19 CET] <t4nk767> ill try [01:15:06 CET] <t4nk767> ah [01:15:33 CET] <t4nk767> seems good now [01:15:55 CET] <t4nk767> ffmpeg -f concat -re -i <(printf "file '$PWD/%s'\n" ./*.mp4 | shuf) -c copy -f flv rtmp://publishing_server:8001/input/stream [01:16:12 CET] <t4nk767> can I put the while somewhere in the -i command there? [01:16:26 CET] <c_14> <(while true; do blah; done [01:16:28 CET] <c_14> ) [01:16:41 CET] <t4nk767> oki thanks, will try [01:25:31 CET] <t4nk767> while true doesnt work, ffmpeg just hangs [01:25:52 CET] <t4nk767> i guess it needs a limit or I am doing something wrong again [01:29:53 CET] <c_14> mhm, ye it might read to eof [01:30:15 CET] <c_14> then just pick a really big number and for i in `seq <big number>`; [01:44:46 CET] <t4nk767> yep its what I did [01:44:48 CET] <t4nk767> thanks [02:13:54 CET] <t4nk767> hi again [02:14:27 CET] <t4nk767> concatenation seems to fail for some reason. Once the first video is finished I get the following error [02:14:28 CET] <t4nk767> invalid dropping st:0 [03:45:02 CET] <fluter> hi [06:35:06 CET] <prelude2004c> hey guys. having trouble with vdpau... someone told me to decode using " vc ffh264vdpau " . not sure where to put that.. i am using ffmpeg [06:35:08 CET] <prelude2004c> mpeg2video sources seem to decode ok and then i can transcode it to something else.. but h264 sources don't seem to decode at all [06:35:09 CET] <prelude2004c> i am using M4000 card [06:35:11 CET] <prelude2004c> running latest 258.16 version [06:38:43 CET] <furq> prelude2004c: that's an mplayer option [06:39:32 CET] <prelude2004c> but ffmpeg has the option too i think [06:39:41 CET] <prelude2004c> is there some way to use mplayer and then pipe to ffmpeg ? [06:39:56 CET] <prelude2004c> i tried with mplayer before but it would not take in the udp source stream [06:41:12 CET] <prelude2004c> even tried with ffmplay [06:58:46 CET] <SSE4> Hi, I am multiplexing MP4 file, and I need to add track reference information (tref box). I've searched ffmpeg sources, and found out that movenc.c has function that does exactly that I need - mov_write_tref_tag. it will be called for trach if it has tref_tag set. however, it's not clear for me how to set tref_tag from the API? tref_tag is member of MOVTrack structure, but I am not sure how can I access it from my code? [09:41:04 CET] <Mavrik> SSE4, if it's a muxer option, pass it as part of options dict when opening the muxer (or then writing header, don't remember ATM which call has the options param) [09:41:52 CET] <SSE4> Mavrik it doesn't seem like muxer option, it's rather internal variable of muxer internals [09:53:13 CET] <Mavrik> Hrmf, yeah I see it in source, the tref_tags are set only in code [09:53:29 CET] <Mavrik> CHAP, HINT and TMCD if I read this correctly [09:56:46 CET] <SSE4> yep exactly [09:57:00 CET] <SSE4> is there a way to set that from the outside? [09:59:12 CET] <Mavrik> Do you want to set one of those three or a custom one? [10:43:33 CET] <SSE4> custom one [14:04:50 CET] <clb> hey, I wonder if someone could help me out for a sec with command line flags to use for converting a sequence of .tifs to a h265 video? [14:05:28 CET] <clb> I am trying with "ffmpeg -start_number 557 -i DSC00%%3d.tif -vcodec libx265 -x265-params --input-csp i420 -preset veryslow out.mp4", but I'm getting "[NULL @ 000001eef5d5cb80] Unable to find a suitable output format for 'i420'" [14:06:18 CET] <clb> in particular, it's looking like this: http://pastebin.com/XGWmzXqz [14:09:20 CET] <clb> hmm, "ffmpeg -start_number 557 -i DSC00%%3d.tif -vcodec libx265 -strict experimental -preset veryslow out.mp4" starts running, though I am a bit unsure about the -strict experimental, I wonder if that's a bad thing to use with respect to getting out a file that'll play in most browsers e.g. in youtube? [14:11:03 CET] <sfan5> can't you omit -strict experimental? [14:11:15 CET] <sfan5> also i'm pretty sure that no browser can play H.265 atm [14:11:25 CET] <sfan5> and -x265-params takes a string [14:11:39 CET] <clb> if I do omit -strict experimental, I get "[libx265 @ 0000027a90a5bae0] 4:2:2 and 4:4:4 support is not fully defined for HEVC yet. Set -strict experimental to encode anyway." [14:12:00 CET] <sfan5> you probably need to do -x265-params "input-csp=i420" if you really want to pass that to x265 [14:12:10 CET] <clb> ah, didn't know browsers don't have H.265, I'm just kinda going from "for 4k video, H.265 is recommended over H.264" [14:12:20 CET] <sfan5> in that case i'd suggest using -pix_fmt yuv420p [14:13:08 CET] <sfan5> telling x265 directly that the input is yuv420p will probably cause problem as ffmpeg doesn't know about that and will pass whatever your input pixfmt was (probably yuv422p) to x265 [14:13:41 CET] <clb> thanks, let me try that in a moment after this -strict experimental encode finishes [14:14:01 CET] <clb> I think my input format is RGB24, since it's a sequence of tiffs(?) [14:14:13 CET] <clb> or perhaps that is different [14:14:18 CET] <sfan5> ffmpeg will convert that to YUV for encoding [14:14:22 CET] <clb> ah, check [14:14:22 CET] <sfan5> probably yuv444p [14:18:38 CET] <clb> ooh ffmpeg is pretty efficient at saturating 16 logical cores on my system, neat [14:19:53 CET] <JEEB> btw, depending on your use case libx265 might not be "ready" yet [14:20:00 CET] <furq> clb: if you're uploading to youtube then it doesn't matter what you transcode it to (unless bandwidth is a concern) [14:20:19 CET] <JEEB> it seems to randomly lose parts of stuff in the picture [14:20:21 CET] <furq> youtube will transcode it to h264/vp9 regardless [14:20:27 CET] <JEEB> on relatively high bit rate scenarios [14:21:12 CET] <JEEB> if it's just to push stuff down while having it not look too great, that is where it already more or less works [14:21:22 CET] <clb> furq, JEEB: thanks, very good to know, perhaps I'll be better off running the final export with h264 then. I suppose h264 is fine with 4K and not outright horrible? [14:21:40 CET] <furq> it's fine with enough bitrate [14:21:57 CET] <furq> youtube will transcode it again anyway [14:22:17 CET] <furq> even if you upload h264/aac it'll transcode it to h264/aac [14:22:20 CET] <JEEB> and if it's to youtube you might as well use some lossless format as the thing that goes up and let youtube take it behind the barn [14:22:33 CET] <furq> unless bandwidth is an issue [14:22:45 CET] <furq> if it's not then yeah, there's no point compressing it [14:22:54 CET] <JEEB> there's a point to compressing it [14:23:07 CET] <JEEB> I don't like getting masters as uncompressed shit :P [14:23:16 CET] <JEEB> (and it takes longer to upload those) [14:23:36 CET] <JEEB> in which I want to say that lossless compression != uncompressed [14:33:18 CET] <clb> ok, switched to h.264 [14:35:54 CET] <BtbN> Doesn't YT have an upload size limit? [14:36:10 CET] <BtbN> Like, won't they shout at you if you upload a 500GB lossless master file? [14:36:13 CET] <furq> yes but it's 128GB [14:36:25 CET] <furq> or 11 hours [14:37:37 CET] <clb> perhaps an odd question, but I wonder if there is a way to duplicate the last frame of the sequence for several seconds? [14:39:34 CET] <furq> clb: http://video.stackexchange.com/a/10833 [14:40:04 CET] <clb> thanks! [15:00:36 CET] <clb> thanks for the help, it worked out well! If you want to take a peek of the result, see https://dl.dropboxusercontent.com/u/40949268/dump/DragonHeartless.mp4 (89MB, 60 seconds) [15:16:52 CET] <clb> need to get a bigger memory card so that I can shoot more frames to get a 30fps timelapse, and with a slightly smaller aperture so that the whole model will be in focus [16:50:24 CET] <Disturbed1> anyone know what this means? been fighting with ffmpeg compile (nvenc/nvresize/patch1511) got it to work... now when i try to transcode a file i get this msg... -> [16:50:28 CET] <Disturbed1> [nvenc @ 0x3c9df80] NVENC with Codec H264 Not Available at requested GPU 0 [17:13:55 CET] <BtbN> Add -pix_fmt yuv420p [17:14:39 CET] <BtbN> Also, "nvresize" looks like you applied that hacky nvidia patch-set. That's entirely unsupported and you are on your own when using that. [17:15:23 CET] <DHE> Disturbed1: sounds like your GPU doesn't support nvenc [17:15:31 CET] <DHE> you need a card without shadowplay support [17:16:00 CET] <BtbN> That entire error message doesn't look like it comes from the ffmpeg nvenc encoder, at least I don't remember seeing it before. [17:21:40 CET] <Disturbed1> i'm using a nvidia s870 ..... :( [17:29:12 CET] <Disturbed1> couldn't find any documentation if the tesla s870 is supported by ffmpeg or nvenc5sdk so i was just hoping it would be... kinda the only reason i bought it... [17:45:44 CET] <DHE> those are not intended for video processing.. no outputs. I'm suspecting they don't have the nvenc chip on them [17:46:13 CET] <DHE> nvenc actually uses a distinct hardware h264 encoding processor. the idea is that encoding has no effect on using the board for ordinary 3d gaming [17:52:01 CET] <BtbN> Just don't use strange patches from nvidia, and it might actualy work [18:45:45 CET] <Disturbed1> i tried compiling before without patch and was getting error -> " No CUDA capable devices found " , with patch i get this new msg NVENC with Codec H264 Not Available at requested GPU 0... after reading a bit more nvenc5 requires nvidia driver 346.22, but my hardware(s870) only works with 340.xx.... i'm going to retry using nvenc4 since it supports 340.22... the joys of repurposing old legecy [18:45:45 CET] <Disturbed1> hardware... o_O [18:47:14 CET] <BtbN> I don't think the old SDK v4 is still supported. [18:47:26 CET] <BtbN> And "No CUDA capable devices found" happens before any NVENC interaction [18:47:42 CET] <BtbN> it means your GPU simply does not support NVENC at all, no matter which driver is driving it [18:47:57 CET] <BtbN> The fact that it needs a legacy driver alone is enough evidence for that [18:48:12 CET] <BtbN> Only Kepler or newer supports NVENC, and those are still supported [18:57:15 CET] <Disturbed1> hmmm... thanks for you input Btbn.... [19:05:11 CET] <Disturbed1> guess what i need todo now is double check my hardware... i'll report back with what i learn shortly... [19:53:17 CET] <DHE> Disturbed1: I'm pretty sure you'll need a more consumer level GPU. one intended for use with graphics. pure GPGPU processing cards sound like they wouldn't have that feature. [19:57:13 CET] <Bombo> is there qtgmc or something like it in ffmpeg? http://avisynth.nl/index.php/QTGMC [20:00:01 CET] <Disturbed1> cd .. [20:01:23 CET] <Bombo> or this https://www.youtube.com/watch?v=vSyupaW1jY8 TempGaussMC [20:16:41 CET] <Disturbed1> BtbN / DHE : yup you guys right.... i went back to nvenc 4 sdk, used the nvida apps (nvEncoderApp) , failed output said [20:16:46 CET] <Disturbed1> >> GetNumberEncoders() has detected 2 CUDA capable GPU device(s) << [20:16:54 CET] <Disturbed1> [ GPU #0 - < Tesla C870 > has Compute SM 1.0, NVENC Not Available ] [20:17:04 CET] <Disturbed1> [ GPU #1 - < Tesla C870 > has Compute SM 1.0, NVENC Not Available ] [20:18:22 CET] <Disturbed1> sooo... time to try and find another purpose for this piece of hardware..... [21:41:57 CET] <adko> I'm following: https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images -- how can I specify a video duration? The problem being - I specify 1/12 for the input frame rate and I need my video to be 12 seconds long [21:42:08 CET] <adko> -t 12 doesn't seem to have an effect [21:43:12 CET] <c_14> Shouldn't the output duration be automatically determined from the number of images and the framerate? [21:43:35 CET] <adko> c_14: would be nice :D [21:43:50 CET] <c_14> What's your current commandline? [21:44:39 CET] <adko> ffmpeg -r 1/12.480000000000004 -pattern_type glob -i '/tmp/1451852979055159028/1451852979055159028-*.png' -c:v libx264 -r 30 -pix_fmt yuv420p /tmp/1451852979055159028/out.mp4 [21:44:47 CET] <adko> I have also tried -vf fps=30 [21:44:58 CET] <adko> (per note on the trac wiki) [21:45:08 CET] <c_14> use -framerate instead of -r [21:45:31 CET] <adko> (in this case there is only 1 image in /tmp/1451852979055159028/ ) [21:45:44 CET] <adko> It seems to just cut the frame short [21:45:49 CET] <adko> last* frame [21:45:53 CET] <adko> ok will try [21:46:24 CET] <c_14> Also, is the output too short or too long? [21:46:30 CET] <adko> boom -- that seems to work [21:46:47 CET] <adko> the output is too short... I didn't realize -r didn't work [21:46:50 CET] <adko> you da man [21:51:18 CET] <Disturbed1> so.... [21:52:00 CET] <Disturbed1> since i've learned my S870 tesla can NOT be used to transcode..... my next question the the ffmpeg community is this... [21:53:27 CET] <Disturbed1> what GPU should i get and is compatible with nvenc and use multiple GPU in one system.... at the moment i'm looking at Quadro.... [21:53:54 CET] <Disturbed1> on budget . . . lol [21:54:41 CET] <Disturbed1> need to build a system to transcode live mpeg2 ts -> live 264 hls [21:55:39 CET] <c_14> Have you tried just using x264? [21:56:23 CET] <Disturbed1> i have 32 live streams to transcode.... [21:56:52 CET] <c_14> x264 on the faster presets uses very little cpu [21:58:50 CET] <Disturbed1> ka, i will try it out when i get a chance... wanna push as many streams into one server as possible to cut back on the amount of machines required for all of them.... [22:01:44 CET] <Mavrik> Disturbed1, use CPU. [22:01:51 CET] <Mavrik> Buying GPUs is a huge waste of money for that. [22:02:00 CET] <Mavrik> 32 streams should be doable on a 24core Xeon machine. [22:05:15 CET] <Disturbed1> wow... ka.. ummm maybe.... [22:06:01 CET] <Disturbed1> maybe i should explain a little more what i'm trying todo here before i confuse everyone here and think i'm a crazy person... [22:08:59 CET] <Disturbed1> i have 32 mpeg2 ts streams comming in at 20mbps per stream at 1080p60... i need each stream transcoded into 3 streams in 264/hls 1080p24/720p24/480p24... [22:10:51 CET] <Disturbed1> plan to use adaptive bitrate to scale up or down depending on viewers net connection [22:11:19 CET] <Mavrik> Ah. [22:11:24 CET] <Mavrik> And? :) [22:13:03 CET] <adko> c_14: Strangely my video still has a reported framerate of 1/2 [22:13:06 CET] <adko> er.. 1/12 [22:13:19 CET] <adko> Which seems to be messing up later "drawtext" filtering [22:13:30 CET] <Disturbed1> last time i tried to transcode 1 stream into 5 (1080/720/480/360/240) i maxed out the server i was using [22:13:54 CET] <Mavrik> Yeah, you can get like 20 outputs on a 24 core dual socket Xeon [22:13:59 CET] <Mavrik> depending on your speed settings [22:14:16 CET] <Disturbed1> so this is why i'm looking at maybe using gpu power to help cut back on the number of machines required [22:14:24 CET] <c_14> adko: is the drawtext filter after the fps filter? [22:14:25 CET] <Mavrik> So I guess you'll need 8 machines or so [22:14:36 CET] <adko> c_14: yeah it's totally separate commands [22:14:37 CET] <Mavrik> GPUs have terrible P/P for that [22:14:51 CET] <adko> do I need -framerate AND -vf fps=30 ? [22:15:05 CET] <c_14> adko: yes [22:15:15 CET] <adko> k will try thanks [22:15:17 CET] <JEEB> also ASIC encoders usually can handle one or two streams and that's it [22:15:17 CET] <c_14> if you want the output to be in 30fps, yes [22:15:25 CET] <JEEB> while a proper CPU can do much more [22:15:52 CET] <Mavrik> Also if I see correctly, currently nvidia driver freezes if you try to initialize several nvenc sessions [22:16:19 CET] <Disturbed1> ka. thx mavrik... i'll continue doing my home work before i buy anything... thx to ya'll [22:16:34 CET] <adko> c_14: didn't help [22:16:43 CET] <Mavrik> I'm just looking at a machine that's crunching through 11 SD streams at 30% CPU utilization across the board [22:17:47 CET] <c_14> adko: try putting the fps filter directly before the drawtext filter? [22:18:15 CET] <Disturbed1> mavrik: what gear you looking at? (model/make/etc) [22:18:58 CET] <adko> ok [22:20:54 CET] <BtbN> NVENC has a hard limit of 2 encoding sessions per GPU [22:21:06 CET] <BtbN> So for your 32 streams, you'd need 16 Nvidia GPUs. Good luck. [22:21:54 CET] <Disturbed1> lol [22:22:23 CET] <Mavrik> Disturbed1, model name : Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz x 2 [22:22:43 CET] <adko> c_14: I did like this: -vf "[in]fps=30,drawtext...." [22:22:46 CET] <adko> right ? [22:22:48 CET] <Mavrik> About 12GB RAM used [22:22:53 CET] <c_14> without the [in] [22:22:53 CET] <adko> It didn't seem to help [22:22:56 CET] <fritsch> BtbN: vaapi encoding should be able to cope with that [22:22:57 CET] <c_14> but ye [22:23:04 CET] <fritsch> BtbN: "in theory" :-) of course [22:23:08 CET] <adko> Well I have to use [in] and [out] because I have lots of filters here [22:23:22 CET] <adko> (drawtext filters) with quotes and junk [22:23:23 CET] <BtbN> I don't think you'll get much more than 2 parallel streams through VAAPI either [22:23:25 CET] <c_14> you can't have more than one -vf per command [22:23:32 CET] <adko> yeah it's just one vf [22:23:33 CET] <Mavrik> Stuffing 16 GPUs in a chasis is problematic in so many levels [22:23:35 CET] <BtbN> It's another hardwired encoder after all [22:23:49 CET] <fritsch> BtbN: let me find it on the ML - there are some guys also holding a speech in belgium conference soon - about exactly that [22:23:53 CET] <fritsch> let me have a look [22:24:17 CET] <Disturbed1> nice CPU.... lol LGA2011 rocks.... [22:24:36 CET] <adko> I think my biggest issue right now is that my initial video is 1/12th fps instead of 30 fps [22:24:44 CET] <adko> I have an idea.. will try [22:27:14 CET] <Mavrik> Even Cisco and others are moving away form ASICs to branded x86 boxes [22:27:21 CET] <adko> c_14: my bad I had -r and -framerate switched... Sorry.. got lost :D [22:35:59 CET] <adko> Well damn.. that didn't fix my ultimate problem [22:36:26 CET] <adko> c_14: skipping backwards in the video gives me a blank video output (in my player) -- unless I get back to the start of the video [22:36:43 CET] <Zeranoe> Does FFmpeg support adding chapters to a MP4? [22:36:52 CET] <adko> sometimes even skipping forward [23:10:15 CET] <c_14> adko: sounds like not enough keyframes [23:14:09 CET] <c_14> Zeranoe: if the input has chapters they'll be copied, adding maybe if you used an ffmetadata file as second input and mapping the metadata from that to the output [23:14:23 CET] <c_14> (or at least mapping the chapter metadata) [23:14:31 CET] <c_14> Don't know if ffmpeg has another method of adding chapters [23:31:41 CET] <adko> c_14: yep I forced some key frames and I'm good to go now. [23:32:11 CET] <adko> Have some work to do on figuring out when to add key frames so I don't artificially bloat my file. But for now I'm good. Thanks again. [23:32:27 CET] <c_14> you could just lower the gop [00:00:00 CET] --- Mon Jan 4 2016

1 0

ffmpeg-devel.log.20160102
by burek 03 Jan '16

03 Jan '16

[00:32:21 CET] <ubitux> jamrial: damn, wtf is going on [00:32:25 CET] <ubitux> no system error [00:32:52 CET] <ubitux> jamrial: no system error though [00:33:11 CET] <ubitux> like, no disk problem [00:41:10 CET] <ubitux> i'll take a look maybe tmr [00:52:35 CET] <ubitux> jamrial: i'm trashing the ccache cache for now, and upgrading rsync (maybe a sync failure of some sort) [00:52:44 CET] <ubitux> anyway, thx for notifying [02:00:27 CET] <prelude2004c> good day everyone.. can anyone help with vdapu ? I am still having an issue. Here goes... " Running a system with M4000 card "... ffmpeg with vdpau enabled.. i can decode mpeg2video just fine using the GPU but any source with h264 it will not use the card to decode and instead uses CPU's. Can anyone assist with this ? what could i be doing wrong ? [02:00:38 CET] <prelude2004c> i have been for weeks looking for an answer .. can anyone help me with it ? [02:05:21 CET] <J_Darnley> I guess nobody knows [02:19:39 CET] <prelude2004c2> somebody knows.. and i get it's something simple :( [09:31:16 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:b966a403dd80: avcodec/utils: fix AVPacket lifetime in seek_frame_generic [10:19:07 CET] <cone-160> ffmpeg 03Kip Warner 07master:cc4c24208159: avresample: Mark avresample_buffer() as pointer to const [10:19:08 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:d1262262de84: Merge commit 'cc4c24208159200b7aff5b5c313903c7f23fa345' [10:21:00 CET] <cone-160> ffmpeg 03Stefan Pöschel 07master:dbce017913ce: mpegtsenc: add flag to embed an AC-3 ES the DVB way [10:21:01 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:40231a58a0d8: Merge commit 'dbce017913ce04966021a2f72e4f8fae5b4b7190' [10:25:49 CET] <cone-160> ffmpeg 03Janne Grunau 07master:50078c1c8070: libavutil: move FFALIGN macro from common.h to macros.h [10:25:50 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:4cf66a81932a: Merge commit '50078c1c8070dd8d1c329e8117ff30ec72489039' [10:33:22 CET] <cone-160> ffmpeg 03Janne Grunau 07master:64034849dad8: arm64: add cycle counter support [10:33:23 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:af2e6f32156e: Merge commit '64034849dad8410bedbe1def4c533490fb85cc4a' [10:46:37 CET] <cone-160> ffmpeg 03Janne Grunau 07master:5dfe4edad639: x86_64: int32_to_float_fmul_scalar sign extend integer length [10:46:38 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:00e91d06767a: Merge commit '5dfe4edad63971d669ae456b0bc40ef9364cca80' [11:06:34 CET] <cone-160> ffmpeg 03Janne Grunau 07master:e2710e790c09: arm: add a cpu flag for the VFPv2 vector mode [11:06:35 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:e754c8e8caa7: Merge commit 'e2710e790c09e49e86baa58c6063af0097cc8cb0' [11:10:50 CET] <nevcairiel> i hope all this arm stuff works, i have no way to test it :) [11:11:00 CET] <cone-160> ffmpeg 03Janne Grunau 07master:c33c1fa8af2b: arm64: convert dcadsp neon asm from arm [11:11:01 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:de3a33784cb7: Merge commit 'c33c1fa8af2b2e82418a06901b6ad17b3d61b73e' [11:15:08 CET] <cone-160> ffmpeg 03Janne Grunau 07master:705f5e5e155f: arm64: port synth_filter_float_neon from arm [11:15:09 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:10e075c13846: Merge commit '705f5e5e155f6f280a360af220fc5b30cfcee702' [11:21:30 CET] <cone-160> ffmpeg 03Janne Grunau 07master:a0fc780a2093: arm64: int32_to_float_fmul neon asm [11:21:31 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:e97e2588ca74: Merge commit 'a0fc780a2093784e8664f88205ee1b215e109cee' [11:22:01 CET] <cone-160> ffmpeg 03Janne Grunau 07master:90b1b9350c0a: arm: add ff_int32_to_float_fmul_array8_neon [11:22:02 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:e23c3a13e330: Merge commit '90b1b9350c0a97c4065ae9054b83e57f48a0de1f' [11:22:15 CET] <cone-160> ffmpeg 03Andreas Cadhalpun 07master:17776638c392: opus: Fix typo causing overflow in silk_stabilize_lsf [11:22:16 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:92ebe35d571e: Merge commit '17776638c392d104975aba169e17b186490e1d5e' [11:22:26 CET] <cone-160> ffmpeg 03Andreas Cadhalpun 07master:5ea59b1f424f: exr: fix out of bounds read in get_code [11:22:27 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:e40b33a9d79c: Merge commit '5ea59b1f424f0efc7805d837e6fdb80561fb0f3a' [11:22:42 CET] <cone-160> ffmpeg 03Janne Grunau 07master:cc29d96d5a37: arm64: fix inverted register order in transpose_4x4H [11:22:43 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:f00e12e630da: Merge commit 'cc29d96d5a379dbcf2649947d884c202c2a52767' [11:53:45 CET] <durandal_1707> nevcairiel: finished with merges? [11:53:51 CET] <nevcairiel> no [11:54:30 CET] <nevcairiel> but i'm going to get some food after the next one if you want to push something [11:55:53 CET] <cone-160> ffmpeg 03Janne Grunau 07master:711781d7a171: x86: checkasm: check for or handle missing cleanup after MMX instructions [11:55:54 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:69ead86027d0: Merge commit '711781d7a1714ea4eb0217eb1ba04811978c43d1' [11:55:56 CET] <nevcairiel> there [12:01:14 CET] <j-b> atomnuker: all your code is done from scratch (for Daala)? [12:19:30 CET] <cone-160> ffmpeg 03Andreas Cadhalpun 07master:c112be25f782: oggparsedaala: reject too large gpshift [12:19:31 CET] <cone-160> ffmpeg 03Andreas Cadhalpun 07master:753930bc7300: doc: make apidoc output independent of SRC_PATH [12:36:16 CET] <cone-160> ffmpeg 03Janne Grunau 07master:9d218d573f80: checkasm: add float comparison util functions [12:36:17 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:0c7ade547ad8: Merge commit '9d218d573f8088c606d873e80df572582e6773ef' [12:41:13 CET] <cone-160> ffmpeg 03Janne Grunau 07master:e71b747e9dc5: checkasm: add tests for dcadsp [12:41:14 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:d882c0b9f9f1: Merge commit 'e71b747e9dc56cb84f8a06ec8214d5f3bd98bb6d' [12:45:46 CET] <cone-160> ffmpeg 03Janne Grunau 07master:568a4323fbde: checkasm: add synth_filter test [12:45:47 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:eb50a3d4409d: Merge commit '568a4323fbde03665b2b23a98068d02b39121812' [12:50:55 CET] <cone-160> ffmpeg 03Janne Grunau 07master:489e6add4478: checkasm: add fmtconvert tests [12:50:56 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:f299d8d9f283: Merge commit '489e6add4478b0f5717dbf644234c6f3a3baf02c' [12:55:47 CET] <cone-160> ffmpeg 03Alexandra Hájková 07master:85990140e730: dca: Add math helpers. [12:55:48 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:a51c2fcdc15d: Merge commit '85990140e7302d1e7fcc9fc0eea316178c19fe03' [13:09:10 CET] <cone-160> ffmpeg 03Alexandra Hájková 07master:aebf07075f42: dca: change the core to work with integer coefficients. [13:09:11 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:af1238f863fd: Merge commit 'aebf07075f4244caf591a3af71e5872fe314e87b' [13:18:01 CET] <cone-160> ffmpeg 03Alexandra Hájková 07master:2008f7605490: dca: remove unused decode_hf function and quant_d tables [13:18:02 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:d03da3e24020: Merge commit '2008f76054906e9ff6bf744800af0e5a5bfe61be' [13:19:57 CET] <cone-160> ffmpeg 03Diego Biurrun 07master:5049f6b77289: rtpdec_jpeg: Coalesce redundant error checks [13:19:58 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:8a04ddeb4704: Merge commit '5049f6b772891cdf4030a9d572362efc8f7ae97f' [13:23:12 CET] <cone-160> ffmpeg 03Diego Biurrun 07master:69a68593ce56: Remove stray line breaks from avpriv_{report_missing_feature|request_samples} [13:23:13 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:95a2b883e36d: Merge commit '69a68593ce5684409c3c4dd9a901bfd8b16925b1' [13:26:23 CET] <cone-160> ffmpeg 03Janne Grunau 07master:f4f27e4cf101: x86: zero extend the 32-bit length in int32_to_float_fmul_scalar implicitly [13:26:24 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:a9cd11b21295: Merge commit 'f4f27e4cf1013c55b2c7df359ce8d58ee922662c' [13:27:06 CET] <cone-160> ffmpeg 03Janne Grunau 07master:f0f54117c8f2: checkasm: x86: post commit review fixes [13:27:07 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:0eefc758e23e: Merge commit 'f0f54117c8f206e8045d301c2eb975b26e9f263d' [13:28:07 CET] <cone-160> ffmpeg 03Janne Grunau 07master:8563f9887194: x86: use emms after ff_int32_to_float_fmul_scalar_sse [13:28:08 CET] <cone-160> ffmpeg 03Hendrik Leppkes 07master:2214207d0481: Merge commit '8563f9887194b07c972c3475d6b51592d77f73f7' [15:27:21 CET] <prelude2004c> good day everyone.. can anyone help with vdapu ? I am still having an issue. Here goes... " Running a system with M4000 card "... ffmpeg with vdpau enabled.. i can decode mpeg2video just fine using the GPU but any source with h264 it will not use the card to decode and instead uses CPU's. Can anyone assist with this ? what could i be doing wrong ? [17:12:43 CET] <ubitux> h264 decoder doesn't compile anymore with -DTRACE [17:57:23 CET] <cone-553> ffmpeg 03Alexandra Hájková 07master:40d949677335: dca: use defines for subband related constants [17:57:24 CET] <cone-553> ffmpeg 03Hendrik Leppkes 07master:7fe77aa62ea2: Merge commit '40d949677335a564f769823f4afdb7e7a3da8d6b' [18:52:53 CET] <cone-553> ffmpeg 03Paul B Mahol 07master:8bcd1997eadb: avfilter/vf_zoompan: do not free frame we pushed to lavfi [18:53:47 CET] <cone-553> ffmpeg 03Paul B Mahol 07master:7f7a9dd78227: avfilter/avf_showspectrum: store win_size in private context and calculate it only once [18:53:48 CET] <cone-553> ffmpeg 03Paul B Mahol 07master:72280d1c6caa: avfilter: add showspectrumpic filter [18:53:49 CET] <cone-553> ffmpeg 03Paul B Mahol 07master:9b06e7befaa7: avfilter/avf_showspectrum: add fiery color map [18:53:50 CET] <cone-553> ffmpeg 03Paul B Mahol 07master:d35c029cbf3a: avfilter/avf_showspectrum: fix null pointer dereference if allocation fails [18:53:51 CET] <cone-553> ffmpeg 03Paul B Mahol 07master:2b172cb6256f: avfilter/avf_showspectrum: make some helper functions [18:53:52 CET] <cone-553> ffmpeg 03Paul B Mahol 07master:af018d802d5f: avfilter/avf_showspectrum: add 4th and 5th root scaler [19:03:07 CET] <BtbN> Great, just noticed that decoding vp8 via vaapi uses more CPU than plain lavc decoding on the CPU. [19:03:18 CET] <BtbN> Or whatever gst uses for it [19:04:10 CET] <Daemon404> A+ [19:06:26 CET] <rcombs> is it one of those "hybrid" decoders [19:06:33 CET] <BtbN> Nope [19:06:47 CET] <BtbN> Well, at least it's in the main intel driver, can't tell how it's implemented [19:07:08 CET] <rcombs> I thought there were hybrid decoders in the main intel driver [19:07:32 CET] <BtbN> iirc they are all(?) in a second driver, which it chainloads [19:07:52 CET] <rcombs> oh [19:07:54 CET] <rcombs> well that then [19:10:15 CET] <cone-553> ffmpeg 03Hendrik Leppkes 07master:51da00e24cb0: dca: adjust decoding of the XBR extension for integer core decoding [19:10:16 CET] <cone-553> ffmpeg 03Hendrik Leppkes 07master:b95cba7b3c82: avcodec/dca: remove unused float quant table [19:10:17 CET] <cone-553> ffmpeg 03Hendrik Leppkes 07master:957667d19854: avutil/cpu: add missing entry for vfp_vm to av_parse_cpu_caps [19:26:20 CET] <atomnuker> BBB_: RFCv5 is on the ML, all should be fine with it now [19:26:58 CET] <BBB_> famous last words [19:27:41 CET] <BBB_> BtbN: well, vp8 decoding is ridiculousy trivial :D [19:28:17 CET] <BtbN> filling the VAAPI input surface is propably more cpu intensive than decoding it... [19:28:29 CET] <nevcairiel> BBB_: i merged some checkasm changes today which check if a mmx function issues emms, and it complained that plenty vp9 functions should be using emms .. so i told it that its intentional that it doesnt to fix fate .. but I would feel better if you could confirm that for me :) [19:28:34 CET] <fritsch> why did I expect something like that again BtbN [19:28:35 CET] <fritsch> hehe [19:28:53 CET] <BBB_> uhm [19:28:53 CET] <BBB_> wait [19:28:58 CET] <BBB_> nevcairiel: why would anything ever call emms? [19:29:05 CET] <nevcairiel> why wouldnt it [19:29:18 CET] <nevcairiel> how is checkasm to know if your code uses float after mmx [19:29:19 CET] <BBB_> nevcairiel: all video decoders in lavc* rely on the fact that we call emms at the end of avcodec_decode_videoN() [19:29:30 CET] <BBB_> doing emms per function adds crazy unnecessary overhead [19:29:36 CET] <BtbN> Well, it still doesn't use much, it's like 5% CPU usage when decoding it to a fake sink with gst. [19:29:44 CET] <BBB_> I dont think we have any video decoders that use float internally [19:29:47 CET] <BtbN> But decoding with lavc is less than 2% [19:29:52 CET] <nevcairiel> then telling it that its ok this way was right =p [19:29:52 CET] <BBB_> at least none that rely on integer simd [19:29:53 CET] <BBB_> so ... [19:29:57 CET] <BBB_> I think the assumption is ok [19:30:10 CET] <BBB_> but youll have to add that assumption to all video decoder simd functions in checkasm [19:30:15 CET] <BBB_> hevc, h264, etc. [19:30:27 CET] <nevcairiel> the merge added it for h264, we dont have hevc checkasm [19:30:31 CET] <jamrial> atomnuker: i'm not sure about the experimental flag. it's not like with encoders where we risk creating bad files that will forever haunt us [19:30:32 CET] <BBB_> are there ever cases where the simd should call emms itself? [19:30:37 CET] <jamrial> atomnuker: as long as it doesn't crash with valid (and invalid) input, even if the codec in question is not finalized it should be fine [19:30:44 CET] <nevcairiel> some very generic simd functions, i suppose [19:30:52 CET] <BBB_> nevcairiel: Id say that any video codec can have that assumption, if checkasm knows media types [19:30:53 CET] <nevcairiel> stuff used for audio [19:30:57 CET] <BBB_> (I guess it doesnt) [19:31:12 CET] <jamrial> most players will not use a decoder that requires the experimental flag [19:31:24 CET] <BBB> nevcairiel: but when generic stuff is used for video, we should still not call emms [19:31:30 CET] <BBB> i.e. caller, not callee, should issue emms [19:31:33 CET] <BBB> if you see what I mean [19:31:38 CET] <BBB> the emms check seems bogus to me TBH [19:31:40 CET] <BBB> but what do I know [19:31:42 CET] <nevcairiel> that seems painfully easy to forget [19:32:05 CET] <nevcairiel> really just screw mmx if you ask me, but shrug [19:32:11 CET] <BBB> that too [19:32:29 CET] <nevcairiel> i was surprised to see vp9 even had any [19:32:57 CET] <jamrial> Gramner was planning on getting rid of mmx code from x264 since it looks like Intel may be about to deprecate the set [19:33:01 CET] <BBB> well, stuff that acts on 8 pixels& [19:33:16 CET] <nevcairiel> its doubtful they could ever actually remove mmx [19:33:18 CET] <jamrial> seeing how it's slower on Skylake on purpose than previous cpus [19:33:22 CET] <BBB> and mmx is still quite widely used [19:33:24 CET] <nevcairiel> it would break everything [19:34:28 CET] <atomnuker> jamrial: yeah, haven't done much fuzzing on the decoder yet, but it won't crash with the old/broken files I've tried [19:35:48 CET] <atomnuker> AFL will find something, but it's ALF, it always does [19:36:10 CET] <cone-553> ffmpeg 03Michael Niedermayer 07master:a30238621dd0: doc/encoders: Fix application name [19:36:11 CET] <cone-553> ffmpeg 03Michael Niedermayer 07master:cccb0ffccc37: avcodec/put_bits: Always check buffer end before writing [19:39:09 CET] <rcombs> what would "removing MMX" entail [19:39:42 CET] <rcombs> isn't a bunch of the SSE stuff basically extensions of MMX instructions to 128 bits [19:39:46 CET] <nevcairiel> they probably removed some execution hardware on skylake to save die space, thats why its s lightly slower [19:39:48 CET] <Gramner> i don't thunk i'm going to get rid of mmx [19:39:55 CET] <jamrial> freeing opcodes, maybe. also simpler die? [19:40:02 CET] <Gramner> but maybe replace some functions that use instructions that are slow [19:40:46 CET] <nevcairiel> if data sets are too small its probably not going to like using sse instead, huh [19:41:24 CET] <J_Darnley> movq/movd into xmm isn't that bad is it? [19:43:10 CET] <nevcairiel> rcombs: the big difference with sse is that it uses its own dedicated registers, while mmx shares its registers with the fpu [19:43:22 CET] <Gramner> nevcairiel: jannau's checkasm emms patch should only check if emms is used in functions that specify that they should issue emms [19:43:39 CET] <Gramner> so you might have botched the merge [19:43:50 CET] <nevcairiel> the implementation is the other way around however [19:44:00 CET] <nevcairiel> it specifically checks that on every function unless told otherwise [19:44:55 CET] <rcombs> oh huh, so the instructions have the same mnemonics but are actually totally different? [19:45:02 CET] <Gramner> doesn't it only check for emms in functions that use declare_new_emms()? [19:45:26 CET] <nevcairiel> if that would be true, then simply merging shouldnt have caused the old vp9 tests to start saysing "didnt issue emms"? [19:45:46 CET] <nevcairiel> because they all did :d [19:46:23 CET] <Gramner> the merge commit itself did that [19:46:30 CET] <Gramner> https://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=tests/checkasm/vp9dsp.c… [19:46:43 CET] <nevcairiel> apparently the reason for this is that it would otherwise prevent testing floating point code [19:47:00 CET] <nevcairiel> well yes, i added those [19:47:04 CET] <nevcairiel> without those changes, it fails [19:47:33 CET] <Gramner> huh, that's interesting. what failed? [19:47:55 CET] <nevcairiel> all the vp9 tests in those blocks [19:47:55 CET] <Gramner> I don't think that patch should change the behavior of old stuff [19:48:00 CET] <nevcairiel> but it did [19:48:21 CET] <Gramner> then there's probably a bug somewhere [19:48:42 CET] <nevcairiel> same reason the h264 pred tests got the call changed to declare_func_emms [19:49:04 CET] <nevcairiel> those functions clearly dont issue an emms [19:50:38 CET] <Gramner> oh, I think the code is backwards [19:52:33 CET] <Gramner> I'll poke jannau about it [20:04:36 CET] <cone-553> ffmpeg 03Andreas Cadhalpun 07master:2e752c7de9df: ffmdec: change type of state and id to unsigned [20:29:21 CET] <cone-553> ffmpeg 03James Almer 07master:78129978f02f: configure: bump copyright year to 2016 [20:29:25 CET] <jamrial> :D [20:31:59 CET] <durandal_1707> nooooo!!! [20:50:27 CET] <atomnuker> durandal_1707: would it be possible to add a scale to showspectrumpic? [20:50:57 CET] <atomnuker> (e.g. duration in seconds vs amplitude in db) [21:10:07 CET] <durandal_1707> atomnuker: as one in sox default? [21:11:57 CET] <durandal_1707> the legend [21:12:54 CET] <atomnuker> yeah [21:13:58 CET] <atomnuker> I'm not sure what functions are available to draw text, but you could probably get away by using ff_draw_pc_font (fixed scale) [21:22:44 CET] <durandal_1707> the font is bit bigger for my taste, perhaps using sox font is better looking imho [21:25:07 CET] <atomnuker> well, that's what I know is currently in FFmpeg and doesn't require any dependency [21:25:41 CET] <durandal_1707> yes, font is in lavu [21:27:43 CET] <cone-553> ffmpeg 03Paul B Mahol 07release/2.7:784506c2b5c6: avfilter/vf_zoompan: do not free frame we pushed to lavfi [21:27:44 CET] <cone-553> ffmpeg 03Paul B Mahol 07release/2.8:6a1bf98b3af1: avfilter/vf_zoompan: do not free frame we pushed to lavfi [23:21:23 CET] <durandal_1707> This is gonna hurt [23:22:24 CET] <kierank> durandal_1707: what is? [23:25:04 CET] <durandal_1707> kierank: doing text/legend for showspectrumpic [23:25:47 CET] <atomnuker> yeah, it will [23:26:04 CET] <atomnuker> extreme resolutions tend to do that [23:26:40 CET] <atomnuker> you can't expect proper labels when users can input something like 10000x10 [23:28:37 CET] <j-b> m [23:29:55 CET] <ubitux> nice ffplay with sdl2 [23:45:16 CET] <durandal_1707> does it use opengl? [00:00:00 CET] --- Sun Jan 3 2016

1 0

ffmpeg.log.20160102
by burek 03 Jan '16

03 Jan '16

[00:14:10 CET] <gadgaholic> I am trying to decode an Audible file, but keep getting an error [00:14:21 CET] <gadgaholic> "Option activation_bytes not found." [00:14:37 CET] <gadgaholic> http://pastie.org/10664686 [00:14:46 CET] <gadgaholic> I have tried 2.8.4 and the HEAD [00:23:33 CET] <pinPoint> so what is this CineForm HD thing that just recently happened? [00:23:45 CET] <pinPoint> into ffmpeg... reversesd CFHD [00:29:37 CET] <JEEB> yes, implementation for decoding based on the so-called specification (never enough to implement if coming from SMPTE), and reverse engineering the main implemenation and having samples at hand [00:30:13 CET] <pinPoint> is CFHD even worth considering? [00:30:29 CET] <pinPoint> when things like h264 work so well [00:32:24 CET] <JEEB> that question would make sense if there was an encoder in the works [00:32:31 CET] <JEEB> but no, the support is just decoding [00:32:35 CET] <JEEB> for already existing files :P [00:32:43 CET] <JEEB> which pretty much always makes sense [00:32:56 CET] <JEEB> which is why people make decoders for game formats or other obscure'ish stuff [00:33:17 CET] <JEEB> but yeah, in this case it makes it simpler to deal with clips that came out of recent gopro cameras [00:34:19 CET] <pinPoint> but vlc plays them back fine no? [00:35:31 CET] <JEEB> uhh [00:35:45 CET] <JEEB> if it's H.264, sure. if it's CFHD, nope [00:36:11 CET] <JEEB> because yunno, VLC depends on libavcodec for most if not all of its decoding (it has interfaces to a very limited amount of non-libavcodec decoders) [00:36:54 CET] <pinPoint> i see [02:00:21 CET] <prelude2004c> good day everyone.. can anyone help with vdapu ? I am still having an issue. Here goes... " Running a system with M4000 card "... ffmpeg with vdpau enabled.. i can decode mpeg2video just fine using the GPU but any source with h264 it will not use the card to decode and instead uses CPU's. Can anyone assist with this ? what could i be doing wrong ? [03:04:25 CET] <xintox> furq: any idea where i can one on the cheap in US? [03:15:13 CET] <_Vi> Is there some FFmpeg's container format that support all simply all codecs supported by FFmpeg? Closest things I know are nut and matroska, but the former can't save opus and the latter can't save rgb24 rawvideo. [03:17:07 CET] <_Vi> I want `ffmpeg ... -f magicalcontainer - | ffmpeg -f magicalcontainer -i -` chain to always succeed and pass all the data (subtitles, attachments, tracks, tags) verbatim. [03:21:35 CET] <klaxa> matroska and nut are pretty much the most flexible containers available [03:21:37 CET] <klaxa> i don't think there are any containers supporting more codecs [03:34:16 CET] <_6U54N0_> this library is a worse [03:34:24 CET] <_Vi> Is there some container internal to FFmpeg where all codecs get available automatically as soon as they are implemented in FFmpeg? [03:34:35 CET] <_6U54N0_> the acc decoder not work [03:35:54 CET] <_Vi> Something like if serialize all AVFrames and other things with Protobuf. [03:37:28 CET] <TD-Linux> _Vi, no, container mapping is generally not that simple [03:37:59 CET] <TD-Linux> (also matroska has its own protobuf like thing called EBML) [03:57:28 CET] <furq> xintox: if you need unmetered 1G then no idea [03:57:51 CET] <furq> i only really pay attention to budget server hosts [04:05:00 CET] <furq> generally if you see a cheap "unmetered 1gbit" offer, especially on a vps, it's either not really unmetered or it's not really 1G [04:05:26 CET] <furq> obviously it'll be shared on a vps but i've heard of companies offering that and then capping the port speed to 50M [04:06:42 CET] <prelude2004c> good day everyone.. can anyone help with vdapu ? I am still having an issue. Here goes... " Running a system with M4000 card "... ffmpeg with vdpau enabled.. i can decode mpeg2video just fine using the GPU but any source with h264 it will not use the card to decode and instead uses CPU's. Can anyone assist with this ? what could i be doing wrong ? [04:27:43 CET] <JodaZ> furq, gotta go to ovh, they gots the real stuff... [07:10:22 CET] <xavii> i've got a ffserver running, feed is fed by ffmpeg grabbing from a UDP source. I can view the video from ffserver as avi. The issue is that when i press play, the video starts fine. When i press stop, and then press play again, the video starts from the beginning of what appears to be cached video (probably something to do with timeshifting), why doesnt it play from the current time? I've tried smplayer and vlc. [10:03:48 CET] <xintox> hey all. i'm trying to manager a bunch off ffmpeg commands, occasionally one will die which requires me to restart all the others. Is there anything that makes this management easier? [10:22:12 CET] <Dark-knight> hey guys got a question for you [10:23:39 CET] <Dark-knight> c_14 and relaxed remember me right? [10:24:28 CET] <Dark-knight> I was wondering, can I use ffmpeg's streaming ability's to stream a video onto someone else's computer [10:24:31 CET] <Dark-knight> ? [10:25:11 CET] <Dark-knight> like I don't want to do screen sharing, I just want to stream a video directly to their computer. [10:25:32 CET] <Dark-knight> could ffmpeg do that? [10:25:38 CET] <Dark-knight> if not, what could? [10:26:01 CET] <Betablocker> you could try with google hangout [10:26:43 CET] <Dark-knight> or maybe VLC? [10:27:01 CET] <Dark-knight> he is across the country [10:27:30 CET] <furq> you can use HLS or DASH if you have a webserver running locally [10:28:19 CET] <Dark-knight> I can't just create a tunnel? [10:29:39 CET] <furq> a tunnel to what [10:29:40 CET] <Betablocker> https://trac.ffmpeg.org/wiki/StreamingGuide [10:33:44 CET] <xintox> Dark-knight: what's the source of your stream? [10:34:01 CET] <Dark-knight> ok just read that. I'm currently to tired for any of that to make sense [10:34:27 CET] <Dark-knight> I want to stream a video I have on my computer to a friends computer across the country [10:34:54 CET] <Dark-knight> like creating a direct tunnel or something [10:35:36 CET] <Dark-knight> I don't care about watching it, I just want him to be able to watch it [10:50:16 CET] <xintox> Dark-knight: you need a cheap web server. [10:50:30 CET] <xintox> then you can stream it. if you give me the source stream I can tell you how to stream it [10:52:01 CET] <furq> "cheap"? [10:53:46 CET] <xintox> you can get a cheap vps that should handle streaming fine. [10:53:50 CET] <xintox> i have a 99 cent one [10:53:58 CET] <xintox> i just saw one today for $12/year [10:54:03 CET] <furq> what difference does a server make if he's streaming to one person [10:54:26 CET] <xintox> its easier [10:54:33 CET] <xintox> or don't do it. i don't care [11:03:27 CET] <furq> Dark-knight: you can set up an ad hoc rtsp server with VLC [11:03:34 CET] <furq> it sounds like that's the closest match to what you want [11:03:57 CET] <Polarbear541> Hi, I'm currently using ffmpeg to automatically record audio from a sound card using Pulse. But the output files seem to skip throughout and errors relating to a 'non-monotonous DTS timestamp' are appearing in the log. See command and output here: http://pastebin.com/GhfadNpG Any ideas? [14:29:51 CET] <aiena> how do i copy audio stream from a seperate file and video stream from a seperate file and merge them together [14:30:27 CET] <JEEB> ffmpeg -i video -i audio -map 0:v -map 1:a -c copy output [14:30:39 CET] <JEEB> map stops the automatic stream selection and picks what you mention [14:31:09 CET] <JEEB> so in that example it picks the video stream(s) from the first input (0th) and audio stream(s) from the second input (1th) [14:31:31 CET] <JEEB> you can also add selectors after the v and a in case you have more than one audio or video track in those inputs [14:31:49 CET] <JEEB> like 0:a:0 selecting the first audio track of the first input file [14:36:34 CET] <aiena> JEEB: OK it seems to identify the streams properly but it churns out '[NULL @ 0xb09820] Unable to find a suitable output format for 'output.mp4'' at the end [14:36:34 CET] <aiena> [14:37:49 CET] <aiena> JEEB: http://paste.opensuse.org/view/raw/08c96f53 is term output first line is terminal command [14:37:56 CET] <aiena> I ran [14:39:09 CET] <aiena> trying yours one sec [14:40:35 CET] <aiena> yours also gives '[NULL @ 0x6d67e0] Unable to find a suitable output format for 'output' [14:41:01 CET] <aiena> here 'video' and 'audio are the file paths themselves right [14:41:12 CET] <furq> output.mp4 [14:41:12 CET] <furq> and yes [14:41:39 CET] <aiena> furq: if i do that I get [NULL @ 0x1c627e0] Unable to find a suitable output format for 'output.mp4' [14:42:04 CET] <aiena> and below that output.mp4: Invalid argument [14:42:20 CET] <furq> --enable-muxer='flac,gif,image2,image2pipe,matroska,matroska_audio,null,webm' [14:42:29 CET] <furq> that doesn't appear to contain mp4 [14:43:00 CET] <aiena> hmm [14:43:06 CET] <aiena> ok will get another ffmpeg build then [14:43:16 CET] <furq> is that a suse package [14:43:38 CET] <aiena> yes [14:43:56 CET] <furq> i guess this is why i don't use suse [14:44:11 CET] <aiena> never had problems with it before probably because the shift to Leap mixes entreprise with the regular [14:44:26 CET] <aiena> anyway suse has packaman which builds a different ffmpeg [14:44:28 CET] <aiena> let me try that [14:44:31 CET] <furq> i can only assume they have some insane license requirements they're trying to meet [14:44:40 CET] <furq> which aren't met by --enable-gpl [14:48:16 CET] <aiena> packamn repos contain all the other vlc-codecs etc [14:48:28 CET] <aiena> otherwise i am game for building ffmpeg from source too [14:48:38 CET] <furq> http://johnvansickle.com/ffmpeg/ [14:48:44 CET] <JEEB> well for stream copy you don't need any special configuration flags either :P [14:48:44 CET] <furq> you can just grab that if the other package doesn't work out [14:49:10 CET] <JEEB> but sure, there are static binaries around as well [14:49:46 CET] <furq> i'm genuinely baffled by that packaging decision [14:49:57 CET] <aiena> yeah never had it before [14:50:03 CET] <aiena> probably a side effect of Leap [14:50:15 CET] <furq> i can only assume it's because it's "enterprise" and they're ultra paranoid about getting sued by MPEG-LA [14:50:16 CET] <JEEB> I would guess it's a very specific binary, and I'm surprised opensuse packages it ata ll [14:50:17 CET] <aiena> i an not going back to buntu though [14:50:33 CET] <furq> or about end users getting sued, rather [14:50:34 CET] <JEEB> furq: you won't get sued but you want to make sure you don't have to license anything [14:50:43 CET] <furq> well you know what i mean [14:50:47 CET] <JEEB> and no, the end users wouldn't get sued [14:50:51 CET] <JEEB> just you since you're distroing it [14:50:59 CET] <JEEB> (the binaries) [14:51:07 CET] <aiena> exit [14:51:14 CET] <JEEB> I think opensuse was similar with VLC? [14:51:16 CET] <aiena> sorryterm commmand [14:51:18 CET] <furq> i meant if the end user included suse in a commercial product [14:51:22 CET] <JEEB> it only had stuff like libvpx,-theora etc [14:51:35 CET] <furq> i assume they'd be liable then, although i'm obviously not a lawyer [14:51:47 CET] <JEEB> if you distribute the binaries, sure [14:51:52 CET] <aiena> yes PackMan binaries work [14:51:59 CET] <aiena> so need to get static builds [14:52:07 CET] <aiena> it muxed [14:52:09 CET] <aiena> thank you [14:52:35 CET] <furq> that's a shame [14:52:39 CET] <JEEB> anyways, I don't dislike limited distros, it just means that I can ignore any FFmpeg packaged if at all (Fedora f.ex. doesn't package FFmpeg et al at all) [14:52:43 CET] <furq> now i don't get to say "use debian {;-)" [14:53:38 CET] <aiena> JEEB: probably those weird playback issues were because of suse's ffmpeg binary too which i reported earlier where mplayer cold play the audio [14:54:14 CET] <aiena> furq: not going to debian [14:54:18 CET] <aiena> back [14:54:26 CET] <aiena> will build the rest [14:54:26 CET] <furq> annoyingly if i was to recommend an OS on the basis of how good the ffmpeg packaging is, it would grudgingly be freeBSD [14:54:39 CET] <aiena> if need be [14:54:46 CET] <aiena> hmm never used BSD [14:54:54 CET] <furq> i'm not actually recommending freeBSD [14:54:54 CET] <JEEB> hah, reminds me of FreeBSD building x264 without asm enabled [14:54:55 CET] <IntelRNG> BSD is cool. [14:54:56 CET] <aiena> I think security wise its loads better [14:55:14 CET] <aiena> but kernel is different dont know if linux apps will compile on it [14:55:16 CET] <furq> occasionally ports+pkgng gets it perfect [14:55:16 CET] <JEEB> also I think gentoo might have for whatever reason disabled asm for x264 as well [14:55:25 CET] <furq> ffmpeg is one shining example of that [14:55:28 CET] <JEEB> (I think for 32bit) [14:55:32 CET] <furq> i can't think of any others right now but they probably exist! [14:55:53 CET] <IntelRNG> aiena: FreeBSD and even OpenBSD have Linux compatibility layers in a form or another. But people prefers to run natively. [14:55:56 CET] <JEEB> and then for a while we had folk coming to #x264 saying it's slow as molasses [14:56:25 CET] <JEEB> I /think/ someone beat some sense into those distros but I have no idea since I don't use either [14:56:25 CET] <furq> aiena: most linux software doesn't make use of linux-specific features [14:56:39 CET] <furq> and even those that do can run under compat layers with varying levels of success [14:56:50 CET] <c_14> Dark-knight: you can stream directly over udp or tcp (you might have to open some firewalls though, and you'll need the IP address of your friend or he'll need yours) [14:56:55 CET] <aiena> ok [14:59:31 CET] <furq> JEEB: i'm pretty sure ffmpeg on freebsd has asm enabled now [14:59:39 CET] <furq> it certainly does if you build it from ports [14:59:57 CET] <JEEB> I think it might have been a brainfart with only (lib)x264 [15:00:05 CET] <JEEB> and possibly only on 32bit, not sure though [15:27:16 CET] <prelude2004c> good day everyone.. can anyone help with vdapu ? I am still having an issue. Here goes... " Running a system with M4000 card "... ffmpeg with vdpau enabled.. i can decode mpeg2video just fine using the GPU but any source with h264 it will not use the card to decode and instead uses CPU's. Can anyone assist with this ? what could i be doing wrong ? [15:33:01 CET] <aiena1> furq: but it was good you helped me identify the ffmpeg problem. Lots of other apps depend on it so it was really messing up other apps too [16:12:52 CET] <volar> hi ql [16:12:57 CET] <volar> hi all [16:13:13 CET] <volar> happy coding or the new year [17:45:49 CET] <micechal> does ffmpeg feature any kind of batch processing capabilities by itself? [17:46:26 CET] <micechal> that is multiple input files into multiple corresponding output files at the same time [17:54:16 CET] <ValdikSS> Hello guys. I can't understand how to properly re-encode vfr video with ffmpeg [17:54:22 CET] <ValdikSS> I have the following video: http://b.1339.cf/rkszxnz.mkv [17:55:16 CET] <ValdikSS> The first part of it is 24000/1001 fps and the opening is 30000/1001 fps. If I use ffmpeg -i file.mkv -vsync 0 it encodes without any warnings or notices, the video and audio is synced but the opening is not smooth [18:01:22 CET] <DHE> micechal: it's not a bulk processing tool. it supports multiple inputs but usually in the context of mixing content from several sources. most people have shell scripts do the legwork there [18:05:17 CET] <micechal> DHE: I see. I'm aware of the shell scripts. the problem I'm facing though is that I've only got ffmpeg cli without the shell, turns out I'll have to do every file by hand [18:31:27 CET] <ValdikSS> michaelni: try GNU parallel [18:43:24 CET] <micechal> is the libopus encoder in ffmpeg deterministic? [18:44:01 CET] <micechal> I encoded the same file twice with the same settings and the checksums do not match [18:44:31 CET] <micechal> could it be because of some date-related metadata? [18:44:50 CET] <c_14> try adding -fflags +bitexact [18:45:24 CET] <micechal> c_14: okay [18:47:27 CET] <micechal> still doesn't match [18:48:06 CET] <micechal> I now have four files encoded with the same settings with different checksums [18:48:30 CET] <c_14> works for me [18:49:21 CET] <micechal> c_14: could it be because I'm encoding on ARM? [18:49:32 CET] <micechal> I'll post the log in a moment [18:50:10 CET] <c_14> afaik, it shouldn't [18:56:01 CET] <micechal> https://bpaste.net/show/471719769288 [18:58:17 CET] <micechal> I don't know what other options the ffmpeg build I'm using might be appending or prepending implicitely [18:58:46 CET] <c_14> micechal: the fflags is an output option [18:58:48 CET] <c_14> not an input option [18:59:07 CET] <micechal> oh, let me try again then [19:01:08 CET] <micechal> like "ffmpeg -i input.flac -fflags +bitexact output.opus"? [19:01:29 CET] <c_14> yes [19:04:17 CET] <micechal> c_14: now after three encodes, the checksum stays the same [19:04:21 CET] <micechal> thank you [19:04:49 CET] <micechal> but does it also create different files for you if you don't specify that flag? [19:04:56 CET] <c_14> hmm? [19:05:40 CET] <micechal> I mean, can you see the same behavior as me when encoding without the bitexact flag [19:06:13 CET] <micechal> ie. the files produced are different each time [19:06:19 CET] <c_14> ye [19:06:56 CET] <micechal> I wonder if the standalone opusenc from opus-tools does that as well [19:07:42 CET] <micechal> can't check that because there are no builds for Android I'm aware of, I'll have to check that the next time I'm on the pc [19:08:38 CET] <micechal> do you think it has any impact on the quality of encodes? if so, which would give better quality? the bitexact ones? [19:08:47 CET] <kepstin> The thing that causes changes without bitexact might just be the selection of the stream number in the ogg muxer [19:08:57 CET] <kepstin> by default it's random so concatenating is more likely to work, iirc [19:09:36 CET] <kepstin> in general, you should prefer non-bitexact unless you actually need identical files [19:10:01 CET] <kepstin> not because of any quality change necessarily tho. [19:10:54 CET] <micechal> I see. But it doesn't harm to use bitexact? [19:11:22 CET] <kepstin> (although it can indirectly in some cases - e.g. in x264 encoding, you have to disable threads to make output bitexact, which means it's slower but also slightly higher quality) [19:12:04 CET] <kepstin> I think in some cases, bitexact can also cause it to use slower, more precise math functions - don't know exactly which codecs do that or not. [19:12:22 CET] <kepstin> (no real quality difference, it's just slower) [19:13:03 CET] <kepstin> most of the time, bitexact just does silly things like not put the encoding time into file metadata [19:13:13 CET] <kepstin> well, not silly, but simple. [21:01:50 CET] <TD-Linux> libopus itself is deterministic. so it is indeed just container stuff that would be changing. [21:10:33 CET] <zhuki> hi guys [21:10:40 CET] <zhuki> can comeone please help me with a complexx_filter [21:10:43 CET] <zhuki> for ffmpeg [21:11:02 CET] <durandal_1707> what exactly? [21:11:40 CET] <zhuki> i have this [21:11:42 CET] <zhuki> ffmpeg -i http://domain.com/stream.mp4 -i /root/overlay.png -filter_complex "[0:v]drawtext=fontfile=/usr/share/fonts/truetype/msttcorefonts/Arial.ttf:textfile=/root/ontvtext.txt:reload=1:fontcolor=white@1.0:fontsize=16:x=w-(tw+w)/25*mod(t\,25):y=h-line_h-20:enable=gt(mod(t\,25)\,0)[text]; [text][1:v]overlay[filtered]" -map "[filtered]" -map 0:a -codec:v libx264 -preset ultrafast -codec:a copy -f flv rtmp://publishpanel:8001/input/strea [21:11:53 CET] <zhuki> there is an image and drawtext [21:12:26 CET] <zhuki> i made it so the image is an overlay the same size of the video, and it contains the channel logo as well as a bar for text background [21:12:38 CET] <zhuki> however the text seems to appear behind the image overaly [21:12:56 CET] <zhuki> and is hidden by this line that is supposed to act as a background for the text [21:13:02 CET] <zhuki> so I ned the text to be on top [21:13:06 CET] <zhuki> need* [21:16:45 CET] <zhuki> any ideas? [21:24:36 CET] <zhuki> aaaaaa [21:24:39 CET] <zhuki> finally I did it [21:24:43 CET] <zhuki> i just changed th order [21:24:46 CET] <durandal_1707> zhuki: change order of text and video for overlay filter [21:24:57 CET] <zhuki> yes [21:25:00 CET] Last message repeated 1 time(s). [21:25:05 CET] <zhuki> took me some time to understand how it works [21:25:10 CET] <zhuki> never used ffmpeg before [00:00:00 CET] --- Sun Jan 3 2016

1 0

ffmpeg-devel.log.20160101
by burek 02 Jan '16

02 Jan '16

[00:20:46 CET] <kierank> TD-Linux: not really [00:27:54 CET] <ubitux> damn that mats answering 6x its own mail [00:28:41 CET] <nevcairiel> i was hoping that he would cut that out after he was called out on that being annoying, but i should've known better [00:31:03 CET] <wm4> wth is libi264 [00:31:15 CET] <nevcairiel> just a random name that guy choose for his vaapi encoder [00:31:47 CET] <nevcairiel> that patch is full of code problems as it is, not to mention that its apparently extremely messy to use vaapi [00:34:05 CET] <Daemon404> ubitux, i wake up every day and go 'wow so man posts on ffmpeg-devel!', but it's mostly just 2 people replying [00:34:06 CET] <J_Darnley> Why has linking become so slow on (my) windows? [00:34:19 CET] <Daemon404> s/man/many/ [00:34:48 CET] <nevcairiel> linking has always been relatively slow, but no reason for it to get slower [00:35:49 CET] <J_Darnley> Perhaps my drive needs defragging [00:36:06 CET] <nevcairiel> i have all my code on SSDs these days, that helps certainly [00:37:03 CET] <wm4> Daemon404: it's like most mails are about minor math refactorings and qt palette something [00:37:18 CET] <Daemon404> wm4, and makign 1 call to log2 faster [00:37:31 CET] <Daemon404> it's like im reliving post-fork diego mails [00:38:30 CET] <J_Darnley> 34% fragmented accoriding to windows' own tool [00:38:51 CET] <nevcairiel> how can someone really care that much about a hundred year old crappy quicktime animations [00:39:58 CET] <J_Darnley> If ffmpeg is supposed to be the goto library for video decoding it is good that someone cares. [00:40:21 CET] <nevcairiel> I would rather someone else cares [00:40:34 CET] <wm4> hm, people stopped blowing up money outside, time to go to bed [00:40:43 CET] <nevcairiel> its still noisy here [00:41:02 CET] <J_Darnley> It sounded like good flak/artillery rounds here [00:41:29 CET] <J_Darnley> pop-pop-pop at launch; boom-boom-boom a little later [00:43:07 CET] <J_Darnley> OMG! Inline assembly in that libi264 patch! [00:43:23 CET] <wm4> wat [00:43:41 CET] <TD-Linux> kierank, well it's not weird if they want to compete with CinemaDNG, but I thought they wanted to be an adobe intermediate [00:43:45 CET] <nevcairiel> yeah i saw that too [00:43:53 CET] <nevcairiel> weird memcpy optimization it looks like [00:44:18 CET] <wm4> hm is this really new code, or copy&pasted from somewhere [00:44:26 CET] <kierank> TD-Linux: there are cameras that record into cineform [00:48:54 CET] <fritsch> https://github.com/dicroce/vakit/blob/master/source/vah264_encoder.cpp <- parts from here? [00:49:37 CET] <fritsch> https://github.com/gbeauchesne/libva/blob/master/test/encode/avcenc.c <- wait, it's here [00:49:59 CET] <llogan> i should auto "mark mail as read" from a certain two from addresses [00:50:00 CET] <fritsch> funny [00:50:41 CET] <nevcairiel> its ugly as fuck code in any case, intel surely doesnt want vaapi to be used for encoding [00:50:54 CET] <wm4> aren't you supposed to use qsv? [00:51:04 CET] Action: wm4 is confused about all this duplication [00:51:05 CET] <fritsch> it seems it is based on the encoding example by the vaapi devs [00:51:28 CET] <nevcairiel> wm4: intel sure isnt making it easy to use qsv on linux, you need a bunch of hacks and patch your kernel [00:51:31 CET] <fritsch> if it was after intel: you should all use libyami [00:51:32 CET] <fritsch> :-) [00:52:15 CET] <wm4> so what's wrong with using libyami for encoding? [00:53:22 CET] <kierank> 2016: year of the many ways to hardware encode [00:53:35 CET] <nevcairiel> if only one of them didnt suck [00:53:38 CET] <fritsch> wm4: libyami itself? [00:53:39 CET] <fritsch> :-) [00:53:53 CET] <fritsch> BtbN looked into it lately and nearly fell of his chair ... [00:53:56 CET] <nevcairiel> at least nvenc seems to work rather painlessly [00:54:02 CET] <nevcairiel> but all intel methods seem to suck [00:54:05 CET] <fritsch> but yeah, as it uses vaapi stuff itself it can only be ugly [00:55:30 CET] <wm4> kierank: well, on Linux there's at _least_ half a dozen ways to hardware _decode_ too [00:55:44 CET] <wm4> because every vendors needs his own API [00:56:27 CET] <nevcairiel> well of course, linux lacks a strong force to provide a central API [00:57:32 CET] <fritsch> wm4: kodi has openmax, amlogic, mmal, vaapi, vdpau and I am sure I missed something [00:57:40 CET] <fritsch> ah we had xvba once [00:59:56 CET] <wm4> mediacodec maybe? [01:00:28 CET] <wm4> there's also v4l (not sure if anyone even uses that?) [01:00:39 CET] <nevcairiel> that can hardware decoder as well? [01:00:54 CET] <nevcairiel> -r [01:01:05 CET] <nevcairiel> must be hip to offer an API for that [01:01:21 CET] <Daemon404> [23:44] <+wm4> hm is this really new code, or copy&pasted from somewhere <-- the sender and author are two different people from two different companies [01:01:24 CET] <Daemon404> so maybe [01:01:35 CET] <nevcairiel> yeah that was weird [01:01:46 CET] <wm4> nevcairiel: AFAIK yes, it can encode and decode [01:01:57 CET] <nevcairiel> which probably means we wont get much improvements on the patch =p [01:03:06 CET] <fritsch> wm4: i forgot IMX [01:03:21 CET] <fritsch> the code sent there is vaapi encoder demo code + ffmpeg adjustments [01:03:23 CET] <fritsch> nothing else [01:03:43 CET] <nevcairiel> Admittedly even on Windows there are vendor specific APIs, but they are generally just wrappers around DXVA2 and offer only very little advantage if any, and I only have them for legacy reasons [01:03:59 CET] <fritsch> but you have DXVA [01:04:13 CET] <fritsch> currently on android we enforce: mediacodec only [01:04:28 CET] <fritsch> every vendor that contacts us: hey get back libstagefright is told: do it platform conform [01:04:43 CET] <fritsch> there are at least three "vendor specific android api hacks" arround [01:04:44 CET] <nevcairiel> doesnt android have openmax [01:04:55 CET] <fritsch> no idea - no vendor for now had that [01:05:00 CET] <fritsch> mediacodec is the way to go [01:05:31 CET] <nevcairiel> All I know about stagefright is that the ffmpeg libstagefright decoder is terrible crap [01:05:31 CET] <wm4> wasn't it that android had openmax, but for root only? [01:05:54 CET] <nevcairiel> apparently stagefright abstracts OMX [01:05:59 CET] <nevcairiel> and mediacodec on top of that [01:06:01 CET] <nevcairiel> or something :D [01:06:19 CET] <fritsch> stagefright on android also was terrible crap [01:06:20 CET] <fritsch> :p [01:06:47 CET] <fritsch> making a good wrapper for a shitty lib is great art [01:06:55 CET] <fritsch> one could wrap libyami again :-) [01:07:12 CET] <nevcairiel> well i've been told by its author that its even worse than that [01:07:19 CET] <nevcairiel> and should've never been submitted [01:07:28 CET] <nevcairiel> but someone found some old PoC branch and just send it :D [01:08:22 CET] <atomnuker> doesn't stagefright actually depend on some ffmpeg stuff? [01:09:02 CET] <nevcairiel> its all sorts of circular, it can abstract a software decoder as well if it wants to, which m ight be ffmpeg [01:33:40 CET] <cone-396> ffmpeg 03Michael Niedermayer 07master:48985576b11a: avcodec/ffv1dec: Support AV_PIX_FMT_YA8 [01:33:41 CET] <cone-396> ffmpeg 03Michael Niedermayer 07master:3843e52cb415: avcodec/ffv1enc: Support AV_PIX_FMT_YA8 [01:56:15 CET] <Compn> lol @ k&r comments on kierank wip patch :D [01:56:52 CET] <J_Darnley> (sorry, I had to) [02:01:57 CET] <kierank> Meh [02:02:05 CET] <kierank> I'll fix it later [02:07:28 CET] <J_Darnley> FUCKMINTTYANDITLOSINGTHEFUCKINGCURSOR [02:37:09 CET] <J_Darnley> kierank: does avdev already have the fate samples somewhere? [02:38:15 CET] <kierank> usr/share/fate possibly [02:38:31 CET] <kierank> seems not [02:41:08 CET] <J_Darnley> Shall I fetch them? [02:41:25 CET] <J_Darnley> Should I fetch them? [02:41:31 CET] <philipl> So, all we need is BtbN's yami encoder and we'll have three ways to use the same hardware to do the same thing? [02:41:46 CET] <cone-396> ffmpeg 03Lou Logan 07master:b47111b6579f: doc/filters: add showwavespic colorize example [02:50:38 CET] <kierank> J_Darnley: yes [02:53:40 CET] <J_Darnley> I'll put them in my home directory and you can copy/move them if you want. [03:01:51 CET] <kierank> ok [03:07:03 CET] <J_Darnley> Why did I assume there was a matching scatter to the gather instruction? [03:09:17 CET] <jamrial> because there is? [03:11:15 CET] <J_Darnley> are you sure? are you sure it isn't avx512? [03:31:12 CET] <jamrial> mmh, you're right [03:57:25 CET] <BtbN> philipl, unless libyami drasticaly improves, I'm not going to send it in for merging. [03:57:29 CET] <BtbN> It's horrible [04:05:56 CET] <J_Darnley> kierank: They're in /home/jdarnley/fate-samples/ [04:06:06 CET] <J_Darnley> and with that I'm going to bed. [04:06:27 CET] <J_Darnley> Good night all and happy new year. [05:16:40 CET] <kierank> lol at that mats guy [05:34:40 CET] <atomnuker> I've always found it surprising how much of my jpeg files are yuv444p [05:35:15 CET] <atomnuker> you'd think subsampling would be as popular as it is in video, but nope [06:06:31 CET] <TD-Linux> people generally save images at much higher quality than video [07:11:55 CET] <kierank> I think we should copy j-b and do "the week in ffmpeg" [09:58:54 CET] <kierank> https://medium.com/@kierank_/reverse-engineering-the-gopro-cineform-codec-7… [10:09:39 CET] <durandal_1707> congratulation! [14:58:13 CET] <michaelni> nevcairiel, about put_bits() & assert(), what do you suggest ? [15:37:32 CET] <nevcairiel> michaelni: i just dont like the prospect of the application crashing due to some internal bug, especially as an API user where writing a file may only be a small function of the bigger program [15:38:07 CET] <michaelni> hmm, so you would be fine with a av_log + av_assert2 ? [15:39:14 CET] <michaelni> or you are against always checking as such ? (so that such bug would write out of array but there would be no 0.1% slowdown) [15:40:28 CET] <nevcairiel> how do these bugs really happen? Someone fiddles with put_bits code and breaks something? Or invalid usage from an encoder? [15:43:30 CET] <michaelni> the max buffer size estimation can be wrong or out of sync with the actual code or someone can do something stupid. One such issue was reported yesterday, i have no idea if thats the only one or there are more [15:45:30 CET] <nevcairiel> adding an av_log to the failure case shouldn't add any extra slowdown, should it? the if clause should prevent that. I would prefer not crashing and logging instead, at the expensive of writing corrupted frames [15:47:06 CET] <michaelni> ill benchmark and then post a new patch [15:52:21 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:1f008f34d5b2: rmenc: do not use AVCodecContext.frame_size [15:52:21 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:53448461a772: Merge commit '1f008f34d5b2b5f6217521747e7acfe3efc0e666' [15:55:12 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:9f1eccb97bf8: ff_parse_specific_params: do not use AVCodecContext.frame_size [15:55:13 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:29e6606e9b42: Merge commit '9f1eccb97bf8894cb18b14f642500686505ef186' [16:00:01 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:6bf4c1d71199: r3d: do not create the audio stream until we know the sample rate [16:00:02 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:f6728a3ea27b: Merge commit '6bf4c1d71199b92894f24db6386ed5070e590a16' [16:03:09 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:cdc9ce098e8d: lavc: print the name of the codec, not its implementation, in avcodec_string [16:03:10 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:5f2d12b82494: Merge commit 'cdc9ce098e8d101b43b8f68dd35ba7226f4a728c' [16:21:30 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:2c6811397bdf: lavc: add profiles to AVCodecDescriptor [16:21:31 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:5e8b05345243: Merge commit '2c6811397bdf13d43ca206e48d6d6da9c2cd47c6' [16:27:02 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:e76064172098: lavc: add vp9 profiles to AVCodecDescriptor [16:29:37 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:cea1eef25c33: lavc: get the profile name through the codec descriptor in avcodec_string() [16:29:38 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:15c60c8af227: Merge commit 'cea1eef25c3310a68dd327eb74aae14ad3c2ddef' [16:45:24 CET] <michaelni> nevcairiel: libavcodec/h264.c:2007:17: error: profiles undeclared here (not in a function) [16:45:55 CET] <nevcairiel> silly vdpau decoders [16:48:41 CET] <michaelni> nevcairiel, theres a 2nd one: libavcodec/vc1dec.c:1168:17: error: profiles undeclared here (not in a function) [16:49:27 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:955aec3c7c7b: mpegaudiodecheader: check the header in avpriv_mpegaudio_decode_header [16:49:28 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:1e96b151fa6e: Merge commit '955aec3c7c7be39b659197e1ec379a09f2b7c41c' [16:49:29 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:42ff56e362e8: lavc: fix profile declarations for vdpau decoders [16:58:07 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:72d658766e6c: mp3dec: replace avpriv_mpa_decode_header with avpriv_mpegaudio_decode_header [16:58:08 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:a78d9abee0df: Merge commit '72d658766e6ccf198317dffd6499c5e288847a1c' [16:59:34 CET] <michaelni> nevcairiel, ok if i push the revert now or should i wait or something else (dont want to break your current work) [16:59:37 CET] <michaelni> ? [16:59:50 CET] <BtbN> Will this i264 thing be another "never heard of again" thing, like the attempt to add libyami support? [17:00:23 CET] <BtbN> In general it seems like the best approach, directly adding an encoder on top of libva, but this patch has a lot of issues, and I'm confused which library it actualy refers to [17:01:16 CET] <nevcairiel> BtbN: the name is made up [17:01:21 CET] <nevcairiel> its not a library [17:01:43 CET] <nevcairiel> michaelni: let me finish the merge of the current commit [17:01:50 CET] <michaelni> ok [17:01:55 CET] <BtbN> oh, the hell, why? oO [17:02:36 CET] <nevcairiel> who the f' knows [17:02:42 CET] <nevcairiel> its just a vaapi encoder [17:05:59 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:de9e199a0394: lavc: make avpriv_mpa_decode_header private on next bump [17:06:01 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:92fe2adc1b2b: Merge commit 'de9e199a039473ebe4b1b87382e3064d0ea2cf02' [17:06:01 CET] <nevcairiel> michaelni: ok [17:07:09 CET] <cone-951> ffmpeg 03Michael Niedermayer 07master:0b1e94c50a6e: Revert "Merge commit '9f1eccb97bf8894cb18b14f642500686505ef186'" [17:07:27 CET] <michaelni> nevcairiel, done, thx [17:14:00 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:09ae7b81ea20: flvdec: do not create any streams in read_header() [17:14:01 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:95daa9e09aec: Merge commit '09ae7b81ea2051eec2be9964296bd6ef492c6622' [17:14:57 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:2d0432d918a7: vocdec: put the code not shared with other demuxers under appropriate ifdef [17:14:58 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:5c06fc4bd88e: Merge commit '2d0432d918a71468419b7ac1e543ab3b399d3d37' [17:21:25 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:9f0b6e6827e2: vocdec: do not create the stream in read_header() [17:21:26 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:a240aefc7a25: Merge commit '9f0b6e6827e21e3477abe1199dc2728e30b8c061' [17:22:17 CET] <cone-951> ffmpeg 03Martin Storsjö 07master:64f8c439fd66: rtmpproto: Include the full path as app when "slist=" is found [17:22:18 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:99f2a5638892: Merge commit '64f8c439fd663fec4d57ac21af572d498fe21f7a' [17:22:34 CET] <cone-951> ffmpeg 03Anton Khirnov 07master:5bc223b15d06: r3d: fix an invalid read introduced in 6bf4c1d [17:22:35 CET] <cone-951> ffmpeg 03Hendrik Leppkes 07master:5236cf871818: Merge commit '5bc223b15d064e328ff90b0241fa1191f1d2786d' [17:23:49 CET] <atomnuker> BBB: I've sent a third revision of my decoder to the ML, check it out during the weeked if you've got the time [17:24:41 CET] <BBB> ok [17:25:17 CET] <BBB> re: i264, didnt we have vaapi already? [17:25:26 CET] <nevcairiel> not as an encoder [17:25:33 CET] <nevcairiel> (for good reason, vaapis encoding api is terrible) [17:26:02 CET] <nevcairiel> its as low level as you can get, you ahve to do *everything* manually, building the bitstream, re-ordering frames, what have you [17:26:26 CET] <BBB> reordering frames? [17:26:32 CET] <BBB> wait, like, what [17:26:40 CET] <BBB> it returns frames in display order? [17:26:48 CET] <BBB> confused [17:36:09 CET] <BtbN> It does not re-order them for you, yes [17:37:07 CET] <BtbN> iirc it also has nothing to collect the required reference frames. You have to keep the yourself and pass them along the frame you want to encode [17:37:55 CET] <BtbN> And even though it generates _some_ of the h264 NAL bitstream itself, you have to pass large parts of it manualy to libva, so it can integrate it into the parts it generates internaly... [17:38:33 CET] <BtbN> There's no clear concept behind it at all, it's just the easiest possible way the Intel Hardware-Devs could have exposed the hardware capabilities [17:38:49 CET] <BtbN> Easiest on the Intel-Devs, of course. A horrible mess for everyone else [17:39:49 CET] <BtbN> An I/P-Only encoder is easily made, if you don't mind copying the entire bitstream generation logic from somewhere, but B frames are realy messy [17:46:25 CET] <durandal_1707> fine to push ahistogram? [17:53:23 CET] <Compn> of course horrible mess. :( [17:53:45 CET] Action: Compn always supports hacky patches. [17:53:54 CET] <Compn> someone wants to come and make it pretty, go for it. until then, it works? :P [17:55:58 CET] <Daemon404> [16:37] <@BtbN> iirc it also has nothing to collect the required reference frames. You have to keep the yourself and pass them along the frame you want to encode <-- wtf? [17:57:04 CET] <nevcairiel> like i said, its as low level as you can get [17:58:02 CET] <Daemon404> im also confused... [17:58:07 CET] <Daemon404> why does intel have like 900 libraries [17:58:12 CET] <Daemon404> do they all use the same underlying hardware? [17:58:16 CET] <Daemon404> or is it all special [17:58:31 CET] <nevcairiel> all the same hardware [17:58:38 CET] <nevcairiel> intel is terrible at producing software [17:58:52 CET] <BtbN> Intel basicaly has libva on linux, and MSF/QSV on windows [17:59:03 CET] <Daemon404> well, i think libva was the one i looked at back in 2011 when i work at an intel subsidiary [17:59:10 CET] <nevcairiel> .. and msdk on linux, and libyami, and... [17:59:11 CET] <Daemon404> i seem to recall it was horrible [17:59:11 CET] <BtbN> But they also ported QSV to Linux because people requested it. They made it by setting it up on top of libva [17:59:15 CET] <Daemon404> and didnt even have ratecontrol? [17:59:28 CET] <nevcairiel> except that qsv on linux is terrible [17:59:38 CET] <BtbN> Yes, needs a patched libva and kernel... [17:59:41 CET] <nevcairiel> on windows its already subpar, but on linux you need to patch your kernel [17:59:45 CET] <Daemon404> who are using these hardware encoders anyway? [17:59:51 CET] <Daemon404> and why [17:59:56 CET] <nevcairiel> plus intel doesnt even offer a linux dispatcher library [18:00:09 CET] <nevcairiel> you have to do the libva management yourself due to that [18:00:15 CET] <Daemon404> i thought there was libmfx [18:00:27 CET] <nevcairiel> that lacks any awareness of linux [18:00:35 CET] <Daemon404> i thought luca forked it [18:00:35 CET] <JEEB> :D [18:00:37 CET] <nevcairiel> on windows it handles the device for you [18:00:43 CET] <nevcairiel> he did, he added the linux stuff [18:00:55 CET] <nevcairiel> but of course all the lusers out there want to build with the official one! [18:01:01 CET] <Daemon404> ;) [18:01:05 CET] <JEEB> classic [18:01:18 CET] <Daemon404> i still stand by my original question: who even uses this stuff and why [18:01:18 CET] <BtbN> It's realy sad, Intel has realy good hardware for multimedia stuff. [18:01:25 CET] <Daemon404> it's not even cost-effective for anything at scake [18:01:25 CET] <BtbN> But they royaly messed up the software side. [18:01:28 CET] <Daemon404> whatsoever [18:01:36 CET] <Daemon404> i linux peeps probably dont capture while playing games [18:01:39 CET] <Daemon404> (dont hurt me pls) [18:01:50 CET] <nevcairiel> its a consumer product really, its not going to be at scale [18:02:00 CET] <BtbN> But they buy horribly slow CPUs and expect them to transcode TV for them [18:02:03 CET] <Compn> Daemon404 : h264 encoder/decoder on embedded devices [18:02:03 CET] <wm4> isn't there vaapi based video capture in wayland (weston), but dunno [18:02:16 CET] <Daemon404> Compn, thats not intel [18:02:35 CET] <Compn> all those intel atom netbooks ? [18:02:53 CET] <Daemon404> i thought they stopped making those a long time ago [18:03:02 CET] <JEEB> and thank goodness [18:03:06 CET] <Compn> possibly china... [18:03:15 CET] <Daemon404> china prefers MIPs im sure [18:03:17 CET] <Daemon404> MIPS* [18:03:20 CET] <wm4> http://cgit.freedesktop.org/wayland/weston/tree/src/vaapi-recorder.c [18:03:22 CET] <JEEB> no, china is making intel-based tablets [18:03:42 CET] <nevcairiel> the only usecase is all those people trying to stream video to their phones, or do fast offline transcodes for phones [18:03:51 CET] <nevcairiel> they dont care about quality, they want it done fast [18:03:52 CET] <Daemon404> wm4, NSFW tag your links man [18:03:57 CET] <Daemon404> thats perverted [18:04:06 CET] <wm4> I knew you'd like it [18:04:13 CET] <JEEB> the teklast x98 et al [18:04:38 CET] <JEEB> but yeah, I've seen those people who just want something fast and I'm not even sure if it's faster than x264 preset ultrafast [18:04:43 CET] <Daemon404> nevcairiel, but really how many normal people do this? [18:04:50 CET] <Daemon404> ive never even thought of streaming to my phone [18:04:57 CET] <Daemon404> tablet maybe... [18:05:01 CET] <Compn> Daemon404 : you dont want a 10.1 in netbook? :P http://www.amazon.com/Acer-AOD270-1375-Netbook-Processor-Espresso/dp/B00758… [18:05:11 CET] <nevcairiel> i do it all the time, well strictly speaking to my tablet, but yeah [18:05:15 CET] <Compn> you can use h264 encoder for webcam stuff [18:05:21 CET] <nevcairiel> but then i use x264 for that :D [18:05:43 CET] <Daemon404> nevcairiel, we solved this problem for my SO by vlc for iOS [18:05:43 CET] <JEEB> yup [18:05:47 CET] <Daemon404> <_< [18:05:50 CET] <Daemon404> the lazy fix [18:06:37 CET] <nevcairiel> this way i can pick a bitrate and even use it from remote if i want to, its kinda handy once you have it all in place [18:06:51 CET] <Compn> intel using image macros? http://www.intel.com/content/dam/www/public/us/en/include/tablets-2/imgs/do… [18:07:08 CET] <Daemon404> Compn, intel is learning dank memes [18:07:12 CET] <JEEB> lol [18:09:58 CET] <Compn> i mean how else are you going to set up your cam show on your intel atom notebook if it doesnt have h264 encoding right to youtube ? [18:10:06 CET] <atomnuker> speaking of hardware decoders, companies are making a fortune selling their FPGAs with their proprietary decoders [18:11:01 CET] <Daemon404> Compn, i dont think people who do cam shows use youtube... [18:11:02 CET] <atomnuker> some go as far as to design and optimize their codecs with FPGAs in mind [18:11:36 CET] <Daemon404> most big codecs are designed with hw in mind [18:11:41 CET] <Daemon404> it's practical [18:11:53 CET] <Daemon404> not sure about suoer magic proprietary oens ive never heard of [18:12:55 CET] <Compn> what proprietary codecs are we talking about here ? [18:13:15 CET] <Compn> thought we had samples for most codecs... [18:13:18 CET] <Daemon404> no idea [18:13:29 CET] <atomnuker> <cough>SMPTE</cough> [18:13:37 CET] <Compn> i cant read your boxes [18:13:55 CET] <atomnuker> that's the point [18:14:23 CET] <atomnuker> VC-5, VC-2, etc. [18:14:37 CET] <Compn> those smpte things [18:14:44 CET] <nevcairiel> I still find their entire concept weird [18:14:44 CET] <Daemon404> Compn cant into unicode [18:14:58 CET] <nevcairiel> you standardize something, and afterwards you have a useless standard that doesnt help y ou for shit? [18:15:03 CET] <nevcairiel> how does that work for anyone [18:15:04 CET] <Daemon404> nevcairiel, it's a circle jerk. a way companies can say they use a 'standard' codec. [18:15:37 CET] <Compn> some corporate requirement to have product "standardized" "accredited" etc [18:15:37 CET] <Daemon404> it's not meant to have other implementations. [18:16:07 CET] <JEEB> yup [18:16:13 CET] <Compn> its not a logic-based concept. its truely bureaucratic. [18:26:32 CET] <prelude2004c> good day everyone.. can anyone help with vdapu ? I am still having an issue. Here goes... " Running a system with M4000 card "... ffmpeg with vdpau enabled.. i can decode mpeg2video just fine using the GPU but any source with h264 it will not use the card to decode and instead uses CPU's. Can anyone assist with this ? what could i be doing wrong ? [18:40:46 CET] <cone-951> ffmpeg 03Clément BSsch 07master:77eeaa2c3dec: lavf/srtdec: rewrite parsing logic [18:47:20 CET] <Daemon404> kierank, you intend to leave bayer out for now i assume? [18:59:59 CET] <kierank> Daemon404: dunno, only got 2 samples [19:01:01 CET] <Daemon404> maybe dave can help you [19:07:57 CET] <kierank> I don't really know what the bayer stuff is meant to look like eithrt [19:08:05 CET] <kierank> Or the pixel format [19:08:28 CET] <Daemon404> bayer is not really a 'pixel format' iirc [19:08:37 CET] <Daemon404> isn't it basically a sensor dump [19:12:39 CET] <wm4> ubitux: awesome [19:13:50 CET] <kierank> Yes but sensors are all different [19:13:57 CET] <kierank> Bayer is not a single type iirc [19:14:02 CET] <kierank> It's a principle [19:14:19 CET] <Daemon404> yes i know [19:14:27 CET] <Daemon404> i thought it might code something to helo [19:14:40 CET] <Daemon404> or it could just be like raw, where you handle it manually in the editor [19:14:57 CET] <kierank> It prilobably does code something to jelp [19:15:03 CET] <kierank> But I dunno what they mean [19:17:09 CET] <ubitux> don't we have bayer pixel formats? [19:19:02 CET] <wm4> yes [19:19:53 CET] <Daemon404> vc-5 is supposed to support bayer [19:19:57 CET] <Daemon404> does the spec not list anything [19:20:49 CET] <kierank> No the spec says input data is out of scope [19:20:58 CET] <kierank> It's just daya [19:21:01 CET] <kierank> Data [19:21:22 CET] <Daemon404> lolwut [19:21:32 CET] <Daemon404> is this a joke? [19:23:29 CET] <kierank> Nope [19:23:51 CET] <ubitux> wm4: i don't doubt a second that you will find me another completely mad file anytime soon [19:24:09 CET] <ubitux> but from a demuxing PoV, that should be better [19:25:31 CET] <wm4> lol [19:25:32 CET] <ubitux> anyway, i think i'm going to try again to end the ass madness [19:25:44 CET] <wm4> srt is surprisingly insane I guess [19:25:45 CET] <Daemon404> "ass madness" [19:27:15 CET] <durandal_1707> fork me reviews [19:28:00 CET] <ubitux> wm4: actually not that much, but easily abused and widespread [19:28:22 CET] <ubitux> i think most of the problems come from the numbers [19:28:32 CET] <ubitux> the "event number" [19:29:25 CET] <Daemon404> ubitux, also it has no spec. [19:29:35 CET] <Daemon404> it was just some format a guy made up for an ocr program [19:29:40 CET] <ubitux> specs or not, people will violate them anyway [19:29:44 CET] <ubitux> so it's not really a problem [19:29:49 CET] <Daemon404> this is true [19:29:59 CET] <Daemon404> people upload the wierdest vtt files to us [19:30:06 CET] <ubitux> i mean, you think the guy editing a .srt really cares about the specs ? [19:30:16 CET] <ubitux> like, with Word [19:30:21 CET] <wm4> vtt is in real world use? [19:30:29 CET] <Daemon404> wm4, all subtitles on vimeo are vtt [19:30:35 CET] <Daemon404> we output a very limited subset [19:30:35 CET] <wm4> D: [19:30:42 CET] <Daemon404> its teh only way to do html5 subs. [19:30:51 CET] <Daemon404> youtube probably does too [19:31:00 CET] <nevcairiel> invent your own js powered subs! [19:31:11 CET] <wm4> isn't vtt like srt, except you need a web browser to render them [19:31:11 CET] <Daemon404> or use .ass in flash like crunchyroll [19:31:27 CET] <Daemon404> wm4, our subset is equivalent to a subset of srt [19:31:31 CET] <Daemon404> no fancy things [19:31:56 CET] <ubitux> is "ass markup in srt" part of that subset? [19:31:56 CET] <Daemon404> source: i own the backend subtitle stack; inherited it from someone else [19:32:02 CET] <Daemon404> subtitles are pain [19:32:11 CET] <Daemon404> ubitux, lolno [19:35:37 CET] <ubitux> why don't we add a frame_duration callback in lavc? [19:35:42 CET] <ubitux> for codecs [19:36:28 CET] <wm4> what would that do? [19:36:28 CET] <Daemon404> the notion is somewhat derpy to begin with [19:36:38 CET] <Daemon404> e.g. what about codecs with variable frames [19:37:05 CET] <durandal_1707> have flag [19:37:31 CET] <ubitux> wm4: move the per-codec code from av_get_audio_frame_duration() inside the codecs themselves [19:37:42 CET] <wm4> ah [19:38:08 CET] <durandal_1707> adding callback? Propose it to #libav-devel? [19:39:14 CET] <Daemon404> ubitux, i still dont know how that would work for variable frame lengths [19:39:25 CET] <nevcairiel> it wouldnt, but that wont work today either [19:39:59 CET] <nevcairiel> some containers require a fixed frame size, and they need to know this frame size before hand, hence this function [19:40:47 CET] <ubitux> do we at least issue a warning if the frame size is not fixed? [19:41:29 CET] <Daemon404> btw why is av_get_audio_frame_duration even public [19:41:46 CET] <Daemon404> eh, i guess for people's own muxer's [19:41:48 CET] <Daemon404> s/'s/s/ [19:41:52 CET] <ubitux> grep -A2 av_get_audio_frame_duration libavformat/nutenc.c [19:41:54 CET] <ubitux> lol [19:42:11 CET] <ubitux> not enough per case inside the function [19:42:15 CET] <Daemon404> \o/ [19:42:38 CET] <durandal_1707> Only pcm and s302m are vfs [19:43:14 CET] <Daemon404> for some reason i thought wavpack was [19:43:20 CET] <Daemon404> it may just be large frames [19:44:41 CET] <rcombs> ubitux: mild preference for that to be in the parser [19:45:16 CET] <durandal_1707> technically it is possible for wavpack but not done for simplicity [19:45:18 CET] <jamrial> atomnuker: look at ogg_validate_keyframe() in oggdec.c [19:45:41 CET] <jamrial> see if you need to add a check like the ones for theora and vp8 [19:45:53 CET] <rcombs> as I believe it's sometimes used when not actually decoding (e.g. remux) so it shouldn't depend on the decoder to work [19:47:41 CET] <durandal_1707> can someone test/review showspectrumpic? [20:25:37 CET] <nevcairiel> Man submitting content to trac is slow [20:31:07 CET] <BBB> I feel that all audio or video codecs are huge massive hacks [20:31:15 CET] <BBB> and then the frameworks or codebases around them are just as bad [20:31:22 CET] <BBB> and then ffmpeg is the king of bad-ass code [20:31:48 CET] <BBB> (re: audio frame size stuff) [20:31:49 CET] <wm4> bad bad-ass code or just bad-ass code? [20:33:14 CET] <BBB> Im as-of-yet undecided [20:34:26 CET] <Compn> you are saying that it is impossible to create pretty code if it has to touch dirty codecs and formats ? [20:34:55 CET] <Daemon404> BBB, it's a natural consequence of writign a generic framework around a lot of specific-requiring things [20:35:11 CET] <BBB> Compn: yes [20:35:13 CET] <Compn> some of these things like avi and mov and rm have had years worth of hacks added. which means the hacks required to play back such files... [20:35:19 CET] <Daemon404> and yet nobody would argue they want a separate lib for every format/codec, i think [20:35:36 CET] <BBB> I wasnt arguing for something like that [20:35:42 CET] <BBB> Im just lamenting that the code has to be ugly [20:36:00 CET] <Compn> you just need to personally redefine your criteria for "ugly" [20:36:03 CET] <BBB> Im shedding tears for the world that was once imagined to be so beautiful, yet ended up as it deserved [20:36:22 CET] <Daemon404> isnt that just called gaining perspective [20:36:36 CET] <BBB> Im growing up mommy [20:36:37 CET] <BBB> :D [20:38:13 CET] <Mavrik> Pretty code either solves no useful problem or doesn't work :P [20:41:22 CET] <wm4> ugly code will eventually kill you [20:41:40 CET] <Daemon404> life eventually kills you [21:16:00 CET] <cone-951> ffmpeg 03Ganesh Ajjanagadde 07master:9dba3f8f0983: lavfi/af_sofalizer: remove exp2 and replace clz by ff_clz [21:19:41 CET] <atomnuker> "Message body is too big: 654645 bytes with a limit of 550 KB" [21:20:40 CET] <atomnuker> and I thought 5.8k lines was around right for a small-ish decoder [21:21:08 CET] <durandal_1707> learn to code in less lines, for once :-/ [21:23:24 CET] <Compn> 5.8k lines shouldnt take up 650k though [21:25:33 CET] <atomnuker> durandal_1707: that's about as small as I could make it without resorting to hacks and making it ugly and slow [21:26:27 CET] <atomnuker> if the code styling standards were less loose I could probably just shape it like Mario's sprite and make it fit in a single file [21:27:07 CET] <durandal_1707> atomnuker: then just commit it, no need for review :/ [21:27:17 CET] <atomnuker> but only the IOCCC accept such code :/ [21:28:17 CET] <atomnuker> durandal_1707: it's a new decoder, it needs a review [21:29:26 CET] <durandal_1707> let reviews modify once it is in master [21:31:04 CET] <atomnuker> maybe I will once I'm convinced it won't blow up someone's computer [21:31:11 CET] <cone-951> ffmpeg 03Michael Niedermayer 07master:dbfb2c1abfe8: avformat/mp3dec: Remove unused variable [21:31:36 CET] <atomnuker> btw durandal_1707, is the showspectrumpic patch broken: "fatal: sha1 information is lacking or useless (libavfilter/avf_showspectrum.c)." ? [21:32:02 CET] <atomnuker> oh wait, I didn't apply 1/2 [21:34:09 CET] <durandal_1707> be sure to use the latest version for 2nd patch [21:35:21 CET] <durandal_1707> maybe I should add option to specify duration so it doesn't use bunch of memory [22:00:55 CET] <atomnuker> durandal_1707: showspectrumpic is perfect: https://0x0.st/oJc.jpg https://0x0.st/oJT.jpg https://0x0.st/oJA.jpg [22:01:10 CET] <atomnuker> I definitely think color=intensity should be the default though [22:05:51 CET] <durandal_1707> atomnuker: this is all log scaler? [22:07:42 CET] <atomnuker> yes, that's with log [22:07:51 CET] <atomnuker> (which I think should be the default as well) [22:08:02 CET] <atomnuker> but then again I've stared at Spek graphs for too long [22:08:34 CET] <atomnuker> those settings do look pretty though, prettier than sox or spek [22:08:54 CET] Action: J_Darnley now wants to install r4 [23:23:22 CET] <jamrial> ubitux: all your fate clients are randomly failing fate-h264-conformance-capcmnl1_sand_e [00:00:00 CET] --- Sat Jan 2 2016

1 0

ffmpeg.log.20160101
by burek 02 Jan '16

02 Jan '16

[00:01:20 CET] <YairNet> -b:v mb? [00:01:45 CET] <c_14> how long is the video? [00:01:54 CET] <YairNet> exemple 2:00 [00:02:14 CET] <YairNet> but i need command for all video maximum 100mb orginal :O [00:02:41 CET] <YairNet> ffmpeg -i new.mp4 -s 640x352 -b:v 16000000 -preset ultrafast test640-352.mp4 (make me 203MB) [00:03:30 CET] <c_14> -b:v <(maximum_size in MiB * 1024) / length_in_seconds>k [00:06:38 CET] <YairNet> 16MB (16000/ 120sec) -b:v 133.3 ? [00:07:32 CET] <c_14> 133.3k [00:09:35 CET] <furq> 1092k [00:10:09 CET] <llogan> YairNet: https://trac.ffmpeg.org/wiki/Encode/H.264#twopass [00:10:56 CET] <YairNet> way 1092k [00:11:29 CET] <furq> or 1066k if you want 16MB and not 16MiB [00:12:44 CET] <furq> YairNet: https://www.google.co.uk/search?q=%2816+megabytes+%2F+2+minutes%29+in+kilob… [00:12:50 CET] <furq> that's 133kB/s, not kbps [00:15:24 CET] <YairNet> how i chack my time movie on php? ffmpeg? [00:16:53 CET] <c_14> ffprobe [00:17:06 CET] <c_14> has several parseable output formats [00:20:29 CET] <llogan> YairNet: https://trac.ffmpeg.org/wiki/FFprobeTips#Duration [00:21:16 CET] <llogan> duration may be considered "fragile"; a damaged, truncated, or corrupted input may report an incorrect duration. [00:21:55 CET] <llogan> alternatively you could completely decode with ffmpeg and view the resulting "time=" in the console output [00:25:08 CET] <YairNet> i take file time: 2:10 (16mb / 130sec) = 984.615385 size file finsh resize: 18MB (Way not maxium 16MB?) http://pastebin.com/Uqs8GUGT [00:26:29 CET] <relaxed> for targeting a specific size you'll probably want to use 2 pass rate control [00:27:26 CET] <YairNet> way is 2 pass rate control can exemple plz [00:27:34 CET] <relaxed> https://trac.ffmpeg.org/wiki/Encode/H.264 [00:32:11 CET] <furq> YairNet: you have an audio track as well [00:32:22 CET] <furq> -b:v is the bitrate of the video stream [00:33:35 CET] <YairNet> So what do I do ? [00:34:55 CET] <volar> Has anyone use ffmpeg with asp.net here? [00:35:15 CET] <volar> I'd like to convert avi file to mp4 file [00:35:56 CET] <volar> anyone told me in this channel that libx264 can't be used in asp.net [00:36:11 CET] <volar> so I decided to converto to ogg or webm [00:36:37 CET] <YairNet> c_14: How do I calculate audio? [00:37:08 CET] <c_14> Just give it something static and subtract that from the video bitrate [00:40:57 CET] <volar> can u help me, please? [00:42:54 CET] <YairNet> i can change to 14MB to incdlue audio? [00:45:23 CET] <volar> a command to convert from avi to ogg in ffmpeg using asp.net [00:45:33 CET] <waressearcher2> volar: hallo [00:45:39 CET] <volar> hi [00:45:41 CET] <waressearcher2> volar: wie geht's ? [00:45:54 CET] <volar> again? [00:46:39 CET] <waressearcher2> naja [00:51:45 CET] <llogan> YairNet: look at the link i provided you. it gives an example. [00:52:15 CET] <llogan> waressearcher2: why do you do that? [00:53:44 CET] <llogan> volar: what is asp.net? [00:59:02 CET] <volar> asp.net is a platform like java [00:59:14 CET] <volar> for windows [00:59:31 CET] <volar> i have to go [00:59:43 CET] <volar> happy new yar [00:59:48 CET] <volar> :) [01:12:16 CET] <YairNet> I can make the ffmpeg work more faster ? [01:13:50 CET] <fritsch> add another core i7 to the encoding farm [01:13:58 CET] <fritsch> it scales with the number of cpus :-) [01:14:18 CET] <fritsch> depending on the task, use your given hardware in a better way [01:20:02 CET] <llogan> YairNet: make sure your ffmpeg is using your CPU capabilities. the console output will indicate if it is or not [03:50:39 CET] <Knowbody> Is it possible to hide all ffmpeg output except for progress and errors? [03:56:19 CET] <furq> Knowbody: -loglevel error -stats [03:58:24 CET] <Knowbody> perfect, thanks [04:47:58 CET] <qubodup> hello, how do I know if my version of ffmpeg has the feature to record jack audio? [04:48:46 CET] <qubodup> https://www.ffmpeg.org/ffmpeg-devices.html says To enable this input device during configuration you need libjack installed on your system but does 'configuration' mean the configuration during the build process? and does it really work this way without having to set a flag? (--enable-jack) doesn't exist [10:10:50 CET] <volar> hi [10:11:27 CET] <volar> does anybody use asp.net? [10:11:35 CET] <volar> ffmpeg with asp.net? [10:11:45 CET] <volar> I need some help [10:12:46 CET] <volar> converting avi file to mp4 file using asp.net [10:27:00 CET] <volar> converting on the fly [10:27:30 CET] <volar> can anyone help me, please? [10:31:02 CET] <Fjorgynn> :( [10:31:21 CET] <Fjorgynn> volar: it's 10.31 am in sweden, day after new years eve [10:31:27 CET] <Fjorgynn> just saying [10:57:19 CET] <flux> 1 [11:08:02 CET] <YairNet> way i have problem - http://pastebin.com/ZmtQjFzm [15:21:07 CET] <volar> hi again [15:21:28 CET] <volar> i just downloade media hander [15:21:56 CET] <volar> a ffmpeg wrapper for asp.net [15:22:05 CET] <volar> has anybody use it? [15:31:21 CET] <volar> #asp.net [16:51:05 CET] <waressearcher2> volar: hallo [17:12:26 CET] <volar> at last i got the solution [17:12:28 CET] <volar> wow [17:56:39 CET] <brli> why isn't hall of shame online for so long? [18:26:36 CET] <prelude2004c> good day everyone.. can anyone help with vdapu ? I am still having an issue. Here goes... " Running a system with M4000 card "... ffmpeg with vdpau enabled.. i can decode mpeg2video just fine using the GPU but any source with h264 it will not use the card to decode and instead uses CPU's. Can anyone assist with this ? what could i be doing wrong ? [21:40:27 CET] <xintox> anyone do any live streaming in here? [21:43:53 CET] <Betablocker> me [21:44:13 CET] <xintox> Betablocker: what kind of streaming you do? [21:44:39 CET] <Betablocker> i build up the biggest german webcam streaming network [21:44:48 CET] <xintox> nice [21:44:49 CET] <Betablocker> for web and delivering to tv stations too [21:44:59 CET] <xintox> how big is biggest? [21:45:23 CET] <Betablocker> 5 million visitors month [21:45:31 CET] <xintox> damn [21:45:33 CET] <xintox> that's awesome [21:45:38 CET] <xintox> where do you host something like that? [21:45:41 CET] <Betablocker> 1000-2500 viewers on the system [21:46:12 CET] <Betablocker> hosting in colocation at frankfurt near internet ex [21:49:48 CET] <Betablocker> jo did this the last 7 years from 1 visitors &. ME ! [21:50:41 CET] <Mavrik> Single location? :) [21:52:12 CET] <Betablocker> ;) [21:52:34 CET] <Betablocker> xintox so what is the question about livestreaming ? [21:53:03 CET] <Mavrik> You like to live dangerously :D [21:53:13 CET] <Betablocker> lol [21:55:53 CET] <xintox> Betablocker: how mcuh bandwidth you use? [21:57:17 CET] <xintox> i'm looking for good place to host [21:57:23 CET] <Betablocker> depends on views& the 720p livestreams h264 take between 1 ,5 - 2,5 Gb a day 24/7 [21:57:35 CET] <Betablocker> on 200 cams [21:57:42 CET] <Betablocker> that is inbound [21:57:51 CET] <Betablocker> outbound depends on the viewers [21:58:03 CET] <Betablocker> what audience do you expect for your project ? [21:58:21 CET] <Betablocker> i mean - how many users do you have to prepare& [21:58:41 CET] <xintox> maybe 200-300 simultanouesly [21:59:37 CET] <Betablocker> did you thought about using youtube live ? [22:00:05 CET] <Betablocker> it is a very nice solution for many projects. and the costs are 0 for a lot of users [22:04:08 CET] <Betablocker> in germany/switzerland you could buy a server for about 50 euros a month. www.hetzner.de with gbit but it is not dedicated bandwith. a dedicated server is about 200-300 euros a month. a dedicated server with guaranteed bandwith is a must have for professional projects. sadly to be fail safe you need everything double & double price too. [22:08:14 CET] <Betablocker> if i were you with 200-300 simult. viewers i would buy one hetzner server or from a similar quality provider of your choice. install wowza, red5 or maybe nginx. on linux and give that setup a chance for your project. costs will be manageable if it is a professional project [22:12:36 CET] <Betablocker> i may repeat but youtube live is not that bad. take a look at it first. no setup time - no administration. dvr feature and scalable as hell. monetization with adsense is possible too. analytics & the last time i took a look at the live api it was creepy but if you are lucky they had done their job at youtube over the time :) [22:17:13 CET] <Betablocker> if you have enough upload at home. in some areas there is gbit upload available. you could stream for yourself without the need of video streaming services. [22:28:57 CET] <Betablocker> ffmpeg -i "rtsp://foobar:foo@IP:554" -map 0 -c:v copy -c:a copy -f flv "rtmp://youryoutubechannel/ID [22:29:20 CET] <Betablocker> that should push your rtsp input to youtube live [22:53:00 CET] <furq> xintox: if you want to stream HD content to 300 viewers then you're going to need an unmetered gigabit connection (at least) [22:53:04 CET] <furq> those weren't cheap last i checked [22:55:31 CET] <Mavrik> Yeah, getting server hooked up to a streamable connection is rather expensive. [22:55:52 CET] <Mavrik> Since most cheap colocations will just disconnect you if they see you burning through gigabit traffic [22:56:45 CET] <Betablocker> jop [22:56:49 CET] <furq> the annoying thing is that if you're not doing transcoding on the box, you hardly need any cpu power or ram [22:57:10 CET] <furq> but good luck finding a weak server which lets you use 250TB monthly bandwidth [22:57:32 CET] <Betablocker> 200-300 users should be no problem with a 50 euro hetzner server in germany if it is not a 24/7 streaming [22:57:38 CET] <Mavrik> Hmm, we burn through CPU on our streamers quite a lot. [22:57:52 CET] <Mavrik> As soon as you setup a few 100 streams over several GBit cards the CPU usage ramps up as well [22:58:13 CET] <furq> which server [22:58:27 CET] <furq> which streaming server, i mean [22:58:50 CET] <Betablocker> you mean like wowza ? or like origin edge cluster ? [22:59:26 CET] <furq> it sounds like he has one input stream and 200-300 viewers, which shouldn't be too resource-hungry [22:59:37 CET] <furq> but then i've never had a streaming server with more than 20 viewers so maybe i'm wrong [22:59:37 CET] <Mavrik> furq, custom [22:59:44 CET] <Mavrik> might be more than 100 though [22:59:53 CET] <Mavrik> Don't really work on the end infrastructure. [23:00:07 CET] <Betablocker> it is like that furq [23:00:17 CET] <Mavrik> I know the devops guys had a bit of issue due to network cards eating too much CPU to send out data [23:00:34 CET] <Mavrik> Mainly syscalls being the bottleneck on those machines [23:03:26 CET] <Betablocker> gotta go buddy - happy new year :) [23:03:40 CET] <Mavrik> ^^ [23:03:42 CET] <Mavrik> Have fun. [23:52:32 CET] <xavii> i've got a ffserver running, feed is fed by ffmpeg grabbing from a UDP source. I can view the video from ffserver as avi. The issue is that when i press play, the video starts fine. When i press stop, and then press play again, the video starts from the beginning of what appears to be cached video (probably something to do with timeshifting), why doesnt it play from the current time? I've tried smplayer and vlc. [00:00:00 CET] --- Sat Jan 2 2016

1 0