Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

July 2016

1 participants
62 discussions

ffmpeg-devel.log.20160710
by burek 11 Jul '16

11 Jul '16

[00:44:28 CEST] <cone-091> ffmpeg 03Michael Niedermayer 07master:e98ab799be9c: avcodec/vaapi_encode_h264: Use av_clip_uintp2() [00:44:29 CEST] <cone-091> ffmpeg 03Sami Hult 07master:d4c8e931903a: Changed metadata print option to accept general urls [01:15:15 CEST] <BtbN> ok? [01:17:10 CEST] <Shiz> 11 [01:37:53 CEST] <BtbN> not ok. [01:41:51 CEST] <Compn> o no its spam time [01:45:15 CEST] <BBB> ugh [01:45:50 CEST] <jamrial_> fflogger chokes when there's spam [01:46:12 CEST] <Compn> not sure if i have the right permissions to ban people [01:46:18 CEST] <Compn> i guess i have to find the banlist and add things [01:46:25 CEST] <Compn> >dont make it easy to ban spammers or anything [01:46:34 CEST] <haasn> range ban the country :^) [01:47:36 CEST] <BtbN> AOL still exists? [01:48:18 CEST] <jamrial_> yeah, plenty of old people that never bothered to cancel the service even after they moved to cable [01:48:31 CEST] <BBB> I think theyre all gone now [01:48:36 CEST] <BBB> poke me if you think I forgot one [01:53:41 CEST] <BBB> Compn: michaelni can give permission for that, ask him :) [02:18:09 CEST] <Compn> BBB : i have permissions i think, just forgot "badip" and "badcontent" [02:18:10 CEST] <Compn> :P [02:19:12 CEST] <BBB> ah, yes, I keep forgetting also [02:19:18 CEST] <BBB> and admin/monitoring and so on [02:19:20 CEST] <BBB> its quite fragmented [11:00:19 CEST] <durandal_1707> Compn: why you have not updated codecs.conf with ffmpeg new decoders? [14:04:37 CEST] <kierank> ah good atomnuker objected to psd [14:09:52 CEST] <BBB> heh a raging fire that burns with the passion of a million suns :D [14:10:20 CEST] <BBB> and the freshwater sharkattack uncles attic [14:10:24 CEST] <BBB> epic [14:11:00 CEST] <BtbN> So this thing only works if you export psd with very special settings? [14:11:07 CEST] <BtbN> What's the point than? Might as well export png or jpeg then [14:12:49 CEST] <BBB> thats what I was thinking :-p [14:13:12 CEST] <BBB> Im esecially confused why someone would animate individual frames and save them as psd if their purpose is to be used for a video [14:13:17 CEST] <BBB> do people really do that? [14:13:31 CEST] <BBB> I cant imagine any video editor supporting psd as input? [14:15:36 CEST] <BtbN> If he managed to write a fully features PSD importer, in a way that's not the most horrible mess on earth, that'd be different. [14:26:24 CEST] <nevcairiel> its a closed proprietary format that evolved for decades [14:26:33 CEST] <nevcairiel> its going to be a horrible mess =p [14:32:40 CEST] <mateo`> IMHO, supporting PSD is only relevant to extract the filters and their values used to achieve a particular effect and reproduce the same output outside Photoshop [14:34:05 CEST] <mateo`> (nothing to do with lavc) [14:55:54 CEST] <Chloe> if I have a libavformat without a probe, would I just set the AVInputFormat.read_probe to null? [14:56:57 CEST] <kierank> you're adding a format? [14:57:10 CEST] <Chloe> yes [14:58:10 CEST] <kierank> you just leave it blank in the struct [14:58:14 CEST] <kierank> afaik [15:12:01 CEST] <Compn> durandal_1707 : someone paid me to look at these binary codecs, so takes priority [15:20:59 CEST] <durandal_1707> bad boy [15:36:55 CEST] <Compn> you should be asking me to put it in videolan [15:37:20 CEST] <Compn> vlc has a more complicated system of stuff just for adding codec tags :\ [15:47:25 CEST] <kierank> ? [16:21:43 CEST] <Compn> kierank : each ffmpeg codec tag has to be entered in both mplayer and vlc or they cannot play them [16:21:48 CEST] <Compn> fourcc that is [16:22:07 CEST] <Compn> unless something changed in vlc recently... [20:34:35 CEST] <Compn> huh [20:35:19 CEST] <Compn> i have a file where the video stream in avi header strf says its 640x240. avi container says 640x480. the video really is 640x480..... how the heck can i change this [20:35:58 CEST] <BtbN> sounds like it's from some old console? [20:36:19 CEST] <Compn> stupid cctv hardware [20:37:10 CEST] <Compn> remuxing does not help, since its a stream header... [20:38:33 CEST] <Compn> hmm does ffmpeg have a media page? https://blogs.microsoft.com/firehose/2015/06/08/developers-ffmpeg-open-sour… [20:47:29 CEST] <jamrial> Compn: hex edit the header :p [20:57:42 CEST] <Compn> jamrial : i guess so. [21:28:19 CEST] <atomnuker> michaelni: anyone volunteered to write the announcement we're going to drop ffserver yet? [21:32:57 CEST] <jamrial> atomnuker: don't think so [21:35:15 CEST] <atomnuker> jamrial: wanna write it? [21:35:35 CEST] <jamrial> no :p [21:35:54 CEST] <jamrial> also, when are we supposedly dropping it? [21:37:17 CEST] <Compn> i thought someone suggested we split it into a seperate repo to die a lonely death ? [22:02:48 CEST] <michaelni> atomnuker, unless i forgot, noone [22:03:16 CEST] <cone-367> ffmpeg 03Michael Niedermayer 07master:58dc8bbca485: avcodec/h264_refs: Assert that op is 0-2 [22:03:27 CEST] <atomnuker> wrote something up and send a patch to the ML [22:08:24 CEST] <durandal_1707> Compn: follow my orders! [22:23:26 CEST] <kierank> atomnuker: looks good [22:31:48 CEST] <Compn> durandal_1707 : ok ok [22:32:58 CEST] <Compn> durandal_1707 : what output colorspace does YLC codec want ? [22:33:00 CEST] <Compn> yv12? [22:33:57 CEST] <durandal_1707> Packed yuv422 [22:34:25 CEST] <durandal_1707> there is sample [22:53:28 CEST] <KGB> [13FFV1] 15dericed closed pull request #13: move code from tables to codeblocks (06master...06tables-to-codeblocks) 02https://git.io/vmxwg [23:15:08 CEST] <Compn> durandal_1707 : lol someone made me order airline tickets and now i'm all riled [23:15:18 CEST] <Compn> cant even think right now. [23:16:12 CEST] <durandal_1707> who? [23:18:57 CEST] <Compn> family members [23:19:18 CEST] <Compn> i dont know why people keep asking me to help them buy airline tickets. second time this month. [23:23:56 CEST] <Compn> ok ylc codec... [23:24:11 CEST] <Compn> if only i had an mplayer nightly build [23:46:01 CEST] <durandal_1707> Compn: also magic yuv and sheervideo [00:00:00 CEST] --- Mon Jul 11 2016

1 0

ffmpeg.log.20160710
by burek 11 Jul '16

11 Jul '16

[03:00:22 CEST] <PlanC> is there a way to set the user permssions for the output file with ffmpeg? [03:00:51 CEST] <PlanC> I'm running ffmpeg as a user and when I run stat on the output files they belong to root [03:00:54 CEST] <PlanC> instead of the user [03:01:14 CEST] <PlanC> so I have to run chown on the output files which sucks because I have to login to root to do it [03:11:51 CEST] <DHE> what shouldn't be possible unless you set ffmpeg as setuid root (!!) [03:16:03 CEST] <PlanC> DHE: any idea on how I can fix it? [03:21:42 CEST] <DHE> PlanC: what do you see if you "ls -l ffmpeg" (the path to your ffmpeg binary) [03:21:51 CEST] <DHE> looking for "rws" permission [03:39:28 CEST] <PlanC> -rwxr-xr-x 1 root root 25364952 Jul 7 18:39 /usr/local/bin/ffmpeg [04:18:07 CEST] <william_> hi i am having trouble compiling ffmpeg on Mint using the official guide [04:19:01 CEST] <william_> i am getting first errors during the configure process [04:42:42 CEST] <william_> pkg_config errors [11:36:16 CEST] <shoo> Hello! I know it seems like my Linux Mint 17.2 problem, but maybe someone will help me here! I am learning ffmpeg by tutorial, and getting "ffmpeg_sources/ffmpeg/libavutil/hwcontext_vaapi.c:915: undefined reference to `vaGetDisplayDRM'" compile error at my first app [11:37:09 CEST] <shoo> My app only include <libavcodec/avcodec.h>, <libavformat/avformat.h>, <libswscale/swscale.h>, and then call av_register_all(); [12:30:38 CEST] <jkqxz> shoo: If you want an immediate fix, adding "-lva-drm" at the end of your link line will probably fix it. But, that should have been done by pkg-config - what libraries did pkg-config tell you to use? [12:47:25 CEST] <shoo> Thanks jkqxz, it works now! I am second day with C and GCC, so I am kinda confused with linker, I use "gcc tutorial01.c -o tutorial01 $(pkg-config --cflags --libs libavcodec libavformat libswscale) -lX11 -lva-x11 -lva-drm -lva -lvdpau" string to compile my .c file [12:48:11 CEST] <shoo> but when I use $(pkg-config --cflags --libs libva) it only saing me to use "-lva" and nothing else [12:51:11 CEST] <furq> shoo: pkg-config --libs libva-drm [12:51:19 CEST] <furq> and libva-x11 [12:51:57 CEST] <ffmpegUser1122> hey guys. im trying to use get image sequence from url as following $ ffmpeg -framerate 1/5 -i http://localhost:8080/ffmpeg/img%03d.png -c:v libx264 -vf "fps=25,format=yuv420p" out.mp4 im getting the following error [image2 @ 0x30dbd80] Could find no file with path 'http://localhost:8080/ffmpeg/img%03d.png' and index in the range 0-4 http://localhost:8080/ffmpeg/img%03d.png: No such file or directory what am i missing ? 10x : [12:52:42 CEST] <furq> what gave you the impression image2 could load files over http [12:53:05 CEST] <ffmpegUser1122> oh damn [12:53:11 CEST] <ffmpegUser1122> isnt? [12:53:23 CEST] <furq> i can't say i've ever tried, but i doubt it [12:53:54 CEST] <ffmpegUser1122> well the funny thing is .. my server getting hits from the right file index [12:54:38 CEST] <ffmpegUser1122> 2016/07/10 - 13:47:05 | 200 | 163.399µs | 127.0.0.1 | | Lavf/57.41.100 | GET /ffmpeg/img001.png 2016/07/10 - 13:47:05 | 200 | 85.54µs | 127.0.0.1 | | Lavf/57.41.100 | GET /ffmpeg/img002.png [12:59:25 CEST] <shoo> Thanks a lot guys, now I compile my file with pkg-config and no errors! [13:00:16 CEST] <furq> huh [13:00:18 CEST] <furq> that actually works for me [13:00:46 CEST] <ffmpegUser1122> can i see the CLI command [13:01:57 CEST] <furq> http://vpaste.net/nm66D [13:02:40 CEST] <furq> try running your command with -v debug [13:03:04 CEST] <furq> be prepared for a million lines of output though [13:05:27 CEST] <ffmpegUser1122> http://pastebin.com/4vPfEtCs [13:06:23 CEST] <furq> wtf is going on with those paths [13:07:10 CEST] <ffmpegUser1122> theres jumping .. idk why [13:07:39 CEST] <ffmpegUser1122> but seems like its downloading the files [13:10:20 CEST] <arpu> hello. is it possible to use timestamp or date in output file (runtime for livestream) [13:12:45 CEST] <ffmpegUser1122> crazy thing is .. same url without the pattern works fine [13:14:23 CEST] <furq> it works with 3.1.1 so i guess it's not a regression [13:15:21 CEST] <furq> it jumps by 2^n and then jumps back to (2^n-1)+1 when it gets a 404 [13:16:21 CEST] <ffmpegUser1122> my server output was 200 for requests [13:16:32 CEST] <furq> do you have an app which is dynamically generating these images or something [13:16:38 CEST] <furq> maybe it's breaking because it's not getting a 404 [13:16:48 CEST] <furq> although it should really stop at 999 since you're using %03d [13:16:51 CEST] <ffmpegUser1122> k ill try in a sec [13:17:46 CEST] <furq> if it turns out to be that then you probably want to report it as a bug [13:26:03 CEST] <ffmpegUser1122> http://pastebin.com/pm2SMD9v [13:26:07 CEST] <ffmpegUser1122> no luck :( [13:28:00 CEST] <furq> that's getting further than it was before [13:29:00 CEST] <furq> set -s 320x240 before -i [13:29:04 CEST] <furq> or whatever the image dimensions are [13:29:24 CEST] <furq> for some reason i didn't need that with 2.8 but i did with 3.1 [13:30:39 CEST] <ffmpegUser1122> no influence at all with the size flag [13:32:37 CEST] <furq> [image2 @ 0x39e8d60] Could not find codec parameters for stream 0 (Video: png, 1 reference frame, none(pc)): unspecified size [13:32:40 CEST] <furq> is it still giving that error [13:35:29 CEST] <ffmpegUser1122> nope im getting another error now [13:36:05 CEST] <ffmpegUser1122> http://pastebin.com/t4eBjneQ [13:41:18 CEST] <ffmpegUser1122> ok i got the problem [13:46:48 CEST] <ffmpegUser1122> ill sums all things up in few minutes [14:04:58 CEST] <ffmpegUser1122> so here's how i understand the whole thing of http image2 seq with http and "-analyzeduration 0". ffmpeg will try to understand what is the range of the sequence by hitting the server with n^2 frame index until getting few 404 response in a row. after that 404 responses, ffmpeg will start hitting server with the starting image index by framerate and duration defs. now its ok ;) [14:05:49 CEST] <furq> yeah it seems weird that it would go beyond 999 with %03d [14:06:00 CEST] <furq> like i said, it might be worth reporting that [14:10:58 CEST] <ffmpegUser1122> k ill report it ;) [16:02:05 CEST] <fanchig> Hello people, [16:02:06 CEST] <fanchig> got a question here, a noobie one really - but I can't figure out why the following script won't work: [16:02:06 CEST] <fanchig> ffmpeg -i Elser.mkv -c:a:2 copy -ss 260 -t 3 Elser_new.mkv [16:02:17 CEST] <fanchig> By "won't work", I mean the output file still keeps the 1st audio stream (AC3), while I want to get the 2nd only (DTS). [16:02:38 CEST] <furq> -map 0:v -map 0:a:1 [16:03:02 CEST] <fanchig> i'll try that, thanks [16:06:16 CEST] <JEEB> by default ffmpeg cli selects a single stream that it thinks is the "best" one (vague definition of "best") [16:06:28 CEST] <JEEB> of each type that is [16:06:43 CEST] <JEEB> you have to use map if you want to select specific tracks :) [16:06:57 CEST] <JEEB> what furq noted selects all video tracks and the second audio track [16:07:56 CEST] <fanchig> ok, I got that yes, I just didn't think I needed to use -map on this one [16:07:59 CEST] <fanchig> still a beginner... [16:08:08 CEST] <fanchig> thx for the clarification :) [16:09:05 CEST] <fanchig> ok, it looks like I got the right channel now, that's a first victory. [16:09:19 CEST] <fanchig> ...so thanks furq [16:09:35 CEST] <fanchig> Yet, it has changed DTS into Ogg [16:09:48 CEST] <fanchig> while I'd like to keep to just transcode the DTS as it is [16:09:55 CEST] <JEEB> you mean remux :P [16:09:58 CEST] <fanchig> yup [16:10:04 CEST] <JEEB> and yes, never leave -c undefined for tracks [16:10:24 CEST] <JEEB> by default it picks *something* according to the output container [16:10:34 CEST] <JEEB> and re-encodes to that [16:10:37 CEST] <JEEB> thus -c:a copy [16:10:45 CEST] <JEEB> copies all selected audio tracks [16:11:21 CEST] <JEEB> -c:a:2 would affect the third audio track you selected, which you probably don't have in your output :P [16:11:26 CEST] <JEEB> (because you selected a single audio track) [16:12:04 CEST] <fanchig> yeah, I thought video was actually the first stream (#0), hence 2 [16:12:37 CEST] <fanchig> I only have two audio tracks in my input [16:12:57 CEST] <JEEB> it doesn't matter, -c applies to things after selection [16:13:34 CEST] <JEEB> map first, which maps streams to output, and then for those you then set -c [16:14:02 CEST] <JEEB> so if you pick a single video and audio track, you only have -c:a:0 and -c:v:0 which is why you might as well just do -c:a and -c:v [16:14:39 CEST] <fanchig> ok, the latter I got it [16:20:23 CEST] <fanchig> ...or did I? [16:20:30 CEST] <fanchig> To me, it'd look like [16:20:32 CEST] <fanchig> -map 0:a:1 -c:a:1 copy [16:20:35 CEST] <fanchig> as for the audio. [16:20:44 CEST] <fanchig> map first, then copy [16:21:47 CEST] <fanchig> script now running with that.. [16:23:02 CEST] <JEEB> do you have two audio tracks in the output? [16:23:13 CEST] <JEEB> -c after -i (for output) affects tracks you've selected! [16:23:25 CEST] <JEEB> also it says whether it's copying or not in the terminal output :P [16:28:22 CEST] <fanchig> I have one audio track in the output, which is what I'm after, and the correct stream [16:28:47 CEST] <fanchig> just not the right codec (DTS) [16:29:05 CEST] <furq> fanchig: -c:a copy [16:29:14 CEST] <JEEB> -c:a:1 is the SECOND SELECTED (as in, that is in the output) [16:29:15 CEST] <furq> there's no need to specify a stream if you only have one in the output [16:29:36 CEST] <JEEB> not SECOND INPUT (unless you are specifying a decoder and doing it before -i) [16:33:13 CEST] <fanchig> furq: thanks! Just dropped the :1 spec and DTS appeared [16:33:57 CEST] <fanchig> Jeez, it's gonna take me some time to master the basics of this [16:33:59 CEST] <JEEB> well yes, since you only had a single track there it didn't apply to any tracks (as I've been trying to note a couple of times 1 was the *second* audio track) [16:34:02 CEST] <fanchig> but I got it on this one [16:34:21 CEST] <JEEB> and as I noted before that if you only have a single track of a type just don't specify track numbers :) [16:34:31 CEST] <fanchig> thanks to you both for your time JEEB and furq [16:34:52 CEST] <fanchig> it makes sense indeed now, sorry 'bout that :p [16:35:07 CEST] <furq> just hang out in this irc channel for months and you too can be a master [16:35:47 CEST] <fanchig> Haha, well-noted, I might let it run then in the evenings and weekends [16:36:22 CEST] <fanchig> really cool tool to play with once you get the concepts I guess [16:36:26 CEST] <fanchig> already quite fun anyway [16:36:37 CEST] <fanchig> Thanks again and greetings from France [16:54:57 CEST] <Polochon_street> Hi ! I'm trying to parallelize some decoding program by opening several audio files at once, but I have the error « No URL Protocols are registered. Missing call to av_register_all()? » even if I indeed call av_register_all() each time. Is it a known problem, and am I doing something wrong ? [16:57:06 CEST] <JEEB> what's your config.log from your build (please provide in a pastebin or similar, do not paste on the channel) [16:58:27 CEST] <Polochon_street> well, the only ffmpeg output I have is the one I pasted above [16:58:55 CEST] <Polochon_street> oh, I see, sorry, you want something else [17:08:10 CEST] <Polochon_street> JEEB: here you are http://sprunge.us/bWdb [17:10:35 CEST] <JEEB> ok, then you most probably are just using the API wrong or something [17:10:47 CEST] <JEEB> I was expecting to see disable-everything and you just not having things enabled in your build [17:11:37 CEST] <Polochon_street> okay. Is it a problem to use av_register_all() on different threads ? [17:11:39 CEST] <JEEB> there could be bugs of course, but a lot of stuff would be broken if file protocol wasn't usable [17:11:50 CEST] <JEEB> not sure :P [17:12:08 CEST] <Polochon_street> no, you're obviously right but I'm really new to parallelizatio [17:12:09 CEST] <Polochon_street> n [17:12:41 CEST] <Polochon_street> all I'm doing is parallelizing a for(), and decode different files on different cores [17:13:01 CEST] <JEEB> but yes, it could be global thing somewhere in lavf/lavc main state. not sure though [17:13:11 CEST] <JEEB> haven't had a case where I had to do something like that [17:14:31 CEST] <Polochon_street> too bad :/. Thanks anyway ! [18:58:25 CEST] <Jeena> Hi, I have two webcams which stream rtsp is it possible to use ffmped to join those streams to get one where the first is on the left and the other on the right? [18:58:38 CEST] <Jeena> if so, what should I google for? [18:59:58 CEST] <furq> -i rtsp://foo -i rtsp://bar -filter_complex vstack [19:00:01 CEST] <furq> er [19:00:03 CEST] <furq> hstack [19:00:38 CEST] <Jeena> does that work with more than two streams too? [19:01:22 CEST] <Jeena> ah that helps a lot while googling [19:01:51 CEST] <Jeena> wow this is really awesome http://stackoverflow.com/questions/36268431/video-grid-with-vstack-and-hsta… [19:02:10 CEST] <Jeena> thanks a lot furq! [21:46:32 CEST] <FishPencil> Looking to split a mp4 up. Is there an efficient way to view the video and find the frames I need for -ss with ffplay, or will I need another application to find the cut points? [23:47:57 CEST] <jaggz> how can I save file space if I have 10 min of video but 60 of audio? [00:00:00 CEST] --- Mon Jul 11 2016

1 0

ffmpeg-devel.log.20160709
by burek 10 Jul '16

10 Jul '16

