Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

December 2017

1 participants
62 discussions

ffmpeg-devel.log.20171225
by burek 26 Dec '17

26 Dec '17

[01:09:43 CET] <jamrial> Gramner: ping [01:22:46 CET] <Gramner> jamrial: pong [01:23:16 CET] <jamrial> Gramner: https://pastebin.com/9KPQW85g is this ok? [01:24:14 CET] <jamrial> audio_mix.asm does some calculations with num_mmregs expecting it to be 8 or 16, and ever since the avx512 that value is 32 on x86_64 even if not using avx512 [01:26:46 CET] <Gramner> I don't think that variable was ever intended to be used outside of x86inc itself, but nasm doesn't really have any practical way of flagging such things so it doesn't surprise me that implementation details ends up being used as API [01:29:16 CET] <jamrial> i can change the asm file in question instead, but it's kinda ugly to do something like "num_mmregs - 16*notcpuflag(avx512)" [01:30:06 CET] <Gramner> I can see it being useful so I'm not against having it signal the proper thing [01:30:09 CET] <jamrial> or i could try replacing that num_mmregs usage with something like 8+8*ARCH_X86_64 [01:30:17 CET] <jamrial> alright [01:31:09 CET] <Gramner> that patch doesn't look correct though [01:31:37 CET] <jamrial> no, it's not. this should be https://pastebin.com/0aiHsTsw [01:32:08 CET] <Gramner> it's only 32 in x86-64. avx-512 doesn't give more regs in 32-bit [01:32:58 CET] <jamrial> ah right [01:37:35 CET] <iive> jamrial: shouldn't you fix audio_mix.asm instead ? [01:38:29 CET] <jamrial> i suggested that, but ideally num_mmregs would report the actual amount of regs available instead [01:39:14 CET] <jamrial> Gramner: https://pastebin.com/M19VZguZ [01:41:01 CET] <Gramner> jamrial: seems reasonable [01:43:23 CET] <iive> oh, i didn't look carefully, i saw changing 32 to 16 and thought you limit it to 16 in all cases. my bad. need sleep. [02:12:09 CET] <jdarnley> wtf? How come I never saw that failure? [02:12:56 CET] <jdarnley> oh [02:12:58 CET] <jdarnley> do you have to explicitly enable avresample? [02:14:24 CET] <kierank> yes [02:18:10 CET] <jdarnley> jamrial, Gramner: if you lower num_mmregs to 16 will it correctly reset permutations and whatnot whengoing from 16->32 and 32->16? [02:19:49 CET] <jdarnley> I guess it probably worked correctly doing 8->16 and 16->8 but mmx may have always been disabled in files which alsohave sse. [02:20:22 CET] <wm4> I've argued to enable avr for ages :( [02:24:00 CET] <atomnuker> well its getting deprecated as soon as I resubmit my patch [02:40:36 CET] <kierank> jdarnley: how much do you understand about the c idct code? [02:40:49 CET] <kierank> maybe a question for atomnuker as well [02:42:04 CET] <atomnuker> not a lot, if you were asking about the daala dct on the other hand [02:42:13 CET] <atomnuker> is it changed compared to 8bit mpeg4? [02:43:16 CET] <jdarnley> Hm, very little, most of my knowledge is about the h264 idct [02:43:59 CET] <jdarnley> (even that is fairly limited) [02:45:13 CET] <kierank> atomnuker: yes quite significantly since the coefficients are 17-bit [02:45:44 CET] <kierank> basically my question is how many more bits the transform uses [02:47:02 CET] <kierank> not sure if i can do it with 32-bit intermediates or i need 64 [02:47:22 CET] <atomnuker> I bet its designed such that normally less than or equal to 32 bits are used unless you feed it junk, in which case it might overflow [02:47:37 CET] <atomnuker> they'd have to be crazy to require 64 bit intermediaries [02:47:59 CET] <atomnuker> (especially considering its not a state of the art codec) [02:49:23 CET] <kierank> i have it working with float dct [02:54:48 CET] <kierank> atomnuker: aren't the intermediates implementation dependent? [02:57:15 CET] <atomnuker> yes, but there's a minimum you can get by with [02:57:55 CET] <kierank> "If each pixel is represented by n bits per pixel, the input to the forward transform and output from the inverse [02:57:55 CET] <kierank> transform is represented with (n+1) bits. The bit precision of the DCT coefficients changes in accordance with the [02:57:55 CET] <kierank> value of mpeg2_stream defined in StudioVideoObjectLayer(). In case of mpeg2_stream = 0, The coefficients are [02:57:55 CET] <kierank> represented in (n+7) bits including three fractional bits. " [03:06:42 CET] <kierank> atomnuker: any idea what this (of course undocumented) ricing does? https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/simple_idct_templat… [03:09:26 CET] <atomnuker> looks like SIMD done with GPRs [03:09:39 CET] <jdarnley> Yeah, that's that DC only bypass [03:10:27 CET] <kierank> jdarnley: but how does that code work independently of coefficient bitdepth [03:10:45 CET] <jdarnley> Its in the template so it gets mutated somehwo. [03:11:12 CET] <kierank> but it should use dctcoef [03:11:43 CET] <jdarnley> ah that's what youmean. [03:12:18 CET] <kierank> my guess is all codepaths assume int16_t? [03:12:51 CET] <jdarnley> I guess so [03:13:15 CET] <jdarnley> do all the supported bitdepths just have 16-bitcoefs. [03:13:17 CET] <jdarnley> ? [03:13:24 CET] <kierank> ah possibly because BBB fudges prores coefficients into 16-bit [03:15:36 CET] <jdarnley> I am wrong when I call it DC-only. It really splats the lowest frequency coefficient to the entire row. [03:33:04 CET] <cone-336> ffmpeg 03James Almer 07master:90d216cb9039: x86inc: set the correct amount of simd regs in x86_64 when avx512 is enabled but not used [05:08:56 CET] <cone-336> ffmpeg 03Karthick Jeyapal 07master:6848201f704b: avformat/http: Avoid calling http_shutdown() if end of chunk is signalled already [05:08:57 CET] <cone-336> ffmpeg 03Karthick Jeyapal 07master:be2da4c52221: avformat/hlsenc: Signal http end of chunk(http_shutdown) during hlsenc_io_close() [05:19:21 CET] <jdarnley> jamrial: thanks for fixing that [05:19:28 CET] Action: jdarnley goes to bed [12:01:05 CET] <cone-679> ffmpeg 03Paul B Mahol 07master:ec6608f51b2d: avfilter/vf_convolve: clear coefficients only when needed [12:01:06 CET] <cone-679> ffmpeg 03Paul B Mahol 07master:86e3eebfb763: avfilter/vf_convolve: use shorter variants for pointers [12:01:06 CET] <cone-679> ffmpeg 03Paul B Mahol 07master:f9f1b2a9274f: avfilter/vf_convolve: split input/output operations from fft [12:01:07 CET] <cone-679> ffmpeg 03Paul B Mahol 07master:c59e49f9b2f3: avfilter/vf_convolve: implement slice threading [12:04:45 CET] <wm4> atomnuker: also libavresample's codebase is cleaner and thus a better lib to work on [12:06:36 CET] <atomnuker> its cleaner because it has less things in it [12:06:53 CET] <atomnuker> pizza without pepperoni is a nice starting base too but you wouldn't want to eat it as-is [12:07:31 CET] <wm4> your first statement isn't true [12:08:18 CET] <wm4> also you wasted your pepperoni on a shit sandwhich [12:09:26 CET] <atomnuker> lswr is more flexible - you can write a new resampling/mixing core without breaking the old one [12:10:17 CET] <wm4> that infrastructure only exists to badly hack in sox [12:13:34 CET] <durandal_1707> hack? [12:13:51 CET] <durandal_1707> give proof to your statements [12:14:13 CET] <atomnuker> its not a hack, its rather clean, barely 100 lines of code [12:14:53 CET] <wm4> with various fun issues when I tried to use it [12:19:48 CET] <durandal_1707> like? [12:26:53 CET] <thardin> which ones do downstream projects use? [12:57:53 CET] <durandal_1707> wm4: its other way around [15:49:28 CET] <cone-241> ffmpeg 03Paul B Mahol 07master:e712d3017361: avfilter/vf_convolve: add threading for complex multiplication [15:57:22 CET] <atomnuker> ubitux: I think the doc/APIchanges line is fine, do you mean the commit message (which I didn't actually write)? [16:55:53 CET] <cone-241> ffmpeg 03Steven Liu 07master:2aee5a872332: avformat/hlsenc: fix resource leak [17:25:58 CET] <ubitux> atomnuker: it's important to specify that it's unmaintained *in FFmpeg* [17:26:36 CET] <ubitux> "better" x2 is not neutral, it's an opinion, i don't think it belongs in apichanges [17:28:26 CET] <atomnuker> fine, "more accurate and faster" then [17:33:51 CET] <jamrial> configure could emit a warning when --enable-avresample is used as well [17:34:12 CET] <atomnuker> I'll look into that as well [18:31:47 CET] <atomnuker> ubitux / jamrial: does this look better https://0x0.st/s8VT.patch ? [18:32:22 CET] <atomnuker> the warning in configure is a bit hacky since it won't work if a user uses --enable=avresample,libx264,etc but only on --enable-avresample [18:33:10 CET] <ubitux> "unmaintained by the FFmpeg project" // i think "in" is more correct english but i'm not a native speaker [18:33:51 CET] <ubitux> should be fine otherwise [18:36:27 CET] <jamrial> atomnuker: make it "enabled avresample && warn" near the end of configure instead [18:36:33 CET] <jamrial> after the check_deps() call for example [18:46:57 CET] <durandal_1707> i got deconvolve filter almost working, but i do not understand why i get artifacts [19:39:30 CET] <tmm1> michaelni: can you "curl -v" a segment from simplehttpd and see if the response is http/1.0 or http/1.1 [19:42:07 CET] <michaelni> tmm1, HTTP/1.0 200 OK [19:42:19 CET] <michaelni> Server: SimpleHTTP/0.6 Python/2.7.6 [19:42:23 CET] <tmm1> thanks, that explains it [19:42:56 CET] <tmm1> setting willclose=1 when the response version is 1.0 should fix the bug [19:47:44 CET] <tmm1> michaelni: does this work https://paste.ubuntu.com/26252718/ [19:56:16 CET] <michaelni> tmm1, doesnt work, the code is never reached, the whole if (s->is_connected_server) { body never is reached [20:04:57 CET] <tmm1> doh thats the http server path i guess [20:09:26 CET] <tmm1> how about this https://paste.ubuntu.com/26252862/ [20:17:05 CET] <tmm1> michaelni: ^^ [21:23:43 CET] <durandal_1707> i think deconvolution cant work with nonpower of 2 images anyway [21:30:32 CET] <michaelni> tmm1, doesnt work, also not with if (!av_strncasecmp ... The code triggers though [21:31:54 CET] <tmm1> hmm ok, ill try to install simplehttpd [21:31:59 CET] <tmm1> pip install wasnt working [21:32:20 CET] <tmm1> is p pointing to "http/" at all? [21:33:37 CET] <michaelni> "HTTP/1.0 200 OK" yes, the if() triggers [22:00:42 CET] <tmm1> oh huh, ok [22:25:45 CET] <durandal_1707> Compn: why you are not in #ffmpeg? [22:27:18 CET] <Compn> dont tell carl :) [22:27:27 CET] <Compn> i not subscribe to ffmpeg-user either [22:39:54 CET] <durandal_1707> there is bug with vfr files, and how are they decoded [22:49:01 CET] <durandal_1707> is there some kind of magic one can use to do non power 2 deconvolution of images? [22:58:05 CET] <atomnuker> what's preventing it from working? [23:03:56 CET] <durandal_1707> atomnuker: you can not create missing data for padded pixels [23:05:24 CET] <durandal_1707> or im missing obvious [23:06:26 CET] <atomnuker> good point [23:06:53 CET] <atomnuker> it would work on non-ptwo images then though [23:07:31 CET] <atomnuker> its just that the images need to be modulo the padding size (e.g. width == stride) [23:08:19 CET] <durandal_1707> it sort of work if you add small constant to impulse and than you get output buut with artifacts [23:10:14 CET] <durandal_1707> you could try convolve filter first and than deconvolve convolved frame [23:11:03 CET] <durandal_1707> for power of 2 dimensions you get perfect output [00:00:00 CET] --- Tue Dec 26 2017

1 0

ffmpeg.log.20171225
by burek 26 Dec '17

26 Dec '17

[00:14:08 CET] <Durandal> I don't know about .tc, ffmpeg doesn't seem to think that's a valid output format [00:14:52 CET] <Durandal> but this works for me: ffmpeg -i (file) -c:v h263p -b:v 3000K -c:a mp2 -b:a 256K "out.mpg" [00:16:57 CET] <Durandal> I don't think ffmpeg encodes divx either since it's proprietary [00:17:08 CET] <Durandal> I assume that's why you wanted h.263? [00:18:04 CET] <Durandal> Might this hardware also support mpeg4 codec since they were in the same generation? [00:19:20 CET] <iive> divx is just trademark [00:19:29 CET] <therage3> i thought it does? [00:19:31 CET] <therage3> https://trac.ffmpeg.org/wiki/Encode/MPEG-4 [00:19:38 CET] <iive> it supports mpeg4-asp and mpeg4-avc [00:21:02 CET] <Durandal> Right, ffmpeg supports the codec but I'm referring to the "hardware" that zyme mentioned [00:21:23 CET] <Durandal> which I assume is some kind of set-top [00:21:43 CET] <therage3> hmmmmmm [01:31:32 CET] <Cracki> .tc? .ts maybe? [04:05:06 CET] <zyme> Cracki_: Sorry yes, TS/MTS/MPEG-TS I don't know if I;ll ever get use to slightly shrunken laptop keyboards, esspecially when they're not backlit [04:52:59 CET] <ZexaronS> Hey guys [04:53:34 CET] <ZexaronS> Why is error/warning loglevel not displaying even the most basic info like the banner and the progress completed [04:53:45 CET] <ZexaronS> is this normal behavior? [04:54:09 CET] <ZexaronS> I am stuck with some informational messages being spammed vs nothing at all, there's nothing in between [05:23:33 CET] <kazuma_> what is being spammed? [05:24:02 CET] <kazuma_> you will probably find the "basic info" you want is flying by on an occasional line inbetween the terminal spam [05:24:12 CET] <kazuma_> but probably to fast to look at it [05:24:25 CET] <kazuma_> the spam is also an indication your settings are wrong [05:24:33 CET] <kazuma_> like wrong frame rate or somthing [06:00:06 CET] <ZexaronS> kazuma_ sorry, I was making the ticket https://trac.ffmpeg.org/ticket/6928 [06:02:42 CET] <kazuma_> hmm i didn't think ffmpeg could handle dvb subs [06:03:03 CET] <kazuma_> but i agree with the points in your ticket [06:03:27 CET] <kazuma_> i get annoyed with the spam also [06:05:20 CET] <kazuma_> what i do with dvbsubs ZexaronS is set the encode going with ffmpeg with the -sn flag, and then while it's encoding i ocr the dvbsubs to subrip .srt then mux those back in at the end [06:05:43 CET] <kazuma_> anyway 5am here, i must sleep, gotta prepare xmas dinner in a few hours [06:05:48 CET] <kazuma_> happy holidays all, o/ [06:06:02 CET] <ZexaronS> The only thing could be that maybe something isn't set right, because I never done this before, but if not, then it's a clear cut case and the devs probably weren't intending this, a green message being reprinted while there's nothing wrong with the output looks something for debug/trace not verbose/info [06:06:57 CET] <ZexaronS> kazuma_: lol also same here, I got into big cabling overhaul and still didn't recover, got 2hrs of sleep a few hours ago, and 3-4 now, what a month this was. [06:07:17 CET] <ZexaronS> happy holidays, later [06:11:51 CET] <ZexaronS> Yeah, for anyone wondering, dvbsubs at least on this TV, don't work in the TV's video player that's meant for movies and mp4 videos, because recording takes a ton of space, I figured a way to transcode them and and put them on another hdd, but need to burn-in the subs then, I didn't even thought it was possible until a few days ago when I noticed it accientially in handbrake, but that thing doesn't support dvbsubs [06:12:43 CET] <ZexaronS> I also made this ticket separately, another thing on my head for years, https://trac.ffmpeg.org/ticket/6929 [07:50:18 CET] <TheRock2> Input #0, matroska,webm, [07:50:28 CET] <TheRock2> Is matroska the video and webm audio? [07:50:49 CET] <TheRock2> ./configure --disable-everything --extra-version=QtAV --disable-debug --enable-static --disable-shared --enable-runtime-cpudetect --toolchain=msvc --extra-ldexeflags='-SUBSYSTEM:CONSOLE,5.01' --enable-avresample --enable-decoder=avi,wma,ogg,wmv,vp8,vp9,opus,vorbis,vc1,mpegvideo,flv,mp3,aac,h264,mpeg2video,mpeg4,asf,swf,mov,wav --enable-demuxer=wmv,ogg,vc1,m4v,flv,mp3,aac,avi,h264,matroska,pcm [07:50:49 CET] <TheRock2> _s16le,mov,m4v,rawvideo,wav,mpegvideo,wma,asf,swf,vp8,vp9 --enable-parser=ogg,wmv,flv,vc1,vp8,vp9,vorbis,opus,aac,h264,mpeg4video,mpegaudio,mpegvideo,wma,asf,swf,avi,mov,wav --disable-programs --disable-parser=h263 --disable-demuer=h263 --enable-protocol=file [07:50:57 CET] <TheRock2> i build ffmpeg like this, but i can only see video, no audio [07:51:16 CET] <TheRock2> i didn't add webm, tho [07:52:39 CET] <bencoh> matroska is a container (as is webm) [07:53:35 CET] <TheRock2> yeah, i thought that [07:53:53 CET] <TheRock2> i added matroska to my ffmpeg build, but no audio [07:54:12 CET] <TheRock2> ffprobe says it uses both Input #0, matroska,webm, [07:54:43 CET] <TheRock2> Stream #0:1(eng): Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s (default) [07:54:47 CET] <TheRock2> I see ac3 needs to be added? [07:57:11 CET] <bencoh> if you wanna decode ac3 then yes [07:57:41 CET] <TheRock2> yeah [07:57:47 CET] <TheRock2> otherwise i don't have audio [07:58:16 CET] <bencoh> why dont you just use the default options? [07:58:45 CET] <TheRock2> It blows up my binary [08:02:10 CET] <TheRock2> But looks like i have to use it soon [17:04:38 CET] <Mooniac> Is there a way to use mpv to only play the audio but not bring up the window? I can't find a command line option for that [17:07:48 CET] <iive> Mooniac: mplayer had -novideo, see if mpv has something similar (--novideo? --no-video?) [17:08:19 CET] <therage3> mpv --audio-display=no song.fla [17:08:21 CET] <therage3> try that [17:08:31 CET] <therage3> song.flac * sorry [17:08:50 CET] <Mooniac> ah, great, -no-video and --no-video [17:08:54 CET] <Mooniac> both work [17:08:56 CET] <therage3> and yes, mpv also has novideo [17:09:10 CET] <Mooniac> thanks, you the best1 [17:22:18 CET] <acresearch> people i used to use this command to record my screen on ubuntu: ffmpeg -f x11grab -s 1280x800 -framerate 30 -i :0.0 -c:v libx264rgb X.mkv now it just gives me a black screen, anyone can help me understand what changed? this IRC channel helped me comeup with this command [17:51:18 CET] <sfan5> why aren't you using OBS? [18:03:39 CET] <diverdude> Hi there. I am trying to run this example from the ffmpack: https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/decode_video.c on a video with these properties https://paste.ubuntu.com/26252057/ However i just get an error saying: " [mpeg1video @ 00000224989F8820] Invalid frame dimensions 0x0. Error sending a packet for decoding ". Why am I getting this error? [18:22:03 CET] <kepstin> acresearch: what version of ubuntu? [18:22:12 CET] <kepstin> acresearch: and what desktop environment? gnome? [18:22:36 CET] <kepstin> if you're running gnome on wayland, the x11grab no longer works. [22:04:06 CET] <ginkob774> HAPPY NIGGER MAS!! IF YOU WANT JOIN A CELEBRATION THAT IS NIGGER FREE PLEASE JOIN #/JOIN RIGHT HERE ON THIS NETWORK!! pnuxjmqk: c3r1c-Linux rav0_ dave0x6d raijin TheRock2 ferdna diverdude nfobot Buster ahjolinna iive jnollette nd whitekidney Stels ketas johnnny22 tontonth zukunf durandal_1707 Adarfive c3-Win momomo D [22:04:11 CET] <ginkob774> HAPPY NIGGER MAS!! IF YOU WANT JOIN A CELEBRATION THAT IS NIGGER FREE PLEASE JOIN #/JOIN RIGHT HERE ON THIS NETWORK!! ucygmwy: gix Durandal Dimtree dv_ Adarfive ahjolinna D-ion yvi Mooniac Jan\ ivanich thebombzen Kei_N Buster TheRock2 Guest2371 merzo basiclaser tontonth momomo u0m3__ raijin Johnjay AppleTor Zucca dav [22:04:16 CET] <ginkob774> HAPPY NIGGER MAS!! IF YOU WANT JOIN A CELEBRATION THAT IS NIGGER FREE PLEASE JOIN #/JOIN RIGHT HERE ON THIS NETWORK!! nczmzzokt: Zucca AppleTor gh0st__ c3-Win goiko gix johnnny22 tontonth zukunf ketas dv_ basiclaser jnollette nfobot erictapen darklink acresearch Blubberbub michaelni yvi Dimtree Johnjay Kei_N Buster the_k_ Guest2371 rav0_ Mooniac [22:04:21 CET] <ginkob774> HAPPY NIGGER MAS!! IF YOU WANT JOIN A CELEBRATION THAT IS NIGGER FREE PLEASE JOIN #/JOIN RIGHT HERE ON THIS NETWORK!! dhuhyhcqdx: whitekidney nd gh0st__ ivanich nfobot momomo goiko Blubberbub dave0x6d iml_ michaelni TheRock2 ferdna diverdude A3G1S Mooniac darklink thebombzen merzo zukunf [22:04:26 CET] <ginkob774> HAPPY NIGGER MAS!! IF YOU WANT JOIN A CELEBRATION THAT IS NIGGER FREE PLEASE JOIN #/JOIN RIGHT HERE ON THIS NETWORK!! vhlirrcle: basiclaser u0m3__ rav0_ dreamon michaelni ketas D-ion Mooniac diverdude dv_ aphirst Adarfive erictapen Blubberbub tontonth acresearch goiko nd iive iml_ ivanich Cracki_ ahjolinna the_k_ dave0x6d durandal_1707 zukunf yvi gh0st__ c3-Win Dura [22:04:31 CET] <ginkob774> HAPPY NIGGER MAS!! IF YOU WANT JOIN A CELEBRATION THAT IS NIGGER FREE PLEASE JOIN #/JOIN RIGHT HERE ON THIS NETWORK!! tymijd: merzo gix beemo_ceniza the_k_ Cracki_ johnnny22 Mooniac Blubberbub ketas iml_ Kei_N rav0_ acresearch Adarfive zukunf goiko erictapen raijin c3-Win momomo Guest2371 darklink durandal_ [22:04:36 CET] <ginkob774> HAPPY NIGGER MAS!! IF YOU WANT JOIN A CELEBRATION THAT IS NIGGER FREE PLEASE JOIN #/JOIN RIGHT HERE ON THIS NETWORK!! qfnqfeb: Dimtree u0m3__ ketas c3-Win johnnny22 iml_ beemo_ceniza thebombzen the_k_ rav0_ Zucca Mooniac Johnjay vush jnollette basiclaser durandal_1707 Kei_N erictapen nd Durandal Cracki_ Stels gh0st__ Blubberbub ferdna ivanich Adarfive dave0x6d aphir [22:10:54 CET] <Johnjay> thought it was odd someone talked to me in here [22:14:49 CET] <ferdna> @ops can you +R channel please? [22:15:28 CET] <durandal_1707> what +R do? [22:15:58 CET] <iive> allows only registered users to join [22:17:46 CET] <iive> it's ok for developers channel, but for users channel it is a problem. [22:17:53 CET] <diverdude> hi, I am trying to run the decode example: https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/decode_video.c on this mpeg1 file: http://hubblesource.stsci.edu/sources/video/clips/details/images/centaur_1.… but it just seems to spit out garbage. Is the example not working? [22:19:11 CET] <durandal_1707> diverdude: iirc it decoddes in ascii [22:20:56 CET] <diverdude> durandal_1707: hmmm but it just spits out saving frame 0 saving frame 0 saving frame 0 saving frame 0 saving frame 0 saving frame 0 saving frame 0 saving frame 0 saving frame 0 saving frame 0...and the outpufile seems kinda strange [22:21:52 CET] <diverdude> here is a small sample of the output file: https://paste.ubuntu.com/26253436/ [22:23:42 CET] <diverdude> durandal_1707: is that what its supposed to output? [22:23:47 CET] <durandal_1707> diverdude: it dumps raw pgm image format [22:24:11 CET] <durandal_1707> of only Y plane iiuc [22:25:53 CET] <diverdude> hmm yes ok...if i open it as an image it actually does have a frame....i guess it should just spit out many images....for some reason that framecounter is not incremented and the image is constantly overwritten? [22:26:17 CET] <durandal_1707> could be , lol [22:27:27 CET] <durandal_1707> i think its because of mpg format [22:27:46 CET] <diverdude> durandal_1707: its dec_ctx->frame_number which is always 0 for some reason [22:28:02 CET] <durandal_1707> does it frame counter works for other decoders? [22:28:31 CET] <diverdude> durandal_1707: i am not sure. this is the first ffmpeg program i have run in my life :) [22:29:59 CET] <diverdude> durandal_1707: but i see that this program only works on mpeg1. does ffmpeg not have some functionality that it just pics the codec needed to read a given video file? [22:30:09 CET] <diverdude> *picks [22:31:36 CET] <durandal_1707> diverdude: see other examples, demuxing_decoding.c [22:37:33 CET] <diverdude> durandal_1707: hmmm i am getting 3 errors when trying to compile it: #error missing -D__STDC_CONSTANT_MACROS / #define __STDC_CONSTANT_MACROS and error: no matching function for call to 'av_get_pix_fmt_name' and error: no matching function for call to 'av_get_bytes_per_sample' [22:38:57 CET] <durandal_1707> diverdude: there is special makefile invocation to build it iirc [22:40:31 CET] <durandal_1707> you should link with libavutil [22:50:14 CET] <diverdude> durandal_1707: but i am linking w. avutil [22:50:37 CET] <diverdude> g++ demuxing_decoding.c -o test_demux -I ./ffmpeg-20171223-d02289c-macos64-dev/include/ -L ./ffmpeg-20171223-d02289c-macos64-shared/bin/ -lavcodec -lavdevice -lavfilter -lavformat -lavutil -lpostproc -lswresample -lswscale [22:52:05 CET] <diverdude> durandal_1707: i am linking both avutil and avformat and all other libs [22:52:39 CET] <durandal_1707> diverdude: strange, let me check smthing [22:53:28 CET] <diverdude> durandal_1707: i get all binaries from here: https://ffmpeg.zeranoe.com/builds/ [22:54:52 CET] <durandal_1707> diverdude: pastebin full compilation output [22:57:56 CET] <acresearch> people i used to use this command to record my screen on ubuntu: ffmpeg -f x11grab -s 1280x800 -framerate 30 -i :0.0 -c:v libx264rgb X.mkv now it just gives me a black screen, anyone can help me understand what changed? this IRC channel helped me comeup with this command [22:59:05 CET] <diverdude> durandal_1707: here: https://paste.ubuntu.com/26253572/ [23:01:14 CET] <durandal_1707> diverdude: try to define that std macro to 1 [23:01:16 CET] <sfan5> I don't think ffmpeg headers work if you compile them as C++ [23:01:37 CET] <durandal_1707> that too [23:01:57 CET] <diverdude> oh, so it has to be c? [23:02:19 CET] <diverdude> hm....that gave way more errors :( [23:02:57 CET] <durandal_1707> diverdude: with gcc? [23:03:10 CET] <diverdude> aha [23:03:15 CET] <diverdude> all errors gone now [23:04:56 CET] <durandal_1707> for c++ you need to use some special extra code... [23:05:22 CET] <diverdude> ugh...segfault :( [23:05:53 CET] <diverdude> maybe because sample video has no audiostream? [23:06:50 CET] <durandal_1707> diverdude: could be, try with one that have audio [23:07:14 CET] <diverdude> hmm is there a place to get sample videos? [23:08:51 CET] <durandal_1707> samples.ffmpeg.org [23:13:09 CET] <diverdude> durandal_1707: hm..seems no :( this mpeg1 w. audio also segfaults (http://samples.ffmpeg.org/MPEG1/zelda%20first%20commercial.mpeg) [23:14:33 CET] <durandal_1707> diverdude: how are you calling it? [23:15:34 CET] <diverdude> durandal_1707: ./test_demux /Users/Jorgen/Downloads/sampvids/zelda.mpeg /Users/Jorgen/Downloads/sampvids/zelda_v.mpeg /Users/Jorgen/Downloads/sampvids/zelda_a.mpeg [23:17:22 CET] <diverdude> durandal_1707: shouldn't that be ok= [23:19:15 CET] <diverdude> durandal_1707: or should i somehow use that refcount option= [23:19:16 CET] <diverdude> ? [23:20:13 CET] <durandal_1707> diverdude: i will check this code tomorrow, it uses old api, but should not crash [23:20:57 CET] <diverdude> durandal_1707: i see. is there a new api available? [23:21:38 CET] <durandal_1707> diverdude: yes, this example have not been ported to it yet [23:23:09 CET] <diverdude> durandal_1707: oh i see..is this a c api or a c++ api? [23:23:45 CET] <durandal_1707> diverdude: its all c, but can be used in c++ apps [23:24:53 CET] <diverdude> durandal_1707: i see... has this been released yet? [23:25:53 CET] <durandal_1707> diverdude: yes, simpler examples already use it [23:26:39 CET] <diverdude> durandal_1707: sounds great. But i just thought i got newest already...but guess not hehe [23:32:05 CET] <diverdude> durandal_1707: in the first example i ran on line 78: https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/decode_video.c#L78, does frame->data[0] contain all the data for one frame? Basically what I want to do is to get the data of each frame so that i can do image analysis on it [23:33:09 CET] <durandal_1707> diverdude: it only contains y plane because of yuv420p poxel format [23:33:57 CET] <durandal_1707> data[1] ... Have other planes: u and v [23:34:03 CET] <diverdude> durandal_1707: aha...y-plane being what? i know this is an ignorant question...but its a 2D video, so there is only 1 plane yes? [23:34:40 CET] <diverdude> ahh [23:34:49 CET] <diverdude> its planes in the colorspace ? [23:34:51 CET] <durandal_1707> diverdude: its plane of each channel component [23:34:57 CET] <diverdude> right ok [23:35:13 CET] <diverdude> great [23:35:36 CET] <diverdude> and if i wanted to decode an mpeg4 video instead of an mpeg1, would that involve a lot of change to that program? [23:36:18 CET] <durandal_1707> no, but its very basic code [23:38:11 CET] <diverdude> durandal_1707: its more than changing the AV_CODEC_ID_MPEG1VIDEO flag to mpeg4 right? [23:38:41 CET] <durandal_1707> probably not [23:39:31 CET] <durandal_1707> just that code does no format auto detection [23:41:07 CET] <diverdude> durandal_1707: is it hard to incorporate format auto detection? [23:42:03 CET] <durandal_1707> no. look at other examples, ffmpeg.c and others code [00:00:00 CET] --- Tue Dec 26 2017

