From burek021 at gmail.com Fri Jul 1 02:05:01 2016 From: burek021 at gmail.com (burek) Date: Fri, 1 Jul 2016 02:05:01 +0200 (CEST) Subject: [Ffmpeg-devel-irc] ffmpeg.log.20160630 Message-ID: <20160701000502.0C15C2AD6004@apolo.teamnet.rs> [00:31:16 CEST] Hello, I�m recording the screen in my macbook, but it says that yuv420p is not supported by the device. How can I list the modes supported. And is ever going to be supported? [00:32:21 CEST] Can you pastebin the actual error? [00:32:34 CEST] Including your command-line and everything ffmpeg displays? [00:32:47 CEST] ok, wait [00:37:45 CEST] Mavrik: http://pastebin.com/BBEmMCU5 [00:38:34 CEST] the list of supported modes is shown right beneath that error [00:38:38 CEST] Well, it's telling you that your INPUT device (avfoundation) doesn't support that pixel format. [00:38:40 CEST] or that warning, rather [00:38:47 CEST] So you should really ask Apple :P [00:38:59 CEST] But that's usually not a problem, what kind of problem are you really having? [00:39:04 CEST] you probably just want to specify -pix_fmt yuv420p as an output option [00:39:20 CEST] i can't imagine any other reason why it'd be an issue [00:39:29 CEST] furq, yes that works, I thought it was a ffmpeg problem [00:39:39 CEST] It's not a problem at all. [00:39:42 CEST] You input is in one pixel format. [00:39:45 CEST] Your video is in another. [00:39:58 CEST] It's how things are :) [00:40:08 CEST] I wont affect the quality of the output? [00:40:14 CEST] no [00:40:18 CEST] It will. [00:40:26 CEST] uyvy422 is higher quality than yuv420p [00:41:02 CEST] You're grabbing RGB screen into a video format that only does yuv420p on most devices. [00:41:09 CEST] You're losing color accuracy in that conversion somewhere. [00:41:18 CEST] But there's nothing you can do about it if you want to keep your video compatible. [00:41:48 CEST] It's a limitation of most H.264 video players. [00:42:01 CEST] it might make more sense to capture in nv12 since that's probably less work for swscale [00:42:08 CEST] it's not going to make a big difference though [00:43:14 CEST] ok thx guys =) [00:43:41 CEST] you will definitely want to specify the output pixel format though [00:43:57 CEST] if compatibility is an issue then use yuv420p [00:46:35 CEST] Does ffmpeg have mp4 version 2 as a container? [00:57:04 CEST] i'm pretty sure it only has version 2 [00:57:10 CEST] hi! I'm extracting a keyframe from a flv stream with something like: ./extract_keyframe | ffmpeg -i - ....., but sometimes it takes too long and I was wondering if I can timeout ffmpeg somehow? [01:14:40 CEST] roxlu: what about writing something that times out, and pipes stdin to stdout, and then doing ./extract_keyframe | timeout-pipe-prog | ffmpeg -i - ... ? [01:57:13 CEST] hello. I see that hdcd filter was added in 3.1, but there is no documentation. how is it used? [02:01:19 CEST] -i 16bit.wav -af hdcd 20bit.wav [02:03:11 CEST] hmm, I tried that but the output was still 16bit [02:06:03 CEST] using HDCD16.flac from https://trac.ffmpeg.org/ticket/4441#no1 ... [02:06:27 CEST] I tried ./ffmpeg -i HDCD16.flac -af hdcd -o OUT.wav [02:06:56 CEST] and OUT.wav was nearly identical to the original, but about 30 bytes longer [02:07:23 CEST] *identical to the original after flac -d [02:13:27 CEST] ffprobe OUT.wav --- Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, 2 channels, s16, 1411 kb/s [02:34:00 CEST] It looks like Chrome uses FFmpeg in some capacity. Does it use FFmpeg for its primary video decoding? [04:02:06 CEST] hey guys.. question anyone know this error : Unsupported data layout: yuvj420p .. [04:02:11 CEST] do i have to set somethign on the input to get around this ? [04:02:14 CEST] vdpau is complaining [04:02:26 CEST] pastebin the command and output [04:08:50 CEST] figured it out... thanx to turik ... can't use vdpau [04:53:02 CEST] anyone know of a batch script progress bar for ffmpeg? [04:53:34 CEST] not the default one that is, something simpler [04:54:02 CEST] I've seen progress bars for other things but I'm not sure how it would be integrated with ffmpeg [05:46:07 CEST] I am trying to grab a window using "ffmpeg -f gdigrab -framerate 30 -i title="Quake 3: Arena" -s 1280x720 -c:v libx264 -b:v 4M -pix_fmt yuv420p -preset ultrafast http://locahost:8084/feed1.ffm" [05:46:25 CEST] But I get only white empty frames. [05:47:52 CEST] But I tried grabbing the window of calculator application. It works. Doesn't work with the game. Any help ? [05:50:22 CEST] Any help, please ? [05:53:07 CEST] i doubt gdigrab will work with opengl windows [05:53:09 CEST] Anyone online, ? [05:55:34 CEST] doesn't ioquake3 support exporting demos to avi [05:55:39 CEST] that's probably the easiest way to do it [05:57:20 CEST] I tried outputting it to an mp4 file also. But still white frames. [05:57:33 CEST] oh wait are you trying to live stream this [05:57:35 CEST] Is this a problem with gdigrab itself ? [05:57:45 CEST] no, with your graphics card driver [05:57:54 CEST] like i said, i doubt it works with opengl or dshow [05:57:55 CEST] it's just not returning the picture with that api [05:58:00 CEST] er [05:58:06 CEST] i doubt gdigrab or dshow will work with opengl [05:58:24 CEST] i know x11grab doesn't work with opengl on linux [05:58:44 CEST] But I am able to grab the window of the calculator application. [05:58:45 CEST] hmm? last I checked, it x11grab can do opengl on linux [05:58:55 CEST] the calculator isn't using opengl [05:59:00 CEST] unless microsoft have actually gone insane [05:59:13 CEST] i assume OBS supports this [05:59:23 CEST] and you shouldn't be using ffserver anyway because it's unsupported garbage [06:00:55 CEST] I am quite naive on all this. So ffmpeg tries to get the frames from opengl but opengl on windows doesn't have an API to return those frames ? [06:00:58 CEST] kepstin: doesn't opengl normally bypass x11 entirely [06:01:19 CEST] furq: not if you're using a desktop compositor [06:01:37 CEST] I guess people who are using a classic wm might have issues capturing games tho [06:01:54 CEST] oh [06:01:59 CEST] it's been years since i used desktop linux [06:02:18 CEST] HokarPokar: the way gdigrab works is it asks windows, via an old api that's been around for many years "please give me a picture of the screen" - it's then up to windows and your graphics driver to do it [06:02:45 CEST] HokarPokar: if your graphics driver doesn't return a picture for some window, well, nothing we can do [06:03:02 CEST] if you want to live stream quake then you probably want OBS and an rtmp server [06:03:11 CEST] kepstin: Thanks. [06:03:14 CEST] yeah, gdigrab is slow [06:03:35 CEST] if you don't care about livestreaming then just record a demo and have ioquake3 render it to a video [06:03:46 CEST] i remember that working quite well [06:04:00 CEST] that said, you're using the window select mode - sometimes games do weird things with windows, so it's picking the wrong one. You can try doing a screen capture instead. [06:05:16 CEST] Can anyone help me with FFMPEG video conversion [06:08:41 CEST] kepstin: I will try once with dshow. But it throws the error Unknown input format dshow. So dshow isn't supported [06:08:41 CEST] join #worldchat [06:09:43 CEST] HokarPokar: try using 'desktop' instead of the window name with gdigrab, see if that works. But yeah, you probably want to use obs for this. [06:12:22 CEST] kepstin: That works. But as you said, it grabs the entire desktop instead of a specific window. [06:12:49 CEST] yeah, so it's probably just an issue where the game has multiple windows and the selection is picking the wrong one [06:24:40 CEST] maybe ioquake3's video recording isn't as good as i remembered [06:24:56 CEST] it splits the video every 2GB, which is roughly every five seconds at 1080p60 [06:25:37 CEST] it also does not play back very well when it's trying to write 400MB/sec to a hard disk [06:26:30 CEST] does anyone know the practical difference between yuv420p and nv12? [06:27:08 CEST] nv12 is planar y and interleaved uv [06:27:16 CEST] yuv420p is fully planar [06:27:38 CEST] other than that they're identical [06:33:49 CEST] is there any reason to use one over the other? [06:34:20 CEST] use whichever is supported [06:35:11 CEST] if you've got nv12 coming from a capture device then most codecs will transform it to yuv420p anyway [06:35:29 CEST] oh okay. I'll stick to yuv420p then [06:35:51 CEST] planar is generally better than packed (or half-packed) [06:36:00 CEST] also, do you have any recommendations on lossless screen-record codecs? I'm currently using utvideo [06:36:13 CEST] not really [06:36:19 CEST] ffv1 seems good but i've never used it for rgb [06:36:38 CEST] ffv1 encodes too slowly for me to screenrecord. I use it for other things [06:37:09 CEST] although when I say "lossless" I'm okay with using swscale. I just don't want to quantize [10:10:35 CEST] Hello! [10:11:15 CEST] Is it possible to set output format context options with av_opt_set_dict()? [10:16:58 CEST] have lot of videos which needs to be transcoded to multiple profiles currently using ffmpeg with some scripts, anyone can point me for a transcoding cluster [10:18:27 CEST] Maybe someone who have some experience in Distributed Multi-bitrate Video Transcoding [10:30:39 CEST] For some reason av_set_options_string() works all right, but av_opt_set_dict() don't. [13:44:23 CEST] Hello! [13:51:22 CEST] Any ides about av_opt_set_dict()? [13:51:30 CEST] ideas [14:00:35 CEST] hi, I'm wondering: when I download 32/64 bits libraries for windows, do I need to install external libs as well? [14:00:49 CEST] (I never developped on windows so no clue about how it works) [14:13:16 CEST] imperio_, if you're about Zeranoe FFMpeg Builds, then no, you don't need. [14:13:45 CEST] imperio_, Zeranoe FFMpeg Builds are statically linked. [14:16:17 CEST] yagiza: even in DLLs? [14:16:32 CEST] imperio_, yes [14:16:40 CEST] damn, such a relief! [14:16:45 CEST] thanks yagiza :) [14:16:57 CEST] imperio_, you're welcome [18:18:03 CEST] is there anything worth reading for h264 encodings using ffmpeg? [18:18:14 CEST] besides the basic wiki here https://trac.ffmpeg.org/wiki/Encode/H.264 [18:19:05 CEST] are there options worth adding outside the presets if I need a high quality encode optimized for still moving scenes? [18:47:02 CEST] hello can anyone have lastet ffmpeg with libaac ? [18:47:06 CEST] for windows [18:47:23 CEST] if you mean fdk-aac then no [18:47:30 CEST] builds with fdk aren't distributable [18:49:08 CEST] in windows is possible to add .dll library on the same dir? [18:57:13 CEST] HSKW, yes, it is [18:58:05 CEST] how do i encode something into g726 [18:58:14 CEST] ok what difference libfaac and libfdk [18:58:15 CEST] ? [18:58:59 CEST] fdk-aac is much better [18:59:07 CEST] although now for LC-AAC you don't need external libraries [18:59:09 CEST] agrecascino, what's the problem? Just use g726 as output audio codec. [18:59:14 CEST] nvm [18:59:15 CEST] got it [18:59:20 CEST] you only need fdk-aac for HE-AAC [18:59:36 CEST] also [18:59:42 CEST] actually [18:59:42 CEST] wait [18:59:43 CEST] nvm [19:06:26 CEST] i've installed libfdk-aac-1.dll [19:06:37 CEST] right? [19:06:51 CEST] it won't make a thing that doesn't have it linked work [19:07:00 CEST] do you need HE-AAC? [19:07:02 CEST] as in, encoding [19:07:07 CEST] yes [19:07:08 CEST] or do you just want to encode LC-AAC [19:07:28 CEST] ok, if you need HE-AAC encoding, then build it yourself [19:07:32 CEST] no other alternative [19:09:37 CEST] i need for RTMP... i dont know if is better LC or HE in this case [19:14:11 CEST] HSKW: if you are planning to go under 64kbps for stereo then it's HE-AAC [19:14:22 CEST] otherwise I would pick LC-AAC [19:14:45 CEST] and in that case you would be fine with the internal aac encoder which was vastly improved by atomnuker [19:17:33 CEST] LC-AAC is the libfdk-aac-1.dll that i 've downloaded, right? [19:18:08 CEST] no [19:18:12 CEST] they are profiles of AAC [19:18:35 CEST] HE is the one that rapes more but enables you to get a somewhat listenable result at <64kbps for stereo [19:19:06 CEST] LC is the one that leaves the sound in a somewhat better state but doesn't compress as well (thus >=64kbps is my random arbitrary number for its usage) [19:19:39 CEST] a good LC-AAC encoder is already included in FFmpeg itself so if you are going to use that, you don't need fdk-aac or anything else [19:19:44 CEST] you just need a recent enough FFmpeg [19:20:37 CEST] Ok, but what is it this libfdk ? LC or HE? [19:20:55 CEST] i see in a lot of example use this codec [19:21:29 CEST] that's because it is the best third party library encoder and that's because the internal one wasn't good enough until like october (?) last year [19:21:36 CEST] so of course you will have it mentioned in examples [19:21:45 CEST] libfdk-aac supports both LC-AAC and HE-AAC encoding [19:23:56 CEST] ah ok,, many thanks.. i use ffmpeg-20160629-57d30fd-win64-static [19:24:54 CEST] well how i can trascode in h264 700K and audio lc aac 96K, res 640x360 and send it to rtmp server? i dont know how to set the command line [19:25:14 CEST] the input is from here: udp://@127.0.0.1:8888 [19:30:15 CEST] http://ffmpeg.org/ffmpeg-utils.html#time-duration-syntax [19:30:36 CEST] it says here negative values are permitted yet it gives me errors when using the -ss -to format [19:31:00 CEST] eg: -ss 00:00:00.00 -to -11 [19:31:27 CEST] I would expect it truncate from the beginning to 11s before the end [20:19:32 CEST] the wiki on seeking is a bit misleading [20:19:52 CEST] howso? [20:19:56 CEST] feel free to edit it [20:20:03 CEST] using -ss before -i results in very inaccurate timings [20:20:23 CEST] whereas placing -ss and -to after -i result in accurate timings [20:20:31 CEST] that can be expected depending on the input format and stuff n' junk [20:21:07 CEST] Spring: before -i works on the container level, after -i works on the stream level [20:21:21 CEST] but is much slower as the stream has to be decoded [20:21:35 CEST] I think [20:22:06 CEST] <__jack__> "As of FFmpeg 2.1, when transcoding with ffmpeg (i.e. not just stream copying), -ss is now also "frame-accurate" even when used as an input option" [20:22:20 CEST] <__jack__> (ffmpeg -ss .. -i ..) [20:23:03 CEST] that's what wasn't clear [20:23:17 CEST] it makes it sound as though it's frame accurate [20:23:35 CEST] <__jack__> is not it ? [20:23:59 CEST] -ss before -i is on demuxer level - it cannot be frame-accurate with formats where there are non-IRAP packets [20:24:19 CEST] -ss after -i is on decoder level where all you have are decoded raw video and audio [20:24:28 CEST] thus it can be fully frame-accurate in theory [20:24:37 CEST] <__jack__> JEEB: so, the wiki is wrong ? [20:25:29 CEST] in one test the end was set to 00:00:14.559 but it actually ended closer to 00:00:17.528 [20:25:44 CEST] using the -ss prior to -i syntax [20:26:07 CEST] reminds me of trimming via AviDemux [20:26:07 CEST] __jack__: no idea what got fixed, but it is as accurate as something can be on the container level [20:26:13 CEST] <__jack__> (tested it, it seems wrong) [20:26:49 CEST] basically if you set a value that is after an IRAP it will go for the next one I think? [20:27:07 CEST] because cutting on a non-IRAP makes no sense on container level [20:27:20 CEST] <__jack__> what's IRAP ? [20:27:26 CEST] Intra Random Access Picture [20:27:35 CEST] aka something you can start decoding from [20:27:41 CEST] <__jack__> I frame at the container level ? [20:28:07 CEST] it is an I frame but additional limitations because you can't have references after it towards things before it [20:28:26 CEST] also container level means that it has access to the encoded data but it doesn't decode [20:28:35 CEST] so it can parse which packet is an IRAP and which is not [20:29:12 CEST] just I frame means a picture that is full intra, but it doesn't promise you that you can decode what comes after it without pictures that came before that I picture [20:29:32 CEST] so basically the double quotes around "frame-accurate" in the wiki are very much intentional :p [20:30:01 CEST] possibly -ss before -i was broken before, and now it should work as well as the demuxer works for a given format or so [20:31:20 CEST] basically -ss before -i works with -c copy - after -i just won't work because nothing is decoded [20:44:46 CEST] on the -threads option, is it correct that specifying 8 threads is right for 2 cores, while 16 for 4 cores? [20:47:05 CEST] no, normally you would specify the number of cores (2 or 4) directly. maybe double for hyperthreading [20:47:49 CEST] I see. There doesn't seem to be a wiki page about it and various posters around the net have differing results [20:48:19 CEST] it depends on the encoder or decoder [20:48:45 CEST] for example, libx264 will automatically choose an appropriate value, so you don't need to use that option [20:49:09 CEST] any idea about libvpx? [20:50:03 CEST] libvpx can't use 16 threads unless you're encoding 4k [20:50:40 CEST] i don't use that encoder but guess it is auto as well: "ffmpeg -h encoder=libvpx" shows "Threading capabilities: auto" [20:51:42 CEST] saw one stackexchange poster mention it can be automatic but it doesn't necessarily utilize all the cores [20:51:58 CEST] yeah it uses slice-based multithreading [20:52:13 CEST] the maximum number of threads it can use is floor(width / 256) [20:52:46 CEST] i think there's also some other option you need to set correctly, maybe tile-columns [20:54:20 CEST] searching for tile-columns brought me to this https://github.com/Kagami/webm.py/wiki/Notes-on-encoding-settings [20:54:47 CEST] which mentions it can't auto detect the number of threads on a system so it has to be manually raised [20:54:54 CEST] that looks right [20:55:33 CEST] bit confusing tbh. Is there some calculation for the right number of threads per core? Want to be able to tell users what they should set. [20:56:05 CEST] not that i know of [20:56:13 CEST] you'll rarely be able to use more than 7 threads anyway [20:56:56 CEST] if more are set via the option but the system doesn't support it will it throw an error or just use the max supported number? [20:57:03 CEST] it'll just use as many as it can [20:57:20 CEST] okay, I'll prob just set a max number like 8 [20:58:21 CEST] http://permalink.gmane.org/gmane.comp.multimedia.webm.devel/2339 [20:58:26 CEST] i'm not sure if that's still accurate [21:03:08 CEST] from that github page "if your source is mostly static, you will have only one keyframe for the entire video" [21:03:55 CEST] so if I had say a video of a fixed camera and mostly still scene it would only add a single keyframe? [21:09:41 CEST] looks like there was a discussion on this on gmane.org [21:59:47 CEST] JEEB: ffmpeg -i udp://@127.0.0.1:8888 -c:a libfdk_aac -b:a 96k -c:v libx264 -b:v 785K -f flv rtmp:// [22:00:01 CEST] on audio codec what i must use? [22:51:04 CEST] So this is strange. I'm encoding a test clip with different settings and comparing the results in Photoshop, when I notice the identical frame I'd copied from the media player minutes before has changed. [22:51:47 CEST] I then notice /all/ frame captures have become identical when previously they displayed differences [22:52:05 CEST] that is, when copying (or saving as PNG) the same frames again [22:52:54 CEST] that is strange [22:53:03 CEST] unless you've overwritten the old frames, in which case it is not strange [22:54:05 CEST] no, they're all different layers and locked as soon as they're placed. I can't even get the same frame from the same video. What's an easy and accurate way to extract a frame? [22:55:23 CEST] ffmpeg -i foo -ss 12.34 -frames:v 1 bar.png [22:56:15 CEST] or `ffmpeg -i foo -vf select=eq(n\,1234) -frames:v 1 bar.png` if you want a specific frame number [23:15:29 CEST] thanks [23:21:08 CEST] Good. It must have just been an anomaly with the video player I was using (PotPlayer). [23:21:19 CEST] ffmpeg outputs the same result as I had initially. [23:23:20 CEST] Solved the mystery. Somehow must have toggled PotPlayer's denoise filter while Ctrl+C'ing. *facepalm* [23:45:20 CEST] Error while decoding stream #0:1: Invalid data found when processing input [00:00:00 CEST] --- Fri Jul 1 2016 From burek021 at gmail.com Fri Jul 1 02:05:03 2016 From: burek021 at gmail.com (burek) Date: Fri, 1 Jul 2016 02:05:03 +0200 (CEST) Subject: [Ffmpeg-devel-irc] ffmpeg-devel.log.20160630 Message-ID: <20160701000503.45C652AD6006@apolo.teamnet.rs> [00:34:41 CEST] The one in AVFrame is also an ABI break. hw_frames_ctx was added in the middle of non-private fields. [00:34:50 CEST] So that needs to be fixed for 3.1.1 as well. [00:34:52 CEST] how can I continue fate so that I can see all the tests which fails and not just the one which does [00:34:56 CEST] all fields below it are documented as no direct access BtbN [00:35:03 CEST] ie. you are supposed to use getters [00:35:11 CEST] Illya: make -k or make -i [00:35:17 CEST] (keep going, or ignore errors) [00:35:30 CEST] thanks :) [00:35:41 CEST] Ah. Well, that makes fixing it easier at least. Or is the position of hw_frames_ctx fixed ABI now? [00:35:58 CEST] imho there is nothing to fix [00:36:02 CEST] see ML, there is a thread about it [00:37:08 CEST] BtbN: hw_frames_ctx is public/fixed, yes. it was added right above the first private field, so no breakage [00:37:42 CEST] Well, as while we're at it, might as well move it to prevent too much of a mess here. [00:37:55 CEST] And then work on a way to prevent easy access to private fields. [00:38:26 CEST] breaking ABI of public fields between 3.1 and 3.1.1 to fix usage in "broken" client apps seems less then ideal to me [00:39:10 CEST] BtbN: what nevcairiel said, moving it would /be/ an abi break [00:40:24 CEST] 3.1 is kind of "burned" for now, so we can as well pretent it never happend and go straight to 3.1.1 [00:42:17 CEST] we have done such changes before, very often, and it was never a huge drama topic [00:42:25 CEST] i still dont get whats with everyone this time [00:42:39 CEST] one guy that complains on trac and suddenly everyone is going crazy? :) [00:43:31 CEST] two versions back when we still kept libav compat, it was the *only* way to add fields in between public and (semi-)private to keep compat with libav, and that never caused these discussions [00:44:00 CEST] Well, it breaks a lot of stuff, and is easy to avoid. [00:44:11 CEST] any fixes are rather ugly [00:44:19 CEST] but that doesnt answer the question [00:44:24 CEST] why is this a topic now? [00:45:01 CEST] Primarily because of the one actual public ABI break, that didn't realy matter for anything. [00:50:01 CEST] ffmpeg broke its own ABI without bumping major version. [00:50:09 CEST] that's the problem. [00:50:22 CEST] the documented public ABI is not broken [00:50:27 CEST] apps just use private parts of it [00:50:42 CEST] nobody used the avfilter field, the only abi breakage [00:50:54 CEST] the rest is library users not bothering to read the field's doxy [00:51:16 CEST] any field that is in installed header is public, despite what the comment says. [00:51:31 CEST] unfortunately. [00:51:34 CEST] nope :) [00:51:42 CEST] and if you use it, then its your breakage, not ours [00:51:53 CEST] its not like thats a new concept [00:51:56 CEST] we've had that for years [00:52:13 CEST] and that private part of the ABI has also changed often [00:52:32 CEST] I still prefer breaking less things if possible, even if they misuse the API. And then making sure misuse becomes harder/impossible in the future. [00:52:35 CEST] but we're looking to get rid of it now so we dont have to discuss about this ever again [00:53:09 CEST] The fixup should be done during a major bump, even if it technically wouldn't break public ABI. [00:53:24 CEST] well, if you ask me, all structs should be private and fields should be accessed with AVOptions [00:53:32 CEST] yes, we're getting rid of all the private crap in the next major bump [00:55:41 CEST] what's the procedure for deprecating a demuxer? [00:55:58 CEST] there isnt one [00:56:18 CEST] you can make it output a log message or something [01:56:03 CEST] michaelni: just a note on the your commit for the web regarding 3.0->3.1, it's 'recommendation' not 'recommandition' :) [05:02:15 CEST] ffmpeg 03Timo Rothenpieler 07release/3.0:bffe1c42220f: ffplay: Fix usage of private lavfi API [09:45:09 CEST] ffmpeg 03Benoit Fouet 07master:3e8cda1eb1a8: h264_ps: change decode_scaling_matrices so that it takes const {s,p}ps [09:45:10 CEST] ffmpeg 03Benoit Fouet 07master:4cc1ce4a9178: h264: straighten dimensions check ff_h264_decode_seq_parameter_set [09:45:11 CEST] ffmpeg 03Benoit Fouet 07master:879330c561f4: h264: make H264ParamSets sps const [10:12:15 CEST] michaelni: do you have samples for c40f51e15? [10:22:18 CEST] i'm pushing a merge commit affecting this; Anton is reworking the mmco stuff, so i'm sticking to his code [10:26:32 CEST] ffmpeg 03Anton Khirnov 07master:2d410ebbaa1e: h264: decode the MMCOs into per-slice contexts [10:26:33 CEST] ffmpeg 03Anton Khirnov 07master:bec993381cfe: h264: postpone generating the implicit MMCOs [10:26:34 CEST] ffmpeg 03Cl�ment BSsch 07master:d407e76c42d5: Merge commit '2d410ebbaa1e760d6837cb434a6d1d4c3c6f0d85' [10:26:35 CEST] ffmpeg 03Cl�ment BSsch 07master:f48aea66ddfe: Merge commit 'bec993381cfec72051b0d9f12ac9d9bb9c750983' [11:38:05 CEST] ffmpeg 03Michael Niedermayer 07release/3.1:3e730278f5a8: avformat/mov: Check sample size [12:35:04 CEST] what does the -mp suffix do in yasm (e.g. as in r5mp)? [12:36:14 CEST] its a pointer to the original location of that parameter, on stack if applicable [12:36:31 CEST] handy [12:36:40 CEST] so you can reference parameters without loading them in regs [12:36:48 CEST] or loading them manually later [12:37:14 CEST] the latest merge is causing me trouble :( [12:37:16 CEST] (https://github.com/ubitux/FFmpeg/compare/merge-libav) [15:09:03 CEST] heh we already have an AVStreamInternal [15:09:15 CEST] but many private fields aren't in [15:34:53 CEST] nevcairiel: https://github.com/xbmc/xbmc/pull/10043 <- as you asked on the ML, this is all we found for now [15:36:39 CEST] ubitux: reminds me of https://www.mail-archive.com/ffmpeg-cvslog at ffmpeg.org/msg17337.html [15:37:51 CEST] ffmpeg 03Vadim Kalinsky 07master:e370aad67ddb: avformat/mov: Skip non-key frames if AVDISCARD_NONKEY is set. [15:37:52 CEST] ffmpeg 03Dan Parrot 07master:1df908f33f65: PPC64: Add versions of functions in libswscale/input.c optimized for POWER8 VSX SIMD. [15:37:53 CEST] ffmpeg 03Martin Vignali 07master:d9e1e0813323: libavcodec/exr : fix decoding piz float file. [15:38:57 CEST] what am i reading [15:40:43 CEST] ffserver really badly uses internal APIs, worse its probably not even that hard to fix if someone did sit down and had the will to fix the API use [15:41:25 CEST] but then i dont know the code well enugh and might be wrong [15:43:20 CEST] we gave a warning to drop ffserver [15:43:28 CEST] the timebomb is on [15:43:43 CEST] like, next time we bump major or so [15:43:50 CEST] if ffserver is not fixed by then, we drop it [15:43:57 CEST] i don't remember the mail about that [15:45:23 CEST] maybe we should remind the maintainer about that [15:46:38 CEST] did we announce the intent of droping ffserver on twitter/facebook ? [15:46:59 CEST] might wake someone up who cares to fix it properly [15:52:39 CEST] if the message hasn't been received, maybe it's time yes [15:52:54 CEST] maybe also announce it on the front page, if it's not the case ? [16:02:01 CEST] I think we should push something to master immediately that disables ffserver unless it's explicitly enabled. [16:02:18 CEST] Like, enabled ffsever || disable ffserver [16:04:28 CEST] and print a warning at configure and runtime "this tool is not maintained, if you care about it, come maintain it" [16:04:44 CEST] or maybe just a warning at runtime should be enough [16:06:10 CEST] yeah, I'd agree with that, disable by default and print a warning saying it'll be dropped unless it's fixed [16:07:07 CEST] i think this is a good idea as well [16:09:35 CEST] damn it seems we have like 40 fields that belongs in the internal field [16:10:01 CEST] maybe the "options" fields should be considered public though? [16:10:21 CEST] (if any) [16:21:17 CEST] michaelni: so & regarding the 3.1 update [16:21:28 CEST] michaelni: a slightly more extreme position could be that we should unrelease 3.1 [16:21:44 CEST] if you really believe that 3.1 broke ABI, then we should revoke the release [16:22:36 CEST] that seems a bit extreem as an alteranative to move 2 fields in s struct [16:23:06 CEST] at least its deterministic [16:23:13 CEST] moving those two fields are an actual ABI break [16:23:36 CEST] if you want to move the newly added libav-specific field down to the end of the struct& [16:23:49 CEST] then revoking 3.1 and re-releasing with that fix as 3.1.1 or 3.2 seems appropriate [16:24:01 CEST] (and then marking the whole struct as public except for AVStreamInternal) [16:24:16 CEST] what exactly do you mean by revoking ? [16:24:29 CEST] deleting it, telling users to revert to 3.0 if they updated, etc. [16:24:36 CEST] and i dont think we want to mark the whole struct as ublic [16:24:43 CEST] discouraging the usage of 3.1 and such in favor of 3.1.1 [16:25:01 CEST] " discouraging the usage of 3.1 and such in favor of 3.1.1" <-- yes of course [16:25:09 CEST] the struct is essentially public [16:25:26 CEST] if you say 3.1 broke 3.0 abi [16:25:34 CEST] then by definition, the fields were part of the abi [16:25:41 CEST] so they are already public [16:25:43 CEST] We should make sure even the private ABI matches in 3.1.1 then, so, applying the other two patches. That's the only way to make sure stuff doesn't explode, even though it is technically all private. [16:25:44 CEST] the documentation is just broken [16:25:59 CEST] you can remove their public status by moving them to AVStreamInternal in the next major bump [16:26:08 CEST] BBB: no, people simply misused it [16:26:20 CEST] yes, in the next major bumps those fields should all vanish from public headers. [16:26:22 CEST] but were suggesting to keep the misused code working [16:26:33 CEST] But for now preventing a stuff from exploding seems more important to me. [16:26:34 CEST] so that means that in practice, they are part of public abi in this major series [16:27:00 CEST] so documentating them as public, treating them as such, and then marking their public status as deprecated by moving them to internal in next major bump seems appropriate? [16:27:14 CEST] yes, seems fine to me [16:27:21 CEST] that at least formalizes the path forward and allows the compiler to give warnings now and errors in the future [16:27:30 CEST] the document-as-private-in-public-header is not practical [16:27:47 CEST] I completely agree with that, which is why I'm very much for keeping stuff working. [16:27:49 CEST] i dont want to cause our user pain, if we tell them "this is public" just to remove it next that would cause pain [16:27:59 CEST] but it's been done for years. and people seemed to use them properly [16:28:08 CEST] Well, "this is public and deprecated, do something" seems ok for me. [16:28:10 CEST] until now when we realize they didn't, at least with avframe [16:28:59 CEST] Would need some macro, so it doesn't throw deprecation warning all across libav* code, but that should be doable [16:29:33 CEST] btw I bought a new laptop and I believe I finally have a machine supporting avx2 now [16:29:38 CEST] so I can start writing avx2 assembly [16:29:44 CEST] nice! [16:29:54 CEST] Im only 4 years late to the party [16:30:07 CEST] maybe Ill start the 16x16 vp9 idct or so [16:30:47 CEST] loopfilter would be fun also [16:30:56 CEST] although & complicated :) [16:31:03 CEST] It also seems bad to me that updating ffmpeg breaks a lot of stuff. The blame will come to ffmpeg, not the applications. [16:31:50 CEST] so & it seems the agreement is that: [16:32:09 CEST] BBB, about marking the fields public, i think fields not used by anyone and marked private should stay marked as private [16:32:13 CEST] 1) we should (As michaelni suggested) not recommend people to update to 3.1, and in addition recommend that people do _not_ upgrade to 3.1 in anticipation of 3.1.1 or 3.2 [16:32:34 CEST] 2) mark these fields as deprecated and move them to AVStreamInternal on next major bump [16:33:06 CEST] (or move them to the public portion on next major bump) [16:33:17 CEST] (whichever applies depending on whether they should be public or not) [16:33:44 CEST] which fields as deprecated? [16:33:45 CEST] 3) move libav-added field to bottom of struct so 3.0 abi applies to private portion of structs in a to-be-made 3.1.1 or 3.2 release [16:33:49 CEST] is that right? [16:33:58 CEST] Yes [16:34:00 CEST] jamrial: the private ones that are used in ffplay [16:34:07 CEST] and mpv and kodi and chromium and ... [16:34:24 CEST] but they are private, there's nothing to deprecate. they are meant to come and go without warning... [16:34:40 CEST] right, but to enforce that in the compiler, we move them to AVStreamInternal [16:34:54 CEST] and then the entry in the private portion of the public struct becomes deprecated [16:35:04 CEST] so that apps get a compiler warning telling them to stop using that field [16:35:26 CEST] fritsch: look at that last ticket comment [16:35:38 CEST] seems that kodi also accessed a private avstream field somewhere [16:35:49 CEST] not just the avframe ones [16:35:52 CEST] BBB 1/2/3 sounds ok [16:36:47 CEST] so & for 2) should the fields be public or moved to AVStreamInternal in next major bump? [16:37:11 CEST] with avframe at least, next major bump should make every currently "do not access directly" private field public, and not shove them into an internal struct. or at least most of them [16:37:14 CEST] (since they are used in many apps but marked as private, so I find it hard to say which way it should go) [16:37:28 CEST] mpv as we know accesses avframe->channels directly and they don't plan to change that [16:37:41 CEST] it would be ridiculous to tell people to use accessors [16:37:42 CEST] (imo) [16:37:48 CEST] were C, not python [16:37:58 CEST] exactly [16:38:07 CEST] ok, so avframe all should be public [16:38:12 CEST] what about the AVStream field kodi uses? [16:38:23 CEST] Since the libav compat stopped, there's not realy a reason not do just make them public. [16:38:30 CEST] we don't know which one it is, but we can find out [16:38:57 CEST] ffplay uses AVStream->avg_frame_rate, right? [16:40:08 CEST] in any case the priority here is choosing what to do with 3.1.1. do we apply those two patches that break avstream and avframe 3.1 abi so the private fields have the same offset as 3.0 to make distros happy [16:40:15 CEST] or do we keep the abi intact and tell distros to recompile the api-misusing packages? [16:40:40 CEST] 3.2/4.0 will solve all this making things public or shoving private stuff into internal structs, but that comes later [16:42:18 CEST] I think they should be applied for 3.1.1. [16:44:42 CEST] then apply them. 3.1 will already be incompatible with 3.1.1 anyway and i'm tired of this [16:44:54 CEST] so 3.1.1 will be compatible with 3.0? [16:44:55 CEST] seriously, how hard was for all these projects to read a field's doxy? [16:44:55 CEST] ok [16:45:02 CEST] jamrial: I dont think people read [16:45:11 CEST] jamrial: I think they just copy ffplay or ffmpeg.c source code [16:45:19 CEST] or inspired by" [16:45:19 CEST] It is easy to miss and not too obvious, which will change now. [16:45:27 CEST] well, that would explain api misuse [16:45:40 CEST] but yes, if 4.0 fixes it through compiler enforcement, this all gets much easier [16:46:03 CEST] And also, yes, most people probably practice a copy&paste style programming. [16:46:16 CEST] nevcairiel: are you against it? [16:47:27 CEST] 3.1 is already fucked and incompatible with 3.1.1 no matter what [16:51:55 CEST] and the 3.1.1 should have a comment somewhere telling people to rtfm [16:53:11 CEST] ubitux: all issues with the libopenmpt demuxer are fixed, it now fully passes fate, I've sent an updated patch to the ML. You're gonna need libopenmpt 0.2.6557 or later, you can get that from here: https://buildbot.openmpt.org/builds/auto/src/ [16:54:02 CEST] Illya: yeah i saw it; didn't have time to test it yet [16:54:13 CEST] you could use av_clipd() btw [16:54:20 CEST] for what? [16:54:46 CEST] for the proba thing [16:55:02 CEST] that's not exactly what you do though [16:55:11 CEST] what's the reason for nullifying <0.25? [16:55:52 CEST] Then it's not a high enough match, but if you think that shouldn't be there, feel free to take it out [16:56:10 CEST] not really [16:56:29 CEST] btw, maybe you should try tools/probetest [16:56:52 CEST] (make tools/probetest && ./probetest) [16:57:29 CEST] hopefully the openmpt probing doesn't slow down the ffmpeg one too much [17:01:51 CEST] jamrial: at this point all I really care about is fixing this in master for good later on, so whichever everyone else agrees ob [17:01:56 CEST] on* [17:10:36 CEST] For the earlier discussion, we'll have to see on a field by field basis if they should be made public or become really private without replacement [17:11:11 CEST] There is a few that make sense to keep, and some which are entirely for avformat internals [17:17:09 CEST] ubitux: what probe test is for? [17:17:28 CEST] all of them if not specified [17:18:06 CEST] what does it do? [17:20:11 CEST] nevcairiel: agree [17:23:02 CEST] michaelni: the two patches for 3.1.1 can go in [17:23:46 CEST] no point wasting more time with it. lets instead focus on cleaning things in master for 3.2/4.0 with the upcoming major bump [17:32:23 CEST] jamrial: yes - I think I found it [17:33:40 CEST] jamrial: https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDDemuxers/DVDDemuxFFmpeg.cpp#L1231 <- might be that one? [17:33:53 CEST] thats probably one yes [17:34:26 CEST] fritsch: yes [17:34:49 CEST] codec_info_nb_frames is one of those fields i would preferably just recycle out of the API entirely, since its values depend on the internal probing process, which may not even take place if the container provides enough data [17:35:28 CEST] jamrial: how to replace it? You know out of head? [17:35:41 CEST] its a private field, there is no replacement [17:36:02 CEST] how to get the information of this private field? [17:36:07 CEST] as it is needed in our code? [17:36:09 CEST] its private, you dont. :) [17:36:43 CEST] like i said above, the meaning of this field is not very well defined and the values depend on a lot of factors that no user knows without reading the code [17:37:25 CEST] perhaps the user (we) read the code [17:37:44 CEST] that doesnt make it any better public API though [17:38:33 CEST] fritsch: regarding the avframe ones, since fernet scheduled the patches for release 18 you may not even need to apply them at all. depending on how far away that release is, we may have already released 3.2/4.0 making those fields public [17:38:34 CEST] avformat decodes frames until it has all the info it needs [17:38:53 CEST] if it finds the info after 1 frame, then it will be happy and quit decoding [17:39:03 CEST] does that mean the stream info is unreliable? certainly not [17:39:41 CEST] jamrial: yeah - I want it fixed. Though being blamed for having code like that for > 10 years :-) does not feel so well [17:39:54 CEST] looking again I think we don't need that field there at all [17:40:10 CEST] if we release 3.2 or 4.0 with a fresh new ABI you probably dont even need to fix anything [17:40:14 CEST] fernet says: "it is stoneold dvd crap" :-) [17:40:19 CEST] translated from german [17:40:39 CEST] as everything in AVFrame will be public, it has no reason to have any internal fields [17:40:54 CEST] we will remove it for v18 [17:41:11 CEST] reason: that part of the code (demuxer) is so fugly wrong - that from three times wrong it gets right at the end [17:41:14 CEST] :-) [17:41:18 CEST] very regression happy that part [17:41:19 CEST] in any case, there is a bunch of fields in AVStream just like this one where we have to decide and figure out what to do with them [17:41:33 CEST] which is our task until the next major [17:42:15 CEST] avframe is simple, everyhting there is made public and the accessors deprecated [17:42:16 CEST] yeah - as said - we are happy to become API conform, though our software has grown for ages and is very fragile at certain positions [17:42:37 CEST] avstream not so much. all the private fields are truly private, with no accessors. plenty of them also exist in libav, even [17:43:34 CEST] nevcairiel: when do you push that dvd menu patch to 3.1? [17:43:50 CEST] michaelni will probably do it in a bit [17:43:54 CEST] thx, much [17:44:16 CEST] i'm only on a phone right now, home internet is flaky [17:45:15 CEST] i looked for ages for a phone with a real keyboard - but could not find one since that old nokia n900 [17:45:26 CEST] sorry, that was offtopic - just thought loudly [17:45:56 CEST] ffmpeg 03Michael Niedermayer 07master:042fb69deb53: avutil/frame: Move new field to the end of AVFrame [17:45:57 CEST] ffmpeg 03Hendrik Leppkes 07master:c2e13d2ecd38: avformat/utils: update deprecated AVStream->codec when the context is updated [17:45:58 CEST] ffmpeg 03Michael Niedermayer 07master:c1c7e0abb0c5: avformat/avformat: Move new field to the end of AVStream [17:45:59 CEST] yeah those are extremely rare [17:46:05 CEST] michaelni: thx much! [17:52:59 CEST] fritsch: motorola droid 4? it's kinda old by now but maybe there's a more recent model [17:53:10 CEST] there isn't [17:53:13 CEST] :-) [17:53:19 CEST] i checked exactly out of that reason [17:53:27 CEST] there are the new android blackberrys [17:53:34 CEST] but they are kind of "wrong form factor" [17:53:52 CEST] 9:16 with the keyboard going out on the wrong side [18:04:01 CEST] ffmpeg 03Martin Vignali 07release/3.1:37c83b53730a: libavcodec/exr : fix decoding piz float file. [18:04:02 CEST] ffmpeg 03Michael Niedermayer 07release/3.1:77473002898f: avutil/frame: Move new field to the end of AVFrame [18:04:03 CEST] ffmpeg 03Hendrik Leppkes 07release/3.1:79af094b9304: avformat/utils: update deprecated AVStream->codec when the context is updated [18:04:04 CEST] ffmpeg 03Michael Niedermayer 07release/3.1:f617b94c233f: avformat/avformat: Move new field to the end of AVStream [18:04:45 CEST] we access much more in our demuxer [18:04:54 CEST] including stream's metadata to find the rotation [18:08:59 CEST] metadata should be public [18:13:25 CEST] nevcairiel: it's "below" that fields [18:14:22 CEST] Hm. Well we'll clean that up soon [18:15:01 CEST] fine mis looked it [18:15:08 CEST] good it's public [18:19:08 CEST] jamrial: can I ask avx2 n00b questions? [18:19:21 CEST] yes, i can try to answer them :p [18:19:35 CEST] is there a movhps to move the upper half of a ymm register to memory? [18:20:05 CEST] vextracti128 [18:20:11 CEST] http://www.felixcloutier.com/x86/VEXTRACTI128.html [18:20:14 CEST] vextracti128 [mem], ymm0? [18:20:28 CEST] okiedokie [18:20:38 CEST] vextracti128 [mem], ymm0, 1 [18:21:30 CEST] 0 would extract the low 128bits, but in that case you should use movdqa with xmm reg anyway [18:24:28 CEST] afaik reading an xmm reg using vex encoded instructions doesn't zero the upper 128 bits, only if you write it [18:24:32 CEST] so vmovdqa [mem], xmm0 should keep the upper contents intact much like vextracti128 [mem], ymm0, 0 [18:25:45 CEST] does movh expand to vmovdqa in avx2 mode? [18:31:28 CEST] BBB: no [20:05:24 CEST] jamrial: and (in the cases where I have to) how do I transfer data between low/high halves of ymm again? [20:05:33 CEST] jamrial: I recall I have to limit it, but in some cases I have to [20:05:44 CEST] jamrial: e.g. a transpose [20:07:12 CEST] BBB: vinserti128 http://www.felixcloutier.com/x86/VINSERTI128.html or vpermi128 http://www.felixcloutier.com/x86/VPERM2I128.html [20:07:38 CEST] *vperm2i128 [20:08:57 CEST] BBB: x264 for example updated the SBUTTERFLY macro to use these when mmsize > 16 [20:14:47 CEST] REAL programmers use SBUTTERFLY [20:24:47 CEST] jamrial: only for dqqq? [20:25:00 CEST] jamrial: I mean, I assume you dont want to do that for all uses, right? [23:03:22 CEST] jamrial: btw mova [mem], xm0 does indeed clear the upper half of xm0 [23:04:39 CEST] oh wait no its something else [23:04:44 CEST] just kick me Im stupid [23:06:08 CEST] I totally hate avx2 now [23:06:17 CEST] what on earth were they thinking stupid idiots [23:06:20 CEST] haha, what happened? [23:06:37 CEST] well I handle 16x16 coefs in my idct16x16 right? [23:06:45 CEST] so Im really careful to not ever cross lanes etc. [23:07:00 CEST] but in the end you need to write out 16 byte pixels by adding 16 words [23:07:15 CEST] so I mova xm%d, [mem to 16 bytes] [23:07:17 CEST] and then punpcklbw [23:07:22 CEST] which obviously doesnt work [23:07:26 CEST] to zero extend? [23:07:55 CEST] yes, but it will only zero extend the first 8 bytes, the other 8 are shifted out of the second quarter of the reg, the third quarter is zero being zero-extended [23:07:57 CEST] [etc] [23:08:01 CEST] you're in luck, because sse4's pmovzx is probably the only instruction intel didn't fuck up regarding lanes [23:08:08 CEST] as it zero extends across lanes [23:08:08 CEST] so if you have 16 contiguous pixels& [23:08:13 CEST] hm.... [23:08:18 CEST] so strange [23:08:41 CEST] http://www.felixcloutier.com/x86/PMOVZX.html [23:08:47 CEST] look at VPMOVZXBW (VEX.256 encoded version) [23:09:21 CEST] and yes, i also wondered why only this one and pmovsx [23:09:37 CEST] oh because it takes xmm as input [23:09:41 CEST] it actually makes sense then [23:09:43 CEST] still stupid [23:11:23 CEST] for pack functions you're screwed, though [23:11:33 CEST] you'll have to shuffle stuff around [23:11:58 CEST] avx512 is the set that adds pack functions that cross lanes i think [23:12:50 CEST] I so hate this [23:12:55 CEST] what on earth were they thinking [23:13:02 CEST] *instructions [23:13:05 CEST] oh lets just invent our own geometry, maybe we can patent it"? [23:15:00 CEST] since moving data across lanes costs extra cycles maybe there were some design issues [23:15:13 CEST] maybe Gramner knows [23:15:34 CEST] how do I extract 8 bytes? [23:15:42 CEST] vextracti64 doesnt seem to exist [23:16:02 CEST] eight bytes from where? [23:16:15 CEST] first eight bytes from upper half? [23:17:10 CEST] i think you'll have to use vpermq for that [23:17:45 CEST] you can't extract less than 16 bytes from the upper half [23:17:49 CEST] because reasons [23:18:00 CEST] nor insert [23:18:22 CEST] because reasons is what I tell my kids when I just want them to shut up [23:18:31 CEST] they didn't extend the insertion/extraction instructions to avx2 for some reason. I tried asking intel but they ignored me [23:18:45 CEST] vpermq works but yes that takes an extra instruction which I was trying to prevent [23:19:01 CEST] I mean basically this means that ymm is just a very odd way of doing two xmm instructions at once [23:19:09 CEST] Gramner: probably because the vperm[qd] instructions covers it [23:19:23 CEST] although vpermd sucks for something as simple as extracting a word because it takes a reg as index [23:19:25 CEST] as soon as there are contiguity requirements across the register, it stops working [23:20:01 CEST] well I suppose intel would ignore me also [23:20:19 CEST] at leas tthe dc only works now [23:20:22 CEST] thats kind of nice [23:20:33 CEST] (yay, dc only 16x16 vp9 idct!) [23:20:56 CEST] jamrial: permutes aren't really equivalent to extracts. if I want to extract dword #6 from an ymm register to memory you can't do it in a single instruction. you could before avx2 [23:21:02 CEST] BBB: great. but is it faster after all the lane bullshit? :P [23:21:11 CEST] Im scared to test [23:21:15 CEST] Gramner: ah, true. i was thinking about reg to reg [23:21:19 CEST] because I give it 50% that the answer is no [23:21:48 CEST] thats still 50% yes! [23:22:27 CEST] I believe the main reason for the lane stuff is to be able to easily power-gate off the upper half [23:23:18 CEST] you'd need more transistors to duplicate some functionality otherwise [23:32:14 CEST] really& so anyone implementing things that switch between words and bytes and operates on contiguous 16 pixel blocks needs a vpermq per 16px? [23:32:22 CEST] I just cant believe this, this is ridiculous [23:32:45 CEST] no wonder people are excited about ppc64 [23:32:50 CEST] this is like corporate suicide [23:33:42 CEST] intel instruction sets are mainly aimed at HPC applications nowadays [23:43:39 CEST] at least in the dc-only the vpermq can be removed by doing some other weird things, but for the full idct a vpermq will be required [23:43:40 CEST] :( [23:43:45 CEST] ohwell [23:43:49 CEST] BBB: try out aarch64, it's clean to write [23:43:51 CEST] hpc doesnt require speed anyway [23:44:02 CEST] if your application is slow, just buy twice as many servers [23:44:04 CEST] now its fast again [23:44:10 CEST] Intel Inside [TM] [23:44:26 CEST] sounds legit [23:44:29 CEST] those people also like efficiency [23:44:36 CEST] nah, then you need twice as much space and twice as much cooling [23:44:45 CEST] BBB: why not use pshufb? [23:44:49 CEST] dont you know how many jobs that creates? [23:45:02 CEST] dude, the number of jobs created - just think construction, etc. [23:45:05 CEST] why would they want to pay more people? =p [23:45:08 CEST] donald trump would be proud of you [23:45:14 CEST] because Intel Loves Everyone! [TM] [23:48:29 CEST] 0:44 PM <"nevcairiel> those people also like efficiency --> no they don't [23:48:34 CEST] it's grad students code that doesn't work [23:49:25 CEST] well they still like to claim to have high density high performance hardware instead of a warehouse full of slow things [23:49:27 CEST] atomnuker: pshufb is still a shuffle - Im trying to do things shuffle-less" [23:49:31 CEST] no matter how bad their code is [23:49:49 CEST] fast vs. slow code is a very perceptual thing [23:49:58 CEST] you can easily hire a bunch of marketeers and say that its fast [23:50:01 CEST] hevc is fast [23:50:06 CEST] and now everyone believes you [23:50:17 CEST] as long as you jazz it up with some nice jingles and some splashy glitter [23:52:30 CEST] ok time to make the full idct work [23:52:34 CEST] this is so painful :D [00:00:00 CEST] --- Fri Jul 1 2016 From burek021 at gmail.com Sat Jul 2 02:05:01 2016 From: burek021 at gmail.com (burek) Date: Sat, 2 Jul 2016 02:05:01 +0200 (CEST) Subject: [Ffmpeg-devel-irc] ffmpeg.log.20160701 Message-ID: <20160702000501.EFA8718A0040@apolo.teamnet.rs> [00:11:10 CEST] hello, why is it recommended to not use over 16 threads? is there limited testing using more than that? [00:12:48 CEST] some codecs degrade in quality, on more threads. Maybe because of that [00:13:52 CEST] viric: do you know if hevc is subjected to this? [00:14:28 CEST] I guess it degrades, like h264 [00:14:41 CEST] should degrade little [00:15:15 CEST] viric, was actually going to ask why thread count changes the quality [00:15:37 CEST] testing 16 vs 4 showed differences in the encodes [00:16:08 CEST] how do you split the encoding process to multiple threads, if all produced data per frame is dependant one on the other? [00:16:31 CEST] by the use of some tricks, that have some degrading effect (should be little) [00:17:12 CEST] yeah it wasn't significant. What was significant though is 'Constant Quality' mode vs 'Constrained Quality' mode [00:17:33 CEST] the wiki says it will keep to a CRF quality except if it hits the max bitrate ceiling [00:17:44 CEST] however I haven't found this at all to be the case with VPx [00:18:00 CEST] I don't know much details about that [00:21:51 CEST] I'm not sure I get the wiki at times :p I can set CRF 4 -b:v 2M and it will typically output around 9-1200kbps, whereas CRF -b:v 0 outputs at like 30000kbps. [00:22:05 CEST] *CRF 4 -b:v 0 [00:23:26 CEST] wait, of course it would. M = MBit/s. [00:24:37 CEST] what crf value would be considered visually lossless? around 23? [00:57:50 CEST] Spring i would assume it ignores a bitrate of zero because it is obvious nonsense? [00:58:23 CEST] just a guess [00:59:55 CEST] utack, according to the docs setting '0' is required for that mode to work, so yeah there's no artificial max. [01:01:14 CEST] uhm..i had that happen with one encoder, can't remember which one, but ffmpeg should not require that [01:01:47 CEST] at least last i tried i think i used just crf [01:02:08 CEST] it does work with CRF without it but it has different results [01:02:28 CEST] crf 4 is pretty heavy, bitrate of 30mbit+ sounds about right [01:03:12 CEST] at first I assumed CRF would work without any -b:v, after reading the docs and comparing results the difference is obvious [01:03:27 CEST] just a quirk I suppose [01:08:43 CEST] hi! i've a problem... i want to transcode an DVB ts udp from smartdvb player... ffmpeg create a lot of error like frame dropped or PMT sync... to avoid this issue i must buy an hdmi capture card and bypass HDMI video card with HDMI in capture card? [01:11:49 CEST] Stream #0:0: Video: h264 (libx264) ([7][0][0][0] / 0x0007), yuv420p, 640x360 [SAR 1:1 DAR 16:9], q=-1--1, 100 kb/s, 25 fps, 1k tbn, 25 tbc [01:12:07 CEST] Stream #0:0[0x200]: Video: h264 (High 4:2:2) ([27][0][0][0] / 0x001B), yuv422p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn, 50 tbc [01:24:31 CEST] http://pastebin.com/BihJaLG4 [01:33:01 CEST] are different filters separated by commas or semi-colons? [01:33:56 CEST] pretty sure they're semi-colons but some are related and use commads [01:34:02 CEST] *commas [01:34:15 CEST] sequential filters are separated by commas to create a filterchain. filterchains are separated by semicolons [01:45:39 CEST] I think I'm getting a bit stuck with how to combine a video+audio filter [01:45:57 CEST] -filter_complex scale=iw:ih;dynaudnorm=m=30:s=10 [01:46:29 CEST] "[0:v]scale[v];[0:a]dynaudnorm[a]" -map "[v]" -map "[a]" [01:47:08 CEST] you don't have to explicitly label inputs and outputs but I prefer not to rely on defaults to avoid surprises [01:47:32 CEST] llogan, ooh. So where would the filter settings be placed in that format? [01:48:03 CEST] "[0:v]scale=640:-2[v];[0:a]dynaudnorm=m=30:s=10[a]" [01:48:20 CEST] scale=iw:ih will do nothing by the way [01:48:35 CEST] yeah, it's a conditional toggle for a batch script [01:48:50 CEST] so when no changes are made I set it to that [01:51:52 CEST] well how i can set? [01:52:39 CEST] ffmpeg -i udp://@127.0.0.1:8888 -pix_fmt yuv420p -c [01:52:39 CEST] :a aac -b:a 64k -c:v libx264 -b:v 100K -vf scale=640:360 -f flv rtmp://localhost/live [02:14:00 CEST] llogan, so I integrated it and it runs but there's no sound. Looking at it there is an audio stream but 0kbps output. Any ideas? [02:17:15 CEST] llogan, this is the final 2 pass code: http://pastebin.com/Xgk5bVEF [02:19:50 CEST] that's not the complete console output. make sure to remove -loglevel and -hide_banner. those are useless when requesting help. [02:23:38 CEST] anyone can help me : http://pastebin.com/BihJaLG4 [02:24:00 CEST] there in no command in that pastebin link [02:24:04 CEST] *is no [02:27:11 CEST] llogan, entire console output: http://pastebin.com/WWtqGrfd [02:27:35 CEST] the command is outputted by the batch script so it doesn't appear in the log when beginning [02:28:34 CEST] the command you used to generate the console output is different than what you showed earleir [02:30:00 CEST] this is the output, I posted the ffmpeg command in the earlier link. The command itself is identical to the one posted earlier but without the loglevel and hidebanner options [02:30:08 CEST] maybe, not. it's just using two different audio encoders for each pass [02:31:34 CEST] I just realized something. I added the audio filter to the first pass when I have the -an switch. [02:32:06 CEST] would that make a difference? [02:32:34 CEST] i doubt you need to encode audio for the first pass. [02:33:13 CEST] thing is all the options are actually variables, so I'll try to make two different versions for each pass [02:33:13 CEST] llogan: ffmpeg -i udp://@127.0.0.1:8888 -pix_fmt yuv420p -c [02:33:13 CEST] [01:52:39] :a aac -b:a 64k -c:v libx264 -b:v 100K -vf scale=640:360 -f flv rtmp://localhost/live [02:33:27 CEST] HSKW: probably a shitty, borken input [02:34:19 CEST] llogan: is an mpegts input.... in this case.. i need an HDMI capture card and loop with GPU hdmi exit?? [02:34:29 CEST] i don't know [02:34:32 CEST] all player like VLC, FFplay mpc work ok [02:34:40 CEST] only if i transcode :( [02:35:38 CEST] HSKW: does that need one of the bsf flags for audio to work right? [02:36:11 CEST] vandemar: dont know :( [02:36:59 CEST] bsf flah what mean? [02:37:27 CEST] I'm not sure you need it, ts issues are a bit fuzzy for me, but https://www.ffmpeg.org/ffmpeg-bitstream-filters.html#aac_005fadtstoasc [02:38:14 CEST] not relevant to the problem you pasted afaik, but worth knowing about [02:40:01 CEST] vandemar: ffmpeg -i udp://@127.0.0.1:8888 -pix_fmt yuv420p -c:a aac -b:a 64k -c:v libx264 -b:v 100K -vf scale=640:360 -f flv rtmp://localhost/live [02:40:10 CEST] this is the command line that run [02:43:02 CEST] so removed the -an (no sound) option and complex filter from the first pass, leaving just the -vf scale filter. Still no sound even though the audio channels are still embedded. [02:43:14 CEST] Is there a correct order to placing audio filters? [02:45:27 CEST] vandemar: i think if the broken input... i must use an secondary video card exit and loop in an hdmi capure card.. and caputure the hdmi av and stream it on rtmp [03:44:57 CEST] got it working. Turns out I needed the audio options in both passes not just the second, at least that's the only way I got it working. [05:52:49 CEST] Hello! [05:53:37 CEST] Any AVOption and AVDictionary guru around? [07:25:50 CEST] so pass logs are saved to the location of the input file not the output file? [07:26:53 CEST] edit, my bad nvm. [14:20:49 CEST] hello why ffmpeg is obsolete and must use avconv? [14:21:46 CEST] You are a few yeard behind. [14:21:49 CEST] *years [14:22:16 CEST] Why? [14:22:36 CEST] i've read this when launch ffmpeg on debian wheezy [14:22:40 CEST] Because that misleading message was added in ancient versions of libav, and has since been removed, and replaced with ffmpeg again. [14:23:02 CEST] Debian Wheezy is ancient. [14:23:14 CEST] BtbN: yes but in server i must use it... [14:23:41 CEST] It does not come with ffmpeg, and the libav version it comes with is equally ancient. [14:24:02 CEST] BtbN: i must buy an HDMI capture card.. i would buy some PCIex card... what work very well with ffmpeg??? Blackmagic Intensity pro 4k? or some Avermedia product? [14:24:30 CEST] I think the only capture cards that work on linux at all are the declink ones. [14:24:48 CEST] blackmagic decklink caputure? [14:25:34 CEST] Blackmagic decklink mini recorder [14:26:04 CEST] are ok this? [14:26:10 CEST] No idea, ask their manufacturer. [14:26:25 CEST] You won't have much fun with any of them using that ancient libav version though. [14:27:15 CEST] BtbN: now i've compiled an fresh ffmpeg 2016 from last source :D [14:27:21 CEST] the message not appear :D [14:27:29 CEST] The message was never part of ffmpeg. [14:27:32 CEST] It comes from libav. [14:27:36 CEST] Or rather, came. [14:27:47 CEST] They indeed did remove ffmpeg after a while. [14:27:53 CEST] libav is inside ffmpeg? [14:28:04 CEST] libav is an entirely seperate project. [14:28:49 CEST] libavutil 55. 17.103 / 55. 17.103 libavcodec 57. 24.102 / 57. 24.102 [14:28:55 CEST] libav was a spoon of ffmpeg [14:29:02 CEST] this is my libav version [14:29:09 CEST] No, that's your libav* versions. [14:29:31 CEST] They did a good job confusing people by choosing that project name. [14:30:16 CEST] BtbN: LoL... libav must compile separately? [14:30:49 CEST] libav and ffmpeg can't be installed on the same system at the same time, as they install "the same" libraries. [14:31:35 CEST] BtbN: ok well if i compile ffmpeg they install the lastet libav library? [14:32:09 CEST] ffmpeg installs its own set of libav* libraries, if you tell it to do so. [14:32:18 CEST] I'd highly recommend against doing that, it _will_ break stuff [14:33:13 CEST] BtbN: i've compiled ffmpeg reading the guide on the wiki... [14:33:30 CEST] As long as you didn't run make install as root, it's fine. [14:33:43 CEST] just put the static binary elsewhere [14:33:52 CEST] ok... done this [14:34:49 CEST] now... i would a advertising on what is the best video capture card... declink that capture in raw pixel or an h264 encoding card like avermedia [14:35:26 CEST] AverMedia does not have linux drivers at all. [14:35:37 CEST] decklink is the only thing i know that works on linux at all. [14:35:51 CEST] decklink what version? there are a lot... :( [14:36:01 CEST] decklink is the ffmpeg input name [14:36:09 CEST] it supports a lot of cards iirc [14:36:46 CEST] DeckLink Mini Recorder ? [14:38:45 CEST] BtbN: i would use this card because i've some problem with the mpegts input from an dvb-ts [14:39:18 CEST] well with the vlc i can play whis mpegts and show on secondary monitor, than capture with this decklink card and ffmpeg :) [14:39:56 CEST] problems while using that ancient version of avconv? [14:41:17 CEST] BtbN: no lastet build... both windows or linux all same problem... wait i send the pastebin link with log of error... [14:46:20 CEST] BtbN: http://pastebin.com/BihJaLG4 look [14:47:27 CEST] looks like a very damaged stream [14:49:14 CEST] BtbN: is from DVB [14:49:29 CEST] with vlc, Mpc-hc all work ok... [14:50:33 CEST] well i would use this workaround... play this stream with VLC on secondary monitor... exit with HDMI from VGA Card... input in decklink capture card and than encode and stream [14:51:57 CEST] sounds like overkill. VLC also just uses libav* to plays its stuff [14:53:49 CEST] BtbN: yes i know.. this is very strage. but this stream is from a professional DVB encoder ericcson [17:07:07 CEST] Hi, is it possible to give an char* to an equivalent of avformat_open_input instead of a filename? [17:07:32 CEST] I have the content of a video file but don't want to write on my harddrive [17:17:13 CEST] Hello everyone [17:17:33 CEST] imperio_: you can make your own "input source" object, I believe an example shows how to do this [17:17:45 CEST] DHE: really? [17:17:48 CEST] that'd be awesome! [17:17:58 CEST] I have an issue. I have 3 video files on my NAS, and I can see video1 and video2 on my Samsunt Smart TV, but not video3... But the streams seems to be correct... what could be wrong? This is the info data on each video: http://hastebin.com/ifidipubiy.bash [17:18:07 CEST] I thought about memory map, but don't know if it's possible to map memory as a file [17:18:25 CEST] dbugger: post the ffprobe output for each file [17:19:34 CEST] furq, i dont know ffprobe, can you tell me the command I have to type? [17:20:05 CEST] oh, of course, simply ffprobe video1 :) [17:22:25 CEST] furq, here it is: http://hastebin.com/juyukuyipa.coffee [17:23:45 CEST] DHE: found it, thanks again! [17:28:58 CEST] dbugger: i can't see anything obvious [17:31:47 CEST] furq, it is weird... I wonder why... [17:32:30 CEST] you could maybe check mediainfo for the encoder settings [17:32:44 CEST] smart tvs are notoriously picky though [17:32:59 CEST] most hardware players are [17:36:00 CEST] furq, mediainfo on the files? [17:36:39 CEST] yeah [17:36:45 CEST] ok, let me install it first.. [17:37:43 CEST] This is video1: http://hastebin.com/exeyarayiz.vhdl [17:38:17 CEST] This is video2: http://hastebin.com/faburusuze.rib [17:38:34 CEST] hastebin's format detection really is a modern marvel [17:39:04 CEST] And this is video3: http://hastebin.com/besekosulo.rib [17:39:07 CEST] I know XDDDD [17:40:52 CEST] yeah i can't see any meaningful difference here [17:41:05 CEST] I have no idea then... :( [17:41:10 CEST] maybe try remuxing it into a new mkv [17:41:15 CEST] ffmpeg -i foo.mkv -c copy bar.mkv [17:41:59 CEST] i did this: "avconv -i input.mkv -cc copy output.mp4" [17:42:02 CEST] It did not work [17:42:16 CEST] I mean "-c", of course :) [17:42:23 CEST] some players are picky about ac3 in mp4 [17:42:38 CEST] although it's been part of the spec since ~2008 so a new smart tv should be able to figure it out [17:42:49 CEST] so you think I should try "avconc -i input.mkv -c copy output.mkv" ? [17:42:58 CEST] it's worth a shot [17:43:01 CEST] ok, let me see [17:43:59 CEST] Ok, pasting. Im gonna test it [17:45:10 CEST] Nothing... it did not work :( [17:57:17 CEST] hi, I have an iso file that contains a movie. I want to extract it to mkv or mp4. If I click on the individual pal files the image appears small, with 5 cm margins. I want to avoid that. Is ffmpeg the tool I need? [17:57:28 CEST] what about mkvtoolnix? [19:30:55 CEST] <]R[> i have a flv file with audio starting late, is there a way to make ffprobe show me when ? (ie: timecode/frame #) [19:54:16 CEST] ]R[: you could see if mediainfo shows something, sometimes it displays more stuff than ffprobe i think [20:24:53 CEST] Hi my people [20:25:07 CEST] What does the AV stand for anyways [20:25:20 CEST] awful video? [20:25:35 CEST] like libavcodec [20:25:36 CEST] etc [20:26:53 CEST] <__jack__> audio video ? [20:27:06 CEST] you say that like its a question [20:27:08 CEST] you are unsure [20:27:21 CEST] <__jack__> that's true, I don't really know [20:27:23 CEST] ffmpeg is the collection of them [20:27:37 CEST] screw it [20:27:39 CEST] <__jack__> false : they are parts of ffmpeg [20:27:44 CEST] PH [20:27:45 CEST] Oh [20:27:50 CEST] then what should i call my thing [20:28:01 CEST] AvideoStreamer : IVideoStreamer [20:28:06 CEST] but then i was thinking [20:28:19 CEST] <__jack__> your thing ? dunno what's your thing [20:28:25 CEST] FFmpegStreamer as a name [20:29:52 CEST] interesting [20:29:56 CEST] look [20:30:00 CEST] is it FFMpeg? [20:30:02 CEST] ffmpeg? [20:30:07 CEST] or FFmpeg [20:30:19 CEST] FFmpeg [20:30:27 CEST] just look at ffmpeg.org and see the title [20:30:33 CEST] https://www.sgi.com/tech/stl/ [20:30:37 CEST] wtf wrong paste [20:30:38 CEST] ah [20:30:45 CEST] i forgot i cant paste from windows [20:30:50 CEST] :) [20:31:00 CEST] FFmpegStreamer : public IVideoStreamer [20:58:59 CEST] Is is possible to proportionally scale down a clip without erroring out half the time? [20:59:30 CEST] E.g., scale to 180 height, while setting width to the closest legal value [21:07:42 CEST] CoJaBo: -vf scale=-2:180 [23:39:13 CEST] ffmpeg -crop=out_w=in_h crop=in_h 1.mkv a.mkv < is this right? [23:40:38 CEST] lerner: no. what are you trying to do? [23:41:54 CEST] 1.mkv is a concatenation of 4 vob files (from an iso file). On the 4 sides of the screen there are 3 cm wide "margins" which I want to get rid of, so I need to recode [23:42:02 CEST] llogan, ^ [23:42:24 CEST] I'm seeing a really strange difference in performance between an FFMPEG I built by hand, and the one I downloaded from Zeranoe. [23:42:27 CEST] on the manpages I found the crop section, which Im trying to use [23:42:45 CEST] https://ffmpeg.org/ffmpeg-filters.html#crop [23:42:49 CEST] I'm recording video/audio with gdigrab, and Zeranoe is a lot faster the moment I introduce an audio track. [23:43:08 CEST] Literally the same options for both. [23:43:23 CEST] I'm recording rawvideo, and pcm just to take encoder performance out of the mix. [23:43:27 CEST] lerner: ffmpeg -i zardoz.mkv -vf crop=iw-100:ih-100 -c:a copy output.mkv [23:43:55 CEST] llogan, I assume zardov is original file? [23:44:01 CEST] yes. it's a terrible movie. [23:44:02 CEST] Does anyone have any ideas on what could explain the performance difference? Perhaps something dealing with syncing the video/audio streams? [23:44:19 CEST] One big difference is Zeranoe is using pthreads- and I am using win32threads. [23:44:22 CEST] llogan, will that remove 100 pixels from each of the 4 sides? [23:44:50 CEST] it will remove 100 pixels from the width, and 100 from the height. [23:45:15 CEST] default is centered, so 50px from left, 50 px from top, 50 px from right, 50px from bottom [23:45:29 CEST] llogan, so the way to go here is to calculate and maybe get lucky finding the exat number of pixesl to get rid of... [23:45:53 CEST] that's one method. another is to use cropdetect to tell you [23:46:04 CEST] Is there any filter to show motion between frames ? [23:46:20 CEST] I want to produce a motion mask [23:46:22 CEST] llogan, is cropdetect a function in ffmpeg? [23:47:24 CEST] lerner: ffmpeg -i police_academy_9.mov -vf cropdetect -f null - [23:47:27 CEST] http://ffmpeg.org/ffmpeg-filters.html#cropdetect [23:47:38 CEST] aua [23:47:42 CEST] it will spew info about detected black area which you can feed to crop [23:50:08 CEST] ChocolateArmpits: maybe tblend? [23:54:46 CEST] llogan: Thanks, difference filtering could be used, but I'm not sure about how accurate the results are, should have some threshold filtering [00:00:00 CEST] --- Sat Jul 2 2016 From burek021 at gmail.com Sat Jul 2 02:05:03 2016 From: burek021 at gmail.com (burek) Date: Sat, 2 Jul 2016 02:05:03 +0200 (CEST) Subject: [Ffmpeg-devel-irc] ffmpeg-devel.log.20160701 Message-ID: <20160702000503.6897418A0041@apolo.teamnet.rs> [01:14:57 CEST] hello ffmpeg... i've a problem to transcode this stream: Stream #0:0[0x200]: Video: h264 (High 4:2:2) ([27][0][0][0] / 0x001B), yuv422p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn, 50 [01:14:57 CEST] tbc [01:16:55 CEST] wrong channel. #ffmpeg-user is for user help. [01:17:40 CEST] its just #ffmpeg isnt it [01:18:47 CEST] nevcairiel: ok thans.. but seems as a bug :( sorry [01:19:41 CEST] unless you have a patch to fix the bug, it should still be reported in #ffmpeg or on our Trac bug tracker [01:20:44 CEST] nevcairiel: yes. early onset dementia. [01:21:57 CEST] http://pastebin.com/BihJaLG4 [02:14:41 CEST] ffmpeg 03Michael Niedermayer 07master:86fec7a7e861: doc/APIchanges: document the lavu/lavf field moves [02:40:26 CEST] ffmpeg 03Michael Niedermayer 07release/3.1:5c695ce90386: doc/APIchanges: document the lavu/lavf field moves [02:40:27 CEST] ffmpeg 03Michael Niedermayer 07release/3.1:fc25481d17be: Update for 3.1.1 [02:45:58 CEST] ffmpeg 03Michael Niedermayer 07master:2a8dadb38f6b: doc/APIchanges: fill in missing git hash [02:46:00 CEST] ffmpeg 03Michael Niedermayer 07release/3.1:ce36e74e7575: doc/APIchanges: fill in missing git hash [03:27:31 CEST] ffmpeg 03Michael Niedermayer 07n3.1.1:HEAD: doc/APIchanges: fill in missing git hash [05:05:47 CEST] ffmpeg 03Michael Niedermayer 07release/3.0:96f5019bde0f: avcodec/libopenjpegenc: Set numresolutions by default to a value that is not too large [13:43:57 CEST] michaelni: can i have testing for my merge-libav branch? [13:44:13 CEST] it's just a single merge commit [14:10:44 CEST] ubitux, seems working fine [14:10:51 CEST] cool, thanks [14:11:49 CEST] ffmpeg 03Anton Khirnov 07master:3fba16ecd978: h264: factor starting a new field out of parsing the slice header [14:11:50 CEST] ffmpeg 03Cl�ment BSsch 07master:99b37f53a13d: Merge commit '3fba16ecd978d5bed338b8da643c3435e62b3437' [14:21:10 CEST] ffmpeg 03Anton Khirnov 07master:d1f539c97e04: h264: merge the two reinit blocks in slice_header_parse() [14:21:11 CEST] ffmpeg 03Cl�ment BSsch 07master:2021326f995f: Merge commit 'd1f539c97e04e7cebecaf6916c5064f243d39fcf' [14:23:28 CEST] ffmpeg 03Anton Khirnov 07master:6e92181bf836: h264: pass just the PPS to get_chroma_qp() [14:23:29 CEST] ffmpeg 03Cl�ment BSsch 07master:5565e2711162: Merge commit '6e92181bf836f48627a4733b6fd240a99fd36365' [16:46:25 CEST] hello, is there a function that convert the pps/sps data from the H264ParameterSet (not encapsulated), into a NALU ? [16:52:42 CEST] bsf_h264_mp4toannexb? [16:57:30 CEST] BtbN: I need to have a separate sps and pps buffers (nalu) for the MediaCodec decoders, I was previously using my own function to achieve that before switch to ff_h264_decode_extradata [16:57:45 CEST] so the extradata basically? [16:58:00 CEST] but I just noticed that ff_h264_decode_extradata remove the rbsp encapsulation [16:58:24 CEST] bsf_h264_mp4toannexb gives you an extradata output buffer, nicely 0001 encoded [16:58:31 CEST] look at the cuvid decoder on how to use it. [16:58:43 CEST] but i need to separate the sps and pps manually right ? [16:58:55 CEST] Yes, that's the usual extradata. [17:12:51 CEST] BtbN: how would I split the pps / sps reliably ? look for {0, 0, 0, 1} header and split according to nalu type ? [17:17:44 CEST] there is no guarantees the extradata will be set if the stream already is annexb [17:25:18 CEST] nevcairiel: are you talking about the extradata of the bsf or the extradata of the avctx ? [17:25:24 CEST] both [17:28:14 CEST] in the case I have the extradata, I have two choices, either I keep using ff_h264_decode_extradata but I actually need to re-encapulsate the pps and sps buffers [17:28:35 CEST] or using the bsf to convert the extradata to annex-b and then split the pps and pps [17:29:43 CEST] I'm not sure what would be the best solution though [18:33:16 CEST] ubitux, "./ffmpeg -fdebug +ts -i issue2.ts -vframes 12 -f null - 2>&1 | egrep 'read_frame_internal stream=' | sed 's/@.*]//' | grep stream=2" DTS are lost [18:34:33 CEST] http://samples.ffmpeg.org/MPEG-VOB/transport/issue2.ts [18:35:09 CEST] i think almost the same regression happened a month ago already [18:45:14 CEST] seems caused by 2021326f995ff2eda5cd2aae600853f6eddb507d [19:28:15 CEST] ubitux, posted a fate test for a similar (?idenntical) failure since 2021326f995ff2eda5cd2aae600853f6eddb507d [20:02:43 CEST] michaelni: http://pastebin.com/myR8GHzz seems to fix it for me [20:08:06 CEST] jamrial: I know we cant decode some files, Im saying thats a bad thing so if its limited effort, lets not make it worse [20:08:32 CEST] right [20:08:38 CEST] BBB: sorry for that reply then [20:08:54 CEST] dont feel bad, its ok [21:01:37 CEST] ffmpeg 03Martin Vignali 07master:92bf87db294c: fate/webp : add test for lossless picture to improve cover [21:42:55 CEST] ffmpeg 03James Almer 07master:77eb05a2f11f: avcodec/h264_slice: Only call ff_h264_flush_change() on initialized contexts [21:43:16 CEST] jamrial, diff applied with some changes, thanks alot! [22:08:37 CEST] jamrial: so & Im looking for a second opinion here, like, an independent one& am I being too hard on these guys for saying an encoder needs a decoder? [22:16:33 CEST] BBB: I do tend to agree that in general it goes dec->enc, or both at the same time. be it a fully lavc decoder or just utilizing a decoder library [22:16:42 CEST] BBB: are you talking about libx264 ? [22:17:15 CEST] BBB: no, you're not being hard [22:17:41 CEST] i'm sure they can add support for these files to the libvpxdec wrapper just as easily [22:18:49 CEST] yeah [22:18:58 CEST] I feel that right now, nobody really knows how to deal with these files. in most cases its just ffmpeg doeesnt play it or gstreamers ffmpeg plugin isnt working" [22:33:39 CEST] BBB: does vp9 do anything special for it's alpha coding? [22:33:58 CEST] to aid sharp edges etc [22:34:03 CEST] no [22:34:07 CEST] it a separate stream [22:34:15 CEST] I suppose its typically coded at a lower Q since its veyr simple [22:34:24 CEST] but no idea [22:34:30 CEST] its not in the main bitstream [22:34:33 CEST] hmm, still a bit annoying then, whole point of alpha is to have clean edges [22:35:43 CEST] yes [22:35:49 CEST] but I mean, Im not asking them ro change the coding [22:35:55 CEST] Im just asking them to provide an implementation [22:36:31 CEST] I just wonder if anybody thought through how to code alpha properly [22:38:52 CEST] likely noto [22:39:01 CEST] why do research if you can hack it together quickly and ship it [22:39:05 CEST] :-p [22:39:11 CEST] its not like h264 did a good job at this [22:39:32 CEST] apple have their own alpha in 264 [22:39:34 CEST] basic rle [22:46:27 CEST] arent there like 3 different ways to code alpha in webm, or something [22:46:33 CEST] or did they finally decide on one officially =p [22:47:14 CEST] :D [23:11:32 CEST] nevcairiel: 2, right? the one in webp and the one in vp8/alpha/webm [23:11:51 CEST] and isnt the one in webp for lossless rgba only or so? [23:11:54 CEST] I dont recall exactly [23:12:56 CEST] BBB: no, webp also supports yuva420p for lossy+alpha [23:13:21 CEST] ah [23:13:36 CEST] does that use the same mechanism as rgba lossless? [23:13:39 CEST] then maybe there are 3 ways [23:14:54 CEST] i should tweet about 3.1.1. what should i say about it? didn't really follow the details. [23:14:55 CEST] all i remember is that the alpha data is practically encoded as "side-data" in the mkv/webm layer and nort part of the video codec, which already screams fail to me [23:16:30 CEST] webp has the alpha bitstream separate from the vp8 bitstream, in a different chunk [23:16:46 CEST] looks like it's used for both lossy and lossless [23:16:54 CEST] ie. alpha is an afterthought, thats never a good recipe for success [23:20:24 CEST] llogan: maybe just say we released 3.1.1 and it has fixes for people that "experienced problems" upgrading from 3.0 to 3.1 with their applications or something like that [23:22:38 CEST] or maybe not even that. most users looking at twitter would probably only care about the cli and that didn't have any issues [23:23:57 CEST] nevcairiel: yeah, the ALPH chunk is part of the "extended" format [23:24:19 CEST] same with animated webp data [23:24:41 CEST] did webp ever see any kind of adoption? [23:24:56 CEST] chromium based browsers only afaik [23:25:00 CEST] at least webm is kinda getting more widely supported in stock browsers [23:25:12 CEST] even MS signed up for that [23:25:13 CEST] firefox refuses to adopt it [23:25:27 CEST] firefox politics are just weird [23:26:58 CEST] they did adopt webm/vp8 and webm/vp9 like everyone else, so it's not just "google bad" or whatever [23:27:17 CEST] jamrial: how about, "We just released FFmpeg 3.1.1 which fixes a few API related issues present in the recent 3.1 release." [23:28:01 CEST] Apple seems to flat out not bother with webm as the last hold out [23:28:07 CEST] safari and iOS have zero support [23:32:10 CEST] google also released a WIC component to add webp support to Windows Photo Viewer and such [23:32:38 CEST] heh [23:34:21 CEST] it's for vista, 7 and 8, but i installed it on 10 and works fine. seems to work with everything except animated webp [23:35:01 CEST] llogan: should work i guess [00:00:00 CEST] --- Sat Jul 2 2016 From burek021 at gmail.com Sun Jul 3 02:05:02 2016 From: burek021 at gmail.com (burek) Date: Sun, 3 Jul 2016 02:05:02 +0200 (CEST) Subject: [Ffmpeg-devel-irc] ffmpeg.log.20160702 Message-ID: <20160703000503.53BCA2AD6001@apolo.teamnet.rs> [00:46:30 CEST] cropdetect returns: x1:0 x2:719 y1:0 y2:575 w:720 h:576 x:0 y:0 pts:1500440 t:1500.440000 crop=720:576:0:0 , but I have no idea how to use this info to create a new command I can use [00:47:20 CEST] crop=720:576:0:0 [00:47:26 CEST] that's the crop command you should use [00:47:47 CEST] or that you would normally use, but it looks like cropdetect hasn't detected anything [00:48:07 CEST] you probably want to adjust the limit and round values of cropdetect [00:48:20 CEST] https://ffmpeg.org/ffmpeg-filters.html#cropdetect [00:48:36 CEST] furq, why didnt it detect anything? if I get that output it means it detected something... [00:48:58 CEST] it means it thinks no cropping is needed [00:49:08 CEST] if you think it's wrong then adjust the params [00:50:30 CEST] e.g. -vf cropdetect=32:2 [01:05:55 CEST] I wonder if Im the only non native speaker finding it painfully slow to learn to run ffmpeg just by reading the manpages [01:08:45 CEST] there is a lot of technical information involved... [01:09:36 CEST] about the topic: i think ffmpeg 3.0.2 in fact is already in debian stable backports and next stable version :) [01:09:48 CEST] ffplay -i YourMovie.mp4 -vf "cropdetect=24:16:0" did play the file as I want it. On the cli I found this info: crop=720:576:0:0. It looks ok, so I proceed to ffmpeg -i YourMovie.mp4 -vf "crop=720:576:0:0" YourCroppedMovie.mp4 , but the output is not cropped... [01:10:04 CEST] from: https://superuser.com/questions/772795/is-it-possible-to-autocrop-black-borders-of-a-video-with-ffmpeg [01:10:38 CEST] you have to seek into the video to where it it can see the black border around the video [01:10:57 CEST] o... [01:12:04 CEST] so ffplay -i YourMovie.mp4 -vf "cropdetect=24:16:2000 (2000 frames = 2000/24=83 seconds [01:12:09 CEST] right? [01:12:34 CEST] I just leave it at defaults, then seek deep into the movie. maybe half way [01:15:41 CEST] on ffplay there is no positon bar, but by randomly klickling on left or right ethe movie advances or goes back ... [01:15:44 CEST] is that normal? [01:21:54 CEST] iirc the whole screen is a seek bar. click the far left to seek to the start, click the far right to seek to the end. [01:26:02 CEST] i'm sending a video myself via rtmp (from ffmpeg to nginx). There are missing frames at the nginx recordings. A local recording shows no problems (-tee "/local.flv|rtmp://") [01:26:40 CEST] same problem avoiding "-f tee" [02:23:59 CEST] with the seek timecode syntax if a user enters just '300' for a time will that be interpreted as '300' seconds, seeing as double digits are accepted. Or does it have to be explicitly written as minutes? [02:24:35 CEST] It sucks not being a native speaker, I struggle to make me understood [02:25:18 CEST] Spring: it can accept seconds or 01:23:45.67 [02:26:01 CEST] llogan, so an input of 300 would be understood by ffmpeg as 5 minutes? [02:26:19 CEST] good to know [02:26:35 CEST] 300 or 00:05:00 would be the same [02:27:19 CEST] Excellent. Was wondering whether I'd need to do some calculations on it (which I may anyway). [02:37:33 CEST] furq: ..out of curiosity, where is -2 documented? I've seen -1:180 as a possible value, but never -2... [02:39:56 CEST] lerner: "left/right [keys]: Seek backward/forward 10 seconds." [02:43:03 CEST] CoJaBo: https://ffmpeg.org/ffmpeg-filters.html#scale-1 [02:43:19 CEST] If one of the values is -n with n > 1, the scale filter will also use a value that maintains the aspect ratio of the input image, calculated from the other specified dimension. After that it will, however, make sure that the calculated dimension is divisible by n and adjust the value if necessary. [02:45:43 CEST] furq: Huh. Dunno how I missed that [02:52:03 CEST] is it possible to select the first frame, and use it as an overlay for the rest of the video? [03:00:33 CEST] ffmpeg -i in.mp4 -filter_complex "[0] select=1 [1]; [1] scale=320:240 [1]; [0] [1] overlay=W-w-5:50" output.mp4 [03:01:04 CEST] this is almost what I want, except it not just the first frame [03:14:21 CEST] kingsob: never done that but i gess you can extract the first frame and, as a second step,watermark the video [04:04:30 CEST] would have been -filter_complex "[0:v]select=eq'(n,1)',scale=iw/2:-1[fg];[0:v][fg]overlay [07:32:42 CEST] Hi trying to convert DTS 5.1 to aac stereo and ac3 5.1. For some reason the aac keeps coming out as surround 5.1. The ac3 works fine. command line here: [07:33:02 CEST] ffmpeg -v debug -i Deadpool\ 2016\ 1080p\ BluRay\ x264\ DTS-JYK.mkv -t 00:00:10 -map_metadata 0:g -map 0:0 -map 0:1 -map 0:1 -c:v copy -c:a:0 aac -ac 2 -af "pan=stereo|FL=FC+0.6FL+0.2BL|FR=FC+0.6FR+0.2BR" -c:a:1 ac3 -ac 6 -movflags +faststart deadpool.mp4 [07:33:44 CEST] Matt___: -ac:0 2 -ac:1 6 [07:33:53 CEST] or maybe -ac:a:0, i forget [07:34:22 CEST] cmd output here:https://gist.github.com/snoby/701cceb1eaf531337618f29ba1917103 [07:35:53 CEST] Here is the crazy part. If I leave out the -c:a:1 basically the part of the cmdline that does the ac3 transcode the aac portion works fine [07:36:14 CEST] I'm using ffmpeg 3.0.2 [07:39:59 CEST] Here it is working with just the ac3 portion removed: http://pastebin.com/8FNzL5Jn [08:13:33 CEST] ok I just posted the question up to the ffmpeg forum, hopefully i can get some insight into why this is happening [10:08:40 CEST] How do I enable everything in ./configure, and is doing that a good idea? [10:27:22 CEST] it doesn't look like you can do it with one flag. run ./configure --help to get a list of things you can enable. that's a lot of dependencies though [10:33:50 CEST] Yeah, I skipped a lot of them. [10:34:22 CEST] I don't think I'll need to convert x265 to VHS today :P [10:35:13 CEST] i came across some weird google video format the other day. it is no longer supported and i don't know of anything that will convert it [10:35:52 CEST] Not VP6? [10:36:37 CEST] i don't think so. i'll try to find the file again [10:37:02 CEST] Idk if VP6 is a thing - I'm just watching $ make run down. [10:41:07 CEST] there it is [10:41:09 CEST] *.gvi [10:41:14 CEST] Lol [10:41:58 CEST] So I'm trying to compile VLC, and its complaining about libswscale.a and libavformat.a. [10:42:13 CEST] Which I've just compiled/installed with the latest snapshot. [10:42:29 CEST] /usr/bin/ld: /usr/local/lib/libswscale.a(swscale.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC [10:42:33 CEST] Thoughts? [10:42:54 CEST] make sure you ./configure to make shared libraries [10:43:07 CEST] and ./configure with the pic option [10:43:34 CEST] ffmpeg's ./configure ? [10:43:39 CEST] --enable-pic --enable-shared [10:43:40 CEST] yeah [10:43:44 CEST] Oh I see it. [10:43:47 CEST] Ty [10:44:52 CEST] https://paste.fedoraproject.org/387363/74490421 [10:45:38 CEST] i think i got a similar error before i added the --enable-shared flag [10:47:05 CEST] i built ffmpeg with every codec my distro has and built mpv against it and it has no idea what to think about a *.gvi file [10:47:14 CEST] Lol [10:47:19 CEST] ffprobe say anything? [10:47:54 CEST] i'll try [10:48:34 CEST] hmm says divx [10:48:43 CEST] i wonder what the confusion is [10:49:11 CEST] Action: bollocks_k tries to transcode it [10:50:09 CEST] seems to be working [13:40:16 CEST] question about time codes (again): I just tested and surprisingly ffmpeg recognized 2:34 as being 2 minutes and 34 seconds [13:40:38 CEST] the docs don't indicate that this format is acceptable but it is apparently [13:41:11 CEST] what happens when the video is say 3 hours, would it consider it then to be 2 hours and 34 minutes? [13:47:24 CEST] also I don't understand the 'No bitrate set, defaulting to 96kbps' message during encoding. I've set it to -qscale: 2, shouldn't that tell it the desired bitrate? [13:51:04 CEST] Spring: the parsing of the time is not related to the target duration [13:51:11 CEST] it's based solely on its format [13:51:32 CEST] 2:34 will always be 2 minutes 34 sec [13:52:01 CEST] qscale is a "quality" factor as opposed to a bitrate [13:52:09 CEST] it generally implies variable bitrate [13:52:13 CEST] if supported [13:52:40 CEST] but i feel like this is an audio bitrate, so probably you want qscale:a ? [13:58:04 CEST] ubitux, yeah I actually use qscale:a but forgot the :a when posting here [13:58:20 CEST] thanks for the confirmation about the timecode syntax [15:26:52 CEST] I'm trying to reduce the size of mp4 video files using the command : ffmpeg -i interface.mp4 -b 1000000 -strict -2 output.mp4 ended up 59MB instead of 36MB originally [15:27:20 CEST] is there is a fixed formula to reduce size of videos using ffmpeg? [15:29:53 CEST] well, you didn't specify audio settings.. check the output of ffmpeg to see what it actually did to your audio and video [15:41:23 CEST] DHE: what is the check command? [16:03:10 CEST] yes checked and ACC codec was not changed ... ffmpeg -i output.avi -acodec mp3 -vcodec copy output2.mp4 ... remains the same [16:18:10 CEST] Still can't win my fight with iLBC. Any ideas? [16:33:27 CEST] Hi. What's the preferred way to convert a video to a fast forward one? I'm going to discard audio anyway, so increasing fps is just fine (after that I'll re-process it and adjust fps to 60 or 30). [16:33:30 CEST] Oh. [16:33:33 CEST] Dang.- [16:33:42 CEST] Action: IHAVENONICK jumps. [16:41:08 CEST] Boom., [16:51:24 CEST] is there a way to set the window size without and degradation in the file. scale= always lowers the quality, I just want the same file quality but have it open in a smaller window [16:54:47 CEST] sor_: So you want the video file to tell the player that it should show smaller video? [16:55:04 CEST] Zucca, yes [16:55:11 CEST] Afaik, you always lose quality when scaling. [16:55:19 CEST] Even if it's done by the player. [16:55:45 CEST] maybe select a different scaler than the default? [16:56:42 CEST] Zucca, when I resize with the player I can adjust it and it maintains quality... I just want it to open like that [16:57:01 CEST] DHE what do you mean [16:57:37 CEST] sor_: Idk, but if there's a way to fake the dpi (tell higher dpi that what it is) that might be the way. BUT will the player actually show the maller window is only up to the player. [16:58:15 CEST] I remember I once and a image program that read the dpi values from jpeg images and zoomed them to match the actual size. [16:58:25 CEST] *once had [16:59:00 CEST] But other image programs only shoved the image in native resolution (pixel for pixel). [16:59:09 CEST] I want to adjust it just like when you do with the player [16:59:24 CEST] metadata perhaps? [16:59:50 CEST] sor_: You are asking for a feature that not many players (if none at all) can conform. [17:02:11 CEST] Zucca, players? all player I now can resize a window [17:02:46 CEST] sor_: But can they resize the window _automatically_ based on some metadata on video? [17:02:59 CEST] I don't think so. [17:03:24 CEST] Zucca, that was just a guess. I don't know how they do it... that is my question [17:04:21 CEST] Zucca, do you know how to change the metadate size? perhaps I shall try [17:05:01 CEST] sor_: Metadata depend on container format I guess. [17:05:20 CEST] You maybe should just wait for someone more exprienced to answer. [17:05:45 CEST] Zucca, ok thanks [17:06:24 CEST] -metadat key=option I just don't know what the key is [18:15:32 CEST] Hi! I'm experiencing some crashes using ffmpeg's rdft, and I was wondering if I was doing something wrong. The relevant code is http://pastebin.com/Jx3rJ7G0 here, and the backtrace thre http://pastebin.com/jHMsGck8 . Is there some problem with proper memory allocation? [18:40:37 CEST] built ffmpeg with decklink support, but still cannot capture from blackmagic intensity pro 4k [18:40:41 CEST] http://pastebin.com/7JZuLFJc [18:43:24 CEST] I try to capture: http://pastebin.com/1nVeMs1U [18:46:35 CEST] oh, decklink device is in the list http://pastebin.com/vJAAFZew [18:47:29 CEST] well yeah, your error is coming from the decklink module so it kind of must be around [18:52:28 CEST] Hello - wondering if it's possible to create a rectangle (using drawbox) that increases in size during playback. Trying to hardcode a "progress bar" to a video. Even though drawbox supports timeline editing, i can't figure out how to change the box shape. Any hints? [18:55:04 CEST] JEEB: so what can I do? [18:55:31 CEST] JEEB: but media express is working and I can capture video with it [18:55:36 CEST] I have nfi, never used that module nor I know if you have just failed at enabling something in the driver or something like that. the message is all that I know as well :P [18:56:13 CEST] so you can of course go look at the code if you want to. also testing building current master is a good idea as well (in general if FATE is green master is a'OK to use) [19:03:07 CEST] I'll try to rebuild [19:36:52 CEST] Hi all. Trying to rebuild ffmpeg from SRPM. I get this error: opencv not found using pkg-config .... meanwhile opencv and opencv-devel are installed. Why is this happening? Is there a way to resolve this? [19:41:46 CEST] twohot: see what it checks for and the result @ config.log [19:50:12 CEST] JEEB: https://paste.fedoraproject.org/387434/48178914/ [19:52:25 CEST] twohot: so yeah - opencv is there but not with the features FFmpeg uses [19:52:32 CEST] so that's rather simple why it fails [19:52:49 CEST] JEEB: looks like it is expecting version 2 whereas I have 3 [19:53:19 CEST] most probably yes [19:54:12 CEST] http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=007c953fca6359d9f5ca4f10332d75504926b6dd;hb=HEAD#l1828 [19:54:17 CEST] still requires it with current master [19:54:58 CEST] ouch, running bleeding edge is fun [21:04:32 CEST] what's the maximum size for rtbufsize? [21:54:20 CEST] g [22:35:33 CEST] it uses 1.5x the bitrate for half the fps :( lol. [22:36:24 CEST] can anyone help me fix "[dshow @ 0000000002392cc0] real-time buffer [Decklink Video Capture] [video input] too full or near too full (121% of size: 3041280 [rtbufsize parameter])! frame dropped!" ??? [22:52:23 CEST] pick faster encoding options. you can't keep up with the live data. or expand the buffer? [22:53:52 CEST] i'm using the fastest encoding option I think [22:54:28 CEST] Get a better CPU then. [22:54:39 CEST] isn't that the default rtbufsize [22:54:59 CEST] I've got a pretty good cpu [22:55:14 CEST] if that's 3041280 bytes then that's pretty small [22:55:21 CEST] i've tried tons of different rtbufsizes, nothing seems to change :( [22:55:28 CEST] pastebin the command [22:55:30 CEST] G:\>ffmpeg -y -f dshow -video_size 1280x720 -framerate 60 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -rtbufsize 1500M -c:v libx264 -pix_fmt yuv420p -preset ultrafast -crf 0 -c:a aac -b:a 384k -r 30 -f mpegts udp://192.168.1.97:1234 [22:55:59 CEST] Buffering 1.5GB of data seems like a bad idea to me. [22:56:13 CEST] 96gb ram, I can spare a bit :D [22:56:25 CEST] That will easily cause tons of delay. [22:56:40 CEST] latency you mean? not an issue, anything shorter than 10 mins is fine [22:57:07 CEST] But anyway, if your CPU can't keep up with ultrafast, it has to be busy doing something else. [22:57:28 CEST] when I'm running that command line, cpu is under 2.7% load [23:01:05 CEST] TAFB: rtbufsize is an input option it must go before the input, not after [23:01:18 CEST] ahhhhhhh [23:01:29 CEST] what would be a good size to try? [23:02:24 CEST] What format is the input ? [23:02:31 CEST] as in rgb ? [23:02:31 CEST] raw [23:02:34 CEST] yeah [23:03:35 CEST] ok so a single second takes up 160 megabytes [23:04:09 CEST] idk maybe try multiplying the previous value by ten [23:04:22 CEST] so it would be 30 megabytes [23:04:23 CEST] 30M [23:04:34 CEST] k. i'll try 30M, thanks! [23:04:57 CEST] I'm just guessing though, don't have experience with devices [23:05:49 CEST] testing now, looking really good so far [23:09:16 CEST] looks really really good!! thanks for the help :) http://tafb.xxx/rtbufsize_30M.png [23:09:53 CEST] i still don't know why it uses 1.5x the bitrate at 30fps instead of 60fps but not really important, lol [23:10:32 CEST] are you planning on encoding a million channels or something [23:10:52 CEST] because otherwise you shouldn't use ultrafast, it's the lowest quality by some distance [23:11:50 CEST] oh nvm this is lossless [23:11:58 CEST] I was told that with "-crf 0" it doesn't matter what your use "ultrafast" and "veryslow" seem to be identical [23:12:06 CEST] yeah i didn't notice that [23:12:15 CEST] slower presets should still compress better though [23:12:25 CEST] i'll give it a try, I got lots of cpu to spare [23:12:59 CEST] if the input is 60fps but I use -r 30 on the output does it still have to encode all 60fps or no? [23:13:05 CEST] no [23:14:29 CEST] nice. with the preset "slow" it uses 63mbps vs. ultrafast at 87mbps [23:14:38 CEST] it looks like ffmpeg is only using 8 out of my 24 cores?? [23:14:53 CEST] it should use all of them [23:14:57 CEST] try setting -threads 24? [23:15:01 CEST] k. 1 sec. [23:15:17 CEST] it defaults to your number of virtual cores, there's no point in doing that. [23:15:39 CEST] i have 12 real cores (24 including virtual) [23:15:43 CEST] so use -threads 12 then? [23:15:56 CEST] it doesn't matter if it's using all your cores if you're limited by input framerate [23:16:12 CEST] also with 24 ht threads it'll default to -threads 36 [23:16:40 CEST] but maybe I can use slower or slowest instead of slow if I can use all 12/24 :) [23:16:54 CEST] it should use them if they're needed [23:17:01 CEST] you can use whatever you want with that many cores. [23:17:04 CEST] TAFB: when you said it's not using all your cores, does it have threads for them and they're not utilized or does it not have threads for them? [23:17:05 CEST] try with -preset placebo and see what happens [23:17:25 CEST] on the cpu graph, only 8 cores are at about 80% utilization, the rest are idle. [23:17:39 CEST] yeah that doesn't really mean anything if the output isn't lagging [23:17:41 CEST] TAFB: check something like htop [23:17:43 CEST] you're limited by input framerate [23:18:00 CEST] lots of dropped frames with "placebo" only using 8 cores. [23:18:01 CEST] something that'll list the threads and their individual usage [23:18:22 CEST] you could switch to slice threading (I think frame is default) [23:18:37 CEST] c_14: I'm on windows :D [23:19:00 CEST] oh yeah i guess frame threading with 36 threads isn't great with a realtime source [23:19:41 CEST] Wait, I don't think x264 has slice threading [23:19:47 CEST] just frame and delay (whatever delay does) [23:20:03 CEST] it does [23:20:14 CEST] -x264opts sliced-threads [23:20:51 CEST] it's less efficient though [23:20:53 CEST] Ah, it's just not listed then [23:21:06 CEST] Probably because the wrapper doesn't handle it [23:21:30 CEST] lots of dropped frames with sliced-threads but it is using all cores :) [23:22:00 CEST] i wonder if it would use more cores with a bigger rtbufsize [23:22:05 CEST] Nah, the wrapper seems to support it [23:22:07 CEST] with frame threading [23:25:01 CEST] working nice with the slow preset, without sliced-threads. Guess I'll just have it run on 8 cores if it does it without issue. [23:26:56 CEST] hmmm, cpu getting a little toasty, 50c... will have to keep an eye on it and see if the water cooling can keep up [23:29:12 CEST] Sounds like there's something wrong with it. [23:30:09 CEST] normally sits around 37c on ultrafast [23:30:30 CEST] seems to be staying pretty constant at 50c, hasn't spuns the fans up yet [23:31:17 CEST] fwiw you might be able to get better compression with ffv1 [23:31:32 CEST] never heard of it :) [23:31:50 CEST] https://trac.ffmpeg.org/wiki/Encode/FFV1#FFV1version3 [23:31:54 CEST] the cooling of a system should be designed to keep the system from overheating even at permanent maximum load. [23:32:15 CEST] 50C isn't really close to overheating [23:33:00 CEST] these cpu's are super inefficient :D [23:33:00 CEST] Still pretty bad for water cooling [23:34:26 CEST] -vcodec ffv1 -level 3 [23:34:57 CEST] you'll probably want to tweak -threads and -slices [23:35:08 CEST] and -coder 2 gives better compression iirc [23:35:18 CEST] is -coder 2 still lossless? [23:35:28 CEST] ffv1 is always lossless [23:35:34 CEST] nice [23:36:59 CEST] ffv1 -level 3 -threads 12 -coder 2 -context 1 -g 1 -slices 32 -slicecrc 1 [23:38:05 CEST] -slices should be as low as you can make it without getting dropped frames [23:39:00 CEST] is that a high core, low clock cpu, or why are you having such a hard time encoding a single stream? [23:40:00 CEST] 32 slices is unsupported :) [23:43:32 CEST] 24 slices works, but when I open the udp stream in vlc player, I only get sound, no picture [23:44:07 CEST] vlc codec info shows no video stream, just audio [23:44:14 CEST] probably needs a really recent version of vlc [23:44:31 CEST] Rather, a vlc linked against a recent ffmpeg [23:46:33 CEST] just updated to 2.4.4 Weatherwax, will test again [23:46:45 CEST] 2.2.4 sorry :D [23:50:25 CEST] nope, still doesn't see the video stream [23:50:33 CEST] does ffv1 support udp streaming? [23:50:41 CEST] i'm not sure if mpegts supports ffv1 [23:50:43 CEST] why would that be up to the codec? [23:51:07 CEST] ahh, what I can use instead of mpegts for udp streaming? [23:53:44 CEST] nut [23:53:57 CEST] if your end point is ffmpeg too [23:54:08 CEST] it could be I guess, ffplay? [23:54:16 CEST] that works fine [23:54:18 CEST] -f nut [23:54:27 CEST] accepts anything under the sun [23:59:27 CEST] with -f nut I get tons of errors on ffplay :( 1 sec. [00:00:00 CEST] --- Sun Jul 3 2016 From burek021 at gmail.com Sun Jul 3 02:05:04 2016 From: burek021 at gmail.com (burek) Date: Sun, 3 Jul 2016 02:05:04 +0200 (CEST) Subject: [Ffmpeg-devel-irc] ffmpeg-devel.log.20160702 Message-ID: <20160703000504.90E0A18A001E@apolo.teamnet.rs> [00:22:52 CEST] anyone want to take over /r/ffmpeg on reddit? [00:23:07 CEST] someone is offering it but i don't use reddit [00:34:00 CEST] is it used? [00:34:15 CEST] and you seem more appropriate than anyone else [00:34:26 CEST] for one, everyone trusts you with root access to public resources [00:35:06 CEST] it seems that /r/ffmpeg is simply an alternative to stackoverflow, it doesnt seem overly useful as such [00:40:52 CEST] has occassional use. just thought i'd ask in case there were any reddit fans here who would be interested. [00:41:17 CEST] i never got the point of reddit, i just find it hard to navigate [01:16:16 CEST] the filters cover get that? [01:16:53 CEST] *didn't cover that [01:27:23 CEST] it did block them often but they kept mutating content. human garbage. [02:01:22 CEST] llogan: does BadContent apply only for wiki entries or also tickets? [02:02:12 CEST] also tickets. that last set might be a little aggressive. [02:02:41 CEST] 8\d{2}.\d{3}.\d{4} in particular [02:04:06 CEST] also thinking of adding: [A-Za-z]\.{4,} to maybe catch this b.u.l.l.s.h.i.t [02:05:02 CEST] my regex skills are elementary. [02:08:26 CEST] nevermind. that won't work [02:09:35 CEST] you can probably do grouping, ([A-Za-z]\.){4,} or something like that [02:13:25 CEST] yes, that will do. i keep forgetting this stuff. [02:13:38 CEST] stupid beer [02:23:01 CEST] michaelni: valgrind doesn't like the new h264-skip tests http://fate.ffmpeg.org/report.cgi?time=20160701232417&slot=x86_64-archlinux-gcc-valgrindundef [03:24:25 CEST] ffmpeg 03Michael Niedermayer 07master:febc862b53c0: avcodec/h264_parser: Set sps/pps_ref [07:51:04 CEST] Hello. Please tell me which ffmpeg mpdule can help me split up a video so that it can be displayed on multiple screens(to form a bigger display). Each part has to streamed to the corresponding machine from the server [13:32:43 CEST] michaelni: ah, sorry and thx for the fix [14:11:56 CEST] michaelni: can you test merge-libav branch again? [14:12:13 CEST] michaelni: i'd suggest testing with the sample from 6fafc62b in particular [14:22:31 CEST] stupid tech n solutions guy spamming me [18:54:16 CEST] mateo`, you could also go ahead and add a feature to the bsf, so it writes the offsets for sps and pps in an additional field. [18:54:29 CEST] That should be the cleanest solution. [18:54:38 CEST] Only problem are streams that already are annexb [19:32:10 CEST] michaelni: you're the only trac maintainer online; would it be possible to do sth about .ts files attachment being inline in the trac [19:32:14 CEST] it's very annoying [19:32:18 CEST] example: https://trac.ffmpeg.org/attachment/ticket/555/H264-TS-CanNotBePlayed-ws1.ts [19:36:49 CEST] that link just crashed my firefox [20:12:12 CEST] ubitux, fixed ts preview [20:16:32 CEST] oh, was it taking it as "typescript"? [20:19:35 CEST] no clue what t took it as but not what was written in /etc/mime.types [20:20:28 CEST] visual studio also now loves to override the .ts extension to itself nowadays [20:20:31 CEST] due to typescript [22:01:03 CEST] ffmpeg 03Michael Niedermayer 07master:07f5e75a47bf: tests/fate: Add test for ticket 3386 ([H264] [Regression] illegal short term buffer state detected) [22:35:20 CEST] ffmpeg 03Michael Niedermayer 07master:fb6b6b5166cb: tests/checkasm/pixblockdsp: Test 8 byte aligned positions [22:57:14 CEST] michaelni: thx :) [23:53:03 CEST] ffmpeg 03Michael Graczyk 07master:a1e3c7cf0fd9: libopusenc: Refactor to simplify forthcoming mapping_family parameter [23:53:04 CEST] ffmpeg 03Michael Graczyk 07master:37941878f193: libopusenc: Add channel mapping family argument [00:00:00 CEST] --- Sun Jul 3 2016 From burek021 at gmail.com Mon Jul 4 02:05:02 2016 From: burek021 at gmail.com (burek) Date: Mon, 4 Jul 2016 02:05:02 +0200 (CEST) Subject: [Ffmpeg-devel-irc] ffmpeg.log.20160703 Message-ID: <20160704000503.3D9072AD6003@apolo.teamnet.rs> [00:00:43 CEST] http://pastebin.com/UUE1Nzi0 [00:01:05 CEST] ffplay "udp://127.0.0.1:1234" [00:14:21 CEST] can av_log_force_nocolor be set via a batch script? [00:15:03 CEST] edit, forgot to add set... doy [00:15:07 CEST] works now [00:16:53 CEST] av_log_force_color on the other hand doesn't seem to be affected [00:18:47 CEST] oh, I see. That option doesn't set the color it only re-enables it if it has been disabled. [00:21:07 CEST] btw MediaInfo has always reported that files are encoded with the original source filename as a 'Movie name' metadata [00:21:27 CEST] can that be disabled via a flag? [00:32:25 CEST] I've tried -metadata name= and movie_name but neither work [00:40:56 CEST] i noticed the audio/video sync is off by about 200/250ms or so, how can I fix it with the ffmpeg live streaming? [00:50:58 CEST] turns out it was 'title' not 'name'. MediaInfo fail. [00:53:28 CEST] Hi! I just upgraded to ffmpeg 3.1 and am excited about the inclusion of Apple's AudioToolbox AAC encoder. I've looked pretty hard to find documentation but haven't been able to find any. Is VBR implemented in it? [00:54:35 CEST] "check the code in libavcodec/relevant_file.c" is how I'd say it :) [00:55:07 CEST] if it maps q or so around, it should have VBR [00:55:43 CEST] Yeah I looked briefly but most of that stuff goes over my head. [00:56:07 CEST] q does seem to pass through in my test files but I have no way of knowing what the resulting target bitrate is [00:56:16 CEST] I have no sense of scale [00:59:10 CEST] the scale is different for each encoder, so don't worry [00:59:39 CEST] also with video encoders q is usually quantizer, which is suboptimal unless constant quantizer is the only VBR mode [01:00:18 CEST] Right I've been able to find the -q scale for a bunch of different audio encoders but not aac_at [01:00:33 CEST] And it does seem to differ from aac to aac_at [01:00:46 CEST] is it limited to any range in the encoder wrapper? [01:00:53 CEST] 0-14 [01:00:55 CEST] if not, it might just be passed to the library [01:01:07 CEST] and then it does 127 - q * 9 [01:01:11 CEST] and passes that to the library [01:01:35 CEST] Doesn't seem like it, i just input 9999999 and it just let it through [01:02:08 CEST] odious: it should warn that it's out of range (if I'm reading this right) [01:02:45 CEST] Nope! Just lets it through lol: ffmpeg -i test.mkv -c copy -c:a aac_at -aq 99999999 -ac 2 test-at-vbr.mkv [01:03:57 CEST] It does clip it (but it should also warn) [01:04:20 CEST] Gotcha [01:06:17 CEST] So if I want to target ~128k I should pass -q 7? [01:11:05 CEST] No idea, I can't seem to find any info about what that value corresponds to in the audiotoolbox documentation except for the fact that: 'VBR quality in the range 0&127' [01:12:02 CEST] It seems to correlate to the afconvert library shipped with macOS [01:12:18 CEST] Trying to find what 1-127 maps to [01:12:48 CEST] 1=lowest bitrate, 127=highest bitrate it seems like [01:18:02 CEST] Thanks for your help by the way! [01:24:56 CEST] So! [01:25:01 CEST] I think I've got it [01:25:57 CEST] In the AudioToolbox vbr scale 0 results in ~40kbps and 127 typically results in ~320kbps [01:26:43 CEST] Extrapolating from that ~256 is around 110, so ~128 should be around 55 which is -q 8! [01:27:11 CEST] Which my test encodes seem to bear out coming in consistently slightly lower than 128kbps cbr [01:57:07 CEST] hello [01:58:02 CEST] Will building ffmpeg with configure option --enable-libsoxr will change the internal resampling algorithm used in libswresample? [01:59:16 CEST] i mean building libswresample [05:26:04 CEST] wish I had a clue how to display a loading/progress animation for ffmpeg in batch, to replace the regular output [07:14:50 CEST] Hey if I do a ffmpeg -i "concat:1.MTS|2.MTS" output.mp4 is the conversion by default at maximum quality? [07:17:51 CEST] no [07:18:13 CEST] the conversion is at the default for mp4, which is x264 at crf 23 and aac at some bitrate or other [07:18:40 CEST] you probably want -c copy if the streams are compatible with mp4 [07:46:58 CEST] Hy [07:47:19 CEST] Morning everybody [14:50:55 CEST] is there a good educational article somewhere that explains what all the things set in the "colorspace" filter mean (colorspace, transfer characteristics, color primaries, and color format)? [15:00:03 CEST] basically stuff to convert YCbCr<->RGB and the EOTF to use during playback [15:01:11 CEST] also the colorspace filter is one of the greatest examples of how people don't want to touch the mess that is swscale [15:01:21 CEST] and instead just make random filters for the specific functionality they want :D [15:01:40 CEST] not that it's bad, it just shows how people don't want to fix/touch/use swsacle [15:01:42 CEST] *swscale [15:02:12 CEST] also first of all you should check the FFmpeg docs on the filter for the actual variables and what they mean [15:02:16 CEST] https://www.ffmpeg.org/ffmpeg-all.html#colorspace [15:02:25 CEST] then you can look up what those things mean [15:03:16 CEST] "The filter converts the transfer characteristics, color space and color primaries to the specified user values. The output value, if not specified, is set to a default value based on the "all" property. If that property is also not specified, the filter will log an error. The output color range and format default to the same value as the input color range and format. The input transfer characteristics, [15:03:22 CEST] color space, color primaries and color range should be set on the input data. If any of these are missing, the filter will log an error and no conversion will take place." [15:19:44 CEST] if while ffmpeg is reading in a rtmp stream waht happens if the stream breakes for a second? [15:23:15 CEST] define "break" [15:23:26 CEST] if it's like EOF ffmpeg will probably finish writing [15:23:41 CEST] if it's just waiting for IO ffmpeg will probably wait [15:24:32 CEST] if there is a problem with the stream then rtmpdump quits and writes the file [15:24:49 CEST] but sometimes when recording a live stream you get "blips" :) [15:25:12 CEST] tried a infinite loop writing multiple files with rtmpdump and then joining them up [15:25:13 CEST] works okay [15:25:22 CEST] that's what i would probably do too [15:26:34 CEST] fair enought i will stick with it then [15:32:31 CEST] would -stream_loop -1 work int he same way but output to one file? [15:42:51 CEST] JEEB yes i have looked up what it works with, and what you can specify [15:43:32 CEST] i have one video i want to convert, and a reference, and it the colors are off when ffmpeg converts it. so i am assuming it guesses one of the parameters wrong, and i would need to guess which one [15:44:07 CEST] post command line and terminal output and make sure you test your output with mpv the opengl renderer of which is currently the "reference" correctness for many things [15:44:16 CEST] and when I say post, post on pastebin or so [15:44:18 CEST] and then link here [15:44:24 CEST] no long logs on the IRC channel kthx [15:44:55 CEST] and as a piece of text on some of these things that some people recommend is http://lurkertech.com/lg/video-systems/ [15:45:08 CEST] thanks [15:47:17 CEST] i was primarily interested in reading what might be happening, it might occur again [15:47:54 CEST] that's why I wanted your command line and terminal output [15:48:19 CEST] and possibly the `ffprobe`/`ffmpeg -i` output of the output file [16:02:21 CEST] ok i think i got it all. input, conversion paramters to get the test frame, and output file information https://paste.ubuntu.com/18388693/ [16:11:06 CEST] utack: I would guess gbrap121e gets somehow converted to 4:2:0 YCbCr with swscale with that [16:11:34 CEST] and since you didn't define any values I don't expect that conversion to do what you expect [16:12:02 CEST] also of course after the conversion it didn't actually specify the colorspace/trc it used for the conversion so the player is left guessing [16:12:41 CEST] you can see the actual automatic filter chain if you do -v debug when doing the re-encode [16:15:06 CEST] and that is why i have to read about this stuff, because i can't really understand all of what you just said. i will try to get that filter chain, one second [16:15:49 CEST] let's just say that the general concensus is that you want to keep swscale doing as little things as possible in your filter chains [16:16:00 CEST] because there's a really huge possibility of it just doing things wrong [16:16:09 CEST] or in a non-specified way [16:18:55 CEST] does this tell you what it is doing at the moment https://paste.ubuntu.com/18390172/ [16:19:56 CEST] yeah, it just says that it's [auto-inserted scaler 0 @ 0x15a6ec0] w:4096 h:2304 fmt:gbrap12le sar:0/1 -> w:4096 h:2304 fmt:yuv420p10le sar:0/1 flags:0x4 [16:20:03 CEST] which just says that swscale is "handling" it [16:20:18 CEST] so how could i get it right, that the output looks visually as similar as possible to the imput? i don't want to waste your time, but i would not know where to start making things better [16:21:08 CEST] and thanks for the info so far, it is already helping me to understand why it goes wrong [16:21:18 CEST] well you'd have to know the filters that you can use (probably colorspace and zscale that uses the zscale/zlib library), and then find out the closest colorspace that those two can handle [16:21:36 CEST] so that you minimize what swscale does and define the actual RGB-to-YCbCr conversion [16:21:46 CEST] I wish the scale filter would output which steps it actually takes within itself [16:24:29 CEST] ok, it seems like zscale supports AV_PIX_FMT_GBRP10 input (?) [16:24:50 CEST] or wait it also takes in 12bit because yours is 12bit [16:24:58 CEST] see the array @ https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_zscale.c#L157 [16:25:37 CEST] so build ffmpeg with zscale, tell it to use zscale, and it should work? [16:25:42 CEST] so you have to have swscale shuffle some bytes from gbrap12le to gbrp12 [16:26:10 CEST] that shouldn't be a bit depth conversion so that shoul only be a shuffle of bytes [16:26:49 CEST] then you proceed to using zscale so that you define for example BT.709 everywhere and then also make sure the encoder outputs that metadata into the stream so that players don't have to guess [16:30:14 CEST] so something a la -vf "format=gbrp12le,zscale=r=limited:p=709:t=709:m=709,format=yuv420p10" [16:30:31 CEST] this instead of just the pix_fmt [16:30:57 CEST] post -v debug of that either it fails or not [16:31:57 CEST] that first should make swscale convert to gbrp12 that zscale possibly should support according to the latest master code, and then should convert into limited range and BT.709 everything YCbCr, 10bit [16:32:19 CEST] zscale itself doesn't take the output format itself so you have to specify another format after zscale for it to know what output format you want [16:33:06 CEST] and yes it's ugly as hell to try and work around the crappiness of swscale. it's an ancient monstrocity that does so many things that people don't want to throw it away [16:33:17 CEST] yet it does many things wrong [16:34:28 CEST] zscale complains about "code 3074: no path between colorspaces" now and does not want to generate an output [16:35:10 CEST] just post the full thing with -v debug and let me see [16:36:55 CEST] on a pastebin I mean :P [16:37:46 CEST] one second, it takes a while [16:39:17 CEST] http://pastebin.com/26SySZG1 [16:39:27 CEST] thanks [16:39:29 CEST] i filtered all the cfhd debug messages out, it was chaotic otherwise [16:39:48 CEST] brb [16:40:21 CEST] i'm doing a multibitrate encoding. why ffmpeg doesn't use all cpu? (only 3 cpu used of 8 available) [16:41:28 CEST] ugh, why was gbrp12 on the list if it isn't supported >:| [16:46:47 CEST] "< Arwen> if you set p/t on the output, you need to set it on the input as well" [16:46:54 CEST] from the author of zimg [16:49:43 CEST] utack: try out -vf "format=gbrp12le,zscale=rin=full:pin=709:tin=709:r=limited:p=709:t=709:m=709,format=yuv420p10" [16:49:59 CEST] that sets input p/t as well [16:50:25 CEST] or... [16:50:25 CEST] 17:45 < Arwen> You can also just not set p/t. Then it will perform a matrix-only conversion, which is probably what you're after. [16:50:28 CEST] 17:45 < Arwen> well, zlib will, idk what zscale does [16:50:38 CEST] I guess for now we can just define those and see what zscale does [17:04:42 CEST] JEEB that seems to have done it, it looks quite similar to what i expected in mpv :) [17:04:53 CEST] and does not complain about anything while doing the conversion [17:05:35 CEST] nice [17:06:05 CEST] thanks for taking all that time. i will still have to read about what your filter chain does, my understanding of it is not great, but it works for now [17:06:20 CEST] hopefully gbrap12le to gbrp12le is not dumb in swscale but if it looks correct that's good [17:06:27 CEST] now just make sure your output got properly marked [17:06:43 CEST] so please provide a ffprobe file or ffmpeg -i file of your output [17:06:58 CEST] so we can see if the output file contains all the required tagging for players not having to guess [17:07:09 CEST] ffprobe? [17:07:17 CEST] either one is fine [17:07:26 CEST] either just `ffprobe file` or `ffmpeg -i file` [17:07:38 CEST] neither will do anything but only show info on the file [17:07:53 CEST] the file being the output file you created with the command line that worked [17:08:06 CEST] seems like it is missing [17:08:09 CEST] Duration: 00:00:10.00, start: 0.000000, bitrate: 371 kb/s [17:08:09 CEST] Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv), 4096x2304, SAR 1:1 DAR 16:9, 0.10 fps, 0.10 tbr, 1k tbn, 0.10 tbc (default) [17:08:09 CEST] Metadata: [17:08:09 CEST] ENCODER : Lavc57.48.101 libx265 [17:08:10 CEST] DURATION : 00:00:10.003000000 [17:08:14 CEST] hope the 3 line paste is ok here [17:08:27 CEST] kind of much but I'll let it slip for now ;) [17:08:39 CEST] yeah, that misses the stuff we set in zscale [17:08:57 CEST] you'll have to use x264-params to set it once more [17:09:01 CEST] ok [17:09:16 CEST] or well, x265-params since that's what you're using atm [17:11:25 CEST] -x265-params "colorprim=bt709:colormatrix=bt709:transfer=bt709" [17:11:27 CEST] it seems [17:11:41 CEST] yes trying that now, i will have the ffprobe in a second [17:11:42 CEST] because we set bt709 in zscale with the "709" parameters [17:12:14 CEST] I kind of had wished zscale's output flags would have affected the encoder, but unfortunately that doesn't seem to be the case [17:12:58 CEST] but by setting those values any player shouldn't have to guess things when playing the video, instead the colorspace values are all written in the file [17:13:13 CEST] http://pastebin.com/e7RG8gSt [17:13:23 CEST] color range full is missing i guess? [17:13:32 CEST] no, YCbCr should be limited [17:13:38 CEST] ok then it is all set [17:13:41 CEST] unless you specifically are aiming for players that can handle it [17:13:52 CEST] thanks again for your help [17:13:53 CEST] mpv can, but unfortunately the rest of the world doesn't :D [17:14:01 CEST] (esp. plastic boxes) [17:14:32 CEST] but yeah, that looks good [17:15:45 CEST] :] [18:00:33 CEST] hello everyone, I am new to open source development...so can anyone help me get started with FFMPEG development? [19:56:09 CEST] can anyone comment on the quality of the new native aac encoder compared to fdk-aac? [19:57:20 CEST] does "there is no consensus about how good it is" count as a comment [19:57:45 CEST] for lc-aac, anyway [19:58:52 CEST] kubrickdave: I'd say it's "good enough" [19:59:10 CEST] ok. thanks! [19:59:13 CEST] it's definitely better than faac [19:59:19 CEST] in much the same way that i am taller than warwick davis [19:59:28 CEST] furq: haha! [19:59:30 CEST] yeah, faac was just bad :P [20:00:42 CEST] if you already have a build with fdk then use that [20:01:24 CEST] if not then the native encoder is probably fine at 128k and above [20:03:50 CEST] yeah. i would use the native encoder just for the convenience of not having to compile with fdk-aac support. [20:28:32 CEST] but I don't think it does HE mode yet [20:28:39 CEST] oh he's gone [22:37:49 CEST] Zucca, when I resize with the player I can adjust it and it maintains quality... I just want it to open like that [22:38:05 CEST] is there a way to set the window size without and degradation in the file. scale= always lowers the quality, I just want the same file quality but have it open in a smaller window [22:38:36 CEST] sorry Zucca wrong paste [00:00:00 CEST] --- Mon Jul 4 2016 From burek021 at gmail.com Mon Jul 4 02:05:04 2016 From: burek021 at gmail.com (burek) Date: Mon, 4 Jul 2016 02:05:04 +0200 (CEST) Subject: [Ffmpeg-devel-irc] ffmpeg-devel.log.20160703 Message-ID: <20160704000504.706E92AD6002@apolo.teamnet.rs> [01:24:18 CEST] wow that text animation guy spammed me on facebook as well [04:39:11 CEST] ffmpeg 03Carl Eugen Hoyos 07master:d5edb6c0483b: lavf/aiffdec: Support QDMC demuxing. [13:50:42 CEST] Just thought I'd mention if you haven't seen it, https://aomedia.googlesource.com/aom - AOMedia aka Alliance for Open Media [15:32:41 CEST] ffmpeg 03Cl�ment BSsch 07master:64c619369b3c: lavc/h264_slice: use sps directly when checking for invalid 8x8 inference [17:36:54 CEST] michaelni: ping - sorry for bothering you: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=ae215e2b42dd172f6bfd9f2dad44c9d5c11884bf in the else if branch shouldn't this be > buf_size, now it's clamped if it's smaller, but the mp_decode_frame would write buf_size into buf which is a problem if its larger than the buffer. Do I see that right? [17:44:01 CEST] the second part was not changed [17:44:05 CEST] the merge just shows it oddly [17:45:23 CEST] still i wonder what happens if the following decode call happens and buf_size is larger as our buffer [17:45:34 CEST] s/as/than/ [17:46:17 CEST] which the old code seemed to have caught [17:54:08 CEST] you are supposed to use the parser to split frames in that case, the decoder would not work either way [17:56:39 CEST] and you seem to read the merge wrong, the only check that was removed is if the buffer was too small, not too big [18:02:21 CEST] hi...I am new to open source...can anybody help me get started with ffmpeg developement? [18:23:46 CEST] nevcairiel: yeah, exactly, that's my point - with that check removed. the decode call beyond will write too much data into a buffer which is too small. [18:24:32 CEST] you seem to misinterpret what the buffer size represents [18:24:53 CEST] hopefully I do, that's why I asked [18:25:00 CEST] its an input buffer [18:25:26 CEST] ah well - then all is fine [18:26:31 CEST] you dont even get to allocate output buffers yourself anymore these days [18:26:42 CEST] or if you do, it tells you how big its supposed to be first [18:32:42 CEST] smitb : sure, what os are you using? have you installed a developer environment / build system yet ? [18:33:06 CEST] smitb : have you compiled source code before? what exp level would you say you were? that will help us figure out what kind of help you need :) [18:33:09 CEST] hi Compn I'm currently running Arch linux [18:33:29 CEST] I have used cmake before [18:33:43 CEST] and also I've used git in some of my projects [18:33:52 CEST] this is my first time with any organisation [18:34:41 CEST] oh ok [18:35:24 CEST] well its pretty simple to start. you can review code and look for problems, or review bug reports and look for problems, or start helping on the ffmpeg-user mailing list and learn the code [18:36:03 CEST] can I get a link to some bugs that beginers can track down? [18:37:49 CEST] well [18:38:18 CEST] we need help with that, we dont have a list of easy to fix bugs i dont think [18:38:21 CEST] http://trac.ffmpeg.org [18:38:29 CEST] is our bugtracker [18:38:54 CEST] one min and i know of a good bug for you smitb [18:41:45 CEST] smitb : i have a sample file that you have to add to ffmpeg. ffmpeg can decode it if you add its tag into the code [18:42:11 CEST] alright [18:42:30 CEST] let me upload it here... [18:44:22 CEST] rcombs, can you take a look at "[FFmpeg-devel] [PATCH] libavcodec/mmaldec.c: add interlaced_frame and format struct to AVFrame for deinterlacing" especially the data[2] stuff looks like it needs a more clear reply than nevcairiels, and you wrote the mmal code ... [18:47:50 CEST] smitb : https://www.datafilehost.com/d/51cb171a [18:50:25 CEST] smitb : you need to add that JR24 tag to the asf demuxer (or probably riff.c) [18:50:50 CEST] ok... [18:51:11 CEST] then make a patch, like it says in our devel rules, http://ffmpeg.org/developer.html#Submitting-patches [18:51:15 CEST] and send it to the mailing list [18:51:29 CEST] ok [18:51:34 CEST] thanks for the help [18:52:34 CEST] sure no problem [18:52:53 CEST] yeah i think you just need to add the tag to the libavformat/riff.c source code. its an mjpeg tag [18:53:18 CEST] then compile the code and make sure it works. :) [19:00:30 CEST] smitb : does that look like something you want to tackle ? [19:00:43 CEST] you can look at previous commits to riff.c so you can find out what you need to do [19:00:54 CEST] http://git.videolan.org has our web git repo for easy checking [19:01:58 CEST] http://git.videolan.org/?p=ffmpeg.git;a=tree;f=libavformat [19:02:45 CEST] yeah...sure [19:03:04 CEST] should only be a one line patch :) [19:05:13 CEST] yeah...currently I'm cloning the repository...I was having some problem due to unusually slow connections in my place [19:11:37 CEST] ok Compn I guess in riff.c I'll have to add a MKTAG right? [19:14:17 CEST] yep [19:14:19 CEST] in the mjpeg area [19:15:40 CEST] ok so in the MJPEG area making a MKTAG which will have the tag JR24 right? [19:15:50 CEST] you can add a comment too, its "Quadrox Mjpeg" [19:15:50 CEST] yes [19:16:04 CEST] thanks [19:16:33 CEST] by mjpeg area, i mean just with all the other mjpeg tags [19:16:34 CEST] ehhe [19:16:50 CEST] yeah I got that :) [19:25:23 CEST] j-b : do you know of any way to organize easy bugs for new contributors ? maybe its as easy as a tag on the trac ? [19:26:39 CEST] michaelni : do you think we should add a category of easy bugs for new contributors ? what should we call it ? [19:27:08 CEST] smitb : the easy part is coding, the hard part is doing organization within the project ;) [19:27:35 CEST] Compn I'm trying to build the cloned repo...and after running I'm getting yasm/nasm not found or too old [19:27:42 CEST] yeah you should install yasm [19:28:05 CEST] one of the very few things ffmpeg relies on [19:28:39 CEST] ok...I'm using arch linux...so I guess the one available through pacman, the package manager should do right? [19:43:19 CEST] What would it take to get support for PNG's gAMA, cHRM and iCCP chunks into libavcodec? [19:43:47 CEST] Parsing the things is easy enough, but it would require plumbing the colorimetry metadata and icc profile through the APIs somehow [19:43:56 CEST] And I have no idea where to even start [19:54:07 CEST] smitb : yes that arch linux repo for yasm should do [19:54:11 CEST] hopefully [19:54:27 CEST] yes its compiled fine [19:54:43 CEST] haasn : good question. not sure what internal api you should be using for those [19:54:58 CEST] haasn : better wait for ubitux or other person who knows :D [19:59:25 CEST] Compn, people could add a keyword like "easy" to easy bugs ... [20:00:47 CEST] we also could add a drop down thingy like for priorty but not sure if its useful enough to do that, depends on the community what is preferred [20:00:47 CEST] haasn: inb4 another type of side data [20:01:11 CEST] JEEB: yeah probably [20:01:19 CEST] embedded ICC profiles are not exactly PNG-specific [20:01:44 CEST] michaelni : ok i'll write a mail to -devel then asking about it [20:02:00 CEST] embedded gamma/primaries are more of a PNG thing, but only in practice - not in principle. I think a single type of side data struct that exposes all forms of embedded colorimetry could work well [20:02:21 CEST] then the PNG, JPEG decoders etc. could all set those based on the actual metadata available to them [20:04:11 CEST] ayup [20:36:47 CEST] michaelni : sent mail to list about bug trac difficulty tag, thanks [20:36:52 CEST] Action: Compn afk [23:06:06 CEST] ffmpeg 03James Almer 07master:293484fa5e44: avcodec: add missing xmm/neon clobber test wrappers for the new decode API [23:38:32 CEST] ffmpeg 03Hendrik Leppkes 07master:1ad4471526c7: configure: disable the new optimizer in Visual Studio 2015 Update 3 [00:00:00 CEST] --- Mon Jul 4 2016 From burek021 at gmail.com Tue Jul 5 02:05:04 2016 From: burek021 at gmail.com (burek) Date: Tue, 5 Jul 2016 02:05:04 +0200 (CEST) Subject: [Ffmpeg-devel-irc] ffmpeg-devel.log.20160704 Message-ID: <20160705000504.F23262AD6009@apolo.teamnet.rs> [03:29:57 CEST] michaelni: a couple of your mingw and clang fate clients are complaining about lack of disk space [03:32:59 CEST] why does my ccache think it has a 16mb sized cache when du thinks its 6gb [03:35:46 CEST] should be fixed [10:37:18 CEST] https://gist.github.com/0d5b38b90b2c10805bdde4d877cfbb7a <-- I forget, who was asking for a CUE demuxer + a way to use that with the segment muxer to split cue sheets? [10:39:14 CEST] ^ that adds a cue demuxer that exports tracks as chapters, a segment.c feature that splits by chapter (and writes chapter metadata to each output file), duplication of attached pictures in each output segment, and attached-pic support in the FLAC muxer [10:40:46 CEST] still missing: an AVOption for cuedec to read audio from a path other than the one specified in the .cue file, an AVOption to disable the segment.c attached-pic duplication, and support for putting track (chapter) titles or other metadata in segment filenames [10:41:15 CEST] and then I can stop using XLD over SMB to split these damn cue sheets [11:36:35 CEST] was calling put_bits with #bits == 0 not allowed? [11:36:50 CEST] or was it not allowed with get_bits? [11:51:21 CEST] its not allowed with get_bits for sure, not sure what happens with put_bits, especially when the value is != 0 that you are writing [14:31:59 CEST] fyi wrt merge; the latest merge commit attempt is in my merge-libav branch (github). current issue is that it can crash (doesn't with libav). the only fix to the problem so far is to undo most of the change of the commit [14:32:08 CEST] which will probably affect further merges [14:32:29 CEST] i won't have time to work on this in for a little while, so everyone is welcome to take over [14:33:23 CEST] only crash i known is with a non shareable fuzzed sample but maybe michaelni has some more [14:34:55 CEST] shouldnt the change just move existing code into a new function, mostly? [14:35:14 CEST] i suppose it does it at a different point in time then [14:35:58 CEST] it does more than that [14:36:33 CEST] it moves some code into a function, but it also call it in some other place [14:36:51 CEST] where it can assumes it's always assume setup is not finished [14:39:27 CEST] without having a sample i can't really test anything, but one thing I saw right away is that the check for the sps staying constant between fields has gone away [14:39:35 CEST] (or between slices, to be more precise) [14:44:51 CEST] i saw more than 1 crash yestarday [14:45:07 CEST] or the day before when i tested [14:48:06 CEST] btw, the patch that removed non factorization changes and results is AFAIK working code was: http://pastebin.com/t0D0aZV7 [14:56:25 CEST] the fate failure btw is related to the pps changes not the call point IIRC [15:12:33 CEST] if someone needs a sample for the crash "./ffmpeg -i corruptfile " will crash (sample from bugzilla.libav.org/attachment.cgi?id=107) [15:12:55 CEST] or rather for a crash of the merge, didnt check if its the same crash [15:13:21 CEST] also i suspect its easy to find more crashes with a fuzzer [15:13:32 CEST] as quite a few random fuzzed files crash [15:15:39 CEST] I am going to have to spend months fuzzing ffmpeg h264 now :( [15:15:41 CEST] fuck all of this [15:49:48 CEST] kierank rage quitted again? [15:50:39 CEST] wow ... [16:11:31 CEST] i thought that there are more h264 merges comming [16:22:03 CEST] yes, at least one more wave after this commit [16:25:41 CEST] hello everyone [16:26:02 CEST] I have a problem when try to save AVFrame to png files [16:26:09 CEST] here is the source code: http://p.fdzh.org/8g8arXRZ [16:26:41 CEST] and here is the result picture: https://s32.postimg.org/ldlw79ct1/222.png [16:27:49 CEST] my original idea is to get the true color png file, but I found the color of picture is very strange, it's gray, and been split to 2 parts [16:29:06 CEST] is it the problem of my code? please help me [16:30:16 CEST] wrong channel, see #ffmpeg [16:31:18 CEST] can you give me some example code about set channel? thanks [16:34:41 CEST] i meant wrong IRC channel [16:38:24 CEST] oh, sorry [19:35:13 CEST] https://github.com/FFmpeg/FFmpeg/compare/master...rcombs:cue?expand=1 I don't recall who was asking for this functionality a while back, but I ran into the use-case and ended up implementing it [19:46:34 CEST] rcombs: i wrote a flacenc picture implementation a few years ago. your patch is almost the same as mine :p [19:46:52 CEST] mostly copied from mp3enc [19:46:59 CEST] but mine was blocked because of the whole audio buffer, so maybe yours can get in [19:47:05 CEST] yeah, i did the same [19:47:15 CEST] what blocked, then? [19:48:46 CEST] the part buffering audio until the first image packet was not well received, and the patch was blocked [19:48:49 CEST] i think because i was asked to make a common implementation for that code for both mp3enc and flacenc [19:49:17 CEST] probably would be reasonably easy to split out [19:49:42 CEST] buffer struct + generic handling routines + callback [19:49:53 CEST] i noticed luca wrote an avpacketlist api for libav so i was waiting for that, but he never commited it and then i lost interest [19:49:54 CEST] This demuxer reads a cue sheet (text file) and exports its track listing in the form of AVChapters. [19:50:02 CEST] Is it actually AVChapters? [19:50:34 CEST] j-b: huh? [19:51:07 CEST] jamrial: oh did you do anything about the whole "number of colors used" thing? [19:51:24 CEST] for gif? nope, just like you i patchwelcome'd it :p [19:51:37 CEST] just writing 0 all the time? [19:51:46 CEST] https://ffmpeg.org/pipermail/ffmpeg-devel/2013-August/146869.html [19:51:51 CEST] I didn't see an easy way to get it and I really doubt anything cares [19:52:32 CEST] no, just bailed out if gif was requested [19:52:36 CEST] I should probably set the video_codec field [19:54:04 CEST] oh, i see you're not checking for gif. in any case i'd say you should return patchwelcome for gif instead of muxing it with that field set to 0 [19:54:19 CEST] I mean, it's not really chapters, is it? [19:54:23 CEST] would that actually break [19:54:32 CEST] no idea [19:54:46 CEST] but muxing files not following the spec is not a good practice [19:54:56 CEST] Action: rcombs shrugs [19:55:12 CEST] also, the spec mentions jpg and png only if i recall correctly, so don't just mux everything from ff_id3v2_picture_types [19:55:28 CEST] heh [19:56:13 CEST] j-b: got a better way to represent them? [19:56:54 CEST] j-b: I mean, cue files are meant to be the index from a CDDA plus some meta, and CDDA track indexes are conceptually the same as chapter markers [19:58:34 CEST] a cue sheet may reference more than one input file [19:58:35 CEST] I would say, it's more a playlist of different tracks [20:01:12 CEST] well we've got no concept of playlists [20:01:29 CEST] nor of distinct tracks in one file [20:01:47 CEST] jamrial: I didn't have a sample for that; how does that work? [20:02:13 CEST] rcombs: nevermind, it supports everything from id3v2 [20:02:20 CEST] and let me check if i can find a sample cue [20:02:24 CEST] k [20:04:16 CEST] the end result of this, btw, is: `ffmpeg -i /path/to/whatever.cue -segment_chapters 1 -f segment -c copy -map 0 /path/to/album/'%02d $artist$ - $title$.flac'` [20:04:34 CEST] (optionally, substitute FLAC with ) [20:05:48 CEST] rcombs: http://pastebin.com/ERu8cwvF [20:06:11 CEST] ah [20:06:12 CEST] yuck [20:08:01 CEST] E_PATCHWELCOME; that'd probably require a bunch of stuff from concat that I'd rather not get into (along with a-priori knowledge of the duration in order to make the chapters for later discs) [20:08:11 CEST] I guess at that point you'd be better off merging this into concat.c [20:08:53 CEST] or concatdec or whatever the demuxer is called [20:27:44 CEST] why did kierank get upset btw? [20:27:49 CEST] I totally dont understand his rage [20:28:27 CEST] who knows [20:28:49 CEST] the fun part is that in the same moment he complains about adult behavior [20:30:08 CEST] you commit merges which breaks h264 [20:30:39 CEST] durandal_170: the commit breaking stuff is not yet pushed [20:30:48 CEST] that's why we were discussing it [20:30:50 CEST] durandal_170: I did not commit anything [20:31:26 CEST] he's also welcome to help with the merge if he's not happy with the result [20:32:04 CEST] trying various provocations attempt on regular schedule isn't going to help [20:32:41 CEST] whenever you change something, fuzzing would need to rerun [20:33:21 CEST] these changes are worth integrating [20:33:35 CEST] sorry for changing the codebase [20:33:53 CEST] lets not rage further [20:33:57 CEST] changes are ok [20:34:01 CEST] so what should we durandal_170, never change anything anymore? [20:34:03 CEST] why did this specifically upset him so much? [20:34:10 CEST] is there a particular reason? [20:34:18 CEST] he's like that since a few weeks [20:34:28 CEST] yes, please. lets just stop [20:34:57 CEST] nevcairiel: after fuzzing, changes must be careful [20:35:38 CEST] add fate test if you're afraid or regressions [20:36:39 CEST] yes, fate tests [20:38:10 CEST] s/or/of/ [20:38:52 CEST] jamrial: imo an OOM should fail instead of continuing with unpredictable things left out [20:39:45 CEST] if you run ouf of memory buffering audio packets, you flush them right then and there and forget about the image packet that is yet to show up [20:40:00 CEST] once you start flushing them, you're freeing memory [20:40:41 CEST] you'd also free memory by flushing the cache and erroring to the consumer [20:41:23 CEST] mp3enc originally bailed out if it ran out of memory buffering the audio packets, but we got an user on trac complaining about it [20:41:29 CEST] he had an itunes-made file with the first video/image packet at the very end of the file [20:42:06 CEST] you can easily tell ffmpeg.c not to copy the attached-pic stream [20:43:01 CEST] yes, i told him that at first [20:43:14 CEST] I'd rather not have it return a successful status code and write a valid-but-not-what-the-user-requested file [20:43:21 CEST] but the average user, like this one, isn't aware the oom is because of a video track trying to be muxed as attached pic [20:43:35 CEST] so he wouldn't think about telling ffmpeg to skip it [20:43:43 CEST] i sent a patch to make this change to mp3enc, and it was oked [20:43:53 CEST] so i don't think it's a bad solution [20:44:57 CEST] Action: rcombs waits for more people to have opinions [20:46:04 CEST] if you look at mp3enc, it will emit a warning saying it's skipping the picture stream [20:46:21 CEST] yeah [20:47:05 CEST] but if this is in a library consumer, or called by a script, or then the user's not likely to be made aware of the failure [20:48:04 CEST] you could always check for explode flag and bail out if it's set [20:48:34 CEST] hmmm, does that exist for muxers? [20:48:43 CEST] yeah [20:48:53 CEST] kode54, there is a difference between the hdcd decoder included in fb2k and the one in ffmpeg that I'm curious about. In hdcd_envelope() below the comment /* attenuate slowly */ ... [20:49:07 CEST] maybe then [20:49:34 CEST] kode54, https://gitlab.kode54.net/kode54/foo_hdcd/blob/master/hdcd_decode.c line 848 [20:49:34 CEST] Has the general policy on intrinsics been changed? This powerpc/swscale thing seems to be demonstrating exactly the problems with them... [20:49:55 CEST] kode54, https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/af_hdcd.c line 952 [20:50:56 CEST] jkqxz: don't think so, at least not for x86/arm/aarc64 [20:51:05 CEST] kode54, ffmpeg does not appear to be changing the gain at all [20:53:27 CEST] it's not incrementing or decrementing that gain variable [20:53:41 CEST] it should be ++gain then, right? [20:53:54 CEST] with a clip check [20:54:01 CEST] oh [20:54:07 CEST] jkqxz: it has not, but i dont know shit about ppc64 :) [20:54:09 CEST] I see it already does a clip check on the len variable [20:54:58 CEST] attenuate should increment it once per iteration [20:55:11 CEST] amplify should decrement it by 8 each iteration [20:55:41 CEST] oh [20:55:47 CEST] amplify already decrements it [20:55:55 CEST] so attenuate isn't incrementing it [20:56:16 CEST] yeah, it seems [20:56:39 CEST] so making the line in attenuate: APPLY_GAIN(*samples, ++gain); [20:56:43 CEST] should fix it, right? [20:56:47 CEST] yes [20:56:49 CEST] ok [20:57:04 CEST] or maybe it should be incremented outside the macro [20:57:14 CEST] in case the macro uses the value more than once [20:57:26 CEST] (is the increment calculated before it is passed to the macro?) [20:58:13 CEST] well it is only used once, but it is probably better practice to do as you suggest [21:00:20 CEST] and idk, but I think it is copied into the macro as ++gain [21:00:31 CEST] I'm really not certain about it tho [21:00:49 CEST] ffmpeg 03Paul B Mahol 07master:de30863fffae: avfilter/vf_rotate: add >8 bit depth support [21:01:26 CEST] The quoted speedups are basically zero, and in fact it's a regression in some of them. Also the submitter has implied that they are only doing it for the bounty, so it will be unmaintained. How is this useful to anyone? [21:11:12 CEST] feel free to express your thoughts on the ML [21:13:27 CEST] so arch is trying to upgrade to 3.1 and thus recompiled mpv and mpd [21:13:33 CEST] they didn't notice 3.1.1 is out [21:13:41 CEST] all that effort to undo the abi changes for nothing :p [21:16:25 CEST] jkqxz: if speedups are none, it can not be accepted [21:19:44 CEST] kode54, http://ffmpeg.org/pipermail/ffmpeg-devel/2016-July/196268.html [21:30:30 CEST] looks good [22:44:25 CEST] kode54, foo_hdcd doesn't do anything with transient filter, right? [00:00:00 CEST] --- Tue Jul 5 2016 From burek021 at gmail.com Tue Jul 5 02:05:02 2016 From: burek021 at gmail.com (burek) Date: Tue, 5 Jul 2016 02:05:02 +0200 (CEST) Subject: [Ffmpeg-devel-irc] ffmpeg.log.20160704 Message-ID: <20160705000503.99BCB2AD6007@apolo.teamnet.rs> [03:01:11 CEST] hello! a question, AAC-LC and AAC-Main profile are too different?? [03:03:12 CEST] yes [03:03:41 CEST] also what is your actual question? [03:03:45 CEST] this one is quite vague [03:05:25 CEST] Hi people I am using ffmpeg 2.1 and I use with streaming rtmp but i need to know i have some api to calcular the bitrate or some snippet or help about that. Thanks. [03:05:54 CEST] klaxa: i've a trouble with it... if i run in AAC-Main profile some SetTopBox can't decode it... problem is the CPU broadcom [03:06:18 CEST] i must use an special software decodind to run this AAC-Mail [03:06:28 CEST] if i encode in AAC-LC no problem [03:06:35 CEST] does ffmpeg even have a main profile encoder [03:06:35 CEST] well use AAC-LC then [03:06:42 CEST] i don't think i've ever seen it in use [03:07:14 CEST] klaxa: not simple, for now i would study the difference [03:07:25 CEST] HSKW: https://wiki.multimedia.cx/index.php?title=Advanced_Audio_Coding#Common_AAC_Flavors [03:08:27 CEST] what are Hulu streams?? [03:08:35 CEST] hulu.com [03:09:55 CEST] i need to transcode it with ffmpeg, is the only solution atm... need patch the physical encoder [09:25:22 CEST] Everytime I use ffmpeg "-vf" I am amazed by how much you can do with it [09:28:13 CEST] -vf is like the karma sutra too much todo use and do [09:32:33 CEST] I still don't understand why my text is bouncing around by 1 line every few frames, the positioning should be based on the baseline [09:57:33 CEST] Is there an option to get ffplay to play frames as fast as they are available from the input (a pipe from x265 via recon-y4m-exec) [11:14:12 CEST] what difference are between H264 Main 3.0 and Main 3.1 ?? [11:14:41 CEST] HSKW: https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels [11:15:49 CEST] well only Major Luma sample/macroblock and higher bitrate support? [11:16:05 CEST] higher bitrate and frame size [11:16:37 CEST] well an Baseline 3.1 is better than an Main 3.0? [11:17:00 CEST] define better [11:17:24 CEST] better quality at the same bitrate [11:17:36 CEST] probably not if main is using cabac [11:18:11 CEST] level is only meaningful with regard to constrained decoders [11:18:21 CEST] if you don't need to play something back on an old phone or something then you can just ignore it [11:19:49 CEST] did you mean level: base main high or leve 3.0, 3.1? [11:20:00 CEST] base/main/high are profiles, not levels [11:20:07 CEST] ok thanks [11:20:21 CEST] another question, minQp and maxQp parameter [11:21:13 CEST] what are? [11:21:24 CEST] https://en.wikibooks.org/wiki/MeGUI/x264_Settings#qpmin [11:21:39 CEST] in general you shouldn't touch them [11:23:13 CEST] i've minQp:4 maxQp:45 [11:23:31 CEST] encodinc at 30fps and keyframe at 60 [11:23:41 CEST] *key interval 60 [11:24:40 CEST] furq: what do you think about this parameter setted for an 640x360 VBR streaming? [11:26:04 CEST] if it looks good at a good bitrate then use it [11:26:12 CEST] those qp settings probably aren't doing anything though [11:27:13 CEST] i've an 1Mbps upload speed... Max bitrate are setted at 700kbps [11:27:44 CEST] i this is the best that i can obtain with this upload speed? [11:28:30 CEST] i have no idea [11:28:39 CEST] you haven't mentioned any settings which affect quality other than the bitrate [11:29:07 CEST] if you want higher quality at the same bitrate then use a slower preset [11:29:59 CEST] Use High at 3.0 is the only that i can support [11:30:13 CEST] that's a profile, not a preset [11:30:38 CEST] http://dev.beandog.org/x264_preset_reference.html [11:30:41 CEST] preset is 9 levels right? [11:30:48 CEST] ^ [11:32:07 CEST] a question veryslow profile require a lot cpu encoding... also in decoding require a lot of cpu??? [11:32:15 CEST] it makes no difference to decoding [11:33:06 CEST] Very Good Thanks! [11:33:19 CEST] except ultrafast which will decode faster because it doesn't use cabac [11:33:28 CEST] but ultrafast is garbage anyway [11:34:34 CEST] well in decoder side only the profile and levels, right? [11:36:09 CEST] if the decoder supports high profile then any preset should be fine [11:36:53 CEST] you might need to lower -refs though [11:38:05 CEST] i dont understand -refs [11:38:57 CEST] https://en.wikibooks.org/wiki/MeGUI/x264_Settings#ref [11:39:21 CEST] some hardware decoders don't like high -refs and -bframes values [11:39:29 CEST] i doubt it'll be a problem though [11:39:49 CEST] ffmpeg cli nowadays limits refs et al in case you have set -level with x264 [11:39:57 CEST] like level 30 for 3.0 [11:40:00 CEST] oh neat [11:40:28 CEST] just use the slowest profile that your cpu will tolerate then [11:40:34 CEST] er [11:40:38 CEST] slowest preset [11:41:53 CEST] furq: ok in encoding side most slowset preset that i can tolerate on cpu clock... on decoder side the max profile that he can tolerate [11:42:56 CEST] by "your cpu will tolerate" you mean "your patience will tolerate" [11:43:10 CEST] it's streaming so i assume it's realtime [11:43:37 CEST] any decent cpu should be able to do 360p in realtime at veryslow [11:45:05 CEST] furq: yes but if i use an I7 2th generation and a very slow profile the cpu goes at 99% load, with i7 6th generation, in the same setting cpu only 30%load [11:47:15 CEST] isn't there a preset for realtime? [11:51:33 CEST] yes but ex. i7 2th generation i cant down over medium preset...cpu in overload... with i7 6th generation i can use the veryslow preset and cpu remain at 30% load [11:53:24 CEST] won't the realtime preset pick the best that still provides realtime? [11:55:06 CEST] viric: for me better to have more quality at low bitrate instead some milliseconds of the realtime... [11:56:27 CEST] ah [14:44:12 CEST] Hi. A general question: is it possible to determine if this is the original wav file or was decoded from an mp3? E.g. if I convert from mp3 to wav back and forward multiple times I will lose quality. But is there a way to determine whether this has happened? [14:44:58 CEST] .48 [14:44:59 CEST] woops [14:45:23 CEST] you could compare the result to the original (psnr maybe?) [15:12:10 CEST] i am trying to use a video encoded using libav with the codecs aac and libx264 in