[00:11:18 CEST] <Mysoft> has anyone here, have heard or seen, some acceleration for x264 [00:11:24 CEST] <Mysoft> using OpenGL shaders? [00:11:37 CEST] <Mysoft> like plain simple 2.1 shaders to speed up x264 tasks using the GPU [00:11:52 CEST] <Mysoft> as alternative methods :) [00:17:09 CEST] <nevcairiel> people tried using OpenCL compute shaders instead, and the benefit was barely zero [00:17:34 CEST] <Mysoft> yes [00:17:43 CEST] <Mysoft> because cards that have OpenCL [00:17:54 CEST] <Mysoft> also have nvidia and dxva/dxva2 and etc.. [00:18:05 CEST] <Mysoft> and they are being used on multi-ghz computers [00:18:05 CEST] <nevcairiel> and thats related to encoding with x264 how? :) [00:18:34 CEST] <Mysoft> but for old cards... and 1ghz computers that barely have OpenGL2.0 cards [00:18:40 CEST] <Mysoft> those DO help [00:18:43 CEST] <Mysoft> much more hehe [00:18:47 CEST] <nevcairiel> so you assume [00:18:57 CEST] <nevcairiel> but you dont have any evidence of that, or do you? [00:19:15 CEST] <Mysoft> nop, because nobody attempted [00:19:24 CEST] <nevcairiel> copying data to and from the gpu costs a lot of overhead [00:19:35 CEST] <nevcairiel> so the advantage would have to be significant to not vanish in overhead [00:19:48 CEST] <Mysoft> so you reduce the amount that need to be copied [00:20:10 CEST] <nevcairiel> .. and there probably just are not enough processing steps in x264 that are simple enough and parallel enough that shaders could do them properly [00:20:40 CEST] <Mysoft> well i don't know that much about encoding to guess deep enough [00:20:51 CEST] <Mysoft> but the part that actually use the quantizers to generate the blocks [00:20:58 CEST] <Mysoft> that math could be done entirely with shaders [00:21:14 CEST] <Mysoft> so the final image would be generated directly on the GPU [00:21:29 CEST] <iive> using pixel shader is a bit problematic, because it outputs a single pixel of information. [00:21:58 CEST] <Mysoft> the part of the algorithm that decodes the 8x8 blocks [00:22:07 CEST] <Mysoft> doesnt require to repeat the same "math" for each pixel? [00:22:11 CEST] <Mysoft> on that block... [00:22:35 CEST] <Mysoft> or they need to be synchronous/recursive? [00:23:04 CEST] <Mysoft> i tought it do that because of the ffplay option... that allow to decode at smaller resolution [00:23:22 CEST] <Mysoft> so i assume that instead of decoding to blocks of 8x8 ... it would decode to blocks of 4x4 [00:23:27 CEST] <nevcairiel> lowres decoding doesnt work with h264 [00:23:35 CEST] <Mysoft> yeah i noticed that too :P [00:23:43 CEST] <Mysoft> which would be wonderful if it did [00:23:51 CEST] <nevcairiel> but it never will [00:23:59 CEST] <iive> you can have lowres decoding if you decode only dc coefficients , aka all 8x8 block have same color. [00:23:59 CEST] <Mysoft> beacuse my old laptop can't handle 1920x1080 hehe [00:24:06 CEST] <nevcairiel> h264 is too complex for that, it has various features that are fundamentally incompatible with that [00:24:10 CEST] <Mysoft> so you can have 1/8 only? [00:24:31 CEST] <Mysoft> does that mean that could be used for 4k decoding? [00:24:32 CEST] <Mysoft> hahaha [00:24:44 CEST] <iive> it would still look bad [00:24:45 CEST] <Mysoft> or 4k uses bigger blocks? :P [00:24:57 CEST] <nevcairiel> you would still run into a bunch of trouble with prediction [00:24:59 CEST] <iive> h264 can have 4x4 blocks [00:25:25 CEST] <Mysoft> ah yeah... true :) [00:25:40 CEST] <nevcairiel> someone else asked about lowres for h264 just a few weeks ago, and we determined that its just not possible to do that for h264 [00:25:42 CEST] <iive> are you familiar with fourier transformation? [00:25:57 CEST] <nevcairiel> any result from that would just be horrible :) [00:26:53 CEST] <Mysoft> yeah a bit... since i used it for DTMF signal decoding [00:28:53 CEST] <iive> ok, dct is descrete cosine transformation, aka ignoring the sine part. [00:29:55 CEST] <iive> to get it to 2d, you do 8 rows, then 8 colums (or vice versa). basically to get 1 pixel you have to process all 8x8 input samples for every shader. [00:31:56 CEST] <Mysoft> ok [00:32:15 CEST] <Mysoft> altough hq2x scalers also have to do something similar [00:32:55 CEST] <iive> you actually might have more luck with trying to some of the existing speed up options. [00:33:20 CEST] <iive> e.g. you can try to disable the loopfilter entirely. [00:33:32 CEST] <nevcairiel> you can also skip frames [00:33:34 CEST] <Mysoft> deblocking? [00:33:36 CEST] <Mysoft> and skip frames [00:33:39 CEST] <nevcairiel> but of course that degrades quality [00:33:48 CEST] <Mysoft> i did that with ffplay [00:34:06 CEST] <Mysoft> so i could run 1280x720@60fps on that notebook [00:34:22 CEST] <Mysoft> altough ffplay is considerable slower than mpc-hc for obvious reasons [00:34:53 CEST] <Mysoft> but no matter what i try... it sems to not keep the video playing at 100% [00:35:11 CEST] <Mysoft> maybe because the frameskip on ffdshow and internal decoders of those are limited to 1 frame [00:35:22 CEST] <Mysoft> while on ffplay it seems to be doing multiple frameskip [00:35:46 CEST] <iive> there is also a way to use halfpel motion compensation. that might not always be fast, i've heard the hpel is mmx, while h264 qpel have sse/avx, but since your laptop is old... [00:35:50 CEST] <Mysoft> which would be acceptable since i'm getting about 92% of the speed [00:36:05 CEST] <Mysoft> it has SSE... but not SSE2 [00:37:24 CEST] <iive> frameskip is probably used to drop b-frames, since they are (usually) not used for prediction [00:37:38 CEST] <Mysoft> i wish i could use DXVA... but seems the card there doesnt have dxva for h264... [00:37:44 CEST] <iive> so the number of droppable frames depends how the steam is encoded. [00:37:55 CEST] <Mysoft> and seems the twitch stream despite being x264 isnt DXVA compatible (on source quality) [00:37:58 CEST] <iive> dxva is windows, are you on windows? [00:38:03 CEST] <Mysoft> yes [00:38:37 CEST] <TD-Linux> you could also visit your local electronics recycling center and pick up a better laptop [00:38:38 CEST] <nevcairiel> skip has various modes, most prominently non-ref (b-frames only mostly) and non-key (everything but I frames really) [00:38:53 CEST] <Mysoft> TD-Linux i prefer smart solutions :) [00:39:00 CEST] <TD-Linux> that was a smart solution. [00:39:03 CEST] <Mysoft> no [00:39:06 CEST] <Mysoft> that is the dumb solution [00:39:38 CEST] <iive> nevcairiel: sure, but i frames tend to be 10 seconds away. [00:39:53 CEST] <Mysoft> you know people don't win at olympics... by doing easy decisions do you? :) [00:40:09 CEST] <nevcairiel> noone is going to come up with a fancy solution for hardware from two decades ago [00:40:15 CEST] <Mysoft> well i will :) [00:40:18 CEST] <nevcairiel> so either replace it or watch slowmo [00:40:21 CEST] <Mysoft> i always do :) [00:40:28 CEST] <Mysoft> hence why my main computer is still using windows XP [00:40:59 CEST] <Mysoft> despite being a new computer [00:41:46 CEST] <Mysoft> and so similar i created several compatibility modules so apps like even ffmpeg can run as if it was vista+ [00:41:57 CEST] <Mysoft> but with the lightweight conditions of XP... and so on [00:42:10 CEST] <nevcairiel> ffmpeg still runs fine on XP, you must be misinformed :p [00:42:22 CEST] <Mysoft> then try to download the lastest 32bit version [00:42:23 CEST] <Mysoft> and run on XP [00:42:25 CEST] <Mysoft> :) [00:42:37 CEST] <nevcairiel> we dont offer binaries [00:42:53 CEST] <nevcairiel> how any inofficial binaries are built is out of our control [00:42:59 CEST] <Mysoft> yes i know [00:43:02 CEST] <nevcairiel> but the ffmpeg code requires nothing that is not present on XP [00:43:14 CEST] <nevcairiel> although that may as well change [00:43:16 CEST] <Mysoft> yup, hence why i'm not complaining of that problem [00:43:39 CEST] <Mysoft> i'm just saying that the binaries out there uses mingw64 [00:43:52 CEST] <Mysoft> that requires _s versions from msvcrt.dll that is something exists on vista+ [00:44:03 CEST] <Mysoft> same goes for python... and a bunch of other GNU compiled stuff [00:44:06 CEST] <Mysoft> since they don't care... [00:44:12 CEST] <nevcairiel> nor should they [00:44:23 CEST] <Mysoft> well i think they should [00:44:26 CEST] <Mysoft> but i wont demand they do [00:44:31 CEST] <nevcairiel> XP is a security hole waiting to be exploited now [00:44:42 CEST] <Mysoft> statistically [00:44:48 CEST] <Mysoft> XP has less security exploits than win7 [00:45:01 CEST] <iive> Mysoft: what is your video card? [00:45:05 CEST] <nevcairiel> but in 7 they still get fixed :p [00:45:10 CEST] <Mysoft> they do? [00:45:16 CEST] <Mysoft> are you sure? :D [00:45:40 CEST] <Mysoft> if i was downgrade to 7... in a year they would force me to downgrade even more to 10 [00:45:43 CEST] <Mysoft> so it's a dead end [00:45:52 CEST] <iive> nevcairiel: actually, no updates are installed until you upgrade to win10 ;) [00:46:12 CEST] <Mysoft> the only reason that i don't use linux [00:46:16 CEST] <Mysoft> is because i like the windows freedom [00:46:24 CEST] <iive> LOL [00:46:34 CEST] <iive> Mysoft: what is your video card? [00:46:36 CEST] <nevcairiel> windows 7 still has security support until at least 2020 [00:46:40 CEST] <Mysoft> oh sorry :) [00:46:51 CEST] <Mysoft> so on my main computer i have geforce 8800 GTX [00:47:06 CEST] <Mysoft> that has all nvidia kind of acceleration so for the main computer everything is fine [00:48:11 CEST] <Mysoft> on the laptop i have an ATI Radeon Xpress [00:48:37 CEST] <iive> i guess you can watch h264 on the main desktop computer [00:48:50 CEST] <Mysoft> well i use the notebook as a secondary monitor [00:48:56 CEST] <Mysoft> while i do my main things on the main computer [00:49:11 CEST] <iive> gf 8800 does support hw h264 decoding. pure video or something [00:49:13 CEST] <Mysoft> so as i said i'm not here really trying to solve a problem [00:49:24 CEST] <Mysoft> but i got curious about the capabilities of those :) [00:49:39 CEST] <Mysoft> but on the main computer being a core2quad i can do 1280x720@60 [00:49:45 CEST] <Mysoft> with <100% of a single core [00:49:50 CEST] <Mysoft> so having hw acc there is irrelevant hehe [00:50:06 CEST] <Mysoft> altough it would help for full HD or 4k :P [00:50:30 CEST] <Mysoft> and yeah i have the nvidia thing working fine on mpc-hc/vlc-hc etc... here [00:50:53 CEST] <Mysoft> i was just curious about if anyone tried to push the limits of it for old hardware [00:50:54 CEST] <Mysoft> :) [00:51:13 CEST] <Mysoft> like you know we always do that.... trying to have stuff running on old computers :) [00:51:57 CEST] <Mysoft> but i'm very thankful for the patience for the input on the matter :) [00:52:42 CEST] <Mysoft> as most of the time when i try such stuff i only get negative and useless "upgrade it" solutions :P [00:53:52 CEST] <Mysoft> now i just have to dig deep into libav code... and see how i can do a tiny footprint mpegts -> mp4 (container converter) [00:53:53 CEST] <nevcairiel> you are free to try anything you want, but unless its directly related to development of ffmpeg itself, maybe try somewhere else? :) [00:54:13 CEST] <Mysoft> and where is that place [00:54:15 CEST] <jamrial> Mysoft: sse without sse2 just wont do for video codecs beyond mpeg2 [00:54:19 CEST] <Mysoft> that would have people that understand about x264 [00:54:23 CEST] <Mysoft> to give me hints? :) [00:55:18 CEST] <Mysoft> jamrial you mean "easily do" [00:55:48 CEST] <jamrial> no, just wont do. no integer simd beyond mmx [00:56:18 CEST] <Mysoft> yeah but it can be adapted [00:56:47 CEST] <Mysoft> to work with floats and so on [00:57:08 CEST] <Mysoft> either way... i know it's not simple, or that it would easily give results [00:57:11 CEST] <nevcairiel> 99.9% of all video codecs dont use floats [00:57:18 CEST] <Mysoft> that's a implementation problem [00:57:24 CEST] <Mysoft> not a "potential" [00:57:37 CEST] <Mysoft> they do because obviously SSE lack of lot to make that easy [00:57:58 CEST] <nevcairiel> they dont use floats because floats are inaccurate and slow [00:58:10 CEST] <Mysoft> slower than not using SSE? [00:59:12 CEST] <Mysoft> i think pairing SSE floats with CPU registers [00:59:18 CEST] <Compn> asm is fastest [00:59:19 CEST] <Mysoft> is faster than only use CPU registers [00:59:21 CEST] <Compn> so they use asm :P [00:59:34 CEST] <nevcairiel> if you need to convert back and forth just to use SSE float, then yes, its going to be slower :p [00:59:55 CEST] <Mysoft> yeah so it requires a complete redesign of something that is already very complex [01:00:04 CEST] <Mysoft> and so it's very costly for little to no effort [01:00:08 CEST] <Compn> you dont want to 100% cpu thread anyways. will melt your motherboard caps :P [01:00:28 CEST] <Mysoft> no [01:00:39 CEST] <Mysoft> not on those old notebooks they are sturdy warriors! [01:01:31 CEST] <Mysoft> because they don't do tradeoffs to increase batter life as much as newer ones do [01:01:50 CEST] <Mysoft> otherwise this 2004 notebook would be dead by now [01:02:07 CEST] <Mysoft> yet it's outliving 3 generations of "desktops" of mine :P [01:02:39 CEST] <Mysoft> anyway, i think my next year resolution would make a jpeg decompressor from scratch [01:02:55 CEST] <Mysoft> and by the end of year having a full x264 decoder writtein by from scratch [01:03:15 CEST] <nevcairiel> good luck with that [01:03:19 CEST] <Mysoft> thanks :D [01:04:40 CEST] <Mysoft> *written by me [01:20:40 CEST] <Mysoft> ok, i gotta keep going with my work [01:21:09 CEST] <Mysoft> thanks for the input... and congrats, because ffmpeg is one of the few programs that looks bloated (because the windows binary is now 35mb) [01:21:33 CEST] <Mysoft> but that in reality has capabilities enough to worth that size :) [01:22:25 CEST] <nevcairiel> those binaries probably include a whole lot of externa libraries [01:22:34 CEST] <Mysoft> they do [01:22:42 CEST] <Mysoft> but ffmpeg also uses a lot of them for a lot of stuff [01:22:55 CEST] <Mysoft> and supporting that many formats... filters.... codecs... protocols [01:23:17 CEST] <Mysoft> it really worth the size :) [01:23:23 CEST] <Mysoft> i was very happy that i could use it to stream to twitch... altough i had to use a "buffering step" on the rtmps:// upload :) [01:23:35 CEST] <Mysoft> because otherwise it wasnt reaching my internet cap of 60kb/s [01:23:54 CEST] <Mysoft> since the capture -> encode -> stream steps are synchronous [01:25:43 CEST] <Mysoft> but using intermediate buffers worked very nice so i don't use the ugly,slow,bloated OBS useless software that requires Windows 20 [01:25:52 CEST] <Mysoft> so again, congrats :) [13:40:13 CEST] <ubitux> i'm going to push the merge with michael's patch undoing the behaviour change unless someone wants to look deeper into the issue [13:40:16 CEST] <ubitux> nevcairiel, michaelni ^ [13:49:24 CEST] <michaelni> ubitux, i agree [13:52:24 CEST] <michaelni> ubitux, probably best if you add a NOTE or TODO comment about moving the call [13:58:39 CEST] <cone-091> ffmpeg 03Anton Khirnov 07master:61f168ae348f: h264: factor out setting the parameter sets for a frame [13:58:40 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:f512e4a39037: Merge commit '61f168ae348f94f39e7afc6971654455a5de0e4d' [13:58:45 CEST] <ubitux> michaelni: done & applied [13:58:50 CEST] <ubitux> thanks [14:06:04 CEST] <cone-091> ffmpeg 03Anton Khirnov 07master:90f469aa2b98: lavc: add H.264 MVC profiles [14:06:05 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:775389fc59bc: Merge commit '90f469aa2b98a868cdbe35170c24272de10e1341' [14:08:14 CEST] <cone-091> ffmpeg 03Anton Mitrofanov 07master:a833ff68f6bf: h264: Fix decoding delay for Intra only streams [14:08:15 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:b4abf0e396d8: Merge commit 'a833ff68f6bf9dc72c3ef0ddf830ebed743c0703' [14:16:18 CEST] <ubitux> ok so we have "smpte428-1" and libav has "smptest428-1" [14:16:21 CEST] <ubitux> should we alias them? [14:16:43 CEST] <ubitux> oh well, maybe we shouldn't care [14:23:54 CEST] <cone-091> ffmpeg 03Vittorio Giovara 07master:bcc07e2576cb: pixdesc: Use C99 array to list color properties names [14:23:55 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:1cfa350429a5: Merge commit 'bcc07e2576cb723007bea1238afd019ae2d1b005' [14:26:33 CEST] <ubitux> opinions on 05a4bacb? [14:27:41 CEST] <ubitux> i remember we have a different politic wrt 0-alloc [14:28:24 CEST] <ubitux> apparently it breaks vorbis test [14:30:06 CEST] <ubitux> (in lavf/oggdec we can have new_metadata allocated with a zero size) [14:31:10 CEST] <ubitux> os->new_metadata = av_malloc(1); [14:31:12 CEST] <ubitux> os->new_metadata_size = 0; [14:31:26 CEST] <ubitux> probably due to this (oggparsevorbis) [14:44:30 CEST] <cone-091> ffmpeg 03Vittorio Giovara 07master:05a4bacbf7ec: avpacket: Error out when creating 0-sized side data [14:44:31 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:415072605b38: Merge commit '05a4bacbf7ece618553d339afe1d0b57bc87aea8' [14:45:42 CEST] <cone-091> ffmpeg 03Diego Biurrun 07master:84b2d3fb68ca: h264: Drop unused function check_opcodes() [14:45:43 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:a7ce5b25c03a: Merge commit '84b2d3fb68caf71cff4b80b44ff865d7ae2531ce' [14:48:41 CEST] <cone-091> ffmpeg 03Diego Biurrun 07master:d6c2c2796d88: LICENSE: Fix silly typo [14:48:42 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:3536493082be: Merge commit 'd6c2c2796d8885e99fc90793cdd7937826f82fab' [14:50:09 CEST] <cone-091> ffmpeg 03Diego Biurrun 07master:a2ddfadc2d9e: avdevice: Ignore timefilter test program [14:50:10 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:1ad3ffadd910: Merge commit 'a2ddfadc2d9e91cf70aa7430a7340b418bdb5b42' [14:55:10 CEST] <cone-091> ffmpeg 03Martin Storsjö 07master:f1a9eee41c4b: x86: Add missing movsxd for the int stride parameter [14:55:11 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:84ecbbfb2727: Merge commit 'f1a9eee41c4b5ea35db9ff0088ce4e6f1e187f2c' [15:07:28 CEST] <cone-091> ffmpeg 03Vittorio Giovara 07master:75872d77d215: lavc: Document AV_PKT_DATA_NEW_EXTRADATA [15:07:30 CEST] <cone-091> ffmpeg 03Vittorio Giovara 07master:187d719760bd: h264: Support AV_PKT_DATA_NEW_EXTRADATA [15:07:30 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:46bd0e8e0dfb: Merge commit '75872d77d215d64b8d9430df23c6c74ff921227b' [15:07:31 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:c67aa7f287e7: Merge commit '187d719760bd130f848194ec4a6bd476341914bb' [15:08:45 CEST] <ubitux> anyone wants to merge the multiple stsd mov thing? [15:16:42 CEST] <ubitux> michaelni: in #3962 the hash d0b27fe8f13d56f409448f27c4c08fc9a49bad4d looks wrong [15:16:53 CEST] <ubitux> i'm also looking for the sample [15:18:17 CEST] <ubitux> ah, i actually commented with the correct hash bein 02f7665a3ce703217ae1cbbc7baa29c438d61456 [15:18:30 CEST] <ubitux> i was smarter 21 months ago :( [15:20:56 CEST] <michaelni> there a link to the sample in ticket 3962 http://stfcc.org/misc/dolby_atmos_truehd_sample.m2ts [15:24:49 CEST] <ubitux> mmh? [15:25:04 CEST] <ubitux> i'm talking about multiple_stsd.mp4 [15:25:15 CEST] <ubitux> i thought i had that one though... [15:27:11 CEST] <michaelni> on samples.ffmpeg.org ffmpeg-bugs/trac/ticket3962/multiple_stsd.mp4 [15:27:43 CEST] <michaelni> also if i should test some branch ? [15:27:54 CEST] <ubitux> i didn't start merging it [15:28:24 CEST] <ubitux> thx for the sample [15:34:47 CEST] <michaelni> for stsd related files and tickets "git log --grep stsd libavformat/mov.c | grep -i fix" might work [15:38:08 CEST] <michaelni> also if you search for a file, try locate whateverfile on ffmpeg.org, it often finds files [15:38:19 CEST] <ubitux> alright [15:38:52 CEST] <ubitux> i won't merge that commit until a few hours [15:38:59 CEST] <ubitux> so anyone is free to take over [15:40:30 CEST] <michaelni> ok, ill go afk a bit too then :) should be back soon / in a few h [15:51:57 CEST] <nevcairiel> ubitux: it appears h264.c now has duplicate handling for AV_PKT_DATA_NEW_EXTRADATA [15:54:10 CEST] <ubitux> oh i missed that, my bad [15:56:52 CEST] <cone-091> ffmpeg 03Clément BSsch 07master:3cdd5f4b7c02: Revert "Merge commit '187d719760bd130f848194ec4a6bd476341914bb'" [15:58:14 CEST] <nevcairiel> not sure why specifically we only allow it in avc mode, but probably has reasons [15:58:26 CEST] <nevcairiel> annexb formats shouldnt have out of band extradata anyway [19:31:48 CEST] <jamrial> https://github.com/mpc-hc/mpc-hc/commit/fe1b4ebd1ab69109c898fd4aa250013e18d… looks like some projects using ffmpeg are disabling tree vectorization to fix crashes [19:33:17 CEST] <jamrial> guess we should disable it for good. it's brought more problems than potential performance improvements [19:35:33 CEST] <nevcairiel> with gcc 6.1 it also doesnt build on windows [19:35:41 CEST] <nevcairiel> because inline asm and registers [19:36:08 CEST] <nevcairiel> (doesnt build on x86 if you use -msse or higher) [19:36:19 CEST] <jamrial> yeah, happened to me [19:36:36 CEST] <jamrial> -march=haswell on mingw x86_32 = cabac fails to compile [19:37:52 CEST] <jamrial> also with 5.x [21:05:04 CEST] <cone-091> ffmpeg 03James Almer 07master:fd6dbc53855f: Revert "configure: Enable GCC vectorization on e4.9 on x86" [22:43:30 CEST] <cone-091> ffmpeg 03James Almer 07release/3.0:4774eb8128ea: Revert "configure: Enable GCC vectorization on e4.9 on x86" [22:43:31 CEST] <cone-091> ffmpeg 03James Almer 07release/3.1:f9a150fc31c5: Revert "configure: Enable GCC vectorization on e4.9 on x86" [00:00:00 CEST] --- Sun Jul 10 2016

1 0

ffmpeg.log.20160709
by burek 10 Jul '16

10 Jul '16

[00:22:45 CEST] <corw> Hi to all [00:23:50 CEST] <corw> I'd like to find, in a movie, where there are changes in audio level, e.g. when a dialog starts [00:24:40 CEST] <Kadigan> corw: if Your goal is to normalize the volume, there are playback plugins to do that, and You can easily roll Your own based on reported playback volume alone. [00:25:24 CEST] <corw> Kadigan: my goal is to sync subtitles [00:25:45 CEST] <Kadigan> Ah. How would You recognize speech as opposed to, say, loud noises? [00:26:38 CEST] <Kadigan> Unless You could specify "general area" pointers where the text "should be", and then use this audio analysis to sync them up "almost perfectly". [00:28:25 CEST] <corw> Kadigan: yes that's a problem, but I need to determine the delay of a srt file [00:28:44 CEST] <Kadigan> The delay of ALL subtitles in the file? [00:28:57 CEST] <Kadigan> (ie. the subtitle offset) [00:30:05 CEST] <Kadigan> Please take a look at http://subshifter.bitsnbites.eu/ <-- You can use this tool to recalculate all SRT subtitle points based on a constant shift (eg. all subtitles 2s late) [00:30:17 CEST] <corw> Kadigan: well I suppose that if I know the delay that I must use for one dialog (-subdelay in mencoder) that will be the same for the other dialogs [00:30:29 CEST] <Kadigan> You can also use that tool to correct for overall length. [00:30:40 CEST] <Kadigan> As for determining this - does this have to be automatic? [00:32:13 CEST] <Kadigan> If it does, You may have to learn to implement VAD (Voice Activity Detection), which is non-trivial. [00:32:29 CEST] <corw> Kadigan: what I'd like to determine is the "2s" of your example [00:32:38 CEST] <Kadigan> Yes, I understand. Does it have to be automatic? [00:33:02 CEST] <corw> Kadigan: I don't need a complete automatic process, [00:33:42 CEST] <Kadigan> Then perhaps You can determine that by hand? [00:33:57 CEST] <Kadigan> ie. manually, by watching, listening and calculating the difference. [00:34:37 CEST] <corw> Kadigan: I did that in the past, but it's annoying and imprecise [00:35:33 CEST] <Kadigan> I do not know how to help You. This detection You're looking for would provide You with MANY false-positives, so Your "manual" precision would still be better. [00:39:01 CEST] <corw> Kadigan: I'd like something like showwaves but with a text output, every frame, like ffprobe [00:39:41 CEST] <Kadigan> I'm sorry, I do not know how to help You. [00:39:59 CEST] <corw> Kadigan: thx anyway [01:03:35 CEST] <ZarfMouse> I'm curious what the etiquette on editing the wiki is? I see that anyone can edit it and I'd like to add info about compiling in libspeex support because that was missing from the compile guide I used: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [01:03:50 CEST] <ZarfMouse> Would it ruffle any feathers if I edited that page to add that info in the same format as the other codecs? [01:08:34 CEST] <CFS-MP3> I'll never understand people who ask a question and leave just because one person in the channel says I can't help you [01:08:44 CEST] <CFS-MP3> I could have helped corw... [01:09:09 CEST] <Kadigan> Can You explain Your solution? I'm curious. [01:09:21 CEST] <Kadigan> (and yeah, I didn't say it was impossible) [01:44:24 CEST] <dystopia> ffmpeg has started hanging since the last zeranoe builds [01:44:35 CEST] <dystopia> had 3 hangs up now, can't close command window [01:44:43 CEST] <dystopia> have to end the process in task manager :| [02:34:36 CEST] <CFS-MP3> Kadigan sorry, just read that. I'm the developer of CCExtractor (an open source subtitle tool)... it's quite a niche tool I guess, but it's got some advanced users [02:35:27 CEST] <CFS-MP3> the linguist department at UCLA spent a lot of time on correcting transcript delays in news casts (where delays are always present since there's someone actually typing audio) [02:35:52 CEST] <CFS-MP3> they do have close to perfect lip sync already [02:36:03 CEST] <Kadigan> Yeah, makes sense. I mean, there should be SOME delay due to conversion and buffering... real-time isn't really real-time is it. [02:36:25 CEST] <Kadigan> That should allow for a short gap (a few seconds maybe) to insert stuff into the stream at the last minute, resyncing it. [02:37:24 CEST] <CFS-MP3> if you enable captions in the news you'll see that the text appears a few seconds after the audio (which itself is live, of course minus buffering and transmissions, but those also apply to the captions themselves so for practical purposes they cancel each other out) [02:38:12 CEST] <CFS-MP3> anyway, at UCLA and other universities they store all the news from lots of TV stations... and they bother sync'ing text and audio for their archives [02:38:40 CEST] <Kadigan> I can't really relate, for three reasons: a) I don't live in the US, so I don't know about news CC, b) even if I did, I threw my TV out the window, and c) I mostly deal with production of planned/programmed stuff that's never real-time. :) [02:38:56 CEST] <CFS-MP3> a couple of PHDs spent their summer last year (for google summer of code) on that [02:39:04 CEST] <Kadigan> CFS-MP3: "and they bother" -- that's a good thing, actually. [02:39:50 CEST] <luc4> Hello! After switching to ffmpeg 3 I started to get this http://pastebin.com/W1uZfGbU when trying to build my application. Any idea why? [02:40:31 CEST] <Kadigan> luc4: it looks as though You need to update Your dependency headers...? [02:41:21 CEST] <luc4> Kadigan: mmh& do you mean Im building my app on the new version while still using the old headers? [02:42:21 CEST] <Kadigan> Either that, or using old libs w/ new headers. It's the linker (ld) that's borking out. [02:42:56 CEST] <luc4> Kadigan: mmh& no, I dont think so. The headers are new and the libs was just built. [02:45:06 CEST] <Kadigan> Google so far only notes one other(?) user having this issue, Wanghong Lin. [02:45:26 CEST] <luc4> Kadigan: yes, but it seems to fail building ffmpeg. [02:45:38 CEST] <luc4> Kadigan: my build succeeds, it is my app that wont link. [02:46:04 CEST] <luc4> Kadigan: I suspect the build is wrong: nm reports ff_put_vc1_chroma_mc8_neon to be undefined. [02:46:24 CEST] <luc4> Kadigan: question is: why isnt that defined in the library? [02:47:57 CEST] <Kadigan> Okay, my natural knee-jerk reaction is to explicitly verify that my env isn't doing some weird caching, and that I didn't in fact copy any headers/references for editing purposes. [02:48:23 CEST] <Kadigan> Failing that, it's possible the latest is borked (it happens). I am unable to help You, then. [02:49:11 CEST] <luc4> Kadigan: Im not sure I understand sorry. [02:49:30 CEST] <luc4> Kadigan: the symbol results undefined. Is that normal? [02:49:51 CEST] <Kadigan> I honestly don't know. [02:50:06 CEST] <furq> http://www.ffmpeg.org/doxygen/trunk/vc1dsp__init__neon_8c_source.html [02:50:11 CEST] <furq> i'm not going to lie, i have no idea what's going on here [02:50:22 CEST] <furq> but that hasn't changed since 2.x [02:51:50 CEST] <luc4> furq: I only see a declaration there. [02:52:05 CEST] <furq> it doesn't show up anywhere else on doxygen [02:52:23 CEST] <furq> maybe it's being defined by a macro somewhere [02:52:32 CEST] <luc4> furq: even grep wont find it. [02:52:54 CEST] <furq> you could maybe work around it by building ffmpeg with --disable-decoder=vc1 [02:53:04 CEST] <furq> assuming you don't need a vc1 decoder obviously [02:53:15 CEST] <luc4> furq: in fact I dont probably need it. [02:53:24 CEST] <luc4> furq: but& this is weird... [02:53:49 CEST] <furq> if you're sure there's nothing wrong with your build environment then maybe report it as a bug [02:53:53 CEST] <luc4> furq: the same configure line has been working for months/years, so something must have changed... [02:54:38 CEST] <furq> is this happening with 3.1 or with git master [02:54:46 CEST] <luc4> furq: my build env is very complex, and my configure line is pretty long, so it is likely something is wrong& however that symbol occurs only there according to grep and the definition is missing... [02:55:19 CEST] <luc4> furq: I dont know, Im using 3.1 tag [02:55:46 CEST] <Kadigan> luc4 You may want to search globally for ff_pub_vc1_chroma_mc followed by a number. [02:56:02 CEST] <Kadigan> This thing gets assigned by overload, if I'm not mistaken, and it's calculated on the fly. [02:56:18 CEST] <Kadigan> (which makes me believe it may also be DEFINED on-the-fly) [02:56:32 CEST] <Kadigan> put* [02:56:32 CEST] <luc4> Kadigan: likely, I see something like that below [02:56:46 CEST] <luc4> Kadigan: and also 2.8 reports exactly the same occurrences. [02:56:57 CEST] <luc4> Kadigan: and 2.8 was working properly [02:57:15 CEST] <Kadigan> It may also be that some dependency was moved out of ffmpeg. [02:57:39 CEST] <Kadigan> Unfortunately, I do not have the knowledge to dig any deeper. [02:57:44 CEST] <Kadigan> I can't help more, sorry. [02:57:53 CEST] <furq> does ffmpeg compile or is it just your app which won't link [02:58:01 CEST] <luc4> Kadigan: it happened in the past that some symbol was moved to some encoder/decoder that I was disabling. The result was pretty similar. [02:58:24 CEST] <luc4> furq: ffmpeg is ok, the symbol is undefined in the static lib and my app wont link [03:01:02 CEST] <furq> http://vpaste.net/X6Tru [03:01:17 CEST] <furq> that's from 3.1.1 [03:02:03 CEST] <Kadigan> Okay, one final thought: can that be an export YOU need to define as per the API? ie. a user-side function? [03:02:20 CEST] <luc4> furq: yes, that is problem probably [03:02:29 CEST] <Kadigan> Never used those, but I know they exist... Though typically they are also explicitly assigned by the developer and there are defaults in place as well... Usually... [03:02:30 CEST] <luc4> furq: I only have two undefined [03:03:01 CEST] <luc4> Kadigan: the neon optimized functions? [03:03:26 CEST] <luc4> Kadigan: I should define those functions while my app may not even use vc1? [03:03:38 CEST] <furq> http://vpaste.net/olic3 [03:03:41 CEST] <furq> in case that helps [03:03:57 CEST] <Kadigan> I have no idea. But in case You are compiling against vc1, You may have to. [03:04:01 CEST] <luc4> furq: unfortuantely my configure line is veeery long [03:04:06 CEST] <furq> yeah [03:04:18 CEST] <Kadigan> A stop-gap would be to disable vc1... [03:05:11 CEST] <luc4> Kadigan: Ill disable vc1 but I strongly suspect those symbols were moved in a place that I disabled in my configure line. [03:05:28 CEST] <Kadigan> It's possible. Do You absolutely need the latest ffmpeg? [03:05:59 CEST] <luc4> Kadigan: Im bumping to keep up to date with updates. [03:06:41 CEST] <Kadigan> What I would do would be: I would revert to previous ffmpeg and keep asking on the forum/on IRC. [03:06:41 CEST] <luc4> Kadigan: so, yes, to accomplish my test I need that. But this task is not strictly needed actually. [03:07:03 CEST] <furq> time for a good old-fashioned configure binary search [03:07:51 CEST] <furq> or yeah just disable vc1 [03:08:04 CEST] <luc4> lets disable vc1 [03:08:09 CEST] <luc4> and see what happens [03:08:13 CEST] <luc4> thanks for the suggestion [06:36:33 CEST] <Prelude2004c> hey guys.. good evening... Stream #0:0: Video: rawvideo (UYVY / 0x59565955), uyvy422, 720x486, 59.94 fps, 59.94 tbr, 60k tbn, 60k tbc .. That is my input... trying go use NVENC to convert it but... it keeps saying [nvenc @ 0x11aade0] No NVENC capable devices found [06:36:43 CEST] <Prelude2004c> does this mean that my input pixel format is not supported or something [06:36:47 CEST] <Prelude2004c> anything i can do to try and fix it ? [07:53:31 CEST] <Prelude2004c> hey guys.. anyone know where i can find seanbright ? [11:46:39 CEST] <luc4> Hello! Already asked this hours ago but Im still unable to solve. Im updating ffmpeg to 3.1 in my application and Im now getting this error: http://pastebin.com/W1uZfGbU. My assumption is that my configure line is disabling something that prevents the introduction of this symbol. Anyone who knows what I should enable to have it defined? [11:54:34 CEST] <furq> luc4: what's your configure line [11:57:04 CEST] <luc4> furq: http://pastebin.com/zz0c9wBx [11:58:28 CEST] <luc4> furq: removing vc1 does not seem to help [12:01:02 CEST] <luc4> furq: this is pretty weird: http://pastebin.com/Sjhw28zk [12:01:41 CEST] <furq> fwiw it looks like those symbols are defined in libavcodec/arm/h264cmc_neon.S [12:02:04 CEST] <furq> i don't see any reason why that wouldn't be working though [12:02:30 CEST] <luc4> furq: Im wondering why those symbols get defined since I disabled vc1... [12:04:49 CEST] <furq> did you run make distclean before rebuilding [12:05:06 CEST] <luc4> furq: I completely removed the directory, including the sources. [12:05:13 CEST] <furq> fun [12:05:39 CEST] <luc4> furq: my scripts clones the repo, configures and builds. I do this every time. [12:08:40 CEST] <furq> oh nice [12:08:53 CEST] <furq> i just rebuilt with --disable-decoder=vc1 and now ffmpeg fails to link [12:12:45 CEST] <ubitux> you know you can --disable-everything and then enable just what you need? [12:13:30 CEST] <ubitux> also, --enable-pthreads --enable-armv5te --enable-neon --enable-armv6t2 --enable-armv6 looks unecessary at best [12:13:37 CEST] <furq> and --arch=armv7a [12:15:33 CEST] <aditsu> hi, I want to add a fade out effect to a clip; if I do it directly, it works, but since it has to reencode the whole thing, the quality is affected a bit [12:15:51 CEST] <aditsu> I tried to cut it, apply the fade only to the end part and the concat [12:16:23 CEST] <aditsu> but then it said "Non-monotonous DTS in output stream", and the end part is all black [12:16:48 CEST] <aditsu> I meant "the*n* concat" [12:17:01 CEST] <BtbN> you have to encode with compatible codec parameters if you want to concat without re-encoding. [12:17:25 CEST] <BtbN> so, same resolution, same codec obviously, same profile, level, and probably some other stuff [12:17:30 CEST] <aditsu> the clip is mp4 with h264 and aac; I reencoded video with libx264 [12:18:05 CEST] <aditsu> I'm not sure what additional parameters it needs to be compatible [12:19:19 CEST] <luc4> ubitux, furq: I prefer to keep the configure line like it is because it comes from another software and I integrate the changes. I keep the changes to a minimum. [12:19:32 CEST] <luc4> unless there is something wrong of course [12:19:43 CEST] <aditsu> (reencoded the fading part, that is) [12:20:01 CEST] <BtbN> Also, try using mpeg-ts instead of mp4 for concating. [12:21:57 CEST] <aditsu> I used "-f concat" [12:22:39 CEST] <furq> well yeah [12:22:45 CEST] <furq> http://vpaste.net/vIP4R [12:22:52 CEST] <furq> that happens while linking ffmpeg_g [12:22:58 CEST] <furq> so i guess there's a bug somewhere [12:23:41 CEST] <luc4> furq: yes that is what I found online. But not happening with my configure line. [12:24:01 CEST] <luc4> furq: very weird [12:24:05 CEST] <furq> not happening? [12:24:28 CEST] <luc4> furq: no, ffmpeg libraries are properly built. It is my app that fails linking. [12:24:32 CEST] <furq> oh [12:24:35 CEST] <luc4> properly" [12:24:41 CEST] <furq> your configure line has --disable-programs [12:24:43 CEST] <luc4> in the sense that the symbol is missing [12:25:04 CEST] <furq> it's failing when it tries to link ffmpeg_g, which you're not doing [12:25:31 CEST] <luc4> furq: yes, you are right [12:25:38 CEST] <luc4> furq: this is explained [12:26:51 CEST] <furq> let me try it with git master [12:28:52 CEST] <luc4> furq: so this problem is exactly the same of that message online [12:29:17 CEST] <furq> well it works fine for me without --disable-decoder=vc1 [12:29:30 CEST] <furq> but it seems like the same thing is causing both those issues [12:31:44 CEST] <furq> yeah, same thing with git master [12:38:58 CEST] <luc4> furq: Ill try again cause it keeps failing here. I probably did something wrong. [12:47:54 CEST] <furq> luc4: fwiw it works with --disable-decoder=vc1 --disable-demuxer=vc1 --disable-muxer=vc1 --disable-parser=vc1 [12:49:46 CEST] <luc4> furq: is it also a muxer? [12:49:54 CEST] <furq> apparently [12:50:42 CEST] <luc4> furq: so the problem is probably that I need the muxers and demuxers but I dont need the decoder, as I have hardware decoder for vc1 [12:51:32 CEST] <furq> were you always building with --disable-decoder=vc1 [12:53:45 CEST] <luc4> furq: actually no: https://github.com/carlonluca/pi/blob/master/piomxtextures_tools/compile_ff… [12:54:00 CEST] <luc4> furq: I disabled when I saw the errors [15:46:43 CEST] <dystopia> anyone else having random crashes with latest ffmpeg? [15:48:19 CEST] <JEEB> is FATE red? [15:48:34 CEST] <JEEB> http://fatebeta.ffmpeg.org/ [15:59:20 CEST] <Navion> Does anyone know of a utility that can take an AAC stream and convert it to MP3? I have a streaming server out in the net and I want to send a single stream to it and be able to encode streams for AAC and MP3. [16:01:47 CEST] <dystopia> besweet can do it [16:06:06 CEST] <Navion> dystopia: Do you know where the home page is for besweet? [16:09:20 CEST] <JEEB> uhh [16:09:24 CEST] <JEEB> besweet, sure is something old [16:09:55 CEST] <JEEB> Navion: you can do that just fine with FFmpeg as well, just build with LAME for mp3 encoding [16:10:30 CEST] <JEEB> ffmpeg -i that_aac_stream.aac -c:a liblamemp3 (I think that's how it's called) <further parameters> out.mp3 [16:15:23 CEST] <Navion> So I need to send an Icecast encoded AAC stream to <something> at the remote server site, transcode it to MP3 and send both the AAC and MP3 encoded streams to an Icecast server. I can't do this as a file conversion. It's got to be something like pipes. [16:15:50 CEST] <JEEB> well icecast is HTTP input for ffmpeg, no? [16:16:03 CEST] <JEEB> then you push that to a streaming server as MP3 bit stream [16:16:16 CEST] <JEEB> you can do HTTP input and HTTP post output towards a streaming server [16:16:23 CEST] <JEEB> why not the same icecast for example? [16:17:07 CEST] <JEEB> also please do not send private messages to me unless you especially have a reason for it (specifically relating to me) [16:18:19 CEST] <Kadigan_KSB> (for the record, it's libmp3lame IIRC) [16:18:46 CEST] <Navion> Jeeb: Sorry I misread something. I thought you had sent me a private message and I was replying but upon further close inspection it was just tagged to me. Sorry. [16:23:19 CEST] <Navion> Right now I have a stream encoder at the radio station that makes an AAC and an MP3 stream and sends it to the streaming server. We're changing server locations and the new guys only want a single incoming stream. They're fine with whatever outgoing streams we want. I've actually got a couple different service software instances on the same computer that I need to feed. Add to that, I'm not a streaming wizard. [16:26:17 CEST] <Navion> Will ffmpeg do transrate as well as transcode? I wanna send a really good AAC stream and step the rate down at the server for mobile devices. [16:42:07 CEST] <Zelmo> Hi. I have problems with ffmpeg. I have a m3u8 link which contains lots of .vtt files. I use ffmpeg.exe -v 9 -loglevel 99 -sub_charenc CP1252 -i "link" "episode.srt" --> but this doesnt use the right charset... å-æ-ø is not showing correctly , and there is a few "duplicates"... the duplicates are fine, but is there a way to make it rip right charset? [16:44:58 CEST] <obelisk29> [pcm_s24be @ 0x2afcf80] Invalid PCM packet, data has size 32 but at least a size of 48 was expected [16:44:58 CEST] <obelisk29> Error while decoding stream #0:0: Invalid data found when processing input [16:45:35 CEST] <obelisk29> Is there anyway to have ffmpeg continue processing the file? even though that occured? [16:47:56 CEST] <obelisk29_> Sorry I got disconnected if anybody responded [20:46:28 CEST] <obelisk29> When I try to mux h264 and flac together into a .mov file I get this error "Using MS style audio codec tag, the file may be unplayable!" any idea on howto solve? [20:46:39 CEST] <obelisk29> alac works fine though. [20:49:44 CEST] <BtbN> mp4 does not support flac i guess [20:52:04 CEST] <obelisk29> its .mov [20:52:49 CEST] <obelisk29> I would have guessed someone would have used h264 and flac together.. [20:52:52 CEST] <obelisk29> so puzzling [20:53:16 CEST] <BtbN> same thing. [20:53:51 CEST] <c_14> mov supports alac and mpeg4-als [20:53:57 CEST] <c_14> And maybe pcm [20:55:11 CEST] <obelisk29> which container supports flac and h264? [20:56:27 CEST] <BtbN> mkv I'd guess [20:56:41 CEST] <BtbN> I'm quite sure I heard about flac in mkv before. [20:56:55 CEST] <obelisk29> mkv supports almost anything i think [20:57:12 CEST] <obelisk29> unfortunately premiere doesn't support mkv =( [20:57:22 CEST] <BtbN> Does it support flac? [20:57:27 CEST] <obelisk29> yes [20:57:31 CEST] <BtbN> In which container? [20:57:41 CEST] <obelisk29> cant find that out [20:58:09 CEST] <BtbN> Have you tried using mp4 instead of mov? It's essentialy the same thing, just with diffrent restrictions. [20:58:36 CEST] <obelisk29> yes it doesnt work [20:59:13 CEST] <obelisk29> wont even encode, mov will encode but wont play audio stream [21:00:18 CEST] <BtbN> Wikipedia lists FLAC as supported in "QuickTime", which seems to mean mov [21:01:11 CEST] <obelisk29> Yes I saw that, which gave me hope. ffmpeg does encode it it just puts the wrong style audio tag on it. Thats why I thought there may be an easy fix. [21:02:07 CEST] <JEEB> if you are going to be loading it into an editor then just use raw PCM instead of FLAC [21:02:26 CEST] <JEEB> for lossless video just use ut video and install the VFW component on your editing machine [21:02:29 CEST] <BtbN> flac in mov should indeed work. Are you using latest ffmpeg master? [21:02:49 CEST] <JEEB> flac in mov sounds like something that nothing supports except for libavformat :P [21:02:57 CEST] <JEEB> unless you have a custom QT component for it [21:03:02 CEST] <ritsuka> you need a third party plugin to play flac in QT [21:03:08 CEST] <JEEB> ^this [21:03:09 CEST] <obelisk29> source audio is pcm and it works i was just trying to get a little more compression but still have it lossless [21:03:19 CEST] <ritsuka> there was a xiph qt plugin some years ago, I don't know if it still exists [21:03:21 CEST] <JEEB> then don't use AVC because no editor supports lossless AVC [21:03:36 CEST] <JEEB> video wise that is [21:04:14 CEST] <JEEB> just give up on the miniscule savings you get from lossless audio compression and getting all those incompatibilities [21:04:34 CEST] <JEEB> for stereo it's like 1.5mbps? [21:04:40 CEST] <JEEB> 16bit 48kHz [21:04:43 CEST] <obelisk29> 2308kbps [21:04:55 CEST] <obelisk29> 24 bit pcm [21:05:01 CEST] <JEEB> yeah, 24bit is bigger of course [21:05:34 CEST] <JEEB> but still, that's still probably at least 1/10 of the video bit rate [21:05:39 CEST] <JEEB> if it's lossless [21:06:01 CEST] <obelisk29> i just have a LOT of really long HD captures in prores so any savings make a big difference [21:06:36 CEST] <obelisk29> 3.8 gb vs 2.2 gb of audio on one file [21:06:48 CEST] <JEEB> well, then you would have to give up on using that file as source for editing as-is [21:06:52 CEST] <JEEB> which is a bigger thing for you? [21:07:58 CEST] <obelisk29> I just run the storage machine and try to keep our editors happy =) [21:08:23 CEST] <JEEB> well then you don't want to make them decode the audio every time they grab the file for editing, right? [21:08:31 CEST] <obelisk29> Yes [21:08:41 CEST] <JEEB> just buy more disks then :/ [21:08:53 CEST] <JEEB> no payware editor supports what you want to do [21:09:03 CEST] <JEEB> (ffv1 or lossless AVC with FLAC or so) [21:09:12 CEST] <obelisk29> h.264 works fine in premiere, are you saying flac or alac would have to be processed. [21:09:22 CEST] <JEEB> yes, *lossy* AVC works [21:09:25 CEST] <JEEB> lossless doesn't [21:09:27 CEST] <obelisk29> yes [21:09:30 CEST] <obelisk29> its lossy [21:09:46 CEST] <obelisk29> 216 gb on average down to 30 [21:10:07 CEST] <JEEB> so you are effectively making it pretty much impossible to make a re-edit of something [21:10:34 CEST] <obelisk29> No they are telling me they can edit just fine on that [21:10:35 CEST] <JEEB> depends on your CRF value but you're basically scrapping out information. not like prores is lossless to begin with of course, but it has lulzy bit rates [21:10:51 CEST] <JEEB> well yes they can, but depending on how much you compress that stuff is worse than the source [21:10:56 CEST] <JEEB> I just want you to understand that [21:11:00 CEST] <obelisk29> They are just using the eye test of course [21:11:07 CEST] <obelisk29> I understand [21:11:34 CEST] <obelisk29> The goal is to edit off prores then once they're done convert to h264 for archival [21:11:35 CEST] <JEEB> also I think QT used to have issues with AVC quantizer going under some value like 4 or so [21:11:53 CEST] <obelisk29> and on the offchance they do need to edit something I guess they will take the quality hit [21:11:57 CEST] <JEEB> yes [21:12:08 CEST] <JEEB> EU is trying to standardize ffv1+flac in matroska for archival [21:12:15 CEST] <JEEB> I wonder if the corps will implement that [21:12:16 CEST] <JEEB> lol [21:13:05 CEST] <obelisk29> I've done screenshot comparison testing and it's pretty darn good. Do you know of any software video quality testers? [21:13:13 CEST] <obelisk29> That would be awesome if they did [21:13:32 CEST] <JEEB> no, eyes are still the best thing around. what were your settings for x264? [21:13:47 CEST] <JEEB> with computers you can just get some sort of values like PSNR or SSIM etc [21:14:04 CEST] <JEEB> those aren't always the same as visual quality [21:14:24 CEST] <JEEB> although I guess if you have high enough limits those could be utilized [21:14:47 CEST] <JEEB> PSNR for example is very easy to get good scores with by just blurring the result [21:15:02 CEST] <obelisk29> -vcodec libx264 -crf 19 -preset slow \ [21:15:02 CEST] <obelisk29> -x264opts colorprim=bt709:transfer=bt709:colormatrix=bt709:fullrange=off \ [21:15:02 CEST] <obelisk29> -map 0:0 -map_metadata -1 \ [21:15:02 CEST] <obelisk29> ../cache/h264_video.mov [21:17:41 CEST] <obelisk29> I still can't understand why premiere doesn't support mkv [21:18:16 CEST] <JEEB> because it's a crazy nonstandard format. the EU people are having "real fun" trying to standardize the mess [21:18:37 CEST] <JEEB> + since no enterprise used it for editing purposes [21:18:58 CEST] <obelisk29> I guess when you support anything, anything goes... [21:20:33 CEST] <JEEB> well it doesn't support anything any more than any other container. just that it doesn't have a clear thing on where things are defined [21:21:07 CEST] <JEEB> I'm pretty sure my write-up on HEVC isn't anywhere else than the mailing list f.ex. [21:21:09 CEST] <obelisk29> I'm also trying out hevc as an archive format. I'm currently encoding a file right now so our editors can test it. Any thoughts on that? [21:21:11 CEST] <JEEB> https://lists.matroska.org/pipermail/matroska-devel/2013-September/004567.h… [21:21:24 CEST] <obelisk29> I know it uses a lot more cpu. [21:21:27 CEST] <JEEB> obelisk29: not useful for your use case really and the encoders can be funky [21:21:34 CEST] <JEEB> + slower to decode [21:21:59 CEST] <JEEB> for archival I'd be using the stuff in lossless mode anyways, so ffv1 and x264 (and ut video for editing machines) would be my picks [21:22:14 CEST] <obelisk29> maybe in the future then [21:23:11 CEST] <obelisk29> how is mac support for ffv1 and ut video? [21:23:36 CEST] <JEEB> ut video has a component from the original author [21:23:38 CEST] <obelisk29> mac premiere specifically [21:23:47 CEST] <JEEB> for QT which then most editors use [21:24:12 CEST] <JEEB> thus it has become the lossless thing I see most people using for video editors on win/mac [21:24:25 CEST] <obelisk29> I would have to find out if our capture software can output that. [21:25:20 CEST] <JEEB> of course it's an editing format so compression ratios aren't exactly excellent [21:25:26 CEST] <JEEB> but that's not what it was meant for [21:25:35 CEST] <JEEB> it's a simple, fast lossless format [21:26:05 CEST] <obelisk29> They are using movierecorder 3 to capture all the footage [21:26:35 CEST] <obelisk29> is it worse compression then prores? [21:26:46 CEST] <obelisk29> or no compression lol [21:26:54 CEST] <JEEB> no compression is of course bigger [21:27:09 CEST] <JEEB> it's got simple median prediction and then huffman coding [21:27:28 CEST] <JEEB> size difference between it and prores depends, prores is pretty much slightly changed JPEG [21:27:32 CEST] <JEEB> and of course lossy [21:31:43 CEST] <obelisk29> movierecorder doesn't support it. It does have a codec listed us uncompressed which I'm not sure what that would be. [21:32:18 CEST] <JEEB> it looks like yer standard QT using thing so I would guess it supports it if you install the QT component [21:32:39 CEST] <obelisk29> I'll definitely try. [21:32:40 CEST] <JEEB> uncompressed is either uncompressed YCbCr or RGB, the usual stuff [21:32:57 CEST] <JEEB> for some reason enterprises only know lossless that is uncompressed [21:34:01 CEST] <obelisk29> We have a 1080i 59.94 input format, if I capture that uncompressed could ffmpeg deinterlace lossless into a 1080p 29.97? [21:34:05 CEST] <obelisk29> Or am I offbase? [21:35:39 CEST] <JEEB> well compressed or uncompressed as long as it's hinted correctly you can deinterlace those fields into frames, yes [21:36:45 CEST] <obelisk29> is it better to make that framerate stepdown for the deinterlacing or is keeping it at 59.94 going to produce the same result? [21:37:15 CEST] <JEEB> depends on the content [21:37:48 CEST] <JEEB> for actual interlaced content with actual separate fields in the fields the best results are gained from having each field become a frame after deinterlacing [21:38:13 CEST] <JEEB> for progressive content coded interlaced you have stuff like field matching and possibly decimation [21:41:16 CEST] <JEEB> usually deinterlacing that halves the rate is used to save resources on the encoding side that comes after that (unless it's actually progressive content coded interlaced) [21:41:16 CEST] <obelisk29> gotcha, So I would have to make sure the capture machine is recording true interlaced not half-converting to progressive right? [21:41:30 CEST] <JEEB> nah, you just have to know what sort of input you've got [21:42:14 CEST] <JEEB> and if your input can actually be progressive in general that's almost always a better deal [21:42:49 CEST] <obelisk29> Scan type : Interlaced [21:42:49 CEST] <obelisk29> Original scan type : Progressive [21:42:49 CEST] <obelisk29> Scan type, store method : Interleaved fields [21:42:49 CEST] <obelisk29> Scan order : Top Field First [21:43:11 CEST] <obelisk29> That's an example capture [21:43:17 CEST] <JEEB> that doesn't really say anything about the actual content coded in there [21:43:38 CEST] <obelisk29> How would I find that out? [21:43:45 CEST] <JEEB> video formats generally only contain info on how something is coded, they don't take note on what is being coded [21:44:00 CEST] <JEEB> by actually checking the video field by field [21:44:06 CEST] <JEEB> short points here and there [21:44:31 CEST] <JEEB> you can use avisynth or vapoursynth for that, among other things. although I think players such as mpv can in theory do that, too if you give them the correct filter chain [21:44:57 CEST] <obelisk29> thx [21:49:19 CEST] <obelisk29> http://avisynth.nl/index.php/Interlace_detection [21:49:33 CEST] <obelisk29> Am I one the right track? I've never used avisynth [21:49:46 CEST] <JEEB> no, don't try to do automagics [21:49:51 CEST] <JEEB> that doesn't work with interlacism [21:50:14 CEST] <JEEB> just load the thing up in avs or vapoursynth and do separatefields() in AvsPmod or vapoursynth editor [21:50:31 CEST] <JEEB> then seek to a piece of motion [21:50:43 CEST] <JEEB> and see if you get every field its own image, or two fields that form an image [21:51:03 CEST] <JEEB> if it's the latter then you start seeing if there's a pattern of 1-2-3-4-5 or 1-2-3-4-4 [21:51:15 CEST] <JEEB> latter having one duplicate image [21:51:43 CEST] <JEEB> which is usually used when coding 24/1.001 Hz content into 30/1.001Hz [21:51:53 CEST] <JEEB> due to broadcast or whatever limitations [21:52:06 CEST] <JEEB> after that you should have an idea of what you're dealing with [21:52:18 CEST] <JEEB> and can apply required filters [21:53:15 CEST] <zeeo> hello people [21:53:31 CEST] <zeeo> i've got a problem encoding to vp8 [21:54:00 CEST] <zeeo> ffmpg seems to ignore my -crf option [21:54:29 CEST] <JEEB> how FFmpeg maps the -crf option is different between libvpx and libx264 [21:54:40 CEST] <JEEB> also vp8 has special limits [21:54:49 CEST] <JEEB> like requiring you to set a bit rate even though you're using CRF [21:54:59 CEST] <JEEB> libvpx with vp9 doesn't require that [21:55:00 CEST] <zeeo> i'm clueless. i get those ~256k default bitrate all the time [21:55:46 CEST] <zeeo> oh. the bitrate requirement could be it. gonna check. [21:57:10 CEST] <JEEB> but as I noted, even though FFmpeg decided to map the -crf command to something in libvpx that doesn't mean it's the same as crf with other encoders :) [21:57:23 CEST] <JEEB> so don't expect similar results [21:58:32 CEST] <zeeo> sure [21:58:38 CEST] <zeeo> i can just set -b:v really high then, right? [21:58:53 CEST] <JEEB> I would guess so, I only checked the libvpx wrapper code and WTF'd :P [21:58:54 CEST] <zeeo> it seems to work. [21:59:16 CEST] <JEEB> because I wondered why the heck official examples at google used both bit rate and "crf" at the same time [21:59:30 CEST] <iongion> is there a way to mux multiple aac + h264 streams to a mp4 file and stream the bytes immediately as they get produced ? I mean, I do not want moov atom at the begging, I just want the fastest way to produce mp4 files without ffmpeg having to travel back and forth to construct the moov atom [21:59:55 CEST] <zeeo> stupid requirement. also, i didn't get that from --help or manpage or all the webpages i checked. [22:00:20 CEST] <c_14> zeeo: https://trac.ffmpeg.org/wiki/Encode/VP8 [22:00:55 CEST] <c_14> iongion: fragmented moov, check all the fragment_ flags in the manpage (most clients won't support fragmented moov though) [22:01:30 CEST] <JEEB> I actually wonder how many things wouldn't support fragmented stuff now [22:01:39 CEST] <JEEB> because DASH support pretty much requires it [22:02:03 CEST] <JEEB> it doesn't but it means that if something supports DASH it's highly likely it supports fragmented ISOBMFF [22:02:12 CEST] <iongion> c_14: but can it be placed last and thus removing the need for fragmented ? [22:02:22 CEST] <JEEB> that's the default [22:02:26 CEST] <JEEB> but you can't play the file right away [22:02:32 CEST] <JEEB> because the moov isn't there [22:02:40 CEST] <JEEB> since the file isn't finished yet :P [22:02:40 CEST] <zeeo> c_14: been there. the following paragraph in there made me stumble: [22:02:49 CEST] <zeeo> "If neither -b:v nor -crf are set, the encoder will use a low default bitrate and your result will probably look very bad. Always supply one of these optionsideally both." [22:03:19 CEST] <iongion> but when I try to have ffmpeg mux and redirect output to a named pipe so I can pick bytes up with python, it complains that muxer dont support non-seekable output [22:03:22 CEST] <c_14> They both have internal defaults, but they're very low. [22:03:26 CEST] <JEEB> yeah, google changed how that option worked between vp8 and vp9 so for vp8 you need both and vp9 is separate :) [22:03:42 CEST] <iongion> I do not want to play it, just to export it as fast as possible [22:03:59 CEST] <JEEB> iongion: you're not using the faststart movflag, right? [22:04:13 CEST] <zeeo> JEEB: from a quick look it seemed to be the same story for libvpx-vp9 for me... [22:04:14 CEST] <JEEB> because otherwise it should be just leaving the moov in the back [22:04:28 CEST] <JEEB> zeeo: that doesn't require the bit rate as far as I remember from the libavcodec wrapper [22:04:52 CEST] <iongion> but then why does it complain that it cannot redirect output to a named pipe ? the muxer does not need to travel in the default case [22:05:19 CEST] <JEEB> dunno, could be something within the mov/ISOBMFF muxer otherwise that wants seeking [22:05:40 CEST] <JEEB> not moov in that case then, but something else where the thing is seemingly using seek [22:06:02 CEST] <JEEB> the feature set I use with the muxer seems to be OK, though [22:06:09 CEST] <JEEB> but I'm using fragments [22:07:42 CEST] <ChocolateArmpits> iongion: use mpegts as muxer ? [22:07:59 CEST] <iongion> yes [22:08:49 CEST] <iongion> but then the file is not an mp4 [22:09:03 CEST] <DHE> mp4 must be written t a real file on disk. it is not stream-friendly at generation time [22:09:23 CEST] <JEEB> uhh, then why am I being able to output to HTTP :P [22:09:33 CEST] <DHE> really? [22:09:35 CEST] <JEEB> I mean, ISOBMFF has limitations but seriously please don't say things that aren't true [22:09:36 CEST] <ChocolateArmpits> You can do -f nut too, that will never complain [22:10:00 CEST] <JEEB> DHE: yes really, I use it currently to produce stuff against other stuff [22:10:01 CEST] <DHE> I thought the moov atom still needed to be updated... [22:10:42 CEST] <JEEB> well, in my case it's fragmented but it's still ISOBMFF. and in theory you should be able to write ISOBMFF even without fragmentation A=>B [22:10:43 CEST] <zeeo> well, no, doesn't seem to work at all. it only respects the -b:v option, it seems. [22:10:53 CEST] <JEEB> zeeo: crf with libvpx is weird [22:11:00 CEST] <JEEB> esp. with vp8 [22:11:10 CEST] <JEEB> also rate control in libvpx is notoriously bad, at least with vp9 [22:12:10 CEST] <JEEB> DHE: that said it seems like there could be an issue with the current movenc.c when not using fragments [22:12:28 CEST] <JEEB> at least according to that guy saying that it complains when writing to a non-seekable output [22:16:31 CEST] <zeeo> i get several megabits/sec with -crf 63 for a 400p video... [22:16:50 CEST] <zeeo> unusable. [22:17:13 CEST] <JEEB> it probably uses the bit rate more than the CRF then :P [22:37:52 CEST] <obelisk29> JEEB ok so I separated the fields into vapoursynth, I'm not sure how to tell if every field has its own image or not and there is no discernible pattern in frames it's like 1 frame then next is duplicate then new frame then duplicate then new frame then duplicate but half of it is shearing then new frame newframe [22:37:55 CEST] <obelisk29> so confused [22:38:16 CEST] <JEEB> just get some actual movement going [22:38:25 CEST] <JEEB> as in, seek to a place where there's movement [22:38:46 CEST] <JEEB> then after you've separated the fields you seek through it and see whether the fields are part of a single picture that's in two [22:38:54 CEST] <JEEB> or if every field is its own picture [22:38:58 CEST] <JEEB> it should be pretty obvious [22:39:12 CEST] <obelisk29> the whole thing has motion [22:40:04 CEST] <JEEB> then it should be simple to see which of those two cases is true :P [22:40:26 CEST] <obelisk29> every frame is taking up the upper portion of the window [22:40:29 CEST] <obelisk29> its halved [22:40:33 CEST] <obelisk29> and fps has doubled [22:41:00 CEST] <obelisk29> 1920x540 [22:41:01 CEST] <JEEB> yes, since a field is half the height of a frame (has every second line) [22:41:22 CEST] <JEEB> actual interlaced content has those fields be taken at different times which should be obvious when you seek through them [22:41:47 CEST] <JEEB> so you have clearly two different images between two fields in actual interlaced content that has movement [22:42:02 CEST] <obelisk29> yes [22:42:29 CEST] <obelisk29> except when they are exact duplicate copies [22:42:41 CEST] <obelisk29> which is very often when i step through frame by frame [22:42:59 CEST] <JEEB> that only happens when there's no movement or when there's telecine going on [22:43:30 CEST] <JEEB> so if you start having stuff like same image but one line up/down kind of effect that means that it seems like progressive images are being encoded as interlaced [22:43:50 CEST] <JEEB> instead of having two completely different images between two fields [22:45:01 CEST] <obelisk29> whats the best case for converting to 1080p from 1080i 59.94? [22:45:11 CEST] <obelisk29> straight interlacing [22:45:23 CEST] <obelisk29> so every frame is half the other one? [22:45:38 CEST] <obelisk29> So it can combine them perfectly into one frame? [22:46:07 CEST] <JEEB> yes, that's called telecine, where you code two parts of a single progressive image into two fields [22:46:22 CEST] <JEEB> then you fieldmatch those together instead of doing dumb deinterlacing [22:46:37 CEST] <JEEB> that's why it's important to look at your stuff instead of just applying a deinterlacer ;) [22:47:02 CEST] <zeeo> 2-pass encoding seems to be unavoidable for reasonable control over target bitrate with vp8/9 if you don't want to nail it to cbr [22:47:21 CEST] <JEEB> zeeo: and expect issues with the rate control anyways [22:47:34 CEST] <JEEB> 'tube has o9k wrappers around it to make it work for them [22:48:35 CEST] <JEEB> I just hope that with the AM1 project some people will care to fix it [22:48:41 CEST] <JEEB> or was it AV1 [22:48:41 CEST] <obelisk29> Thx so much for your help [22:48:57 CEST] <JEEB> obelisk29: anyways for progressive content you just want to keep it progressive all the way :P [22:49:05 CEST] <JEEB> instead of making it interlaced at some point [22:49:08 CEST] <JEEB> less of a headache [22:49:37 CEST] <obelisk29> Yes half our cameras can only output 1080i =) [22:49:45 CEST] <obelisk29> Waiting for them to upgrade [22:50:12 CEST] <ChocolateArmpits> They should output 25p too as that's per standard [22:50:57 CEST] <ChocolateArmpits> or 30p if you're in the States [22:51:09 CEST] <Navion> Jeeb: Do you know where I can find people that have used Liquidsoap? It seems like a streaming transcoder is part of that package. [22:51:10 CEST] <obelisk29> I was about to say isn't that a pal format? [22:51:18 CEST] <obelisk29> ;) [22:51:28 CEST] <JEEB> Navion: no idea whatsoever :P [22:51:42 CEST] <Navion> Jeeb: Pooh! [22:51:45 CEST] <JEEB> Navion: also if you had that question about audio rate change, yes FFmpeg can do that too [22:51:54 CEST] <JEEB> ffmpeg cli has -ar for that [22:51:59 CEST] <JEEB> -ar 22050 etc [22:54:24 CEST] <Navion> Jeeb: I think Liquidsoap probably uses ffmpeg to do the work but they have built all the shimware to get a stream and re-stream it. Easier than writing a bunch of stuff from scratch. [22:54:58 CEST] <JEEB> ok, I can't say anything about 3rd party solutions [00:00:00 CEST] --- Sun Jul 10 2016

1 0

ffmpeg-devel.log.20160708
by burek 09 Jul '16

09 Jul '16

[08:42:22 CEST] <andrey_turkin> i see a potential issue with SCTE-35 regarding its timing. There may be zero, one or many pts values embedded in the messages, and somehow the messages should be in sync with rest of the streams despite all the massaging done to timestamps in ffmpeg [08:44:00 CEST] <andrey_turkin> easiest cases probably would work reasonably well though (immediate cue in/out commands and no delays in fifos/buffers) [09:43:23 CEST] <andrey_turkin> libav merges seem to have stalled ( I guess pending h264 regression resolution? [09:47:31 CEST] <mateo`_> andrey_turkin: yes, the current commit being merged is problematic (and cause regressions) [09:55:00 CEST] <andrey_turkin> that's unfortunate. I was looking forward to recent batch of qsv patches ( [10:06:13 CEST] <nevcairiel> one other reason is that ubitux was busy the recent days [10:31:13 CEST] <ubitux> yeah i'm pretty busy currently [10:31:18 CEST] <ubitux> maybe i'll have time this week end [10:31:33 CEST] <ubitux> but i'm really not satisfied with reverting most of the commit to get it work in ffmpeg [10:31:42 CEST] <ubitux> it will only delay things [10:50:18 CEST] <nevcairiel> did you see michaels patch on top of that? [10:51:42 CEST] <ubitux> i only see one removing the code repositionning [11:03:44 CEST] <nevcairiel> ubitux: http://pastebin.com/t0D0aZV7 .. it basically adds a few security checks back that were lost, and moves the function call back to its original position - but keeps the refactoring into its own function [11:04:49 CEST] <nevcairiel> not sure if that counts as reverting most of it, the diff seems acceptably small [11:06:11 CEST] <ubitux> yes that's what i was talking about [11:06:21 CEST] <ubitux> not moving that code might have consequences in the future [11:06:37 CEST] <nevcairiel> not every changing coming from the other side has to be taken as flawless and issue free :p [11:06:38 CEST] <ubitux> it means they can execute that function in that particular place [11:06:40 CEST] <ubitux> while we can't [11:06:57 CEST] <ubitux> i don't know [11:07:07 CEST] <ubitux> they don't trigger the same crash we have [11:07:30 CEST] <nevcairiel> they also dont play a variety of files we can, so maybe it just bails out earlier [11:09:02 CEST] <ubitux> maybe, but i didn't want to make that assumption without verification [11:09:03 CEST] <nevcairiel> there is at least one security check that was just flat out removed in the current merge, not sure if that alone helps already [11:43:32 CEST] <ubitux> nevcairiel: if you think that's the best/least worse way to handle it, feel free to go ahead and commit [11:43:40 CEST] <ubitux> i'll continue the merging this week end probably [11:46:18 CEST] <nevcairiel> i dont have a broken sample, so i cant really say with any certainty [13:06:57 CEST] <ubitux> nevcairiel: ask michael [15:14:20 CEST] <BBB> michaelni: you didnt respond to my request to revert the ppc64 simd patch (the first one, which you merged, iirc) [15:14:25 CEST] <BBB> michaelni: whats your opinion? [15:38:51 CEST] <cone-560> ffmpeg 03Hendrik Leppkes 07master:c3e9b098e12b: h2645_parse: only read avc length code at the correct position [15:38:51 CEST] <cone-560> ffmpeg 03Hendrik Leppkes 07master:83a940e7fb96: h2645_parse: don't overread AnnexB NALs within an avc stream [15:41:54 CEST] <nevcairiel> should really find out what kind of crappy software writes mp4s with annexb NALUs [15:45:52 CEST] <Compn> hmm, mips optimizaitons http://elinux.org/CI20_MPlayer [15:48:48 CEST] <ubitux> wrong channel [15:49:27 CEST] <ubitux> or are they patching libav* dumped inside their mplayer repo? [15:50:11 CEST] <nevcairiel> probably [15:50:57 CEST] <nevcairiel> yeah there is all sorts of crazy custom code in avcodec et al [15:51:17 CEST] <Compn> yes they have their own avcodec [15:51:30 CEST] <Compn> not sure if those have already been backported here tho [15:51:39 CEST] <nevcairiel> those are not backportable [15:51:44 CEST] <nevcairiel> they hacked them in everywhere [15:51:49 CEST] <nevcairiel> no clean integration anywhere [15:51:50 CEST] <Compn> mips32 [15:52:03 CEST] <Compn> ah well, we should keep a list for interested parties [15:52:09 CEST] <ubitux> no [15:52:52 CEST] <nevcairiel> its also one huge code dump from 2014 or so, no history before that, which covers the majority of changes [16:40:30 CEST] <michaelni> BBB, didnt reply as i dont really know whats best [16:40:47 CEST] <BBB> ok& so how do you suggest we move forward? [16:40:55 CEST] <BBB> want to ask third-person opinions? [16:41:01 CEST] <BBB> do nothing seems a bad idea [16:41:53 CEST] <j-b> BBB: what's the issue? [16:42:09 CEST] <BBB> whether to revert the first ppc64 patch [16:42:14 CEST] <BBB> from that guy that threatened ubitux [16:42:21 CEST] <j-b> The code is correct? [16:42:24 CEST] <BBB> theres little-to-no performance gains [16:42:28 CEST] <BBB> and the code seems highly inefficient [16:42:33 CEST] <BBB> (gains vs. c) [16:43:01 CEST] <j-b> who benched it? [16:43:02 CEST] <nevcairiel> it is otherwise technically correct, BBB is just worried it might hamper efforts of some future ppc64 person [16:43:04 CEST] <BBB> so I prefer to revert it and leave the bug (#5570) open so other people can work on it without having to bother with existing code that is probably doing it fundamentally wrong and thus serves as a poor example [16:43:19 CEST] <BBB> the guy himself benched it [16:43:35 CEST] <BBB> he gets like 0.9-1.25x speed vs. c whereas sse2 gives ~4x [16:43:44 CEST] <BBB> the 0.9x is especially worrying because it means it got slower [16:43:47 CEST] <j-b> wut? [16:43:48 CEST] <j-b> lol [16:43:53 CEST] <BBB> so I want to revert it [16:43:58 CEST] <michaelni> the first patch was alwayys > 1 but not much bigger [16:44:10 CEST] <michaelni> otherwise BBB explained the situation well [16:44:13 CEST] <BBB> oh ok I didnt know (he didnt report it publicly in emails) [16:44:18 CEST] <BBB> (or did he?) [16:44:26 CEST] <nevcairiel> i think there were numbers in one mail [16:44:29 CEST] <michaelni> i think in the mail i linked IIRC [16:44:37 CEST] <nevcairiel> but he didnt bench using START_TIMER so its an unusual format [16:44:44 CEST] <ubitux> j-b: he was probably motivated by the bounty [16:44:54 CEST] <BBB> ubitux: thats not an issue [16:44:59 CEST] <BBB> if people get paid, thats fine [16:45:02 CEST] <BBB> but the code needs to be good [16:45:04 CEST] <ubitux> of course [16:45:29 CEST] <ubitux> i'm just proposing an explanation for the why he may not have care so much about the quality [16:45:52 CEST] <BBB> fair enough [16:45:54 CEST] <j-b> I'd argue it should not have been merged, but I don't see the reason to revert it, unless the code is really shitty [16:46:02 CEST] <BBB> its really shitty :-p [16:46:05 CEST] <nevcairiel> i wonder if IBM might care that they got a measily 20% speed up at best [16:46:19 CEST] <j-b> BBB: really? [16:46:24 CEST] <BBB> I wouldnt be surprised if the bounties are managed by non-coders [16:46:29 CEST] <BBB> which means they dont care [16:46:37 CEST] <BBB> they just want a checkmark on a piece of paper [16:46:45 CEST] <BBB> [ ] ffmpeg swscale input has simd [16:46:48 CEST] <BBB> [v] [16:46:52 CEST] <BBB> right? [16:46:57 CEST] <nevcairiel> i guess [16:48:24 CEST] <jkqxz> I still think there must be something else going on. The code doesn't appear to be that bad - it's a simple translation which should gain more than it did, even if it has significant micro issues. [16:49:17 CEST] <BBB> my impression is that at least in the code that I reviewed, its not confirmed that all code actually runs in simd vector instructions [16:49:26 CEST] <jkqxz> But yes: if noone is going to work on it further, it should probably be reverted so that the slate is clean if someone else wants to have a go. [16:49:27 CEST] <BBB> some code - I think! - runs in scalar [16:49:40 CEST] <BBB> so theres a vector - scalar - vector transition going on in a few places [16:49:58 CEST] <BBB> and because he does it in c (using c language, not intrinsics) its invisible [16:50:05 CEST] <BBB> the one I reviewed, he uses * [16:50:12 CEST] <BBB> on straight integers [16:50:25 CEST] <BBB> most simd sets have no int*int multiplication instruction [16:50:33 CEST] <BBB> they have word*word->int or so [16:50:38 CEST] <BBB> (with horiz. add) [16:50:41 CEST] <BBB> or something like that [16:50:52 CEST] <BBB> but thats invisible because he mixed C and intrinsics [16:50:59 CEST] <BBB> and somehow it doesnt give compiler warnings [16:51:22 CEST] <BBB> (thats my hunch, I tried verifying it through disassembly but that looks so horridly large that I couldnt make sense out of it - plus its not my job) [16:52:37 CEST] <BBB> it also doesnt explain why other functions are slow, but maybe add has the same issue (he uses += on vector int, instead of intrinsics) [16:52:58 CEST] <BBB> again, I didnt confirm, but a 1.25x speed improvement over c for simd is not something we should be happy about if other archs get 4x [16:54:40 CEST] <nevcairiel> I would honestly be surprised if compilers warned about such things [16:54:50 CEST] <nevcairiel> it would be nice for sure [16:55:02 CEST] <michaelni> has it been confirmed auto vectorization was disabled for C ? [16:55:16 CEST] <andrey_turkin> there is an assembler for Power8 with simd support, right? gas should work? I'd say revert it and wait for someone to write it in assembly. This way at least there won't be any doubts about compiler efficiency [16:56:44 CEST] <BBB> I think andrey_turkin is on to something [16:56:50 CEST] <ubitux> all existing ppc optim in ffmpeg are in intrinsics, aren't they? it shouldn't be a reason to revert [16:57:10 CEST] <nevcairiel> all other ppc optimizations are probably 10 years old though [16:57:22 CEST] <ubitux> who can bench ppc code here? [16:59:51 CEST] <BBB> michaelni: no (I mentioned that in one of my emails also) [17:06:52 CEST] <jkqxz> IBM notionally offers free access to some developer machines, though I don't know how many hoops you have to jump through to use them. [17:10:40 CEST] <michaelni> IIUC the patch broke build on some configuration, if that isnt fixed that would be a unambigous reason to revert [17:12:08 CEST] Action: andrey_turkin almost considers learning vsx [17:33:38 CEST] <BBB> andrey_utkin: not that I want to tell you what to do, but it may be more useful to learn something that is actually, yknow, useful :-p [17:33:54 CEST] <BBB> michaelni: the mailinglist suggests that got fixed already [17:35:26 CEST] <BBB> j-b: yay registration is open! [17:36:49 CEST] <BBB> j-b: flights only $800, nice [17:37:43 CEST] <j-b> BBB: please buy it in British Pounds, it soon will be $0 [17:38:03 CEST] <BBB> I dont think BA flies there directly :( [17:39:02 CEST] <j-b> it was a joke :) [17:42:39 CEST] <BBB> it was a good idea [17:42:55 CEST] <Compn> registration time eh [17:42:59 CEST] <BBB> if I buy fx futures, I can buy now and pay later [17:43:09 CEST] <BBB> (when BP -> 0) [17:43:31 CEST] <Compn> family member wants me to drive her from berlin to lviv, ukraine... [17:44:12 CEST] <Compn> anyone been to poland? how is it ? [17:44:15 CEST] <BBB> michaelni: so I think we still dont have a decision on the first ppc64 patch from that guy [17:44:22 CEST] <BBB> michaelni: think about it for a bit so we can decide and move on [17:45:25 CEST] <cone-560> ffmpeg 03Matthieu Bouron 07master:0f2654c9a3ea: lavc: add mediacodec hwaccel support [17:47:48 CEST] <j-b> 17:42 <@BBB> if I buy fx futures, I can buy now and pay later [17:47:52 CEST] <j-b> I'd argue you should :) [17:48:03 CEST] <j-b> I don't see how the pound can increase :) [17:48:19 CEST] <j-b> Compn: you must see Krakovia. Warsaw is dead boring [17:49:04 CEST] <BBB> j-b: you guys take care of hotel right? [17:49:11 CEST] <BBB> (booking) [17:49:34 CEST] <j-b> yep [17:49:39 CEST] <BBB> ty [17:49:41 CEST] <j-b> except for you, though [17:49:44 CEST] <j-b> /s [17:50:01 CEST] <BBB> :'( [17:50:24 CEST] <Compn> j-b : ok, yes thats what i was thinking warsaw was like. will put krakovia on the list. thanks :) [17:50:56 CEST] <Compn> j-b : btw do you have idea about how much usa to berlin should cost? i havent looked at ticket prices but it says ask :P [17:51:39 CEST] <BBB> j-b: jfk-berlin starts at $796 [17:51:42 CEST] <BBB> oops [17:51:47 CEST] <BBB> Compn: jfk-berlin starts at $796 [17:52:05 CEST] <BBB> (direct) [17:52:38 CEST] <BBB> Compn: what airport do you fly from? [17:52:43 CEST] <Compn> dtw ( detroit) [17:53:09 CEST] <iive> BBB: it would be good if you could prove your suspicions [17:53:17 CEST] <Compn> which is a hub, so i can get most direct flights :) [17:53:40 CEST] <iive> BBB: assembler output should be enough to see if there is indeed mix of vector and scalar ops. [17:53:54 CEST] <iive> BBB: a real benchmark too. [17:54:05 CEST] <BBB> holy shit youll pay $1038 but with 2 stops :-o [17:54:10 CEST] <Compn> lol [17:54:39 CEST] <BBB> one-stop is $1236 [17:54:44 CEST] <BBB> 1297 actually [17:54:55 CEST] <BBB> with united airlines [17:55:09 CEST] <BBB> american is same price [17:55:17 CEST] <BBB> (arent they the same company?) [17:56:06 CEST] <Compn> no non stops! wow. [17:56:19 CEST] <Compn> i'm searching nwa (aka delta klm now) [17:56:26 CEST] <Compn> dunno all of the airlines are merging [17:56:55 CEST] <Compn> i can get non stop to japan but not berlin :V [17:58:15 CEST] <Compn> any particular difference of BER or TXL (berlin-tegel) ? [17:58:40 CEST] <BBB> no ide [17:58:41 CEST] <BBB> a [17:58:57 CEST] <Compn> my stop would either be amsterdam or cdg france [17:59:18 CEST] <Compn> wonder what the better airport to switch would be ? [18:01:52 CEST] <BBB> I would say ams but Im dutch so Im biased :-p [18:02:34 CEST] <Compn> i mean, are there usual slowdowns or air worker strikes or bad weather at AMS airport ? [18:02:43 CEST] <Compn> is more my question [18:03:11 CEST] <ln-> Compn: BER is an airport that has not been opened yet. [18:03:48 CEST] <ln-> https://en.wikipedia.org/wiki/Berlin_Brandenburg_Airport [18:04:46 CEST] <BBB> Compn: oh, I think this is summer so you should be fine [18:05:00 CEST] <BBB> Compn: strikes are by its very nature unannounced so hard to say [18:05:19 CEST] <BBB> Compn: french typically strike more than dutch but j-b might feel offended by that [18:05:19 CEST] <Compn> ln- : ah, flight website confused me, yes setting BER sends me to TXL anyway. ok thanks [18:06:01 CEST] <Compn> BBB : i just wasnt sure if netherlands was a country that had strikes. i know france does [18:06:10 CEST] <kierank> 4:37 PM <"j-b> BBB: please buy it in British Pounds, it soon will be $0 [18:06:12 CEST] <kierank> :( [18:06:13 CEST] <Compn> and usa of course :) [18:06:35 CEST] <BBB> netherlands has strikes, but proportionally lower than in france from what I recall [18:07:10 CEST] <Compn> also customs would be nice to know about [18:07:28 CEST] <Compn> cdg customs was fine. sometimes long lines [18:07:55 CEST] <Compn> i probably dont have to go through customs with a connecting flight but :P [18:14:11 CEST] <j-b> kierank: haha. [18:14:13 CEST] <j-b> sorry :) [18:17:15 CEST] <BBB> kierank: sorry dude :( I really do feel bad for your country [18:17:40 CEST] <j-b> (I don't. For once that we are not the stupids) [18:17:51 CEST] <BBB> now now now [18:19:26 CEST] <michaelni> BBB, it would be nice to know how far the code is from whats achiveable before reverting. if its a third of the speed what a ppc can do then revert to get a clean slate seems to make more sense than if its 30% below whats achviveable. [18:19:49 CEST] <BBB> Im going to say 4x should be achievable [18:20:02 CEST] <BBB> by a knowledgeable person who is willing to dig into this a little [18:20:21 CEST] <BBB> for the function I analyzed (rgb24toy) [18:20:32 CEST] <Compn> j-b : oh , lol. in america we just call it 'krakow' [18:20:33 CEST] <BBB> others probably similar, theyre straightforward vector functions [18:20:42 CEST] <Compn> i thought krakovia was some other town D: [18:20:44 CEST] <Compn> ehe [18:21:33 CEST] <kierank> 5:17 PM <"j-b> (I don't. For once that we are not the stupids) [18:21:38 CEST] <kierank> :) [18:21:56 CEST] <BBB> didnt french rurals vote for le pen? [18:24:38 CEST] <j-b> not yet [18:24:47 CEST] <j-b> 2017 will be the French-stupid one [18:24:54 CEST] <j-b> 2016 is UK-US-stupidity [18:25:01 CEST] <j-b> please leave us one year of laughing [18:25:07 CEST] <BBB> hey we still have a few months of sanity left [18:25:16 CEST] <BBB> dont judge us before we do something stupid [18:25:16 CEST] <j-b> TRUMP! MAGA! [18:25:30 CEST] <BBB> trump is a disaster only in november [18:25:40 CEST] <BBB> if the earth goes down, please let us have some fun on it before that? [18:25:54 CEST] <j-b> yeah, before, please continue killing yourselves with guns and the police [18:26:03 CEST] <BBB> manhattan has sensible gun laws [18:26:15 CEST] <j-b> anyway, next year, French will be the stupid with LePen [18:26:19 CEST] <BBB> what they do in other parts of the country is their problem :-p [18:30:12 CEST] <michaelni> is there someone who could benchmark VSX PPC against (non auto vectored C) ? but either way iam happy with whatever the people prefer to do with patch 1 [18:31:53 CEST] <BBB> michaelni: I would argue thats not our job [18:32:00 CEST] <BBB> michaelni: thats the job of the person submitting the patch [18:32:12 CEST] <jamrial> michaelni: if nobody can bench and since it's confirmed it broke some setups, then it should be reverted, IMO [18:32:13 CEST] <BBB> michaelni: after all, he has knowledge of ppc64 simd instructions and toolchains [18:32:36 CEST] <jamrial> also, the person that submitted the code proved to be an asshole [18:32:44 CEST] <jamrial> what the fuck was all that anyway? [18:33:09 CEST] <Compn> it is better to forgive and forget than to insult and ridicule but ok :P [18:33:11 CEST] <BBB> yeah that was shitty [18:33:17 CEST] <jamrial> insulting and threatening devs? WTF [18:33:44 CEST] <kierank> jamrial: yeah, terrible [18:33:56 CEST] <kierank> he should do some work on the bugtracker, that will remedy the problem [18:34:53 CEST] <BBB> ??? [18:35:06 CEST] <kierank> maybe move to austria as well [18:35:30 CEST] <BBB> & [18:35:34 CEST] <Compn> people like to hold grudges [18:35:35 CEST] <jamrial> the fact he accused people of "interjecting" while "being nobody" makes me think he's unaware that the review process is not a one on one process [18:36:10 CEST] <kierank> point is the double standard in ffmpeg is truly shocking [18:36:11 CEST] <BBB> kierank: lets stay nice for a bit please? [18:36:21 CEST] <BBB> I agree that we have issues [18:36:54 CEST] <BBB> and I agree theres a few people we should probably ban for violating the CoC rules [18:37:05 CEST] <Compn> retroactively [18:37:11 CEST] <Compn> ? [18:37:48 CEST] <BBB> maybe. we can vote on it, right? [18:38:04 CEST] <BBB> laws are often implemented in response to actual events anyway [18:38:17 CEST] <BBB> were not a legal system, were a small community, we can do whatever we want [18:38:25 CEST] <BBB> what are they gonna do, sue us? good luck on that [18:38:34 CEST] <iive> laws are never applied retroactively, and for a good reason. [18:39:16 CEST] <durandal_1707> we are in anarchy [18:39:54 CEST] <jamrial> i don't think anyone ever threatened a dev before, especially not for something as stupid as criticizing a patch, so nothing from this guy should be accepted from now on [18:40:15 CEST] <BBB> jamrial: +1 to that [18:40:30 CEST] <Compn> or we could try to teach him to be polite ? [18:40:40 CEST] <BBB> :( [18:40:42 CEST] <Compn> if someone wanted [18:43:23 CEST] <jamrial> Compn: teach him to be polite for what? [18:43:28 CEST] <jamrial> "please, use nicer words next time you threaten someone"? [18:45:44 CEST] <Compn> maybe no one ever taught him that was rude to threaten someone else [18:46:29 CEST] <Compn> just playing devils advocate here jamrial [18:46:38 CEST] <Compn> i dont know. [18:50:09 CEST] <BBB> I dont think we want such people here [18:50:27 CEST] <BBB> its not nice to threaten someone is like saying its not nice to point a gun at someone or its not nice to hit someone [18:50:34 CEST] <BBB> you teach that to babies, maybe toddlers [18:50:42 CEST] <BBB> after that, you are supposed to know that [18:51:43 CEST] <jamrial> no, we don't want them. but we tend to have trouble getting rid of that kind of people [18:54:04 CEST] <BBB> I think this one went off by himself [18:54:08 CEST] <BBB> so at least that problem is solved [19:17:19 CEST] <BtbN> I have no idea what that omx report is talking about. Does it watermark? Does it show something on the display? [19:18:07 CEST] <nevcairiel> BtbN: i assume they start a transcode and for some reason it ends up on screen? :D [19:18:37 CEST] <BtbN> That would be an interesting side effect. [19:32:50 CEST] <nevcairiel> for sure [20:58:10 CEST] <Yuken> How would I go about compiling ffmpeg with NVENC support under Linux? [20:58:25 CEST] <nevcairiel> grab the header, put it somewhere ffmpeg finds it, enjoy [21:00:34 CEST] <jkqxz> Also --enable-nvenc; it isn't autodetected. [21:28:21 CEST] <friki2015> hi, the compile option "--enable-decklink" requieres an extra library. where can i get it? [21:30:44 CEST] <Compn> friki2015 : i checking [21:32:24 CEST] <Compn> Blackmagic DeckLink SDK [21:32:36 CEST] <Compn> http://software.blackmagicdesign.com/SDK/Blackmagic_DeckLink_SDK_10.3.1.zip [21:32:40 CEST] <Compn> possibly. [21:32:55 CEST] <Compn> if you are building on windows theres this, https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=1823 [21:33:02 CEST] <friki2015> thanks, i'll try [21:33:16 CEST] <Compn> maybe this helps too , https://github.com/dche/ffmpeg-decklink [21:33:21 CEST] <friki2015> i'm trying to do it in Debian [21:33:36 CEST] <friki2015> i'll check the link anyway :) [21:36:36 CEST] <friki2015> the zip link seems to stop working [21:41:09 CEST] <Compn> must be on their site somewhere :D [21:46:08 CEST] <friki2015> i need the serial number to download the lib (i'm working remote with the server). Is it the only way to capture video using a blackmagic card? [21:51:36 CEST] <Compn> try asking lu_zero in #videolan [21:51:41 CEST] <Compn> i think he knows about decklink [21:52:31 CEST] <friki2015> thanks [22:43:05 CEST] <BBB> there, my first avx2 patch [22:45:57 CEST] <Gramner> you got a rig with a avx2-capable cpu now? :D [22:47:54 CEST] <BBB> I bought a shiny new laptop [22:48:04 CEST] <BBB> nobody wants to buy me one so I just bought me one myself [22:50:56 CEST] <durandal_1707> FFmpeg now have money [23:00:50 CEST] <BBB> I think people objected to me wanting a shiny high end macbook pro [23:02:24 CEST] <ubitux> vp9_inv_dct_dct_16x16_add_8_1_sse2: 638.6 [23:02:27 CEST] <ubitux> vp9_inv_dct_dct_16x16_add_8_1_avx: 661.2 [23:02:28 CEST] <ubitux> heh [23:02:39 CEST] <BBB> I know, something is weird there [23:02:48 CEST] <BBB> I didnt really check, since I dont really care [23:02:54 CEST] <ubitux> doesn't happen with the other ones though [23:03:00 CEST] <ubitux> (unless i misread) [23:03:03 CEST] <BBB> and only for the very small sub-idcts [23:03:38 CEST] <Gramner> random cache line alignment shenanigans or stuff like that usually [23:03:52 CEST] <BBB> 8_2 and 8_1 [23:04:12 CEST] <BBB> Gramner: but they use the same rodata and input data and output buffers [23:04:28 CEST] <Gramner> code, not data [23:04:31 CEST] <Gramner> then you change some code in a different file and now the result is the opposite [23:04:39 CEST] <Gramner> because it linked at a different position [23:04:52 CEST] <BBB> oh I See [23:04:55 CEST] <BBB> could be, yes [23:05:21 CEST] <ubitux> (ah with ssse3/avx in 8_2 indeed) [23:06:06 CEST] <ubitux> nice improvement with avx2 btw [23:08:26 CEST] <BBB> I was quite happy with it, yes [23:08:27 CEST] <nevcairiel> indeed, numbers look good [23:08:31 CEST] <BBB> 32x32 should see similar improvements [23:08:35 CEST] <BBB> (I hope?) [23:08:43 CEST] <BBB> maybe slightly less because you still have to store [23:08:49 CEST] <BBB> but 1.5x would be pretty good still [23:10:31 CEST] <BBB> and then loopfilter would _probably_ also benefit from it, but thats trickier because of the way the loopfilter is laid out in vp9 [23:10:52 CEST] <BBB> I can probably figure out how to do it but I need to study that code a bit again, so maybe Ill just not bother and write 10/12bpp asm instead [23:11:24 CEST] <BBB> oh and directional intra pred, but I feel soooo lazy about doing that [23:12:10 CEST] <nevcairiel> how big is intra pred in overall cycle use? [23:13:56 CEST] <Gramner> BBB: why mova + pmovzx instead of doing just the latter from memory? [23:14:11 CEST] <BBB> is that possible? [23:14:15 CEST] <jamrial> yeah [23:14:15 CEST] <BBB> I didnt know that was possible [23:14:17 CEST] <Gramner> sure [23:14:18 CEST] <BBB> :-p [23:14:24 CEST] <BBB> nevcairiel: very tiny [23:14:39 CEST] <BBB> nevcairiel: and most intra pred is dc, tm is secondary, and directional is a distant last [23:14:47 CEST] <BBB> nevcairiel: as is also the case for hevc/h264/... [23:14:55 CEST] <BBB> (although they use planar instead of tm) [23:16:09 CEST] <BBB> Gramner: fixed locally [23:16:41 CEST] <BBB> if you have any ideas on how to prevent that vpermq in there, Id love to hear it [23:16:49 CEST] <jamrial> BBB: did you get into any issues running checkasm --bench? last time i tried it complained about "failed to issue emms" with a vp9 loop_filter test [23:16:52 CEST] <Gramner> BBB: also a minor nit; no need for the v prefix in the pmovzx instructions [23:17:06 CEST] <BBB> changed that also [23:17:17 CEST] <BBB> jamrial: I commented everything out, so dunno :-p [23:17:26 CEST] <BBB> (I only ran the 16x16 idct for vp9) [23:17:26 CEST] <jamrial> ah [23:18:14 CEST] <durandal_1707> BBB: nobody objected [23:18:39 CEST] <nevcairiel> i dont think he ever officially asked =p [23:19:09 CEST] <BBB> I feel the money should be used for more productive affairs rather than my love for shiny apple crap [23:19:40 CEST] <BBB> like, lets use it for sponsoring more devs to attend vdd, or have a dinner there [23:19:44 CEST] <BBB> or something like that [23:19:56 CEST] <BBB> call it a ffmpeg and libav reunification dinner And invite the libav crew also [23:20:10 CEST] <BBB> and then Ill pay for the laptop myself [23:20:45 CEST] <BBB> so I guess Ill do avx2 32x32 idct next? [23:21:13 CEST] <BBB> I think last time I did the 32x32 I vowed to never touch it again [23:21:15 CEST] <BBB> I hate that thing [23:21:19 CEST] <BBB> its soooooo big [23:22:11 CEST] <jamrial> probably the same reason nobody wants to touch hevc idct [23:22:18 CEST] <BBB> Ill touch it [23:22:22 CEST] <BBB> but I want some company to pay me :-p [23:22:32 CEST] <jamrial> heh [23:22:44 CEST] <nevcairiel> arent all the idcts somewhat similar? [23:22:56 CEST] <BBB> no [23:22:57 CEST] <TD-Linux> HEVC uses an actual matrix multiply [23:23:00 CEST] <BBB> the fdcts are similar [23:23:02 CEST] <BBB> (can be) [23:23:07 CEST] <BBB> but the idct is matrix-based, yes [23:23:11 CEST] <BBB> (for hevc) [23:23:17 CEST] <nevcairiel> i see [23:23:19 CEST] <BBB> no idea why they did it that way, its ridiculously slow [23:23:29 CEST] <BBB> I guess its b/c for hardware its all the same [23:23:51 CEST] <nevcairiel> if its all the same for hardware, why not use one that is faster :D [23:23:52 CEST] <TD-Linux> nah it's slower for hardware too [23:24:14 CEST] <BBB> oops again then [23:24:33 CEST] <BBB> recall how jason was so upset that they broke the idct ordering in vp8 so you need to transpose twice in your assembly? [23:24:39 CEST] <BBB> guess what they did in hevc& [23:26:24 CEST] <BBB> I guess theres quite a bit of strange stuff in hevc so this is just part of a pattern [23:27:42 CEST] <Gramner> BBB: it's possible avoid that vpermq by using 2x vpmovwb instead of packuswb + vpermq + mova + vextracti. unfortunately that requires avx512bw though ;) [23:28:12 CEST] <BBB> vpmovwb?!?!? [23:28:15 CEST] <BBB> that sounds amazing [23:28:17 CEST] <jamrial> then he can't avoid it :p [23:28:26 CEST] <BBB> so thats like a cross-lane packuswb? [23:28:30 CEST] <bofh_> avx512 is basically KNL SIMD, so of course it's amazing [23:28:39 CEST] <bofh_> sadly it's available on like nothing so far [23:29:09 CEST] <jamrial> avx512 skylake xeons should be out this year, afaik [23:29:10 CEST] <BBB> I guess its a cross-lane packuswb to memory [23:29:10 CEST] <Gramner> it's the opposite of pmov(s|z)x [23:29:13 CEST] <BBB> sweet [23:29:13 CEST] <nevcairiel> i'm still suspicious if it will be available on the next gen of consumer cpus like some people claim [23:29:28 CEST] <BBB> anyway, yeah, Ill use that once it exists [23:29:41 CEST] <Gramner> it will be in cannonlake unless they do soem last-minute backtracking [23:29:50 CEST] <nevcairiel> so next-next-gen then [23:29:54 CEST] <jamrial> so no kabylake? [23:29:55 CEST] <BBB> will someone buy me a cannonlake macbook pro? [23:30:28 CEST] <Gramner> isn't kaby lake just a fancier pr term for "lets release skylake again" [23:30:55 CEST] <bofh_> even if it's out on cannonlake that still means we need 2 years for it to become popular in actual consumer hardware [23:31:10 CEST] <BBB> is it ok to interleave xmm/ymm register use in v* instructions? [23:31:21 CEST] <BBB> (i.e. theres no slowdown as long as I Dont use non-v instructions?) [23:31:47 CEST] <BBB> I thought it was but want to make sure [23:31:48 CEST] <Gramner> as long as you use vex-encoded instructions (which x86inc will do automatically in avx+ functions) there is no penalty [23:32:00 CEST] <BBB> ok cool [23:32:12 CEST] <BBB> yeah x86inc.asm makes this stuff pretty sweet [23:32:30 CEST] <BBB> the 16x16 is a bit of new macros because the old idct was from memory instead of from registers [23:32:34 CEST] <BBB> so I had to rewrite it [23:32:42 CEST] <BBB> but the 32x32 should be fairly trivial since its from-memory [23:32:51 CEST] <BBB> (so it can use existing infrastructure) [23:33:03 CEST] <bofh_> x86inc makes coding x86 asm not totally painful, it's amazing. [23:34:06 CEST] <TD-Linux> BBB, the matrix does remove the need for the transpose (obviously) and has flat scaling, which I guess is useful if you don't use a QM [23:35:00 CEST] <BBB> the flat scaling is nice from a precision pov, yes [23:35:19 CEST] <BBB> but then they made the coefficients 6 or 7 bit or so [23:35:26 CEST] <BBB> what on earth were they thinking [23:38:59 CEST] <BBB> in my tests, the vp9 roundtrip error for 16x16/32x32 is an order of magnitude better (lower) than the hevc one, which I would attribute to the low coefficient precision [23:38:59 CEST] <jamrial> BBB: wouldn't it be better to merge the sbutterflydqqq into the x86util one, and move the new transpose macro there as well? [23:39:24 CEST] <BBB> jamrial: yes, I just didnt want to recompile all asm files every time I fixed them [23:39:32 CEST] <BBB> jamrial: Im happy to merge the final products in x86util.asm [23:39:45 CEST] <jamrial> alright then [23:39:46 CEST] <BBB> jamrial: you want me to merge the sbutterflydqqq into sbutterfly? [23:39:58 CEST] <jamrial> if possible [23:40:01 CEST] <BBB> like %ifidn %1, dqqq .. %else ..current code.. %endif [23:40:35 CEST] <jamrial> yeah [23:41:22 CEST] <BBB> michaelni: fixed 32bit also [23:41:24 CEST] <BBB> (locally) [23:41:36 CEST] <BBB> jamrial: ok, Ill do that in a bit [23:52:20 CEST] <BBB> jamrial: done locally (move transpose/sbutterflydqqq into x86util.asm, integrate sbutterflydqqq into sbutterfly) [23:53:03 CEST] <jamrial> BBB: thanks :) [23:53:22 CEST] <BBB> if I dont get comments in the next 30 min or so, Ill re-send [00:00:00 CEST] --- Sat Jul 9 2016

1 0

ffmpeg.log.20160708
by burek 09 Jul '16

09 Jul '16

[00:02:06 CEST] <tuxlovesyou> what happened to the qp option? [00:02:21 CEST] <tuxlovesyou> I am trying to do a lossless x264 screen cap [00:02:24 CEST] <c_14> nothing? [00:02:43 CEST] <tuxlovesyou> Unrecognized option 'qp'. [00:02:43 CEST] <tuxlovesyou> Error splitting the argument list: Option not found [00:02:53 CEST] <c_14> works fine here [00:03:11 CEST] <tuxlovesyou> okay [00:04:24 CEST] <tuxlovesyou> http://pastie.org/10901498 [00:05:07 CEST] <tuxlovesyou> I have libx264-10bit installed [00:05:30 CEST] <tuxlovesyou> I followed https://trac.ffmpeg.org/wiki/Capture/Desktop to the tee [00:05:52 CEST] <c_14> your ffmpeg isn't built with libx264 support [00:06:15 CEST] <c_14> you have to specify --enable-libx264 during configure [00:06:36 CEST] <tuxlovesyou> Oh, I think I was trying to mess with libdrc for the wii U [00:06:43 CEST] <tuxlovesyou> let me try and reinstall [00:06:44 CEST] <tuxlovesyou> thanks [00:08:20 CEST] <tuxlovesyou> weird, this is the stock ffmpeg from Arch. It worked last time [00:08:26 CEST] <tuxlovesyou> I guess I have to do a pkgbuild [00:09:28 CEST] <tuxlovesyou> they have a version in the user repos called ffmpeg-full [00:09:35 CEST] <tuxlovesyou> I'm giving that a try first [00:10:34 CEST] <tuxlovesyou> still have to compile it... [00:11:41 CEST] <tuxlovesyou> I wanted to record the historic moment of my first time installing OS X El Capitan on KVM. :/ [00:11:59 CEST] <tuxlovesyou> waiting on the internet more than the computer lol [00:12:59 CEST] <tuxlovesyou> I am going to set the mtune to native :) [00:15:49 CEST] <c_14> run `which ffmpeg' [00:16:05 CEST] <c_14> You might have another ffmpeg binary somewhere in your path hiding the other one [00:22:53 CEST] <tuxlovesyou> Maybe, but I already removed the default one and am compiling [00:23:10 CEST] <tuxlovesyou> I'd hate to waste all of that magic smoke :P [00:26:10 CEST] <tuxlovesyou> lol that's exactly what it was lol [00:26:21 CEST] <tuxlovesyou> I put one in /usr/local/bin [00:26:23 CEST] <llogan> there is no package named ffmpeg-full in the Arch repos. you must be referring to AUR. [00:27:20 CEST] <llogan> although I see no reason to ever use any of the myriad ffmpeg-full* packages in AUR. ENAABLE EVEYRTHGNI! [00:28:03 CEST] <tuxlovesyou> thank you! [00:32:18 CEST] <Protected> Noob question, ffmpeg 3.1.1: I'm trying to convert an mkv with subtitles and chapters to an mp4 with subtitles, but no matter what file I try what seems to end up in the mp4 are the chapters (though ffprobe says it's a "subtitles" stream). Would anyone be willing to help me try to understand what I'm doing wrong? [00:38:58 CEST] <Protected> llogan, correction: Careful examination of the output of the initial conversion to mp4 shows the subtitles are never included in it at all [00:39:20 CEST] <obelisk29> Has anyone encountered any issues with libx264 encoded videos have stuttering issues when playing back in premeire pro? Regular h264 captures work just fine. [00:39:51 CEST] <Protected> I'll stop collecting data at this point, make the paste and hope someone can tell me how to tell ffmpeg to included the subtitles [00:40:13 CEST] <Protected> http://pastie.org/private/srnplakrngapsxhcrrba [00:40:45 CEST] <furq> Protected: you probably need -c:s mov_text [00:40:58 CEST] <furq> oh wait, ass [00:41:04 CEST] <furq> i don't think ass is supported in mp4, you'd need to burn them in [00:41:26 CEST] <furq> maybe ffmpeg can convert from ass to mov_text but you'd lose all formatting [00:41:28 CEST] <Protected> If I'm willing to lose any [00:41:30 CEST] <Protected> It's fine [00:41:46 CEST] <furq> try -c:s mov_text then [00:41:47 CEST] <Protected> I only need to create a test mp4 with subtitles, no matter how simple they are [00:41:50 CEST] <Protected> Alright, 1s [00:43:09 CEST] <Protected> Ok, I have two "subtitle" streams now, that's promising [00:44:02 CEST] <Protected> ffmpeg -i test.mp4 -c srt -map 0:2 test.srt returns the actual subtitles now! I'm going to assume that did the trick, thanks [00:44:13 CEST] <Protected> I had no idea you could specify a codec for the subtitles in just one command [00:44:39 CEST] <furq> it should pick the right format if you use -c:v copy -c:a copy [00:44:46 CEST] <furq> -c copy applies to subtitles as well [00:44:56 CEST] <Protected> It was ignoring them [00:51:05 CEST] <Protected> Would there be a way to get it NOT to include the chapters as a subtitle track in the mp4? [00:51:36 CEST] <obelisk29> I am trying to convert a prores capture file into h264. Our editors usually can edit h264 just fine but the h264 mov that ffmpeg and libx264 produces stutters badly when playing back within adobe premiere. I have tried to copy exactly every setting that the working h264 captures use. The only difference I can see now is that the working h264 captures have is a Reframes of 2 whereas ffmpeg outputs 4. It still stutters and is driving [00:52:55 CEST] <c_14> Protected: -map_chapters -1 ? [00:53:03 CEST] <obelisk29> You'll notice i'm also delaying the audio and mapping the 16 audio channels into stereo, but that shouldn't effect anything and that part is working fine. [00:54:29 CEST] <c_14> obelisk29: upload the output of ffprobe on a working and non-working sample to a pastebin service [00:54:36 CEST] <obelisk29> http://pastebin.com/S5PDj7Ct [00:54:42 CEST] <obelisk29> sorry it chopped my link [00:57:00 CEST] <Protected> Awesome, c_14, thanks [00:58:16 CEST] <obelisk29> Ok here is the ffprobe comparison http://pastebin.com/2Gwfmhgh [00:59:22 CEST] <FishPencil> Trying to extract a f4v stream (from RTMP) from a pcap capture and process it with FFmpeg. Anyone familiar with this? [01:02:59 CEST] <c_14> obelisk29: can you try running the working capture through `ffmpeg -i video.mov -c copy -map 0 -map_metadata -1 out.mov' and seeing if it still works with that [01:05:12 CEST] <obelisk29> you think its a metadata missing issue? I'll do that. [01:05:33 CEST] <c_14> either that, or a slightly different container version/muxing [01:06:51 CEST] <obelisk29> If it doesn't work then that would prove it's a missing metadata issue, I did try copying every metadata tag I could into the output file but it wouldn't copy no matter what I did. [01:08:40 CEST] <obelisk29> What would be my options for version/muxing issue? [01:10:26 CEST] <c_14> Running the files that don't work through something like l-smash/gpac or opening a bug report on trac [01:15:50 CEST] <obelisk29> I'm actually at home and can't get them to test the file until morning are you going to be on chat tomorrow or should I just come back tomorrow and continue with someone else =) [01:16:32 CEST] <obelisk29> If it is a metadata issue how do I copy all the tags to the output file without ffmpeg dropping them? [01:16:32 CEST] <c_14> depends on the timing [01:16:35 CEST] <c_14> I should be here though [01:17:42 CEST] <obelisk29> or at the very least if ffmpeg cant output them is there something I can do in a linux environment to add them back in? [01:17:56 CEST] <obelisk29> all hypothetical of course ;) [01:18:41 CEST] <c_14> If -map_metadata doesn't work, look into using l-smash/gpac. Those should be able to do it [01:19:39 CEST] <obelisk29> Thanks for your help! [03:05:21 CEST] <InsaneCrazyMad> If I want to convert a 3D movie so that I can view it using Google Cardboard, what would be the details of the format I'd be wanting to export to ? [03:07:50 CEST] <InsaneCrazyMad> I am thinking of pairing up the 2013 Wizard of Oz 3D remaster with the 2011 Dark Side of the Moon remaster for Google Cardboard. [04:45:39 CEST] <ornj> How can I change the speed and rotate in the same command? [04:46:04 CEST] <ornj> It seems like -vf "transpose=1 setpts=0.5*PTS" worked but -vf "transpose=1 setpts=0.25*PTS" does not. [04:49:17 CEST] <pzich> so you were able to change the speed, but only to a certain point? [04:50:17 CEST] <ornj> I guess - I mean, I can change the speed as a separate command [04:50:20 CEST] <ornj> and I can rotate [04:50:46 CEST] <ornj> but the two commands together, only 0.5*PTS worked. [04:51:36 CEST] <ornj> Oh, oops [04:51:43 CEST] <ornj> Update, maybe it didn't. [04:51:55 CEST] <ornj> But it didn't choke on my syntax so I guess I assumed it did. [04:51:57 CEST] <ornj> (Whoops.) [04:52:26 CEST] <ornj> So let me modify my original question slightly: Can one change the speed and rotate in the same command? [04:54:32 CEST] <ornj> What is the correct syntax to invoke both: -vf "transpose=PTS" and: -vf "setpts=0.5*PTS" ? [04:54:49 CEST] <ornj> I'm not certain where I'm s'posed to put the quotation mark :-/ [04:58:51 CEST] <ornj> Sorry, figured it out [04:59:04 CEST] <ornj> I think [04:59:06 CEST] <ornj> We'll see [04:59:20 CEST] <ornj> I still don't know what a "chain" is [05:00:33 CEST] <ornj> but commas worked, semicolons didn't :P [08:15:51 CEST] <Vineet> hi! has anyone tried hardcoding hindi subtitles using ffmpeg? [08:16:20 CEST] <Vineet> I'm facing issues with compound letters, they are not getting rendered properly [08:20:08 CEST] <furq> Vineet: ffmpeg uses libass to burn in subs, so if there's a rendering bug it's probably in libass [08:22:42 CEST] <Vineet> furq: will it help if I post the rendered glyph here? [08:23:35 CEST] <Vineet> or asking for it here will be useless, and I should bother libass people? :) [08:24:24 CEST] <furq> there's no harm in asking [08:27:39 CEST] <Vineet> https://www.anony.ws/image/N5aa is the rendered glyph [08:28:04 CEST] <Vineet> ".AG 2$> ? /K *B0G 5?6M5" is how it should have rendered [12:55:42 CEST] <flying_toaster> Hi there [12:56:26 CEST] <flying_toaster> I'm using ffprobe to analyze a h264 + aac HEv2 stream (mov container) and I'm having trouble retrieving the right number of audio channels [12:56:57 CEST] <flying_toaster> using ffprobe -print_format json -show_streams, it outputs : [12:56:59 CEST] <flying_toaster> - Stream #0:0(und): Audio: aac (HE-AACv2) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 46 kb/s (default) [12:57:03 CEST] <flying_toaster> on stderr [12:57:11 CEST] <flying_toaster> and "channels": 1, [12:57:11 CEST] <flying_toaster> "channel_layout": "mono", [12:57:24 CEST] <flying_toaster> in the audio stream object in the json output, on stdout [12:58:08 CEST] <flying_toaster> Is this normal ? [13:02:23 CEST] <c_14> It shouldn't be [13:02:29 CEST] <c_14> Does the file maybe have 2 audio streams? [13:14:43 CEST] <JEEB> HE-AAC is such that if you don't decode enough of the audio you will not get the correct amount of channels [13:31:11 CEST] <flying_toaster> c_14 : no, this is the only audio stream [13:31:53 CEST] <flying_toaster> JEEB : Ok, but in that case, ffprobe is decoding audio enough since it reports correctly on stderr [13:53:58 CEST] <cowai> Hi all, is there a db meter for ffplay/ffmpeg? [13:54:18 CEST] <cowai> All I can find is ebur128 which does not give me db afaik [14:12:29 CEST] <johnnny22> When using "https://devimages.apple.com.edgekey.net/streaming/examples/bipbop_4x3/bipbo…" as an input to ffmpeg, I'm having difficulty having the output start at timecode 0:00 (displayed on the video). Also, if I want it to start at a specific time, it seems to have difficulty finding the right position. Anyone have a trick to help the HLS demuxer seek properly ? [15:01:39 CEST] <johnnny22> I always seem to be offsetted by a couple of seconds :( [15:25:11 CEST] <steward> I can set alpha for RGB color with complex expressions using fontcolor_expr=@0x%{eif... But bordercolor accepts no such? Yet COLORS section of doc seems to say they are all handled the same way. Does bordercolor accept an expression for the alpha? Am I fighting syntax or a lost cause? Many thanks. [15:55:53 CEST] <Kadigan_KSB> Hi. I wanted to ask what the "Past duration X.XXXXXX too large" message is all about, and what can I do to help ffmpeg deal with it? I'm decoding nonstandard(?) video that is 1504x1504px (data from a 360 camera). [15:56:35 CEST] <Kadigan_KSB> I know it's 30000/1001 fps (ie. 29.97) but I can't ensure that that's accurate (it's what I specify as input rate), or that it doesn't fluctuate (as in vfr) [16:57:44 CEST] <Danimal> what causes the image to go blocky briefly, then fix after a second or so? [17:00:33 CEST] <DHE> corruption, until the next I-frame fixes it [17:03:38 CEST] <sybariten> hello! [17:05:08 CEST] <sybariten> trying to do the ol' still-image-to-video-thing .... i've done this a jhundred times i think but now i dont succeed. Heres the first file: bode_1951.png up until bode_2100.png ... i used this: ffmpeg -i %04d.png -start_number 1951 -c:v mjpeg -qscale:v 0 $jacob/bode.avi [17:05:21 CEST] <sybariten> " Could find no file with path '%04d.png' and index in the range 0-4 " [17:06:51 CEST] <furq> -i bode_%04d.png [17:06:57 CEST] <enche> i was curious when looking through the FFMPEG API examples, what are "delayed frames"? [17:07:19 CEST] <enche> and why do they only seem to occur when encoding? [17:07:24 CEST] <enche> are there delayed packets as well? [17:10:37 CEST] <sybariten> furq: that was stupid of me, but still: Could find no file with path 'bode_%04d.png' and index in the range 0-4 ( from ffmpeg -i bode_%04d.png -start_number 1951 ) [17:51:26 CEST] <thadude> Hey all i have question, is there a way to make a subtitle track not forced? [19:50:38 CEST] <obelisk29> Hey c_14 the file stripped of metadata worked just fine. [19:51:38 CEST] <obelisk29> So I guess that means it's a container issue the premiere doesn't like right? [19:57:52 CEST] <CFS-MP3b> I have a stream that ffmpeg is reencoding live (sending it to a wowza instance). I have separate subtitles in a text stream that is also being generated live. Is there a way to have ffmpeg insert those subtitles into the stream that is sent to wowza? [19:58:36 CEST] <latk> I'm trying to match a load of png's of format 0.png 1.png etc, and turn them into a video. Using %d fails, saying it can't find a file path with %d and index 0-4. Why ? [20:01:30 CEST] <obelisk29_> I have an issue regarding prores to h264 videos. Our editors can edit just fine with premiere pro on our h264 live captures, but when they go to edit the prores to h264 video I encoded via ffmpeg they have very choppy playback. [20:01:47 CEST] <latk> http://pastebin.com/dTzVe9h4 [20:02:23 CEST] <obelisk29_> I went on last night and another user suggested I take a working capture and fun it through ffmpeg while stripping it of all metadata. That file worked just fine so it's not a metadata issue. [20:02:54 CEST] <obelisk29_> Here is my encoded file and commands http://pastebin.com/S5PDj7Ct [20:03:38 CEST] <kepstin> latk: that seems fine... are you sure you're running it in the directory which contains the png files? [20:03:47 CEST] <obelisk29_> And here is an ffprobe comparison of the working capture and the stuttering h264 encoded file http://pastebin.com/2Gwfmhgh [20:04:06 CEST] <latk> kepstin: Yep. A different directory with 4 signifiicant figures using %04d works. [20:05:12 CEST] <kepstin> and you don't have any case issues where your files are all named '.PNG' rather than '.png' or anything like that? [20:05:45 CEST] <latk> nope, they are all generated by the same script [20:06:19 CEST] <latk> I guess I will just rerun this script with padding on the file name [20:06:21 CEST] <latk> just it will take 30 mins [20:06:40 CEST] <kepstin> because that error is basically just saying "I tried to open the files 0.png, 1.png, 2.png, 3.png, 4.png and couldn't find any of them." [20:08:03 CEST] <drv> you could run ffmpeg under strace and see what is being passed to open() and/or what error it returns [20:09:10 CEST] <drv> (actually it looks like it's using access() but same idea) [20:12:35 CEST] <obelisk29_> How often is the respectable limit to repeat my question before I post to the user mailing list? [20:16:26 CEST] <c_14> obelisk29_: you can ask on the user ml whenever you want, just don't post here more than every few hours [20:16:40 CEST] <c_14> But I can't think of what else it could be, so it might be a good idea to ask on the ml [20:17:21 CEST] <obelisk29_> Ok thx! [20:56:41 CEST] <jkqxz> obelisk29_: You talk about reference frames in the H.264 stream as being a difference, but you don't say what happens if you reduce the number libx264 is using it to match the other stream? [20:58:45 CEST] <jkqxz> (It certainly sounds like something which could be relevant if the other decoder does not fully support H.264.) [21:01:49 CEST] <obelisk29_> I added the -refs flag and it didnt show any difference when using k-lite mediainfo to display info [21:02:32 CEST] <obelisk29_> especially when the default refs is 3 but in mediainfo is showing as 4 [21:02:43 CEST] <obelisk29_> ReFrames to be exact [21:03:51 CEST] <obelisk29_> So I would love to be able to match it exactly but I wasn't sure how. And everything I found and tried didn't show a difference. [21:04:13 CEST] <lesderid> how do I extract the n-th frame of a video stream with the libav* libraries (in the original pixel format)? I couldn't find any working examples online. it has to be the exact frame, it can't be a frame off [21:07:51 CEST] <jkqxz> Does it work if you use a faster preset (ultrafast or veryfast)? (They disable some features to make it faster, and are therefore a convenient way to get a simpler encode.) [21:09:39 CEST] <obelisk29_> I haven't attempted that I will do that right now. [21:14:35 CEST] <obelisk29_> Format profile : Main@L4 [21:14:35 CEST] <obelisk29_> Format settings, CABAC : Yes [21:14:35 CEST] <obelisk29_> Format settings, ReFrames : 4 frames Still showing 4 ReFrames but I will get our editors to test it now. [21:15:23 CEST] <jkqxz> That's veryfast? [21:15:46 CEST] <obelisk29_> yes veryfast [21:17:55 CEST] <jkqxz> If the test is onerous, ultrafast is probably a better thing to try first (if that works, it's a binary search exercise to find the option which kills it). [21:23:34 CEST] <obelisk29_> the bitrate is hilarious on ultrafast. veryfast still stuttered. trying ultrafast now [21:25:51 CEST] <obelisk29_> Format settings, CABAC : No [21:25:51 CEST] <obelisk29_> Format settings, ReFrames : 1 frame [21:26:38 CEST] <obelisk29_> ultrafast still stuttering. I'm going to try removing all my special filters [21:26:55 CEST] <obelisk29_> apparently the ultrafast is better though... [21:27:07 CEST] <obelisk29_> still not close to working though [21:30:05 CEST] <jkqxz> I think there must be something else to blame, then. Is it expecting an intra-only stream? [21:32:02 CEST] <obelisk29_> I can't find any info on what premiere pro is expecting to find in a h264 encoded file. [21:33:40 CEST] <Mavrik> Do you have a VFR file by any chance? [21:37:08 CEST] <obelisk29_> VFR file? [21:40:04 CEST] <jkqxz> Oh, that's a good idea. Variable FrameRate, i.e. the time between frames is not uniform. Try adding "-r <number>" ("-r 30", maybe?) before the "-i" to rewrite the timestamps to be uniform. [21:41:39 CEST] <Mavrik> obelisk29_, variable framerate, not constant framerate like 30fps/24fps etc. [21:41:45 CEST] <Mavrik> Most phone videos are VFR [21:41:51 CEST] <Mavrik> And a lot of software hates that [21:43:23 CEST] <obelisk29_> Ok I'm testing those options now. I'm just copying the audio stream ruling out audio codec messing it up, then I'll test the vfr setting [21:44:45 CEST] <yahsharahla> can ffmpeg be used for screen recording with webcam veiwer? [21:45:19 CEST] <obelisk29_> It's a production capture file I'd be very surprised if the source was vfr, but who knows =) [21:47:41 CEST] <Kadigan> So I was in here earlier asking about messages of "Past duration 0.XXXXXX too large" and whether there was something I could do to fix that -- I am assuming ffmpeg doesn't understand something about the video, and maybe I could inform it better? [21:47:58 CEST] <yahsharahla> I guess no one understands my question [21:48:20 CEST] <Kadigan> yahsharahla: what was Your question? [21:48:38 CEST] <lesderid> yahsharahla: you asked it three minutes ago. be patient [21:49:03 CEST] <yahsharahla> ok @lesderid so you can answer [21:49:44 CEST] <lesderid> what's 'webcam viewer'? [21:49:47 CEST] <jkqxz> ffmpeg can be used for screen recording, yes. I don't know what you mean by a "webcam viewer" though. [21:50:46 CEST] <yahsharahla> meaning the front camera is also recording while screen recording is taking place [21:52:28 CEST] <Kadigan> Does (s)he want to record the screen w/ a camera window up, and it's not working? [21:52:47 CEST] <Kadigan> (like, black instead of video there?) [21:56:09 CEST] <obelisk29_> Ok adding -r 30 didn't help but removing all the extraneous processing did deliver some interesting results. [21:56:26 CEST] <obelisk29_> ffmpeg -r 30 -i test/20160522_sunam_mlc_rhb.mov -pix_fmt yuv420p -vcodec libx264 -crf 18 -acodec copy -preset medium -t 00:04:00 encoded/testme4.mov [21:56:51 CEST] <obelisk29_> that produced a file that almost fast forwarded by itself [21:57:08 CEST] <obelisk29_> I think the audio has something to do with it but im not sure what [21:58:46 CEST] <obelisk29_> I'm really stuck now because doing it two ways produces two buggy outcomes. [21:59:51 CEST] <Kadigan> obelisk29_: what's the issue? (I just came in) [21:59:59 CEST] <Kadigan> Audio/video desync? [22:00:22 CEST] <obelisk29_> I have working h264 live capture that our editors can edit just fine in premiere pro [22:00:59 CEST] <obelisk29_> But when I try convert the old prores captures into h264 via ffmpeg they stutter really badly in within premiere [22:01:08 CEST] <wiak> any idea why i keep getting av_interleaved_write_frame(): Broken pipe when i use https://awesome.nwgat.ninja/misc/ffmpeg.paste it streams pretty nicely in opera, firefox and chrome yet randomly crashes ;/ [22:01:34 CEST] <wiak> ffmpeg crashes not browsers* [22:01:46 CEST] <wawrek> Can we apt-get install FFmpeg with built in support fot libvorbis and libtheora without having to compile? [22:01:54 CEST] <obelisk29_> http://ffmpeg.org/pipermail/ffmpeg-user/2016-July/032712.html [22:01:56 CEST] <Kadigan> obelisk29_: that's actually weird. ProRes is designed to be a constant framerate, constant bitrate codec. Things like that shouldn't happen... in theory. [22:02:24 CEST] <obelisk29_> Yes the playback stutters and sometimes audio drops out completely [22:02:46 CEST] <Kadigan> obelisk29_: have You tried splitting it into audio and video tracks, and then inserting them separately? [22:02:51 CEST] <Kadigan> Since it's going into an NLE anyway... [22:03:09 CEST] <obelisk29_> Premiere reacts differently to it as well, instead of generating peak files like it does with the other captures it conforms it. [22:03:25 CEST] <obelisk29_> I haven't done that [22:03:27 CEST] <wiak> remuxing might also help, but dunno i dont use prores sorry [22:03:53 CEST] <obelisk29_> That would rule out which codec premiere can't handle [22:04:31 CEST] <wiak> is it only premiere? [22:04:37 CEST] <Kadigan> It may also be that PP doesn't quite like .mov files in general. Tried .mp4? [22:04:51 CEST] <obelisk29_> Yes it plays fine in quicktime and vlc [22:05:06 CEST] <obelisk29_> After effects doesn't like it either [22:05:15 CEST] <wiak> okey that rules out the file, the it might adobe issue [22:05:16 CEST] <Kadigan> I've had some issues with porting Mac-made ProRes files to Premiere Pro on Windows. [22:06:28 CEST] <obelisk29_> We have working h264 captures that premiere likes just fine. [22:06:39 CEST] <Kadigan> obelisk29_: are they in .mov containers? [22:06:51 CEST] <obelisk29_> If I could only get it into the exact thing that premiere likes [22:06:54 CEST] <obelisk29_> yes [22:07:23 CEST] <obelisk29_> ffprobe comparison http://pastebin.com/2Gwfmhgh [22:09:38 CEST] <obelisk29_> Ok I'm out for a bit, gonna try the splitting of the audio and video and see what happens thx [22:10:05 CEST] <obelisk29_> my questions is here http://ffmpeg.org/pipermail/ffmpeg-user/2016-July/032712.html if you have any other suggestions thx! [22:10:12 CEST] <Kadigan> I'm curious as to the TBN/TBC differences, but I probably don't know enough to explain it. [22:10:54 CEST] <Kadigan> (working has 29.97 tbr, 30000 tbn, 50 tbc; broken has 29.97 tbr, 11988 tbn, 59.94 tbc) [22:10:56 CEST] <obelisk29_> I wondered that as well [22:11:47 CEST] <Kadigan> tbn is timebase from the container, tbr is the assumed fps, and tbc is the timebase used in the context of the codec used [22:12:21 CEST] <Kadigan> (at least from SO) [22:13:08 CEST] <Kadigan> In general I can safely say I dislike working with /1001 video. It doesn't lend itself well to converting, IMO. [22:13:43 CEST] <obelisk29_> prores (apcs / 0x73637061), yuv422p10le(bt709), 1920x1080, 114900 kb/s, SAR 1:1 DAR 16:9, 29.97 f ps, 29.97 tbr, 2997 tbn, 2997 tbc (default) [22:13:56 CEST] <obelisk29_> thats the ffprobe of the source material [22:14:30 CEST] <obelisk29_> so compare that with broken [22:14:37 CEST] <obelisk29_> it doesn't match at all [22:16:03 CEST] <Kadigan> One thing. Using -r before -i only apparently works for raw formats. [22:16:41 CEST] <Kadigan> Also, the file is 29.97 so -r 30 would result in some fail in the output (would need to use either -r 29.97 or -r 30000/1001 if that were the case) [22:17:25 CEST] <obelisk29_> full ffprobe of source http://pastebin.com/vfZWpyME [22:17:34 CEST] <Kadigan> If You want to reencode the file to use a specific rate, You either need to deal with the timestamps, duplicate frames or export to raw and re-encode. [22:17:51 CEST] <Kadigan> That's my understanding, anyway. [22:18:09 CEST] <wiak> any idea why i keep getting av_interleaved_write_frame(): Broken pipe randomly on my ffmpeg/icecast hybrid? http://nwgat.ninja:8001/live.webm [22:18:30 CEST] <wiak> it is alot more stable i have no clue what i did [22:18:31 CEST] <wiak> lol [22:20:32 CEST] <Kadigan> wiak: if it's suffering from intermittent/random failures, I would assume that it's probably an issue with Your decoder not understanding the stream, or the stream being broken [22:23:58 CEST] <Kadigan> (or, encoder, same difference I would assume) [22:26:56 CEST] <obelisk29_> i'd rather just have it copy the source framerate they suggested I add it to see if the source being vfr was the issue [22:40:24 CEST] <spirou> would it be possible for ffmpeg to convert the strange .ts files that the TV saved (when recording tv-programs with it to usb)? [22:41:19 CEST] <spirou> or ffprobe to find out what format it is [22:41:24 CEST] <spirou> in this case the TV is one made by Vestel [22:58:19 CEST] <durandal_1707> spirou: try it, it's probably protected [23:16:42 CEST] <obelisk29_> IT WORKS [23:17:35 CEST] <obelisk29_> I split out the video and audio into seperate files then encoded them seperately then remuxed them together and it works perfect! [23:18:15 CEST] <obelisk29_> Thanks Kadigan and wiak! [23:18:57 CEST] <wiak> oh snap remux worked hehe [23:19:01 CEST] <Kadigan> obelisk29_: it's a roundabout way as You essentially rebuilt the streams and resynced them. I hope it keeps sync. [23:19:27 CEST] <Kadigan> wiak: it's probably both that worked - converting it to something that had separate timestamps each, and then remuxing based on those... [23:19:38 CEST] <obelisk29_> How I remove my user mail question? [23:19:48 CEST] <obelisk29_> Or reply to it saying how I solved it? [23:19:59 CEST] <c_14> Just reply saying how you solved it. [23:20:23 CEST] <wiak> yeah, i like those people that reply to them self with the solution [23:20:51 CEST] <obelisk29_> I think it was the audio codec getting confused by the video timecode, atleast that what im going to tell myself [23:21:53 CEST] <obelisk29_> Im a noob when it comes to these mailing list questions, how do I reply to myself lol [23:22:14 CEST] <Kadigan> I think it's time I repeat my question: on certain video files (produced by a 360fly camera), mp4 files at rate 30000/1001, resolution 1504x1054 - I receive bucketloads of messages saying "Past duration 0.XXXXXX too large". I don't think it's affecting the produced files much, but I am wondering if it's something I could assist ffmpeg with figuring out (a switch I could use, some forwards detection I could auto-determine this with etc.)? [23:22:35 CEST] <Kadigan> Correction: resolution 1504x1504* (square video) [23:23:24 CEST] <Kadigan> For the record, I'm attempting to convert these MP4 files into ProRes so that I can work on them easily in an NLE in an Apple environment. [23:24:36 CEST] <wiak> obelisk29_ simply reply to the return mail or something you got from mailinglist [23:25:20 CEST] <wiak> did you try -r 30? [23:25:24 CEST] <wiak> to force it to 30fps [23:25:47 CEST] <Kadigan> On an entirely unrelated topic: is there some easy way (and by "easy" I mean one-step or two-step command) I could convert VFR video into CFR video? I don't mind frame doubling, I do mind frame skipping. I've heard that the only reliable way of doing this is to extract the video into a raw format and then re-encode. [23:26:07 CEST] <wiak> no clue [23:26:17 CEST] <PhoenixBR> Hi guys! [23:26:32 CEST] <Kadigan> Hey PhoenixBR. 'sup? [23:26:47 CEST] <PhoenixBR> Kadigan: nice, thx [23:27:42 CEST] <Kadigan> (just for clarification: VFR is Variable Frame rate Video, where CFR is Constant (FR); VFR happens a lot in anime where action sequences get a higher frame rate resolution than the rest, and the rate can jump dozens of times during one video clip) [23:28:07 CEST] <PhoenixBR> Well, I have a very simple issue: Need to put 3 green screen frames in the beggining and in the end of a video. Can anybody help with this? [23:29:16 CEST] <Kadigan> PhoenixBR: You can create a 3-frame video stream and then concatenate that to the beginning and end. [23:30:02 CEST] <kepstin> Kadigan: what exactly is the desired result that you want? constant framerate with "realtime", dropping/adding frames, or constant framerate where parts with higher framerate are turned into slow motion, and parts with lower framerate into fast motion? [23:30:47 CEST] <PhoenixBR> Kadigan: how can I do that? [23:30:59 CEST] <Kadigan> kepstin: the intended use is for playback in a system that does some magic on look-ahead and intra-frame blending, smooth video (SVP). As such, I would like to end up with a constant frame rate video - I don't mind it being the highest frame rate it has. [23:31:31 CEST] <Kadigan> Otherwise, the entire forward buffer is dropped when this change happens, which results in a very, very noticeable jerk (up to about 1.5s of playback) as it re-buffers and recalculates. [23:32:07 CEST] <kepstin> Kadigan: ah, ffmpeg doesn't have anything to interpolate frame or whatnot; the only thing it can do to raise framerate is simply duplicate/repeat a frame to fill time [23:32:16 CEST] <Kadigan> So basically, if a video file is generally 25fps, but then jumps to 48fps, then down to 12fps (for cartoonish effect) and then back to 25, I don't mind it being CFR 48fps. [23:32:26 CEST] <kepstin> Kadigan: which you can do by using the -r output option (or equivalently -vf fps) [23:32:56 CEST] <Kadigan> Ah, and that would produce duplicate frames wherever they're needed to 'pad out' the rate. [23:33:01 CEST] <kepstin> yeah [23:33:53 CEST] <Kadigan> This would have the advantage of not losing the buffer, but the disadvantage of allowing for less interpolation where it would be required (by intentionally "falsifying" temporal information). I can see how I would be going against my original purpose that way... [23:34:06 CEST] <kepstin> ideally, your "smooth video" system really needs to just handle vfr input correctly [23:34:13 CEST] <kepstin> there's no other way to do what you want, really. [23:34:37 CEST] <Kadigan> Yeah, that would be the ideal situation. I'm puzzled as to why SVP doesn't actually... [23:35:03 CEST] <kepstin> since it's already doing inter-frame blending, etc, it would be a great place to interpolate extra frames to fill in the lower framerate sections [23:35:06 CEST] <Kadigan> (I am ignorant to the complexity of these calculations, and I expect the "border" calculations to be somewhat more complicated) [23:35:31 CEST] <PhoenixBR> Kadigan: I've created the Green.avi video: ffmpeg -f lavfi -i color=green:s=704x576:r=24000/1001 -f lavfi -i anullsrc -ac 2 -t 1 green.avi [23:35:42 CEST] <PhoenixBR> Kadigan: what else? [23:36:00 CEST] <Kadigan> PAL video? Nice. [23:38:41 CEST] <Kadigan> PhoenixBR: https://trac.ffmpeg.org/wiki/Concatenate please read up here, and https://ffmpeg.org/ffmpeg-filters.html#concat for usage and documentation on using the CONCAT filter. [23:39:13 CEST] <Kadigan> It allows to join multiple streams together, whether same-codec or different codec. [23:40:10 CEST] <PhoenixBR> Kadigan: but it has to be the same codec =\ [23:41:00 CEST] <Kadigan> PhoenixBR: I do not understand You. It needs not be the same codec. What matters is that you produce the desired codec at output. [23:41:59 CEST] <Kadigan> As a side-note, I never fully grasped using ffmpeg to output production-quality mpeg-2 streams usable for DVD mastering... Never could get the options right for mastering software to accept the damn thing... [23:42:29 CEST] <PhoenixBR> Kadigan: the first link says both video need to have the same codec [23:42:59 CEST] <Kadigan> No, it doesn't. Please read further down. [23:43:30 CEST] <Kadigan> Actually, please read the first two introductory sentences to their end. [00:00:00 CEST] --- Sat Jul 9 2016

1 0

ffmpeg-devel.log.20160707
by burek 08 Jul '16

08 Jul '16

[00:12:28 CEST] <cone-716> ffmpeg 03Martin Vignali 07master:7ebd13fc8b2d: libavodec/exr : add support for Y and YA file (ticket #5621) [00:12:29 CEST] <cone-716> ffmpeg 03Martin Vignali 07master:50747d6b1f25: libavcodec/exr : indent gray support patch [01:09:59 CEST] <rcombs> OK, weird case to think about [01:10:40 CEST] <rcombs> right now, the FLAC muxer uses the timestamps from the bitstream, which means they're wrong if you're using the segment muxer or seeked in ffmpeg and are stream-copying or [modified timestamps after the encoder in any other way] [01:11:22 CEST] <rcombs> I've got a change here that rewrites the frame header to insert the timestamp from AVPacket instead [01:11:45 CEST] <rcombs> and also modifies STREAMINFO's total duration value [01:12:04 CEST] <rcombs> what should I do if timestamps don't start at zero, though? [01:12:38 CEST] <rcombs> right now, I'm setting the STREAMINFO duration by adding all the packet durations, and setting packet timestamps directly from pkt->pts [01:12:40 CEST] <nevcairiel> its a raw audio format, you should just generate new timestamps [01:13:07 CEST] <rcombs> but the format does allow for a positive nonzero start time [01:13:17 CEST] <rcombs> nevcairiel: that seems sane enough [01:13:41 CEST] <rcombs> nevcairiel: only one thing I'm concerned about; is it possible to have invalid/zero packet durations there? [01:13:58 CEST] <nevcairiel> its audio, cant you get full durations from it somehow? [01:14:29 CEST] <rcombs> like, parse the packet header and get it from there? [01:14:37 CEST] <rcombs> I suppose I could [01:15:00 CEST] <rcombs> (I'm already doing a reasonable amount of parsing so I can rewrite the timestamps correctly) [01:15:43 CEST] <nevcairiel> just need to handle variable blocksize and fixed blocksize cases [01:16:00 CEST] <nevcairiel> iirc the want different info in that field then [01:16:17 CEST] <rcombs> yeah, I'm handling that for the timestamp rewriting already [09:05:30 CEST] <ubitux> hey nevcairiel [09:05:40 CEST] <ubitux> did you receive some insults from the guy or not yet? [09:05:55 CEST] <ubitux> just got 2 personal mails full of threats [09:13:52 CEST] <andrey_turkin> I see no actual threats there. Just 100% full of insults and a bit over the top [09:15:31 CEST] <nevcairiel> ubitux: nah didnt get anything [09:15:47 CEST] <ubitux> "a bit over the top" [09:15:49 CEST] <ubitux> lol [09:18:36 CEST] <nevcairiel> at first i thought that many people write emotional mail sometimes, but thats another kind of crap [09:19:32 CEST] <andrey_turkin> I can understand his frustation about apparent rejection he got, and he had some points about factual numbers on speedups gained by using SIMD on x86. Now he was given the measurement, and he was given detailed analysis of his patch, and "overreacted" is not even an understatement to his response [09:20:42 CEST] <nevcairiel> he could've just answered the questions instead of degrading to personal attacks [09:21:04 CEST] <nevcairiel> this way he will not get code accepted at all [09:23:34 CEST] <andrey_turkin> hey, maybe he'll come back with reworked patch addressing those comments and it'll be beautiful and 4x speedup... Good thing conditions of that bounty require to get fixes into main repo - it got to make him more amenable [09:24:21 CEST] <nevcairiel> you would think so, but he doesnt sound like it [09:25:16 CEST] <ubitux> was 1df908f33f658979b32599489ca6f1a39821013c ever reviewed btw? [09:25:20 CEST] <andrey_turkin> He could've thought he did the best job possible. Until review email, that is. Now there are technical objections that needs to be addressed [09:46:44 CEST] <andrey_turkin> hm, so there's 3 different bounties on various parts of ffmpeg, totalling over $3000 [09:47:45 CEST] <nevcairiel> which really isnt a lot in developer man hours [09:48:16 CEST] <andrey_turkin> depending on a place it can be plenty [09:48:31 CEST] <andrey_turkin> my monthly salary is a bit over $1000 [09:48:47 CEST] <nevcairiel> it isnt a lot where IBM comes from, lets put it this way [09:48:48 CEST] <andrey_turkin> so it woul be worth 3 months of full time work [09:49:04 CEST] <andrey_turkin> that's true. Probably not many people have power8 just lying around [09:49:07 CEST] <kierank> interesting double standard in ffmpeg when it comes to insults [10:07:38 CEST] <mateo`_> hello there [10:09:28 CEST] <mateo`_> quick question regarding avctx->pkt_timebase, a decoder is not supposed to rely on its value to rescale the pkt->pts as it is not meant to be set if an application is using the new codecpar api, right ? [10:12:10 CEST] <mateo`_> also, what was the initial purpose of this field ? [10:13:34 CEST] <mateo`_> s/purpose/use case/ [10:28:07 CEST] <nevcairiel> mateo`_: its really unrelated to codecpar - but decoders should typically have no reason to touch the timestamps at all, some subtitle decoders with in-band timing info not withstanding [10:30:42 CEST] <mateo`_> nevcairiel: ok, i'm using it in my current MediaCodec hwaccel patch to provided rescaled pts in us to the input packet (so the values are forwared to the output surface and the user gets a chance to get ts in us at this level) but since I switched to codecpar the pkt_timebase is not set anymore [10:32:04 CEST] <nevcairiel> its not a field guaranteed to be available [10:32:18 CEST] <nevcairiel> and video decoders should really just forward the input timestamps [10:33:17 CEST] <nevcairiel> anyway you would need to set pkt_timebase on the avcodeccontext manually during creation from AVStream->time_base [10:33:18 CEST] <mateo`_> I'll explicitely tell in the documentation that the timestamps forwarded the surface are in fact pts from the input avpackets (and need to be rescaled if the user wants something in us) [10:34:59 CEST] <mateo`_> nevcairiel: just to confirm what you just said, it is not mandatory to set it, right ? [10:35:13 CEST] <nevcairiel> its not, but some things need it to function properly [10:35:30 CEST] <mateo`_> ok [10:36:13 CEST] <mateo`_> It's better not using it right ? [10:37:04 CEST] <nevcairiel> unless you absolutely have to do for some things [10:37:28 CEST] <nevcairiel> it was introduced for a reason, its needed if you need to touch the timestamps [10:37:41 CEST] <nevcairiel> but thats really just very few cases in audio and a few subtitle things [10:37:50 CEST] <nevcairiel> video should not have such a reason, usually [10:38:44 CEST] <nevcairiel> thats what all other video codecs do, just forward AVPacket->pts in AVFrame->pkt_pts [10:38:54 CEST] <nevcairiel> without changes [10:41:44 CEST] <mateo`_> In theory I need to feed normalized ts in us to MediaCodec, in pratice I'm not even sure it is used at all by users or the surface itself for rendering. I'll double check this point before dropping the rescaling. [10:42:27 CEST] <nevcairiel> some external libraries have rather fixed requirements when it comes to timestamps [10:42:47 CEST] <nevcairiel> its quite unfortunate they cant just passthrough timestamps untouched [11:29:32 CEST] <rcombs> so, ff_vorbis_comment uppercases keys [11:30:16 CEST] <rcombs> despite the rest of lavf using lowercase keys [11:30:19 CEST] <rcombs> ~why though~ [11:32:26 CEST] <rcombs> looks like the VorbisComment spec recommends uppercase keys, so we should be writing uppercase and converting to lowercase when reading [11:37:15 CEST] <nevcairiel> metadata api is case insensitive, so does it matter? [11:37:16 CEST] <nevcairiel> :) [11:37:22 CEST] <nevcairiel> for writing, i guess [11:37:52 CEST] <rcombs> well we currently write lowercase tags contrary to the spec [11:39:30 CEST] <rcombs> I guess it doesn't matter much on input since people probably don't use AV_DICT_MATCH_CASE but it's still weird [14:55:47 CEST] <cone-469> ffmpeg 03Michael Niedermayer 07master:b450b82514e9: avcodec/exr: Fix mixed declarations and statements [15:01:16 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vKmfw [15:01:16 CEST] <KGB> 13FFV1/06master 14c126901 15Jérôme Martinez: Add myself as author [15:24:46 CEST] <Timothy_Gu> ok this dan parrot guy is THE best I've ever seen, and I've been here for a while [15:28:32 CEST] <ubitux> the one who started by insulting on the trac and went talking to himself wasn't that bad either [15:31:55 CEST] <BBB> Im not sure best is the best choice of words here :-p [15:35:26 CEST] <Timothy_Gu> nah ML is better. More damage. [16:09:35 CEST] <andrey_turkin> I wonder if measuring benchmarks in cloud environment has any relation to actual speedups on the hardware [16:13:00 CEST] <Timothy_Gu> Hey! fatebeta actually managed to make a v3.1 branch automatically this time [16:33:31 CEST] <BBB> andrey_turkin: I really think that questions like that should be left to the person writing the assembly [16:33:48 CEST] <BBB> andrey_turkin: if he thinks thats an issue, he should provide evidence (data, facts) to support that idea [16:34:55 CEST] <BBB> andrey_turkin: I dont think we should make a habit out of allowing fud (doubts, etc.) to discredit genuine (e.g. data-driven) concerns [16:35:09 CEST] <andrey_turkin> It is a more of a general question. I'm genuinely interested [16:36:05 CEST] <andrey_turkin> say, if I don't have AVX512 hardware but there is a cloud VPS which supports it. Can I get any meaningful results from that or do I have to have bare-metal? [16:36:41 CEST] <BBB> I dont know... [16:36:47 CEST] <nevcairiel> if its actual hardware powering that and not some sort of crazy emulation, its probably close enough [16:38:58 CEST] <jkqxz> Yeah. Shared machines may randomly do nasty thing to your results, but if you run it lots of times then it should be valid. [16:39:56 CEST] <andrey_turkin> cool. that's good to know ) [16:40:03 CEST] <jkqxz> (Though VPS type things certainly hide features - even if the underlying CPU supports something, it may not actually appear. If it's there then it should be fine.) [16:43:04 CEST] <Gramner> it's usually very obvious if anything weird is going on with performance of instruction sets on a machine due to emulation or whatnot. e.g. if an instruction takes 5000 clock cycles instead of 3 [17:06:26 CEST] <nevcairiel> Timothy_Gu: can you also make fatebeta start automatically so its not down so much? :) [20:21:12 CEST] <CFS-MP3b> I sent a patch yesterday (first ever) but there's been no reply... don't know if it's good or bad but I'm leaning towards bad :-) [20:21:14 CEST] <CFS-MP3b> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-July/196382.html [20:21:27 CEST] <CFS-MP3b> Could someone comment? Maybe I just didn't send it correctly [20:25:00 CEST] <jamrial> CFS-MP3b: give people some time. and if you don't get a reply or review after a week then ping the patch [20:29:08 CEST] <llogan> it's a busy mailing list. sometimes we just forget or miss it. [20:36:37 CEST] <CFS-MP3b> jamrial @llogan that's fine, I just want to make sure it's not that I sent the patch incorrectly :-) [21:53:29 CEST] <JEEB> sure is "clever" spam [21:55:39 CEST] <bollocks_k> lol [22:05:44 CEST] <BBB> how do I ban a user? [22:06:51 CEST] <BBB> well theyre deleted [22:07:01 CEST] <BBB> but I dont know how to retrieve the users IP so I cant ban the ip :( [22:07:17 CEST] <jamrial> llogan probably knows how [22:09:00 CEST] <BBB> he just added it already [22:09:18 CEST] <jamrial> the filter has reached a point where spammers are forced to mangle their shit so much that i wonder just how effective posting all that is at this point [22:09:51 CEST] <llogan> persistant bastards aren't they? [22:10:02 CEST] <BBB> always the quickbooks tech support, also [22:10:09 CEST] <BBB> llogan: how do I find the ip? [22:11:13 CEST] <llogan> BBB: i view IP via .org/admin/spamfilter/monitor [22:11:27 CEST] <llogan> if you don't have access I can add you [22:11:35 CEST] <BBB> I have access [22:11:42 CEST] <BBB> crap I just deleted them [22:11:54 CEST] <BBB> anyway, thanks [22:12:11 CEST] <BBB> oh wait monitor is still there [22:12:15 CEST] <BBB> I just deleted the reports [22:13:16 CEST] <llogan> a trac update removed "mark selected as spam". i need to re-introduce that because "delete selected as spam" is much less useful...also that only deletes the entry in the monitor, and doesn't actually delete the associated post, etc. [22:14:09 CEST] <llogan> oh, you deleted the spam reports. that's fine. [22:14:18 CEST] <BBB> llogan: so, you didnt actually add the guys ip to badip, did you? [22:14:31 CEST] <BBB> (122.177.63.136, according to monitor) [22:14:57 CEST] <llogan> i guess i missed that one. there were several [22:15:31 CEST] <llogan> also, i can't recall if entries apply immediately in the badip filtering or not [22:15:43 CEST] <BBB> we need a button to add selected to badip ;) [22:16:07 CEST] <llogan> i can add it unless you want to [22:21:14 CEST] <llogan> i should be taking my lunch break now instead of dealing with these retards [22:21:29 CEST] <BBB> Ill deal with it [22:21:46 CEST] <llogan> i wonder how many incoming calls they can handle [22:29:08 CEST] <llogan> BBB: do you see any results if you do a google site search on trac for quickbooks? i get three. some from may 18. so i don't think they even care if they are deleted here. [22:29:43 CEST] <kierank> CFS-MP3b: I don't personally see what you want to implement in scte-35 [22:30:03 CEST] <kierank> iirc it needs quite specific timing [22:30:07 CEST] <BBB> I see only links to deleted pages [22:30:13 CEST] <BBB> if you click Select similar ones, you get 8 [22:40:38 CEST] <CFS-MP3b> kierank : Take SCTE-35 cues into account when it is cutting video for HLS segmentation and export SCTE-35 data to HLS Playlists are the first goals of this stage of the project [22:41:00 CEST] <nevcairiel> didnt we have someone want that before [22:41:21 CEST] <CFS-MP3b> nevcairiel I'm sure it's a recurring thing [22:42:25 CEST] <nevcairiel> oh right someone made stream copying of data streams work related to scte-35, which would kinda imply scte35 streams are exposed as data streams already [22:42:29 CEST] <CFS-MP3b> I even saw some patch that was rejected some time ago... I checked it out and it seemed rushed... for example it missed section 6 of the specs completely (PMT data) [22:44:34 CEST] <CFS-MP3b> Anyway my plan is to do a complete implementation, but since I'm new to ffmpeg it doesn't seem like a good idea to do everyhing and come with a large patch that might look to me but be complete shit [22:45:00 CEST] <nevcairiel> doing smaller parts incrementally is definitely a good idea [22:45:45 CEST] <CFS-MP3b> @nevcairiel that's why I started with a small thing... add the codec type, prepare a dummy function that receives data if present even if it doesn't do anything just yet [22:46:47 CEST] <CFS-MP3b> getting this accepted into the mainstream version is a requirement... just having a patch that does the job but that needs to be backported from time to time it's not good enough [22:51:37 CEST] <kierank> lol [22:51:58 CEST] <CFS-MP3b> lunch time for me, bbl [23:10:24 CEST] <ehedeman> Is this the right place to propose or ask for feedback on changes? [23:11:44 CEST] <ehedeman> I have been working on some changes to the fps video filter, and realized that each filter appears to have it's own symbol table for the command line expression parsing. [23:13:18 CEST] <ehedeman> Thoughts on having a global symbol table so that things like height/width/fps can be shared across different filter configs? [23:13:44 CEST] <kierank> how is that thread safe [23:14:16 CEST] <BBB> or even multi-instance safe [23:14:55 CEST] <nevcairiel> the thing with those expressions is that they point into a struct, so even though the options are the same, they tend to have different offsets into different structs [23:24:29 CEST] <ehedeman> Ah, yeah I didn't think about the multi instance implications. [23:26:02 CEST] <ehedeman> We are just thinking about doing more adaptive transcoding, and it would be nice to not have to add a new field and submit upstream every time we want to add a condition. [23:33:27 CEST] <KGB> [13FFV1] 15michaelni closed pull request #19: Make rfc format (06master...06make-rfc-format) 02https://git.io/vozkz [23:53:56 CEST] <CFS-MP3b> back [00:00:00 CEST] --- Fri Jul 8 2016

1 0

ffmpeg.log.20160707
by burek 08 Jul '16

08 Jul '16

[03:11:59 CEST] <fling> How do I save all the incoming ffserver streams to files? [03:17:02 CEST] <fling> updated util-linux and segfault gode [03:17:09 CEST] <fling> s/gode/gone/ [03:17:18 CEST] <fling> But how do I check all the binaries for segfaults? [03:17:31 CEST] <fling> D'oh! wrong channel :P [03:57:55 CEST] <fling> So can't I save different streams to different files specifying the stream start date as a filename? [06:27:14 CEST] <fling> Lookl like I could run ffmpeg in a loop for this& [07:28:30 CEST] <hero_biz> hi guys [07:29:07 CEST] <hero_biz> guys,i'm trying to encode 2 audio tracks of a mkv file and make 2 one output per track. [07:29:28 CEST] <hero_biz> i used this command: [07:29:41 CEST] <hero_biz> ffmpeg -i a.mkv -map 0:a -c:a:0 libfdk_aac -b:a:0 48k audio1.aac -c:a:1 libfdk_aac -b:a:1 48k audio2.aac [07:30:00 CEST] <hero_biz> but it seems it does not work correctly, because first I get this warning: [07:30:15 CEST] <hero_biz> "Codec AVOption b (set bitrate (in bits/s)) specified for output file #1 (audio2.aac) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream." [07:30:33 CEST] <hero_biz> and second this is shows at end of encode for stream mapping: [07:31:17 CEST] <hero_biz> "Stream mapping: Stream #0:1 -> #0:0 (ac3 (native) -> aac (libfdk_aac)) Stream #0:2 -> #0:1 (ac3 (native) -> aac (native)) Stream #0:1 -> #1:0 (ac3 (native) -> aac (native))" [07:31:42 CEST] <hero_biz> any idea what I have done incorrectly? [07:32:42 CEST] <relaxed> ffmpeg -i a.mkv -map 0:a:0 -c:a:0 libfdk_aac -b:a:0 48k audio1.aac -map 0:a:1 -c:a:1 libfdk_aac -b:a:1 48k audio2.aac [07:34:36 CEST] <hero_biz> relaxed: ty,now streams are ok, but encoding not: [07:34:51 CEST] <hero_biz> "Stream mapping: Stream #0:1 -> #0:0 (ac3 (native) -> aac (libfdk_aac)) Stream #0:2 -> #1:0 (ac3 (native) -> aac (native))" [07:36:26 CEST] <hero_biz> aha corrected it myself,ty help :) [07:36:43 CEST] <hero_biz> needed to use 0 for 2nd track encoders too: [07:36:56 CEST] <hero_biz> ffmpeg -i a.mkv -map 0:a:0 -c:a:0 libfdk_aac -b:a:0 48k audio1.aac -map 0:a:1 -c:a:0 libfdk_aac -b:a:0 48k audio2.aac [07:40:50 CEST] <relaxed> right, in this case you could just use -c and -b [07:41:45 CEST] <CoJaBo> I like how ffmpeg will quite happily create a 2×1080 output file, and default to 16:9 display aspect ratio for it [07:42:34 CEST] <furq> only if your input file has the dar set to 16:9 [07:43:33 CEST] <CoJaBo> Took a stupid long while to figure out what happened >_> [07:43:48 CEST] <CoJaBo> I thought the playback app was broken :/ [07:45:18 CEST] <CoJaBo> Looks hella tippy tho [07:46:41 CEST] <CoJaBo> ..trippy [10:00:01 CEST] <Accord> hey, anyone know why screen capture doesn't work in windows 10? [10:00:21 CEST] <Accord> [dshow @ 03b67700] Could not find video device with name [screen-capture-recorder] among source devices of type video. [10:00:21 CEST] <Accord> video=screen-capture-recorder: I/O error [10:28:10 CEST] <furq> Accord: https://github.com/rdp/screen-capture-recorder-to-video-windows-free [10:40:13 CEST] <Accord> furq, that seems to be using the ffmpeg command I am [10:40:40 CEST] <furq> that is the screen-capture-recorder device [10:40:59 CEST] <Accord> huh [10:41:13 CEST] <Accord> didn't need it on windows 8 [10:42:04 CEST] <furq> are you sure you weren't using gdigrab [10:42:15 CEST] <Accord> yep [10:42:21 CEST] <Accord> will try this now, thanks [10:44:24 CEST] <Accord> seems to work, thanks again :) [10:46:37 CEST] <Accord> though i do get a lot of [dshow @ 0311b640] real-time buffer [screen-capture-recorder] [video input] too full or near too full (545% of size: 3041280 [rtbufsize parameter])! frame dropped! [11:05:21 CEST] <c_14> Try increasing the -rtbufsize option [11:15:18 CEST] <Accord> c_14, how much should i set it? i tried 6x 3041280 as said in the error but i still get it [15:11:41 CEST] <termos> Hi I'm resampling my audio from 48khz to 44.1khz and it's fine, but 48khz to 22.05khz causes my audio to play in slow motion. Is there something special I need to be able to resample this far? [15:12:56 CEST] <termos> Oh I might have found it [15:29:03 CEST] <DHE> sounds like you didn't resample it, but simply replaced the sample rate value [15:47:20 CEST] <BtbN> Anyone ever tried to play a 5.1 or mono, or rather, non 2 channel stereo, file in Spotify? [15:47:52 CEST] <BtbN> They hard-coded it to two channels apparently, so when playing 5.1, it plays the interleaved samples like it was stereo. [15:48:51 CEST] <DHE> like, skipping through the various channel samples? [15:55:47 CEST] <mantas322> Hi guys [16:11:51 CEST] <ntz_> hello [16:12:40 CEST] <ntz_> can anybody please help me with capturing my screen ? it worked for me in past, I've googled out several commands for that but it has only black screen now ... [16:12:52 CEST] <ntz_> I have opensuse with x11 [16:15:13 CEST] <c_14> ffmpeg -f x11grab -i :0 out.mkv ? [16:17:01 CEST] <ntz_> c_14: http://susepaste.org/view/raw/21759184 [16:17:09 CEST] <ntz_> yeah, that's basically how it worked before [16:18:08 CEST] <c_14> I'm pretty sure the problem's just that your version of mplayer doesn't support 444p vp9 [16:18:16 CEST] <c_14> try with ffplay [16:18:25 CEST] <c_14> or use a different codec (like ffv1) [16:18:29 CEST] <c_14> or mpv/vlc [16:18:45 CEST] <c_14> Also, you don't want to use vp9 for screan recording [16:18:48 CEST] <c_14> It'll be too slow [16:19:00 CEST] <c_14> According to the output you're recording at half-realtime [16:19:12 CEST] <ntz_> o.O [16:19:25 CEST] <ntz_> c_14: is mplayer involved in that when I do it with ffmpeg ? [16:19:34 CEST] <c_14> no [16:19:50 CEST] <ntz_> oh, for playback [16:20:25 CEST] <ntz_> gotcha ... weird since my mplayer simply plays/played anything - even videos that vlc has problem with - I considerf mplayer as the most reliable player for years [16:20:55 CEST] <bencoh> using almost exclusively mplayer here, but ... I wouldn't call it "most reliable player" :) [16:21:13 CEST] <bencoh> (even if I'm still a huge fan) [16:21:20 CEST] <ntz_> anyhow, I still suspect a ffmpeg not capturing my screen properly [16:21:33 CEST] <ntz_> btw https://trac.ffmpeg.org/wiki/Capture/Desktop [16:21:38 CEST] <c_14> ntz_: use a different codec [16:21:54 CEST] <ntz_> this results in black screen [16:21:56 CEST] <c_14> like -c:v utvideo or -c:v mpeg4 or -c:v ffv1 [16:22:05 CEST] <ntz_> ok [16:22:23 CEST] <c_14> or switch the output pixel format -pix_fmt yuv420p [16:23:01 CEST] <ntz_> I tried this `ffmpeg -f x11grab -i $DISPLAY -c:v mpeg4 x11_out.mkv'' still black screen, perhaps I have broken teh x11grab part ? [16:23:30 CEST] <ntz_> ^^ surely, shall not be .mkv but doesn't matter, it's just a filename [16:24:35 CEST] <ntz_> http://susepaste.org/view/raw/87428127 [16:24:41 CEST] <ntz_> ^^ is this helpful in any way ? [16:24:49 CEST] <c_14> avfoundation won't work [16:24:52 CEST] <c_14> that's osx only [16:25:22 CEST] <ntz_> I was attracted by that -list_devices [16:25:32 CEST] <ntz_> which spits error message in linux [16:27:07 CEST] <c_14> if you try `ffmpeg -f x11grab -i $DISPLAY out.gif' does that produce output you can view? [16:29:09 CEST] <ntz_> c_14: it creates 9KB big gif that seems just empty [16:29:21 CEST] <ntz_> after say 5 seconds of capturing [16:29:42 CEST] <ntz_> http://susepaste.org/view/raw/22681952 [16:30:10 CEST] <c_14> Is the top left-corner of your monitor black by any chance? [16:30:34 CEST] <ntz_> wait, I was stopping that always with ctrl+c, now I see it says `q' to quit [16:30:45 CEST] <c_14> they do the same thing [16:31:58 CEST] <ntz_> pff, no difference .. maybe one more point, I have two displays: http://susepaste.org/view/raw/2414989 [16:32:34 CEST] <c_14> It'll always record offsetted on the top leftest corner [16:33:13 CEST] <c_14> 14:30 <c_14> Is the top left-corner of your monitor black by any chance? [16:33:26 CEST] <ntz_> I'm afraid that something broke because I was able to record my screen with ffmpeg completely fine ... past == few years ago when things weren't so complicated [16:33:46 CEST] <ntz_> c_14: I can show ya, second please: [16:36:34 CEST] <ntz_> c_14: http://susepaste.org/view/raw/90700736 [16:36:38 CEST] <ntz_> this is my screen [16:37:14 CEST] <ntz_> X does create some virtual size of the screen so maybe yes, I have from the POV of ffmpeg some parts of my 2800 x 1920 screen black [16:38:34 CEST] <c_14> try -i :0+1600 maybe [16:40:08 CEST] <ntz_> c_14: wou, that did something [16:40:27 CEST] <ntz_> c_14: thanks !!!! I think you've pointed me to the right direction [16:40:51 CEST] <c_14> So it looks like you just need to push the window out of that giant black space to wherever you want. [16:42:33 CEST] <ntz_> c_14: ffmpeg -f x11grab -i $DISPLAY+1600 -framerate 25 -video_size 1024x768 x11_out.mp4 [16:42:38 CEST] <ntz_> good, now it works ^^^ [16:42:53 CEST] <c_14> both -framerate and -video_size should be in front of -i [16:43:03 CEST] <ntz_> ofc it doesn't record what I wanted but this finally produces a video file with section of my screen [16:46:06 CEST] <ntz_> c_14: PERFECT, thanks much .... this works as I needed `ffmpeg -f x11grab -framerate 25 -video_size 1200x1920 -i $DISPLAY+1600 x11_out.mp4', however as in result, ffmpeg recording my screen devours all my cpu resources (I have i5 laptop) and the video is a bit blurred [16:46:31 CEST] <ntz_> so I guess it's just the matter of some other opts like to use more light-weight codec or such like [16:46:47 CEST] <c_14> try using -c:v libx264 -preset faster or something [16:46:55 CEST] <c_14> Or record with a lossless codec first and reencode later [16:47:24 CEST] <ntz_> Unknown decoder 'libx264' [16:47:30 CEST] <c_14> after -i [16:47:30 CEST] <ntz_> but that's no-issue :) [16:47:36 CEST] <ntz_> ok [16:47:47 CEST] <c_14> options that affect the input go before -i options that affect the output go after it [16:48:54 CEST] <ntz_> ok, memorizing it [16:49:33 CEST] <ntz_> c_14: thanks much for help .... I think that now it's up to me to read the man, google out and find out what codec shall be optimal according to performance of my laptop and available codecs here in suse [16:49:43 CEST] <ntz_> c_14++ [16:50:04 CEST] <ntz_> because now it definitelly works [16:50:12 CEST] <ntz_> however a bit blurred [16:54:06 CEST] <ntz_> c_14: may I ask one additional question ? I have here teh dual gfx laptop, there's intel i915 gfx chip and nvidia chip that I have completely disabled ... does ffmpeg use at some extend some gfx hw accel ? [16:54:44 CEST] <ntz_> for instance can I use vdpau for better performance while capturing a screen using ffmpeg ? [16:54:51 CEST] <ntz_> ^^ in the case of nvidia [16:54:58 CEST] <c_14> not unless you explicitly tell it to [16:55:17 CEST] <ntz_> ok [16:55:34 CEST] <ntz_> but generally said, it's done in cpu, right ? so i915 is not ptoblem ? [16:55:39 CEST] <c_14> vdpau is only for decoding, if you have nvenc support you can use that for encoding if you don't have the cpu to encode otherwise (but x264 --preset ultrafast is usually better) [16:55:49 CEST] <c_14> It's usually done on the cpu, yes [16:58:27 CEST] <ntz_> the performance here with relatively recent cpu is tragic :( ... just trainwreck [16:58:41 CEST] <c_14> that still vp9? [16:58:43 CEST] <ntz_> model name : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz [16:58:47 CEST] <c_14> vp9 is really slow [16:58:49 CEST] <c_14> that's expected [16:58:56 CEST] <c_14> well, libvpx is really slow [16:58:56 CEST] <ntz_> ok [16:59:44 CEST] <ntz_> I'd try with looseless codec [17:04:35 CEST] <ntz_> c_14: ffmpeg -f x11grab -framerate 25 -video_size 1600x900 -i $DISPLAY+0,1020 -c:v libx264 -qp 0 -preset ultrafast x11_out.mp4 [17:04:46 CEST] <ntz_> ^^ I dare to say that this works perfect !!!!! [17:04:59 CEST] <ntz_> THANKS MAN !!! [17:05:29 CEST] <ntz_> not blurred with acceptable performance (ofc it eats some cpu but not that bad with looseless codec) [17:05:41 CEST] <kepstin> if you're doing screen capture, you might consider using 'libx264rgb' instead of 'libx264', that avoids a colorspace conversion. [17:05:53 CEST] <ntz_> thanks for point [17:09:30 CEST] <ntz_> http://www.starenka.net/ntz/x11_out.mp4 [17:09:33 CEST] <ntz_> gooood [17:09:47 CEST] <ntz_> kepstin: libx264rgb doesn't work .... it just shows first frame [17:09:52 CEST] <ntz_> but nothing more [17:10:04 CEST] <ntz_> again, thanks much channel for your help !!!!! [17:12:28 CEST] <ntz_> last question .... which codec shall be considered as the least cpu intensive (loseless is fine) ? [17:12:48 CEST] <c_14> rawvideo [17:12:53 CEST] <c_14> that'll murder your hdd though [17:13:18 CEST] <c_14> other than that, either libx264 on ultrafast or ffv1 or utvideo maybe [17:13:31 CEST] <ntz_> fairt [17:13:36 CEST] <ntz_> s/t$// [17:15:13 CEST] <kepstin> somewhere inbetween rawvideo and ffv1 is ffvhuff, which is really fast but only moderately smaller than raw. [17:18:06 CEST] <ntz_> to be honest I don't catch why it's so big :D ... well, there are protocols like vnc and rdp (and forexample tw allows you share the screen over the network with rather low bandwidth) [17:18:31 CEST] <ntz_> it just seems that once I want it save to a disk it starts to be big [17:18:43 CEST] <c_14> you can make it real small really easily [17:18:49 CEST] <c_14> just use a largish crf on libx264 [17:18:56 CEST] <viric> libx264 can do also lossless [17:18:59 CEST] <c_14> something like 25 should be fine [17:19:10 CEST] <c_14> As soon as you go lossless you go big [17:20:14 CEST] <kepstin> ntz_: stuff like vnc and rdp are very far from lossless, they tend to do things like send only partial updates, reduce colors, and use jpeg or even lossy video codecs on complex or rapidly changing screen sections. [17:20:35 CEST] <viric> partial updates can be lossless [17:21:14 CEST] <kepstin> hmm, true. But (aside from x264, to a limited extent - and I dunno about utvideo) most lossless video codecs tend to be intra-only. [17:21:37 CEST] <kepstin> since they're designed as digital intermediate formats for editing. [17:22:28 CEST] <ntz_> hmm [17:23:26 CEST] <kepstin> hmm. an i5-2520M? I forget how capable the qsv encoder is on that chip line, if it's even present. [17:23:53 CEST] <ntz_> well, this cpu shall be some mid range in mobile cpus [17:24:14 CEST] <ntz_> but I don't feel that's enough powerful [17:25:04 CEST] <kepstin> that's not really related, the quicksync encoder is a fixed-function gpu block. which should be present and capable of doing h264 on your cpu. [17:25:31 CEST] <kepstin> if it works (e.g. via vaapi), that might be a reasonable way to get a realtime low-cpu encode at not-quite-lossless. [17:26:40 CEST] <ntz_> btw http://susepaste.org/view/raw/48373111 [17:26:48 CEST] <ntz_> I guess this seems all correct, right ? [17:26:55 CEST] <ntz_> I mean how it is built ... [17:27:07 CEST] <jkqxz> Sandy Bridge Quick Sync H.264 encode quality isn't so good, but it will be fine at high bitrates. VAAPI should work; I think libmfx won't because they dropped support for the older models. [18:18:36 CEST] <pikajude> can I add multiple .srt files to a .mp4 (not burning in)? [18:21:55 CEST] <IntelRNG> YOu can do it in mkv, I guess you could for mp3 [18:21:59 CEST] <IntelRNG> mp4* [18:22:01 CEST] Action: IntelRNG checks [18:24:03 CEST] <IntelRNG> I think srts are not supported without conversion btw [18:24:36 CEST] <pikajude> i'm fine with conversion, i just want to put multiple sub tracks into a .mp4 [18:24:40 CEST] <pikajude> because i want to import it into itunes [18:26:27 CEST] <IntelRNG> Does itunes support mkv? Just curious. [18:33:22 CEST] <pikajude> i seriously doubt it [18:33:59 CEST] <pikajude> i gave it a .mkv file and it seemed to do nothing [18:34:01 CEST] <pikajude> so I guess that's the answer [18:35:27 CEST] <pikajude> i figured out how to do it, btw [18:36:12 CEST] <pikajude> turns out you just have to put -i foo.srt for all the subtitles [18:39:10 CEST] <pikajude> and then -map them all [21:42:12 CEST] <monoflo> Hi! I followed a tutorial on how to create video files in C# frame-by-frame (http://en.code-bude.net/2013/04/17/how-to-create-video-files-in-c-from-sing…) I was able to get everything to work but I would now like to change codecs to H264 and configure some keyframe settings, neither of which I know how to do. [21:43:37 CEST] <monoflo> I downloaded a .NET Framework that included ffmpeg, and through a .dll I have access to an enum of Video Codecs which does not include H264 [21:45:43 CEST] <monoflo> Would someone here happen to be familiar with AForge Video and be able to give me a hand? [21:53:31 CEST] <Accord> monoflo, your best bet might be checking out the C examples and try to translate that to whatever libs you're using [21:55:37 CEST] <FishPencil> Is it possible to decode raw H.264 data, if the stream doesn't contain any header or container information? [21:55:38 CEST] <monoflo> Where can I find those? [21:56:12 CEST] <JEEB> FishPencil: what do you consider a header? [21:56:27 CEST] <FishPencil> JEEB: An RTMP header for example [21:56:50 CEST] <JEEB> AVC can be either in AVCc or Annex B. Annex B is basically in-band so as long as you get valid Annex B packets you should be able to decode it [21:57:52 CEST] <monoflo> Accord: Think I found them. Thanks [22:06:20 CEST] <FishPencil> JEEB: Correction: it's an f4v with an AAC stream and H.264. It's currently only seeing the AAC stream, and ffprobe is spitting errors with it [22:14:08 CEST] <Danimal> I'm using gdigrab and virtual-audio-capturer, and my video is falling behind the audio. is there a way to enforce sync? [22:41:43 CEST] <Danimal> ugh. bit it's intermittent. this is hte worst [22:43:40 CEST] <furq> would it not be better to use screen-capture-recorder [22:48:39 CEST] <Danimal> mmmm, I had a reason why i wasn't using that one. but can't remember what it was. why would that be better? [22:50:10 CEST] <furq> i would assume it works better with virtual-audio-capturer considering they're both written by the same guy [22:50:16 CEST] <furq> but also gdigrab is pretty slow [22:53:43 CEST] <Danimal> okie, well that makes sense, I could give it a try. driving me batty that I can't reliably reproduce the issue though. Only seen it once. [22:54:01 CEST] <Danimal> but it showed up within a minute of starting it up [22:55:15 CEST] <Danimal> here's a command line. "C:/Program Files/ffmpeg/bin/ffmpeg.exe" -fflags genpts -f gdigrab -framerate 30 -draw_mouse 0 -i desktop -itsoffset 00:00:00.08 -f dshow -i audio="virtual-audio-capturer" -r 30 -c:v libx264 -preset veryfast -b:v 12000000 -bufsize 24000000 -muxrate 17069000 -crf 23 -c:a libvo_aacenc -b:a 192000 -ac 2 -ar 48000 -pix_fmt yuv420p -vf "scale=1280:720" -g 100 -keyint_min 100 -sc_threshold 0 -async 1 -f mpegts -flus [22:55:44 CEST] <Danimal> I'll give screen capture recorder a try [23:21:30 CEST] <kepstin> gdigrab being slow shouldn't affect sync, but the fact that it's using a different timing source from the audio might :/ [23:22:09 CEST] <kepstin> (gdigrab uses pc realtime clock as timing source, while audio is probably timed on the sound card I guess) [00:00:00 CEST] --- Fri Jul 8 2016

1 0

ffmpeg-devel.log.20160706
by burek 07 Jul '16

07 Jul '16

[01:23:08 CEST] <cone-253> ffmpeg 03Petru Rares Sincraian 07master:3f5b7a2d7357: fate: add test for asetrate [09:41:21 CEST] <Mysoft> hello, i would like to use part of the ffmpeg code... just to do a TS -> MP4 conversion (audio+video copy), can you guys hint me witch parts of the code i need to use to accomplish that? [10:29:03 CEST] <andrey_turkin> BtbN: I've no idea. But last time I tried that there were issues with chroma handling (looks like it disagrees regarding plane layout or something). So maybe you've hit that bug. Or maybe they saw that bug and decided it was easier to disable yuv420p rather than fix it? )) [10:29:46 CEST] <BtbN> Or maybe it behaves different on Kepler [10:29:53 CEST] <andrey_turkin> maybe. [10:30:16 CEST] <thardin> Mysoft: you could just use the ffmpeg program [11:23:46 CEST] <cone-654> ffmpeg 03Michael Niedermayer 07master:fcdbbbd85a16: avcodec/iff: decode_delta_j: Check that the number of bytes that will be read are available [11:23:47 CEST] <cone-654> ffmpeg 03Michael Niedermayer 07master:55ef890b29ac: avcodec/iff: Print error for cols/bpp/bytes being bad in decode_delta_j() [14:41:51 CEST] <ubitux> oh man someone is angry on the ml again [14:42:36 CEST] <nevcairiel> I only asked the questions several people asked here on IRC but for some reason didnt feel like posting on the ML :p [14:50:04 CEST] <atomnuker> what the hell is up with that dan parrot guy [14:50:19 CEST] <atomnuker> now he's screaming at nevcairiel for not understanding compilers [14:51:17 CEST] <atomnuker> is there no assembler out for ppc64? [14:51:59 CEST] <nevcairiel> i bet there is, writing assembler is just harder [14:52:46 CEST] <nevcairiel> he wrote simd functions that are sometimes even slower then the C, and he wonders when we question whats wrong [14:53:03 CEST] <atomnuker> yes, exactly, I saw the numbers and some are slower than the C version [14:53:07 CEST] <BtbN> What happend to the "No SIMD" rule? [14:53:17 CEST] <atomnuker> and it's all intrinsics [14:53:28 CEST] <BtbN> or rather, no intrinsics [14:54:06 CEST] <nevcairiel> we already have a bunch of altivec intrinsics from ages ago for reasons [14:54:17 CEST] <nevcairiel> noone cared about ppc for a long time [14:56:25 CEST] <atomnuker> I wonder if the compiler backends are now good enough to beat the altivec optimizations we have [14:56:56 CEST] <atomnuker> (or maybe not since no one has cared about ppc since 2005) [15:00:25 CEST] <BBB> BtbN: no intrinsics is primarily for x86 [15:00:42 CEST] <BBB> BtbN: for x86, we have very good, definitive evidence to support the decision, which is final [15:00:57 CEST] <BBB> BtbN: we also have sufficiently many people that can write raw assembly or teach others to do so [15:01:05 CEST] <BBB> BtbN: for ppc64& we really dont have anything like that [15:02:03 CEST] <ubitux> oh there is a $1k bounty... ok. [15:03:41 CEST] <nevcairiel> hence why multiple devs asked about the motivation [15:03:45 CEST] <nevcairiel> they just didnt ask on the ML [15:03:47 CEST] <nevcairiel> only here [15:05:12 CEST] <atomnuker> I feel like it's going to backfire since the "optimizations" make some functions slower [15:20:14 CEST] <atomnuker> michaelni: you know about in-place DWTs, right [15:21:08 CEST] <atomnuker> got any tips on how to convert a line-for-level to an ordinary top-left=ll, ..., bottom-right=hh [15:21:45 CEST] <atomnuker> is non-ll even doable without having some sort of a cache [15:21:45 CEST] <cone-654> ffmpeg 03Matthieu Bouron 07master:88d9c30cf57e: lavc/mediacodecdec_h264: properly convert extradata to annex-b [15:26:29 CEST] <amishi> Hi! I noticed that ffmpeg libquvi support was removed. Is there now some other library used to read e.g. YouTube streams? [15:26:37 CEST] <BtbN> no [15:26:51 CEST] <BtbN> Use something like youtube-dl [15:28:02 CEST] <amishi> Doesn't using youtube-dl mean that I have to dl the file first and cannot stream it directly to ffmpeg via the URL? [15:28:59 CEST] <amishi> Similarly, when using ffmpeg via libav* it will not support streaming. [15:29:48 CEST] <atomnuker> amishi: youtube-dl can export the raw url you need to feed into libavcodec, look at how mpv uses ytdl [15:33:21 CEST] <Mysoft> thardin... and require a 18mb .exe for my 80kb.exe no thanks [15:34:27 CEST] <Mysoft> also that would require me having two more socket connections to pass stuff in and out ffmpeg [15:34:36 CEST] <amishi> Got it. There is a `-g` option. Thanks. [15:34:55 CEST] <amishi> Seen here: http://stackoverflow.com/a/24174801/135862 [15:35:51 CEST] <michaelni> atomnuker, IIRC full DWT can be done inplace with lifting transforms + reshuffle at the end, it might be faster to do horizontal reshuffle during the transform for better cache use [15:36:20 CEST] <michaelni> not sure that was what you aske fr [15:37:28 CEST] <atomnuker> look at deinterleave() in vc2enc_dwt.c, that's the reshuffle at the end [15:38:11 CEST] <atomnuker> problem is it breaks when the input is also the output, so that's why all the data is copied to a separate synthl buffer at the start of the transform before lifting [15:39:17 CEST] <atomnuker> nothing really blocks doing the transform in-place other than figuring out how to do the reshuffle without breaking any filter coefficients [15:40:00 CEST] <BBB> atomnuker: I certainly agree we should not accept optimizations that make stuff slower [15:40:25 CEST] <BBB> atomnuker: as for the amount of speedup, Id like more specific data on which functions get how much speedup from x86 and how that (per-func) compares to ppc64 [15:40:40 CEST] <BBB> right now its we typically get 2x for x86 but you get 1.17x on this func for ppc64 which is a little fuzzy [15:40:59 CEST] <BBB> if its we get 2x on this func for x86 but only 1.17x on ppc64, I feel solid in rejecting the patch [15:41:06 CEST] <BBB> s/solid/comfortable/ [15:42:21 CEST] <michaelni> atomnuker, if the question is how to reshuffle coeffs inplace, its always possible with one temporary coeffiient, might be more efficient with more temporary dunno. The case i worked with filled things in reshuffled order from the bitstream [15:42:32 CEST] <michaelni> so it didnt had inplace reshuffle of the whole [15:44:53 CEST] <atomnuker> michaelni: actually yeah, it should totally be possible with 4 temp coefficients [15:45:49 CEST] <atomnuker> that's how daala does it IIRC [16:14:25 CEST] <thardin> someone hilighted me? [16:17:32 CEST] <mateo`_> thardin: Mysoft did [16:18:33 CEST] <Mysoft> ^^"" [18:57:51 CEST] <cone-716> ffmpeg 03Carl Eugen Hoyos 07master:3e4357eb822c: lavc/libx265: Support gray encoding. [21:00:56 CEST] <rcombs> hmm, the FLAC muxer ignores timestamps [21:01:08 CEST] <rcombs> but they get written anyway as part of the packets [21:01:17 CEST] <nevcairiel> its a raw audio format, should that really convey timestamps? [21:01:20 CEST] <nevcairiel> audio with holes is no fun [21:01:31 CEST] <rcombs> probably not, but they're there anyway [21:01:55 CEST] <rcombs> like, do `ffmpeg -i input.flac -t 30 -c copy out.flac` and then `ffprobe out.flac` [21:02:06 CEST] <rcombs> you'll see the full duration of the original file, rather than 30s [21:02:29 CEST] <rcombs> so I guess it's just duration, not timestamps [21:07:52 CEST] <rcombs> WTF, FLAC uses UTF-8 to encode non-text [21:08:41 CEST] <JEEB> o_O [21:09:40 CEST] <rcombs> the `frame_or_sample_num` value is encoded as UTF-8 [21:09:53 CEST] <rcombs> as if it was a code point [21:10:12 CEST] <JEEB> funky [21:10:19 CEST] <rcombs> I mean, I guess it's as good a variable-length integer encoding method as any [21:10:22 CEST] <rcombs> but still, wat? [21:10:33 CEST] <JEEB> ah right, that thing that matroska's using as well [21:10:42 CEST] <rcombs> oh, does matroska do that too? [21:10:49 CEST] <rcombs> I thought they had their own variable-length int thing [21:11:02 CEST] <JEEB> it noted that it was similar to the UTF-8 one I think? [21:11:05 CEST] <JEEB> if not the same [21:12:17 CEST] <rcombs> it's pretty distinctly different [21:12:29 CEST] <JEEB> oh [21:12:59 CEST] <rcombs> 7-bit, 14-bit, 21-bit, or 28-bit [21:13:21 CEST] <JEEB> yeah, I remember the matroska thing (that sounds like it) [21:13:26 CEST] <rcombs> continuation bytes don't start with 0b10 [21:14:01 CEST] <rcombs> it's sorta similar in concept but more efficient because it doesn't need resyncing [21:14:18 CEST] <rcombs> whereas FLAC uses literally-UTF-8 for this one value [21:14:26 CEST] <nevcairiel> using a standard multi-byte code like that seems somewhat smart, rather then inventing your own :p [21:16:58 CEST] <rcombs> the matroska thing is more efficient [21:18:07 CEST] <rcombs> UTF-8 is designed to self-resync; it's not optimal for coding individual variable-length integers [21:18:21 CEST] <rcombs> (in this case, literally one of them) [21:32:31 CEST] <rcombs> nevcairiel: oh nope I'm wrong it sticks in a PTS as well [21:38:02 CEST] <rcombs> I suppose this is meant to allow arbitrary byte-based seeking [22:58:50 CEST] <cone-716> ffmpeg 03Burt P 07master:ba69a81019a2: libavfilter/af_hdcd.c: Collect HDCD stats and report [23:38:35 CEST] <michaelni> BBB, would you be interrested to be admin for the next round of outreachy ? (2016 december) [23:38:42 CEST] <BBB> no :-p [23:38:51 CEST] <michaelni> :( [00:00:00 CEST] --- Thu Jul 7 2016

1 0

ffmpeg.log.20160706
by burek 07 Jul '16

07 Jul '16

[00:01:26 CEST] <ChocolateArmpits> Threads: yeah [01:41:18 CEST] <dystopia> ffmpeg is only using about 50% of my cpu load they rest is idle [01:41:28 CEST] <dystopia> how can i get it to max out the cpu performance? [01:43:46 CEST] <dystopia> http://i.imgur.com/T4K50Ea.jpg [01:46:12 CEST] <iive> libx264 usually manages to max out 8 cores [01:46:47 CEST] <iive> so... what are you doing exactly? [01:49:16 CEST] <dystopia> encoding 1080i mpeg2 to 720x404 hdtv [01:49:24 CEST] <dystopia> to x264* [01:49:30 CEST] <dystopia> http://pastebin.com/BYJEKuEx [01:49:32 CEST] <dystopia> encoding line [01:53:04 CEST] <iive> one possibility is that yadif and scale make feeding frames slow enough for x264 to not fully load. [01:54:06 CEST] <iive> try adding -threads 4 before the filters... maybe mpeg2 decoder would start using threads for decoding. [01:54:39 CEST] <dystopia> ok will give it a shot [01:56:22 CEST] <iive> try it before the "-i" too. [01:57:51 CEST] <iive> sorry, gtg. maybe somebody else could help. [02:07:38 CEST] <dystopia> it's slower now [02:07:54 CEST] <dystopia> averaging at 35-40% cpu usage :( [04:23:47 CEST] <ThatTreeOverTher> Is there a way to change the volume of a file during playback? Is it possible to send new commands to FFserver as it streams? [04:26:55 CEST] <jnorthrup> i think i saw this question last week [04:27:07 CEST] <jnorthrup> yes, dtdin is live, you can adjust volume through stdin [04:27:27 CEST] <jnorthrup> oh sry, ffserver, nm [04:27:51 CEST] <ThatTreeOverTher> no, either one is good! I just want to change volume "interactively". [04:27:59 CEST] <ThatTreeOverTher> what is "dtdin" ? [04:31:30 CEST] <ThatTreeOverTher> Oh, I understand now. Thanks! [04:35:08 CEST] <ThatTreeOverTher> One more question: is there a way to buffer the output of FFmpeg? I'd like to stream data to a pipe, but give the playback some leeway so it doesn't start and stop. [04:35:18 CEST] <ThatTreeOverTher> (or is that what FFserver is for?) [04:41:33 CEST] <klaxa> buffering data is the job of the player [04:42:50 CEST] <ThatTreeOverTher> Darn, okay. Thanks. [04:45:07 CEST] <klaxa> i mean, it's not like you can tell the user what to do with your data, right? [04:45:27 CEST] <klaxa> what you can do is send some data from the past if it is a livestream [04:45:49 CEST] <klaxa> i think ffserver even has a setting for that, or rather it is a request parameter for the url requested by the client [04:48:00 CEST] <ThatTreeOverTher> I'm trying to pipe data through FFmpeg into a Discord stream, and I was wondering if FFmpeg could hold off on sending some of the bytes through the pipe until a certain amount were already ready [04:48:15 CEST] <ThatTreeOverTher> But I guess I could just start FFmpeg early and then pick up the bytes later or something [05:28:44 CEST] <fling> Could ffserver be used to save video to files? [05:30:45 CEST] <fling> ThatTreeOverTher: you could use mbuffer [05:31:26 CEST] <ThatTreeOverTher> oh that looks nice [05:31:53 CEST] <ThatTreeOverTher> Instead of writing to a tape, I am writing to people's ears [05:32:00 CEST] <fling> haha [05:32:13 CEST] <fling> can I see your ffserver config file? [05:33:09 CEST] <ThatTreeOverTher> I stopped using ffserver, I'm now playing with ffmpeg and its interactive stdin [05:33:18 CEST] <ThatTreeOverTher> although it's not quite working... [05:33:26 CEST] <fling> what is wrong with it? [05:34:11 CEST] <ThatTreeOverTher> I'm trying to send "all -1 volume " and then a random number, and then enter every half a second [05:34:17 CEST] <ThatTreeOverTher> the volume remains unrandomized [05:35:14 CEST] <ThatTreeOverTher> I can't find any documentation on the interactive stdin, I have no idea what I'm supposed to do or even if ffmpeg is getting my input [05:40:24 CEST] <pzich> what are you using to send that to stdin? you may need to flush the pipe between each of those [05:43:32 CEST] <ThatTreeOverTher> pzich, I'm using node.js... you're right, I hadn't considered flushing the pipe [05:44:05 CEST] <fling> D'oh! [06:20:48 CEST] <ThatTreeOverTher> is there a way for me to interactively change volume during output with ffmpeg? I know typing "c" will open a console, but I don't understand how to say "change the volume" through it [07:34:07 CEST] <ThatTreeOverTher> Okay. I figured it out. [07:34:39 CEST] <ThatTreeOverTher> Somewhere at the beginning of your ffmpeg invocation you must include "-af" and "volume" with a value I think [07:35:17 CEST] <ThatTreeOverTher> then you send it "cvolume -1 volume <modifier>" via stdin to modify its volume during the rendering process [09:32:02 CEST] <soulshock> is there a recommendation for which deinterlacing to use? i.e. which one offers a decent tradeoff between speed and quality [09:32:21 CEST] <furq> probably yadif [09:33:34 CEST] <furq> yadif in mode 1 is pretty good with a clean source [09:33:56 CEST] <furq> otherwise i tend to use qtgmc with avisynth/vapoursynth [09:34:09 CEST] <furq> you could use nnedi in ffmpeg but it's incredibly slow [09:34:42 CEST] <soulshock> ok. the source is very clean, 1080i xdcam 60mbit so yadif might be best [09:34:47 CEST] <furq> yeah yadif will be fine [09:35:14 CEST] <soulshock> and it handles motion? i.e. football matches [09:35:33 CEST] <furq> it should be fine [09:35:49 CEST] <furq> you can preview it with ffplay or vlc [09:35:58 CEST] <furq> probably mpv too [09:36:08 CEST] <soulshock> ah cool [09:36:54 CEST] <furq> for reference i get about 15fps on ntsc dvd with nnedi [09:37:01 CEST] <furq> so you'd probably be getting <5 on 1080i [09:38:24 CEST] <Nem> Hello, First time in this IRC [09:38:53 CEST] <Nem> Anyway to see a list of active members using the web client? [09:41:18 CEST] <soulshock> furq ah I'm resizing to 720p though. so it would probably be faster than 5fps [09:41:33 CEST] <furq> well you'd want to deinterlace before resizing [09:41:50 CEST] <soulshock> yeah I put -filter_complex "yadif=0:-1:0,scale=1280x720" [09:42:14 CEST] <furq> that should be 1280:720 [09:42:37 CEST] <soulshock> seems to produce same result [10:10:40 CEST] <k_sze[work]> So apparently it's possible to *push* a video stream via rtmp. [10:11:25 CEST] <k_sze[work]> Does anybody know how libraries to implement the receiving side? [10:11:32 CEST] <k_sze[work]> s/how// [10:12:01 CEST] <k_sze[work]> Does ffmpeg's libraries support acting as the receiving side of rtmp push stream? [10:49:40 CEST] <whald> hi! could someone lend me a hand figuring out how to use VAAPI to decode h264 when using libav*? I managed to do the initialization dance w/ wayland and now sit here with a AVHWDeviceContext and AVHWFramesContext, but I have no clue what to do with them. looking at the h265 decoder source, it seems to look for a hwaccel filled in in it's AVCodecContext [10:51:46 CEST] <BtbN> look at ffmpeg_vaapi.c [10:52:39 CEST] <whald> i don't really see what's up next. my ultimate goal would be to obtain frames in the AV_PIX_FMT_VAAPI format, which could then be displayed using vaGetSurfaceBufferWl: https://cgit.freedesktop.org/libva/tree/va/wayland/va_wayland.h#n91 [10:53:21 CEST] <whald> BtbN, that file was the reference for most of what I currently have, but I don't see how to kick of the actual decoding part [10:53:43 CEST] <BtbN> you set the relevant fields, and then use the normal h264 decoder. [10:56:07 CEST] <whald> BtbN, that would be pix_fmt and hwaccel_context it seems, it was in plain sight all the time... thanks! :-) [10:56:49 CEST] <BtbN> you also have to implement the get_format callback and select the right hwaccel pix fmt there. [10:58:22 CEST] <whald> BtbN, i'll try that. thanks again. [15:13:48 CEST] <hero_biz> hi all [15:14:24 CEST] <hero_biz> guys, I use a connad like this for encoding audio of a mkv file: ffmpeg -i a.mkv -vn -c:a libfdk_aac -b:a 48k audio.aac [15:14:41 CEST] <hero_biz> this is on for when there is 1 audio track. [15:15:16 CEST] <hero_biz> I wonder how I can do similar thign when there are 2 audio tracks and make 2 different .aac files. [15:17:59 CEST] <whald> hero_biz, you can specify multiple outputs and map input channels to those [15:18:30 CEST] <BtbN> Don't use .aac though [15:18:36 CEST] <whald> hero_biz, there's a nice wiki enty about this: https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs [15:18:55 CEST] <BtbN> That's raw AAC, you want to use some container, like m4a, which is essentialy just mp4, for example [15:20:55 CEST] <hero_biz> BtbN: I will use it for mkvmerge later. Will not be a standalone file or I were used .mka container [15:21:18 CEST] <hero_biz> whald: ty I will check it out [18:42:01 CEST] <satinder___> There have anyone who have expertise in ffmpeg rtsp streaming [18:42:21 CEST] <satinder___> I am using following command but that is not working [18:43:05 CEST] <satinder___> ffmpeg -i video.ts -vcodec copy -f mpegts rtsp://227.40.50.60:1234 [18:43:15 CEST] <satinder___> please anyone can help me [18:46:54 CEST] <DHE> mpegts over multicast? do you maybe just want UDP mode instead? [18:48:55 CEST] <satinder___> DHE : thank you for replay [18:49:08 CEST] <satinder___> I want use rtsp protocol for streaming [18:49:20 CEST] <satinder___> I used udp that is working fine [18:49:42 CEST] <satinder___> but when I change udp:// to rtsp:// that is not working [18:50:01 CEST] <satinder___> please give some idea how I can do rtsp streaming with ffmpeg [18:50:08 CEST] <satinder___> DHE : ?? [18:51:39 CEST] <DHE> sorry, I don't do rtsp. I do use udp though [18:52:07 CEST] <satinder___> ok thanks for giving your time :) [18:52:29 CEST] <c_14> -rtsp_transport udp_multicast ? [18:54:38 CEST] <satinder___> ok sir I will try it [18:54:49 CEST] <satinder___> c_14 : give update to you as soon [18:54:53 CEST] <satinder___> thanks :) [18:55:55 CEST] <satinder___> c_14 : I use following and got error header error [18:56:58 CEST] <satinder___> ffmpeg -i ../video.mp4 -f rtsp -rtsp_transport tcp rtsp://localhost:8888 [18:56:58 CEST] <satinder___> Could not write header for output file #0 (incorrect codec parameters ?): Connection refused [18:56:58 CEST] <satinder___> [tcp @ 0x28c3ba0] Connection to tcp://localhost:8888?timeout=0 failed: Connection refused [18:56:59 CEST] <satinder___> these two red errors comes after running above command [18:57:28 CEST] <satinder___> c_14 : what I am doing wrong sir ?? [18:57:30 CEST] <c_14> eeh [18:58:20 CEST] <satinder___> Sorry [18:58:45 CEST] <satinder___> Now you want I paste it on pastebin [18:58:48 CEST] <satinder___> ?? [18:58:53 CEST] <satinder___> please help [18:59:03 CEST] <c_14> I want everything, the command you're using along with the complete console output [18:59:09 CEST] <c_14> On a pastebin service of your preference [18:59:17 CEST] <c_14> (as long as it's not annoying to use for me) [18:59:19 CEST] <satinder___> ok sir give me 2 mins [19:03:47 CEST] <satinder___> c_14 : there is my console : http://pastebin.com/6T19sgRW [19:04:21 CEST] <satinder___> please see [19:06:59 CEST] <c_14> Do you have a process listening on tcp on port 8888 localhost? [19:07:25 CEST] <satinder___> no [19:07:32 CEST] <satinder___> you meaning any player [19:07:50 CEST] <satinder___> which have already waiting for packets ?? [19:07:56 CEST] <c_14> tcp is a connection oriented protocol, you need to have something listening on the port if you want to send something there [19:08:05 CEST] <satinder___> ok [19:08:15 CEST] <satinder___> can I use vlc for that [19:08:20 CEST] <satinder___> or ffplay [19:08:23 CEST] <c_14> sure [19:08:27 CEST] <c_14> probably [19:08:39 CEST] <satinder___> then that will work ? :) [19:08:52 CEST] <c_14> ffplay rtsp://localhost:8888 -listen 1 [19:08:56 CEST] <c_14> eh [19:09:03 CEST] <c_14> -rtsp_flags listen [19:09:58 CEST] <satinder___> 1st one I understand but what is second one ? [19:10:08 CEST] <c_14> use that instead of -listen 1 [19:10:16 CEST] <satinder___> where I can use second one or for which purpose ? [19:10:19 CEST] <satinder___> ok [19:10:22 CEST] <satinder___> thanks [19:11:27 CEST] <satinder___> thank you so much sir that is working fine [19:11:43 CEST] <satinder___> but I want know little more info [19:11:54 CEST] <satinder___> I read some forms [19:12:04 CEST] <satinder___> sorry forums [19:12:25 CEST] <satinder___> there is said , use ffserver for rtsp stream [19:12:31 CEST] <satinder___> any reason ?? [19:12:58 CEST] <c_14> I wouldn't recommend using ffserver, when it works it works but when it doesn't it doesn't and nobody really knows how to fix it and nobody really maintains it. [19:14:15 CEST] <satinder___> sir then what is main purpose of develop ffserver [19:15:14 CEST] <c_14> Some people wrote it because they wanted it/used it, now it lingers because nobody wants to delete it. [19:15:27 CEST] <satinder___> ok [19:15:51 CEST] <satinder___> thanks for giving user valuable time sir [19:15:57 CEST] <satinder___> :) [19:16:12 CEST] <satinder___> sorry your ;) [19:17:34 CEST] <DHE> next major version of ffmpeg will probably remove it [21:27:43 CEST] <defusix> Hey hey. I'm using the ffmpeg C libraries to read audio from a video/audio file and it works fine for most files. But with WAV files (that the ffmpeg CLI accepts perfectly), I get the following message: "[pcm_s16le @ 0x1e50480] PCM channels out of bounds" and avcodec_open2(...) fails. The function av_dump_format(...) gives the right information, including the number of channels. Demonstrating code: http://pastebin.com/kEuiXshG I'm using ffmpeg 3.1 I [21:27:44 CEST] <defusix> hope someone here is able to help me out [23:12:11 CEST] <defusix> I think I found the proper solution to my problem. If I copy the codec context from the right stream from the format context to the allocated codec context it works without errors. [23:12:25 CEST] <defusix> So I don't need anyone's help anymore. [23:50:36 CEST] <__raven> hi [23:50:45 CEST] <__raven> how to do rolling shutter correction of cmos footage? [00:00:00 CEST] --- Thu Jul 7 2016

1 0