1 0

ffmpeg-devel.log.20171224
by burek 25 Dec '17

25 Dec '17

[03:10:36 CET] <mistym> Anyone have advice on prebuffering the audio/video samples in a muxer? I've got a format where I need to know the number of packets in advance in order to be able to write a correctly-sized sample table in the header, but not sure how I could handle that. [03:12:29 CET] <c3r1c3-Win> mistym: Try a circular buffer. You'll have to Google for the definition and code examples but basically you grab the data from ffmpeg, check if it's big enough to fill the buffer. If so forward the buffer to the process. If not, cycle around again. [03:14:12 CET] <mistym> c3r1c3-Win: Thanks! Do you know if there are any formats which already do this? [03:14:37 CET] <c3r1c3-Win> Sorry, I know of none. [03:14:56 CET] <mistym> OK, thanks anyway [03:48:39 CET] <jamrial> mistym: ff_interleave_add_packet [03:49:47 CET] <mistym> jamrial: Thanks! Is there a limit to how many packets I can buffer that way? [03:50:21 CET] <jamrial> not counting oom, i think not [03:51:49 CET] <mistym> It's a good thing the format I'm muxing usually maxes out at 320x224, lol [04:37:28 CET] <jamrial> tmm1: one of your recent patches introduced a memory leak http://fate.ffmpeg.org/report.cgi?time=20171224025547&slot=x86_64-archlinux… [04:43:53 CET] <tmm1> huh i didnt allocate any memory [04:44:41 CET] <tmm1> oh its an earlier patch [05:30:52 CET] <TimothyGu> BtbN: where did you get the nvidia headers in https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary? [05:31:20 CET] <TimothyGu> I downloaded the SDK but the dynlink_cuda.h in the SDK is different from the one you have [05:32:22 CET] <TimothyGu> from https://developer.nvidia.com/nvidia-video-codec-sdk that is [05:32:48 CET] <wm4> yes, our headers are modified to include dynamic loading [05:33:19 CET] <TimothyGu> yeah but like the licenses are different too [05:33:38 CET] <Compn> iirc we got permission to relicense, but dont quote me on that [05:33:47 CET] <Compn> when we got the permission to include it in ffmpeg source originally [05:33:53 CET] <Compn> going to have to go back and read ml [05:34:03 CET] <TimothyGu> oh heh. would be nice to have that linked in the README [05:34:12 CET] <Compn> good idea [05:35:05 CET] <TimothyGu> I have https://github.com/TimothyGu/nvidia-video-codec-sdk which provides a nice-ish way of looking at API differences across SDK versions [05:35:16 CET] <TimothyGu> but the headers come straight from the SDK [05:39:11 CET] <Compn> nevcairiel or BtbN should know the license history [05:39:15 CET] Action: Compn looking at old irc logs [05:43:05 CET] <Compn> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=325e56479ff64c884f3bcc… [05:43:12 CET] <Compn> looks like nvidia changed its headers [05:43:18 CET] <Compn> er header license a few times ? [05:43:32 CET] <Compn> TimothyGu : do the header license change in your repo across different sdk versions? [05:45:44 CET] <TimothyGu> Compn: no [05:45:57 CET] <Compn> when did you download the sdk versions ? [05:46:01 CET] <Compn> over time or all at once ? [05:46:34 CET] <TimothyGu> Compn: over time but not that long (over 1 year) [05:47:02 CET] <TimothyGu> actually the commit you linked doesn't say the license changed [05:47:21 CET] <TimothyGu> it says the relevant parts are still MIT, but just less accessible [05:47:49 CET] <Compn> https://github.com/TimothyGu/nvidia-video-codec-sdk/blob/v8.0/nvEncodeAPI.h [05:48:11 CET] <TimothyGu> what about it? it's still MIT [05:48:12 CET] <Compn> i was looking at irc logs when i saw BtbN say the license changed [05:48:42 CET] <Compn> so uh, what was the question? sorry its late here and im distracted [05:48:49 CET] <Compn> relicensing from mit > lgpl ? [05:49:22 CET] <TimothyGu> No I was wondering where the license in dynlink_cuda.h came from [05:49:54 CET] <Compn> oh [05:49:54 CET] <TimothyGu> The SDK has multiple files, some of which are MIT (the ones are published). Others are EULA'd. [05:50:17 CET] <TimothyGu> dynlink_cuda.h is one of the EULA files in the SDK, yet FFmpeg distributes it with a MIT license header [05:50:49 CET] <Compn> sorry i was looking at wrong file [05:53:44 CET] <Compn> is it possible its the same filename but different stuff inside ? [05:54:40 CET] <TimothyGu> it has mostly the same stuff but there are differences, yes [05:57:01 CET] <Compn> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199861.html [05:58:21 CET] <Compn> oh this maybe [05:58:21 CET] <Compn> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199859.html [05:58:37 CET] <Compn> philipl maybe knows cuda ? :) [05:59:06 CET] Action: Compn retreats to cave under his rocks [06:21:02 CET] <mistym> What's the preferred threading settings for send-email to the ffmpeg-devel list? [06:25:33 CET] <wm4> mistym: which settings are there? [06:25:54 CET] <wm4> I'm just using defaults, and it seems so do others [06:26:07 CET] <mistym> Oh, perfect. I worried my threading was too chaotic and was being annoying [06:26:13 CET] <mistym> wm4: Main ones I'm thinking of are --chain-reply-to and --thread [06:26:14 CET] <wm4> sometimes with --cover-letter or --in-replty-to [06:26:22 CET] <mistym> Yeah, I've been using those two [06:26:30 CET] <mistym> The reply I sent to you was fine then? [06:27:37 CET] <wm4> I don't think we use --chain-reply-to, the one you've just sent is the first time I saw that at all [06:28:25 CET] <wm4> yeah seems --thread --no-chain-reply-to is the default and what we normally use [06:28:40 CET] <mistym> OK, perfect - I'll make sure I'm using that then. Thanks! [07:26:10 CET] <mistym> Is 512KB an okay size for a new FATE test file? And are clips from copyrighted material okay? I was asked to contribute tests for a patchset [07:33:03 CET] <mistym> Oh, looks like there are definitely bigger samples, and clips from copyrighted material, so I should be fine [08:32:20 CET] <JEEB> mistym: yup [08:32:28 CET] <mistym> JEEB: Great, thanks! [08:32:56 CET] <JEEB> the clip should of vourse be as small as possible but no need to get too crazy [08:33:03 CET] <mistym> My patchset adds support for an audio format to MPEG files, I'm figuring an ffprobe test that makes sure the audio track is recognized should be fine [08:33:21 CET] <mistym> Yeah, I got a ~512KB clip (from an originally-7MB file) that will be fine [08:47:08 CET] <JEEB> mistym: reminds me I dhould do something similar :) [08:47:34 CET] <JEEB> althougg I'll have to check if I have any of my samples around [09:29:57 CET] <mistym> Yay, my tests passed! [10:13:41 CET] <nevcairiel> TimothyGu: the cuda header is basically reverse engineered from documentation, and not taken from their sources due to license reasons [10:18:36 CET] <cone-962> ffmpeg 03Paul B Mahol 07master:175122fcd5e6: avfilter/vf_convolve: fix convolution of borders [10:19:55 CET] <nevcairiel> it only provides a very minimal subset of functionality which we specifically needed [12:11:32 CET] <BtbN> TimothyGu, I wrote them. [12:11:50 CET] <BtbN> the dynloading stuff and the dynload_cuda [12:12:08 CET] <BtbN> The 3 main headers are from the SDK, but modified to be useable [12:14:21 CET] <BtbN> The dynload_cuda header is not from the SDK. I wrote it to have a minimal set of CUDA functions, just enough to init cuvid/nvenc. [12:14:46 CET] <BtbN> And then nvidia themselves kept sending patches to add more functions to it they needed for filters and such. [12:15:16 CET] <BtbN> dynload_cuda in the SDK is pretty much the entirety of CUDA [14:49:46 CET] <atomnuker> jdarnley: what happened to your flac asm? [17:40:09 CET] <jdarnley> atomnuker: It is still in the list. I think I took care of most of the changes requested so I will send another patch set sometime soon. [17:40:36 CET] <jdarnley> I was also going to push the avx512 set as an early christmas gift to everyone. [17:40:42 CET] <atomnuker> do it [17:48:26 CET] <durandal_17> should we ban nicolas as gift too? [18:19:07 CET] <kierank> jdarnley: yeah do dit [18:25:51 CET] <cone-253> ffmpeg 03Paul B Mahol 07master:5533cbfc84ea: avfilter/vf_convolve: fix various issues [18:26:25 CET] <durandal_17> now i just need to speed it up [18:26:54 CET] <durandal_17> and also write deconvolve vf [18:31:07 CET] <atomnuker> can't you deconvolve a convolved video by convolving it with the original convolution input^-1? [18:35:35 CET] <durandal_1707> atomnuker: nope [18:36:41 CET] <durandal_1707> actually yes, but with what you can inverse input? [18:47:38 CET] <atomnuker> a filter? [18:53:45 CET] <durandal_1707> atomnuker: what it would do? float pixel fornat support is not present in sws [18:58:12 CET] <atomnuker> yeah, you have a point, it would have to calculate the inverse of a matrix and that's slow [19:18:30 CET] <thebombzen> atomnuker: if the original matrix is invertible, which in the case of convolution filters is usually not the case [19:18:43 CET] <thebombzen> seeing as it nearly always has two identical rows or two identical columns [19:19:44 CET] <thebombzen> if you convolve a filter with a video, and then convolve that with the matrix inverse of the original video, you'll just get the filter matrix back [19:20:20 CET] <thebombzen> but if you convolve a filter with a video and convolve that with the filter's inverse, you should get the original video back. but it's unlikely that the filter will be an invertible matrix [19:22:24 CET] <durandal_1707> thebombzen: did you studied math? [19:22:36 CET] <thebombzen> yes [19:22:45 CET] <durandal_1707> wow [19:23:25 CET] <kierank> durandal_1707: did you studied trolling? [19:24:12 CET] <durandal_1707> kierank: why that, did i made mistake? [19:24:29 CET] <kierank> is your "wow" sarcasm [19:25:02 CET] <atomnuker> pretty sure that wasn't sarcasm [19:25:23 CET] <durandal_1707> kierank: no, sorry, im only sarcastic about mplayer matter and its devs [19:25:36 CET] <kierank> ok [19:28:00 CET] <tmm1> how can i run a single valgrind test locally? [19:28:28 CET] <atomnuker> compile with valgrind enabled and just run fate [19:28:45 CET] <atomnuker> the test will fail if valgrind finds something [19:30:00 CET] <durandal_1707> kierank: have you found solution for the problem you asked yesterday? [19:30:12 CET] <kierank> durandal_1707: I think yes but then i went drinking until 3am [19:30:24 CET] <durandal_1707> :) [19:42:59 CET] <tmm1> grr valgrind is useless on macOS 10.13 [21:00:31 CET] <cone-253> ffmpeg 03Aman Gupta 07master:3d95868d1bf2: avformat/hls: fix CID 1426930 [21:00:32 CET] <cone-253> ffmpeg 03Aman Gupta 07master:b33cf735071c: avformat/hls: fix memory leak with non-http segments [21:33:04 CET] <cone-253> ffmpeg 03Aman Gupta 07master:207e98b4e502: avformat/hls: fix SEGV in previous commit [22:14:38 CET] <cone-253> ffmpeg 03James Darnley 07master:b7a3d1f249c9: configure: test whether x86 assembler supports AVX-512 [22:14:39 CET] <cone-253> ffmpeg 03James Darnley 07master:8b81eabe5789: avutil: add AVX-512 flags [22:14:40 CET] <cone-253> ffmpeg 03James Darnley 07master:4783a01c113b: avutil: detect when AVX-512 is available [22:14:41 CET] <cone-253> ffmpeg 03James Darnley 07master:e2218ed8ce6e: avutil: add alignment needed for AVX-512 [22:14:42 CET] <cone-253> ffmpeg 03James Darnley 07master:8f86e6623811: avcodec: add stride alignment needed for AVX-512 [22:14:43 CET] <cone-253> ffmpeg 03Henrik Gramner 07master:f7197f68dc61: x86inc: AVX-512 support [22:14:44 CET] <cone-253> ffmpeg 03James Darnley 07master:40d4b13228bf: checkasm: support for AVX-512 functions [22:16:08 CET] <atomnuker> fuck yes avx512 [22:16:24 CET] <atomnuker> do you get those nice opmasks for free or do they cost extra cycles? [22:17:15 CET] <jdarnley> Do you mean is "vpaddw m1 {k1}, m2, m3" slower than "vpaddw m1, m2, m3"? [22:17:20 CET] <atomnuker> yes [22:18:26 CET] <jdarnley> The Intel docs say it is the same [22:19:51 CET] <atomnuker> jesus christ [22:20:17 CET] <jdarnley> There could be some instructions where it isn't but I haven't seen or heard of any. [22:21:29 CET] <jamrial> the intructions required to fill those opmask regs with something however probably cost a few cycles [22:23:16 CET] <atomnuker> if you're doing some rdo search on a bunch of coeffs (like the libvpx trellis thing) that cost would be next to nothing [22:24:03 CET] <atomnuker> the daala loopfilter (with the 3rd weights) does something that opmasks would exactly fit [22:24:27 CET] <atomnuker> could even use them to write a faster pvq search [22:46:55 CET] <jdarnley> jamrial: yes [22:47:19 CET] <jdarnley> if you want to load a constant not in memory then it is two moves. [22:49:05 CET] <jdarnley> otherwise I think you would usually create them with the compare instructions [23:38:27 CET] <TimothyGu> BtbN: oh thanks haha [00:00:00 CET] --- Mon Dec 25 2017

1 0

ffmpeg.log.20171224
by burek 25 Dec '17

25 Dec '17

[00:34:07 CET] <therage3> ok, so these are the two 1920x1080 video streams available for a video on youtube, after i download them and parse them through ffprobe: https://pastebin.com/raw/yJrXXTHD https://pastebin.com/raw/bkDCsM7b [00:34:20 CET] <therage3> is there a way to figure out from just that which one is higher quality? [00:37:31 CET] <Djfe> not really, first of all: quality is objective [00:37:37 CET] <Djfe> *subjectively [00:38:00 CET] <therage3> i see [00:38:15 CET] <Djfe> second: vp9 might be the newer codec but depending on the settings the output might look worse [00:38:24 CET] <Djfe> how have you encoded these videos? [00:38:32 CET] <Djfe> Visual comparison is probably the best [00:39:12 CET] <therage3> that's the thing, *I* didn't encode them, youtube did [00:39:21 CET] <therage3> i downloaded them from youtube (youtube-dl) [00:39:33 CET] <therage3> so all the information i have is what ffprobe yanks out [00:39:37 CET] <Djfe> The next important factor: YouTube will reencode those videos probably anyway, it doesn't have to, but if you have a file with higher bitrate available and a fast flatrate internet connection you might wanna upload that instead and let youtube do the transcoding [00:39:49 CET] <Djfe> oh lol, I see [00:39:53 CET] <therage3> wait, what?? [00:40:16 CET] <Djfe> I see, I thought you were the uploader [00:40:19 CET] <therage3> no, no, I don't want to *upload* anything on youtube [00:40:24 CET] <therage3> yeah [00:40:27 CET] <Djfe> but you're the downloader and want the best looking output [00:40:33 CET] <therage3> right, correct [00:41:03 CET] <Djfe> H.264 is better supported across hardware, but VP9 is getting there. If your device supports vp9 playback, choose vp9 ;) [00:41:26 CET] <therage3> i see, that's in terms of cross-compatibility, but necessarily video quality [00:41:30 CET] <Djfe> it'll likely look a bit better [00:41:34 CET] <therage3> i see! [00:41:41 CET] <therage3> ok that's an interesting fact [00:44:08 CET] <Djfe> personally I'm looking forward to AV1, which will be finalized end of this month. It's the best open source codec to date and will be 30-35% better compared to hevc (all around not only at high resolution). [00:44:25 CET] <therage3> that sounds good [00:44:30 CET] <Djfe> YouTube, Netflix, Twitch everybody will switch to it on the web, once it's out [00:44:36 CET] <Djfe> (from vp9) [00:45:05 CET] <Djfe> though the encoders and decoders still need to be optimized before they can be used and hardware support will take >1 year till it's out I think [00:45:55 CET] <therage3> i see [00:46:08 CET] <Djfe> The programms will be optimized for better performance (faster encode times) once the bitstream is frozen (end of this month). [00:46:57 CET] <therage3> youtube's stuff sort of sucks... the audio that comes with their video is lower quality than their separate audio-only streams for a lot of their videos [00:47:10 CET] <therage3> so to get the best video and audio, I have to download each separately and mux them [00:47:30 CET] <Djfe> http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/AV1-A-St… [00:48:01 CET] <Djfe> I didn't know that they offer audio separately, interesting ^^ [00:48:27 CET] <CoreX> just go with dash [00:48:29 CET] <CoreX> 248 webm 1920x1080 1080p 2423k , vp9, 24fps, video only, 16.96MiB [00:48:29 CET] <CoreX> 137 mp4 1920x1080 DASH video 2516k , avc1.640028, 24fps, video only, 17.08MiB [00:48:31 CET] <Djfe> 150kbit/s aac is already pretty transparent though. Are they using opus for vp9? [00:48:46 CET] <therage3> no, but *I* am lol [00:48:53 CET] <therage3> Opus is what I used to mux in with the vp9 [00:49:25 CET] <therage3> CoreX: I see, DASH is the one that isn't vp9, which Djfe suggested is perhaps the better one [00:49:55 CET] <Djfe> vp9 isn't transported over dash? [00:50:15 CET] <Djfe> dash is only the container so I thought, that it shouldn't matter [00:50:50 CET] <kazuma_> anyone know why im getting this error when trying to demux a .aac audio stream? [00:50:52 CET] <kazuma_> [ipod @ 0000000000552240] aac bitstream error [00:50:52 CET] <kazuma_> Last message repeated 11150 times [00:51:35 CET] <Djfe> https://developers.google.com/youtube/v3/live/guides/encoding-with-dash#und… [00:52:02 CET] <Djfe> therage3: I dunno why vp9 doesn't say dash, but it should actually be dash afaik [00:52:03 CET] <therage3> Djfe: https://pastebin.com/raw/MnMLNMtU << these are the available ones for download [00:52:17 CET] <Djfe> dash is a protocol not a container (misused the terminology term) [00:52:27 CET] <therage3> I see [00:53:11 CET] <Djfe> kazuma: you could report it as a bug, if you want it fixed: https://ffmpeg.org/bugreports.html [00:53:32 CET] <Djfe> kazuma: I don't know what the error means, do you hear any difference after encoding it to let's say flac? [00:54:36 CET] <therage3> Djfe: i think I may extract frames from these two videos and compare them to see how much they diffeer [00:54:39 CET] <therage3> differ* [00:55:10 CET] <Djfe> maybe the devs added dash video as a name instead of 144p or the resolution because they couldn't read the resolution at this stage unlike vp9 [00:55:39 CET] <Djfe> sounds good! :) [00:56:04 CET] <Djfe> maybe you can get the original from the uploader (depends though) [00:56:26 CET] <Djfe> anyways, I need to go to bed now, bye gn :) [00:56:37 CET] <therage3> LOL [00:56:46 CET] <therage3> the original was uploaded by Sega's official account [00:56:49 CET] <therage3> I doubt that'll ever happen [08:00:30 CET] <vush> does someone see an error if these two lines are in a loop? [08:00:32 CET] <vush> raw_image = p2.stdout.read(1280*720) [08:00:32 CET] <vush> frame = cv2.imdecode(np.frombuffer(raw_image, np.uint8), 1) [08:01:12 CET] <vush> im using subprocess. Popen and PIPE. [08:02:58 CET] <vush> and in the second run, frame is empty [08:05:29 CET] <vush> p2 looks as follows: [08:05:30 CET] <vush> p2 = Popen(["ffmpeg", "-i", "pipe:0", "-f", "rawvideo", "-filter:v", "fps=0.5", "-qscale:v", "1", "-f", "image2pipe", "-"], stdin=p1.stdout, stdout=PIPE, bufsize=10**8) [08:05:40 CET] <vush> its messy i know, added some parameters, deleted some [08:06:12 CET] <vush> -f rawvideo may be stupid, doesnt work either way [08:16:16 CET] <vush> maybe, because the frames come in bursts (while the amount of frames depends on fps obviously) of about 4 seconds there must be something i am missing. like.. read the second frame from the raw data? [08:37:03 CET] <vush> i read a solution about ramdisk. should note that i dont want to write/save ffmpeg output frames. it would be a solution but first im still trying to get the buffers right? [08:37:38 CET] <vush> i guess 1280*720 is wrong [09:27:48 CET] <vush> well the pipe breaks, nothing wrong with ffmpeg actually. gonna look around. thanks! [09:37:12 CET] <ZexaronS> Hello [09:37:44 CET] <ZexaronS> what's the "decomb" equivalent in ffmpeg, (that's how a deinterlace filter is called in handbrake) [09:38:51 CET] <ZexaronS> since I need to do burn-in dvbsub, which handbrake doesn't support, need to use ffmpeg, I used ffmpeg in the past to do pullup/detelecine/deinterlace but it was quite some time ago, I do still have the command lines which I'm looking at now [09:48:40 CET] <ZexaronS> bwdif sounds similar [10:04:14 CET] <vush> (i can stream to opencv now! it may have been parameters -f image2pipe and -vcodec rawvideo. before i went for images on HDD) [11:41:49 CET] <ZexaronS> hello [11:41:59 CET] <ZexaronS> what the heck is this "no filter found bwdif" [11:43:33 CET] <ZexaronS> Im really tired of these various editions with some things not included [11:43:45 CET] <ZexaronS> I have zeranoe for winx64 [11:50:36 CET] <ZexaronS> ah oops forgot to copy ffmpeg.exe to the correct folder [13:21:48 CET] <sazawal> I am using the command, "ffmpeg -ss timestamp -i filename -vframes 1 image.jpg" to extract frames every 0.01 seconds from an mp4 file. But the output I am getting has the same frame repeated a number of times and then appears a different frame. In other words, the frames are not continuous. What am I doing wrong? Or is there a problem in reading the mp4 file? [13:22:17 CET] <ZexaronS> Hey [13:22:57 CET] <ZexaronS> Is this still true that fps option in filters isn't meant to be used with yadif or bwdif ? Because it works and it creates ok results, but that's what the documentation says [13:24:02 CET] <ZexaronS> I could try removing it and recoding with the -r HZ option to drop duplicates [13:24:26 CET] <ZexaronS> they seem to be 99% duplicates, there's a few pixels that change [14:36:54 CET] <Guest36343> Hi, I'm using the following command to capture my screen and laptop video camera and place the video in the bottom right of the screen. It works just greta [14:37:54 CET] <pos> i'm doing -vcodec copy of some rtsp streams, the output files from some sources end up with invalid timestamps (appear to be several hours long even if they only last a few minutes [14:38:12 CET] <pos> i've tried -fflags +genpts to no avail [14:39:50 CET] <Guest36343> Hi, I'm using the following command to capture my screen and laptop video camera at the same time. The command places the video in the bottom right of the screen. It works just great. However there is a snag; I can't see the video of myself on screen while I'm recording and I want to be able to see this so I can be sure I align myself with the camer . How can I do this? [14:39:50 CET] <Guest36343> ffmpeg -f alsa -i default \ [14:39:50 CET] <Guest36343> -f x11grab -s `xdpyinfo | grep 'dimensions:'|awk '{print $2}'` -r 25 \ [14:39:50 CET] <Guest36343> -i :0.0 -f video4linux2 \ [14:39:52 CET] <Guest36343> -i /dev/video0 -filter_complex '[2:v]scale=380:-1[cam];[1:v][cam]overlay=W-w-8:H-h-8' \ [14:39:54 CET] <Guest36343> -c:a flac \ [14:39:56 CET] <Guest36343> -qscale 0 screen_and_video_grab.mkv [14:55:06 CET] <sazawal> I am using the command, "ffmpeg -ss timestamp -i filename -vframes 1 image.jpg" to extract frames every 0.01 seconds from an mp4 file. But the output I am getting has the same frame repeated a number of times and then appears a different frame. In other words, the frames are not continuous. What am I doing wrong? Or is there a problem in reading the mp4 file? [14:55:49 CET] <DHE> that only seeks to keyframes [14:56:08 CET] <DHE> also 0.01 seconds is pretty tight. is your input video actually 100fps (or higher)? [14:56:36 CET] <sazawal> DHE: I see. No its 25 fps i guess [14:56:43 CET] <DHE> there's better ways. I suggest doing them all at once in a single command... [14:57:19 CET] <sazawal> you mean including the fps argument in the command, right? [14:57:44 CET] <DHE> well, what interval do you actually want images in? all frames? every nth? [14:57:52 CET] <sazawal> I could do this, but then it would generate like 1000s of pics at once, is there a workaround to do it one at a time? [14:58:27 CET] <sazawal> DHE: if it is 25 fps then i would like at 25 fps, or more, is there a way to choose this? [14:58:59 CET] <DHE> if you put -ss after the input it will do decoding in order to select the exact frame you want. but this doesn't scale well to multiple runs to get 1 frame at a time. [14:59:25 CET] <DHE> other than the disk space required, a single shot to generate the whole movie's worth of snapshots is probably the best way to do it [15:01:49 CET] <sazawal> DHE: I see. There is also a command where the ss argument is placed after the inputfile argument. And it was quite slow when I checked it. How is it different from the one I am using? [15:03:09 CET] <DHE> -ss on the input will do a file seek, but it always lands on a keyframe. -ss on the output will skip that much time worth of the input by decoding the video but discarding the result until the desired timeframe is reached [15:04:21 CET] <sazawal> I see [15:05:48 CET] <sazawal> my input file is a movie of 700 MBs. If I use fps as the argument, like you suggested, would the size of all snapshots more than 700 MBs? [15:06:35 CET] <DHE> probably, because most video codecs operate using previous frames as references for decoding, whereas each jpeg must stand alone. [15:07:43 CET] <DHE> also jpegs are variable quality/compression so it is highly content-dependent [15:08:29 CET] <sazawal> what about pngs? Actually I need pngs, so anyway I am gonna convert the jpgs to pngs. I could directly generate pngs [15:11:18 CET] <DHE> pngs are lossless, but have worse compression typically. especially with photographic pictures [16:49:07 CET] <kepstin> if you need pngs, you should definitely generate them directly rather than convert to jpeg first [16:51:22 CET] <sazawal> kepstin: DHE , right. Well, I still think converting the whole video into frames is not good for me. If I can get a way to do them one by one, then I can delete the previous one before generating the first one. [16:51:43 CET] <kepstin> what are you actually using the result for? [16:52:05 CET] <kepstin> if this is some custom tool you're writing, you should consider using a pipe with raw frames rather than saving to files. [16:52:50 CET] <sazawal> I am writing a script to generate soft subtitles from a hardcoded one. After getting the frames, I will use OCR for text recognition. [16:53:21 CET] <MarkGG> Why does the sound become muted? I'm trying to add a text caption to the top of a video, and the output is muted even though the original has sound: ffmpeg -i public/tmp/5a3e761780cbb.mp4_topbar.jpg -i public/videos/5a3e761780cbb.mp4 -filter_complex '[0:v][1:v] vstack=inputs=2 [out]' -map [out] public/videos/proc_5a3e761780cbb.mp4 -y [16:53:46 CET] <sazawal> kepstin: Sorry, What is the concept of piping ? [16:53:50 CET] <kepstin> MarkGG: if you use the '-map' option, ffmpeg will only include the streams explicitly listed and ignore the others [16:54:10 CET] <kepstin> MarkGG: so you also have to map the audio, add e.g. "-map 1:a" to include the audio from the mp4 file [16:55:50 CET] <kepstin> sazawal: hmm, if you're just writing a shell script, a pipe probably won't work for you. Might be best to just break the video into segments (e.g. 10s-1m long), then work on a segment at a time. [16:56:40 CET] <MarkGG> kepstin: Thank you! I will test this right away [16:56:59 CET] <zukunf> hei [16:57:09 CET] <zukunf> hardcore upscaling settings? [16:57:33 CET] <zukunf> something that is capable of enhancing to the max [16:57:49 CET] <sazawal> kepstin: Yes I am writing a shell script. This sounds like a good idea to break the video into segments. By the way, the breaking would happen at the point I provide to ffmpeg? Or only at the keyframes? [16:58:12 CET] <kepstin> sazawal: for this purpose, you'd probably want to break at keyframes so you're not re-encoding the video multiple times. [16:58:24 CET] <kepstin> so you might get segments of varying length, but that's ok. [16:58:54 CET] <sazawal> kepstin: I see. Does ffmpeg give the timestamps of keyframes? [16:59:30 CET] <zukunf> what's a general purpose scaler? [16:59:54 CET] <zukunf> in my case is backwards, gif to mp4 [16:59:55 CET] <kepstin> sazawal: you shouldn't need them - I'd suggest using ffmpeg with -c copy and the "segment" muxer to write segmented files, then process each segment file into pngs one at a time in your script. [17:00:27 CET] <kepstin> zukunf: why do you need to scale at all? probably best to just encode at original resolution and scale at playback if needed [17:00:51 CET] <kepstin> zukunf: and is this a sort of pixel-art thing or photographic? [17:01:17 CET] <zukunf> kepstin: original is smaller than target output [17:01:44 CET] <kepstin> ah, you have limitations in target? like you're encoding for a dvd or bd or something with a limited set of supported resolutions? [17:02:24 CET] <kepstin> or merging multiple videos into a single stream, i guess [17:02:26 CET] <sazawal> kepstin: I am not sure I understand you. But I can learn from the internet more about it. Still, I need the timing of the keyframes so that I can place the rendered text at the right timestamps in the subtitle file. [17:03:00 CET] <kepstin> sazawal: you know the number of frames in each segment, because it's the number of png files you get. If you also know the framerate, you can calculate the timestamp from the frame number. [17:03:15 CET] <kepstin> and just keep a running count as you do each segment [17:03:31 CET] <sazawal> kepstin: Oh right, this makes sense. [17:04:33 CET] <kepstin> sazawal: anyways, what kind of visual content does the gif have? some sort of pixel-art animation or something photographic/cg? [17:04:55 CET] <zukunf> I need something simple [17:05:12 CET] <sazawal> kepstin: Another question. I am not much aware how the videos are encoded. But, is the length of the video between two keyframes is of approximately fixed length? What if a video has keyframes between 1 hour interval? [17:05:29 CET] <kepstin> er, i mentioned the wrong person there. [17:05:34 CET] <kepstin> zukunf: anyways, what kind of visual content does the gif have? some sort of pixel-art animation or something photographic/cg? [17:05:46 CET] <sazawal> kepstin: No, its a movie file. And I am extracting the hardcoded subtitles [17:05:50 CET] <kepstin> sazawal: if the video had keyframes that far apart, you wouldn't be able to seek in it :) [17:06:15 CET] <zukunf> kepstin: it's like a vid. So not a pixel art but real ppl [17:06:41 CET] <sazawal> kepstin: Oh sorry, I thought you were asking me. [17:07:07 CET] <zukunf> everything I search is gif to mp4 so I am doubpting to use those filters. [17:07:09 CET] <kepstin> sazawal: keyframe interval varies, but for typical, uh, internet downloadable video each interval will normally be no more than a couple minutes. [17:07:52 CET] <kepstin> zukunf: ok, so this is simple then. You can just use ffmpeg's standard scaler and it'll look ok. What's the original resolution and final video output size you want? [17:08:49 CET] <sazawal> kepstin: Alright. Just for the information, the piping thing you mentioned, if I cannot do it in shell script, then what is the other option, C++? Well, I can integrate a C program with the shell script, if it is handy. [17:08:59 CET] <zukunf> not much at all from 346x147 to 854x480 [17:09:42 CET] <kepstin> zukunf: hmm, so your gif is a bit wider than the video - you want black bars top/bottom? [17:09:47 CET] <zukunf> thing is, there still some room for sharpening. [17:10:12 CET] <zukunf> na, that part doesn't really matter. [17:11:16 CET] <ZexaronS> I've got a weird MPEGTS circumstance which FFMPEG will not detect, but it's playable in MPC-HC and Handbrake [17:11:49 CET] <ZexaronS> ffmpeg just says "none" [17:11:59 CET] <kepstin> zukunf: ffmpeg -i file.gif -vf "scale=854:360,pad=0:60 out.mp4" is the basic command you'll need, but you might want some extra options to do additional filtering (like sharpening) and set video quality. [17:11:59 CET] <ZexaronS> so does ffprobe, but i'll open a ticket [17:12:44 CET] <kepstin> ZexaronS: even if you set -probesize and/or -analyzeduration longer? [17:12:59 CET] <kepstin> ZexaronS: it would be helpful to see the complete ffmpeg output as well. (pastbin it) [17:13:19 CET] <ZexaronS> kepstin: oops didn't knew there's a setting like that, but I was WONDERING about it for months and never got to search for it [17:14:36 CET] <ZexaronS> yes the MPEGTS are all produced brokenly, I mostly used Handbrake for these ones because it's not something important or archival but I need to do some subtitle burn-in so I had to start using ffmpeg [17:14:53 CET] <kepstin> ZexaronS: -probesize takes an amount in bytes, defaults to ~5mb and -analyzeduration takes a value in microseconds, defaults to 5 seconds. ffmpeg stops at whichever it hits first. [17:15:03 CET] <ZexaronS> they're fine, just at the beginning at the end they're not proper, but that's how the device operates normally [17:15:23 CET] <ZexaronS> Thanks for the headsup [17:17:09 CET] <ZexaronS> microseconds, miliseconds, sure? [17:27:45 CET] <ZexaronS> kepstin: nope, I put in 300 MB and 900000000 and still nothing [17:28:25 CET] <kepstin> ZexaronS: can you pastebin the ffmpeg output please? [17:28:35 CET] <ZexaronS> already on it [17:30:07 CET] <MarkGG> kepstin: Should I be doing this differently? (When adding the 1:a to the -map parameter, it has a new error: "Unable to find a suitable output format for '[out']" --- Command: ffmpeg -i public/tmp/5a3e761780cbb.mp4_topbar.jpg -i public/videos/5a3e761780cbb.mp4 -filter_complex '[0:v][1:v] vstack=inputs=2 [out]' -map 1:a [out] public/videos/proc_5a3e761780cbb.mp4 -y [17:30:36 CET] <kepstin> MarkGG: you need two separate -map options, one for each stream [17:30:45 CET] <kepstin> MarkGG: so "-map [out] -map 1:a" [17:31:15 CET] <MarkGG> Does it matter which order those are in? [17:31:27 CET] <MarkGG> e.g. could it be "-map 1:a -map [out]"? [17:31:37 CET] <kepstin> the order they're in is the order that the streams will be included in the output file [17:31:45 CET] <kepstin> for one audio and one video, it doesn't really matter [17:32:00 CET] <MarkGG> Makes perfect sense, thank you! I appreciate it [17:55:23 CET] <diverdude> hi, what lib should i reference to get access to av_init_packet? [18:11:13 CET] <ZexaronS> Kepstin: it's a mpegts from an internal recorder on a hdtv, all of these have common broken frames in the beginning, all of them start out rough with various error that are local to that frame, a few moments into the file is where good packets start, handbrake had some problems with the ending of these files leading to this fix for example https://github.com/HandBrake/HandBrake/commit/68762017fe256de8df143331d77e0… [18:11:37 CET] <ZexaronS> Kepstin: even mediainfo seems to detect it fine, but there are missing streams and some texts off a bit [18:11:46 CET] <ZexaronS> https://pastebin.com/zn6jL8sJ [19:00:46 CET] <ZexaronS> i'm buringin in subtitles using overlay and I get spammed messages about "changing frame properties on the fly is not supported by all filters" even tho all is ok in result and this is a green message, not error, it's doing this message as it's applying the overlay, as subs are pretty much constant, it constantly messages [19:14:38 CET] <kepstin> hmm, that's probably an issue with the original video stream - mpeg-ts streams can change properties like frame size/aspect through the stream [19:14:49 CET] <kepstin> so you get that warning if something like that happens [19:15:05 CET] <kepstin> if it works, you can ignore it. but like it says, some filters might have issues. [19:57:01 CET] <Guest88180> I'm using the following command to capture my screen cast and laptop video camera at the same time. Video from the camera appears in a smallish window in bottom right of the screen cast. This works just great. However there is a snag; I can't see the video of myself on screen while I'm recording and I want to be able to see myself in the bottom right window so I can be sure I align myself with the camera. How can I do this? [19:57:01 CET] <Guest88180> ffmpeg -f alsa -i default \ [19:57:02 CET] <Guest88180> -f x11grab -s `xdpyinfo | grep 'dimensions:'|awk '{print $2}'` -r 25 \ [19:57:02 CET] <Guest88180> -i :0.0 -f video4linux2 \ [19:57:03 CET] <Guest88180> -i /dev/video0 -filter_complex '[2:v]scale=380:-1[cam];[1:v][cam]overlay=W-w-8:H-h-8' \ [19:57:05 CET] <Guest88180> -c:a flac \ [19:57:07 CET] <Guest88180> -qscale 0 screen_and_video_grab.mkv [20:06:25 CET] <BtbN> Guest88180, can't you just use OBS? [20:09:53 CET] <Guest88180> I tried out OBS last night, amongst many other softwares, and I couldn't figure it out. Ideally I will find a way to get ffmpeg to do this. I will look at OBS again later. [20:31:00 CET] <c3r1c3-Win> Guest88180: Add a display capture and a V4L2 (Video4Linux2) capture source, select the webcam. Adjust placement and size to taste. [20:34:44 CET] <Guest88180> <c3r1c3-Win> I'm not that good with ffmpeg. It was a bit of a struggle to get to here. Code above does the whole job, except does not display the video camera output in the bottom right corner. How would I adjust the given code to do that? [20:35:40 CET] <c3r1c3-Win> Guest88180: I don't use ffmpeg for stuff like that, so I couldn't really tell you. [21:12:12 CET] <ZexaronS> kepstin: Well indeed all of them come out corrupted like this, it's suppose to be normal, the original device can playback it's own normally, but there is sometimes rarely where it won't play them, maybe this file is one of those occasions [21:13:19 CET] <ZexaronS> kepstin: but judging from the fact that MPC-HC is able to play it, it's ffmpeg that subpar in the extra detection capabilities so I was thinking of trying to fix because one way or another I need this to work so I can burn the subtitles into the video [21:14:02 CET] <ZexaronS> either fix ffmpeg to detect better or fix repair the format [21:14:38 CET] <kepstin> Well, if you have a file that works with some player but not ffmpeg, then you should probably open a ticket and include a sample [21:16:09 CET] <ZexaronS> One of which I can do myself, fixing the file it self, otherwise I can only open a ticket on trac and hope this is even something that's acceptable focus for the developers, worst case that it is considered to be nonstandard file and not ffmpeg's problem to care [21:19:11 CET] <ZexaronS> However it may just the player's extra above-standard ability to handle broken files, ultimately it may not be ffmpegs fault so I'm aware that I can't expect this to be a priority or acceptable at all but I'll try [23:10:11 CET] <zyme> I like running ffplay on windows 10's ubuntu cli, it's like cool looking automatic easy-ASCII art out of any video, and is almost watchable with the font size way down lol. =) [23:12:14 CET] <therage3> i just use Linux natively, no need to go through Windows' Linux subsystem [23:25:32 CET] <zyme> dumb question, can you convert a HEVC mkv with ffmpeg to h.263 .tc video file format, and if anyone knows a short command for it offhand, I'm interested in testing performance and compatibility with hardware that doesn't like xvid but loves divx h.263... and I know it likes h264 .tc files from ffmpeg... [00:00:00 CET] --- Mon Dec 25 2017

1 0

ffmpeg-devel.log.20171223
by burek 24 Dec '17

24 Dec '17

[00:00:03 CET] <iive> it's just pointers to blocks [00:00:49 CET] <cone-218> ffmpeg 03Aman Gupta 07master:28358e466d4f: avformat/http: return EINVAL from ff_http_do_new_request() if re-used with different hostname [00:00:49 CET] <cone-218> ffmpeg 03Aman Gupta 07master:9395e44b8d20: avformat/http: add "Opening" info logging to ff_http_do_new_request [00:00:49 CET] <cone-218> ffmpeg 03Aman Gupta 07master:b7d6c0cd48da: avformat/hls: add http_persistent option [00:00:49 CET] <cone-218> ffmpeg 03Aman Gupta 07master:03765aa6fa9c: avformat/hls: allow open_input to be re-used [00:00:49 CET] <cone-218> ffmpeg 03Aman Gupta 07master:1f0eaa02aa71: avformat/hls: add http_multiple option [00:03:59 CET] <wm4> tmm1: so is this still not enabled by default, or how is it used? [00:04:58 CET] <tmm1> its enabled by default now [00:05:23 CET] <tmm1> i just sent some more benchmarks to the list [00:05:29 CET] <tmm1> 3x throughput improvement on a random internet stream i just tried [00:11:40 CET] <wm4> nice [00:13:04 CET] <StevenLi_> Great :) [00:14:06 CET] <wm4> does DASH benefit from this too? [00:14:24 CET] <kierank> iive: and in mpv_reconstruct_mb_internal how do know how to write coefficients to dest_y, cr, cb? [00:14:27 CET] <tmm1> only if the hls.c changes are copied over [00:16:15 CET] <iive> kierank: in i420 you have 6 blocks, 4 y, 1 cr and 1cb. you just point them to the correct possitions, then point to the ctx->blocks[][] . [00:16:25 CET] <kierank> it's 10-bit 444 [00:16:40 CET] <kierank> but then the dct does stuff and puts them in dest_y, cr, cb [00:16:43 CET] <StevenLi_> tmm1: can you merge it into dashdec by the way? :D [00:16:44 CET] <iive> the contex even have the pointers pre-calculated in the ctx [00:17:05 CET] <iive> you'd just have to tweak the formula or abstract the function to update it. [00:17:32 CET] <kierank> but when I decode the dpcm data it's before I know where to put it [00:17:43 CET] <iive> how so? [00:17:48 CET] <StevenLi_> by the way my means "if you convenient" :D [00:17:55 CET] <iive> you don't decode the image MB by MB ? [00:19:29 CET] <kierank> when I rebase I'll show you [00:23:27 CET] <kierank> iive: https://github.com/kierank/ffmpeg-sstp/blob/master/libavcodec/mpeg4videodec… [00:23:35 CET] <kierank> well i have to know where to decode the dpcm data [00:23:40 CET] <kierank> I can't just use s->block [00:23:46 CET] <kierank> or block2 in my case [00:31:46 CET] <iive> the code has exit(0) there. Don't you have it implemented with a memcpy? [00:32:00 CET] <kierank> not yet [00:32:07 CET] <kierank> because i don't know where to put the coefficients [00:34:55 CET] <wm4> what does PCM mean in context of video? [00:35:54 CET] <kierank> wm4: the block data is coded directly in the bitstream (no transform, quantisation etc) [00:36:10 CET] <iive> a raw bitmap [00:36:50 CET] <kierank> so where do I put the data [00:45:59 CET] <iive> why you cannot put it in block2 ? [00:47:23 CET] <iive> you can put some special mb mode, e.g. mb_intra=2 and do memcpy instead of dct later. [00:47:31 CET] <kierank> so there's no way of doing it without memcpy [00:47:39 CET] <kierank> because of mpegvideo.c being terrible [00:47:40 CET] <kierank> great [00:47:48 CET] <iive> i didn't said that [00:48:10 CET] <iive> imho, ctx->dest[] should already be set before starting decoing [00:48:19 CET] <iive> decoding [00:49:03 CET] <iive> decoding of the MB [00:51:17 CET] <iive> ff_init_block_index() [00:51:43 CET] <kierank> yes but what about [00:51:43 CET] <kierank> dest_y [00:51:46 CET] <kierank> if(readable){ [00:51:46 CET] <kierank> dest_y= s->dest[0]; [00:51:46 CET] <kierank> dest_cb= s->dest[1]; [00:51:46 CET] <kierank> dest_cr= s->dest[2]; [00:51:46 CET] <kierank> }else{ [00:51:46 CET] <kierank> dest_y = s->sc.b_scratchpad; [00:51:47 CET] <kierank> dest_cb= s->sc.b_scratchpad+16*linesize; [00:51:47 CET] <kierank> dest_cr= s->sc.b_scratchpad+32*linesize; [00:51:48 CET] <kierank> } [00:52:02 CET] <kierank> and also lowres of course [00:54:19 CET] <iive> I think a little bellow there is a code that copies the scratchpad to the dest[] possition. [00:55:29 CET] <kierank> but that happens after the coeffs are done [01:03:27 CET] <iive> you can just add another condition to set readable, that is special case for you and not bother with scratchpad [01:05:30 CET] <iive> actually if you use dest[] in the coefficients code, you can literally skip the most of the function. [01:09:35 CET] <kierank> yes, the point is that if s->dest is valid [01:17:15 CET] <iive> it should be valid at all time, it should be set at slice start and updated after every mb decoded. [01:18:52 CET] <kierank> and how do I make s->block int32-t without it breaking everything [01:18:56 CET] <kierank> and causing speed issues [01:30:12 CET] <iive> i'll leave that for another day. [01:30:26 CET] <wm4> jkqxz: looking at this cabac x264 bug - is there a magic bsf command line that adds SEI + user data to every packet? [01:30:47 CET] <kierank> iive: :( [01:31:40 CET] <kierank> michaelni: are the ffmpeg golomb codes the 00001 variant or the 11110 variant? [01:33:27 CET] <kierank> actually it's not a golomb i'm reading [01:33:38 CET] <atomnuker> pretty sure they're all the 00001 variant [01:33:52 CET] <kierank> atomnuker: do you know what the helper function is for these kind of VLCs? [01:33:56 CET] <kierank> https://usercontent.irccloud-cdn.com/file/JhAKV5Gn/image.png [01:34:46 CET] <kierank> i think the native type actually [01:43:04 CET] <cone-218> ffmpeg 03Aman Gupta 07master:54d0ef1738ff: avformat/http: return EOF from ff_http_do_new_request if previous response said Connection:close [01:43:05 CET] <cone-218> ffmpeg 03Aman Gupta 07master:5f4a32a6e343: avformat/hls: hide misleading warning when http reconnect is required [01:51:13 CET] <kierank> atomnuker: how much do you know about rice codes [01:53:12 CET] <atomnuker> only that they're a superset of golomb codes (or was it the opposite) [01:53:22 CET] <atomnuker> jdarnley ought to know more, flac uses them [01:53:50 CET] <nevcairiel> rice is a special golomb [01:54:06 CET] <jdarnley> Sorry I think I only know reverse-golomb from Dirac. [01:55:21 CET] <kierank> https://usercontent.irccloud-cdn.com/file/qsPyxIbG/image.png [01:55:30 CET] <kierank> atomnuker: any idea how to calculate the length of dpcm_residual [01:57:19 CET] <kierank> it just says "dpcm_residual: This is an unsigned integer that indicates the value of a DPCM residual" [01:58:08 CET] <nevcairiel> shouldnt the definiton of "uimsbf" tell you how to parse those values [01:58:25 CET] <kierank> sure, but doesn't explain the 4-12 [01:58:44 CET] <nevcairiel> how did you figure out the length of say block_mean. its 8-12 uimsbf [01:59:10 CET] <kierank> block mean is the average of the block and the supported bitdepths are 8-12 [02:01:31 CET] <nevcairiel> so basically the format syntax is just bonkers [02:10:12 CET] <kierank> there must be something I'm missing [02:11:13 CET] <jkqxz> wm4: The h264_metadata sei_user_data option adds it to the first packet and then every packet containing an SPS. [02:11:23 CET] <wm4> yeah you wrote that [02:11:35 CET] <jkqxz> It kindof wants to go in the extradata, but that doesn't work for H.264. [02:12:06 CET] <nevcairiel> yeah they changed their minds with hevc and have a slot for sei in extradata [02:12:12 CET] <Chloe> https://0x0.st/s8cg.err could this be caused by parsers not being loaded correctly? [02:12:16 CET] <jkqxz> (Because AVCC is too restrictive.) [02:12:22 CET] <wm4> anyway, I'm trying to fix it for playback use, fixing it with a bsf is just a curiosity [02:12:43 CET] <nevcairiel> detecting it would be nice, but not sure its in any way easy [02:12:49 CET] <wm4> especially the fact that it doesn't works with initial seeks sucks [02:12:54 CET] <wm4> -s [02:12:56 CET] <Chloe> seems to fail decoding the code block due to an overread/underread(?) [02:13:19 CET] <Chloe> i dont really know how jpeg2000 works [02:14:30 CET] <jkqxz> Detecting it is not fun. You're pretty much stuck with "if the whole frame fails to decode, try again in the other mode". [02:14:48 CET] <wm4> my current sucky idea is adding a h264 avoption to set the x264 build (if unset), and prefetching the first video packet in the demuxer to parse the x264 version [02:15:15 CET] <wm4> jkqxz: shouldn't decoding be mostly stateless, other than for frame management? [02:15:21 CET] <nevcairiel> that fixes the seek issue, but not the broken files [02:15:27 CET] <wm4> nevcairiel: yes [02:15:37 CET] <wm4> but better than nothing [02:16:16 CET] <wm4> I'd go as far as saying the h264 decoder should actually assume a buggy x264 if the version is unset and std compliance is not set to strict, but I'm sure that'd make everyone hate me [02:16:40 CET] <Chloe> how would I begin to debug this? [02:16:54 CET] <wm4> Chloe: is it a regression? [02:17:20 CET] <Chloe> I assume git master passes all fate, so probably [02:17:37 CET] <wm4> then bisect [02:17:43 CET] <jkqxz> Yes. It is certainly possible. It's just not directly detectable because the arithmetic coding is carefully designed not to be redundant, so all you can see is some unclear error sometime after the failure point. [02:18:37 CET] <wm4> jkqxz: my thought for this was unset x264_build + using 4:4:4 + decoding fails "somehow" -> enablw workaround [02:18:39 CET] <wm4> *enable [02:18:45 CET] <wm4> but that is icky too [02:19:24 CET] <Chloe> wm4: I mean it'd only be one commit which breaks it, so not sure how bisect would help (I'm checking git master now) [02:20:24 CET] <wm4> oh [02:24:52 CET] <kierank> durandal_1707: ping [02:25:48 CET] <Chloe> wm4: yep, my patch definitely breaks it, somehow. [02:27:57 CET] <wm4> Chloe: maybe a parser gets not found (or the wrong one or something like this) [02:30:12 CET] <wm4> why do we have stuff like ff_mutex_init? [02:30:19 CET] <wm4> instead of defining pthread stubs [02:33:23 CET] <Chloe> oh. so this test encodes in mjpeg first then decodes--probably choosing the wrong parser or just not choosing it at all [02:33:57 CET] <jamrial> wm4: there's a hardened version when using pthreads, and it works with no threading at all [02:35:35 CET] <jamrial> if you use pthreads directly (native or w32/os2 emulation) you'd have to wrap everything under HAVE_THREADS checks [02:36:25 CET] <wm4> not sure what you mean, but this means I'll have to use AVMutex etc. in my patches (I don't want an ifdef soup) [02:37:39 CET] <jamrial> that's what i mean. you just do ff_mutex_lock() instead of #if HAVE_THREADS pthreads_mutext_lock() #endif [02:39:20 CET] <Chloe> could just define pthreads_mutext_lock() as a noop macro if !HAVE_THREADS too [02:39:34 CET] <wm4> seems like we posted about this at pretty much the same time [02:39:55 CET] <wm4> Chloe: yeah, but for some reason it was explicitly not done - who knows why [02:40:17 CET] <Chloe> jamrial: why not use a noop macro? [02:40:18 CET] <wm4> because at ASSERT_LEVEL>1 we do: #define pthread_mutex_init strict_pthread_mutex_init [02:41:13 CET] <jamrial> that's for native pthreads only, though [02:41:55 CET] <jamrial> w32threads.h could define a bunch of noop macros, but i think it would be best if we instead just use AVMutex everywhere [02:42:22 CET] <wm4> what I mean is, we override the pthread standard names with our own stuff anyway at high assert levels [02:42:43 CET] <Chloe> why AVMutex over using/emulating/noop-ing pthreads everywhere? [02:44:27 CET] <wm4> that's the question [02:44:42 CET] <wm4> I think the argument was something about not conflicting with standard names? [02:44:52 CET] <Chloe> in atomics (once I've removed the avpriv stuff), we use normal atomics everywhere and define normal atomics for win32 which doesnt support stdatomic [02:44:59 CET] <wm4> thus why I mentioned this ASSERT_LEVEL stuff [02:45:06 CET] <Chloe> wm4: but we do this with stdatomic [02:45:09 CET] <wm4> yeah [02:45:17 CET] <Chloe> there shouldnt be any reason not to do it with pthread [02:45:27 CET] <wm4> maybe I'll send a patch later to get rid of that [02:45:33 CET] <wm4> for now I'll use AVMutex [02:46:08 CET] <wm4> michaelni: any other comments on that patch set before I update/rebase/resend them? [02:47:28 CET] <jamrial> wm4: for that matter, don't remove the InitializeCriticalSection and WaitForSingleObject redefinitions in w32threads.h [02:47:36 CET] <jamrial> even if they are unused inside that header after your patch, they are used elsewhere [02:48:02 CET] <jamrial> dxva2.c, dshow.c, vfwcap.c, hwcontext_d3d11va.c [02:48:39 CET] <jamrial> WaitForSingleObject is, at least [02:49:09 CET] <wm4> is that for winrt or something? [02:49:40 CET] <jamrial> no, for _WIN32_WINNT >= 0x0600, which will be the default now [02:50:12 CET] <wm4> I don't get it, what is that for? [02:50:53 CET] <wm4> these are normal win32 API available everywhere [02:51:42 CET] <jamrial> yes, the define is to force the usage of WaitForSingleObjectEx instead of WaitForSingleObject on Vista or newer [02:53:02 CET] <jamrial> why is it needed? i don't know, but lets not remove it unless there's a reason to [02:53:16 CET] <wm4> nevcairiel: any clue? [02:54:11 CET] <wm4> ah 428b0578c64241fc677fed7083cc8fe65e10f32e [02:54:54 CET] <wm4> claims winrt doesn't have them (unlike MSDN) [02:55:02 CET] <jamrial> so yeah, winrt related after all [02:55:23 CET] <jamrial> well, we don't have winrt fate clients to check if that's still true [02:56:27 CET] <jamrial> and again, unrelated to your patch in any case [02:56:35 CET] <wm4> yeah [02:57:59 CET] <wm4> I might be stupid, but how do you get the original avctx/context in AVCodec.init_thread_copy? [02:58:01 CET] <michaelni> wm4, i didnt had the time to look at the set, just looked briefly at one patch, so no other comments from me on the set. ill look tomorrow if i have time and if its not applied yet [02:58:29 CET] <wm4> michaelni: ok, then I'll wait [03:01:40 CET] <cone-218> ffmpeg 03Aman Gupta 07master:4c78bbd3136a: avformat/internal: log underlying error with ff_rename failure [03:06:19 CET] <mistym> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/222811.html Anyone have a suggestion on a good way to handle this? http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/222811.html [03:17:50 CET] <jamrial> mistym: just put them directly in a header [03:18:29 CET] <jamrial> we have big tables in headers, these 5 element arrays are no issue [03:19:06 CET] <mistym> Oh okay, sounds easy enough. Should they be renamed when I do that? [03:19:10 CET] <jamrial> no, you can keep the ff_ suffix that way, as well [03:19:20 CET] <mistym> Oh great, thanks! [03:37:13 CET] <mistym> jamrial: Is there a good place to look at an example of something that's done this? I'm not sure how to avoid duplicate symbols when linking [03:38:36 CET] <Chloe> wouldnt declaring them as static work [03:38:49 CET] <jamrial> mistym: mpeg4data.h [03:39:04 CET] <jamrial> and yes, what Chloe said, declare them as static const [03:39:10 CET] <mistym> Thanks! [03:40:57 CET] <wm4> jamrial, Chloe: well that would duplicate them in both binaries, but good enough [03:41:47 CET] <jamrial> they are five elements each. better this than having them as avpriv_ [03:47:42 CET] <mistym> Yeah, that did it, and `make fate` passes; thanks! [05:31:17 CET] <Chloe> atomnuker: you said you had some sed for the filter insanity [05:31:18 CET] <Chloe> ? [06:43:52 CET] <cone-498> ffmpeg 03Vishwanath Dixit 07master:d02289c386ec: avformat/hlsenc:addition of #EXT-X-MEDIA tag and AUDIO attribute [09:11:16 CET] <atomnuker> Chloe: mod the filter file to remove all #includes [09:11:18 CET] <atomnuker> then just [09:11:21 CET] <atomnuker> gcc -E libavcodec/allcodecs.c | cut -c 7- | cut -d ";" -f 1 | perl -i -pe 's/$/;/' | sed -r '/^.{,3}$/d' [09:11:26 CET] <atomnuker> except with the filter file [09:13:32 CET] <durandal_1707> kierank: pong [11:42:35 CET] <cone-897> ffmpeg 03Paul B Mahol 07master:4754d70a2325: avfilter/video: pick sar from link [11:42:35 CET] <cone-897> ffmpeg 03Paul B Mahol 07master:f6608f472553: avfilter/vf_aspect: change outlink sample aspect ratio instead of inlink [11:42:35 CET] <cone-897> ffmpeg 03Paul B Mahol 07master:b943bc343de0: avfilter/vf_fftfilt: support >8 bit depth formats [14:18:27 CET] <durandal_1707> found bug in convolve filter, nobody understands this shit [14:31:10 CET] <Chloe> atomnuker: put lavc list patch on before i start working on the other libs, don't want to start them unless lavc one looks alright [14:35:19 CET] <RiCON> tmm1: 4c78bbd3136 broke compilation with --enable-decklink https://i.fsbn.eu/KGUy.txt [15:38:32 CET] <thardin> what's the libav* way of counting the number of elements in an array? [15:38:35 CET] <thardin> I recall there being a macro [15:46:10 CET] <thardin> FF_ARRAY_ELEMS [15:47:21 CET] <atomnuker> yes [16:05:05 CET] <thardin> it's a bit meh that --enable-ffplay silently fails if libsdl2 isn't installed [16:27:09 CET] <jdarnley> Lots of the enable options silently fail if some lib is not installed. Quite annoying sometimes. [16:28:03 CET] <jdarnley> I remember the time when I didn't have zlib installed and nothing would actually make configure fail. [16:29:07 CET] <wm4> should have brhaved more like autoconf [16:29:13 CET] <wm4> behaved [16:29:55 CET] <jdarnley> What? Continue as normal then at the end print a message "I don't know what --enable-whatever means"? [16:30:05 CET] <jamrial> i think it's easy to fix. ubitux wrote this request() feature for autodetected libs that are explicitly requested in the command line [16:30:09 CET] <thardin> jdarnley: it catches that [16:30:22 CET] <jamrial> should be a matter of adding ffplay to it [16:30:45 CET] <jdarnley> sure, it might catch zlib *now* [16:33:10 CET] <jamrial> thardin: try https://pastebin.com/kUr1WinN [16:37:51 CET] <thardin> giving it a go [16:38:48 CET] <wm4> jdarnley: I thought it'd fail [16:40:28 CET] <thardin> jamrial: purged libsdl2-dev, did ./configure --enable-ffplay [16:40:37 CET] <thardin> configure succeeded, no ffplay among programs [16:40:53 CET] <jamrial> mmh [16:42:13 CET] <jamrial> what did you mean with "silently fails" for that matter? [16:43:47 CET] <thardin> jamrial: silently accepts is perhaps more apt [16:43:54 CET] <thardin> like I request ffplay but don't ge tit [16:44:52 CET] <jamrial> what should happen is that configure should fail and emit an error, much like when you do --enable-libwhatever and said library is not available [16:45:48 CET] <thardin> yeah that doesn't happen [16:47:15 CET] <jamrial> not even with the above patch? [16:48:21 CET] <thardin> unless I did something wrong in applying it. git diff seems as expected [16:55:44 CET] <RiCON> tmm1: found this thread discussing it back in 2013 https://ffmpeg.org/pipermail/libav-user/2013-January/003440.html [16:57:31 CET] <wm4> is there a problem with av_err2str somewhere? [16:58:18 CET] <wm4> oh damn [16:58:38 CET] <RiCON> yeah, it doesn't work in c++ [16:58:39 CET] <wm4> I guess some C++ files might include that file (maybe the decklink wrapper) [16:58:49 CET] <RiCON> it includes avformat/internal.h [16:58:53 CET] <wm4> and the macro requires C99 [16:59:18 CET] <wm4> it'll have to call av_strerror directly then [16:59:27 CET] <wm4> which is slightly less convenient, but no deal breaker I guess [17:00:07 CET] <wm4> (also I'd like to object that fact how horribly all this stuff is hacked into header files, probably to allow sharing between the sub-libs) [17:00:15 CET] <wm4> (can we kill the sub-libs separation yet) [17:15:27 CET] <rcombs> wm4: it's possible to work around in C++ using a static inline function and a struct containing the array [17:24:25 CET] <wm4> rcombs: how? [17:24:47 CET] <wm4> something like fn().field ? [17:24:57 CET] <rcombs> yeah [17:25:12 CET] <wm4> could work I guess [17:25:14 CET] <rcombs> actually you could probably do it with just a struct containing the array and a macro [17:25:29 CET] <rcombs> the only thing about it that doesn't work in C++ is the inline array declaration [17:54:12 CET] <cone-890> ffmpeg 03Paul B Mahol 07master:b5958ff82eed: avfilter/vf_convolve: unbreak non-power of 2 width&height filtering [18:55:20 CET] <tmm1> ugh [19:06:58 CET] <wm4> tmm1: sorry, heh [19:11:15 CET] <kierank> so I have mpeg4 pixel formats that aren't in ff_h263_hwaccel_pixfmt_list_420 [19:11:17 CET] <kierank> what do I do? [19:11:20 CET] <kierank> add them? [19:11:28 CET] <kierank> in fact they aren't even 420 [19:12:22 CET] <wm4> I think those are for hwaccels only, and no hwaccel won't support 444, so don't add them? [19:13:12 CET] <kierank> but it's needed in the pix_fmts struct [19:13:20 CET] <wm4> (I think it's all about whether get_format will include hwaccel formats if the decoder pixfmt is in that list) [19:14:03 CET] <wm4> .pix_fmts = ff_h263_hwaccel_pixfmt_list_420, [19:14:04 CET] <wm4> oh. [19:14:36 CET] <wm4> you can probably take inspiration from the h264 code (which needs to support both hwaccels and non-hw decodable formats) [19:14:47 CET] <wm4> of course it's a mess [19:15:21 CET] <durandal_1707> thats for encoding only i think [19:15:39 CET] <kierank> I can't actually get my decoder to work without putting the desired pixel format at the top of that list [19:15:41 CET] <wm4> no this is on ff_mpeg4_decoder [19:15:49 CET] <kierank> i get complaints about reconfiguring the pipeline pixel format [19:16:38 CET] <durandal_1707> huh, cant it be got in init? [19:17:37 CET] <wm4> kierank: ff_get_format should be called with only 1 sw pixfmt [19:17:51 CET] <wm4> so you need to switch between different lists, basically [19:18:19 CET] <wm4> libavcodec itself will always select the first sw pixfmt for normal decoding, I think [19:18:26 CET] <kierank> "[mpeg4 @ 0x27ccda0] format change not supported" [19:19:04 CET] <kierank> somewhere there is a big yuv420p assumption [19:19:37 CET] <durandal_1707> where you set pixel format? [19:21:01 CET] <kierank> https://github.com/kierank/ffmpeg-sstp/blob/master/libavcodec/mpeg4videodec… [19:21:06 CET] Action: kierank bbl [19:32:02 CET] <durandal_1707> look where is yuv420p set [19:52:21 CET] <durandal_170> michaelni: https://nvd.nist.gov/vuln/detail/CVE-2017-17555 [20:11:28 CET] <tmm1> RiCON: does this work https://paste.ubuntu.com/26240610/ [21:18:00 CET] <RiCON> tmm1: yes, that worked [21:32:52 CET] <tmm1> RiCON: great will commit [21:33:14 CET] <RiCON> don't forget to mention ticket #6926 [21:33:29 CET] <tmm1> im afk for a bit, so if you want to commit go ahead [21:33:40 CET] <RiCON> i don't have push access [21:38:04 CET] <cone-744> ffmpeg 03Aman Gupta 07master:9e5e3236f4f2: avformat/internal: fix compile error with some versions of g++ [21:43:08 CET] <michaelni> durandal_170, ive seen this before, its a bug in aubio, it sets up the resampler for stereo and sends mono data, which crashes because mono doesnt have a 2nd channel, its also there: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884232 [21:44:25 CET] <durandal_170> i got immpresion that swr doesnt check pointers? [22:59:19 CET] <thardin> sending in an updated codec2 patchset soon [23:17:28 CET] <thardin> there we go [00:00:00 CET] --- Sun Dec 24 2017

1 0

ffmpeg.log.20171223
by burek 24 Dec '17

24 Dec '17

[00:00:10 CET] <pos> it does, primary pulls rtsp video (and audio if embedded in the same stream) [00:00:45 CET] <pos> it supports extra ffmpeg options, like allowed_media_types and loglevel [00:00:59 CET] <pos> specifying two sources does not work, however [01:14:56 CET] <pos> are there any options in ffmpeg to ignore the embedded segment time from the source? [01:15:37 CET] <pos> i store maybe fifteen minutes of video, yet all players seem to think the file is 240 hours long (source uptime)? [01:15:42 CET] <pos> rtsp [01:18:36 CET] <sfan5> genpts? [01:19:45 CET] <pos> please explain? [01:20:11 CET] <sfan5> https://ffmpeg.org/ffmpeg-formats.html#Format-Options [01:20:16 CET] <sfan5> not exactly sure but you can try -fflags +genpts [01:31:30 CET] <pos> nope, didn't work [01:31:54 CET] <pos> and the output now appears to be even longer :) [01:37:07 CET] <greencalx> Anyone using Opus audio? I have tried ffmpeg 3.1.4 and 3.4.1 and get "Invalid data" when I pass a .opus file as input [01:40:33 CET] <pos> sfan5, yeah, playing the stream with mpv gives: No video PTS! Making something up. [01:40:33 CET] <pos> VO: [opengl] 1920x1080 yuv420p [01:40:34 CET] <pos> Invalid video timestamp: 0.000000 -> 0.000000 [01:57:14 CET] <pos> https://stackoverflow.com/questions/5522112/ffmpeg-rtsp-problem-with-ip-cam… [03:41:03 CET] <Johnjay> asdf [04:28:08 CET] <chanmyae> Hi [04:29:37 CET] <chanmyae> I would like to make text and image animation on video using ffmpeg in android development. [04:30:12 CET] <chanmyae> Let me know sample or documentation? [04:33:23 CET] <chanmyae> https://www.youtube.com/watch?v=wRciIdjLQI8 [04:34:06 CET] <chanmyae> Like video which is following above. [06:53:33 CET] <shinchiro> Did anyone able to compile ffmpeg with libxml2 on Mingw? [06:53:46 CET] <shinchiro> for some reason I got implicit declaration error [06:53:51 CET] <shinchiro> src/libavformat/dashdec.c:496:16: error: implicit declaration of function 'xmlNextElementSibling'; did you mean 'xmlNewElementContent'? [-Werror=implicit-function-declaration] [07:16:48 CET] <shinchiro> ah nvm. Found the culprit [07:19:10 CET] <fella> shinchiro: anything that might be interesting to others? [07:41:45 CET] <shinchiro> well, if you build libxml2 --with-minimum flags, you need to pass --with-tree to declare those functions [09:50:12 CET] <voltagex> http://ffmpeg.org/pipermail/ffmpeg-user/2017-December/038298.html - downmixing + copying audio stream. Any ideas? [13:41:09 CET] <nyuszika7h> how can I force showspectrumpic to show at least up to 22.05 kHz? [13:42:14 CET] <furq> nyuszika7h: it should by default but it'll truncate the y axis if the height isn't a power of 2 [13:54:40 CET] <sfan5> just use spek instead :^) [14:03:37 CET] <furq> use sox [14:05:22 CET] <furq> assuming it's one of the few formats that sox actually supports without having to pipe it through ffmpeg first [14:06:27 CET] <durandal_1707> sox is slow and sucks [14:06:50 CET] <durandal_1707> spek is awfull [14:06:52 CET] <furq> this is true but it does create nicer spectrograms than lavfi [14:07:02 CET] <durandal_1707> it doesnt [14:07:09 CET] <durandal_1707> fix eyesight [14:44:22 CET] <milek7> there is some denoising audio filter? [14:52:47 CET] <atomnuker> not yet, working on it [15:36:07 CET] <therage3> what version of lame encoder does ffmpeg use? [15:36:10 CET] <therage3> how can I tell [20:09:58 CET] <Djfe> Hi, has anyone here compared ffmpeg's native mpeg2 encoder with x262? (just wanna squeeze the most out of a dvd I'm going to burn) [20:14:17 CET] <Djfe> or is x262 not stable enough for use, yet? [20:18:38 CET] <kepstin> I don't think the public version of x262 was ever really finished [20:18:51 CET] <sfan5> http://webcache.googleusercontent.com/search?q=cache:pfhe3d9PEZMJ:johnwarbu… seems to imply that x262 is better [20:22:56 CET] <kepstin> you can tweak ffmpeg's mpeg2video encoder to do... well, almost as good as anything else, on dvds. It'll run pretty slow, and the settings are quite arcane [20:24:57 CET] <kepstin> the main issue is that the bitrate/vbv limits on dvd are just terrible. [20:32:30 CET] Action: kepstin should actually try out x262 with some dvd encodes, see what it does. [20:43:31 CET] <Djfe> thx for your replies! :) [20:43:40 CET] <Djfe> very helpful [20:46:11 CET] <Djfe> just found this: http://www.mpeg.org/MPEG/DVD/Book_B/Video.html [21:19:37 CET] <Djfe> sfan5: later down he says in the comments (2 years later): I have lately found that using FFmpeg with the mpeg2video encoder and -q:v gives even better results than x262. [21:36:30 CET] <kepstin> hmm, it would be interesting to see how a single pass with -q:v <low value> comparse to a 2-pass encode with -b:v <high value> [21:38:39 CET] Action: kepstin notes that throwing on "-dia_size 784 -mbd rd -cmp rd -mpv_flags +qp_rd+skip_rd+cbp_rd+mv0 -subcmp rd -mbcmp rd" may improve ffmpeg's mpeg2 video encoder quality, but will definitely make it a lot slower. [21:46:31 CET] Action: kazuma_ has never seen any of those switches before [21:59:32 CET] <Djfe> :D [22:38:53 CET] <diverdude> Hi, is it possible to obtain prebuilt dll files together with h files for ffmpeg for windows without having to built the entire library ? [22:45:11 CET] <diverdude> anyone? [23:11:42 CET] <Djfe> do you mean: https://ffmpeg.zeranoe.com/builds/ [23:11:45 CET] <Djfe> ? [23:14:10 CET] <therage3> what version of lame encoder does ffmpeg use? [23:14:11 CET] <therage3> how can I tell [23:25:04 CET] <CoreX> therage3 use google to find out [23:25:17 CET] <CoreX> or encode something with ffmpeg and check the metadata [23:25:22 CET] <therage3> hmmmm [23:26:16 CET] <furq> i don't think ffmpeg puts the lame version in the metadata [23:26:27 CET] <furq> it definitely doesn't write the encoder details in the xing header [23:27:19 CET] <furq> with that said lame hasn't had any updates that affected the sq for about 7 years [23:27:28 CET] <furq> so it's probably not worth knowing [23:35:46 CET] <therage3> furq: I see [00:00:00 CET] --- Sun Dec 24 2017

1 0

ffmpeg-devel.log.20171222
by burek 23 Dec '17

23 Dec '17

[00:16:07 CET] <BtbN> I still prefer cygwin [00:16:10 CET] <BtbN> it integrates better [00:25:44 CET] <nevcairiel> wm4: i can build with a vista level defined on the command line right now, how does the configure pollfd thing exhibit itself? [00:27:44 CET] <Chloe> BtbN: I thought you could only run cygwin stuff inside of cygwin? [00:27:55 CET] <Chloe> Why does it integrate better? [00:28:10 CET] <BtbN> Because you can properly run win32 stuff inside of cygwin [00:28:28 CET] <BtbN> and you can run a cygwin built binary outside of cygwin, as long as its dependency dlls are there [00:28:42 CET] <nevcairiel> i've had cygwin mess up my filesystem persmissions before, so i dont touch it again [00:29:44 CET] <wm4> nevcairiel: if you define it on the command line, the check for pollfd will detect its presence and it works [00:30:12 CET] <wm4> nevcairiel: it only fails when the w32thread check raises the OS version (after all those checks including pollfd ) [00:30:56 CET] <nevcairiel> on that, isnt that probe_libc thing already raising the version before the w32thread thing? [00:33:03 CET] <wm4> I remember modifying this [00:33:19 CET] <wm4> maybe it's because _WIN32_WINNT wasn't set at all [00:33:37 CET] <nevcairiel> i would think including windows.h would always have it set to something [00:33:42 CET] <wm4> should it just set the API level even if it's undefined? [00:34:13 CET] <wm4> it's mysterious to me how that is set in the first place [00:46:20 CET] <cone-395> ffmpeg 03Karthick J 07master:93a0e478768e: avformat/hlsenc: set EXT-X-TARGETDURATION use lrint(EXTINF) [00:46:21 CET] <cone-395> ffmpeg 03Karthick J 07master:e3b2c8502b33: avformat/dashenc: avformat/dashenc: Fix the EXT-X-TARGETDURATION as per the hls specification [01:21:31 CET] <jamrial> nevcairiel: on mingw-w64 it's set to 0x502 by default (winxp/2003). on msvc it's apparently set to 0x601 (win7) [01:26:13 CET] <wm4> yeah that would explain the behavior I've seen [01:29:54 CET] <jamrial> and mingw32 (old i think dead project) to win98 :p [01:32:51 CET] <Chloe> jdarnley: yep, configure seems to run really fast in WSL [01:33:28 CET] <Chloe> This should lessen the pain of making changes to it now, it only takes 5 min (down from ~30 min previously) [05:18:45 CET] <mistym> When I was looking at adding a new feature, I found a patch for it on trac: https://trac.ffmpeg.org/ticket/3233 I've submitted an improvement, but I was wondering what the best way would be for me to get feedback and help push this over the finish line so the patches can be accepted. [05:20:39 CET] <wm4> mistym: you pretty much need to send patches to the mailing list [05:21:20 CET] <mistym> wm4: Ah, okay. Thanks! I'll send them there. [05:25:16 CET] <mistym> I was also hoping to get advice on the best way to handle writing a header format for a muxer I'm working on. [05:25:56 CET] <mistym> The format includes a sample table with an entry for every video or audio chunk in the file, located as a part of the header at the beginning of the file. I'm not sure how to reserve enough space though, because the number of video/audio chunks isn't provided up front in libavformat. [05:28:06 CET] <wm4> yeah, if you really need to know exactly, you'd probably have to buffer all data upfront [05:29:04 CET] <mistym> Is there a good example for something that does this I could use as a reference? [07:53:19 CET] <lrusak> jkqxz: is there a way to get a drmprime output for sw decode? [08:09:33 CET] <wm4> lrusak: what would that even mean? [08:09:50 CET] <lrusak> it's a moot point [08:10:38 CET] <lrusak> was just wondering if we could get a drmprime encapsulated buffer from sw decode [08:11:12 CET] <wm4> you can use get_buffer2, which is designed for using a user provided buffer [08:11:33 CET] <lrusak> ok interesting [08:11:52 CET] <lrusak> I'm just wondering how we can fall back if the hw decoder doesn't support decoding a certain format [08:12:08 CET] <lrusak> say on v4l2, but the driver doesn't support vp9 [08:12:39 CET] <lrusak> can we use the same renderer to set the drm plane directly from the output of ffmpeg sw decode [08:14:48 CET] <wm4> this could probably be made simple by adding frames allocation to hwcontext_drm, and mapping that for get_buffer2 (but not sure if such a contraption would work out nicer than doing it manually) [08:15:33 CET] <lrusak> hmm ok :) [08:15:42 CET] <wm4> hm that assumes drm can use yuv420p, which it probably can't [08:15:51 CET] <wm4> (likely would use nv12 only or so) [08:15:57 CET] <wm4> ah whatever [08:15:59 CET] <lrusak> yes nv12 is typically [08:16:04 CET] <lrusak> used [08:16:10 CET] <wm4> so you'd need to copy/repack the data anyway [08:16:19 CET] <wm4> (and preferably not with libswscale, which is slooow) [08:16:51 CET] <wm4> sometimes I wonder what (dis)advantages adding nv12 support to sw decoding would have [08:17:22 CET] <wm4> obviously x264 thought it was worth doing (it accepts nv12 input for encoding) [08:18:17 CET] <nevcairiel> in the past people have said it might be 1-2% faster, but obviously it would require a lot of work [10:02:28 CET] <wm4> wbs: I wonder what are our chances to get rid of avformat_network_init()? [10:03:19 CET] <wbs> wm4: it depends on whether you can do a threadsafe global init of all the supported tls libraries [10:03:48 CET] <wbs> iirc gnutls should be fine these days, as long as you don't support 2.x versions I think [10:03:53 CET] <wbs> openssl I dunno [10:04:46 CET] <wm4> and WSA? [10:05:19 CET] <wbs> the winsock init itself should be threadsafe and atomically refcounted [10:05:51 CET] <wbs> i.e. fine to stick in the startup of tcp/udp protocols [10:06:49 CET] <wm4> for openssl we still use this weird external mutex stuff [10:07:43 CET] <wbs> yes, that's one thing - I think that can be skipped in modern versions (but do check before removing), but the other question is whether it's safe to run e.g. SSL_library_init from multiple threads at the same time [10:09:53 CET] <wm4> openssl is such a mess [10:10:55 CET] <wbs> yup, but at least some of it should be possible to clean up if you drop support for older versions (back when I wrote that in 2011 or so, supporting such old versions were more of a must) [10:58:13 CET] <jkqxz> lrusak: It very much depends on what you want to do with the buffers afterwards. [10:59:03 CET] <jkqxz> If you only want output to scanout on a KMS device, then you can allocate dumb buffers in a common way (I wrote some code for this in <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212547.html>). [10:59:54 CET] <jkqxz> But, that does still need to know the format, which will involved querying the output device - many things do not support NV12 output. [11:02:09 CET] <jkqxz> If you want to use the buffers for something else then it quickly becomes system-specific. You pretty much need to know how allocation works with GEM per-DRM-driver. [11:05:45 CET] <jkqxz> For some cases you may be able to get GBM to do it, but that is really meant for render targets rather than sources. [12:32:48 CET] <durandal_1707> can i get fast review of my lut patch? [12:39:16 CET] <BtbN> wm4, doesn't x264 natively use nv12, and "normal" I420 was added for convenience? [12:39:49 CET] <wbs> BtbN: yes, but iirc it originally used I420 and they switched the internals at some point [12:41:43 CET] <jdarnley> durandal_1707: is that "add support for gray formats"? [12:46:21 CET] <durandal_1707> yes [12:51:41 CET] <jdarnley> :) not much to it but it looks good to me (I also sent an email) [13:58:49 CET] <cone-216> ffmpeg 03Paul B Mahol 07master:d2a2bc9a9f30: avfilter/vf_lut: add support for gray formats [14:09:35 CET] <kierank> rcombs: wm4: can you make ps4 plex play at native refresh rate [14:09:37 CET] <kierank> kthx [14:16:08 CET] <durandal_17> what happened to register filter patch set? [14:23:22 CET] <atomnuker> Chloe's gonna do it as soon as he finishes the lavc one [14:23:58 CET] <atomnuker> (or me if he can't, I have the gcc/sed hackery to convert REGISTER_FILTER to extern) [14:29:42 CET] <durandal_1707> Chloe is wasting time by playing games [14:30:31 CET] <atomnuker> wasn't that called "self-improvement"? [14:34:01 CET] <iive> atomnuker: btw, what happened with that systemd error? did you fixed it, or you reinstalled? [14:34:42 CET] <atomnuker> lost my usb flash, got a new one yesterday, wondering what to install, I think I'll go with arch [14:36:10 CET] <atomnuker> btw is there a filesystem that both linux and mac suppor that has support for more than 4gb files? [14:36:43 CET] <atomnuker> I got a 128gb flash because it was cheap but I'm not going to make it useless by formatting the whole as fat32, maybe 16gb [14:45:41 CET] <nevcairiel> ExFAT probably [14:46:14 CET] <nevcairiel> its the default filesystem for bigger SD cards now [14:46:44 CET] <Chloe> How have people setup WSL for building ffmpeg? I figured a mingw compiler then: `./configure --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32- --host-os=mingw32` but then fate doesnt pick up any of the binaries cause they're all .exe [14:49:54 CET] <durandal_1707> why? use linux [14:50:10 CET] <Chloe> I cant run VMs, my computer is too slow [14:50:54 CET] <durandal_1707> Chloe: ask for some ffmpeg sponsoring [14:54:17 CET] <Chloe> seems a bit excessive just to be able to build ffmpeg, surely someone here is using WSL [14:56:21 CET] <atomnuker> nevcairiel: exfat works on macs? [14:56:40 CET] <nevcairiel> if not, you should sue apple for being dumb fucks :) [14:57:25 CET] <Chloe> atomnuker: afair it does [14:57:47 CET] <Chloe> Though last I tested it was previous macOS version, my mac has since packed up. [15:16:52 CET] <RiCOM> atomnuker: it should, that was kinda the point of making it [15:19:46 CET] <wm4> kierank: I can't make anything at plex anymore, lol [15:20:11 CET] <kierank> wm4: did you leave? [15:36:24 CET] <kierank> BBB: http://obe.tv/about-us/obe-blog/item/50-avx-512-what-s-useful-for-us [15:36:29 CET] <kierank> and others I guess [15:36:47 CET] <BBB> put it on hackernews :-p [15:37:07 CET] <kierank> jdarnley needs to check it first [15:37:10 CET] <mistym> Well, messing up `git send-email` probably wasn't the best first mailing list impression. [15:37:11 CET] <kierank> and other simd geeks [15:37:47 CET] <BBB> `pcmpgtq; pand; pandn; por` <- the r is not in a code style [15:38:03 CET] <kierank> ah [15:38:03 CET] <kierank> hmm [15:38:05 CET] <BBB> in the Maximum and minimum of packed signed quadwords can be emulated with `pcmpgtq; pand; pandn; por` and a spare register. paragraph [15:39:49 CET] <kierank> BBB: ? [15:39:59 CET] <mistym> For future reference: what's the best etiquette for sending a set of multiple patches as a part of a change? git send-email sent one email for each patch, along with the cover letter, which I'm assuming was bad form on my part. [15:40:28 CET] <BBB> the code fragment ocurs a few times, wanted to make sure which one I meant [15:40:37 CET] <BBB> so ignore if you knew what I meant in th sentence before it [15:40:48 CET] <atomnuker> holy shit opmasks [15:41:28 CET] <Chloe> mistym: you can get git send-mail to send multiple just by selecting multiple [15:42:04 CET] <unknowguy> Hi all, I just know a little bit of C and i am thinking to contribute To Ffmpeg , but i am not sure where to start.. https://www.ffmpeg.org/developer.html this page only describes Coding Rules and other stuff....Is there any place i can learn can have a look at overview description of FFMpeg codebase and also i think i need to learn some other things about video encoding,codec etc. any [15:42:05 CET] <unknowguy> guide would be appreciated . Thanks [15:42:58 CET] <durandal_1707> unknowguy: first spell FFmpeg 1000 times [15:44:01 CET] <unknowguy> :O ? my spelling of FFmpeg is correct [15:44:13 CET] <atomnuker> unknowguy: not really, I suggest just going into the file of whatever codec you find interesting and playing with it [15:44:29 CET] <mistym> Chloe: Thanks! What I meant was, was one email per patch fine? Or did I accidentally spam the list? :b [15:46:23 CET] <Chloe> mistym: what's your patch? [15:46:52 CET] <mistym> Chloe: Looks like it didn't get posted (might have forgotten to confirm my list membership before sending), but it was the "Sony MPEG with ATRAC-3 audio support" thread [15:47:32 CET] <Chloe> dont have to be on the list to send to it I think [15:47:42 CET] <Chloe> your mail setup is probably just broken [15:48:26 CET] <BBB> unknowguy: most people would suggest finding a feature thats missing and that youre personally interested in, or finding a bug on trac.ffmpeg.org, or something like that [15:48:28 CET] <mistym> It's a moderated list, got a message about being held since it was from a non-member. [15:50:52 CET] <Chloe> Compn: ^ [15:51:18 CET] <kierank> jdarnley: do you have HN? [15:51:21 CET] <kierank> can you post that link [15:51:30 CET] Action: kierank has to wait 60 minutes [15:51:42 CET] <BBB> I can post [15:51:52 CET] <jdarnley> no [15:52:11 CET] <jdarnley> i was banned for being too negative [15:52:11 CET] <BBB> nomepost? [15:52:27 CET] <BBB> https://news.ycombinator.com/item?id=15987796 [15:52:52 CET] <kierank> jdarnley: loooool [15:53:58 CET] <BBB> what cpus support the new xmm/ymm instructions? [15:54:10 CET] <BBB> skylake-x also? [15:55:17 CET] <jdarnley> i think all the cpus currently support all the not-phi features [15:56:29 CET] <jdarnley> if that makes sense [15:57:19 CET] <jdarnley> Gramner has linked to a venn diagram in the past i will try to find it [15:58:37 CET] <jdarnley> https://twitter.com/InstLatX64/status/870285161979682818 [16:01:24 CET] <kierank> https://www.reddit.com/r/programming/comments/7lhv11/avx512_whats_useful_fo… [16:01:28 CET] <kierank> people keep downvoting :( [16:08:21 CET] <kierank> durandal_17: right, holidays start now, gonna finish ripping out mpegencctx from mpeg4video [16:12:49 CET] <Chloe> `./configure --samples=fate --arch=x86_64 --target-os=mingw64 --host-os=mingw64 --cross-prefix=x86_64-w64-mingw32-` on WSL leads to `make fate` not adding .exe for tests somehow [16:20:53 CET] <nevcairiel> try using --target-exec [16:24:04 CET] <kierank> jdarnley: congrats, hn front page [16:29:23 CET] <Chloe> nevcairiel: and write a wrapper to tack on .exe? [16:30:08 CET] <Chloe> no that wouldnt work [16:38:14 CET] <funman> atomnuker: how did you test rtpdec_rfc4175.c ? I don't see how ffmpeg or ffplay handle SDPs [16:41:04 CET] <funman> looks like my sdp was incomplete [16:44:04 CET] <funman> well it crashes imediately [16:45:27 CET] <funman> doesn't like timestamps fixed at 0 it seems [17:00:02 CET] <Gramner> BBB / jdarnley: https://twitter.com/InstLatX64/status/918796987352408064 is more up-to-date (with ICL and KNM added) [17:00:29 CET] <jdarnley> thanks [17:01:16 CET] <Gramner> with another hundred flags because why not [17:01:35 CET] <BBB> I feel like I cant keep up with technology anymore [17:01:41 CET] <BBB> am I an old useless fart now? [17:02:27 CET] <BBB> maybe I should turn myself in a suit and use expensive empty words [17:02:37 CET] <Gramner> I guess the old naming scheme of increasing a number and grouping together all new instructions of a new µarch was too simple [17:03:15 CET] <Gramner> need more things to add as bullet points on powerpoint presentationd [17:03:26 CET] <BBB> hm& powerpoint [17:03:58 CET] <jdarnley> they'll make a budget processor that only supports a very limited set, like a pentium not supporting avx [17:04:40 CET] <kierank> jdarnley: those budget pentiums are not bad [17:04:46 CET] <Gramner> except intels own guidelines even recommends grouping together flags as baselines [17:04:53 CET] <Gramner> which is funny [17:05:01 CET] <kierank> jdarnley: we started shipping those [17:05:41 CET] <Gramner> no idea how we even should name all the avx512 stuff, because grouping together stuff is required to maintain sanity [17:08:07 CET] <jdarnley> yeah the pentiums are very nice [17:09:08 CET] <jdarnley> Gramner: we will cross that bride when we need to [17:10:43 CET] <Gramner> "whereas vpsraq is 1, 4, or 8 cycles, depending on the precise form used". it's 4 cycles when using a scalar shift value in xmm, otherwise it's 1 cycle. unless you count the latency from memory when using memory operands [17:11:54 CET] <Gramner> and there's vpsravq if you want variable shifts (instead of using scalar in xmm) which is often more useful and also 1 cycle [17:12:27 CET] <jdarnley> i thought i read 8 cycles if it had a memory operand [17:13:27 CET] <jamrial> holy shit, they keep adding extensions [17:13:43 CET] <jamrial> back in my day we had f, bw, dq, vl, and we liked it [17:13:44 CET] <Gramner> counting latency of memory operands is kind of iffy because it depends on where in the memory hierarchy your'e reading from and if any caches or memory buses are overloaded with other loads/stores [17:14:32 CET] <Gramner> maybe it's swapped to slow disk, with a billion cycle latency [17:14:34 CET] <jdarnley> true but i would guess that 8 is a best case [17:14:49 CET] <atomnuker> funman: I haven't tested it [18:24:33 CET] <wm4> Gramner: so no CPU supports all of AVX? [18:24:44 CET] <Gramner> correct [18:25:04 CET] <wm4> I'm sure that's great for development... [18:25:15 CET] <nevcairiel> the phi and consumer sets are quite distinct in usage [18:42:35 CET] <Chloe> jdarnley: did you setup ffmpeg on WSL? [18:53:28 CET] <jamrial> wm4: a bunch of those extensions are useless for multimedia anyway [18:55:19 CET] <jdarnley> Chloe: no i dont use win 10 [19:39:37 CET] <kierank> not found eval: wmv3_vdpau_hwaccel [19:39:39 CET] <kierank> what does that mean [19:43:36 CET] <jamrial> where did you get that? [19:43:57 CET] <kierank> trying to compile ffmpeg edited on windows using a linux guest vm [19:44:05 CET] <kierank> in configure [20:09:05 CET] <wm4> there doesn't seem to be anything unusual about that symbol [20:09:32 CET] <wm4> hm except that it's somehow messed into the vc1 code [20:13:24 CET] <jamrial> wmv3_vdpau_hwaccel implies (aka, enables) vc1_vdpau_hwaccel in configure [20:14:45 CET] <wm4> as it should be [21:39:07 CET] <wm4> nevcairiel, jamrial: is this ok for the windows thread configure changes? https://0x0.st/s8b8.bin [21:39:21 CET] <wm4> I'm not liking that redundancy much [21:41:45 CET] <jamrial> i don't think that check at the end of probe_libc is needed [21:42:44 CET] <jamrial> you're already forcing _WIN32_WINNT to be at least 0x600 on mingw32, mingw-w64 and msvc [21:43:17 CET] <jamrial> i don't think it's possible for that check to succeed and call die() [21:44:54 CET] <wm4> I can drop it [21:45:34 CET] <jamrial> that'd be best [21:45:47 CET] <wm4> https://0x0.st/s8bc.diff [21:45:55 CET] <wm4> (paste should have a correct mime type now) [21:46:41 CET] <wm4> time to actually test this [21:46:50 CET] <wm4> which will take ~30 minutes (blergh) [21:59:39 CET] <kierank> wm4: how do I make s->avctx->hwaccel->decode_mb(s); not take MpegEncContext? [22:03:01 CET] <wm4> I think xvmc is the only thing that uses this [22:03:29 CET] <wm4> mpegvideo_xvmc.c [22:04:36 CET] <wm4> so either argue for removing that (will probably fail on iive), or refucktor it [22:06:40 CET] <wm4> iive: is that still needed? [22:46:26 CET] <jamrial> kierank: make decode_mb() pass an avcodeccontext instead? [22:47:00 CET] <kierank> ok, it's one of the many changes i need to make [22:47:11 CET] <wm4> it'd still need to access lots of internal mpegvideo state [22:47:15 CET] <wm4> and it's hard to test [22:47:25 CET] <wm4> I mean how do you even run xvmc, even if you have a linux machine [22:55:40 CET] <Chloe> Is there any real benefit to xvmc over stuff like VA-API and VDPAU? [22:57:09 CET] <wm4> if you have really really old hardware [22:57:10 CET] <wm4> (???) [22:58:54 CET] <Chloe> I mean, we're dropping XP support, xvmc shouldnt be too dissimilar [23:05:13 CET] <wm4> I wouldn't have a problem with dropping it [23:08:50 CET] <Chloe> I doubt there would be much opposition, I reckon just submit a patch [23:10:20 CET] <wm4> iive is the maintainer of it, so I suppose it depends on his consent [23:10:57 CET] <iive> is there any reason to drop xvmc? AFIR there was some reason to drop XP support. [23:11:16 CET] <iive> It is working and I do maintain it. [23:11:20 CET] <wm4> kierank wants to unmess mpegvideo [23:11:38 CET] <wm4> because currently it's one monolithic big thing that can't be extended [23:11:44 CET] <iive> well, then unmess it. [23:12:01 CET] <wm4> nobody can test xvmc exceot you [23:12:04 CET] <wm4> *except [23:12:11 CET] <wm4> you're probably the only user too [23:14:27 CET] <iive> it doesn't requre anything special. standard mplayer, radeon with mesa3d or nvidia with binary drivers (last time they still provided it). [23:15:15 CET] <iive> i had some bugreports from intel drivers, no idea if they still provide it, i guess mesa3d too. [23:15:54 CET] <wm4> and just what is this still useful for [23:16:05 CET] <wm4> nvidia binary drivers provide no less than 2 better APIs [23:16:12 CET] <wm4> so do mesa and intel [23:17:00 CET] <iive> as I said, if kierank wants to unmess mpegvideo, then he could feel free to break xvmc [23:17:27 CET] <iive> I'll try to fix if possible, and if not possible then feel free to scrap it. [23:17:51 CET] <wm4> kierank: ^ [23:18:02 CET] <wm4> that sounds reasonable [23:26:57 CET] <kierank> there's going to have to be a lot of templating it seems [23:30:30 CET] <iive> this doesn't sound good. i just hope you are not going to baloon the generated code. [23:34:05 CET] <kierank> definitely will [23:34:14 CET] <kierank> it's the only way to get 10-bit mpeg-4 in [23:36:05 CET] <iive> i doubt that. [23:36:15 CET] <kierank> it is [23:36:29 CET] <kierank> let me know how you're going to get 10-bit video into mpegvideo.c [23:36:41 CET] <kierank> without ugly hacks [23:38:23 CET] <iive> are there any other differences than the size of the block elements? [23:39:44 CET] <iive> pixel buffers and MC stuff. [23:40:11 CET] <kierank> coefficients [23:40:22 CET] <kierank> a pcm mode [23:41:44 CET] <iive> well, coefficients are stored in block elements. [23:43:11 CET] <kierank> the coefficients are larger than the native data type [23:43:18 CET] <kierank> coefficients are 17-bit [23:43:33 CET] <iive> sure [23:44:00 CET] <iive> i guess you use int[64] instead of short[64] for blocks [23:45:50 CET] <kierank> easy to say [23:46:08 CET] <Compn> reddit is a terrible place to have a discussion [23:46:21 CET] <Compn> since people think downvotes are a disagreement button heh [23:46:37 CET] <iive> Compn: it is, no matter what the instructions say :D [23:47:02 CET] <Compn> :P [23:49:27 CET] <kierank> wm4: might give up for the second time, mpegencctx affects so much code [23:50:14 CET] <wm4> write a new decoder (possibly using old parts), make it pass fate, remove the old decoder from mpegcrap [23:50:19 CET] <iive> kierank: you should try to use mpegencctx instead. e.g. decode_mb() is function pointer [23:50:21 CET] <wm4> not sure if that's doable [23:50:32 CET] <kierank> not possibble [23:50:42 CET] <iive> it means that it can have decode_mpeg4_8bit and decode_mb_mpeg4_16bit functions [23:50:48 CET] <wm4> too many weird corner cases in fate? [23:50:54 CET] <kierank> too many weird codecs [23:51:00 CET] <iive> MC is already in function pointers [23:51:08 CET] <wm4> hey they managed with h264 too [23:51:53 CET] <kierank> wm4: yeah but there's no h264 encoders [23:51:57 CET] <kierank> of dozens of variants [23:52:02 CET] <kierank> that's why it's doable [23:52:16 CET] <kierank> iive: int (*decode_mb)(struct MpegEncContext *s, int16_t block[6][64]) [23:53:35 CET] <wm4> encoders? also why the shit is MpegEncContext used by decoders [23:53:44 CET] <iive> kierank: you can replace the second one with a single pointer. e.g. xvmc uses pblocks that is just pointers to the block structure. [23:54:13 CET] <kierank> wm4: tens of thousands of lines of code reuse [23:56:11 CET] <iive> there was a time when int16_t was DCTelem or something like that. [23:57:09 CET] <iive> kierank: if we make int32_t block[][] for all codecs, how much more code will you need to implement 10bit mpeg4 decoding? [23:57:22 CET] <kierank> pcm blocks [23:57:31 CET] <kierank> how do you decode in-place without a dct [23:58:00 CET] <iive> dct that does nothing? [23:58:31 CET] <iive> i already do that for xvmc, since I need the raw coefficients. [23:58:39 CET] <kierank> not possible without memcpy [23:58:54 CET] <iive> pblocks [23:59:21 CET] <kierank> completely undocumented [00:00:00 CET] --- Sat Dec 23 2017

1 0

ffmpeg.log.20171222
by burek 23 Dec '17

23 Dec '17

[00:30:45 CET] <alexpigment> spacerabbit: kodi [00:30:59 CET] <alexpigment> oh nm, you mean transcoded on the fly [00:31:36 CET] <alexpigment> why do you want to transcode? [00:31:47 CET] <spacerabbit> to watch on cellphone [00:31:52 CET] <alexpigment> ah [00:32:42 CET] <alexpigment> maybe google plex alternatives 2017 [00:32:56 CET] <alexpigment> i don't transcode, so I don't have any experience [00:33:23 CET] <spacerabbit> ideally something that works like a file browser rather than a media library but idk if that exists [00:33:40 CET] <alexpigment> do you have iOS or android? [00:33:45 CET] <spacerabbit> android [00:33:54 CET] <alexpigment> well, that's already a start [00:33:58 CET] <spacerabbit> i have that setup for my tv already [00:34:23 CET] <spacerabbit> with satellite tuners on a pci card and gpu transcoded with the nvidia card [00:34:25 CET] <alexpigment> so really the only problem you'd probably commonly face is audio codec support or perhaps something like mpeg-2 or xvid [00:34:37 CET] <alexpigment> gotcha [00:34:44 CET] <alexpigment> so you're dealing with mpeg-2 + ac3 [00:34:49 CET] <spacerabbit> i transcode the picture only [00:34:55 CET] <spacerabbit> its mostly AVC [00:35:03 CET] <spacerabbit> i copy the audio [00:35:04 CET] <alexpigment> then what's the need to transcode? [00:35:15 CET] <alexpigment> deinterlacing and making the bitrate smaller? [00:35:41 CET] <spacerabbit> id like to have a setup where i can open video files and they are transcoded on the flu [00:35:44 CET] <spacerabbit> fly [00:35:49 CET] <spacerabbit> my setup only works with live tv atm [00:36:02 CET] <alexpigment> right, i'm just making sure I understand since avc should be natively supported by your phone [00:36:12 CET] <spacerabbit> i transcode to hevc [00:36:19 CET] <spacerabbit> but i guess it doesnt matter much [00:36:22 CET] <alexpigment> for bitrate reasons? [00:36:26 CET] <spacerabbit> yeah [00:36:34 CET] <alexpigment> hmmm [00:36:37 CET] <spacerabbit> and its all hardware encode and decode [00:36:39 CET] <spacerabbit> so low power [00:36:54 CET] <alexpigment> have you tried *not* transcoding and leaving it avc to see if it works? [00:36:59 CET] <spacerabbit> sure [00:37:01 CET] <spacerabbit> it doesnt [00:37:07 CET] <alexpigment> k [00:37:08 CET] <spacerabbit> 5mbps upload max here [00:37:16 CET] <alexpigment> ah, over internet [00:37:22 CET] <spacerabbit> + worst case of LTE reception is like 2mbps [00:37:26 CET] <spacerabbit> in some bad spots [00:37:31 CET] <alexpigment> when you mentioned nas, I thought you were talking about in-network [00:37:37 CET] <spacerabbit> even if it goes up to 100mbps in a good spot [00:37:57 CET] <spacerabbit> ah in network i watch from 5ghz everything is smooth [00:38:22 CET] <alexpigment> have you tried Media Browser? [00:38:28 CET] <alexpigment> that appears to be a common plex alternative [00:38:32 CET] <spacerabbit> never heard about it [00:38:35 CET] <spacerabbit> lookingit up [00:39:04 CET] <alexpigment> and Kodi has a plugin for it, if you're unable to get a native client working on your phone [00:39:29 CET] <spacerabbit> https://github.com/MediaBrowser/Wiki/wiki/Transcoding "NVidia NVENC" [00:39:30 CET] <spacerabbit> sounds good [00:39:42 CET] <spacerabbit> i hope there's ways to fine tune the settings [00:40:20 CET] <alexpigment> well, i can tell you that nvenc and fine tuning are kinda mutually exclusive, but maybe it's enough for you [00:40:45 CET] <spacerabbit> well without the good settings it def look worse [00:41:08 CET] <spacerabbit> and tbh the hevc looks quite good [00:41:36 CET] <alexpigment> hevc via nvenc is generally on par with x264 from what I gather [00:41:42 CET] <spacerabbit> all things considered [00:41:44 CET] <spacerabbit> yeah [00:41:50 CET] <alexpigment> but it's better than h264 on nvenc [00:42:04 CET] <spacerabbit> a lot [00:42:32 CET] <spacerabbit> especially considering it doesnt use ressources [00:43:12 CET] <alexpigment> yeah, that's a big plus [00:43:24 CET] <spacerabbit> on my tv setup i can switch to x265 its not a problem [00:43:27 CET] <alexpigment> it would take a beefy system to encode x265 on the fly [00:43:34 CET] <spacerabbit> theres a menu on the android app [00:43:44 CET] <BtbN> A Ryzen 1800X can barely do 1080p60 [00:44:20 CET] <spacerabbit> well my 6600k maxed out can encode better 1080p than nvenc with x265 [00:44:25 CET] <spacerabbit> its a bit overkill though [00:44:35 CET] <therage3> BtbN: seriously? [00:44:40 CET] <therage3> i'd have expected more from those [00:44:49 CET] <alexpigment> x265 is very complex [00:44:52 CET] <BtbN> hm? That's super decent for a desktop CPU [00:44:59 CET] <therage3> wait [00:45:07 CET] <therage3> when you say "do 1080p60" what do you mean [00:45:13 CET] <therage3> play it back or what [00:45:18 CET] <alexpigment> encode on the fly [00:45:19 CET] <BtbN> it does slightly over 60 fps with x265 [00:45:24 CET] <therage3> oh, ENCODE on the fly [00:45:43 CET] <alexpigment> :) [00:46:07 CET] <alexpigment> live transcoding in x265 is going to be done on the GPU for most people for the foreseeable future [00:46:10 CET] <alexpigment> er [00:46:13 CET] <alexpigment> H.265 rather [00:46:54 CET] <BtbN> encoding h265 on a gpu is pointless [00:46:58 CET] <spacerabbit> it make sense for me because i share that tv app on android with another family member [00:47:04 CET] <BtbN> x264 is likely faster and results in better quality [00:47:06 CET] <spacerabbit> so it doesnt tax my cpu when he use it [00:47:15 CET] <alexpigment> BtbN: i agree for the most part, but he's wanting very low CPU usage [00:47:30 CET] <spacerabbit> plus its real time [00:47:31 CET] <BtbN> I'd still use a h264 hw encoder then [00:47:37 CET] <spacerabbit> blah [00:47:55 CET] <alexpigment> BtbN: read up above. he's trying to get really low bitrates for streaming over LTE [00:47:57 CET] <BtbN> last time I tested nvenc, there was virtually no difference between the two [00:48:17 CET] <BtbN> it did not yield smaller files or better quality [00:48:19 CET] <alexpigment> so if low CPU and low bitrate are the key points, nvenc hevc is really the only option [00:48:24 CET] <BtbN> it basically operates hevc at h264 feature levels [00:48:36 CET] <BtbN> So there is no point in actually using it [00:48:52 CET] <spacerabbit> well i have HW decoders for both my the receiver [00:49:08 CET] <spacerabbit> so it doesnt make sense to tax a lot of cpu for the same results [00:49:13 CET] <BtbN> Decoders are bit perfect anyway, there's no quality to be gained [00:49:47 CET] <spacerabbit> anyway the choice of the codec doesnt matter much [00:50:06 CET] <alexpigment> spacerabbit: anyway, hopefully mediabrowser / emby is what you're looking for [00:50:07 CET] <spacerabbit> i need a system to encode files from a nas on the fly [00:50:24 CET] <spacerabbit> yep sounds good from what im looking at [00:50:26 CET] <BtbN> well, if you use h264, you get better compatibility. And with hw encoders, there isn't really anything to gain from using hevc. [00:50:52 CET] <spacerabbit> well i stream to 2 mobiles that both have hevc [00:51:05 CET] <spacerabbit> and there is an option to use h264 for other phones [00:51:52 CET] <spacerabbit> so because it has the option to use hevc doesnt make it less compatible [00:52:15 CET] <spacerabbit> i guess it should work the same with that other software [00:53:46 CET] <alexpigment> BtbN: i actually can't tell anything meaningful on my macbook right now, but here's a link: http://forum.mediacoderhq.com/viewtopic.php?f=4&t=13184&start=10#top [00:53:54 CET] <alexpigment> there are screenshots, for whatever it's worth [00:54:37 CET] <therage3> i'm resisting the urge to do audiophile things [00:54:53 CET] <alexpigment> clearly, x264 at slow speeds is better than hardware in general, but there's certainly a benefit in using hevc over h264 on nvenc [00:55:17 CET] <alexpigment> therage3: like? [00:55:52 CET] <therage3> someone told me about some obscure SoX dithering method to use when downscaling 24-bit audio files to Red Book compliant audio CD 16-bit files [00:55:59 CET] <alexpigment> oh yeah [00:56:01 CET] <therage3> sounds like a bit of a waste [00:56:11 CET] <alexpigment> well, dithering has its merits [00:56:26 CET] <alexpigment> but it's hard to tell if you'd notice [00:56:58 CET] <therage3> my understanding is that it's used to randomize the quantization error noise you get from the downscaling process, which turns the noise into a more tolerable white noise thing [00:57:16 CET] <therage3> but different kinds of dithering, different algorithms, produce different end results [00:57:36 CET] <alexpigment> therage3: my 2 cents: do it from now on; don't waste your time redoing something you've already done [00:58:13 CET] <alexpigment> or at least do a test on one or two tracka and see if you can notice a difference. if you can't, don't redo anything [00:59:17 CET] <therage3> yeah, good call [00:59:47 CET] <therage3> the specific context is that this FLAC came in 44.1kHz 24-bit format [00:59:51 CET] <therage3> and i was like, uhhhhhh [01:00:13 CET] <alexpigment> yeah, 24bit is really just used for having a lower noise floor and higher db ceiling [01:00:23 CET] <alexpigment> it's useful for recording and editing [01:00:33 CET] <alexpigment> but most people end up going to 16-bit at the end [01:00:50 CET] <alexpigment> kinda like working in 10-bit with video even though you go down to 8-bit at the end [01:02:36 CET] <therage3> yeah [01:04:30 CET] <therage3> i was messing around a bit with it [01:04:51 CET] <therage3> downscaled the bit depth, burned a CD with CD-Text and all [01:04:56 CET] <therage3> seems to sound great [01:09:15 CET] <therage3> is this sort of frequency spectrum normal for a file of these specs? https://i.imgur.com/lDsD8UG.jpg [01:09:41 CET] <therage3> i mean, i know they go up to 22.05kHz because of the Nyquist theorem and the sampling rate they use [01:09:51 CET] <therage3> but is it normal for it to be cut off sharply just there? [01:10:01 CET] <therage3> often i see them just trail off softly close to the peak [01:36:02 CET] <alexpigment> therage3: not really sure [01:36:15 CET] <alexpigment> i know that during mastering they hard cut a lot of the low frequencies [01:36:29 CET] <therage3> but the ones cut here are the _high_ ones.. [01:36:33 CET] <alexpigment> it seems likely they'd do the same for the highs, but i'm not an expert on the matter [01:36:38 CET] <therage3> right [01:36:49 CET] <therage3> (as in, right they may do that, not that you're not an expert lol) [01:37:07 CET] <alexpigment> no worries - i knew what you meant :) [01:37:29 CET] <alexpigment> i've done a lot of music recording in the past, but i was never a spectrum view person [01:37:30 CET] <therage3> let's see if this audiophile channel knows [01:37:35 CET] <alexpigment> ;) [01:37:46 CET] <therage3> well lately i've been looking at some spectrum analysis tools with more care [01:38:09 CET] <therage3> since there's a bunch of "320kbps" mp3's out there that have all frequencies above 15kHz hard cut off [01:38:16 CET] <therage3> i'm like, "yeah, 320kbps my ass..." [02:03:12 CET] <alexpigment> therage3: i think it depends on the encoder tbh, but yeah, mp3 is lossy at any bitrate [02:03:31 CET] <alexpigment> and the big savings of an mp3 is simply cutting off frequencies "they" think you can't hear [02:03:46 CET] <therage3> the encoder? [02:04:03 CET] <therage3> but this is a FLAC file, it should be, theoretically, bit-for-bit identical to the source [02:04:16 CET] <alexpigment> you were talking about 320kbps mp3 files [02:04:47 CET] <alexpigment> i was just saying that I think the cutoff frequency for mp3s varies by encoder [02:04:58 CET] <alexpigment> (to some degree, anyway) [02:05:23 CET] <therage3> ohhh, you mean what I said _most recently_ [02:05:38 CET] <alexpigment> yeah, that's how i operate [02:05:42 CET] <alexpigment> linearly in time ;) [02:06:12 CET] <therage3> BRB a sec, then i'll answer [02:12:44 CET] <therage3> alexpigment: ok back [02:13:04 CET] <alexpigment> cool [02:13:16 CET] <therage3> so yeah, it may depend on encoder and whatever, but a hard limit of 15kHz for a presumably 320kbps mp3 is... sketchy [02:13:24 CET] <alexpigment> yeah i hear you [02:13:30 CET] <therage3> now as for the other question [02:13:36 CET] <therage3> the one with the FLAC [02:14:10 CET] <therage3> in the audiophile channel they told me that the song was mastered in some manner such that frequencies higher than 22.05kHz existed on that master [02:14:21 CET] <therage3> but the 44.1kHz downsampling clobbered them [02:14:37 CET] <therage3> that's the origin of that wall at 22.05kHz [02:14:58 CET] <alexpigment> ah, that rings a bell [02:15:11 CET] <alexpigment> so 48k or 96k would have a broader range? [02:15:54 CET] <therage3> that's the idea, i guess, 48kHz would go up to 24kHz in actual "audio" range (I write "audio" in quotes because anything above 20kHz is dubiously called audio...) [02:17:20 CET] <alexpigment> yeah, i just found out recently that AAC audio has a feature that replaces certain high frequencies with white noise to increase encoding efficiency [02:17:32 CET] <alexpigment> which seems wtf on paper but I guess in practice doesn't make too much difference [02:17:33 CET] <therage3> oh fancy [02:17:50 CET] <therage3> and i guess that white noise masquerades well as whatever it's replacing for the human ear¿ [02:17:52 CET] <therage3> ?* [02:18:03 CET] <alexpigment> i would hope so [02:18:17 CET] <alexpigment> i've never done a back to back comparison [02:18:37 CET] <therage3> i can kind of see why it does that, 8-bit video game consoles had high-hat and crash cymbals that sounded like white noise [02:18:41 CET] <therage3> so it makes sense in some manner [02:29:12 CET] <alexpigment> well to be fair a) they sounded like shit, and b) they weren't replacing the cymbals in real recorded audio with fake crash cymbal sounds ;) [02:29:55 CET] <alexpigment> in my head, it's equivalent to saying "ok, anything over 15khz, just turn into midi" [02:30:10 CET] <alexpigment> replace with softsynth ;) [02:30:42 CET] <alexpigment> but yeah, i can understand how they could be approximated as the same [02:33:09 CET] <therage3> yeah [02:35:27 CET] <alexpigment> anyway, i'm not enough of an audiophile to care about all this i guess [02:36:04 CET] <alexpigment> like i think you'd notice a bigger difference in $600 speakers vs $100 speakers than you would in flac vs mp3 [02:36:14 CET] <alexpigment> even if you could tell the difference side-by-side [02:36:46 CET] <alexpigment> the only time i really ever notice quality sucking is when i'm watching a music video on youtube or listening to satellite radio [02:37:53 CET] <alexpigment> but given that you're ripping stuff from CD or whatever, sure, go FLC [02:37:55 CET] <alexpigment> *FLAC [02:38:03 CET] <alexpigment> because why the hell not :) [02:38:51 CET] <klaxa> for archival FLAC, for listening opus is good enough nowadays [02:38:57 CET] <alexpigment> there's a certain peace of mind to knowing something is lossless rather than worrying about if something is more or less lossless [02:39:27 CET] <klaxa> one of the reasons for storing archives in lossless formats is because you can re-encode to new state-of-the-art lossy codecs without quality loss [02:40:05 CET] <therage3> the thing with YouTube is the following [02:40:35 CET] <therage3> a lot of times, the best video they have is paired with an audio stream that isn't the best they have on file for that video [02:40:46 CET] <therage3> the best audio stream they have is often an audio-only container elsewhere [02:41:04 CET] <therage3> i've tested this myself with a few videos and youtube-dl [02:41:07 CET] <alexpigment> klaxa: i understand where you're coming from, but if you can play the lossless file and it seems like it's not a fleeting format, the lossy version is unnecessary [02:41:30 CET] <alexpigment> therage3: yeah, youtube does some really stupid stuff with audio [02:41:42 CET] <alexpigment> it used to be that 1080p rips had 160kbps AAC tracks [02:41:49 CET] <alexpigment> and then they changed them to 128kbps later [02:41:54 CET] <alexpigment> and I have proof of that [02:41:58 CET] <klaxa> on a hi-fi audio setup, sure go for whatever quality you like :) [02:42:19 CET] <klaxa> on my phone with low-level consumer-grade hardware i use opus and can't tell the difference :P [02:42:51 CET] <alexpigment> klaxa: yeah, i'd agree with that. i just use spotify for mobile at this point [02:43:09 CET] <alexpigment> the "high quality" seems good enough for me, whatever it is [02:43:18 CET] <alexpigment> probably 256kbps aac or something [02:44:27 CET] <alexpigment> that does bring up a question i've been wondering [02:44:37 CET] <alexpigment> what's the transparency of bluetooth at this point? [02:45:04 CET] <alexpigment> doesn't it have to be compressed in a specific way for bluetooth? [02:46:03 CET] <c3-Win> Depends on the version of Bluetooth and what's going over the wire. [02:46:40 CET] <alexpigment> right, but isn't it only lossy codecs at this point? [02:46:51 CET] <alexpigment> and if so, is there a bitrate limit? [02:48:54 CET] <alexpigment> looks like aac at 250kbps, sbc at 328kbps, and aptx at some other bitrate [02:49:10 CET] <alexpigment> and i guess sbc is inferior to mp3 [02:49:17 CET] <kepstin> you can put mp3 and aac over bluetooth nowadays, iirc some devices (apple?) have players that just sttream the original aac directly to bt devices [02:49:52 CET] <kepstin> my sony stuff does ldac, which seems to sound great, but uses so much bandwidth that it cuts out all the time if there's any other nearby bt devices [02:50:11 CET] <alexpigment> yeah, that's always a concern [02:50:25 CET] <alexpigment> i still don't use bluetooth for anything [02:51:10 CET] <kepstin> lets see, ldac has 3 modes - 333kbit, 660kbit, and 990kbit [02:51:25 CET] <alexpigment> those are nice rates on paper [02:51:36 CET] <kepstin> supposedly the 330kbit mode sounds better than sbc at 328kbit [02:51:37 CET] <alexpigment> are the higher ones for multichannel? [02:51:49 CET] <kepstin> no, high bit depth mostely [02:51:55 CET] <alexpigment> ah [02:52:06 CET] <kepstin> so you can send 96khz from your gold plated walkman [02:52:14 CET] <alexpigment> :) [02:52:27 CET] <alexpigment> but yes, i can see how those bitrates could cause reliability problems [02:52:41 CET] <kepstin> https://www.sony.com/electronics/walkman/nw-wm1z - it is actually literally gold plated, btw [02:53:13 CET] <alexpigment> that price tag... [02:53:34 CET] <alexpigment> some real cork sniffing stuff going on here [02:53:49 CET] <kepstin> i really wish opus over bt would become a thing [02:54:02 CET] <kepstin> low latency + sounds great + error concealment... [02:54:07 CET] <kepstin> it's the perfect codec for bt [02:54:51 CET] <alexpigment> if sony or apple had a stake in opus, it would probably have happened by now [02:55:11 CET] <alexpigment> this is how the codec world has worked for the last however many years [02:55:23 CET] <kepstin> i mean, people always complain about bt audio latency causing desyncs when watching movies and stuff, opus fixes that [02:55:58 CET] <alexpigment> i'll take your word for it [02:56:06 CET] <alexpigment> i use good ol' wires [02:56:15 CET] <alexpigment> audio in sync over here ;) [02:56:26 CET] <alexpigment> but sure, i'm up for more codec support [02:57:13 CET] <kepstin> i'm just annoyed because the headphone jack in my phone broke and i forgot to test it after repairing it before I put the back on again, so it's still broken [02:57:16 CET] <alexpigment> VIA and fraunhoffer are probably paying lots of money to the bluetooth people [02:57:30 CET] <alexpigment> that sucks [02:57:54 CET] <alexpigment> i have an iphone SE and i'm sticking to it until apple releases a new SE model or whatever else has a headphone jack [02:58:12 CET] <alexpigment> fortunately it's still a fast phone [02:58:40 CET] <kepstin> annoying glass back phone with unreusable glue, if I take the back off again I basically have to replace the glue :/ [02:58:58 CET] <alexpigment> kepstin: i've seen where you live. you can afford glue [02:59:11 CET] <alexpigment> (i had to lie a bit to make that joke. i don't really know where you live) [02:59:31 CET] Action: kepstin could, but it's just kind of annoying. [02:59:38 CET] <alexpigment> no i get it [02:59:55 CET] <alexpigment> i work on my guitars a lot and have done something similar [03:00:11 CET] <alexpigment> it's like "ok, this middle position is out of phase now. i don't want to take this apart again" [03:00:12 CET] <kepstin> i mean, it's literally acouple bucks to get the precut adhesive from someone in china in the mail in a couple weeks [03:00:58 CET] <alexpigment> well, if it hasn't become a big enough deal yet, i guess it's not a huge deal [03:01:15 CET] <alexpigment> for me, i have these sony headphones that I love and I don't want to invest in some stupid wireless headphones or a dongle [03:01:47 CET] Action: kepstin ended up getting some nice sony noise cancelling wireless headphones, and honestly hasn't really missed the headphone jack [03:01:58 CET] <alexpigment> and the sonys aren't anything special on paper, but they just sound perfect. they used to be $20 new and people are regularly trying to sell them for $200+ on ebay now for some stupid reason [03:02:59 CET] <alexpigment> i kinda like being able to hear outside of my headphones. that's a rare quality these days between all the earbuds and over-the-ears out there now [03:04:00 CET] <kepstin> curiously enough, that's actually something the sony noise cancelling stuff does well - you can switch them to an ambient passthrough mode that lets you hear stuff around you, but doesn't leak your sound [03:04:16 CET] <alexpigment> oh nice [03:04:25 CET] <alexpigment> that's a really cool use of the mic [03:04:41 CET] <alexpigment> i didn't know they did that [03:04:53 CET] <kepstin> even have a mode that'll silence fan noise and whatnot but let you hear voices. [03:05:15 CET] <alexpigment> ah, selective bands [03:05:21 CET] <alexpigment> pretty cool [04:04:01 CET] <foul_owl> Is there a filter that can extract the movement from some frames? I know it won't be perfect, but like a greenscreen effect? [04:04:17 CET] <foul_owl> Imagine you set up a tripod and someone walked through the shot. [04:04:35 CET] <foul_owl> I want to capture the "diffs" and save that as an animation, basically a poor man's greenscreen. [04:04:44 CET] <foul_owl> Again, I know it won't be perfect but I can edit by hand later [04:04:51 CET] <foul_owl> Mainly just want to extract the bulk of the diffs [04:04:55 CET] <foul_owl> Is this possible? [04:05:30 CET] <foul_owl> Maybe with gimp? [04:13:13 CET] <fella> convert screenshot_2.png screenshot_1.png $ -clone 0 -clone 1 -compose difference -composite -threshold 0 $ -delete 1 -alpha off -compose copy_opacity -composite -trim moving_parts.png [04:15:24 CET] <klaxa> neat [04:51:30 CET] <foul_owl> Damn, that is so awesome :D Thank you! [04:51:47 CET] <foul_owl> Probably a long shot, but do you know how to extend that to more than two images? [04:52:32 CET] <foul_owl> Maybe take output from that and use that as input 1, and then frame 3 as input 2, etc? [09:35:46 CET] <durandal_1707> foul_owl: dont use imagetragick [09:36:22 CET] <durandal_1707> fella: dont promote imagetragick here [10:38:32 CET] <durandal_17> ffmpeg -i video -vf "split[v1][v0],[v1]tblend=all_mode=difference,format=yuv444p,extractplanes=y+u+v[r][g][b],[r][g]blend=all_mode=or[rg],[rg][b]blend=all_mode=or,lut=255*gt(val\,0):255*gt(val\,0):255*gt(val\,0)[alpha],[v0][alpha]alphamerge" [10:38:58 CET] <durandal_17> this does similar to imagetragick [10:51:52 CET] <alexpigment> durandal_17: are you saying imagetragick in place of imagemagick? [10:52:07 CET] <alexpigment> is there some beef with that software? [10:54:38 CET] <durandal_17> alexpigment: its full of tragic CVEs [10:56:33 CET] <furq> alexpigment: https://imagetragick.com/ [10:57:01 CET] <furq> convert itself is probably fine, notwithstanding that you can do a lot of that stuff with ffmpeg [10:57:20 CET] <furq> but i definitely wouldn't use it in anything network-facing [10:58:19 CET] <furq> i wouldn't have used it anyway because it's a horrible resource hog iirc [11:02:51 CET] <alexpigment> ah [11:05:37 CET] <furq> libvips is a good alternative if you need a library that has usable bindings for scripting languages [12:19:04 CET] <tommy``> guys there is a way to use online computer to encode video? [12:19:24 CET] <tommy``> my pc i slow for encoding so i'd like to use some server that grant it [12:42:34 CET] <BtbN> tommy``, rent a server, encode on it. [12:42:54 CET] <tommy``> you dont say [12:43:17 CET] <BtbN> Any server you can ssh to(so, all of them) will work [12:43:21 CET] <BtbN> The more CPUs, the faster [12:43:48 CET] <BtbN> iirc AWS even has an abstracted transcode service, so you don't need to invoke ffmpeg yourself, or manage the hardware. But it's stupidly expensive. [12:44:17 CET] <BtbN> Grabbing a 8 or 16 core box on GCE would be way cheaper and perform equally or better [13:04:35 CET] <iive> tommy``: i guess your video card doesn't have encoding support either? [13:05:14 CET] <tommy``> ( iive ): my all pc is bad: dual core e6600, ddr2 6gb and gtx 550ti [13:43:00 CET] <DHE> 680 (iirc) is the minimum for nvenc [14:00:32 CET] <furq> yeah, it's any kepler GTX 600 and up [16:03:16 CET] <johang> I have encountered a few times that running ffplay somehow wrecks the window manager in my Fedora system so I have to restart a lot of stuff. Before I dig too much: does that sound familiar to you? [16:03:39 CET] <johang> I usually just reboot [16:09:46 CET] <khali> never seen that johang, but I don't use ffplay a lot... only when VLC fails [16:13:02 CET] <johang> That's pretty much what I do too. Well, gotta go. [16:30:20 CET] <Psilovybin> i've tried a few things... something i'm overlooking? https://pastebin.com/gqFHk95A [17:43:42 CET] <logicWEB> good day :-) I'm wondering if there is documentation anywhere about the big shift that happened in the libavfilter infrastructure over the last 8 years [17:43:56 CET] <logicWEB> mplayer has this filter lavfi in the source code that's been disabled for ages because it's broken. it was written back when libavfilter used the end_frame callback and held frame data in struct AVFilterBufferRef. [17:44:00 CET] <logicWEB> I've been poking at commits and trying to figure it out, and it looks like the core of the filtering infrastructure is now the filter_frame callback, and frame data is now kept in the standard struct AVFrame, but I'm really uncertain about the correctness of my code because I haven't found anything that clearly explains what a filter is expected to [17:44:00 CET] <logicWEB> do and how the filtering infrastructure calls into it [17:45:10 CET] <logicWEB> basically, I have mplayer SVN with FFmpeg master HEAD building with minimal changes on the FFmpeg side, but when I try to activate a filter via mencoder -vf lavfi, mencoder doesn't crash but simply exits immediately, feels like it's interpreting something as meaning "you've reached the end of the stream" [17:45:48 CET] <logicWEB> in order to debug this, I have to figure out BOTH mplayer's and FFmpeg's filter models so I can understand in what way they're not talking to each other right now :-) [17:47:59 CET] <kepstin> logicWEB: you'd probably be better off starting from mpv, which already has fixed the libavfilter integration. Maybe look at its git history? [17:52:31 CET] <pos> so, i've got this mp4 file which is giving me some headaches playback-wise [17:53:52 CET] <pos> vlc shows the first frame and crashes, firefox (.) believes it is two hours long (and believes it is corrupt if i try to skip ahead) [17:54:43 CET] <pos> mpv/mplayer believes it is 19 hours long and also stops responding of i try to jump ahead [17:55:11 CET] <pos> it's supposed to be about four hours long [17:55:56 CET] <pos> i was hoping to transcode it to a playable file with correct time metadata? [17:58:02 CET] <iive> try `ffmpeg -i input.mp4 -c copy output.mp4` and see what you'd got. [18:01:29 CET] <iive> also, if you suspect that the file might contain a lot of zero blocks, you could try `gzip -1 (fastest) -c input.mp4` video files are already compressed and cannot be made smaller. if it is smaller... the file is incomplete [18:02:37 CET] <iive> if the blocks are zeros, `cp --sparse=always input.mp4 test.mp4` might be faster way to detect zero blocks. you need `du test.mp4` to check for holes [18:03:27 CET] <pos> tried it, now both vlc and mpv will open it but it appears to be only two hours long [18:03:28 CET] <furq> if mpv is misdetecting the time then i don't hold out much hope for ffmpeg [18:03:36 CET] <pos> also, jumping progress works in neither [18:04:04 CET] <furq> copying to a new container should have fixed the index [18:04:08 CET] <pos> rather, doesn't work in either. both stop responding [18:04:11 CET] <furq> so yeah you've got other issues if seeking still doesn't work [18:05:58 CET] <pos> thing is, fastforwarding works [18:06:24 CET] <pos> firefox doesn't believe the output is corrupt but also hangs at skip [18:07:32 CET] <pos> cp --sparse=same file size [18:08:49 CET] <pos> it is basically a transport stream from a cctv cam [18:09:18 CET] <pos> the 19 hours mpv believes is the video length is eerily similar to the camera sys uptime [18:11:20 CET] <pos> the stream was supposed to be divided into 15 minute individual segments but something broke and the sys kept putting four hours into the same file [18:11:26 CET] <logicWEB> kepstin: oh! thanks very much :-) [18:13:16 CET] <pos> ffmpeg -i input.mp4 -c libx264 -an test.mp4 [18:13:37 CET] <pos> [buffer @ 0x115e5a0] Unable to parse option value "-1" as pixel format [18:13:51 CET] <pos> [buffer @ 0x115e5a0] Error setting option pix_fmt to value -1. [19:11:15 CET] <SviMik> Hi! How would you apply a filter (like 'curves') to a part of a video (like bottom half)? [19:13:17 CET] <SviMik> I have tried 'crop' and 'overlay' approach, but stumbled into some positioning error on overlay stage - it does some weird stuff if vertical offset is an odd number [19:22:59 CET] <durandal_1707> SviMik: you must use even numbers for subsampled formats [19:24:00 CET] <SviMik> durandal_1707 I've already tried to add "format=rgba" before the filters, still no luck [19:24:58 CET] <durandal_1707> overlay default fornat is yuv420p, so change that [19:26:40 CET] <furq> SviMik: crop and vstack is probably easier [19:27:17 CET] <furq> assuming you only need the bottom half and not a region [19:28:13 CET] <SviMik> durandal_1707 ah, there it is! thanks! I thought all filters use some auto detection [19:28:21 CET] <SviMik> furq I need a region... [19:31:23 CET] <SviMik> -filter_complex "[0:v]crop=x=700:y=43:w=460:h=77,curves=m='0/0 0.697/1.0'[crt];[0:v][crt]overlay=x=700:y=43:format=rgb,format=yuv420p" [19:31:27 CET] <SviMik> works [19:32:08 CET] <SviMik> (trailing format=yuv420p just to convert the final result back to yuv420p) [23:19:58 CET] <Tugamars> Hello, anyone here? [23:21:20 CET] <SviMik> Tugamars don't ask to ask a question. just go and ask it [23:25:25 CET] <Tugamars> Can someone check this post i made on reddit and help me with this question? https://www.reddit.com/r/ffmpeg/comments/7ldh3j/how_to_overlay_image_with_a… [23:26:10 CET] <Tugamars> My objective is to, basicly: create a movie and just "replace" the 'static' images with new ones, so i can create a script that automaticly does that [23:27:42 CET] <furq> why are you using -s 640x480 if you don't want the output to be 640x480 [23:27:59 CET] <Tugamars> i want the final video output to be 640x480 [23:28:14 CET] <furq> what does "the video scales down" mean then [23:29:18 CET] <SviMik> are you sure that your image is 640x480 too? [23:29:58 CET] <Tugamars> The red thing is the video, the blue thing is the image. I want to put the video on top of image (the video have alpha), and export it as a new video with 640x480. http://prntscr.com/hr78mv [23:30:31 CET] <Tugamars> The problem is that the red thing (video) is rendered at 640x480 but when i try to use ffmpeg to overlap both it scales down [23:31:57 CET] <Tugamars> Not sure if i explaned well [23:34:32 CET] <furq> is bg.jpg much bigger than 640x480 by any chance [23:34:46 CET] <Tugamars> yes, it is [23:34:51 CET] <furq> well yeah there's your problem [23:34:56 CET] <furq> it's scaling to 640x480 after overlaying [23:35:08 CET] <Tugamars> I need to scale it down/crop before using? [23:35:11 CET] <furq> yeah [23:35:23 CET] <Tugamars> Thanks :) Will try [23:35:24 CET] <furq> you can do that with ffmpeg but it's probably easier to just scale it beforehand [23:36:44 CET] <furq> http://vpaste.net/WoRB8 [23:36:49 CET] <furq> also your command should probably look more like that [23:37:05 CET] <pos> i have an application which is pulling an rtsp stream for video, thing is that the source is providing audio on a separate stream [23:37:17 CET] <Tugamars> Another question, if i may: How do you define the "time" that the bg image stays ? I mean, imagine i want one image from 00 to 01 and another from 01 to 02, how do i do that ? I've been searching but cant find much info [23:37:32 CET] <pos> the app can handle extra params for ffmpeg, can i specify a second source for audio? [23:37:34 CET] <furq> Tugamars: https://ffmpeg.org/ffmpeg-filters.html#Timeline-editing [23:38:12 CET] <furq> pos: -i rtsp://1.ts -i rtsp://2.ts [23:38:15 CET] <Tugamars> What does "lavfi" does ? [23:38:23 CET] <furq> it's an alias for -filter_complex [23:38:38 CET] <furq> -vf and -af can only handle one input at a time, -filter_complex can handle multiple [23:38:38 CET] <pos> ah, unsure as to whether it'll accept two -i s [23:38:47 CET] <Tugamars> oh ok. Thanks furq :) [23:39:00 CET] <furq> pos: "extra args" would imply they're after some output options, yeah [23:39:18 CET] <furq> i don't know if the movie filter accepts network inputs but if it does then that might work [00:00:00 CET] --- Sat Dec 23 2017

1 0

ffmpeg-devel.log.20171221
by burek 22 Dec '17

22 Dec '17

[04:15:57 CET] <cone-792> ffmpeg 03Steven Liu 07master:8318f60845bb: avformat/hlsenc: fix first fragment mp4 do not split bug [04:19:55 CET] <cone-792> ffmpeg 03Steven Liu 07master:7feae7be5b08: avformat/hlsenc: reindent after previous commits [04:40:56 CET] <cone-792> ffmpeg 03Karthick J 07master:3ac76d890d91: avformat/hlsenc: Fix a memory leak when http_persistent is 1 [04:50:50 CET] <cone-792> ffmpeg 03James Almer 07master:22ae33fb4083: configure: fix minimum required version of libzimg [04:53:56 CET] <wm4> so what are the plans for the next ffmpeg release (based on current git master or later) [04:57:51 CET] <jamrial> tagging it around late january or february, i guess [04:58:23 CET] <jamrial> ffserver will be gone, and ideally so will the lavu atomic wrappers [04:59:44 CET] <jamrial> and judging by the vote about winxp support, that will be gone too [05:01:29 CET] <jamrial> maybe also the first version to have initial support for avx512 if jdarnley pushes his patchset [05:03:46 CET] <wm4> I'll probably make a patch some time that introduces static mutex initializers to the windows pthread wrapper (which will come with a patch to remove the XP code) [05:04:17 CET] <jamrial> that'd be a pretty good addition [05:04:35 CET] <wm4> and then I want to deprecate the "lock manager" [05:25:11 CET] <cone-792> ffmpeg 03James Almer 07master:bc10260f49d5: avformat/mov: simplify parsing of mdcv atom using av_make_q() [11:21:56 CET] <atomnuker> wm4: oh yes please, that lockmgr code isn't good [11:25:39 CET] <stevenliu> Hi guys [11:25:43 CET] <stevenliu> The EXT-X-TARGETDURATION tag specifies the maximum Media Segment [11:25:44 CET] <stevenliu> duration. The EXTINF duration of each Media Segment in the Playlist [11:25:44 CET] <stevenliu> file, when rounded to the nearest integer, MUST be less than or equal [11:25:45 CET] <stevenliu> to the target duration; longer segments can trigger playback stalls [11:25:47 CET] <stevenliu> or other errors. It applies to the entire Playlist file. [11:25:52 CET] <stevenliu> how should i understand it? [11:26:27 CET] <stevenliu> EXT-X-TARGETDURATION >= EXTINF? or EXT-X-TARGETDURATION can < EXTINF? [11:29:50 CET] <stevenliu> i have sent a mail to http-live-streaming-review(a)group.apple.com for ask this question. i just curiosity the spec said EXT-X-TARGETDURATION must > EXTINF, but use mediastreamvalidate, it get error when EXT-X-TARGETDURATION > EXTINF, just when EXTINF is less than x.4444440, but if EXT-X-TARGETDURATION equ 4, it less than EXTINF. [12:32:19 CET] <cone-121> ffmpeg 03Paul B Mahol 07master:c99ed89f8961: avfilter/af_biquads: add kHz width_type [12:32:20 CET] <cone-121> ffmpeg 03Paul B Mahol 07master:7fc89f226fb6: avfilter/af_biquads: increase width range [12:32:21 CET] <cone-121> ffmpeg 03Paul B Mahol 07master:5a6e753bc62f: avfilter/af_biquads: change defaults for biquad filter [18:51:31 CET] <cone-395> ffmpeg 03wm4 07master:55eebf2a11d2: v4l_m2m: add missing AV_CODEC_CAP_DELAY flags [18:51:31 CET] <cone-395> ffmpeg 03wm4 07master:1083859cb8c9: rkmppdec: move AV_CODEC_CAP_AVOID_PROBING to the correct field [18:52:28 CET] <wm4> whoops, posted on the ML that I pushed these patches, but my stupid mail client only replied to the v4l2 guy [19:13:30 CET] <nevcairiel> that usually happens to me if people answer to me directly and only CC the ML, which is kinda bad practice to begin with [19:15:51 CET] <wm4> also I misspelled the prefix [19:15:56 CET] <wm4> it's v4l2m2m or something [19:16:06 CET] <wm4> (how did they manage to get two "2m" in there) [19:16:47 CET] <wm4> the subsystem is called v4l2 because it was the second version of v4l, but the original v4l is long dead [19:17:32 CET] <wm4> nevcairiel: btw. what's the best way to detect the presence of a Windows Vista+ target in configure? [19:19:07 CET] <iive> m2m is memory to memory [19:50:00 CET] <nevcairiel> wm4: check _WIN32_WINNT i guess [19:50:14 CET] <nevcairiel> >= 0x0600 would be vista+ [19:50:45 CET] <wm4> hmmm I guess [20:25:42 CET] <cone-395> ffmpeg 03Michael Niedermayer 07master:42274db1c623: avcodec/jpeg2000dec: Allocate lengthinc and data_start arrays as needed [20:25:43 CET] <cone-395> ffmpeg 03Michael Niedermayer 07master:4b2a186ef02c: avcodec/mpeg4videodec: Add support for parsing and exporting video_range [20:25:44 CET] <cone-395> ffmpeg 03Michael Niedermayer 07master:80344959f064: avcodec/jpeg2000dec: Free lengthinc earlier [20:50:38 CET] <wm4> just ran configure on windows - took 24 minutes [20:52:15 CET] <wm4> and I did it wrong, so I need to run it again [20:55:27 CET] <tmm1> SortaCore: did you ever figure out a fix for those random qsv -17 errors? [22:21:11 CET] <wm4> we're still in the ABI unstable phase right? [22:21:29 CET] <jamrial> yeah [22:21:52 CET] <nevcairiel> we should really get that sorted tho [22:22:41 CET] <jamrial> the lavu atomic wrappers are still there [22:22:56 CET] <jamrial> if atomnuker or someone else can't remove them, then we'll have to leave them there until the next bump [22:23:50 CET] <wm4> changing this lock manager stuff allows us to remove an avpriv [22:24:03 CET] <wm4> libavcodec defines this: avpriv_lock_avformat() [22:24:10 CET] <wm4> and the only reason is this lock manager nonsense [22:24:18 CET] <wm4> the WTFs are just piling up [22:32:22 CET] <wbs> did you get usable static mutexes now? if you do, you can replace that with a private static mutex in libavformat [22:32:49 CET] <wm4> wbs: we'll drop XP support [22:33:08 CET] <wm4> Windows Vista provides a new kind of light weight lock (SRWs) which can be explicitly static [22:33:15 CET] <wbs> yup [22:33:25 CET] <wbs> does OS/2 have anything matching? :P [22:33:29 CET] <wm4> who knows [22:33:45 CET] <wm4> not my problem, and I think the OS/2 maintainer will take care of it [22:33:47 CET] <wm4> I can CC him [22:41:33 CET] <atomnuker> jamrial: Chloe was working on it and he was quite close [22:42:09 CET] <Chloe> jamrial: when is next bump [22:42:32 CET] <jamrial> who knows [22:42:44 CET] <jamrial> could be in a year, in half a year, or in two years [22:43:04 CET] <wm4> jesus christ ffplay uses the lock manager [22:44:45 CET] <Chloe> wm4: ffmpeg on mingw (on Windows) is actually not practical at all [22:46:04 CET] <atomnuker> Chloe: 2 years, so very long [22:48:57 CET] <Chloe> I can just do it now I guess. [22:50:36 CET] <wm4> Chloe: well I used to do windows development in wine, but they don't support most newer APIs [22:51:45 CET] <wbs> they do add more support for newer APIs all the time though, so it's worth trying with a very recent wine version [22:52:04 CET] <wm4> I doubt I can hope for d3d11va and stuff [22:58:50 CET] <wbs> I wouldn't count on that no [23:08:28 CET] <cone-395> ffmpeg 03Marton Balint 07master:d6a8e46f9788: fate: add 12 bit framerate filter tests [23:08:29 CET] <cone-395> ffmpeg 03Marton Balint 07master:1eb926dc0268: avfilter/vf_framerate: add threaded blending operations [23:08:30 CET] <cone-395> ffmpeg 03Marton Balint 07master:090b740680f9: avfilter/vf_framerate: factorize blend_frames [23:08:31 CET] <cone-395> ffmpeg 03Marton Balint 07master:be15304ee610: avfilter/vf_framerate: factorize get_scene_score [23:08:32 CET] <cone-395> ffmpeg 03Marton Balint 07master:e1113a83ccb6: avfilter/vf_framerate: fix scene change detection score [23:08:33 CET] <cone-395> ffmpeg 03Marton Balint 07master:c6a65ed67088: avfilter/vf_framerate: do not calculate scene change score multiple times for the same frame [23:08:34 CET] <cone-395> ffmpeg 03Marton Balint 07master:e403e4bdbea0: avfilter/vf_framerate: fix scene score with negative linesize [23:13:23 CET] <wm4> nice, windows restarted while compiling ffmpeg [23:13:34 CET] <wm4> it's doing that for an update [23:13:49 CET] <wm4> moronic OS [23:14:35 CET] <BtbN> It usually bugs you about a needed restart for at least a day until it actually just does it [23:18:45 CET] <nevcairiel> it does, and you can configure a time period you want to disable that stuff entirely, usually that only happens when people ignore it for way too long [23:19:40 CET] <BtbN> What sometimes happens is, that it does not perform the updates when you tell it to shutdown [23:19:47 CET] <BtbN> But goes into hibernation instead [23:19:58 CET] <BtbN> so after a few days of that, it does the actual reboot for the update [23:20:24 CET] <BtbN> I have seen Windows with several days of uptime, even though they are "shut down" every night [23:23:03 CET] <wm4> lol [23:27:06 CET] <Chloe> has anyone tried the linux on windows thing for ffmpeg dev? how well does it work compared to a VM? [23:29:05 CET] <wm4> that would still be cross compiling, so I imagine it's basically like a VM, with better filesystem sharing support [23:29:48 CET] <nevcairiel> its a bit more odd then cross compiling, since you can basically run native win32 compilers in it and run the resulting binary as well [23:30:22 CET] <wm4> that sounds like it actually has an advantage [23:30:31 CET] <wm4> at least due to it using kernel fork [23:30:48 CET] <nevcairiel> i havent really tried it much tho [23:33:27 CET] <jdarnley> At least configure should be a bit quicker in it :D [00:00:00 CET] --- Fri Dec 22 2017

1 0

ffmpeg.log.20171221
by burek 22 Dec '17

22 Dec '17

[06:16:21 CET] <illegal> how come I can't see stream size in mediainfo whenever I mux with ffmpeg? [06:16:26 CET] <illegal> I wonder how does mediainfo even get the stream size to begin with [11:13:54 CET] <ItWasntM_> can anyone tell me how to run ffplay or ffmpeg using dshow output? I can't seem to find a way to do it. I want to choose XXX sound card to output audio [12:12:43 CET] <AlienPenguin> Hi, i am trying to compile ffmpeg 3.2.9 on windows using visual studio 2010, i am following the trac guide, however i found an error while compiling avcodec/proresdec2.c: at line 601 there are two "for" loops with the cycling vars defined within the for definition. I extracted the var definition and it seems to be going good... was this a known issue? or some bad config on my side? [12:14:24 CET] <SortaCore> I compile it on VS2015 fine [12:14:45 CET] <SortaCore> not sure if VS2010 is recent enough [12:16:17 CET] <AlienPenguin> SortaCore, vs2015 should accept that since it supports c99, however i did install, as per trac the c99 convert tools [12:16:30 CET] <AlienPenguin> and that error i mentioned is the only one that was reported [12:17:46 CET] <fritsch> what did it complain at this line? [12:18:12 CET] <fritsch> ah! [12:18:16 CET] <AlienPenguin> unknown identifier for the loop variable [12:18:24 CET] <fritsch> it might have a problem with the non need { ? [12:18:26 CET] <fritsch> hehe [12:19:19 CET] <fritsch> https://paste.ubuntu.com/26226630/ [12:19:24 CET] <fritsch> but that would be funny [12:20:15 CET] <AlienPenguin> fritsch, was that a known issue then? [12:21:05 CET] <fritsch> no - but looking at that code that is all "my imagination" can come up with [12:21:22 CET] <fritsch> AlienPenguin: can you try it? [12:21:47 CET] <fritsch> I was not born in 2010 - therefore no idea what happened there in VS [12:22:00 CET] <AlienPenguin> fritsch, in a while, what i did now was to declare i and j out of the for loops [12:22:13 CET] <fritsch> which is just making the scope larger [12:22:32 CET] <fritsch> but i think the issue here rather is that VS has a problem determining the scope [12:27:16 CET] <therage3> would I need to downscale a 24-bit FLAC audio file to 16-bit before burning a Red Book audio CD? if so, do I need to do it manually? [12:27:32 CET] <furq> therage3: yes [12:27:40 CET] <furq> whether you'd need to do it manually depends on what burning tool you're using [12:28:03 CET] <therage3> yeah, I see [12:28:03 CET] <furq> i assume some of them will convert to 16/44.1 pcm before burning [12:28:14 CET] <therage3> I'm just concerned because some people tell me to dither first, others tell me don't do it [12:28:18 CET] <therage3> and now I'm all confused [12:28:23 CET] <furq> it makes no difference really [12:28:34 CET] <therage3> ._. [12:28:37 CET] <therage3> so confused [12:28:37 CET] <therage3> lol [12:28:39 CET] <furq> it's technically better to dither but you won't be able to hear the difference either way [12:28:47 CET] <fritsch> therage3: are those audiophile guys that need a green light to hear that stuff sounds great? [12:28:49 CET] <furq> like with 95% of stuff that audiophiles obsess over [12:28:51 CET] <therage3> hm I see [12:29:01 CET] <fritsch> therage3: then I would give them an USB stick ... with the original flac [12:29:25 CET] <therage3> fritsch: both are audiophiles, the ones that tell me to do it with as well as without dithering, so it's all over the place [12:29:40 CET] <fritsch> let's do the following [12:29:44 CET] <fritsch> make it work [12:29:47 CET] <furq> therage3: ffmpeg -i foo.flac -sample_fmt s16 -dither_method triangular -ar 44100 -filter_size 256 -compression_level 12 foo.wav [12:29:50 CET] <fritsch> and afterwards tell the one guy: dithered [12:29:52 CET] <furq> er [12:29:53 CET] <fritsch> the other one: it's not [12:29:58 CET] <furq> ffmpeg -i foo.flac -sample_fmt s16 -dither_method triangular_hp -ar 44100 -filter_size 256 -compression_level 12 foo.wav [12:30:09 CET] <fritsch> you can avoid the triangular [12:30:11 CET] <furq> triangular_hp is the same thing as sox very high quality, which is what people usually recommend [12:30:13 CET] <therage3> fritsch: haha, nice. i'll need to try that [12:30:17 CET] <furq> but yeah, it hardly makes any difference [12:30:22 CET] <therage3> furq: nice [12:30:26 CET] <furq> and it's very unlikely to make any audible difference [12:30:26 CET] <fritsch> I'd check for the cutoff [12:30:28 CET] <fritsch> frequency [12:30:49 CET] <furq> er [12:30:55 CET] <furq> get rid of compression_level as well [12:31:08 CET] <therage3> i was going to ask [12:31:12 CET] <therage3> since wav's are, well, uncompressed [12:31:13 CET] <therage3> lol [12:31:15 CET] <furq> you might be able to tell that i took this command from an earlier pastebin for someone asking how to do it with flac [12:31:29 CET] <fritsch> cutoff 1.0 filter_size 256 [12:31:32 CET] <fritsch> and fine [12:32:15 CET] <furq> what's wrong with the default cutoff [12:32:29 CET] <fritsch> furq: nothing - but audiophiles you know [12:32:32 CET] <furq> lol [12:32:44 CET] <fritsch> in kodi I implemented: high low mid [12:32:54 CET] <furq> i mean if 1.0 is technically better than 0.97 then i'll add it for the future [12:32:57 CET] <fritsch> and high uses stuff that CPU load increases over mid by at least 5% [12:33:06 CET] <fritsch> so that the audiophiles have a CPU load feedback [12:33:09 CET] <furq> i'm sure it won't be inaudible but this paste is normally going out to audiophiles [12:33:19 CET] <furq> er, won't be audible [12:33:39 CET] <furq> -filter_size 256 is already overkill but it sure gives a nice spectrogram of a sweep sample [12:34:14 CET] <fritsch> jep [12:34:18 CET] <fritsch> Set cutoff frequency (swr: 6dB point; soxr: 0dB point) ratio; must be a float value between 0 and 1. Default value is 0.97 with swr, and 0.91 with soxr (which, with a sample-rate of 44100, preserves the entire audio band to 20kHz). [12:34:47 CET] <fritsch> so - no need to change anything [12:34:55 CET] <fritsch> but yeah, most guys that asked you to dither :-) [12:35:09 CET] <fritsch> might tell you, that they hear those frequencies ;-) "above" that band [12:35:27 CET] <fritsch> while they hear whales singing from 1000 km distance and dog pipes before piping them [12:35:39 CET] <furq> i mean there are people that claim they can hear a difference between aiff and wav [12:35:47 CET] <fritsch> but in that case I would just blame the speakers of their audio phile cd player [12:35:48 CET] <furq> everything is possible [12:35:55 CET] <fritsch> I make blind tests with them [12:36:00 CET] <fritsch> it's quite easy [12:36:21 CET] <fritsch> the stranges guys are those that flac encode dts wavs [12:36:28 CET] <fritsch> :-) [12:36:37 CET] <fritsch> and then in kodi use the software volume [12:36:40 CET] <fritsch> and come and complain [12:36:52 CET] <furq> i mean dts wav is already horrible [12:37:01 CET] <furq> mux it into mka or something [12:37:03 CET] <fritsch> jep, but at least you know what might be coming [12:37:08 CET] <fritsch> and can check [12:37:20 CET] <fritsch> but decoding flac and checking for DTS no way [12:37:54 CET] <fritsch> actually thinking of "downdither" from 24 bit to 16 bit [12:38:02 CET] <fritsch> if that not actually makes more stuff "around" worse [12:38:32 CET] <fritsch> but yeah - trying to think as audiophile makes life unhappy [12:38:32 CET] <furq> what you should do is just silently resample everything to 16/48, and then after a year, announce that you did that [12:38:37 CET] <furq> and see how many people actually noticed [12:38:42 CET] <fritsch> +1 [12:38:51 CET] <fritsch> like the guy with the 3000 dollar usb dac [12:38:56 CET] <fritsch> that attached it to android [12:38:58 CET] <fritsch> :-) [12:39:01 CET] <fritsch> and used audiotrack [12:39:08 CET] <fritsch> that resampled everything and all to 48 / 16 [12:39:11 CET] <furq> nice [12:39:14 CET] <fritsch> he was happy a very long time [12:39:19 CET] <fritsch> until he saw his DAC display [12:39:31 CET] <furq> no doubt he was happy until someone pointed it out to him, at which point he realised it actually sounded terrile [12:39:36 CET] <fritsch> jep [12:39:37 CET] <furq> b [12:39:45 CET] <fritsch> same with HD passthrough vs. lpcm decode [12:39:58 CET] <fritsch> but, but, but my AVR's green light does not light up [12:40:31 CET] <fritsch> okay, enough fun with the audiophiles [12:40:55 CET] <fritsch> therage3: buy them the original CD [12:41:04 CET] <fritsch> from your cold hands ... [12:42:01 CET] <furq> if it's 24-bit then hopefully it's a better master than exists on cd [12:43:00 CET] <furq> strong emphasis on hopefully there [12:43:55 CET] <fritsch> hehe [12:44:02 CET] <fritsch> most likely ripped from CD [12:44:06 CET] <fritsch> and "dithered up" haha [12:52:38 CET] <therage3> well, here's the context [12:52:44 CET] <therage3> this is the product: [12:52:58 CET] <therage3> https://data-discs.com/products/sonic-mania [12:53:12 CET] <therage3> this vinyl comes with a download code for both a FLAC and a lossly mp3 version [12:53:24 CET] <therage3> the FLAC version is the one I'm dealing with; it's 24-bit, 44.1kHz [12:53:59 CET] <therage3> i have no clue how the FLAC mastering was done, either from a vinyl or how [12:56:37 CET] <furq> i assume it'll just be the masters they got from the artist [12:56:59 CET] <therage3> that still leaves open the question, how the artist came up with those masters [12:57:11 CET] <therage3> i guess I could send Tee Lopes an email or something and ask [12:57:11 CET] <furq> by making them? [12:57:20 CET] <furq> either way there's no cd release of that album [12:57:30 CET] <therage3> yes, exactly [12:57:34 CET] <therage3> that's precisely the problem [12:58:25 CET] <furq> at least you got one of their releases that isn't just dumped from a modded megadrive [12:59:10 CET] <therage3> megadrive? this is a new game for new consoles [12:59:16 CET] <furq> i know [12:59:17 CET] <therage3> not a Sonic game from the early 90s [12:59:24 CET] <therage3> but yeah I get you [12:59:34 CET] <furq> data discs have released a lot of megadrive stuff which is just dumped from a console [12:59:36 CET] <therage3> a lot of people make "OST's" by using the soundtest feature of the game [12:59:38 CET] <therage3> and record it [12:59:48 CET] <furq> the only exception is the bare knuckle stuff iirc [12:59:50 CET] <therage3> and God knows wtf they did to "record" it [13:00:02 CET] <furq> which is probably just sourced from koshiro's remasters he did for the anniversary cd [13:00:12 CET] <therage3> I see [13:01:57 CET] <furq> even their shinobi soundtrack is sourced from a console [13:02:10 CET] <furq> and i'm sure koshiro has masters of those [13:02:29 CET] <therage3> damn [13:02:30 CET] <furq> it's nice of them to be up front about it though [13:02:55 CET] <furq> there are at least two remastered cds of that soundtrack and i have no idea what the provenance is [13:02:58 CET] <therage3> maybe they wanted the sound to be identical to what the actual gaming hardware plays [13:03:08 CET] <therage3> so that people don't go "heyyyy this isn't what's on the game" [13:03:10 CET] <therage3> i dunno [13:03:53 CET] <furq> shrug [13:04:14 CET] <furq> actually [13:04:17 CET] <furq> http://vgmdb.net/album/4642 [13:04:22 CET] <furq> Disc 1: The Super Shinobi & Bare Knuckle: Ikari no Tekken -PC-8801 Version- [13:04:44 CET] <furq> the pc-88 is what koshiro composed these on, so he obviously does still have the masters [13:04:58 CET] <furq> with that said the pc-88 versions of bare knuckle 2 do sound noticeably different [13:09:43 CET] <therage3> I see [13:13:36 CET] <furq> aww [13:13:46 CET] <furq> i saw data discs have previews on their soundcloud, so i thought i'd compare some of the masters [13:14:00 CET] <furq> but i forgot soundcloud is 128k mp3 and so it just sounds like garbage anyway [13:15:13 CET] <zash> what is this, 1996? [13:16:15 CET] <furq> i should try and track down a copy of gunstar heroes because all the cd masters of that sound like garbage [14:32:23 CET] <khali> good afternoon folks [14:32:57 CET] <SortaCore> heyo [14:33:08 CET] <SortaCore> I'm about to go to bed [14:33:13 CET] <SortaCore> #Brexit [14:37:18 CET] <khali> alexpigment: I have prepared the samples for you [14:39:44 CET] <khali> let me know if/when you have time to look at them [16:07:30 CET] <alexpigment> khali, i'll take a look, but odds are someone else might be more able to help [16:17:14 CET] <khali> alexpigment: both files are at http://jdelvare.nerim.net/avidemux_vs_ffmpeg/ [16:17:28 CET] <khali> same source, same x264 settings [16:17:53 CET] <alexpigment> oh this issue. right ;) [16:18:07 CET] <alexpigment> i was thinking this was something someone else mentioned [16:18:28 CET] <khali> ffmpeg-generated file is 45% larger [16:18:32 CET] <alexpigment> k [16:18:37 CET] <alexpigment> downloading now [16:18:40 CET] <khali> I stripped sound to get it out of the equation [16:18:46 CET] <alexpigment> good thinking [16:19:28 CET] <khali> the only difference I can see is that tbn and tbc values are different [16:19:57 CET] <khali> I did not specify them, so I don't know how avidemux and ffmpeg decided them [16:20:38 CET] <alexpigment> well, this might indicate that one is progressive and one is interlaced [16:21:12 CET] <alexpigment> because mediainfo shows "original frame rate" of 50fps with the avidemux version [16:21:18 CET] <therage3> lol [16:21:22 CET] <therage3> so many bad memories [16:21:29 CET] <therage3> soooo so many bad memories of this very topic [16:21:29 CET] <alexpigment> :) [16:21:41 CET] <khali> alex: but mediainfo says Progressive for both files still [16:22:51 CET] <alexpigment> yeah I see that. but the original frame rate thing I've seen in the past. in my experience it's that the interlacing is done via "separated fields" rather than MBAFF. either way, i'm just throwing that out there as a slight possibility. still looking [16:22:53 CET] <khali> (the source is clearly interlaced though, you are right) [16:23:25 CET] <therage3> khali: i had issues exactly like yours, different programs reporting different things [16:23:35 CET] <therage3> in my case, it turned out to be a shitty mastering process [16:23:51 CET] <therage3> it was a cartoon that was hard telecined but with bizarelly random hard-telecined frames [16:23:55 CET] <therage3> which made a lot of filters act up [16:25:52 CET] <khali> alexpigment: I can't share the source file itself as it is 6 GB, but I can provide any information you need about it [16:25:53 CET] <alexpigment> khali: out of curiosity, you're presumably wanting to deinterlace, right? [16:26:21 CET] <alexpigment> and assuming you are, do you want to keep the original motion smoothness (50fps) or decimate down to 25fps? [16:26:33 CET] <khali> I can also share the 1st few MBs of it if it helps [16:26:40 CET] <khali> alexpigment: no I don't [16:26:59 CET] <alexpigment> khali: ok so you're fine with the interlaced combing in the output? [16:27:21 CET] <khali> the samples are the very beginning of the recording, I chose that because it was easier to produce the 2 files [16:27:38 CET] <khali> but what I'm actually interested it is later in the source file, and it is not interlaced [16:28:32 CET] <alexpigment> if you cut the latter part of the source file? if it's actually true progressive, I'm wondering if that ends up the same size in both programs [16:28:39 CET] <khali> in my experience DVB-T streams are always advertised as interlaced even when the actual material is progressive, probably for "compatibility reasons" [16:29:37 CET] <khali> alexpigment: no, the file size problem persists, that's even how I noticed it in the first place [16:30:10 CET] <khali> but I can generate new samples from the right section, if you think this is relevant [16:30:39 CET] <alexpigment> not yet. looking more into this [16:31:56 CET] <khali> I have added the output of mediainfo on the source, for your convenience [16:32:49 CET] <alexpigment> ok, so here are my thoughts: [16:33:48 CET] <alexpigment> 1) avidemux might be preserving the interlacing, even if mediainfo reports progressive. like I said, it also shows "original frame rate" or 50fps, which only generally exists when some aspect of the video is interlaced, in my experience [16:34:54 CET] <alexpigment> 2) you've got this set to level 5.0, which is not what I would expect from a 1080p25 video. it's possible that avidemux is enforcing a lower bitrate limit (like 4.0 or 4.1) and ffmpeg is taking full advantage of the 5.0 bitrate limitations [16:35:28 CET] <alexpigment> you can rule out number 2 by setting them both to level 4.0 and see if the bitrate becomes basically the same [16:36:44 CET] <alexpigment> you can rule out number 1 by adding an interlacing filter in avidemux. use Yadif and set it to the default settings; in ffmpeg, similarly add -vf yadif=0 [16:37:08 CET] <khali> alexpigment: adding "-level 4.0" on the ffmpeg command line would do that? [16:37:15 CET] <alexpigment> yeah [16:37:28 CET] <khali> trying right now [16:37:59 CET] <khali> I was surprised that 5.0 is the default btw, as I read that most devices available only support 4.1 [16:38:38 CET] <DHE> that's about right. 4.1 supports 1080p at 30fps [16:38:59 CET] <alexpigment> yeah, 5.0 is generally only necessary for higher resolutions than 1080p [16:39:16 CET] <alexpigment> even 4.2 is all that's needed for 1080p60/50 [16:39:44 CET] <alexpigment> of course, if the bitrate gets extremely high, you'll hit level 5.0 [16:43:18 CET] <khali> alexpigment: I tried with -level 4.0, no change in file size [16:43:38 CET] <alexpigment> yeah, i didn't think that was going to be it, but I figured I'd mention it [16:43:41 CET] <khali> only difference is "Format profile : High@L4" in mediainfo output [16:43:47 CET] <alexpigment> with such a low average bitrate, it probably isn't spiking too much [16:43:59 CET] <DHE> can a -level really change anything? the only settable h264 parameter that it can clamp is the reference frame count. libx264 can't change the framerate or the resolution of the input image. [16:44:35 CET] <alexpigment> DHE: I only mentioned it in case avidemux adds vbv options on the backend to enforce levels [16:44:52 CET] <alexpigment> ffmpeg doesn't do that for x264 though [16:45:14 CET] <khali> producing yadif files now [16:45:33 CET] <DHE> but x264 does that itself. you specify the level to the encoder and it will clamp settings. similarly for preset and profiles [16:47:40 CET] <alexpigment> DHE: are you sure? if you set level 4.0 and CRF ~1, it'll go beyond the 4.0 bitrate limits I believe [16:50:40 CET] <alexpigment> fwiw, I just did a test with a high CRF, set one to level 4.0 and one to level 5.0. the file sizes are the same and the avergae bitrate is 102mbps on both [16:53:27 CET] <khali> with yadif filter applied, avidemux output is down from 15.2 MB to 12.9 MB, and ffmpeg output is down from 22.0 MB to 18.6 MB [16:53:37 CET] <alexpigment> weird [16:53:56 CET] <alexpigment> i'm going to try one more thing and then probably give up [16:53:58 CET] <alexpigment> 1 sec [16:54:22 CET] <khali> well it is expected that both go down, as the source is indeed interlaced, so progressing encoding was certainly a nightmare for x264 ;-) [16:54:40 CET] <khali> progressive*, sorry [16:55:25 CET] <alexpigment> does mediainfo still report an original frame rate of 50 for the one using yadif? [16:55:43 CET] <alexpigment> the one from avidemux specifically [16:57:42 CET] <DHE> alexpigment: https://github.com/mirror/x264/blob/master/encoder/set.c#L816 seems I'm wrong. it will show warnings/errors instead of clamp. it doesn't appear to be fatal to the encoder though. [16:58:23 CET] <alexpigment> also, have you tried putting in -preset veryslow in your ffmpeg command line? everything looks like this should be equivalent, but maybe there's something else that occurs when you explicitly set it [16:58:35 CET] <alexpigment> DHE: good to know [16:59:31 CET] <alexpigment> DHE: if you have a chance, take a look at khali's sample files above. he's got one file from avidemux and one from ffmpeg, seemingly using the exact same settings, but the ffmpeg one is significantly bigger [16:59:41 CET] <alexpigment> i'm out of ideas about what the difference might be [17:00:31 CET] <khali> alexpigment: yes, after yadif is applied, I still see "Original frame rate : 50.000 FPS" in the mediainfo output [17:00:50 CET] <alexpigment> k [17:01:14 CET] <khali> and yes I tried setting -preset veryslow for ffmpeg [17:01:35 CET] <alexpigment> ok, i'm completely out of ideas then. maybe someone else here might spot the key factor [17:02:31 CET] <khali> this changes the values of the lookahead_threads, bframes and direct, but does not affect the file size noticeably [17:04:26 CET] <alexpigment> i believe kepstin was helping you on this the other day, right? maybe he'll chime in and see if he can figure it out with those samples you provided [17:05:16 CET] <khali> correct, he was trying to help as well [17:05:26 CET] <khali> I have just uploaded the first 33M of the source file [17:05:47 CET] <khali> which is the same video duration as my samples, roughly [17:05:58 CET] <khali> in case it helps any [17:06:19 CET] <khali> either way, thank you very much alex for your help, that was highly appreciated [17:07:03 CET] <khali> at least, if you can't figure it out either, it means I'm not completely crazy or inept ;-) [17:07:04 CET] <alexpigment> no worries. sorry I couldn't be of help [17:07:26 CET] <alexpigment> you're implying that i'm not inept? ;) [17:10:10 CET] <alexpigment> khali: actually, I think I just proved that the avidemux one is interlaced [17:11:08 CET] <alexpigment> 1 sec [17:12:06 CET] <alexpigment> ok, so I took the avidemux one into handbrake [17:12:20 CET] <alexpigment> it's deinterlace filter seems to work a little bit better for reasons I don't fully understand [17:12:48 CET] <alexpigment> anyway, I set it to deinterlace > Yadif > Bob > Interlaced Detection Off [17:13:00 CET] <alexpigment> I then set the frame rate to 50fps in the Video section [17:13:08 CET] <alexpigment> the resultant video has 50 unique frames per second [17:14:31 CET] <khali> it reconstructs full frames from fields, using interpolation? [17:14:42 CET] <alexpigment> well, not via interpolation [17:14:52 CET] <alexpigment> maybe some interpolation [17:14:57 CET] <alexpigment> it's mostly just line doubling though [17:15:26 CET] <alexpigment> so every field has half the amount of vertical lines (540 instead of 1080). on the most basic level, it just doubles the field lines to 1080 and then makes it a frame [17:15:27 CET] <khali> that's interpolation.... with weights 0 and 1 ;-) [17:15:38 CET] <alexpigment> k :) [17:16:15 CET] <alexpigment> I just meant that it's not interpolating frames in the sense that it's making up frame 1.5 by seeing the difference between frames 1 and 2 [17:16:32 CET] <khali> yes, of course not [17:16:35 CET] <alexpigment> you know, that horrible thing that modern TVs do by default ;) [17:16:47 CET] <khali> I know :( [17:17:14 CET] <khali> I can't believe TV is still using interlaced cameras in 2017 [17:17:40 CET] <khali> these should have been banned from the planet one decade ago [17:18:04 CET] <alexpigment> khali: well, given that most broadcast is still 1080i, it makes sense for the cameras to be as well, at least from one perspective [17:18:18 CET] <khali> yeah [17:18:19 CET] <alexpigment> although ideally, we'd be shooting in 1080p60/50 and the interlacing as necessary for the output [17:18:28 CET] <khali> my point is that the whole chain should be progressive [17:18:33 CET] <alexpigment> true [17:18:57 CET] <khali> and if they want it as smooth as before, they can go 50p/60p [17:19:05 CET] <alexpigment> but if streaming media is any indicating, getting rid of interlacing would mean than we'd be at 1080p30/1080p25 rather than 1080p60/50 [17:19:22 CET] <alexpigment> *indication [17:19:30 CET] <khali> personally I would have killed interlacing first, before trying to increase resolution [17:19:49 CET] <khali> true as well [17:20:24 CET] <alexpigment> so back to the issue at hand: I'm not exactly sure why avidemux is treating the interlacing differently [17:20:38 CET] <khali> but it's easier to produce 30p output from 60p source than decent 30p output from 60i [17:20:48 CET] <alexpigment> but what I would try is to add -flags +ilme+ildct to the ffmpeg command [17:21:11 CET] <khali> yes sir, trying immediately [17:21:28 CET] <alexpigment> khali: true, although it depends on the type of source media. getting true ~24fps from 1080i is easy [17:21:32 CET] <khali> without yadif, right? [17:21:35 CET] <alexpigment> yeah [17:21:57 CET] <alexpigment> now, the file sizes are not going to match, most likely. but I believe the file size will still go down on ffmpeg [17:23:55 CET] <khali> hmmm ffmpeg seems unhappy [17:24:09 CET] <khali> [libx264 @ 0x11bf0c0] interlace + weightp is not implemented [17:24:09 CET] <khali> [libx264 @ 0x11bf0c0] using SAR=1/1 [17:24:09 CET] <khali> [libx264 @ 0x11bf0c0] interlaced (1) > level limit (0) [17:24:27 CET] <alexpigment> oh, do you still have -level 4.0 specified? [17:24:31 CET] <alexpigment> get rid of that [17:24:51 CET] <alexpigment> and you can ignore the interlace + weight p and the using SAR messages [17:24:53 CET] <alexpigment> that's normal [17:25:14 CET] <khali> no I don't have level specified [17:25:15 CET] <alexpigment> well, normal for me, anyway. i primarily work with interlaced content [17:25:18 CET] <alexpigment> k [17:25:36 CET] <alexpigment> i'd still ignore it [17:25:41 CET] <khali> file size is a bit down indeed [17:25:56 CET] <khali> from 22.6 MB to 21.7 MB [17:25:59 CET] <alexpigment> is it comparable to the with_avidemux.mp4 sample you sent earlier? [17:26:01 CET] <alexpigment> hmmm [17:26:22 CET] <alexpigment> maybe a sample of the original source would be helpful for this after all [17:26:25 CET] <khali> still nowhere close to what avidemux produces (15.6 MB) [17:26:34 CET] <khali> I have uploaded that already [17:26:50 CET] <alexpigment> I think avidemux is doing some weird handling of the interlacing. it's passing it off as progressive, but the interlacing is still there in some respect [17:26:51 CET] <khali> you can download source.ps [17:26:55 CET] <alexpigment> oh, it's on the same page [17:27:04 CET] <khali> yep [17:27:28 CET] <khali> it's a truncated file but hopefully for a MPEG-TS file it shouldn't matter much [17:27:36 CET] <alexpigment> should be fine i think [17:34:20 CET] <ZexaronS> Hello [17:34:56 CET] <ZexaronS> I'm looking to find a way to burn-in DVBSUBtitles from a MPEGTS which uses 3 streams of DVBSUBs [17:35:32 CET] <ZexaronS> I tried with VLC but no luck, I don't know how to select the correct DVBSUB stream (language) [17:36:09 CET] <ZexaronS> I used the GUI, probably need to use a more refined command [17:36:49 CET] <ZexaronS> Also, the file contains Teletext subtitles, which I think may be something else, but it's not showing DVBSUBs in MediaInfo, so I'll do a ffprobe [17:46:54 CET] <alexpigment> khali: fyi, I'm trying to figure out which filter most closely matches how ffmpeg handles (or doesn't handle, rather) the interlacing of the original source [17:47:14 CET] <alexpigment> i'll let you know what i find [17:54:25 CET] <khali> alexpigment: ok [17:54:58 CET] <khali> alexpigment: but I wonder if you aren't barking up the wrong tree [17:55:49 CET] <alexpigment> khali: it's possible I am. but if I can get true 50fps out of the avidemux one and I can't out of the ffmpeg one, that means there's a lot more unique data in the one from avidemux [17:55:53 CET] <khali> because the bitrate difference also exists on the portion of the source which is "progressive" (in the visual sense of the term... might be interlaced from a video stream perspective) [17:56:24 CET] <khali> alex: but then the avidemux one would be larger, not smaller? [17:56:34 CET] <alexpigment> it's valid point, but there may be some nuances in how the two types of content get processed [17:57:52 CET] <alexpigment> khali: if ffmpeg sees every other line as being from a different timestamp, it's going to be harder to encode it into progressive. on the other hand, avidemux might be interpreting the source more correctly, encoding it as mbaff and saving bits because each line is similar to the one above and below it [17:57:59 CET] <alexpigment> just kind of my off-the-cuff thought here [17:58:39 CET] <khali> well one interesting data point is that I had to convert a completely different file, old avi which had not need properly encoded at the time [17:59:04 CET] <khali> I did it with both avidemux and ffmpeg, and I get the same file size [17:59:07 CET] <alexpigment> i think the real problem is that ffmpeg's handling of MPEG-4 with non-mbaff interlaced encoding is bad. I've had many experiences that point to this [17:59:18 CET] <khali> (after aligning the settings, that is) [17:59:35 CET] <khali> so the source definitely matters [18:00:06 CET] <alexpigment> here's perhaps a better test [18:00:15 CET] <khali> mediainfo claims my source is MBAFF-interlaced.... is it lying? [18:00:16 CET] <alexpigment> you don't have something like adobe premiere or a pro level NLE do you? [18:00:22 CET] <khali> no I don't [18:00:40 CET] <alexpigment> khali: well, it says "separated fields" [18:00:40 CET] <khali> running Linux here and no commercial software [18:00:48 CET] <alexpigment> that's the key factor in my experience [18:00:54 CET] <alexpigment> maybe non-mbaff is mispoken [18:00:55 CET] <khali> ok [18:01:09 CET] <alexpigment> but anything that says "separated fields", I've had to override ffmpeg's default detection [18:01:29 CET] <alexpigment> this is common among consumer cameras that shoot 1080i [18:01:34 CET] <alexpigment> in avchd [18:01:36 CET] <khali> France switched from MPEG-2 to MPEG-4 for DVB-T not so long ago [18:01:45 CET] <alexpigment> as they should [18:01:52 CET] <alexpigment> i wish the US would do the same [18:01:52 CET] <khali> beforehand I was using dvbcut and ffmpeg and it worked like a charm [18:02:13 CET] <alexpigment> yeah, the reason I was asking about Premiere is that I was going to suggest converting to true interlaced MPEG-2 [18:02:19 CET] <alexpigment> and seeing if the result was the exact same [18:02:24 CET] <alexpigment> i'll get you a sample in a few minutes [18:02:38 CET] <khali> but dvbcut no longer works with MPEG-4.... which is how I ended up using avidemux instead.... but avidemux has a few annoying bugs :/ [18:03:02 CET] <alexpigment> if you had Windows, I would HIGHLY recommend videoredo [18:03:09 CET] <alexpigment> i use that tool every single day [18:03:58 CET] <alexpigment> that would also probably get rid of those ffmpeg error messages about missing reference picture probably [18:04:29 CET] <CoreX> you gonna give him the $$$ for videoredo [18:04:46 CET] <CoreX> tho you could just pirate it [18:04:54 CET] <khali> no, I would not [18:04:59 CET] <khali> obviously [18:05:19 CET] <furq> http://www.videoredo.com/en/images/wwb_img6.jpg [18:05:30 CET] <CoreX> lol [18:05:41 CET] <alexpigment> yeah, they definitely get awards for bad stock images [18:06:29 CET] <alexpigment> anyway, I purchased videoredo for like $50 originally and then upgraded at some point for some lower price. as for paid software, I've gotten my money's worth over and over [18:06:45 CET] <alexpigment> I think tmpgenc has a similar smartcutter tool but i've never used it [18:07:58 CET] <khali> handbreak doesn't offer any editing options, right? [18:08:06 CET] <khali> handbrake* even [18:08:18 CET] <alexpigment> not that i'm aware of [18:09:11 CET] <alexpigment> fyi, i'm testing this again after converting to MPEG-2 in premiere [18:09:12 CET] <CoreX> are you just trying to cut with ffmpeg in certain frames ? [18:09:39 CET] <alexpigment> if i get the same file size in each, it'll confirm that it's ffmpeg's bad handling of mpeg-4 interlacing [18:11:25 CET] <alexpigment> khali: ok, same file size now with the converted MPEG-2 source [18:11:44 CET] <alexpigment> lemme look how i've worked around this in the past [18:23:37 CET] <alexpigment> khali: ok, I've got the two encodes to match more or less [18:24:27 CET] <alexpigment> ffmpeg -r 25 -i [source] [settings] -vf yadif=1 -r 25 [output] [18:24:42 CET] <jaggz> how do I record from a pulseaudio source? this is the device as displayed by "pactl list sources": http://slexy.org/view/s21zhjKCms [18:25:34 CET] <alexpigment> avidemux: add filter Yadif > Bob, skip spacial temporal check > Top field first ; add filter Resample FPS > 25 (PAL) [18:26:02 CET] <alexpigment> that makes both of them deinterlace to 50p, then drop frames down to 25fps [18:26:18 CET] <alexpigment> which is personally what I'd do with interlaced source content, even if it's got progressive parts [18:29:33 CET] <alexpigment> khali: of course, if you really want to preserve the original fidelity, make the output rate in ffmpeg be 50fps rather than 25fps. keep the -r 25 before the input though [18:31:32 CET] <jaggz> https://www.ffmpeg.org/ffmpeg-devices.html#pulse [18:31:39 CET] <jaggz> weird ffmpeg [18:31:48 CET] <jaggz> says "PulseAudio input device. To enable this output device..." [18:32:18 CET] <fritsch> every output has a monitor attached [18:40:36 CET] <khali> alexpigment: I never realized -r could be used for both input and output [18:40:53 CET] <alexpigment> khali: yeah, it's kind of a way to ensure that the file is being read properly [18:41:14 CET] <alexpigment> or perhaps a way to override the source frame rate for time stretching [18:41:59 CET] <alexpigment> but either way, my MPEG-2 tests kinda confirmed that this disparity between the two applications has to do with how they handle interlaced MPEG-4. neither of them are really handling the video "right" [18:42:37 CET] <alexpigment> so the file size may still be bigger than it was with the original avidemux, but at least now you'll have a file that can be properly read by most players [18:42:47 CET] <khali> I understand, thanks for the investigation [18:42:57 CET] <khali> but one thing worries me [18:43:43 CET] <khali> I fully understand how it can affect the bitrate when the input frames are actually interlaced, as is the case of this sample [18:44:25 CET] <khali> but when the input frames are from a progressive source (true 25 fps, not 50i), I can't see how it can make a difference [18:45:10 CET] <alexpigment> you mentioned that there is a part that's progressive later on [18:45:30 CET] <alexpigment> but I don't have that sample, so I can't speak on it [18:45:50 CET] <alexpigment> maybe it too is actually interlaced and tagged wrong [18:45:55 CET] <alexpigment> i can only speculate [18:47:08 CET] <khali> I'll test again on what I believe is progressive [18:47:13 CET] <khali> maybe I missed something [18:48:39 CET] <alexpigment> khali: if you look in avidemux at File > Information, see what it says the frame rate is [18:48:48 CET] <alexpigment> avidemux is shown 50fps on this source.ts file [18:48:52 CET] <alexpigment> even though it's actually 25fps [18:49:15 CET] <alexpigment> if it's doing the same thing on your 'progressive' sample, then it's probably handling it in the same quasi-interlaced way [18:52:39 CET] <khali> alexpigment: it says 50 fps [18:52:56 CET] <alexpigment> yeah, then i'd guess it's actually 25i [18:53:31 CET] <khali> I think one cause of problems is that DVB-T streams both interlaced and progressive contents [18:53:55 CET] <khali> and I guess it "looks better" to deinterlace everything than to deinterlace nothing [18:54:03 CET] <alexpigment> how can you tell it's actually progressive and not just interlaced with identical fields? [18:54:09 CET] <khali> so they take the easy way a treat everything as interlaced [18:54:37 CET] <khali> sorry, what I say may be seen as technically incorrect [18:54:54 CET] <alexpigment> i mean you ideally don't want to switch back and forth so you don't confuse decoders. in our cable system, everything that's 1080i stays interlaced the entire time [18:55:09 CET] <khali> I mean that for example TV shows are recorded with interlaced cameras, while movies are recorded with progressive cameras [18:55:15 CET] <alexpigment> ahh right [18:55:18 CET] <khali> and both end up in the same DVB-T stream [18:55:20 CET] <alexpigment> so, that's normal [18:55:29 CET] <alexpigment> but you have to treat them differently if you're going to deinterlace [18:55:48 CET] <khali> ideally the information would still be present in the DVB-T stream so that the end viewer (me) knows how to process it best [18:55:59 CET] <khali> but in practice the information is long lost when the data reaches me [18:56:05 CET] <alexpigment> well, actually, maybe not for PAL. i don't know what the hell they do for telecined content on PAL tv. maybe they do the 4% speedup [18:57:13 CET] <khali> yes they do [18:57:24 CET] <alexpigment> so in NTSC, most things are 1080i as I said. some of the content is filmed at 1080i (29.97fps, 59.94 effective rate), some of it is filmed at 23.976fps and some of it is filmed at 29.97fps [18:57:40 CET] <khali> movies last a bit less when you watch them on TV in Europe, than in cinema or US TV [18:58:08 CET] <khali> 25/24 telecine is simply not worth it.... would probably look horrible too [18:58:43 CET] <alexpigment> so if i were going to deinterlace, i'd deinterlace true 1080i as 1080p50. i'd inverse telecine the film-sourced content to 23.976. i'd then deinterlace and drop frame for the 29.97fps progressive content. OR... i'd just leave it all interlaced. which is basically what i do because it require zero thought and looks correct on my tv [18:59:05 CET] <alexpigment> *requires [18:59:10 CET] <khali> hehe [18:59:24 CET] <khali> perfectionism vs pragmatism :) [19:00:18 CET] <therage3> the audiophile's worst nightmare [19:09:47 CET] <khali> I'll have diner now, I'll resume working on this when I return [19:09:56 CET] <khali> thanks a lot for all the help so far [19:10:11 CET] <alexpigment> khali: yeah, that's kinda how I do it. I also realize that deinterlacing methods aren't perfect anyway, so pragmatism is kinda also still a better bet :) [19:10:28 CET] <alexpigment> anyway, see you around later [19:29:31 CET] <furq> alexpigment: i've only ever seen the 4% speedup but apparently film to pal pulldown is a thing [19:29:44 CET] <furq> apparently it's called [19:29:45 CET] <furq> 2-2pulldown.svg [19:29:50 CET] <furq> shut up clipboard [19:29:54 CET] <alexpigment> furq: yeah, I just didn't know how they did it for like TV shows. I knew movies did the speedup thing [19:29:56 CET] <furq> apparently it's called 2:2:2:2:2:2:2:2:2:2:2:3 pulldown [19:30:05 CET] <furq> you'll forgive me for obviously copying and pasting that [19:30:09 CET] <alexpigment> but yeah, i knew there was that pulldown method which sounds horrible ;) [19:30:34 CET] <furq> i've never seen it [19:30:38 CET] <furq> but then i don't watch very much tv [19:30:43 CET] <furq> i've certainly never seen it on a dvd [19:30:43 CET] <alexpigment> i haven't either, but i live in the US, so that's my excuse [19:31:03 CET] <alexpigment> yeah I think all commercial movies use a speedup [19:31:15 CET] <furq> every pal film dvd i own is just sped up [19:31:25 CET] <furq> or at least the ones that i've ripped are [19:31:32 CET] <furq> i've not checked the times on all of them [19:31:46 CET] <alexpigment> but since you can't do a speedup in realtime, i wondered if broadcast channels take 23.976 US tv feeds and apply a pulldown [19:32:49 CET] <furq> 24fps us tv feeds? [19:32:50 CET] <alexpigment> i realize it's unlikely that someone is getting a *live* 23.976fps feed, but still [19:32:50 CET] <furq> is that a thing [19:33:00 CET] <alexpigment> well, shows that are recorded in 23.976 [19:33:32 CET] <alexpigment> anyway, i'm just guessing here. I have no idea how things go down in PAL-land [19:33:47 CET] <furq> i don't know that any live american shows are simulcast here [19:33:52 CET] <furq> but if they are then they're probably not 24fps [19:33:56 CET] <alexpigment> right [19:34:03 CET] <alexpigment> it would be a 1080i60 > 1080i50 conversion [19:34:07 CET] <furq> yeah [19:34:08 CET] <alexpigment> which also sounds problematic [19:34:13 CET] <furq> which i assume is just dropping every sixth frame [19:34:38 CET] <furq> it's at least easier than a 480i to 576i conversion [19:34:43 CET] <alexpigment> i can almost feel the 3:2 pulldown cadence being ruined ;) [19:34:53 CET] <alexpigment> true [19:44:43 CET] <kepstin> i think most 24000/1001fps content broadcast in the us is done telecined in a 60i stream :/ [20:25:55 CET] <alexpigment> kepstin: yeah, I figured so. I just didn't know in what form european TV stations get their content for syndication [21:13:43 CET] <pos> so, i've got this application which is basically doing v:copy and a:copy from a source and piping it to a mp4 with some header mods. problem is, some of the sources are using their own sys or stream uptime as "length" which is messing with playback of said files later on [21:13:58 CET] <pos> are there any params which will remedy this? [21:16:17 CET] <pos> long story short: the files (which may last like five minutes) appear to vlc/mplayer/whatever to be for example 232 hours long [21:41:49 CET] <khali> alexpigment: I tested again, and can only confirm what I said before [21:42:38 CET] <khali> for film material, which is originally not interlaced, I see a similar difference between the two tools, for same x264 settings [21:42:48 CET] <alexpigment> *originally is the operative word [21:43:12 CET] <alexpigment> you have a video that has an interlacing method that neither avidemux nor ffmpeg handle the same way [21:43:19 CET] <khali> well, I look at the pictures too, and my eyes tell me it's not interlaced and doesn't need deinterlacing [21:44:28 CET] <alexpigment> khali: i completely understand that, but it *is* interlaced and it is being handled in a particular way. for example, ffmpeg is converting it to 25fps progressive, so it's not just keeping it interlaced [21:44:45 CET] <khali> alex: I just don't get why either would even try anything, given that I did not enable any filter [21:45:14 CET] <alexpigment> khali: here's a test you can do [21:45:19 CET] <khali> alex: is there anyway I can convince ffmpeg that the input if not interlaced? [21:45:26 CET] <khali> is* not [21:45:27 CET] <alexpigment> 1 sec [21:46:02 CET] <alexpigment> take what you out of ffmpeg, then re-run it through avidemux and then ffmpeg with those same settings. i assume the file size is the same now? [21:46:21 CET] <alexpigment> khali: I think ffmpeg is not realizing it's interlaced in the first place [21:47:05 CET] <alexpigment> avidemux does seem to realize that the file isn't 25fps progressive, but then it's doing some weird hack job on the output so that it writes a "progressive" file that actually has interlaced frames [21:48:18 CET] <alexpigment> also, the test I mentioned above, which is taking your ffmpeg output from earlier (the file you put on your server) and re-running the encoding jobs in both avidemux and ffmpeg from this source should kinda prove this [21:48:41 CET] <alexpigment> if the files end up the same size, that is [21:49:14 CET] <khali> sorry, do you mean ffmpeg -> avidemux -> ffmpeg, or compare ffmpeg -> avidemux and ffmpeg -> ffmpeg? [21:51:17 CET] <alexpigment> so, earlier you sent a file that was from source > ffmpeg [21:51:27 CET] <alexpigment> and this one was bigger than source > avidemux [21:51:34 CET] <khali> yes [21:51:36 CET] <alexpigment> take that ffmpeg output [21:51:51 CET] <alexpigment> run it through the same encoding path in both avidemux and ffmpeg [21:52:05 CET] <alexpigment> basically re-encode what you've already encoded [21:52:22 CET] <khali> yeah; that thing I was told to never do ;-) [21:52:31 CET] <alexpigment> this is for testing and confirmation [21:52:35 CET] <alexpigment> not for watching [21:52:43 CET] <khali> and yes, same file size [21:52:58 CET] <khali> 9473074 vs 9481282, can hardly be closer [21:53:11 CET] <alexpigment> ok, so the reason is that the output from ffmpeg in the first encode is true progressive [21:53:33 CET] <alexpigment> ffmpeg basically hamfisted your source and said "here you go. sorry about your fields" :) [21:53:42 CET] <alexpigment> which is the default behavior for ffmpeg [21:54:12 CET] <khali> and is the right thing to do in that case, right? [21:54:27 CET] <alexpigment> it depends on what you want it to do [21:54:49 CET] <alexpigment> if you're only interested in the part of the video that's true progressive, then I suppose so [21:54:56 CET] <khali> yes [21:55:07 CET] <alexpigment> but I would personally still use -yadif=0 on those progressive parts [21:55:12 CET] <alexpigment> er [21:55:15 CET] <alexpigment> -vf yadif=0 [21:55:30 CET] <khali> isn't it losing some information? [21:55:37 CET] <alexpigment> now, the result of this is larger than the output of avidemux, and I understand that, but it's actually in the correct format [21:56:02 CET] <alexpigment> well, if the content is true progressive in an interlaced stream, then each interlaced field should have exactly 1/2 of the information [21:56:11 CET] <khali> so your conclusion is that I should stay away from avidemux? [21:56:12 CET] <alexpigment> and -yadif=0 should combine each field into one frame [21:56:33 CET] <alexpigment> khali: yeah, it's making a weird file that I don't think will play consistently on different players [21:56:36 CET] <alexpigment> even if the output is smaller [21:57:30 CET] <khali> and I've been using for over a year; yay :/ [21:57:40 CET] <alexpigment> if it works, it works, I guess [21:58:00 CET] <khali> it works with VLC... didn't try the files anywhere else yet [21:58:29 CET] <alexpigment> I've always felt avidemux was really janky. I get that it has its advantages (a preview that you can use to cut), but most everything it does can be done better by another application on Windows, for me [21:58:49 CET] <khali> which brings me to my next question: is there a free alternative to avidemux running on Linux? [21:58:59 CET] <alexpigment> well, VLC also doesn't handle interlacing correctly anyway, but it seems like you're not trying to watch the true interlaced part of the stream [21:59:33 CET] <alexpigment> VLC makes you have to opt-in to an interlacing mode, and the only decent on is Yadif2x, which is a huge CPU hog and causes dropped frames on many systems [21:59:38 CET] <khali> I think I'm trying to convince myself that interlaced material doesn't exist.... for my own peace of mind :D [21:59:51 CET] <alexpigment> khali: there are a lot of people who are in that boat [22:00:08 CET] <alexpigment> but almost everything I deal with is interlaced, so it's something I have to think about regularly [22:00:54 CET] <khali> more seriously, I don't record anything interlaced... the few interlaced things I watch, I watch live, and forget about them [22:01:34 CET] <alexpigment> that's understandable. most things I record are things that don't get rebroadcast ever again, and most of them are true 1080i [22:01:56 CET] <alexpigment> anything else (tv shows, etc), they'll generally be around for years whenever I want to watch them [22:02:05 CET] <khali> I was horrified when I found that Breaking Bad had been recorded with TV (interlaced) cameras [22:02:16 CET] <alexpigment> ah, so the telecine was burned in? [22:02:19 CET] <khali> and skipped it altogether, although I was told it was pretty good [22:02:35 CET] <alexpigment> yeah, it's a good show [22:02:48 CET] <alexpigment> but even if the cameras are interlaced, it's probably in a telecine mode [22:03:07 CET] <alexpigment> which means that they almost certainly inverse telecined for the master copies [22:03:18 CET] <khali> what was broadcast on TV here was purely non-encodable [22:03:26 CET] <khali> I tried a few tricks and gave up [22:03:29 CET] <alexpigment> there, yes [22:03:38 CET] <kepstin> well, the problem with doing telecine in camera is that they might have done editing on the interlaced stuff, so there could be bad cuts and mismatched overlays and stuff [22:03:52 CET] <kepstin> crossfades are the worst :( [22:04:02 CET] <alexpigment> wouldn't you IVTC before editing though? [22:04:20 CET] <alexpigment> maybe there's a nuance of telecine modes on cameras that I don't understand [22:04:40 CET] <kepstin> well, if you just open the stuff you get off the camera in your editing suite, it'll open in interlaced mode [22:04:52 CET] <alexpigment> right, but we're talking about a major TV studio [22:05:12 CET] <alexpigment> probably with Blu-ray and streaming distribution in mind from early on [22:05:41 CET] <kepstin> sure would be nice if that was the case, wouldn't it? [22:06:00 CET] <alexpigment> kepstin: well, I don't have any reason to think otherwise [22:06:11 CET] <alexpigment> again, maybe you have info that I don't have [22:06:15 CET] Action: kepstin notes that crunchyroll gets interlaced raws for some stuff, and they ocassionally fail to detelecine it correctly. [22:06:53 CET] <alexpigment> that's all anime, right? [22:07:01 CET] <kepstin> yeah [22:07:59 CET] <alexpigment> do they actually film it these days? [22:08:11 CET] <kepstin> anime is normally produced at 24p, with animation traditionally done on 2s (so 12fps), but it's usually edited on - often cheap, previous generation - tv equipment which sometimes doesn't do 24p so you edit on the telecined stuff [22:08:30 CET] <alexpigment> oh you mean analog sourced content [22:08:44 CET] <kepstin> no, even digital [22:08:49 CET] <alexpigment> ah [22:08:59 CET] <alexpigment> well, consider me ignorant on anime tech [22:09:06 CET] <kepstin> nah, hasn't been filmed (aside from some movies) since around the mid-late 2000s. [22:11:16 CET] <alexpigment> anyway, for the sake of steering back to one previous tangent, the breaking bad blu-ray discs are 1080p [22:11:30 CET] <alexpigment> at some point it got IVTC'd [22:11:43 CET] <alexpigment> I would hope that would be during the ingestion phase [22:12:08 CET] <alexpigment> and if not, I guess there are some bad cuts here and there [22:12:12 CET] <kepstin> i wouldn't be surprised if it was done during bd mastering tho :/ [22:12:29 CET] <alexpigment> maybe [22:13:25 CET] <kepstin> not saying that's what happened on this show, but i'm pretty sure that is the case for a decent amount of stuff. [22:19:32 CET] <alexpigment> right, khali was specifically talking about breaking bad; i was just letting him know that the interlaced cameras don't mean that the show was stuck in an interlaced format [22:19:43 CET] <alexpigment> i.e. the masters for the show are probably in 24p [22:32:25 CET] <pos> alexpigment, so that's why BB looks weird [22:32:28 CET] <pos> now i know [22:33:10 CET] <alexpigment> looks like film to me, but ok [22:33:21 CET] <alexpigment> pos: did you watch it in a PAL broadcast? [22:33:25 CET] <pos> on the same tangent: why are walking dead eps so frigginin huge (filesize-wise) compared to others? [22:33:40 CET] <pos> i can't say the quality is that much better [22:33:43 CET] <furq> probably grainy [22:33:54 CET] <pos> any other show: 800-1200mb per 42 mins. wd: 2.1 b [22:34:01 CET] <pos> gb [22:34:14 CET] <alexpigment> pos: you're talking about a lossy secondary encode [22:34:19 CET] <pos> ofc [22:34:25 CET] <alexpigment> whoever encoded them probably also felt it was worth preserving more quality [22:34:30 CET] <alexpigment> but grain plays into that as well [22:34:42 CET] <pos> well, i'm assuming that killers&co know what they're doing [22:34:45 CET] <furq> https://www.dvdtalk.com/reviews/images/reviews/274/full/1377569910_3.jpg [22:34:47 CET] <furq> yeah this is super grainy [22:34:59 CET] <furq> i'm not surprised it's closer to film filesizes [22:37:01 CET] <pos> right, 'cause almost every pixel changes between each frame [22:37:03 CET] <pos> ofc [22:37:29 CET] <furq> also i'm looking at some rips here that are 7-10GB per episode [22:37:42 CET] <furq> Overall bit rate : 29.6 Mbps [22:37:45 CET] <pos> what, 1080p TS? [22:37:53 CET] <furq> 1080 x264 [22:37:56 CET] <alexpigment> furq: that sounds like a blu-ray rip without transcoding [22:37:57 CET] <furq> crf 17 [22:38:03 CET] <furq> they're hdtv rips [22:38:07 CET] <alexpigment> CRF 17 on a grainy source will definitely do it [22:38:32 CET] <furq> well that's 43 minutes [22:38:35 CET] <alexpigment> I use CRF 18 and end up with 2GB+ rips for 30 minute TV shows regularly [22:38:36 CET] <furq> so 9GB is a fair old amount [22:38:52 CET] <alexpigment> then again, my cable company sucks so it's already pretty lossy to begin with [22:38:59 CET] <furq> lol [22:39:30 CET] <furq> even the amazon web-dls of this show are massive [22:39:32 CET] <alexpigment> saying "cable company" and bad quality is almost redundant [22:39:36 CET] <furq> like 4.7GB per episode [22:39:45 CET] <alexpigment> that's good to hear though [22:40:00 CET] <alexpigment> i appreciate that they're not cutting the bitrate too much [22:40:12 CET] <furq> and then ofc there's one scene group doing 480p rips at 330MB per episode [22:40:16 CET] <furq> god bless [22:40:24 CET] <alexpigment> haha [22:40:27 CET] <therage3> lol [22:40:48 CET] <furq> i expect there's one scene group doing 1/2 cd xvid rips [22:40:49 CET] <alexpigment> you gotta help out the people that are still using their modded Xbox for their media center! :) [22:40:55 CET] <furq> but sadly not where i'm looking [22:41:23 CET] <alexpigment> maybe they were aiming at 350MB and just reached saturation.... [22:43:32 CET] <pos> i keep coming across asian/middle eastern repos filled with tertiary encode 350mb files [22:43:42 CET] <pos> bandwith, storage, sharing i guess [22:44:03 CET] <alexpigment> yeah, when you see 350, you know you're deal with people who are still stuck in the "rip for CD" mindset [22:44:17 CET] <pos> ofc, over there they sell CDs with this stuff at market [22:44:28 CET] <alexpigment> yeah, i don't doubt it [22:44:53 CET] <alexpigment> "pardon me. do you have the newest walking dead on VCD?" [22:45:18 CET] <pos> ofc sir [22:45:23 CET] <alexpigment> "oh you have SVCD? I'll have to check that my player can do that" [22:45:45 CET] <pos> would you like a copy of the last jedi too? super quality :) [22:45:59 CET] <alexpigment> "i'll take the best camrip you have!" [22:46:12 CET] <pos> no, this is cinema quality, sir [22:46:28 CET] <alexpigment> :) [22:46:39 CET] <pos> ofc they also sell dvd player able to play xvid :) [22:47:05 CET] <furq> didn't china have its own weird hd disc format [22:47:09 CET] <alexpigment> yeah [22:47:15 CET] <alexpigment> CVD i think [22:47:58 CET] <alexpigment> i think CVD is just SVCD with a really bad horizontal resolution [22:48:03 CET] <pos> well, imagine living on two dollars a day and having gov censorship up the wazoo. ofc the market will thrive [22:48:18 CET] <furq> i think CBHD is the one i'm thinking of [22:48:20 CET] <alexpigment> like VCD horizontal res + SVCD vertical res = CVD [22:48:24 CET] <alexpigment> oh that one [22:48:29 CET] <furq> i'm sure i remember it being successful enough to merit a longer wikipedia entry [22:48:30 CET] <alexpigment> yeah, i don't remember the deal with that one [22:49:16 CET] <furq> CBHD uses the PRC government-owned AVS video codec, DRA audio codec,[4] and a new copy protection system, DKAA, as an alternative to HD DVD's and Blu-ray's AACS. [22:49:42 CET] <furq> http://vpaste.net/S9gz5 [22:49:45 CET] <furq> you know i did that immediately [22:49:48 CET] <alexpigment> i mean normally i would say this is a fail on china's part [22:49:49 CET] <pos> and i'm assuming that they managed to keep the keys under lock and key? :P [22:49:58 CET] <furq> oh i'm sure they did that [22:50:01 CET] <alexpigment> but i'm sure blu-ray licensing is prohibitive [22:50:24 CET] <furq> i really want to see some AVS encoded footage now [22:50:42 CET] <pos> wasn't it chinese manufs ineptitude or lack of caring which lead to the leak of aacs keys? [22:50:57 CET] <alexpigment> pos: i don't know, but that seems very plausible [22:51:35 CET] <pos> and then every other image on digg was bart simpson writing said key on a blackboard while the mpaa was trying to take down half the sites on the inet? [22:51:41 CET] <furq> aacs was cracked through windvd iirc [22:51:51 CET] <furq> the keys were just sitting in memory while a dvd was being played [22:52:22 CET] <furq> i think the bluray keys might have been leaked because of some china hardware though [22:53:01 CET] <furq> i'm pretty sure those early analog capture rips of 4k blurays were done through chinese hdmi boxes that didn't bother with hdcp [22:53:25 CET] <alexpigment> well, there's one company that makes a stripper [22:53:37 CET] <pos> oh, konig hdmi audio splitters don't care either [22:53:39 CET] <alexpigment> whoever makes HDfury [22:53:55 CET] <furq> hdfury is chinese fwiw [22:54:10 CET] <alexpigment> well, I remember it was a big deal when they were forced to take the device off the market [22:54:17 CET] <pos> hdmi in, optical and no-hdcp hdmi out .) [22:54:24 CET] <alexpigment> I don't even have anything 4k, so I don't know how just general splitters work [22:54:35 CET] <furq> dcp tried to sue them and it got dropped because they don't actually strip hdcp, they just downgrade it to a lower (already cracked) version [22:54:40 CET] <furq> which is explicitly allowed by the license [22:54:44 CET] <pos> prolly won't work with 4k/new hdcp though [22:55:04 CET] <alexpigment> yeah, HDCP is really crazy with 4k [22:55:20 CET] <pos> and slysoft got shut down [22:55:26 CET] <furq> it works up to 2.2 apparently [22:55:28 CET] <alexpigment> so much that you have to have specific PC hardware from the last 2 years to even play a 4k Blu-ray [22:55:30 CET] <furq> which i think is the latest? [22:55:43 CET] <pos> still, i'm seeing tons of x265 4k content getting pushed, so it is possible [22:55:56 CET] <furq> i've seen some 4k bluray remuxes [22:56:00 CET] <furq> i'm not sure how that's being done [22:56:34 CET] <alexpigment> let's put it this way, if I'm going to own a 4k Blu-ray, I'll probably just play the 4k Blu-ray for the time being [22:56:48 CET] <alexpigment> those file sizes are going to be huge and compression will take forever [22:57:19 CET] <pos> are they not like bd+? inet connection and auth required for playback? [22:57:39 CET] <alexpigment> what do you mean? [22:57:52 CET] <pos> back when aacs got whacked they launched bd0 [22:57:54 CET] <pos> bd+ [22:57:59 CET] <alexpigment> ah [22:58:08 CET] <pos> your player had to have an inet connection and had to auth each playback [22:58:12 CET] <alexpigment> well they made some attempt at prevent piracy in 2010 [22:58:20 CET] <alexpigment> and there were a lot of new things that players had to do [22:58:24 CET] <alexpigment> no analog outputs [22:58:33 CET] <pos> i was assuming they went all in with 4k [22:58:36 CET] <alexpigment> bd+, bd live, avchd 2.0 [22:59:25 CET] <pos> judging from release logs (and file sizes) the situation hasn't really changed :) [23:00:32 CET] <pos> but i sure as fsck won't be buying a 4k set until i find a not-smart OLED i like [23:00:52 CET] <alexpigment> yeah, i'm still using 2008 samsung TVs that work great [23:00:54 CET] <pos> current LGs are all smart: no way [23:01:10 CET] <alexpigment> i'm trying to figure out when it's a good time to buy a 4k tv [23:01:17 CET] <alexpigment> because now certainly doesn't seem like the right time [23:01:19 CET] <pos> not now [23:01:34 CET] <alexpigment> let's let this HDR thing shake out first at least [23:02:00 CET] <alexpigment> and then whenever OLED gets cheaper or samsung's tech doesn't have any technical downsides [23:02:08 CET] <pos> you get a tv with software/firmware made by an ad agency (scroogle) or it will be lackluster in some other way [23:02:26 CET] <alexpigment> well, I honestly don't trust LG to make a good TV [23:02:34 CET] <alexpigment> but they've got a monopoly on OLEDs right now [23:02:34 CET] <pos> oh, they make great panels [23:02:40 CET] <pos> the software though... [23:02:43 CET] <alexpigment> right [23:02:51 CET] <alexpigment> when I say a "good tv" i mean the whole package [23:02:55 CET] <pos> well, the sony oled (with lg panel) is sweeet [23:03:04 CET] <alexpigment> yeah, i've heard that [23:03:06 CET] <pos> but is is huge bc of the integrated speaker/woofer [23:03:19 CET] <pos> and ofc: android tv [23:03:21 CET] <pos> no thanks [23:03:48 CET] <pos> present me with an OLED signage (non-smart) display: take my money [23:03:51 CET] <alexpigment> pos: i think you'll just have to accept that all modern TVs are "smart" and their smart components will become obsolete at some point [23:04:04 CET] <pos> no, "signage" is becoming a think [23:04:08 CET] <pos> thing [23:04:20 CET] <pos> finally [23:04:33 CET] <alexpigment> yeah, that's a possibility, but I assume there are some downsides with signage TVs [23:04:42 CET] <khali> thank everybody again for the help, especially alex, I'll go to bed now [23:04:44 CET] <alexpigment> like lack of certain processing modes or perhaps ports [23:04:50 CET] <pos> great panels, great expected lifetime, no smart features [23:04:56 CET] <alexpigment> khali: cool, have a good nice [23:05:59 CET] <pos> yeah, LG has close to a monopoly on OLED. and samsung is pushing this weird quantum dot LCD fairytale. they still can't show a proper red [23:06:22 CET] <pos> not a single samsung (lcd) set i've seen since 2008 can show a proper red [23:06:28 CET] <pos> always orange/pinky [23:07:01 CET] <pos> ofc it didn't help that the store put a pioneer next to the samsungs ofc [23:07:15 CET] <pos> "how do you like them apples" [23:09:25 CET] <pos> i don't get why they did it though. that's like putting a veyron in a datsun store. ofc everyone is going home "to think about it" [23:12:02 CET] <pos> ever tried out those high-end lg OLEDs? the remote functions as a mouse pointer for the menus [23:12:17 CET] <pos> gawd, that is awful to use [23:12:55 CET] <pos> it's like using a laser pointer for a mouse [23:13:49 CET] <furq> actually i'm one of the three people who really enjoyed navigating menus on the wii [23:15:38 CET] <alexpigment> furq: yeah, you're weird ;) [23:16:14 CET] <alexpigment> pos: i'm very much in your camp of having simplified things. when harmony stopped having physical number buttons on their remotes, consider me done as a customer [23:16:31 CET] <alexpigment> and i'm not going to use my phone as a remote like an idiot [23:16:40 CET] <alexpigment> just give me some physical buttons and we're good [23:18:56 CET] <pos> agreed [23:20:00 CET] <pos> i had ten minutes to kill the other day, went to a best-buy kinda store and was asking about the killer OLED. i wanted to make sure it could be used without an internet connection [23:20:13 CET] <therage3> lol, good luck with _that_ [23:20:26 CET] <pos> turns out: it can't [23:20:30 CET] <therage3> exactly [23:20:36 CET] <pos> it can play media from usb: the other stuff? nope [23:21:34 CET] <alexpigment> i'd really just appreciate if all TVs didn't come with horrible default settings [23:21:56 CET] <alexpigment> motion smoothing off, sharpening off, overscan off, edge enhancement off, noise reduction off, etc [23:22:15 CET] <alexpigment> (i mean i'd like all those things off, to be clear) [23:25:21 CET] <therage3> so I just managed to downscale these 24-bit FLAC's to 16-bit WAVs successfully with what was suggested here before [23:25:44 CET] <therage3> managed to burn a CD just fine, with CD-Text and all [23:26:02 CET] <alexpigment> nice [23:26:27 CET] <alexpigment> i used to have to do that for certain DVDs so they would play on XBMC [23:26:43 CET] <therage3> i see [23:26:44 CET] <alexpigment> they figured out 24bit support at some point later I guess [23:27:15 CET] <alexpigment> ok guys, I'm heading out. see you all later [23:27:20 CET] <therage3> see you [23:57:05 CET] <spacerabbit> is there tools on windows to stream transcoded media from my nas on demand and use the GPU acceleration. (other than plex) [00:00:00 CET] --- Fri Dec 22 2017

1 0