Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2016

1 participants
62 discussions

ffmpeg-devel.log.20160820
by burek 21 Aug '16

21 Aug '16

[00:26:09 CEST] <durandal_1707> michaelni: got sample? [00:28:20 CEST] <michaelni> durandal_1707, i downloaded your sample, ill fix it [00:29:26 CEST] <durandal_1707> thx [00:58:43 CEST] <jamrial_> looks like acosh is not available on msvc 2012 [00:59:11 CEST] <jamrial_> what would be better, hide the avoption inside a preprocessor check, or make ff_generate_window_func return ENOSYS if WFUNC_DOLPH is requested? [00:59:38 CEST] <cone-820> ffmpeg 03Michael Niedermayer 07master:f10ea03df3dd: avcodec/h264_parser: Factor get_avc_nalsize() out [00:59:39 CEST] <cone-820> ffmpeg 03Michael Niedermayer 07master:528171ba84b2: avcodec/h2645_parse: Use get_nalsize() in ff_h2645_packet_split() [00:59:40 CEST] <cone-820> ffmpeg 03Michael Niedermayer 07master:15dd56c093be: avcodec/h2645_parse: fix nal size [01:00:03 CEST] <jamrial_> third option would be drop msvc 2012 support for good :P [01:00:23 CEST] <jamrial_> durandal_1707: ^ [01:08:11 CEST] Action: Compn still wishes no one drops support for win98/win2k [01:11:01 CEST] <jamrial_> well, it's currently broken anyway [02:32:33 CEST] <jamrial_> michaelni: could you add the user cirrus to cc for ticket 5781? he commented but didn't add himself so he wont see my reply [02:40:20 CEST] <michaelni> jamrial_, try again, every developer should be able to edit CC now [02:41:53 CEST] <jamrial_> michaelni: yeah, i can now. thank you [07:03:10 CEST] <rcombs> so QTKit is removed in 10.12 [07:03:32 CEST] <rcombs> might be time to get rid of qtkit.m [07:18:35 CEST] <cone-925> ffmpeg 03James Almer 07master:a8e3833a61c3: x86/avf_showcqt: use the FMULADD_PS x86util macro [12:08:22 CEST] <cone-669> ffmpeg 03Roger Pack 07master:18ce63a60e1b: avdevice/dshow: satisfy alloc contract better [12:15:18 CEST] <BtbN> http://arstechnica.com/information-technology/2016/08/windows-10-anniversar… so, that's where all the issues come from... [12:34:05 CEST] <fritsch> BtbN: yeah - too bad if NSA could not see your face while you were skyping :-) [12:34:40 CEST] <BtbN> It seems like a good idea in general, but why didn't they think of this?! [12:35:28 CEST] <fritsch> cause they are idiots? [12:35:47 CEST] <fritsch> and only tested only with USB3 cameras that use uncompressed data? [12:37:36 CEST] <fritsch> there is really no other explanation, if you are Microsoft and do such a change under the hood, you need to test more than 2 devices when establishing such a thing [12:37:55 CEST] <fritsch> or at least care for a "passthrough" mode if you detect a stream you don't support [12:38:00 CEST] <fritsch> to keep backwards compatibility [13:34:03 CEST] <Compn> fritsch : implying microsoft gives a shit [13:34:25 CEST] <Compn> this will happen more and more in the future, breaking all kinds of random devices and computer systems [13:34:29 CEST] <Compn> auto update is bad. [13:38:35 CEST] <BtbN> Auto Updating has nothing to do with this. [13:38:48 CEST] <BtbN> They just plain forgot about testing a usecase of various devices. [13:39:07 CEST] <BtbN> The Update was in pre-testing for quite a while, and nobody noticed this. [13:50:34 CEST] <Compn> you're talking to the guy who ran win2k for 12 years. updates are bad :P [16:52:26 CEST] <cone-769> ffmpeg 03James Almer 07master:27ee70290ef4: avfilter/window_func: use a constant instead of acosh() [19:40:17 CEST] <cone-769> ffmpeg 03Michael Niedermayer 07master:a31e08fa1aa5: avcodec/diracdec: Check numx/y [20:36:33 CEST] <cone-769> ffmpeg 03Michael Niedermayer 07master:8b43ee4054af: avformat/mov: Check STSD atom more completely [22:32:33 CEST] <cone-769> ffmpeg 03Michael Niedermayer 07master:2624695484cd: avcodec/svq3: fix slice size check [23:04:48 CEST] <durandal_1707> michaelni: comment for crop filter? [23:05:37 CEST] <durandal_1707> I locally removed another hacky check [23:06:24 CEST] <durandal_1707> this adds support for cropping subsampled videos properly [23:29:00 CEST] <abumusa> I want to register one codec, it is not working for me.. what is the correct syntax to register only one [23:47:35 CEST] <michaelni> durandal_1707, replied [00:00:00 CEST] --- Sun Aug 21 2016

1 0

ffmpeg.log.20160820
by burek 21 Aug '16

21 Aug '16

[05:55:03 CEST] <refrijerator> hello, I am trying to record audio with like $>ffmpeg -f alsa -i hw:0,1 -t 10 out.wav and my voice sounds extremely high pitch, and the out.wav file is only 5secs long (though I recorded for 10) [05:56:05 CEST] <c_14> Sounds like an incorrect samplerate [05:56:40 CEST] <c_14> You can try running a pass with -af asetrate=blah over it [05:57:52 CEST] <refrijerator> blah? [05:58:28 CEST] <c_14> substitute blah with the sample rate you think it should be [05:58:36 CEST] <c_14> Something sane is 44100 or 48000 or thereabouts [05:58:41 CEST] <c_14> Unless your mike does 96k or so [05:58:44 CEST] <c_14> But that should be rare [05:59:05 CEST] <refrijerator> I recorded again with -ar 44100 and it is the same [05:59:22 CEST] <refrijerator> maybe I should record with another rate [05:59:26 CEST] <c_14> -ar resamples, asetrate interprets the data at a different sample rate [05:59:45 CEST] <c_14> You might want to check your alsa settings [05:59:52 CEST] <c_14> Have you tried recording with arecord from the same source? [06:00:02 CEST] <refrijerator> will do this [06:00:14 CEST] <refrijerator> which alsa settings? [06:00:27 CEST] <c_14> for the capture device [06:00:43 CEST] <c_14> Maybe alsa is misdetecting the samplerate [06:36:09 CEST] <refrijerator> thanks for your help [09:44:29 CEST] <Pantera> hi, how to install latest ffmpeg on centos 6. I was not successful [09:44:46 CEST] <Pantera> i need exact guide for this [10:11:12 CEST] <dl2s40> Pantera, just compile it by yourself? git clone https://github.com/FFmpeg/FFmpeg.git | ./configure | make | make install (root). that is what i would try. [10:31:06 CEST] <Pantera> I did it [10:31:26 CEST] <Pantera> ffmpeg version N-81401-ga8e3833 Copyright (c) 2000-2016 the FFmpeg developers [10:31:26 CEST] <Pantera> built with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-17) [10:31:26 CEST] <Pantera> configuration: [10:31:26 CEST] <Pantera> libavutil 55. 29.100 / 55. 29.100 [10:31:26 CEST] <Pantera> libavcodec 57. 54.100 / 57. 54.100 [10:31:26 CEST] <Pantera> libavformat 57. 47.101 / 57. 47.101 [10:31:26 CEST] <Pantera> libavdevice 57. 0.102 / 57. 0.102 [10:31:27 CEST] <Pantera> libavfilter 6. 52.100 / 6. 52.100 [10:31:27 CEST] <Pantera> libswscale 4. 1.100 / 4. 1.100 [10:31:28 CEST] <Pantera> libswresample 2. 1.100 / 2. 1.100 [10:31:28 CEST] <Pantera> Hyper fast Audio and Video encoder [10:31:29 CEST] <Pantera> usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}... [10:31:53 CEST] <Pantera> t version is not same with: [10:31:55 CEST] <Pantera> http://download1.rpmfusion.org/free/el/updates/6/x86_64/ffmpeg-0.10.15-1.el… [10:35:10 CEST] <dl2s40> dont spamm in irc, better use pastebin.com or such. i am pretty sure the version from github is the latest version [10:35:56 CEST] <dl2s40> it seems it is 3 hours old [12:28:03 CEST] <thewonderer14> When I run `ffplay -video_size 512x512 -pixel_format gray file.yuv` the YUV image is correctly displayed. When I rename file.yuv to just file , and call `ffplay -video_size 512x512 -pixel_format gray file`, I get the error: [12:28:12 CEST] <thewonderer14> "Invalid data found when processing input" [12:28:40 CEST] <thewonderer14> How do I tell ffplay that this is a YUV file, to treat it as a file with the .yuv extension ? [14:41:33 CEST] <Guest88475> Hi guys. Can you help me with one question? [14:44:03 CEST] <Guest88475> Sometimes DTS-HD MA depth is faked from 16 bits to 24 bits. Eac3to can track that and truncate trailing zeros with no quality loss. [14:44:54 CEST] <Guest88475> eac3to v3.24 command line: eac3to test.dtshd -analyzebitdepth ------------------------------------------------------------------------------ DTS Master Audio, 5.1 channels, 24 bits, 48kHz (core: DTS, 5.1 channels, 24 bits, 1509kbps, 48kHz) Decoding with ArcSoft DTS Decoder... The original audio track has a constant bit depth of 16 bits. eac3to processing took 4 seconds. Done. [14:44:55 CEST] <Guest88475> For example: [14:45:28 CEST] <durandal_1707> yes? [14:45:36 CEST] <Guest88475> Or, while converting: [14:45:42 CEST] <Guest88475> ac3to v3.24 command line: eac3to test.thd test.wavs -libav ------------------------------------------------------------------------------ TrueHD, 5.1 channels, 48kHz Decoding with libav/ffmpeg... Writing WAVs... Creating file "test.C.wav"... Creating file "test.L.wav"... Creating file "test.R.wav"... Creating file "test.SR.wav"... Creating file "test.SL.wav"... Creating file "test.LFE.wav"... The original audio track has a constan [14:46:22 CEST] <Guest88475> sorry for no break lines :( i'm new here [14:46:23 CEST] <Guest88475> The original audio track has a constant bit depth of 16 bits. [14:46:29 CEST] <Guest88475> Superfluous zero bytes detected, will be stripped in 2nd pass. [14:46:40 CEST] <Guest88475> Starting 2nd pass... [14:47:10 CEST] <durandal_1707> use pastebin [14:48:42 CEST] <Guest88475> How can I analyse and convert such faked streams with ffmpeg, same way eac3to does? [14:52:26 CEST] <Guest88475> I just inserted to pastebin eac3to outputs. Thanks for the hint @durandal_1707 [14:52:27 CEST] <Guest88475> http://pastebin.com/Pkn05RtC [15:10:52 CEST] <durandal_1707> Guest88475: upload short file [15:12:58 CEST] <mgpai_> Hi.. am using ffmpeg -i input.wav -b:a 192k output.mp3 for CBR. How to use ABR. Couldn't find much on it in the doumentation. [15:16:29 CEST] <fritsch> mgpai_: https://trac.ffmpeg.org/wiki/Encode/MP3 [15:16:33 CEST] <fritsch> you did not find this? [15:16:34 CEST] <fritsch> https://trac.ffmpeg.org/wiki/Encode/MP3 [15:17:30 CEST] <durandal_1707> mgpai_: add -abr 1 [15:17:34 CEST] <mgpai> Found it but for ABR info recommends https://www.ffmpeg.org/ffmpeg-codecs.html#libmp3lame-1, but could not find much even there [15:17:57 CEST] <mgpai> durandal_1707 thx.. i'll try it was trying -abr=1 ;) [15:18:52 CEST] <mgpai> Thank durandal_1707, it worked :) [15:18:59 CEST] <mgpai> *Thanks [15:19:10 CEST] <fritsch> durandal_1707: that was written in the wiki ... [15:21:30 CEST] <mgpai> fritsch It said set abr option to 1, but I didn't know the syntax. Was trying -abr=1. [15:23:28 CEST] <fritsch> yeah - no harm intended [15:29:04 CEST] <mosb3rg> so guys i was using a bash script to reload ffmpeg process, until cmd; do cmd; done [15:29:16 CEST] <mosb3rg> but im reaching some errors that dont restart naturally. [15:49:06 CEST] <relaxed> mosb3rg: that's too vague [15:52:30 CEST] <mosb3rg> i can give you a script but it contains private cookie details from my account [15:52:39 CEST] <mosb3rg> would prefer it wasnt posted publically to be searched on the web [15:53:08 CEST] <mosb3rg> i appreciate your response if your cool with at least letting me post the script privately. [15:54:01 CEST] <relaxed> do you want ffmpeg to restart forever? [15:54:19 CEST] <mosb3rg> correct. but the issue is sometimes feeds dont 100% end [15:54:22 CEST] <mosb3rg> they just thread lock and sit there [15:54:43 CEST] <mosb3rg> and i need some checking mechanism to see this kill it and restart it also [15:54:56 CEST] <mosb3rg> anything running a cookie, is too slow in professional panel managers. [15:55:10 CEST] <mosb3rg> so i need to manage it on my own instead. [15:55:38 CEST] <relaxed> do the streams give you a duration? [16:01:32 CEST] <mosb3rg> hey sorry [16:01:48 CEST] <mosb3rg> well there live, so by default they dont have the analyze probe results right [16:02:19 CEST] <mosb3rg> i theory i suppose when it stops outputting the time code for X amount of time [16:02:23 CEST] <mosb3rg> *in [16:02:38 CEST] <mosb3rg> could force a restart of the script perhaps. [18:33:49 CEST] <Natha> Hello all ! My names Natha, and Im a desesperate user of ffmpeg. Im trying to simply configure a DNxHD or ProRes encoding, but after some hours of desesperation, Ive never been able to do so. [18:34:37 CEST] <Natha> Would someone be able to help me with this ? If yes, I can provide more specfific details. [18:36:21 CEST] <Natha> specific* [18:40:04 CEST] <Natha> Here you go csbrobot http://pastebin.com/yua9nrZ1 [18:40:20 CEST] <Natha> Here you go cbsrobot http://pastebin.com/yua9nrZ1 [18:41:36 CEST] <Natha> (Console outputs on the way) [18:44:12 CEST] <Natha> http://pastebin.com/HUn9zsTP The log file was too big, so I took the « supposed to be » interesting part [18:46:25 CEST] <iive> you are trying to use mencoder, not ffmpeg [18:47:13 CEST] <Natha> Wasnt mencoder based upon ffmpeg ? (Im a complete noob at this :-/ ) [18:47:17 CEST] <iive> mencoder can use bunary codecs, but you don't need them for avc1/h264 and pcm. [18:47:43 CEST] <iive> mencoder is part of mplayer project. They use libavcodec/fformat/ etc libraries of ffmpeg [18:48:19 CEST] <iive> it's better if you use ffmpeg directly. [18:48:45 CEST] <Natha> The encoding software that I use is able to use either ffmpeg or mencoder. But everytime I tried to encode in ProRes or DNxHD, either I got a « Unknown codec » (ffmpeg part) or a « cannot find codec » (mencoder) [18:49:29 CEST] <Natha> So, I am able to use ffmpeg in my case, but I just cant get it work [18:51:59 CEST] <Natha> For instance, I did try those commands with the ffmpeg module, none of them worked http://pastebin.com/wpVbP1yL [18:59:52 CEST] <Natha> Any idea about why those are not working ? :-( [19:01:49 CEST] <iive> try `ffmpeg -codecs` and see if you can find prores in there [19:02:25 CEST] <iive> also... check if your ffmpeg is recent. [19:03:37 CEST] <Natha> Nope, not in the list [19:03:59 CEST] <iive> then it is compiled without it. [19:04:05 CEST] <Natha> And I suppose to have the latest version (3.1.2 / downloaded and installed through homebrew) [19:04:09 CEST] <iive> do you compile them on your own. [19:04:53 CEST] <Natha> Nope, I did try to do it via Homebrew, but consider me as a complete begineer [19:05:03 CEST] <Natha> Beginner* [19:05:06 CEST] <cbsrobot> Natha: Mac OSX static build for ffmpegX [19:05:18 CEST] <cbsrobot> I guess it is outdated [19:05:29 CEST] <cbsrobot> MEncoder dev-CVS-060307-04:23-4.0.1 (C) 2000-2006 MPlayer Team [19:05:32 CEST] <cbsrobot> ^this too [19:05:47 CEST] <Natha> That would make sense [19:06:06 CEST] <Natha> Is there any simple way for me to update it ? Alos, how can I install the static build of ffmepg ? [19:06:12 CEST] <Natha> Also* [19:06:33 CEST] <cbsrobot> What encoding softwre do you use ? [19:06:41 CEST] <iive> ffmpeg 3.1.2 should be recent enough. i mean, prores has been around for 5 years or more [19:06:43 CEST] <cbsrobot> can't you use plain ffmpeg ? [19:06:43 CEST] <furq> isn't the prores encoder builtin [19:06:52 CEST] <iive> so it is up to compilation options. [19:06:55 CEST] <furq> and enabled by default [19:07:00 CEST] <furq> so someone would've had to specifically disable it [19:07:05 CEST] <Natha> Thats what I thought [19:07:38 CEST] <iive> furq: any idea if some variants are licence locked? [19:07:50 CEST] <furq> gee i wonder if it's one of those cargo cult guys with the ./configure invocation longer than the script itself [19:07:51 CEST] <iive> e.g. there is decoder named preres_lgpl ... [19:08:19 CEST] <Natha> Im using a specific software developped by Grau GmbH in order to repair a bunch of corrputed .mov files (H.264/PCM) http://grauonline.de/cms2/?page_id=5 [19:08:33 CEST] <iive> doesn't ffmpeg print the configure options? when run without arguments? [19:09:06 CEST] <iive> or do i get this only because i build with debugging? [19:09:10 CEST] <Natha> In order to get the files fully repaired, the software has to reencode them, allowing me to use ffmepg or mencoder in order to do this [19:09:17 CEST] <furq> iive: it does that by default [19:09:20 CEST] <furq> or you can use -version [19:09:43 CEST] <iive> Natha: pastebin the `ffmpeg -version` output [19:09:47 CEST] <furq> also why would you reencode them to prores [19:10:30 CEST] <Natha> live http://pastebin.com/mm9Qn8cm [19:10:56 CEST] <furq> pastebin the output of `ffmpeg -codecs | grep prores` [19:10:58 CEST] <Natha> furq because the basic reencoding process makes an awfull reencoding [19:11:16 CEST] <Natha> (Lots of blocking) [19:11:18 CEST] <furq> i was going to suggest using rawvideo but i guess that doesn't play nice with mov [19:11:55 CEST] <Natha> furq http://pastebin.com/2AQWycSW [19:12:14 CEST] <Natha> Never heard about rawvideo [19:12:17 CEST] <furq> so you do have a prores encoder then [19:12:44 CEST] <furq> are you sure this software isn't using its own build of ffmpeg or some bullshit like that [19:13:02 CEST] <iive> or rather you should have one... [19:13:04 CEST] <Natha> I sincerely have no idea about this [19:13:23 CEST] <iive> only single codec is disabled jpeg2000 [19:13:26 CEST] <furq> -c:v prores will not give an "unknown codec" error [19:13:29 CEST] <Natha> All that I know is that other commands for other codecs work [19:13:41 CEST] <furq> iive: http://pastebin.com/2AQWycSW [19:13:47 CEST] <furq> DEVIL. prores Apple ProRes (iCodec Pro) (decoders: prores prores_lgpl ) (encoders: prores prores_aw prores_ks ) [19:13:48 CEST] <iive> Natha: pastebin `ffmpeg -codecs` too [19:13:51 CEST] <furq> he just did [19:14:33 CEST] <furq> but yeah if it gives that error then this software isn't using that ffmpeg [19:14:57 CEST] <Natha> live http://pastebin.com/SFU5y90t [19:15:11 CEST] <Natha> So, does it mean that Im stuck with it ? :-( [19:15:37 CEST] <furq> you could try finding the ffmpeg it is using and replacing it [19:16:26 CEST] <Natha> furq like this one ? https://cl.ly/3k2W2w062h1W [19:16:40 CEST] <furq> that's probably it [19:16:47 CEST] <furq> delete that and symlink the one from homebrew in its place [19:17:15 CEST] <Natha> Im sorry, but& Whats a symlink and how can I do it ? [19:17:53 CEST] <iive> 2011 [19:17:57 CEST] <iive> so 5 years old. [19:18:05 CEST] <iive> \o/ [19:18:24 CEST] <Natha> live and since ProRes has been included with ffmpeg since 2012& (if my infos are right) :D [19:18:32 CEST] <iive> just replacing it might be trouble... as some syntax has changed. [19:19:49 CEST] <Natha> What would be the best way to replace it correctly ? [19:28:42 CEST] <Natha> I did try to replace it with a new one freshly downloaded from the ffmpegs website, restarted the software and tried those commands : http://pastebin.com/wpVbP1yL [19:29:15 CEST] <Natha> Log file still says « Cannot find codec NAME OF THE CODEC in libavcodec.. » [19:29:18 CEST] <Natha> :-( [19:42:52 CEST] <Natha> So, what do you think ? May I be able to update the ffmpeg version of the software ? Or should I stop dreaming about getting a clean ProRes file ? :-/ [19:50:45 CEST] <iive> mencoder is linked staticly, so libraries won't change, because you've changed another exe... [19:50:49 CEST] <iive> try ffmpeg [19:51:50 CEST] <durandal_1707> Pay them to update software [19:53:32 CEST] <Natha> I did try with ffmpeg after replacing the old one with an updated version [19:53:41 CEST] <Natha> It still doesnt work :-( [19:53:50 CEST] <Natha> And yes durandal_1707, Ill drop them a mail... [20:02:15 CEST] <Natha> Well, I guess I wont be able to get further into this issue. [20:02:42 CEST] <Natha> Many thanks for your help furq live cbsrobot [22:09:14 CEST] <VamoMenem> hi! im now using nvenc whit a quadro m4000 card to encode in h264 but ffmpeg still using 70% of cpu, have someone any clue about why ffmpeg still using cpu? [22:10:11 CEST] <BtbN> Because something else you are doing needs a lot of CPU. [22:16:49 CEST] <aurox> hello, I am compiling ffmpeg-3.1.2 and get the following error in make: http://pastebin.com/TLphV1ce [22:16:57 CEST] <durandal_1707> VamoMenem: without full command, it is guessing [22:17:29 CEST] <aurox> Looking in the source tree, I can not find where kAudioFormatMPEG4AAC_ELD would be defined either [22:18:14 CEST] <durandal_1707> that is from 3d party lib [22:19:05 CEST] <VamoMenem> ffmpeg \ -i http://192.168.100.254:2044/rtp/239.255.7.2:5004/ \ -acodec libfdk_aac -ar 44100 -b:a 64k \ -vcodec h264_nvenc -preset medium -profile:v main -level 4.1 -b:v 300K -minrate 300K -maxrate 300K \ -f ssegment \ -segment_list /home/dvb/www/swapb/ch9/info.m3u8 \ -segment_list_flags +live \ -segment_atclocktime 1 \ -hls_allow_cache 0 \ -segment_time 4 \ -segment_list_size 3 \ -segment_wrap 3 [22:19:20 CEST] <VamoMenem> wait i put it line by line [22:19:28 CEST] <durandal_1707> Nope [22:19:33 CEST] <VamoMenem> ffmpeg \ [22:19:40 CEST] <durandal_1707> use pastebin [22:19:41 CEST] <VamoMenem> -i http://192.168.100.254:2044/rtp/239.255.7.2:5004/ \ [22:20:39 CEST] <VamoMenem> http://pastebin.com/FZfynM84 [22:20:56 CEST] <VamoMenem> i think i dont not doing nothing more than segmenting [22:22:09 CEST] <durandal_1707> how much CPU is used if you do not encode audio? [22:22:21 CEST] <VamoMenem> lets me check that [22:23:20 CEST] <VamoMenem> the same, like 50% [22:24:19 CEST] <durandal_1707> hmm, dunno it's bit to much [22:26:35 CEST] <VamoMenem> if i do the same whitout nvenc cpu is 70% [22:27:15 CEST] <VamoMenem> i think nvenc must absorb more than 20% of cpu usage [23:27:59 CEST] <abumusa> I want to register one encoder only, it is not working with me [23:28:06 CEST] <abumusa> how do you register only one codec? [23:29:47 CEST] <relaxed> what do you mean register? [23:32:10 CEST] <c_14> I believe he means using avcodec_register() [23:38:34 CEST] <c_14> abumusa: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/allcodecs.c?l=38 [00:00:00 CEST] --- Sun Aug 21 2016

1 0

ffmpeg-devel.log.20160819
by burek 20 Aug '16

20 Aug '16

[00:27:30 CEST] <durandal_1707> michaelni: those h264 changes, got new reports? Or those are old? [00:30:38 CEST] <jamrial_> Dresk|Dev: look at avcodec_parameters_to_context(), if you haven't already [00:31:44 CEST] <jamrial_> you need to call it after avcodec_alloc_context3 but before avcodec_open2, to pass the stream codec parameters to your manually allocated avcodeccontext [00:32:50 CEST] <jamrial_> you're right that it's currently poorly documented. the avcodec_open2 doxy should probably have a line about it [03:22:09 CEST] <michaelni> why does everyone quit after asking a question [03:23:16 CEST] <michaelni> and before one can awnser [03:24:57 CEST] <cone-254> ffmpeg 03Michael Niedermayer 07master:237207645b36: avcodec/rawdec: Fix bits_per_coded_sample checks [03:24:57 CEST] <cone-254> ffmpeg 03Michael Niedermayer 07master:2a3720bc22d9: avformat/swfdec: Move packet size check before side data allocation [03:28:34 CEST] <jamrial_> michaelni: if you mean paul, it's kinda late for him right now so it makes sense he left. also his connection is often spotty [11:04:23 CEST] <cone-941> ffmpeg 03Michael Niedermayer 07master:a453bbb68f3e: avformat/swfdec: Fix inflate() error code check [14:50:54 CEST] <cone-095> ffmpeg 03Michael Niedermayer 07master:9ffe44c5c75c: avcodec/indeo2: check ctab [16:06:01 CEST] <durandal_1707> michaelni: see above [16:15:38 CEST] <cone-095> ffmpeg 03Umair Khan 07master:4f6f56114e56: avformat/movenc: allow rewriting extradata [16:15:39 CEST] <cone-095> ffmpeg 03Michael Niedermayer 07master:ca906e81909d: avformat/movenc: Free extradata after successfull allocation of new instead of before [18:03:13 CEST] <cone-095> ffmpeg 03Paul B Mahol 07master:0d8b6a15ddca: avfilter/vf_histogram: make foreground and background opacity configurable [19:47:29 CEST] <durandal_1707> michaelni: so there's no way to loop audio without reinitializing? [19:49:43 CEST] <CFS-MP3> michaelni: Just submitted a new version of SCTE-35, fixes the crash you reported on the previous one for one of the test files [20:02:53 CEST] <BtbN> Is there a way to find out the type of a memory address? Specifically, if it's uswc memory or not. [20:03:45 CEST] <nevcairiel> no [20:04:05 CEST] <BtbN> Is there no table somewhere to find out if it's in a range of uncachable memory? [20:04:39 CEST] <nevcairiel> nothing even remotely portable [20:04:49 CEST] <BtbN> Well, it only has to work on linux. [20:15:11 CEST] <fritsch> you also cannot check vaapi / driver as they might do it differently depending on the driver / gpu gen [20:18:37 CEST] <BtbN> The movntdqa based copy code is notably slower on normal memory, so knowing when to use it would be good. [20:19:00 CEST] <nevcairiel> ime its not really slower [20:19:23 CEST] <fritsch> afaik it was factor 4 slower [20:19:27 CEST] <BtbN> might have just been my test-code then [20:19:40 CEST] <fritsch> i think btbn tested it with a simple memcpy [20:19:47 CEST] <fritsch> so not much you can do wrong there :-) [20:20:02 CEST] <BtbN> Well, I compared against av_image_copy_plane iirc [20:20:05 CEST] <nevcairiel> these instructions have certain restrictions on how to use them [20:21:13 CEST] <nevcairiel> like always unroll into groups of 4 [20:21:33 CEST] <BtbN> I also used intrinsics for the test [20:21:55 CEST] <nevcairiel> anyway trying to transparently shoehorn that into existing APIs is like not a good idea [20:22:08 CEST] <nevcairiel> better to make a new one and let the calling code decide [20:22:57 CEST] <fritsch> the unroll and the alignment should not be an issue in that regard [20:23:10 CEST] <fritsch> as ffmpeg's buffer fullfil all the needs this sse4 copy needs [20:23:37 CEST] <nevcairiel> but still needs to be written like that, because if you use it without the unroll it will be slower [20:24:09 CEST] <BtbN> I hope I still have that code somewhere [20:24:47 CEST] <fritsch> we have it in kodi, pretty straight forward encapsulated into a method [20:27:02 CEST] <BtbN> https://gist.github.com/35f0e54489d5494628405100b389fe93 still have it [20:27:42 CEST] <fritsch> for ffmpeg that alignement should be given correctly [20:27:55 CEST] <fritsch> so no need to copy the modulo bits [20:28:01 CEST] <fritsch> manually I think [20:29:22 CEST] <fritsch> the copy2d misses the unaligned partly loop [20:29:23 CEST] <fritsch> btw. [20:29:28 CEST] <fritsch> that is a bug [20:29:41 CEST] <fritsch> ah no it's not, you assert above [20:29:50 CEST] <fritsch> but compute the unaligned var never the less [20:30:13 CEST] <BtbN> i think that code comes from some Intel-Sample [20:30:39 CEST] <fritsch> i know :-) we copied the same [20:31:01 CEST] <nevcairiel> personally i've also never seen the small cache block intermediate to actually help but only complicate the code [20:31:13 CEST] <fritsch> we have tested it [20:31:23 CEST] <nevcairiel> you think i have not? =p [20:31:23 CEST] <fritsch> our use case was: yadif deinterlacing of vaapi decoded video [20:31:54 CEST] <fritsch> and that needs the copy from uscw memory [20:32:12 CEST] <fritsch> celeron 1007U: 35 to 45 ms 1080p frame [20:32:15 CEST] <fritsch> with memcpy [20:32:25 CEST] <fritsch> and 1 to 5 ms with this copy [20:32:52 CEST] <nevcairiel> its not about this copy vs. memcopy, its about this copy or a simplified version of this copy [20:33:00 CEST] <nevcairiel> without the intermediate cache [20:33:16 CEST] <BtbN> It's 16 seconds vs. 11 seconds here. So, SSE4 code vs. plain memcpy [20:33:49 CEST] <BtbN> Is there some way to get a bit of uswc memory, to actually test the speed benefit? [20:34:03 CEST] <nevcairiel> other then using your gpu to lock some? [20:34:23 CEST] <BtbN> without actually going through all of VAAPI [20:34:33 CEST] <fritsch> mmh [20:34:50 CEST] <fritsch> you can just use the decoded image itself? [20:35:04 CEST] <fritsch> it's actually "a fair bit of uswc memory" [20:35:05 CEST] <nevcairiel> its not necessarily about being uswc alone, but also that its really gpu memory which might impact it further, so i would test with the proper case [20:35:39 CEST] <BtbN> Well, I could just hijack ffmpeg, and place the benchmark in the middle of its VAAPI code [20:35:45 CEST] <fritsch> hehe [20:35:56 CEST] <fritsch> or just assume it's uswc memory in 100% of the cases [20:36:07 CEST] <fritsch> that will be true for vaapi nowadys most of the time I think [20:36:08 CEST] <nevcairiel> ffmpeg_vaapi.c copies the image to memory, just add your alternate copy function there [20:36:09 CEST] <BtbN> No, I want to see how fast it is on actual uswc memory [20:36:18 CEST] <nevcairiel> its not really much hijacking [20:36:28 CEST] <BtbN> libavutil copies the image iirc? [20:36:40 CEST] <nevcairiel> oh right that was probably refactored [20:36:55 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/hwcontext_vaapi.c#L8… [20:36:57 CEST] <nevcairiel> avutil/hwcontext_vaapi.c then =p [20:37:42 CEST] <BtbN> Will have to re-implement larger parts of av_frame_copy though. It does quite a bit of stuff [20:38:06 CEST] <fritsch> for benchmarking, hacking it into av_frame_copy directly? [20:38:17 CEST] <fritsch> will most likely be sufficient - as it's for testing only [20:38:49 CEST] <nevcairiel> its really just a wrapper around av_image_copy which just copies all planes [20:38:52 CEST] <nevcairiel> not that much magic [20:39:14 CEST] <BtbN> only some weird PAL stuff [20:39:30 CEST] <fritsch> probably bypassed in the case [20:39:35 CEST] <nevcairiel> which you dont need to handle :D [20:39:47 CEST] <BtbN> it can't happen in stuff vaapi decodes? [20:40:39 CEST] <fritsch> i currently don't see how - as vaapi outputs NV12 [20:40:52 CEST] <fritsch> or has kind of nv12 format in its buffers [20:42:04 CEST] <BtbN> For this to land in ffmpeg I'd have to write yasm for it anyway, and I have no idea about that. [20:46:09 CEST] <BtbN> nevcairiel, so, without that buffer would essentialy mean just using that copy_from_uswc function from my test directly, right? [20:46:20 CEST] <nevcairiel> yes [20:46:31 CEST] <BtbN> that should be somewhat simple to write in yasm [20:46:36 CEST] <jamrial_> BtbN: BBB will hit me for suggesting it, but if you can glue it properly you could maybe use inline asm [20:47:03 CEST] <BtbN> It should not be hard to do it in yasm. For someone who has done yasm before... [20:47:44 CEST] <fritsch> i wonder if there is some kind of auto converter [20:47:46 CEST] <fritsch> :p [20:48:03 CEST] <nevcairiel> there is no reason to use inline asm, we dont want any new inline asm, and copying an entire plane also has no argument of saving overhead [20:48:05 CEST] <jamrial_> assuming it's just one or a few mov instructions and not a full function implemented in assembly, using inline (like the intreadwrite macros) may also be better than yasm [20:48:14 CEST] <jamrial_> fair enough [20:48:37 CEST] <BtbN> https://bpaste.net/show/70b17c7760b8 [20:48:42 CEST] <BtbN> it's exactly this function [20:48:54 CEST] <nevcairiel> if you implement it with very contrained requirements its probably pretty simple [20:49:13 CEST] <michaelni> CFS-MP3, i can confirm it doesnt crash anymore [20:49:29 CEST] <fritsch> BtbN: that's without the intermediate or do I overlook that? [20:49:36 CEST] <BtbN> Yes. [20:51:29 CEST] <jamrial_> yeah, that should be implemented in yasm [20:51:58 CEST] <fritsch> i really wonder how many instructions that will generate at the end [20:52:11 CEST] <BtbN> way too much, no idea what gcc is doing to it [20:52:30 CEST] <fritsch> and I wonder about the policy to why this is needed [20:52:36 CEST] <fritsch> for such a straight forward loop [20:52:45 CEST] <BtbN> Uhm. [20:52:54 CEST] <BtbN> Without the intermittend 4K buffer, it even outperforms plain memcpy [20:53:06 CEST] <BtbN> not by much, but it's faster. [20:53:25 CEST] <fritsch> and how fast is it with uscw memory in comparison to with 4k buffer? [20:53:39 CEST] <BtbN> No idea, I don't have a uswc buffer at hand in the test app [20:54:05 CEST] <fritsch> i have a feeling, that it makes sense [20:54:09 CEST] <fritsch> for non uscw memory [20:54:18 CEST] <fritsch> to be faster [20:54:27 CEST] <BtbN> In that case, av_image_copy_plane could just be using that sse4 code if it's available all the time? [20:54:46 CEST] <fritsch> if it's still fast enough for the real uscw copy [20:54:59 CEST] <fritsch> which it should be in any ways - as it's faster [20:55:01 CEST] <fritsch> than before [20:55:13 CEST] <fritsch> i wonder how that performs on amd cpus [20:55:22 CEST] <fritsch> or other platforms hitting that path [20:55:54 CEST] <fritsch> i can benchmark on ivb, hsw, bsw, snb [20:56:00 CEST] <fritsch> but no amd currently plugged in [21:11:40 CEST] <BtbN> http://www.felixcloutier.com/x86/MOVNTDQA.html what's the difference between the first two? [21:12:33 CEST] <fritsch> i think it's the same [21:12:47 CEST] <fritsch> besides the first one works on cpus with sse41 only that don't have avx? [21:12:50 CEST] <fritsch> does that make sense? [21:12:51 CEST] <BtbN> The operation seems to be slightly diffrent [21:14:13 CEST] <jamrial_> BtbN: legacy sse and VEX encoding versions of the same instruction [21:17:55 CEST] <jamrial_> they are the same. x86inc will emit the second if you init the function targeting avx or newer, otherwise the first [21:18:39 CEST] <BtbN> https://gist.github.com/56be86b002a21db35de5a4b66f78c483 good patch. [21:19:25 CEST] <jamrial_> the latter obviosuly has the difference of clearing the high 128 bits of ymm regs whereas the first doesn't, but that's only an issue if you mix sse and ymm vex instructions which you never should [21:19:51 CEST] <BtbN> ah, so that's what it refers to [21:20:21 CEST] <BtbN> The ymm and xmm registers share the first 128 bit? [21:21:19 CEST] <jamrial_> yes. xmm regs on avx cpus are mapped to the low 128 bits of ymm regs [21:21:34 CEST] <BtbN> Yeah, makes sense then. [21:22:01 CEST] <BtbN> I'm quite amazed this patch actually compiles. If you configure with cpu=host that is, or something that supports those. [21:42:43 CEST] <BtbN> turns out testing vaapi decoding stuff on my nvidia box wasn't the best idea. [21:43:01 CEST] <BtbN> took me way to long to realize why stuff was failing horribly. [21:45:37 CEST] <fritsch> hehe [21:45:42 CEST] <fritsch> should I test something for you? [21:45:55 CEST] <BtbN> Nah, just had to use another PC... [21:46:08 CEST] <fritsch> and already some preliminary results? [21:46:23 CEST] <BtbN> Well, using VAAPI doesn't work on Nvidia cards. [21:46:30 CEST] <fritsch> yeah [21:46:37 CEST] <fritsch> and even if you get the vdpau-vaapi wrapper [21:46:41 CEST] <fritsch> it won't be uscw memory [21:47:49 CEST] <BtbN> The box I was testing on does have an ivy bridge GPU though [21:47:54 CEST] <BtbN> But it kept refusing to use it [21:47:58 CEST] <BtbN> Even vainfo fails [21:48:09 CEST] <fritsch> use your braswell [21:48:20 CEST] <BtbN> Yeah, that's what I'm re-compiling on right now. [22:01:27 CEST] <BtbN> hm, i barely get 60 fps out of vaapi decoding h264 [22:01:38 CEST] <BtbN> There must be some other bottleneck [22:02:43 CEST] <fritsch> is it vsynced? [22:02:46 CEST] <fritsch> "somehow"? [22:02:56 CEST] <fritsch> yeah I think if vaPutSurface is used it actually is :-( [22:04:23 CEST] <BtbN> Where does it use vaPutSurface? [22:04:42 CEST] <fritsch> "if" <- [22:04:58 CEST] <fritsch> read something like that recently on vaapi mailing list [22:05:10 CEST] <BtbN> I get 55 fps with classic copying, and 77 fps with the sse4 intrinsic copy function [22:05:37 CEST] <BtbN> with ffmpeg using around 50% CPU each time [22:05:38 CEST] <fritsch> can you "noop" also? [22:05:44 CEST] <fritsch> e.g. don't copy at all? [22:05:53 CEST] <fritsch> or memset zeros? [22:06:29 CEST] <BtbN> doing nothing hits 87 fps [22:06:48 CEST] <BtbN> and still 40% CPU [22:07:05 CEST] <BtbN> No idea how to propperly operate that vaapi decoding in ffmpeg though [22:07:11 CEST] <fritsch> what's the input file? [22:07:16 CEST] <BtbN> 1080p [22:07:58 CEST] <fritsch> 77/55 = 40 % improvement [22:08:03 CEST] <fritsch> with 10 lines of code [22:08:12 CEST] <BtbN> But I wonder what is using so much CPU there? [22:08:15 CEST] <BtbN> The CPU should be idle! [22:08:37 CEST] <fritsch> good question [22:09:04 CEST] <BtbN> ./ffmpeg -threads 1 -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -i ~/game.of.thrones.s01e01.1080.mkv -c:v rawvideo -sn -an -y -f null -pix_fmt nv12 /dev/null [22:10:39 CEST] <BtbN> [auto-inserted scaler 0 @ 0x247be60] Setting 'flags' to value 'bicubic' [22:10:43 CEST] <fritsch> haha [22:10:44 CEST] <fritsch> ^^ [22:10:44 CEST] <BtbN> that sounds like a good candidate [22:10:46 CEST] <fritsch> now you know [22:10:51 CEST] <BtbN> But why?! [22:11:07 CEST] <fritsch> it's the default sws_scale algorithm? [22:11:17 CEST] <fritsch> can you force it to bilinear_fast or something? [22:11:18 CEST] <BtbN> It should not insert a scaler for matching formats [22:11:21 CEST] <BtbN> at all [22:11:34 CEST] <BtbN> or rather, the scaler should not do anything [22:11:44 CEST] <fritsch> change the pix_fmt? [22:11:50 CEST] <BtbN> I did. [22:12:03 CEST] <BtbN> [graph 0 input from stream 0:0 @ 0x244f1a0] w:1920 h:1080 pixfmt:yuv420p tb:1/1000 fr:13978/583 sar:1/1 sws_param:flags=2 [22:12:07 CEST] <fritsch> perhaps it's used to convert from input to output [22:12:13 CEST] <BtbN> it thinks the input is yuv420p, even though vaapi will output nv12 [22:12:13 CEST] <BtbN> hm [22:13:04 CEST] <CFS-MP3> michaelni: About this reply to send on the ML: "can you document in a comment briefly what is in the AVPackets [22:13:04 CEST] <CFS-MP3> for most codecs that is clear, SCTE-35 is maybe a bit special [22:13:04 CEST] <CFS-MP3> also what the dts/pts values of teh AVPackets mean" [22:13:25 CEST] <CFS-MP3> Can you point me to an example comment that meets the comment requirements? :-) [22:13:39 CEST] <CFS-MP3> reply you sent I mean, sorry [22:15:12 CEST] <michaelni> i dont think others are documented, its clear for most like what pts/dts are for video [22:24:48 CEST] <fritsch> BtbN: so what happens if you say yuv420p? [22:25:48 CEST] <BtbN> it switches to nv12 at runtime and scales. [22:25:55 CEST] <fritsch> hehe [22:32:52 CEST] <cone-820> ffmpeg 03Michael Niedermayer 07master:b8b36717217c: avcodec/cfhd: Increase minimum band dimension to 3 [22:34:11 CEST] <jkqxz> Are you getting the scaler because of the reinit after hwaccel is enabled? You might be able to do better by setting -hwaccel_output_format explicitly. [22:41:21 CEST] <BtbN> Even with that set to nv12, it allways inserts a scaler. [22:41:23 CEST] <jkqxz> Also, thoughts on hardware frame mapping such as you are looking for there are most welcome. <https://lists.libav.org/pipermail/libav-devel/2016-July/078123.html> [22:42:34 CEST] <BtbN> isn't hwframe_map already in ffmpeg? [22:42:50 CEST] <durandal_17> michaelni: https://we.tl/aJmrgBc5KK [22:43:29 CEST] <BtbN> ah, no. It uses vaPutImage... [22:43:44 CEST] <BtbN> on unmap though oO [22:44:00 CEST] <fritsch> BtbN: haha [22:44:14 CEST] <fritsch> that's totally bad [22:44:27 CEST] <fritsch> it auto scales to rgb full [22:44:30 CEST] <jkqxz> It's kindof there for VAAPI, because it tries to do something sensible for the read/write cases. Really this is for user-accessible mapping. [22:44:32 CEST] <BtbN> seems like it uses vaPutSurface to copy back changed data [22:44:49 CEST] <BtbN> Which should never happen during hwdownload [22:45:32 CEST] <jkqxz> It only puts the data back if you were writing to the surface. [22:46:13 CEST] <BtbN> But why does it not use vaDeriveImage, which is the fastest from what i know, if the mapping is READ? [22:46:16 CEST] <jkqxz> (transfer_data_from() maps it read-only.) [22:46:19 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/hwcontext_vaapi.c#L7… [22:46:50 CEST] <jkqxz> See comment above. Noone has written a usable uncached copy for it. [22:47:09 CEST] <BtbN> So, for testing my uncached copy, i should plain remove that. [22:47:26 CEST] <jkqxz> Yes. [22:47:27 CEST] <fritsch> wait it uses vaPutImage and not vaPutSurface [22:47:31 CEST] <fritsch> that's a big difference [22:48:55 CEST] <BtbN> Yes, now i see a noticable speedup [22:49:26 CEST] <BtbN> 200 fps with a no-op copy. [22:50:18 CEST] <jkqxz> fritsch: Um, yeah. vaPutSurface() is a debug-only function for terrible output to X11 windows. [22:50:28 CEST] <fritsch> it was "the only resort" for years [22:50:32 CEST] <fritsch> :-( [22:50:39 CEST] <fritsch> and used with texture from pixmap [22:50:46 CEST] <fritsch> in kodi and anywhere else [22:50:56 CEST] <BtbN> So, 200 fps with not copying at all. [22:51:08 CEST] <fritsch> now let's see what you get with sse4 part [22:51:09 CEST] <BtbN> 25 fps with plain simple sse4 copy [22:51:14 CEST] <BtbN> 10 fps with classic copy [22:51:22 CEST] <fritsch> mmmh [22:51:25 CEST] <fritsch> there is something wrong [22:51:27 CEST] <fritsch> isn't it? [22:51:32 CEST] <BtbN> Going to put the whole 4K buffer thing in there [22:51:58 CEST] <fritsch> kod results: https://dl.dropboxusercontent.com/u/55728161/sse4vsputsurface.png [22:52:17 CEST] <fritsch> you should get > 100 [22:55:53 CEST] <BtbN> even with the optimized copy function, it's slow, using tons of CPU [22:57:45 CEST] <fritsch> can you post the diff, please? [22:57:52 CEST] <fritsch> I don't fully get what you removed now [22:58:03 CEST] <fritsch> and why you had 77 fps before [22:58:15 CEST] <BtbN> just reduced the check for it to use deriveImage [22:58:23 CEST] <BtbN> it allways uses it now [22:58:48 CEST] <BtbN> perf also confirms, 90% of the CPU time is spent in av_image_copy_plane [22:59:56 CEST] <BtbN> https://bpaste.net/show/f1d53e60696b that's the current diff [23:00:01 CEST] <nevcairiel> on DXVA with an optimized copy function i maybe get 2-3% CPU use and practically the same decoding speed as not copying back at all [23:00:25 CEST] <BtbN> Yeah, something must be wrong with that copy function [23:00:26 CEST] <nevcairiel> but thats not though ffmpeg.c [23:00:45 CEST] <BtbN> Well, perf confirmed that it indeed is the copy function being slow [23:01:37 CEST] <BtbN> There is no difference in speed between the cache-block and the direct approach though [23:01:41 CEST] <BtbN> so they are equally slow [23:04:14 CEST] <jamrial_> https://trac.ffmpeg.org/ticket/5781#comment:4 the doxy needs to be improved [00:00:00 CEST] --- Sat Aug 20 2016

1 0

ffmpeg.log.20160819
by burek 20 Aug '16

20 Aug '16

[09:20:00 CEST] <luc4> Hello! Im building ffmpeg from macports and I see that it does not include hevc encoding support and lossless support. Any idea why? Isnt it ready yet? [09:20:20 CEST] <luc4> Or maybe they just didnt include it in the build configuration for some reason? [10:55:10 CEST] <durandal_1707> luc4: yes, that's possible [10:55:27 CEST] <luc4> durandal_1707: that it is not ready yet? [10:56:14 CEST] <luc4> durandal_1707: I see that the static build includes the decoder, that is why I asked. [10:57:39 CEST] <durandal_1707> luc4: it have encoder I think but its optional library [10:58:03 CEST] <luc4> durandal_1707: but is it safe to use? [10:58:16 CEST] <durandal_1707> safe and slow [10:58:59 CEST] <luc4> durandal_1707: I see, thanks! [11:40:08 CEST] <odinsbane> I get some complaints from power point about my perfectly good video encoded with ffmpeg. Does somebody have a good set of options they use for compatibility with ms office? [11:55:59 CEST] <N_1ck> hi there, not really ffmpeg-related topic, may i ask about video over IP and networking ? [12:00:02 CEST] <Amnesia> hi question, how should I convert a mkv file to a format which I can burn using growisofs? [12:01:01 CEST] <Amnesia> http://superuser.com/questions/347451/encoding-mkv-to-dvd-with-ffmpeg uses the mkv container as well as output, which most dvd apps probably don't accept [12:59:45 CEST] <Conder> hello, i want resize .h264 video to 720p and i want output in .h264 too. can be it done with this? ffmpeg -i input.h264 -vf scale=1280:-1 -c:v libx264 -crf 20 output.h264 [13:03:22 CEST] <odinsbane> Conder: did you try it? You can specify the output size instead of scale. [13:07:15 CEST] <Conder> i tried it now, seems its okay :D [13:50:51 CEST] <svRichard> I'd appretiate if anyone has any insight with an OSX avfoundation screencapture issue I'm having. [13:50:56 CEST] <svRichard> To grossly over simplify the issue, if I use "sudo -u B ffmpeg -f av... -i o:" from user A, it captures the desktop of user A (I'm expecting the desktop of user B). If use "ssh B@localhost <same command>" I get the desktop for user B. [13:51:41 CEST] <svRichard> Now I'm hoping to use the "sudo -u B" solution but have no clue as to why it would record the desktop of user A [13:53:14 CEST] <svRichard> For clarity, the command used in both cases is: /usr/local/bin/ffmpeg -y -v error -f avfoundation -r 10 -pix_fmt yuyv422 -i "0:" -c:v h264 -preset:v ultrafast -profile:v baseline -qp:v 1 -pix_fmt yuv420p /tmp/rec.mp4 [13:55:45 CEST] <svRichard> And the version is 3.1.2-tessus [14:00:38 CEST] <viric> grmbl. I use crf=30 in x264, and with two different camera sources, I get very different results, targetting 720p 25fps. For one, quite good. For the other, a much smaller file and with much more artifacts. [14:07:08 CEST] <viric> I can't understand. If the 2nd source were noisier, it might have more artifacts, but not be much smaller [14:08:40 CEST] <svRichard> gr8push [14:09:50 CEST] <svRichard> ^ sorry for the spam [14:33:56 CEST] <nonex86> can anyone help? i am trying to encode video stream (variable frame rate) and mux it into mkv using ffmpeg library, what fields in avcodeccontext and avstream should i fill to do it properly? [14:36:35 CEST] <nonex86> comments for avcodeccontext.time_base said i should be set to 1/framerate, but what if the framerate is variable? [14:36:45 CEST] <nonex86> *it [14:47:06 CEST] <DHE> for variable FPS you basically set PTS timecodes that skip numbers. If your 30fps video occasionally becomes 15, you can go +2 on the PTS instead of +1 as needed [14:47:33 CEST] <DHE> if your FPS is less mathematically pleasant, you might need to use a timebase of something like 1/1000 and go skipping all the time [14:47:43 CEST] <DHE> and beware not all containers are variable-fps friendly [14:48:32 CEST] <nonex86> thanks, as far as i know mkv should be ok [14:48:39 CEST] <DHE> yeah mkv is good [14:48:46 CEST] <nonex86> but after i mux the file i have some problems [14:48:50 CEST] <nonex86> mpv plays it ok [14:49:00 CEST] <nonex86> but vlc is not [14:49:16 CEST] <nonex86> also in media info i see CFR for the video stream :/ [14:49:45 CEST] <nonex86> so i guess i missed something [14:49:49 CEST] <nonex86> at least on muxer side [14:55:07 CEST] <nonex86> or... its on the codec side, because h264 carry cfr/vfr information afair... [14:55:46 CEST] <nonex86> so its the question how to tell to x264 encoder in ffmpeg to set vfr for stream [15:07:06 CEST] <DHE> h264 by itself doesn't have a concept of framerate. that's a necessity of the container. an h264 ES is basically just a sequence of frames and nothing more [15:08:19 CEST] <nonex86> i just found this post [15:08:20 CEST] <nonex86> http://forum.doom9.org/archive/index.php/t-165256.html [15:09:22 CEST] <nonex86> "MKV does not have any header information telling you whether the file is VFR or CFR (H.264 bitstream does, though." [15:10:03 CEST] <nonex86> honestly speaking i dont remember anything related to fps in h264 sps/pps... [15:10:55 CEST] <nonex86> curious, why media info said my output file is CFR than... [15:11:12 CEST] <BtbN> Probably because it has no idea, and defaults to cfr [15:11:16 CEST] <DHE> it would need to scan the whole file to be 100% sure about that [15:11:23 CEST] <DHE> or at least until it finds the framerate changing on it [15:15:40 CEST] <nonex86> BtbN, yeah, this make sense [15:21:20 CEST] <JEEB> nonex86: there's a field in the parameter sets that sets the maximum rate of the stream [15:21:47 CEST] <JEEB> usually programs think a stream is cfr if it is sey [15:22:07 CEST] <JEEB> but as the field notes, it's just the max [15:22:43 CEST] <JEEB> also the container per-picture timestamps could be completely different and override anything the bit stream sets [15:25:40 CEST] <JEEB> but in the end you just have to see wtf things like mediainfo use in their source code [15:50:39 CEST] <kdehl> A question about the scale2ref filter, why does it have two outputs? Isn't the only interesting output the scaled video? [15:54:18 CEST] <kdehl> Oh. [15:54:42 CEST] <kdehl> It's to easily use it with the overlay filter. [16:16:38 CEST] <nonex86> JEEB: thanks [16:22:59 CEST] <ozette> i have a machin with armv7l architecture, i build ffmpeg for that machine using a raspberry pi which has a armv7l arch as well [16:23:22 CEST] <ozette> the ffprobe works fine on the machine, but the ffmpeg returns an error when i try to create a hls list [16:23:37 CEST] <ozette> the error being: ffmpeg was killed with signal SIGILL [16:24:19 CEST] <ozette> does this mean that the machine can't process the instructions from the ffmpeg that was build on the raspberrypi? [16:26:23 CEST] <DHE> Illegal instruction was executed [16:26:42 CEST] <ozette> does that have anything to do with the flag i give? [16:26:53 CEST] <ozette> i pass a -hls_list_size 0 [16:27:14 CEST] <ozette> or the ffmpeg can't process the media i give? [16:27:15 CEST] <DHE> no, this will either be a bug in the pre-written assembly code or gcc built ffmpeg with the wrong -m settings [16:27:27 CEST] <ozette> i built this ffmpeg only with the x264 library [16:27:42 CEST] <ozette> not sure if i need aac as well [16:27:47 CEST] <DHE> yes, but both x264 and ffmpeg have hand-written assembly options [16:27:50 CEST] <ozette> it's a mp4 file [16:27:59 CEST] <ozette> ah [16:28:24 CEST] <DHE> so somebody screwed up, either said hand-written instructions or the code that decides when to use them, or gcc was told the CPU would be of a higher model than what you have. [16:28:27 CEST] <ozette> i followed this guide by the way: http://www.jeffreythompson.org/blog/2014/11/13/installing-ffmpeg-for-raspbe… [16:28:49 CEST] <ozette> i see, very possible since this was the very latest ffmpeg [16:28:50 CEST] <DHE> hmm.. if you followed a pre-written guide, you'd think it's a tested configuration [16:29:01 CEST] <ozette> well it uses git at some point [16:29:03 CEST] <ozette> to get the ffmpeg source [16:29:17 CEST] <ozette> it's not a stable, so maybe that's my problem? [16:29:37 CEST] <kepstin> also, which raspberry pi model? there's several, with varying processors [16:29:37 CEST] <ozette> version is N-81350-g32282e31 [16:29:40 CEST] <DHE> well, for testing you can use --disable-asm for the configure command of both x264 and ffmpeg to eliminate item number one. [16:29:51 CEST] <DHE> or if you know how to use gdb, you can just see where it crashes [16:29:59 CEST] <ozette> kepstin: pi 3 model B v1.2 [16:30:18 CEST] <ozette> it has an armv7l architecture [16:30:41 CEST] <kepstin> huh, that's the newest one, with a cortex-a53 core. I wonder which instruction it's having issues with [16:30:55 CEST] <ozette> DHE: would ffmpeg crash when it isn't build with aac? [16:31:28 CEST] <ozette> i did the bare minimum of that guide, because i wasn't too sure how to get the other libraries [16:32:06 CEST] Action: kepstin notes that technically the cpu in the pi 3 is armv8, but it's usually run with 32bit/armv7 userspace. [16:32:08 CEST] <ozette> but i can --help and -version the ffmpeg [16:32:23 CEST] <ozette> interesting [16:32:38 CEST] <DHE> ozette: building ffmpeg is likely good enough. besides, for aac audio there's a built-in ffmpeg encoder which is fine [16:33:09 CEST] <furq> ozette: you should use --arch=armhf for the rpi3 [16:34:24 CEST] <ozette> furq: aha so armhf instead of armel? [16:34:37 CEST] <furq> yeah [16:34:42 CEST] <furq> assuming your distro is armhf as well [16:34:45 CEST] <ozette> yea [16:34:51 CEST] <furq> i have no idea how raspbian dealt with the transition to the pi 2 [16:34:56 CEST] <furq> i just run regular debian on my pi 2 [16:34:57 CEST] <ozette> alright i will try that [16:35:03 CEST] <ozette> oh wauw [16:35:50 CEST] <viric> all pi have 'armhf' [16:35:54 CEST] <kepstin> pi 1 was armv6, iirc, so i assume it was a new build to get armv7 [16:36:02 CEST] <viric> hard-float [16:36:51 CEST] <viric> different simd instructions, though. [16:36:58 CEST] <ozette> when ./configuring ffmpeg, it shows a list of enabled decoders [16:37:30 CEST] <ozette> including an aac, so those decoders are all included, correct? [16:38:19 CEST] <viric> ozette: SIGILL means it is bad compiled. It's not related to the decoders [16:41:54 CEST] <ozette> viric: alright thanks [16:42:19 CEST] <ozette> i'm rebuilding with --arch=armhf [16:42:52 CEST] <furq> i take it you're not cross-compiling then [16:43:56 CEST] <ozette> well [16:44:31 CEST] <furq> also i believe you need --enable-omx-rpi if you want to use the builtin h264 decoder [16:44:36 CEST] <furq> and the builtin encoder but that's pretty much trash [16:45:16 CEST] <ozette> i'm actually compiling for another machine [16:45:19 CEST] <viric> it is not advertised as such ;) [16:45:40 CEST] <ozette> but it has an architecture similar to the pi, so i'm hoping armhf will do the trick [16:45:47 CEST] <furq> oh [16:45:55 CEST] <viric> similar as in "it also has usb"? [16:45:57 CEST] <ozette> the toolchain i originally made failed [16:46:00 CEST] <kepstin> ... oh, so you're not running it on the pi? [16:46:09 CEST] <DHE> the general opinion of everybody is that hardware h264 encoders are fast, but x264 still produces the best image quality [16:46:12 CEST] <ozette> so i decided, nvm i'll build it on the rpi and bring it over like a static [16:46:21 CEST] <DHE> having tested nvidia's encoder, that's certainly true [16:46:24 CEST] <kepstin> yeah, it's probably just a mismatch between the compiler on the pi and the architecture of the board you're using [16:49:47 CEST] <ozette> i think compiling with armhf will do the trick [16:50:11 CEST] <furq> you've picked a really weird way to go about this [16:50:45 CEST] <kepstin> tbh, if the problem is a compiler architecture mismatch, using armhf will either leave it the same or make it worse [16:50:52 CEST] <ozette> probably, but time is short, i have my application working on 2 different architectures already [16:51:45 CEST] <ozette> it's funny how the ffprobe i compiled before runs 'fine' [16:52:16 CEST] <kepstin> the bad instruction is probably located in a part of the code that ffprobe doesn't run [16:52:18 CEST] <ozette> no instruction errors so far, but i'm using it only for a single purpose [16:52:26 CEST] <ozette> yea i think so too [16:53:19 CEST] <ozette> lucky me, anyway, i'll let you know if the compilation worked out, this may take a while [16:57:34 CEST] <shincodec> so [16:57:55 CEST] <shincodec> msvc build broken [16:57:57 CEST] <shincodec> right? [16:59:44 CEST] <shincodec> AWk: [16:59:47 CEST] <shincodec> this and that [16:59:54 CEST] <shincodec> what sort of idiot uses that? [17:02:34 CEST] <furq> what a nice young man [17:04:52 CEST] <viric> I'm with kepstin, armhf will only make it worse [17:04:56 CEST] <viric> (or same) [17:05:30 CEST] <viric> ozette: you have to match the exact vfp version supported, and same for neon and such things. There are many versions. [17:06:09 CEST] <viric> ozette: you may even have the trouble in non-ffmpeg code (libc, etc.), which is built for the other platform [17:06:31 CEST] <viric> so maybe it does not matter with what flags you build ffmpeg [17:35:47 CEST] <ozette> we'll see [19:17:20 CEST] <shincodex> now really [19:17:31 CEST] <shincodex> help me understand on msvc why im having snprintf issue [19:17:47 CEST] <shincodex> why is there a macro in configure redefining snprintf [19:18:02 CEST] <shincodex> then in internal.h "EXTERN" is used with av wtfver ever snprintf [19:22:59 CEST] <shincodex> holy crap [19:23:06 CEST] <shincodex> i think i compiled your shit with crt [19:26:45 CEST] <durandal_1707> shincodex: doing what? [19:29:06 CEST] <DelphiWorld> hey [19:29:17 CEST] <DelphiWorld> guys someone know how to catch a url in a swf flash file? [19:31:39 CEST] <durandal_1707> why? [20:23:01 CEST] <shincodex> compiled ffmpeg in command line visual studio and msys crap [20:23:15 CEST] <shincodex> now im trying to figureout how to make CC libavformat/allformats.o [20:23:25 CEST] <shincodex> display the exact compile string verbose and stop hiding it [20:23:35 CEST] <shincodex> i did it once before but i cant remmber where in make file that junk is [20:23:52 CEST] <shincodex> CAuse mvsc flags is using O3 thats not valid for msvc cl.exe [20:24:03 CEST] <shincodex> so im thinking its sileently erroring and continue onward [20:24:09 CEST] <shincodex> assuming /O0 [20:24:11 CEST] <shincodex> which is bad for me [20:27:38 CEST] <drv> make V=1 [20:29:25 CEST] <shincodex> Got it. its common.mak compile [20:33:51 CEST] <Glimmergaunt> setting up the decoder can pps, and psp, one after each other? (same byte array) or do they have to be separate? (if that makes any sense) [20:33:57 CEST] <Glimmergaunt> For setting up* [20:50:42 CEST] <shincodex> drv [20:50:53 CEST] <shincodex> That was giberish but now that makes sense [20:50:54 CEST] <shincodex> i saw that [20:51:03 CEST] <shincodex> I just said screw it and dropped CC from brief [20:51:04 CEST] <shincodex> lol [20:51:37 CEST] <shincodex> and indeed release msvc sends O2 to compiler [20:54:19 CEST] <shincodex> inconfigure i translate fpic to -MD hope it works [21:56:58 CEST] <kadiro> hello, i have an mkv video, i tried to convert it with 480p mp4 file, i used this line: ffmpeg -i my_file.mkv -vf scale=-1:480 -vcodec mpeg4 -scodec mov_text -qscale 3 my_file.mp4 , the problem the output video is about 2.8G , the mkv source file is only 940M [21:57:54 CEST] <kadiro> if you need other information just tell me i will do it [22:02:49 CEST] <kadiro> any one have a little time to direct me [22:06:08 CEST] <Mavrik> kadiro, I'm sure your input file isn't MPEG-4 video :) [22:06:20 CEST] <Mavrik> Which is an old format that's bad at compression :) [22:06:33 CEST] <kadiro> Mavrik, it must have the same codec? [22:06:39 CEST] <Mavrik> Well... [22:06:55 CEST] <Mavrik> if you want same filesize it has to be a codec that's as good or better [22:06:56 CEST] <Mavrik> Not worse :) [22:07:13 CEST] <Mavrik> Also nothing is encoded in MPEG-4 anymore. [22:07:13 CEST] <kadiro> it is Input #0, matroska,webm [22:07:16 CEST] <Mavrik> Use H.264. [22:07:21 CEST] <kadiro> ah [22:07:28 CEST] <kadiro> it compress? [22:07:45 CEST] <Mavrik> kadiro, please look up the difference between a container ("mp4, webm") and what's inside that container (video and audio tracks and their formats). [22:08:22 CEST] <kadiro> oops my bad, it is Stream #0:0: Video: h264 (High), yuv420p, 1288x536 [SAR 1:1 DAR 161:67], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default) [22:09:07 CEST] <kadiro> Is the `-vf scale=-1:480` fine? Mavrik [22:09:08 CEST] <Mavrik> mhm, so it's worth encoding back to h.264 :) [22:09:16 CEST] <Mavrik> -vcodec libx264 [22:09:27 CEST] <kadiro> thanks so much [22:10:10 CEST] <kadiro> my end goal is to make the video less in size ( from 1288x536 to something less ) [22:18:58 CEST] <kadiro> i tried to add a modified subtitle extracted from the original file : ffmpeg -i my_file.mkv -i my_sub.ass -vf scale=-1:480 -vcodec libx264 -acodec copy -qscale 3 my_file.mp4 [22:19:22 CEST] <kadiro> but i got this error: Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [22:20:28 CEST] <kadiro> the original video have 1 video stream, 1 audio, 2 subs and one jpeg [22:26:10 CEST] <kadiro> something is wrong with my command line but i can't see it [22:30:05 CEST] <kadiro> I will add -map 0:0 and hope it will do it [22:31:57 CEST] <kadiro> ah i think i get something when i scroll up "width not divisible by 2 (1153x480)" [22:34:39 CEST] <durandal_1707> michaelni: I get bunch of exceeding next NALFF with latest h264 decoder [22:35:26 CEST] <michaelni> durandal_1707, how can i reproduce ? [22:35:30 CEST] <kadiro> whatever i use for '-vf scale:-1:something' i got this "width not divisible by 2 (1153x480)" what's wrong? [22:37:10 CEST] <kadiro> ok i'm googling anyway [22:37:12 CEST] <furq> kadiro: -vf scale=-2:480 [22:37:15 CEST] <furq> also get rid of -qscale 3 [22:37:41 CEST] <kadiro> thanks furq [22:38:19 CEST] <kadiro> its working thanks again [00:00:00 CEST] --- Sat Aug 20 2016

1 0

ffmpeg-devel.log.20160818
by burek 19 Aug '16

19 Aug '16

[00:13:13 CEST] <cone-176> ffmpeg 03Marton Balint 07master:b72a7b96f84e: avformat: factorize iso 8601 timestamp writer to a dictionary avutil function [00:18:11 CEST] <cone-176> ffmpeg 03James Almer 07master:bba6a03b2816: examples/demuxing_decoding: convert to codecpar [09:46:37 CEST] <cone-252> ffmpeg 03Carl Eugen Hoyos 07master:f866f22c3f58: lavf/pcmdec: Try to fix msvc compilation after 4c42d306. [10:45:15 CEST] <durandal_17> michaelni: ./ffmpeg.exe -f lavfi -i aevalsrc="0.2*sin(440*PI*t):duration=5" -af aresample=44100:dither_method=shibata -c:a pcm_f64le dbl.wav [10:45:23 CEST] <durandal_17> this gives silence [11:33:18 CEST] <durandal_17> so each project have same time slot for talking about its future, how neat [12:16:08 CEST] <cone-252> ffmpeg 03Michael Niedermayer 07master:946acacdcdff: swresample: move dither init up [12:16:09 CEST] <cone-252> ffmpeg 03Michael Niedermayer 07master:30b2611ed310: swresample: Skip over dither steps if dithering scale is 0 [12:16:36 CEST] <michaelni> durandal_17, fixed the silence [12:16:46 CEST] <durandal_17> thanks [14:20:53 CEST] <ubitux> anyone working on ffmpeg/codecpar? [14:21:21 CEST] <ubitux> i'd like to work on the merges but it's going to be tricky for the incoming merges without that part [14:25:44 CEST] <ubitux> we're down ~250 commits now [14:26:08 CEST] <ubitux> we passed the h264 waves, but the avconv are going to be tricky [14:26:58 CEST] <JEEB> i think chloe was trying to poke at that but iirc there were parts where manual avctx was needed instead of codecpar etc? [14:27:57 CEST] <ubitux> i can look at this for a few hours (about 3), but if work has already been done i don't want to walk on someone's feet [14:28:10 CEST] <ubitux> (it very much likely won't be enough but well) [15:22:46 CEST] <durandal_1707> ubitux: the codecpar thing is blocking because of hacks [15:23:24 CEST] <ubitux> what hacks? how can i help? [15:23:42 CEST] <durandal_1707> can I push swr change? [16:31:16 CEST] <cone-393> ffmpeg 03Paul B Mahol 07master:9876d8fc6d2b: swresample: add int64 sample format [16:31:16 CEST] <cone-393> ffmpeg 03Paul B Mahol 07master:fc600eff630f: avcodec: add 64-bit signed pcm codec [16:31:16 CEST] <cone-393> ffmpeg 03Paul B Mahol 07master:81f7d07608e1: avfilter/af_astats: add support for s64(p) sample format [16:31:16 CEST] <cone-393> ffmpeg 03Paul B Mahol 07master:703ae350c2de: avfilter/af_astats: fix flt(p) support [18:41:37 CEST] <Chloe> ubitux: yeah, I gave it a shot, but I kept encountering issues because of things requiring avctx, I tried to switch them over, and more things broke. I'm not entirely sure where codecpar needed to replace avctx. [19:55:58 CEST] <Dresk|Dev> So I realize this isn't the responsibility of you guys, but I figured you might be able to help, we have been building ffmpeg natively in MSVC2015 but without any ASM optimizations, which is torturous, so I want to get the latest 3.1.2, but the Zeranoe builds are oddly named and I can't find his 3.1.2 : https://ffmpeg.zeranoe.com/builds/win32/shared/ [19:57:23 CEST] <BtbN> He just builds latest git master every day, which is the recommended way of using ffmpeg. [19:57:42 CEST] <BtbN> Releases basically only exist to make distributors happy. [19:58:31 CEST] <Dresk|Dev> BtbN: Well we're building for multiple OSes and platforms, it helps us to have a definitive "release", especially for the investors [20:00:01 CEST] <Dresk|Dev> I'm just trying to understand if his random, hashes, it seems, have any correlation to the Git releases [20:01:14 CEST] <BtbN> It's exactly the git commit. [20:01:56 CEST] <Dresk|Dev> So, if we have this https://ffmpeg.zeranoe.com/builds/win32/shared/ , how can I find 3.1.2 from this? https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog/n3.1.2 [20:02:31 CEST] <BtbN> There is no 3.1.2. It builds git master. [20:03:02 CEST] <Dresk|Dev> Grrr! [20:03:19 CEST] <BtbN> 3.1 was branched off, so it has no relation to master anymore, just getting security and bugfixes. [20:03:24 CEST] <Dresk|Dev> But look, zeranoe does make "distributor" builds : https://ffmpeg.zeranoe.com/builds/win32/shared/ffmpeg-3.0.1-win32-shared.7z [20:04:08 CEST] <BtbN> Probably only when someone requests one. Or he just stopped. No 3.1 there. [20:04:16 CEST] <Dresk|Dev> Yeah, I noticed that [20:04:44 CEST] <BtbN> What's the issue with just using latest git master? [20:04:52 CEST] <Dresk|Dev> But, and I would be deeply appreciative, if you could help me find, if it's possible, which one of these builds on Zeranoe's site IS the 3.1.2 Git from ffmpeg [20:05:03 CEST] <BtbN> None of them is. [20:05:05 CEST] <BtbN> He builds git master [20:05:06 CEST] <Dresk|Dev> It's more of an investor thing, just, politics [20:05:08 CEST] <BtbN> 3.1.2 is not on master. [20:05:25 CEST] <Dresk|Dev> Oh, ah [20:05:53 CEST] <Dresk|Dev> Well I shall then embrace the latest, which means I have no idea what to call the folder, heh [20:06:36 CEST] <BtbN> The git commit is right in the version name. [20:07:12 CEST] <Dresk|Dev> I am dumb sometimes [20:10:24 CEST] <Dresk|Dev> BtbN: Thanks, gonna see if I can actually build this with YASM via MSVC, that would be ultimate for us since we don't want to rely on MSVCRT.dll from Cygwin due to it being OS-dependent and just, bad [20:10:50 CEST] <BtbN> You'll depend on some runtime anyway. [20:10:58 CEST] <BtbN> gcc also has its runtime library. [20:11:22 CEST] <BtbN> The easiest way to build ffmpeg for windows is by using Linux with a cross compiler. [20:11:23 CEST] <Dresk|Dev> Well if we built it with MSVC2015 we can depend on vc-runtime-140.dll [20:11:38 CEST] <Dresk|Dev> BtbN: But that causes it to use MSVCRT.dll, which is NOT a good DLL to rely upon [20:12:01 CEST] <BtbN> Why would it do that? [20:12:22 CEST] <Dresk|Dev> https://sourceforge.net/p/mingw-w64/wiki2/The%20case%20against%20msvcrt.dll/ [20:12:58 CEST] <BtbN> That only lists reasons why it would not do that. [20:13:36 CEST] <Dresk|Dev> That DLL was what Microsoft used to use with new versions of Windows, updating the runtime and putting it in the same file, so you never know what version you're really gonna have [20:14:04 CEST] <Dresk|Dev> Now with WinSxS we can have the individual runtime DLLs and make sure we're executing on the correct one [20:14:17 CEST] <Dresk|Dev> Myth #3 is particularly damning [20:14:25 CEST] <BtbN> From how I understand this library, it comes with windows by default, and export a minimum standard set of features. So using it should be perfectly safe. [20:14:59 CEST] <BtbN> I don't think MinGW uses any higher level features from it. [20:15:04 CEST] <BtbN> It has its own runtime for that after all. [20:15:39 CEST] <Dresk|Dev> Newer C99 features and the like are not guaranteed to work in MSVCRT.dll [20:16:09 CEST] <BtbN> That's what gcc has its own runtime for. [20:17:04 CEST] <Dresk|Dev> In general you can't mix VC runtimes, though exceptions do exist, such as MSVCRT mixing with explicit runtimes, but it's not clean, professional code [20:17:23 CEST] <cone-393> ffmpeg 03Paul B Mahol 07master:b3c6e89d4871: avfilter/avf_showspectrum: do not use uninitialized memory [20:17:24 CEST] <cone-393> ffmpeg 03Paul B Mahol 07master:e2a39b103e59: avfilter/avf_showvolume: use current peak value for picking colors [20:17:34 CEST] <BtbN> Tons of applications are using mingw64, they all work fine. And use their own runtime anyway... [20:18:29 CEST] <Dresk|Dev> But if you build an app in MSVC and include libs built wiht mingw64, you're really playing with fire, and it will only get worse [20:18:53 CEST] <BtbN> No you're not. Using multiple shared versions of MSVC runtimes is perfectly supported. [20:19:05 CEST] <BtbN> You just can't link more than one statically, for obvious reasons. [20:19:52 CEST] <Dresk|Dev> Before you yell at me some more, due to only needing basically 2 containers and 5 codecs, we're trying to build ffmpeg statically since the binary size increase isn't that bad [20:20:15 CEST] <BtbN> Keep in mind that you might run into licensing issues with that. [20:20:23 CEST] <BtbN> Ending up with a binary that cannot be redistributed. [20:20:27 CEST] <Dresk|Dev> We're aware [20:22:40 CEST] <BtbN> I'm quite sure an ffmpeg.exe with a microsoft VC runtime statically linked into would fall into that category. [20:28:30 CEST] <Dresk|Dev> So, think I can get YASM going in MSVC2015 for a proper build? [23:14:20 CEST] <Dresk|Dev> Did ffmpeg 3.x introduce significant performance advantages over 2.x / 2.8.x+? Almost seems like my CPU is a little more taxed [23:18:31 CEST] <Compn> Dresk|Dev : what cpu ? [23:19:16 CEST] <Compn> Dresk|Dev : bonus question, if you can make a testcase and test ff 3.x v ff 2.x we can find the speed bug if it exists [23:19:43 CEST] <Compn> e.g. run the same ffmpeg command , same file, on same computer with both versions and see if there is speed diff [23:19:53 CEST] <Dresk|Dev> Compn: RIght now testing on 4960x under 32bit binary Windows OCed to 4.8Ghz [23:20:10 CEST] <durandal_1707> what command? [23:20:36 CEST] <Dresk|Dev> We've integrated ffmpeg into our OGL program and are rendering to textures [23:20:56 CEST] <Dresk|Dev> I'd just profile the various ffmpeg calls I guess and see if they take more [23:22:29 CEST] <Compn> i dont think we do time based checks [23:22:36 CEST] <Compn> i requested this feature in FATE testing a long time ago [23:22:44 CEST] <Compn> but .... no one seems to care [23:25:41 CEST] <durandal_1707> what decoder/encoder so on, provide useful info [23:40:27 CEST] <cone-599> ffmpeg 03Michael Niedermayer 07master:cc13bc8c4f0f: avcodec/h2645: Fix NAL unit padding [23:40:27 CEST] <cone-599> ffmpeg 03Michael Niedermayer 07master:382a68b0088b: vcodec/h2645_parse: Clear buffer padding [23:41:25 CEST] <Dresk|Dev> Actually, to be most honest I just moved from 2.8.2 to 3.1.2 and I'm trying to fix these 2 deprecated things with not much documentation [23:52:04 CEST] <durandal_1707> ignore them [23:52:14 CEST] <durandal_1707> for now [23:57:04 CEST] <Dresk|Dev> It was just passing in a context for avcodec_alloc_context3(codec) such that I could pass in the context for avcodec_open2 (instead of codec) [00:00:00 CEST] --- Fri Aug 19 2016

1 0

ffmpeg.log.20160818
by burek 19 Aug '16

19 Aug '16

[00:33:09 CEST] <CFS-MP3> [ffmpeg/video] h264: co located POCs unavailable [00:33:12 CEST] <CFS-MP3> What does that mean? [00:34:13 CEST] <DHE> stream corruption. I've seen that if the first frame isn't a keyframe [04:01:28 CEST] <i336> Hi. How can I get monitor the output of a filter graph using -sdl with ffmpeg? [04:01:31 CEST] <i336> I'm using: ffmpeg -f v4l2 -input_format yuyv422 -framerate 30 -video_size 640x480 -i /dev/video0 -i /dev/video1 -filter_complex "[0:v]setpts=PTS-STARTPTS, transpose=1, pad=iw*2:ih[bg]; [1:v]setpts=PTS-STARTPTS, transpose=2[fg]; [bg][fg]overlay=w" -vcodec libx264 -tune zerolatency -preset slow -f h264 -b:v 1000k udp://127.0.0.1:9999 [04:02:05 CEST] <i336> I'd like to figure out where to cram -sdl in there so that I can monitor the output of the filter graph - -sdl reports that it can't monitor both input sources. [04:03:30 CEST] <i336> The reason I want to do _that_ is because udp:// introduces about 15 seconds of latency, for some reason, even over localhost - if I can minimize that to maybe a second that would be a workable solution too [04:04:09 CEST] <i336> Oh, and "ffmpeg -b:v 10000k - | ffplay -" is really slow to update as well. [06:45:05 CEST] <c_14> i336: -f sdl blah [08:25:48 CEST] <kdehl> kepstin: I can't find any pointer to the start of the image. [08:26:34 CEST] <kdehl> I'm using DecodeFrameNoDelay(), which is recommended according to the comments in the header file. [08:27:38 CEST] <kdehl> The only information I get is iBufferStatus, uiInBsTimeStamp, uiOutYuvTimeStamp, width, height, format and stride. [09:40:23 CEST] <viric> I'm finally testing shotcut [10:08:17 CEST] <Mateon1> Hi, I have a quick question. How do I convert an audio file to raw PCM? `ffmpeg -i file.ext -c:a u16le file.u16.raw` doesn't work, it says it's unable to find suitable output format for file.u16.raw, and then says it's an invalid argument [10:10:55 CEST] <Mateon1> log: http://pastebin.com/vjqJuW3k [10:11:32 CEST] <Mateon1> Actually, here I use -acodec, but -c:a gives the same result [11:43:07 CEST] <flux> mateon1, ffmpeg -y -i input.wav -f s16le -ar 48k ${base}.pcm has worked for me [11:43:38 CEST] <Mateon1> flux: Ah, so did I miss a few options? What does -y and -ar do? [11:43:53 CEST] <flux> oh, well -y is force overwrite, but -f is the more important one [11:44:16 CEST] <flux> it forces the output file format [11:44:23 CEST] <Mateon1> Ah, so -f, not -c [11:44:50 CEST] <flux> I think -f is like mpeg4, avi when -c is like h264 or mp3 [11:45:16 CEST] <Mateon1> flux: Thanks, that worked perfectly, by the way [11:47:58 CEST] <Mateon1> Also, I just tried playing the source wav file in ffplay, and the Fourier transform visualization built in is better than in my actual audio analysis toolset... Where can I see documentation on that, or the sourcecode? [11:49:07 CEST] <viric> Mateon1: remember that it is lgpl :) [11:54:27 CEST] <durandal_1707> Matron: you haven't tried showspectrum filter, it is that on steroids [11:56:13 CEST] <durandal_1707> Mateon1: see above [11:56:29 CEST] <Mateon1> Okay, I'll try that [12:00:03 CEST] <Mateon1> Hm, I'm not quite sure how to pass the audio through a filter [12:00:27 CEST] <Mateon1> ffplay file -af showspectrum fails, while -vf doesn't do anything [12:01:31 CEST] <Mateon1> http://pastebin.com/8k38TRjK [12:01:56 CEST] <viric> ffplay -vf showspectrum file.mp3 looks good [12:02:25 CEST] <viric> ah, the same spectrum as without the -vf [12:08:44 CEST] <Mateon1> I found the source code, and I'm both scared and amazed [12:09:52 CEST] <Mateon1> I'm amazed that all the source code for ffplay is just 135k of C code, I'm scared it's all in a single file, with not the best looking code I've seen. [12:10:22 CEST] <durandal_1707> viric: Dont use ffplay, use ffmpeg [12:11:12 CEST] <durandal_1707> Mateon1: see showspectrum code [12:11:49 CEST] <durandal_1707> It's 1k lines [12:15:08 CEST] <viric> The manual has a oneline that shows how to use showspectrum in ffplay [12:15:11 CEST] <viric> (man ffmpeg-filters) [12:15:38 CEST] <durandal_17> https://www.youtube.com/watch?v=DJwX0KfGmmo [12:17:31 CEST] <viric> ffplay -f lavfi 'amovie=jovial.mp3, asplit [a][out1]; [a] showspectrum=mode=separate:color=intensity:slide=1:scale=cbrt [out0]' [12:29:44 CEST] <Mateon1> Wow, now I wonder if I can hook up a microphone to this thing [14:03:59 CEST] <miller15> Hey everyone, I'm trying to get thumbnails from a video every 5 seconds. I have tried ffmpeg -i input.mp4 -vf fps=1/5 out%d.jpg, but it seems to be grabbing the frames in this order. 0s, 2s, 7s, 12s, 17s [14:04:26 CEST] <miller15> Has anyone encountered this before? [14:06:13 CEST] <miller15> Also using -ss 5 gives frames from the following times, 5s, 7s, 12s, 17s [14:08:53 CEST] <BtbN> try a diffrent rounding method [14:09:07 CEST] <BtbN> like, zero or inf [14:09:38 CEST] <BtbN> Or just plain down. The default near might behave weird for a that low framerate. [14:14:33 CEST] <miller15> forgive me, but different rounding method? [15:11:29 CEST] <miller15> I tried fps=0.20 but still the same output occurring. hmm [15:14:12 CEST] <durandal_1707> rounding [15:14:48 CEST] <DHE> miller15: https://ffmpeg.org/ffmpeg-filters.html#fps-1 <-- read [15:18:19 CEST] <miller15> ah thank you very much, I think that's got it. I used :round=zero [15:20:10 CEST] <miller15> going to test with a few videos [15:24:56 CEST] <maziar> what does it mean "frame=28636 fps=257 q=28.0 size=N/A time=00:19:05.96 bitrate=N/A" [15:28:11 CEST] <durandal_17> that you are not using latest ffmpeg [15:29:59 CEST] <maziar> durandal_17 you talk with me ? [15:33:12 CEST] <durandal_17> yes [18:47:27 CEST] <jpack> Hello, I use FFMPEG to mix two audio files that are in .m4a format. The audio files are rarely over 2 minutes long, but the command takes a bit long for the user. I was curious if anyone sees anything that could optimize for speed with this. http://pastebin.com/FfpNTKP8 Thank you [18:57:45 CEST] <durandal_17> jpack: why volume=1? that does nothing [18:58:15 CEST] <durandal_17> jpack: pan may be slow, try mixing with swresample [18:58:25 CEST] <jpack> I normally have a float variable there but just placed it to 1 to avoid confusion in it. [18:59:04 CEST] <durandal_17> jpack: what "bit long" means? [19:02:19 CEST] <jpack> I can't seem to find the swresample documentation durandal_17 [19:06:01 CEST] <viric> durandal_1707: I think you suggested shotcut to me; I thought I tried it before, but I did not. I tried it today... it's quite bad at handling 1h long clips [19:06:10 CEST] <viric> durandal_1707: any change of zoom in the timeline takes ages [19:10:00 CEST] <jpack> I can't seem to find the swresample documentation durandal_17 [19:20:29 CEST] <durandal117> jpack: how long it takes? how long you want it should take? [19:41:04 CEST] <ChocolateArmpits> Something might be up with read speed, write speed [22:45:09 CEST] <tab1293_> what are the accepted formats when specifying bitrates? ive only seen -b:a 256k [22:45:21 CEST] <tab1293_> are there other suffixes that are valid? [22:46:10 CEST] <parsec> tab1293_, I've never needed anything else [22:47:22 CEST] <furq> you can use m or g [22:47:27 CEST] <furq> not that you'd need to [22:47:37 CEST] <furq> https://ffmpeg.org/ffmpeg.html#Options [22:47:41 CEST] <tab1293_> and a number by itself is just bits? [22:48:02 CEST] <furq> you can also use B for bytes, and KB/MB/etc [22:48:06 CEST] <furq> yes [22:48:34 CEST] <tab1293_> cool thanks! [00:00:00 CEST] --- Fri Aug 19 2016

1 0

ffmpeg-devel.log.20160817
by burek 18 Aug '16

18 Aug '16

[00:02:13 CEST] <durandal_1707> I was watching someone other day claiming more than 50% [00:05:22 CEST] <michaelni> depends on content [00:07:44 CEST] <durandal_1707> I know, but for the content you tried? [00:19:58 CEST] <michaelni> for vsynth_lena-ffv1 it compresses better than 50% [00:21:12 CEST] <durandal_1707> tried something bigger? [00:21:47 CEST] <jamrial> durandal_1707: for artificial content you could try testsrc or testsrc2 [00:23:23 CEST] <durandal_1707> I mean non-boring content [00:24:05 CEST] <durandal_1707> something like big buck buny but 16 bit [00:24:42 CEST] <durandal_1707> besides testsrc2 have noise [00:25:08 CEST] <jamrial> big buck bunny doesn't? [00:25:27 CEST] Action: michaelni doesnt have much 16bit content especially not noiseless ... [00:26:20 CEST] <durandal_1707> jamrial: yes, they are images iirc [00:27:40 CEST] <durandal_1707> those bitplanes with pure noise effectively have no useful signal, so just ditch plane [00:28:18 CEST] <durandal_1707> and you now have lossy ffv1 [04:19:30 CEST] <cone-771> ffmpeg 03Jan Sebechlebsky 07master:9023a4a30c83: doc/APIchanges: Document addition of list BSF API in lavc [04:25:13 CEST] <cone-771> ffmpeg 03James Almer 07master:f85842b09e08: doc/APIChanges: fill in missing git hashes [13:49:10 CEST] <cone-607> ffmpeg 03Paul B Mahol 07master:ed8d7e7a9b66: avfilter: add bitplanenoise filter [13:49:10 CEST] <cone-607> ffmpeg 03Paul B Mahol 07master:d299defbba30: avfilter/Makefile & allfilters: sort entries [14:29:37 CEST] <durandal_1707> michaelni: idea for outreach: mt in lavfi [14:32:04 CEST] <durandal_1707> *frame mt [14:51:02 CEST] <michaelni> durandal_1707, feel free to add it to https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12 if you want to mentor it [15:36:03 CEST] <cone-607> ffmpeg 03Clément BSsch 07master:2477775bf837: doc: add Libav merge document [16:34:25 CEST] <cone-607> ffmpeg 03Clément BSsch 07master:b2016189db99: lavf/utils: add some const to pointers parameters in a few functions [16:34:26 CEST] <cone-607> ffmpeg 03Clément BSsch 07master:ffd71c9c5c64: lavf: mark stream as const pointer in av_stream_get_side_data() for next bump [16:34:27 CEST] <cone-607> ffmpeg 03Clément BSsch 07master:fabff1024438: lavf/version: fix belive/believe typo [16:36:31 CEST] <kierank> does movd have alignment restrictions [16:49:22 CEST] <durandal_1707> Compn: what happened to your little task? [16:50:57 CEST] <Compn> somehing cam up [16:50:59 CEST] <Compn> ready now [16:52:00 CEST] <Compn> so someone paid you to do sheer stuff? :) [17:05:26 CEST] <jamrial> kierank: no [17:23:09 CEST] <durandal_1707> Compn: aliens [17:23:10 CEST] <Compn> durandal_1707 : ok, figured out sheer [17:23:14 CEST] <Compn> added to mplayer [17:23:18 CEST] <Compn> testing all samples now [17:23:59 CEST] <durandal_1707> that player doesn't care [17:24:22 CEST] <Compn> ? [17:24:55 CEST] <durandal_1707> guess our lord and savior [17:29:54 CEST] <Compn> vlc ? [17:35:25 CEST] <Compn> durandal_1707 : sheer added to mplayer [17:35:42 CEST] <Compn> and ylc codec (sssssh i didnt test) [17:37:51 CEST] <jamrial> ubitux: there was no need to bump minor for that scheduled const change. there's no effective change right now to justify it [17:38:27 CEST] <ubitux> it was said to follow that ifdefery dance on the ml [17:38:35 CEST] <ubitux> so i did [17:38:43 CEST] <jamrial> ah [17:38:52 CEST] <jamrial> it's not an isse anyway [17:39:03 CEST] <jamrial> but IMO was not necessary [17:42:32 CEST] <durandal_1707> Compn: hurray! [18:08:56 CEST] <cone-607> ffmpeg 03Carl Eugen Hoyos 07master:4c42d30602f1: lavf/pcmdec: Map mime_type audio/L16 to the s16le demuxer. [18:08:57 CEST] <cone-607> ffmpeg 03Carl Eugen Hoyos 07master:ec9d7047c441: ffmpeg: Do not set too large bits_per_raw_sample. [18:12:04 CEST] <cone-607> ffmpeg 03Stephen Hutchinson 07master:f84cff8565e9: compat/avisynth: update AviSynth+ header [18:26:32 CEST] <durandal_1707> why tinterlace mode merge sets strange dar [22:03:21 CEST] <cone-176> ffmpeg 03Paul B Mahol 07master:345c252e9c19: avfilter/avf_showspectrum: unbreak dB legend [22:03:21 CEST] <cone-176> ffmpeg 03Paul B Mahol 07master:5ee5f4b13cc4: avfilter/avf_showfreqs: make minimum amplitude for log scaler configurable [22:10:57 CEST] <cone-176> ffmpeg 03Carl Eugen Hoyos 07master:a810126fd1b9: lavc/rscc: Fix colourspace for codec_tag RSCC and 32bpp. [22:40:06 CEST] <durandal_1707> michaelni: default resampling params give poor quality [22:42:33 CEST] <durandal_17> michaelni: try: ./ffmpeg.exe -f lavfi -i aevalsrc="0.9*sin(PI*t*t*t*t):s=96000",aresample=44100 -lavfi showspectrum=scale=log -f nut -c:v rawvideo -an -|mplayer.exe - [22:43:54 CEST] <jamrial_> durandal_17: did you open the swr_drop_output bug ticket? wm4 seems to have trouble with it and ended up working around it in a sledgehammer way [22:45:48 CEST] <durandal_1707> jamrial: nope, but try looping audio with swr [22:46:21 CEST] <durandal_1707> I planned to wrote using example program [22:46:57 CEST] <durandal_1707> but give up finding there are useless exampless in docs [22:51:28 CEST] <durandal_17> eg: no example that does decoding and resampling at same time [23:01:50 CEST] <kierank> durandal_17: swresample and avresample docs are useless as well [23:03:47 CEST] <durandal_17> jamrial_: swr_drop_output may be culprit [23:04:16 CEST] <durandal_17> so you loop and resample at same time [23:04:27 CEST] <michaelni> durandal_17, the swr filter parameters where tuned by some people with ears, so quality of th default filters should be good [23:04:59 CEST] <kierank> durandal_17: swr_compensate isn't documented at all [23:05:26 CEST] <durandal_17> michaelni: i can hear another signal in command i gave [23:05:53 CEST] <durandal_17> and its obvious if you use log scaler to see it [23:06:41 CEST] <durandal_17> the soxr resampler in swr does not exibit this bug [23:09:03 CEST] <durandal_17> try: ./ffmpeg.exe -f lavfi -i aevalsrc="0.9*sin(PI*t*t*t*t):s=96000",aresample=44100:resampler=soxr -lavfi showspectrum=scale=log -f nut -c:v rawvideo -an -|mplayer.exe - [23:11:10 CEST] <michaelni> filter_size=256:linear_interp=1 should avoid the vissible stuff too [23:12:06 CEST] <michaelni> the parameters simply where tuned to be fastest where absolutely no artifacts could be heared on real world material IIRC [23:12:56 CEST] <michaelni> if you can hear artifacts with real world material then please tell me what the fastest parameters are that are free of audible artifacts [00:00:00 CEST] --- Thu Aug 18 2016

1 0

ffmpeg.log.20160817
by burek 18 Aug '16

18 Aug '16

[00:00:05 CEST] <CoJaBo> Ah, that'd do it.. but if that's the case, you probably expanded the size of the video stream [00:00:35 CEST] <CoJaBo> Yeh, I can't recall ever seeing an MKV that wasn't encoded specifically with x264 [00:00:55 CEST] Action: c_14 has several mkvs with all sorts of video codecs [00:01:24 CEST] <CoJaBo> I have some too, but only when I've stream-copied from some other container.. never seen them made elsewhere like that [00:01:53 CEST] <CoJaBo> The stupidest thing I've ever seen was someone "compressing" videos using MPEG1 [00:02:19 CEST] Action: c_14 even has an mkv encoded with snow [00:02:21 CEST] <c_14> Because why not. [00:03:21 CEST] <CoJaBo> They'd take a ~100MB clip that was 5MB of x264-encoded video and 95MB of uncompressed audio, then compress that to a 50MB clip with no sound that looked horrificly bad [00:03:29 CEST] <CoJaBo> I can't even. [00:11:26 CEST] <Bray90820> Honestly I don't see why anyone would even have a need to do something like that [00:24:43 CEST] <CoJaBo> Bray90820: 50MB size limit [00:25:03 CEST] <Bray90820> I guess [00:25:22 CEST] <Bray90820> But I'm good with what I have [00:29:58 CEST] <Conder> hello, how to identify what preset has been used for x264 encoded file? mediainfo doesnt show it. [00:32:52 CEST] <durandal_1707> why you use mediainfo? [00:33:50 CEST] <durandal_1707> unless its exported as metadata you can only guess by watching [00:35:15 CEST] <CoJaBo> I just use `strings`; if it's there, it'll show up [00:35:46 CEST] <furq> Conder: http://dev.beandog.org/x264_preset_reference.html [00:35:54 CEST] <furq> you can figure it out from the mediainfo output and that [00:36:41 CEST] <furq> subme is unique for each preset so that's a good place to start [00:37:06 CEST] <Conder> nice, thx [00:40:59 CEST] <furq> durandal_1707: http://vpaste.net/456Zb [00:41:04 CEST] <furq> ffprobe doesn't show that afaik [00:42:49 CEST] <durandal_1707> what ffprobe commands you tried? [00:42:55 CEST] <furq> -show_streams [00:43:36 CEST] <durandal_1707> will try tomorrow... [00:43:48 CEST] <furq> and -show_format since i think that string is container metadata [01:06:08 CEST] <deweydb> I would like to take a vertical video (9:16) and crop it, and vertical letterbox it to 4:3. right now i've got: -filter_complex "crop=w=iw:h=iw*a:x=0:y=n*(ih-oh)/(819)" [01:06:15 CEST] <deweydb> where 819 is number of frames. [01:06:26 CEST] <deweydb> but i don't know how to do the 4:3 part and the black bars on left and right [01:07:20 CEST] <deweydb> the last part there can be ignored, i guess i should have simplied my example and said my current command is: -filter_complex "crop=w=iw:h=iw*a:x=0:y=0" [01:16:04 CEST] <furq> durandal_1707: looks like it's part of the video stream [01:16:06 CEST] <furq> http://vpaste.net/EjdLe [02:55:25 CEST] <rkantos> how might I pipe ffplay after a youtube stream? I just want to be sure that the stream works.. By the looks of things the stream with colorkey still seems to be ok, but youtube doesn't start streaming with it. cpu usage is under 50%..., so it shouldn't be a performance issue. [08:11:43 CEST] <jya> hi... when using ffmpeg to truncate a flac file, it doesn't appear to rewrite the metadata to indicate the new size [08:12:07 CEST] <jya> I did ffmpeg -i input.flac -ss 00:00:30.0 -t 4 -acodec copy flac.flac [08:12:11 CEST] <jya> am I missing something? [09:47:57 CEST] <viric> oh. h264 veryslow is not that much slower than medium [09:48:02 CEST] <viric> x264 I mean [09:48:36 CEST] <viric> less than 4x slower I'd say [11:04:11 CEST] <flux> you call 4x slower "not that much slower"?-) [11:04:26 CEST] <infinarchy> talking about presets. huh? [11:05:18 CEST] <viric> flux: right. I expected 20x slower :) [11:05:53 CEST] <flux> viric, are you getting better results? [11:06:14 CEST] <viric> flux: I'm checking. I was dumb enough to test with different crf :) [11:06:21 CEST] <flux> of course :) [11:06:39 CEST] <viric> So, for what I understand, for the same crf I should get a smaller file [11:06:41 CEST] <flux> the scientific method "always vary more than one parameter to converge faster" [11:06:55 CEST] <viric> hehe very well stated. [11:07:33 CEST] <viric> flux: medium crf30 vs veryslow crf45. The file was definitely smaller :) [11:08:05 CEST] <viric> I found crf=30 to be the greatest acceptable value (I go for small files) [11:08:41 CEST] <infinarchy> crf 30. rly? sounds bad. [11:08:50 CEST] <infinarchy> i prefer higher quality [11:08:56 CEST] <viric> 2h recordings [11:09:02 CEST] <infinarchy> so? [11:09:08 CEST] <infinarchy> i use crf 18 [11:09:20 CEST] <viric> and ethernet bandwidth [11:09:23 CEST] <viric> I guess :) [11:09:53 CEST] <infinarchy> check this: http://slhck.info/articles/crf [11:09:53 CEST] <viric> these are for public download (archive.org) [11:10:25 CEST] <viric> infinarchy: I know about the crf [11:10:51 CEST] <flux> small size is fine, but so is the lack of artifacts :) [11:11:20 CEST] <viric> Right. 30 seems good enough for me. :) [11:12:17 CEST] <viric> the camera isn't that good either. [11:18:42 CEST] <viric> moreover, many people are used to the artifacts already. [11:19:11 CEST] <flux> .. [11:19:15 CEST] <viric> :) [11:19:16 CEST] <flux> like the worst reason ever :) [11:20:06 CEST] <viric> See, we had good TV, interlaced (50fps), in CRT. Then we got those TFT screens, which had worse contrast. [11:20:24 CEST] <viric> Then we got youtube, and spread of 25fps video, and full of artifacts [11:20:44 CEST] <viric> Then we got DVB-T mpeg2, that gave even more artifacts than what people got in DivX. [11:21:04 CEST] <viric> with HD flat screens. [11:21:26 CEST] <viric> And when we got FullHD and h264 DVB-T, we get everyone recording with mobile phones and rolling shutter cameras [11:21:47 CEST] <bencoh> "'good' TV" huhu [11:21:49 CEST] <viric> with heavy video compression in social networks, full of artifacts [11:22:06 CEST] <viric> So [11:22:14 CEST] <bencoh> we had another kind of artifacts back then :) [11:22:15 CEST] <viric> (and noone buying bluerays) [11:22:56 CEST] <viric> bencoh: right, but lack of square pixels made the low resolution look like slighly out of focus and little more. [11:23:23 CEST] <bencoh> bleeding colors, blooming, not-so-good definition/resolution, cropped picture, ... [11:23:24 CEST] <viric> and 50fps was great. I love the 50fps [11:23:52 CEST] <viric> bencoh: that's more for low-band vhs, isn't it? [11:23:57 CEST] <bencoh> dont get me wrong, I still play arcade games and wish I kept my CRT or bought a multisync/15k screen, but ... [11:24:09 CEST] <viric> :) [11:24:26 CEST] <viric> The bw of PAL was quite good. But VHS was quite below it [11:25:18 CEST] <bencoh> I lived in the PAL world, but it still wasnt that good [11:28:10 CEST] <viric> better than a rolling-shutter mobile phone recording at 25fps without stabilizer. [11:28:19 CEST] <bencoh> agreed :) [12:29:41 CEST] <viric> furq: long ago I made some work regarding jpeg and its artifacts [12:30:11 CEST] <viric> furq: more artifacts gave the impression of a sharper image [12:30:29 CEST] <viric> furq: so, reducing the artifacts efectively was perceived as lack of sharpness [13:59:59 CEST] <kepstin> viric: yeah, x264's psy optimizations make use of that effect - for noisy/high detail video areas at low bitrate, it'll put artifacts there rather than attempt to encode the detail accurately, to give the impression of more detail. [14:05:51 CEST] <viric> kepstin: great [14:12:21 CEST] <kdehl> So, I have encoded a yuv file to H.264 using OpenH264, and now I try to decode the H.264 file back to YUV. I get three buffers, a Y, U and V. But they don't seem to make much sense. When I save them to separate files, this is what I get: http://dose.se/~madman/hex/ [14:13:00 CEST] <kdehl> First, the Y part seems to be padded with a lot of zeros for each line. [14:13:31 CEST] <kdehl> (It's the Static 152x100 yuv file that comes with the package that I am playing with.) [14:14:42 CEST] <kdehl> Anyone knows OpenH264? [14:16:26 CEST] <kepstin> kdehl: it looks like it's using a stride that's longer than the width of the image (stride 0xC0, while the image width is 0x98) [14:16:35 CEST] <kepstin> so you just have to account for that. [14:16:53 CEST] <kepstin> the stride should be given to you somehow... [14:16:58 CEST] <kdehl> It does, doesn't it. [14:17:10 CEST] <kdehl> The only info I can find about the output is the width and height. [14:18:37 CEST] <kdehl> What is the point of strides anyway? [14:18:56 CEST] <kdehl> I can imagine HBlank and the likes on CRT TVs, but nowadays? [14:19:27 CEST] <kepstin> efficiency, it makes it so the start of a line is on a nice even byte boundary, so still like sse/avx can operate on aligned values [14:20:11 CEST] <kdehl> Yeah okay. That makes sense. [14:20:24 CEST] <kdehl> C0 is a pretty even number. [14:20:32 CEST] <kepstin> ffmpeg's "crop" filter makes use of it - it doesn't actually change the image data, just the start pointer, line count, and image width/stride values. [14:20:35 CEST] <kdehl> I guess. [14:20:38 CEST] <furq> yeah it would be crazy if we were still using things that only made sense on old TVs [14:20:46 CEST] <kdehl> Ah. [14:21:02 CEST] <kdehl> furq: Yeah really... Like interlacing... heh. [14:21:08 CEST] <furq> i was thinking more of yuv but sure [14:21:14 CEST] <viric> what is better than interlacing, nowadays? :) [14:21:20 CEST] <furq> not interlacing [14:21:25 CEST] <viric> I like 50fps [14:21:28 CEST] <viric> 50fps progressive? [14:21:33 CEST] <furq> sure [14:21:50 CEST] <kdehl> furq: Ah. Heh. :) [14:21:56 CEST] <viric> isn't it more cpu load than just interlacing? [14:22:06 CEST] <durandal_1707> 120 fps [14:22:15 CEST] <furq> i imagine it's less cpu load than running a deinterlacer [14:22:24 CEST] <furq> it's certainly less than running a good one [14:22:31 CEST] <kdehl> YUV makes sense though, doesn't it. Like chroma subsampling. Or maybe there are better ways of doing it, I dunno. [14:22:35 CEST] <kdehl> I just learned about it. :) [14:22:39 CEST] <viric> furq: the nvidia hw deinterlacer is quite good [14:23:05 CEST] <viric> I wish intel hw had it [14:23:10 CEST] <kepstin> kdehl: the openh264 api should be giving you stride, https://github.com/cisco/openh264/blob/master/codec/api/svc/codec_api.h#L358 - you pass in a int pointer that it'll fill with the stride value [14:23:14 CEST] <furq> i'm using a slower-than-realtime one for dvd ripping, so i don't want to hear about interlacing right now [14:23:20 CEST] <viric> hehe [14:23:21 CEST] <furq> that's slower than realtime on 8 threads [14:23:28 CEST] <viric> furq: what one? [14:23:30 CEST] <furq> qtgmc [14:23:33 CEST] <viric> furq: do you store 50fps? [14:23:39 CEST] <furq> depends on the source, but usually [14:23:41 CEST] <viric> ok [14:23:55 CEST] <kepstin> kdehl: looks like there's some newer more recommended apis that'll store it in a picture information structureof some sort [14:23:56 CEST] <viric> double fps is far from double file size, in x264? [14:24:06 CEST] <furq> at slow settings it doesn't make much difference [14:24:13 CEST] <furq> i imagine at ultrafast it would be close to twice the size [14:24:16 CEST] <viric> ah ok [14:24:37 CEST] <viric> furq: what image height do you store? full frame, or only field height? [14:24:43 CEST] <furq> full frame [14:24:47 CEST] <viric> I guess full frame, with the good deinterlacer [14:24:48 CEST] <viric> k [14:24:49 CEST] <viric> ok [14:25:00 CEST] <furq> http://avisynth.nl/index.php/QTGMC [14:25:00 CEST] <viric> I will try for the 50fps; I thought it would be double size [14:25:13 CEST] <kdehl> kepstin: Thank you! I haven't seen that one. I just followed the example in the comments in the beginning of that very file. [14:25:16 CEST] <furq> it's based on nnedi3 which is available in libavfilter, but it's single-threaded in libavfilter [14:25:18 CEST] <viric> furq: do you use avisynth? [14:25:22 CEST] <furq> i use vapoursynth [14:25:30 CEST] <furq> avisynth-mt really enjoys crashing [14:25:38 CEST] <furq> which is annoying after 7 hours of encoding [14:26:00 CEST] <viric> aha [14:26:08 CEST] <viric> furq: I wanted to use an avisynth piece... [14:26:23 CEST] <viric> I can't remember the name. For the VHS bad hclock [14:26:30 CEST] <kdehl> kepstin: BTW, do you know whether DecodeFrameNoDelay decodes all frames in the H.264 buffer or does it only decode one frame at a time? [14:26:31 CEST] <viric> would that work in vapoursynth? [14:26:38 CEST] <furq> no idea, i've never touched vhs stuff [14:26:42 CEST] <furq> it depends if someone has ported the plugin [14:26:53 CEST] <furq> i've only ever really used avisynth for qtgmc and srestore [14:27:00 CEST] <kepstin> kdehl: no idea, I only read the header just now to find where the stride is stored :) [14:27:06 CEST] <kdehl> Maybe it ought to be DecodeFrameSNoDelay. But I don't trust the Chinese to distinguish between singular and plural. :) [14:27:13 CEST] <kdehl> kepstin: Ah okay. [14:27:50 CEST] <viric> why isn't qtgmc in ffmpeg? [14:28:16 CEST] <furq> iirc libavfilter doesn't do frame multithreading so it'd be pretty useless [14:28:31 CEST] <furq> nnedi on its own is unusably slow with one thread [14:28:42 CEST] <viric> aha [14:28:50 CEST] <durandal_1707> it have slice threading [14:29:15 CEST] <furq> i got the impression that wasn't used by much [14:29:18 CEST] <kdehl> kepstin: But how does that work in general though? Say I want to decode just _one_ frame at a time and send a H.264 buffer to the decoder, how does the decoder know where to start reading the buffer? As I understand one frame can depend on other frames (P and B frames or whatever?). [14:29:34 CEST] <furq> wasn't/couldn't be [14:30:38 CEST] <furq> qtgmc also depends on a bunch of other filters which aren't in libavfilter, like fft3d/dfttest/knlmeanscl [14:31:45 CEST] <kepstin> kdehl: hmm. openh264 is baseline only, right? that means it doesn't have B frames [14:32:00 CEST] <viric> ok [14:32:05 CEST] <kepstin> kdehl: without B frames, it can do decoding with one-frame in, one frame out [14:32:19 CEST] <kdehl> kepstin: Aha. [14:32:23 CEST] <kepstin> (it'll internally store buffers with info needed for predicted frames) [14:32:30 CEST] <kdehl> Right. [14:32:35 CEST] <kdehl> Well, that makes sense. [14:33:54 CEST] <kepstin> with a full h264 decoder, there's a decoding delay - you may have to feed multiple frames in before you get a frame out [14:34:16 CEST] <kdehl> Right. [14:34:19 CEST] <kepstin> depending on the input stream, of course [14:34:24 CEST] <kdehl> Yeah. [14:34:43 CEST] <kdehl> Well this file was also encoded with OpenH264 so I guess I don't have to worry about that. [14:34:46 CEST] <kdehl> Oh shit. [14:35:04 CEST] <kepstin> but openh264 was written by cisco for video conferencing, so encoding modes that don't add extra delay were preferred [14:35:13 CEST] <kdehl> I just realized that later I might get a stream I need to decode that could have been encoded with other codecs. [14:35:44 CEST] <kdehl> Hm. Is this true for all video conferencing H.264 streams? [14:35:52 CEST] <kepstin> x264's "-tune zerolatency" switches it to a mode where frames are 1-in-1-out [14:36:19 CEST] <kepstin> it should be, for latency reasons. But some people might have messed it up and used bad settings :/ [14:36:19 CEST] <kdehl> Well I kinda have to use OpenH264. [14:36:26 CEST] <kdehl> Right. [14:36:29 CEST] <kdehl> Hm. [14:36:35 CEST] <kdehl> Does that mean OpenH264 can't handle it? [14:36:48 CEST] <kdehl> The decoding of that stream, that is. [14:36:55 CEST] <kepstin> openh264 can't handle anything other than baseline (or maybe constrained baseline) [14:37:27 CEST] <kdehl> Hm. Strange that the guy who started this project chose to use this codec then. [14:37:35 CEST] <kdehl> Was years ago though. Maybe he had his reasons. [14:38:05 CEST] <kdehl> It's for a video call simulator for 3G and 4G telephony. [14:38:13 CEST] <kepstin> well, the only reason to use openh264 is the cisco patent license [14:38:34 CEST] <kepstin> if it wasn't for that, ffmpeg's decoder and x264 encoder are rather better [14:38:57 CEST] <kdehl> I see. [14:39:13 CEST] <kdehl> Strange though, I thought those patents only mattered in the States. [14:39:22 CEST] <kdehl> I'm in Europe. [14:40:12 CEST] <kepstin> I'll leave that up to you and your lawyers to decide :) [14:40:36 CEST] <kdehl> Hehe. Yeah. [14:40:55 CEST] <furq> a lot of people continue to live in america for some reason [14:43:15 CEST] <kdehl> Yeah, and I'm going to be one more. [14:51:44 CEST] <kdehl> kepstin: There doesn't seem to be any stride in the U and V buffers though, could that be right? [14:51:59 CEST] <DHE> kepstin: zerolatency does other things as well. even without b-frames x264 can buffer frames for bitrate prediction purposes. zerolatency takes that away. [14:52:20 CEST] <kdehl> The stride is 40 bytes of the Y buffer, then it ought to be 10 bytes per U and V buffer, no? [14:52:47 CEST] <kepstin> kdehl: if the u/v have a stride, it should be indicated separately [14:52:57 CEST] <kdehl> kepstin: Aha. [14:53:17 CEST] <kdehl> kepstin: That makes sense, since the buffers are paresed separately. [14:53:21 CEST] <kdehl> And need to be aligned separately. [14:53:46 CEST] <kdehl> I'll try to figure out how to find them in the structs. [14:54:07 CEST] <kdehl> BTW, shouldn't it be possible to just copy the Y buffer and let U and V be zero? [14:54:13 CEST] <kdehl> I'll still get a video, right? [14:54:27 CEST] <kepstin> using the Y only will give you a B&W video, yeah [14:54:34 CEST] <kdehl> Right. [14:54:39 CEST] <kdehl> Excellent. [14:54:41 CEST] <kdehl> I'll try that first. [14:55:17 CEST] <kepstin> (need to interpret that either as single-plane B&W or set the u/v to contain all 0x80 tho) [14:55:29 CEST] <kepstin> unless you like weird colors :) [14:55:43 CEST] <kdehl> Heh. I don't mind, this is just for testing. [14:55:48 CEST] <kdehl> What's magical about 0x80? [14:55:54 CEST] <kdehl> I see a lot of those. [14:56:02 CEST] <kepstin> it's the middle/neutral value for u/v [14:56:59 CEST] <kdehl> Hm. Mkay. [14:57:05 CEST] <kepstin> if you set both to 0 you'll get red [14:57:25 CEST] <viric> what is there FOSS for videoconferencing, beyond linphone? (in C/C++) [14:57:44 CEST] <viric> telepathy for gajim maybe... never tried. [14:57:52 CEST] <viric> All I tried was horrible. [14:58:06 CEST] <viric> qtox too. [14:58:08 CEST] <kepstin> basically, you can think of the U/V as signed numbers, where 0x80 is 0, less is negative, more is positive. It's kind of a color bias thing [14:58:39 CEST] <kdehl> Huh. Okay. [14:59:23 CEST] <kdehl> Alright, well I'll try not to dig into the details. It's hard, but my boss gets annoyed when I spend an entire day reading books and Wikipedia. :-/ [15:01:04 CEST] <kepstin> you can sort of think of e.g. U as the 'blueiness', where 80 is neutral (like in grey), lower is unblue, higher is more blue. Similarly, V is 'rediness'. Not exactly correct, but it gives an idea more or less :) [15:01:29 CEST] <kdehl> Interesting. [15:01:39 CEST] <kdehl> Now you make me want to read up on it. [15:01:50 CEST] <kdehl> Boss did go home early today... [15:02:17 CEST] <kepstin> it's really just 2 arbitrary axis defining a color plane. not that exciting. [15:02:40 CEST] <kdehl> Oh. [15:02:45 CEST] <kdehl> Now I even get it. [15:03:43 CEST] <kdehl> So that is what that color plane means on Wikipedia's page on YUV. [15:04:56 CEST] <JEEB> planar = separate buffers for the parts, packed = stuff is together. and then you have mixed cases like NV12 (which GPUs seem to like) [15:05:10 CEST] <kdehl> Hm. Is it just me, or is V=0, U=+0.5 less blue than V=-0.5 and U=+0.5 [15:06:05 CEST] <kepstin> kdehl: the color space is defined based on the locations of the RGB primaries, so V=0 U=max should mean only the 'B' or RGB is lit up [15:06:15 CEST] <kepstin> well, that's not exactly true [15:06:18 CEST] <kdehl> JEEB: So what OpenH264 returns is "planar" (since there are three buffers), but a YUV file contains "packed" data? [15:06:33 CEST] <kepstin> there's some wonkiness and a matrix calculation needed [15:06:44 CEST] <JEEB> depends on how the data is handled [15:06:47 CEST] <kdehl> Yeah I saw that. [15:07:02 CEST] <kdehl> I hated linear algebra. Took me like five years to pass that exam. [15:07:29 CEST] <kepstin> kdehl: the colors on the U/V plane don't really correspond to anything - they were picked so as to minimize redundant information (i.e. have as much detail as possibly in Y, and as little in U/V) [15:07:46 CEST] <kepstin> kdehl: so that U/V could be subsampled and still look ok [15:07:52 CEST] <kdehl> kepstin: Right. [15:08:23 CEST] <kepstin> kdehl: as a result of this, most of the 'G' of RGB is actually stored in Y rather than either of the U/V planes, since humans are more sensitive to it. [15:09:10 CEST] <kdehl> And B is the other way around? Since we're less sensitive to that, IIRC. [15:09:55 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/colorspace.h;h=cc2… [15:09:57 CEST] <kepstin> yeah. There's some coefficients defined in that wikipedia article [15:10:04 CEST] <JEEB> I added this lately for BT.709 [15:10:18 CEST] <JEEB> terrible macros, but might be simpler than linear algebra:) [15:10:55 CEST] <kepstin> those macros look a lot like linear algebra to me ;) [15:11:58 CEST] <JEEB> and yeahm [15:12:14 CEST] <JEEB> they are terrible but I just added one with the correct BT.709 coeffs [15:12:27 CEST] <JEEB> so that the blu-ray subpictures would be correct finally :) [15:15:43 CEST] <kepstin> one of the hilarious parts of YUV (and YPbPr) is that you still get kinda ok looking human skin tones with only the V/Pr. One of my friends had this Pb cable come loose on component video and didn't realize for quite a while :) [15:16:09 CEST] <kdehl> Hehe. [15:18:50 CEST] <viric> furq: what is the vapoursynth output for your deinterlacing? Do you later use ffmpeg? [15:18:55 CEST] <viric> (for "final" encoding) [15:18:58 CEST] <furq> yeah [15:19:10 CEST] <viric> what is that middle format? a big file? [15:19:19 CEST] <furq> it's rawvideo [15:19:23 CEST] <furq> you can pipe it stright into ffmpeg [15:19:37 CEST] <furq> http://www.vapoursynth.com/doc/vspipe.html [15:19:50 CEST] <viric> ah, no file. ok [15:19:55 CEST] <viric> and what about sound? [15:20:00 CEST] <furq> i mux that in separately [15:20:42 CEST] <viric> another pipe [15:20:43 CEST] <viric> ? [15:20:50 CEST] <furq> http://vpaste.net/ZEWaH [15:21:15 CEST] <viric> ah, directly from the dvd files [15:21:34 CEST] <kdehl> Aha. There are two strides. I assume it's width and height of the frame. [15:21:38 CEST] <viric> what is that input file syntax ${...} ? [15:21:53 CEST] <furq> https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansio… [15:21:53 CEST] <viric> ah, bash [15:21:59 CEST] <viric> ok [15:22:00 CEST] <furq> it strips off the file extension [15:22:22 CEST] <viric> I use to run $(basename $m .extension) [15:22:27 CEST] <viric> good [15:24:31 CEST] <kdehl> Weird. The first value is 224, the other is 112. That doesn't seem to be right. [15:43:32 CEST] <viric> What do you think of 'melt'? [15:43:47 CEST] <viric> https://mltframework.org/ [15:57:49 CEST] <viric> furq: can you share your vapoursynth script? [15:57:56 CEST] <viric> for deinterlacing dvd [15:59:00 CEST] <furq> http://vpaste.net/HRsf5 [16:00:28 CEST] <furq> https://bitbucket.org/mystery_keeper/vapoursynth-editor [16:00:31 CEST] <furq> you can use that to preview scripts [16:00:36 CEST] <viric> oh nice [16:00:44 CEST] <viric> ah it is a python thing [16:00:54 CEST] <furq> yeah [16:00:59 CEST] <furq> it's slower than avisynth but less crash-prone [16:01:07 CEST] <viric> good. [16:01:12 CEST] <furq> shame they didn't write it in luajit really [16:01:26 CEST] <viric> is .d2v in the dvd? [16:01:35 CEST] <furq> no [16:01:38 CEST] <furq> that's from dgindex [16:01:50 CEST] <viric> it's quite a constellation of pieces at work [16:02:01 CEST] <durandal_1707> so why you don't use hqdn3d? [16:02:16 CEST] <furq> it's not one of the supported denoisers in qtgmc [16:02:28 CEST] <furq> i was also under the impression it was lower quality than nlmeans [16:02:52 CEST] <viric> I worked a few years with the writer of hqdn3d [16:02:58 CEST] <durandal_1707> that's just for anime [16:03:58 CEST] <furq> that's not what i've read [16:05:58 CEST] <viric> the writer of hqdn3d wrote it thinking of vhs, I think [16:06:05 CEST] <viric> very long ago. [16:07:36 CEST] <furq> i normally don't denoise anyway [16:07:46 CEST] <furq> but this source is pretty dirty [16:35:38 CEST] <magusx> Hello - is anyone here? [17:09:18 CEST] <maziar> I have a HDMI camera and i connect the camera to my system over HDMI, now i want to stream from my system to all person on my lan, how should i do it ? [17:12:19 CEST] <nonex86> capture the stream with ffmpeg and stream it with ffserver perhaps? [17:15:53 CEST] <DHE> use of ffserver is discouraged. try something else like nginx-rtmp, or multicast. what you do will depend on your network and the viewers' clients [17:20:04 CEST] <furq> if it's on a lan then you could use the hls muxer and an httpd [17:20:17 CEST] <nonex86> yeah, nginx with rtmp module good too [17:21:15 CEST] <DHE> I like multicast if it's possible. setting it up tends to require more skill than most users fully understand, unfortunately. [17:25:41 CEST] <kdehl> kepstin: You still here? [17:25:52 CEST] <kdehl> kepstin: I can't make any sense of my outputs still. [17:27:57 CEST] <kdehl> I've added an "util_output.hex.txt" to http://dose.se/~madman/hex/ [17:28:43 CEST] <kdehl> It is a hexdump of the output generated by the h264dec utility that comes with OpenH264, so it ought to be legitimate. [17:29:16 CEST] <kdehl> But the offsets are completely different from the ones the ones I get from the library. [17:30:39 CEST] <kdehl> My utility reports correctly that the h264 file has a resolution of 152x100 and that it generates a yuv output with a stride of 40. [17:32:03 CEST] <kdehl> If you look at the pattern of y.hex.txt it seems like each line is 184 bytes long (plus a stride of zeros of 40), which makes it 224. [17:32:23 CEST] <kdehl> Sorry, I meant that my program reports a stride of 224. Which seems to be correct. [17:32:29 CEST] <kdehl> And YUV420 format. [17:32:57 CEST] <kdehl> But where do those 184 bytes per row come from? [18:16:09 CEST] <Mavrik> kdehl, hmm, 152x100 file kinda shouldn't have a stride of 40 [18:16:22 CEST] <Mavrik> It should have a stride of 152*bit depth + any padding [18:19:13 CEST] <kepstin> kdehl: the decoder is allowed to put data in the padding that you're supposed to just ignore [19:19:56 CEST] <kdehl> Mavrik: Sounds somewhat excessive, doesn't it? [19:20:11 CEST] <Mavrik> Excessive? [19:20:15 CEST] <Mavrik> Which part? :) [19:20:30 CEST] <kdehl> Mavrik: Sorry, misunderstanding. [19:20:34 CEST] <kdehl> I just got home. Heh. [19:20:53 CEST] <kdehl> Mavrik: It's 224, not 40. :) [19:21:19 CEST] <kdehl> kepstin: It [19:21:40 CEST] <kdehl> kepstin: It's strange though, it seems like the first line is smaller than the rest. [19:21:49 CEST] <kdehl> Anyway, I'll look at it when I'm back at work tomorrow. [19:23:22 CEST] <kepstin> kdehl: I bet looks like it uses 16px on either side of the real image for decoder use [19:24:44 CEST] <kdehl> kepstin: You mean it pads the frame both left and right? [19:25:55 CEST] <kepstin> Yeah, but the start pointer you get will be the start of the real image. Explains why first line appears shorter [19:31:26 CEST] <wallbroken> not clear if is better to use 32 or 64 bit version of ffmpeg, anybody have a good answer? [19:32:12 CEST] <kdehl> kepstin: I wasn't aware of a start pointer. [19:32:21 CEST] <kdehl> kepstin: I'll look for it tomorrow. [19:32:35 CEST] <DHE> 64 bit should have access to features like AVX[2] if you have them. I don't think those are available on 32 bit systems [19:33:33 CEST] <wallbroken> but the product file have some difference? [19:34:39 CEST] <DHE> there may be minute floating point variances when using different calculation methods or operations [19:35:47 CEST] <wallbroken> both the output will work in the same way on all the devices? [19:37:09 CEST] <kepstin> the architecture of the ffmpeg executable has no relation to the file formats of the output files [19:41:01 CEST] <DHE> if that's your concern, don't worry. h264 is h264, etc. [19:55:59 CEST] <wallbroken> no, i'm just trying to figure out which one is better to use [19:56:27 CEST] <furq> haven't you been trying to figure this out for about two weeks now [19:56:28 CEST] <furq> just pick one [19:56:53 CEST] <kepstin> the 64bit version is likely to be marginally faster if you can run it; if you really care, test them both and compare. [20:01:26 CEST] <wallbroken> kepstin: i've done [20:01:39 CEST] <wallbroken> i've produced the same with both 32 and 64 [20:01:55 CEST] <wallbroken> and i have no clue on which one to pick [20:02:03 CEST] <kepstin> which one encoded faster? [20:02:11 CEST] <wallbroken> and i don't want to pick one of them with throing a coin [20:02:30 CEST] <wallbroken> i don't remember, but i don't care about the encoding speed [20:02:49 CEST] <kepstin> if they're about the same, the 64bit version should have better memory address randomization, which might be handy if you're encoding user-provided content (security improvement) [20:02:52 CEST] <wallbroken> i just want to focus on the outputs [20:03:21 CEST] <kepstin> the output should be identical between the two of them, modulo any tiny differences due to floating point rounding [20:03:33 CEST] <kepstin> (and you can't say one is better than the other in that case, they're just different) [20:04:21 CEST] <wallbroken> so, it should be a little bit better the 64bit one? [20:18:13 CEST] <haasn> Does libavcodec have known issues scaling to multiple cores (more than 4) for e.g. HEVC decoding? [20:18:26 CEST] <haasn> Can the codec perhaps not be parallelized further by design? [20:33:58 CEST] <Earthnail> Hi there. I'm decoding audio files, and noticed that when specifying the -t option to set a stop time, that it sometimes reads a tiny bit less than what I specified. For example, with `-t 5`, it reads 4.99 seconds of audio. Is there a way to make ffmpeg read the exact number of seconds? [20:34:59 CEST] <durandal_170> yes by using strum filter [20:35:13 CEST] <durandal_170> *atrim [20:35:46 CEST] <Earthnail> durandal_170: but that's not very efficient, is it? [20:36:34 CEST] <durandal_170> it comes with price [20:42:15 CEST] <Earthnail> Unfortunately, atrim still doesn't work: [20:42:18 CEST] <Earthnail> ffmpeg -accurate_seek -i tests/data/audio/example_mono.ogg -f s16le -ac 1 -to 6.000000 -af atrim=0.000000:5.000000 - [20:43:30 CEST] <relaxed> omit -accurate_seek and -to 6.000000 [20:44:40 CEST] <Earthnail> ffmpeg -i tests/data/audio/example_mono.ogg -f s16le -ac 1 -af atrim=end=5.000000 - [20:44:42 CEST] <Earthnail> same problem [20:46:05 CEST] <Earthnail> If I specify end_sample, it works. Unfortunately, I don't know the sample_rate when executing the command. [20:47:46 CEST] <Earthnail> Ah, now it's getting interesting: end_sample works, but end_pts does not work. [20:48:11 CEST] <kepstin> hmm. the issue is that the pts (used by -to, etc.) is per-packet, and a packet contains some number of samples [20:48:44 CEST] <kepstin> in theory, atrim could be more accurate, since it knows the sample rate so it can calculate exact times :/ [20:49:56 CEST] <Earthnail> Could the problem be that the time stamps in the file are off? That would explain why end_sample= works, since it simply reads 5*44100 samples, whereas end_pts= doesn't work since the 5 second mark is a bit earlier. [20:50:25 CEST] <pgorley> can h263p be accelerated with ffmpeg, or is it only h263? [20:51:17 CEST] <kepstin> Earthnail: hmm. I dunno about ffmpeg's internal representation, but in the ogg format audio packets are given the timestamp of the *last* sample in the packet [20:51:34 CEST] <kepstin> Earthnail: so I could see it behaving that way [20:51:46 CEST] <Earthnail> hmm. Well, I just tried duration=5 instead, but that again gave me the wrong result [00:00:00 CEST] --- Thu Aug 18 2016

1 0

ffmpeg-devel.log.20160816
by burek 17 Aug '16

17 Aug '16

[00:10:38 CEST] <durandal_1707> michaelni: swr_drop_output misbehaves [00:52:27 CEST] <michaelni> durandal_1707, is there a ticket about it ? [00:55:33 CEST] <durandal_1707> nope [01:41:24 CEST] <michaelni> please create a ticket and put me in the CC list of it, ill look when i have time [02:06:06 CEST] <bp0> is Paul B. Mahol in the room? [02:07:43 CEST] <atomnuker> the man, the legend, durandal_1707 [02:08:41 CEST] <bp0> durandal_1707 == Paul B Mahol? [02:11:41 CEST] <atomnuker> yes [02:39:41 CEST] <bp0> alright [02:39:44 CEST] <bp0> but he's gone now [02:39:45 CEST] <bp0> heh [09:55:57 CEST] <durandal_1707> bp0: ? [09:58:24 CEST] <bp0> hi [09:58:32 CEST] <bp0> I had some question, I don't recall [09:58:48 CEST] <bp0> oh, I noticed you added some handling of other sample formats to af_astats [09:59:04 CEST] <bp0> while looking through that, I noticed that you have an option to inject metadata [09:59:17 CEST] <bp0> how is that metadata used later? [09:59:21 CEST] <bp0> @durandal_1707 [10:01:31 CEST] <durandal_1707> that's only useful for graphing, because you can't add metadata to higher level at flush time, the one is mostly interested [10:02:15 CEST] <durandal_1707> to peak values of whole file not single frame [10:03:02 CEST] <bp0> hmm [10:07:30 CEST] <bp0> is there a way to read metadata in a fate test? [10:07:33 CEST] <bp0> as a result? [10:11:10 CEST] <durandal_1707> yes, via ffprobe usually [10:12:21 CEST] <bp0> but the metadata inserted by astats, for example, does not get written to the output [10:15:46 CEST] <durandal_1707> it's part of avframe [10:16:09 CEST] <durandal_1707> ffprobe can write metadata to file [10:46:48 CEST] <durandal_1707> michaelni: it involves another program, trying to write simple example [12:34:17 CEST] <cone-964> ffmpeg 03Jon Toohill 07master:c3c4c72665b9: lavc: add trailing_padding to AVCodecContext to match AVCodecParameters. [15:58:01 CEST] <cone-964> ffmpeg 03Paul B Mahol 07master:ea58dd2bebf8: avfilter/window_func: add dolph window [15:58:02 CEST] <cone-964> ffmpeg 03Paul B Mahol 07master:1457786d6920: avfilter/avf_showspectrum: do not let multiple threads to write to same part of memory [16:02:14 CEST] <cone-964> ffmpeg 03Paul B Mahol 07master:a2c40931c80d: avfilter/vaf_spectrumsynth: check return code [16:16:47 CEST] <BtbN> the tracker lacks a notabug resolution. [16:32:56 CEST] <jamrial> BtbN: isn't that what "invalid" is for? [16:33:36 CEST] <BtbN> Well, it's not an invalid complaint, but it's not a bug ffmpeg could do anything about. [16:39:45 CEST] <michaelni> BtbN, i think invalid is ok for that, but its easy to add resolution options, if theres a consensus, so if you think something should be added suggest it on the ML and if everyone likes it i or someone else will add it [17:13:42 CEST] <cone-964> ffmpeg 03Jun Zhao 07master:46bfc1562f18: ffmpeg/qsv: fix QSV-accelerated transcode performance drop issue. [18:10:01 CEST] <cone-964> ffmpeg 03Paul B Mahol 07master:b438c2025c3e: avfilter/window_func: add cauchy, parzen and poisson window function [18:54:03 CEST] <durandal_1707> don't pay Compn trip, he is not ffmpeg dev and is not adding ffmpeg codecs to mplayer [19:01:07 CEST] <iive> is that some kind of joke? because it doesn't sound funny. [19:01:42 CEST] <durandal_1707> I'm serious [19:03:46 CEST] <iive> so now you are talking shit about Compn [19:06:07 CEST] <iive> i guess your remarks about "mplayer developer" yesterday also reffered to him, then [19:06:29 CEST] <Compn> iive : i think hes joking [19:07:17 CEST] <durandal_1707> I just stated truth, truth hurts feelings [19:08:13 CEST] <durandal_1707> anyway not my choice [19:10:10 CEST] <Compn> i do have time to add codecs , now, durandal_1707q [19:10:28 CEST] <Compn> are there sample files somewhere ? [19:10:28 CEST] <durandal_1707> ok [19:10:39 CEST] <iive> if you are in a mood to tell the truth, then tell the whole truth [19:10:56 CEST] <iive> what is the thing that irritates you about Compn [19:10:57 CEST] <Compn> paul has been working hard in ffmpeg :) [19:11:05 CEST] <Compn> while i've been lazy [19:11:49 CEST] <durandal_1707> Compn: see on Trac, there is bunch of them for sheervideo [19:12:10 CEST] <durandal_1707> for ylc I care less [19:12:36 CEST] <Compn> ok :) [19:13:27 CEST] <durandal_1707> iive: you seems to be easily offended [19:14:45 CEST] <iive> durandal_1707: that's the wrong word [19:15:37 CEST] <durandal_1707> Compn: magy samples are in fate samples thing [19:17:12 CEST] <Compn> yeah i see them [19:17:14 CEST] <Compn> 492 ticket [19:17:25 CEST] <Compn> 10bit grumble, i have to find the colorspace for that [19:18:00 CEST] <Compn> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket492/ [19:18:07 CEST] <durandal_1707> just add 8bit w/o alpha for start [19:18:10 CEST] Action: Compn brb afke [19:20:33 CEST] <iive> durandal_1707: We've already seen where 1 smear campagin leads to. I'm not letting another just go past me. [19:21:37 CEST] <iive> durandal_1707: if you have a problem with somebody, tell directly and avoid a pissing off contests. [19:24:47 CEST] <omerjerk> I am writing config to extradata in the last frame as well - https://github.com/omerjerk/FFmpeg/blob/alsenc_patch/libavcodec/alsenc.c#L2… [19:25:33 CEST] <omerjerk> still when I read the bitstream in the decoder, the values in the header are the ones which were written while inside the init function. [19:26:10 CEST] <omerjerk> any idea why extradata is not being overwritten in the last frame? [19:26:42 CEST] <durandal_1707> iive: I'm really not in mood to talk about smear campaigns... [19:33:55 CEST] <iive> you know, there are nicer ways to ask Compn to do some work, than trolling. [19:34:15 CEST] <iive> and if you are no longer in trolling mood either, then my job is done. [19:36:07 CEST] <omerjerk> P.S. Is there any way to know total number of samples in the encoder beforehand? [19:36:12 CEST] <omerjerk> Like inside the init function? [19:38:12 CEST] <durandal_1707> omerjerk: nope, perhaps mp4 muxer needs change [19:38:57 CEST] <durandal_1707> like, rewrite with new extradata provided by encoder [19:41:22 CEST] <omerjerk> but flacenc also rewrite extradata in the last frame. [19:41:31 CEST] <omerjerk> So am I doing in my code. [19:42:04 CEST] <omerjerk> but the decoder reads the values which were written to the extradata in the init function. [19:42:11 CEST] <durandal_1707> Yes, but what flac muxer does? [19:43:37 CEST] <omerjerk> I didn't see that. I'm just testing with mp4 format for now. So, als muxer doesn't come into action. [19:44:30 CEST] <durandal_1707> omerjerk: right, you just need to copy functionality from flacenc when frame is null [19:45:15 CEST] <omerjerk> yes. I have done that already. And I'm rewriting the extradata in the last frame as well. But somehow it isn't getting written. [19:45:32 CEST] <omerjerk> https://github.com/omerjerk/FFmpeg/blob/alsenc_patch/libavcodec/alsenc.c#L2… [19:47:54 CEST] <Compn> bbl , 20 mins [19:48:37 CEST] <durandal_1707> omerjerk: new packet side data [19:49:27 CEST] <omerjerk> durandal_1707: means? [19:50:07 CEST] <durandal_1707> I dont see that function call in your code [19:51:05 CEST] <cone-964> ffmpeg 03Michael Niedermayer 07master:ae0192ef5fe8: avformat/mov: Check extradata before access [19:53:03 CEST] <omerjerk> which function exactly? [19:53:31 CEST] <durandal_1707> av_new_packet_side_data [19:53:56 CEST] <omerjerk> oh [19:54:01 CEST] <omerjerk> I get it now. [19:54:21 CEST] <omerjerk> thanks a ton!! I was stuck on it for past 4-5 hours. Let me test. [20:03:31 CEST] <omerjerk> it didn't work. :( [20:05:17 CEST] <omerjerk> the decoder still reads the values which were written in the first frame in the encoder regardless of me writing the extradata in the last frame. [20:18:08 CEST] <durandal_1707> omerjerk: uploaded code? [20:18:39 CEST] <omerjerk> yes. this is the latest code - https://github.com/omerjerk/FFmpeg/blob/alsenc_patch/libavcodec/alsenc.c#L2… [20:27:07 CEST] <durandal_1707> omerjerk: maybe you need also to update mov muxer [20:27:52 CEST] <omerjerk> you mean mp4? [20:30:45 CEST] <omerjerk> durandal_1707: [20:32:03 CEST] <durandal_1707> yes, I referred to source code file [20:49:30 CEST] <omerjerk> durandal_1707: I did a git pull. Still the same issue. [20:50:51 CEST] <durandal_1707> omerjerk: ups, I meant add als codec to mov muxer [20:51:18 CEST] <durandal_1707> see alac lines [20:52:07 CEST] <omerjerk> inside mov.c file or somewhere else? [20:52:12 CEST] <durandal_1707> I don't see nowhere codec Id of alsmp4 [20:52:28 CEST] <durandal_1707> omerjerk: movenc.c [21:04:35 CEST] <omerjerk> durandal_1707: Still no luck. [21:07:20 CEST] <omerjerk> may be some special change in the movenc.c needed. [21:10:04 CEST] <omerjerk> just to summarize, my bug would easily be fixed if I could get the total number of samples in the .wav file right at the beginning. [21:10:18 CEST] <omerjerk> Let me know if there is some way. :/ [21:11:00 CEST] <omerjerk> I calculate total number of samples by the end, but then I'm not able to rewrite the extradata [21:41:30 CEST] <durandal_1707> omerjerk: what you tried in movenc? [21:48:40 CEST] <omerjerk> https://github.com/omerjerk/FFmpeg/commit/3d7bbf971fa87ba1abba16dcffc65d52b… [21:48:53 CEST] <omerjerk> durandal_1707: [23:55:47 CEST] <durandal_1707> ffv1 couldn't encode 4k content last time I tried [23:56:38 CEST] <cone-456> ffmpeg 03Michael Niedermayer 07master:87da1188981f: avcodec/ffv1enc: Factor rice high depth check out [23:56:38 CEST] <cone-456> ffmpeg 03Michael Niedermayer 07master:b1d12509384b: avcodec/ffv1: Fix rgb plane ordering in experimental planar RGB [23:56:38 CEST] <cone-456> ffmpeg 03Michael Niedermayer 07master:a95fdac4c620: avcodec/ffv1enc: do not offset null pointers [23:56:38 CEST] <cone-456> ffmpeg 03Michael Niedermayer 07master:62f5e601aa4d: avcodec/ffv1enc: Add RGB48 support [23:56:38 CEST] <cone-456> ffmpeg 03Michael Niedermayer 07master:0d98686fde90: fate: Add RGB48 FFV1 test [23:58:44 CEST] <durandal_1707> michaelni: how much this can compress artificial, noiseless content? [00:00:00 CEST] --- Wed Aug 17 2016

1 0

ffmpeg.log.20160816
by burek 17 Aug '16

17 Aug '16

[00:00:12 CEST] <furq> you'll need to restart command prompt etc after you edit it [00:01:04 CEST] <Kiicki> Not sure if I'm looking at the right thing, but on the path, this comes up: C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Skype\Phone\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common [00:01:11 CEST] <sfan5> that looks right [00:01:15 CEST] <furq> 22:58:12 ( furq) edit that and add ";C:\path\to\ffmpeg" to the end [00:02:20 CEST] <Kiicki> C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Skype\Phone\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common\;C:\path\to\ffmpeg [00:02:42 CEST] <Kiicki> not sure if I did right. I added a backslash before ";C" [00:02:51 CEST] <furq> it makes no difference either way [00:03:02 CEST] <furq> also in case it wasn't obvious i meant the actual path to your ffmpeg dir [00:03:31 CEST] <Kiicki> I was wondering how it would know where it was -.- [00:05:34 CEST] <Kiicki> C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Skype\Phone\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common\C:\Program Files\FFMPEG Standalone\ffmpeg [00:05:53 CEST] <Kiicki> seems right? I have my exe file in a folder called "FFMPEG standalone" in programfiles [00:06:04 CEST] <furq> it's the path to the dir, not the path to the exe [00:07:04 CEST] <sfan5> i feel like someone should write a program to do this automatically [00:07:07 CEST] <sfan5> it seems to be hard [00:07:33 CEST] <Kiicki> No, I'm just retarded [00:08:47 CEST] <furq> echo "export PATH=$PATH:$(whereis ffmpeg)" >> ~/.bashrc [00:08:51 CEST] <furq> oh wait never mind [00:09:26 CEST] <sfan5> :D [00:11:01 CEST] <Kiicki> Was a joke or something? : p [00:11:04 CEST] <Kiicki> that* [00:13:37 CEST] <durandal_1707> You work for nvidia? [00:14:40 CEST] <Kiicki> yes, I work for nvidia but cannot setup FFMPEG properly [00:17:02 CEST] <Kiicki> Think I'm better of using Handbrake. The only reason why I wanted to try out FFMPEG is that it allows to copy the audio, and not re-encode it if I don't want to change it. Sucks that GUI programs doesn't support this feature. I think I'm just better of re-encoding the audio and let it take some extra time to convert the file. [00:17:53 CEST] <sfan5> if you dont want to touch the command line [00:17:59 CEST] <sfan5> you could use handbrake to convert only the video [00:18:19 CEST] <sfan5> and then use mkvtoolnix-gui to take the audio from the orginal file and the new video to mux it into a fresh .mkv [00:18:37 CEST] <Kiicki> yeah, I have been doing that a few times. Using MKVmerge to pull out the audio from the file and use mkvmerge again to merge the video and the audio together [00:18:53 CEST] <Kiicki> aah, yes. that's what I do. Doesn't fully work as I want it to [00:19:39 CEST] <Kiicki> for example: Converting 10 files at a time. Using mkvmerge to pull out the audio from those 10 files, it just merges everything into 1 MKV file and not 10 different [00:19:56 CEST] <Kiicki> They do have a split feature, but it only works my "time" "chapters" and so on [00:20:01 CEST] <Kiicki> why not just by file? [00:20:10 CEST] <Kiicki> forces me to do one by one [00:21:55 CEST] <Kiicki> if it would be possible to just insert "-c:a copy" into a GUI it would be perfect for me [00:22:05 CEST] <Kiicki> and of course have CRF value [00:22:32 CEST] <durandal_1707> use new bash thing from win 10? [00:23:02 CEST] <sfan5> won't that impact performance? [00:23:51 CEST] <durandal_1707> besides handbrake uses libav [00:24:25 CEST] <furq> can you call windows binaries from win10 bash [00:24:38 CEST] <Kiicki> I just don't understand why there isn't a "-c:a copy" thing on GUI programs. am I the only one that wants to avoid re-encoding something that I don't want to change? [00:25:06 CEST] <durandal_1707> perhaps there is, already asked? [00:25:16 CEST] <sfan5> it can be hard to implement that based on how the program was designed [00:25:23 CEST] <Kiicki> yes, I have tried for several days to find a GUI converter that does that [00:25:28 CEST] <sfan5> that seems to be the case with e.g. mpv [00:25:45 CEST] <Kiicki> I would think that Handbrake should easily fix that since it is based on FFMPEG [00:26:09 CEST] <furq> isn't there an "auto passthrough" option in handbrake [00:26:12 CEST] <durandal_1707> there is qtractor IIRC [00:26:21 CEST] <furq> there definitely is for dvd ripping [00:26:22 CEST] <sfan5> the question is whether handbrake directly uses libav or just passes flags to ffmpeg [00:26:27 CEST] <furq> i've never used it for converting anything else [00:26:30 CEST] <furq> and it uses libav* [00:26:43 CEST] <furq> it actually uses its own lib which wraps libav iirc [00:27:09 CEST] <Kiicki> dude, does auto pass through actually mean the same as "-c:a copy"? [00:27:10 CEST] <furq> it has some filters and stuff which aren't part of libavfilter [00:27:16 CEST] <furq> Kiicki: i believe so [00:27:22 CEST] <Kiicki> omg -.- [00:27:27 CEST] <Kiicki> yes, it does have that [00:27:54 CEST] <furq> yeah it's a dumb name but that should just copy the audio tracks [00:28:28 CEST] <Kiicki> well, thanks! Really. I have been stuck in this subject for weeks. been waiting for 5 days to post on Doom9 and everything [00:28:35 CEST] <Kiicki> and the feature was always there [00:29:29 CEST] <sfan5> it does have passthru for aac, ac3, dts, dts-hd and mp3 [00:29:47 CEST] <Kiicki> yeah, just saw that. I just didn't know that passthru meant that [02:54:48 CEST] <rkantos> anybody got ideas why youtube doesn't want to go live with my ffmpeg stream that has the chroma overlay? [02:55:05 CEST] <rkantos> if I just have an overlay without chroma everything works fine [02:55:12 CEST] <rkantos> so weird [02:59:11 CEST] <rkantos> in ffplay everything works also great with the chroma [02:59:22 CEST] <furq> rkantos: pastebin the ffmpeg output [03:04:05 CEST] <rkantos> furq: currently running with this; the upper works and the lower doesn't (in youtube): ffmpeg -thread_queue_size 512 -r 30 -i rtmp://localhost/video/s4 -thread_queue_size 64 -i rtmp://localhost:1936/data/s4 -vcodec libx264 -pix_fmt yuv420p -preset superfast -b:v 3000k -acodec copy -lavfi "[1:v]colorkey=0x000000:0.5:0.1[ckout],[ckout]scale=400x225[ckout2],[0:v][ckout2]overlay=x=W-w:y=H-h[out]" -map "[out]" [03:04:11 CEST] <rkantos> -c:v mpeg2video -f avi - | ffplay - [03:04:17 CEST] <rkantos> ffs [03:04:28 CEST] <rkantos> http://pastebin.com/M3VV8jqg [03:04:46 CEST] <furq> i said the output [03:05:03 CEST] <furq> although my guess was going to be pix_fmt and you seem to have that covered [03:06:47 CEST] <rkantos> furq: you see this does work fine: http://pastebin.com/8bC8Aif4 [03:06:58 CEST] <rkantos> and again, both work in ffplay [03:07:10 CEST] <rkantos> how should I pastebin the output? :S [03:07:38 CEST] <furq> if your terminal is bad then use -report [03:10:25 CEST] <rkantos> yt just goes starting with the green color for a second, a livestream pops to my channel, but then goes back to starting with grey, which means it's not receiving anything supposedly. [03:20:06 CEST] <rkantos> furq: at least the log is full a whole lot of "Current profile doesn't provide more RBSP data in PPS, skipping [03:20:09 CEST] <rkantos> " [03:20:12 CEST] <rkantos> hmm [03:36:35 CEST] <kernelkatze> hi guys [03:36:39 CEST] <kernelkatze> i need some help [03:37:49 CEST] <kernelkatze> i try to rip a dvd with ffmpeg (legal in my country) but the result is pretty shitty because the video has lots of artifacts etc. i installed all common libs (such as libdvdcss e.g). [03:38:18 CEST] <kernelkatze> cat VTS_09_0.VOB VTS_09_1.VOB VTS_09_2.VOB VTS_09_3.VOB VTS_09_4.VOB VTS_09_5.VOB VTS_09_6.VOB | ffmpeg -i - /home/user/video.mp4 [03:38:23 CEST] <kernelkatze> i used this command [03:39:10 CEST] <kernelkatze> here r just some errors i get [03:39:11 CEST] <kernelkatze> http://pastebin.com/FQj7HDf2 [03:46:34 CEST] <rkantos> is this an issue furq? [swscaler @ 0x162e240] No accelerated colorspace conversion found from yuv420p to argb. [04:03:32 CEST] <rkantos> furq: here's the output https://paste.ee/p/fDeLf [04:04:14 CEST] <rkantos> this is currently working with youtube: https://paste.ee/p/RfBFO [04:52:07 CEST] <Spring> what chroma subsampling does ffmpeg use by default? [04:54:14 CEST] <c_14> That of the input or that which it considers suitably similar to the input that the output codec supports. [05:01:12 CEST] <Spring> thx [05:01:44 CEST] <k_sze[work]> How can I tell ffmpeg to output a blank video frame when a damaged video frame is encountered? Or repeat the last good frame? [05:02:28 CEST] <c_14> don't think the binary has support for that [05:12:45 CEST] <Spring> in vp9 the docs state to use -b:v 0 when wanting to use CRF quality, while someone else here mentioned adding -maxrate is the better way to limit bitrate. When used together though ffmpeg gives an error that no bitrate has been set (since -b:v is '0'). [05:13:16 CEST] <Spring> Should I use -b:v 20M for example or just not use -maxrate at all to set a max bitrate? [05:15:46 CEST] <Spring> so far I've been using the 'constrained quality' which is crf + a b:v max value. Basically wondering if maxrate should be used in some way or not. [05:18:35 CEST] <k_sze[work]> I remember there was an option to generate new timestamps when transcoding. I can't remember what it is. [05:19:38 CEST] <c_14> k_sze[work]: -fflags +genpts [05:21:20 CEST] <k_sze[work]> If I use `-f null` as output format, I still get "[null @ 0x1910520] Encoder did not produce proper pts, making some up." [05:47:05 CEST] <k_sze[work]> hmm, looks like ffmpeg automatically does the "right" thing if I decode ffv1 to rawvideo with damaged frames. [05:48:27 CEST] <k_sze[work]> It will output a weird-looking frame, but at least then my timesync isn't messed up. [06:01:21 CEST] <Kiicki> got a off topic question here: Any recommendation for a free DLNA service that will work on my Smart TV and on Android? Hopefully a DLNA service that can separate movies and TV-series and not put it all under "videos" like Serviio. Plex won't work since it's not free not mobile. also I have had some audio issues with Plex recently. [06:13:57 CEST] <klau> Hi. I have 256 images, named sequentially img031 to img286, and would like to tile them in a 16x16 array using the tile command [06:14:38 CEST] <klau> I tried the following: ffmpeg -i img%03d.jpg -filter_complex tile=16x16 output.jpg [06:14:51 CEST] <klau> however get the following error: [image2 @ 00000000024524a0] Could find no file with path 'img%03d.jpg' and index in the range 0-4 img%03d.jpg: No such file or directory [06:32:50 CEST] <jya> ffmpeg flac decoder is unable to decode a flac live stream? it will error out if extradata is 0 [06:50:45 CEST] <rafael2k> people, it seems mpegts muxer is not working with latm/loas encoded by libfdk_aac [06:50:54 CEST] <rafael2k> it does not set the correct program type [06:53:44 CEST] <c_14> klaxa: use -start_number 31 [06:53:52 CEST] <c_14> eh, sorry wrong highlight [06:53:55 CEST] <c_14> He's already gone [06:54:24 CEST] <c_14> rafael2k: update to a git build/open a bugreport on trac [06:54:36 CEST] <c_14> jya: ditto [06:55:43 CEST] <jya> c_14: you mean to open a bug? I can see that the code doesn't handle it... I was more voicing my surprise than anything else [06:56:04 CEST] <c_14> yes, though in this case it might be a feature request [07:13:15 CEST] <jya> c_14: I can make a quick patch to make it work... [07:13:58 CEST] <c_14> You could try sending it to the ml mentioning the issue and how to reproduce it. [07:14:06 CEST] <c_14> Depends on how much effort you want to put into fixing it. [07:14:14 CEST] <jya> oh actually, it's something else... it wants null as extradata, doesn't check the size like other decoders do [09:11:29 CEST] <k_sze[work]> So how to I make ffmpeg not drop damaged frames when using it as a library? [09:11:48 CEST] <k_sze[work]> The ffmpeg command line does drop damaged frames when I decode as rawvideo. [09:11:56 CEST] <k_sze[work]> s/does/doesn't/ [09:15:07 CEST] <Bray90820> Can someone tell me what this error means? [09:15:08 CEST] <Bray90820> http://pastebin.com/raw/1a83g35J [09:54:20 CEST] <durandal_1707> Bray90820: why you use same file as input and output? [09:54:44 CEST] <durandal_1707> looks like you trashed file [09:55:03 CEST] <Bray90820> durandal_1707: One has the extension mov the other one is mp4 [09:55:08 CEST] <Bray90820> I'm converting it to mp4 [09:55:48 CEST] <durandal_1707> then one file is either incomplete or corrupted [09:58:05 CEST] <Bray90820> Does the input have the correct syntax tho? [09:58:58 CEST] <Bray90820> durandal_1707: [09:59:17 CEST] <durandal_1707> syntax? [09:59:34 CEST] <Bray90820> Is the input correct? [10:01:45 CEST] <Bray90820> durandal_1707: Is the input correct? [10:02:50 CEST] <durandal_1707> no, its missing something, the file [10:03:35 CEST] <Bray90820> What do you mean? [10:04:17 CEST] <durandal_1707> what ffmpeg tells, is the problem [10:05:51 CEST] <Bray90820> Yeah I think the file is corrupt? [10:05:58 CEST] <Bray90820> Sorry no question mark needed [10:06:48 CEST] <ritsuka> does the .mov work in quicktime or another player? [10:09:11 CEST] <Bray90820> It plays in VLC and quicktime and oddly it plays in VLC [10:09:40 CEST] <Bray90820> Sorry I meant Oddly it plays in iTunes [10:09:56 CEST] <Bray90820> Because I thought iTunes was only for mp4 and m4v files [10:10:19 CEST] <durandal_1707> Bray90820: could you upload it? [10:10:55 CEST] <Bray90820> This site has a bunch of them and they all seem to experience the same behavior [10:10:56 CEST] <Bray90820> http://www.markmarek.org/ANIMATIONS/KABLAM.html [10:12:00 CEST] <Spring> no surprise it plays in iTunes, seeing as MOV is an Apple format :) [10:12:49 CEST] <Bray90820> Oh well then I take back my comment about iTunes [10:17:02 CEST] <Bray90820> So any info with the videos [10:17:42 CEST] <durandal_1707> still downloading [10:17:49 CEST] <Bray90820> Alright [10:17:54 CEST] <Bray90820> Take your time [10:21:46 CEST] <durandal_1707> Bray90820: ep01 plays fine even partially downloaded [10:22:08 CEST] <Bray90820> Then why can't it convert? [10:52:24 CEST] <durandal_1707> Bray90820: perhaps you have different file [12:05:54 CEST] <nonex86> hey, guys, still looking someone, who can clarify things on avformat_seek_file and mpeg container [12:15:23 CEST] <JEEB> nonex86: rather use bytewise seeking with such containers [12:30:48 CEST] <hbo> hi [12:31:22 CEST] <hbo> guys im using ffmpeg complied with h264 and libfdkaac for windows [12:31:29 CEST] <hbo> but i need same file for linux [12:31:50 CEST] <hbo> i complied windows file with this https://github.com/rdp/ffmpeg-windows-build-helpers [12:32:05 CEST] <hbo> but i dont know how to do this for linux [12:35:43 CEST] <bp0> ./configure --enable-libfdk-aac [13:15:04 CEST] <cowai> Any one know I can can flip field order without reencoding, only shifting the lines? [13:29:55 CEST] <durandal_1707> cowai: not possible [13:34:24 CEST] <nonex86> JEEB: so for mpg container keyframe seek is broken? because the same codepath works ok on mp4/h264 stream and do exactly what it should - seek to keyframe with 0 flags? [13:35:07 CEST] <cowai> durandal_1707: So I loose quality, not just loosing a line? It cannot be done? [13:38:25 CEST] <furq> nonex86: which codec [13:38:35 CEST] <nonex86> mp2video/audio [13:38:38 CEST] <JEEB> nonex86: you need an idr/irap and parameter sets. and mpeg-ts/ps container has no idea of random access [13:38:55 CEST] <furq> nvm wrong nick [13:38:58 CEST] <furq> cowai: which codec [13:39:39 CEST] <nonex86> JEEB: i am sorry, what is idr/irap? its some kind of exra date in codec context for mp2 video? [13:39:48 CEST] <nonex86> *extradata [13:39:55 CEST] <bencoh> there is no extradata either :D [13:41:10 CEST] <furq> cowai: if it's bff which is marked as tff or something similar then there are tools which can fix that for mpeg2video [13:41:14 CEST] <furq> possibly for other codecs as well [13:42:11 CEST] <nonex86> as a conclusion, for mpeg, to seek on it first i should index the file to find keyframe file offsets and than i can seek to that saved offsets using avformat_seek_file with apropriate flags, right? [13:44:25 CEST] <bencoh> a RAP is basically a position in stream where you can start parsing/decoding without knowledge of previous data [13:44:46 CEST] <nonex86> yes, already understand what it was all about [13:44:47 CEST] <bencoh> it's a more than "just a keyframe" [13:44:51 CEST] <nonex86> idr [13:45:25 CEST] <nonex86> or recover point hint [13:46:13 CEST] <bencoh> IDR is at codec level [13:46:59 CEST] <cowai> furq: mpeg2video, my files are real bff, but the playout doesnt care and plays them as tff. [13:47:13 CEST] <bencoh> oh and, when working with mpegts, a RAP usually implies that you'll receive needed TS stuff as well (PAT/PMT, ...) [13:47:39 CEST] <furq> cowai: http://www.videohelp.com/software/Restream [13:48:07 CEST] <furq> i vaguely remember using that years ago but there are probably other tools which will fix it [13:48:16 CEST] <nonex86> i already parcing mpeg2/h264 streams, but i was confused when i start to use avformat_seek_file [13:48:22 CEST] <nonex86> *parsing [13:48:37 CEST] <nonex86> because it works on mp4 container with h264 [13:48:50 CEST] <nonex86> but broken on mpeg2 video :( [13:49:37 CEST] <cowai> furq: thanks. It doesnt look like it can shift the fields up a line. [13:49:45 CEST] <cowai> or does it? [13:50:08 CEST] <cowai> I basically want to crop the first line, and add 1 black line at the bottom. [13:52:31 CEST] <nonex86> one more question, as far as i understand mpegps & mpegts is two different format, isnt it? but usually both have mpg/mpeg extension? [13:57:23 CEST] <durandal_1707> cowai: crop + pad [13:58:44 CEST] <furq> cowai: you can't do that without reencoding [13:58:50 CEST] <furq> that tool will just mark the stream as tff or bff [13:59:23 CEST] <cowai> furq: Okay, thanks. [13:59:53 CEST] <furq> nonex86: mpegts is normally .ts or .m2ts [14:00:13 CEST] <furq> although i've definitely seen some which were .mpg [14:05:11 CEST] <Mandevil> Hm, can ffmpeg do some video analysis? Like printing average I-frame interval? [14:08:58 CEST] <iive> Mandevil: take a look of ffprobe [14:09:08 CEST] <Mandevil> Oh, just realized that ffprobe is a thing :0 [14:09:16 CEST] <Mandevil> Thanks. [14:12:56 CEST] <nonex86> furq: is it possible to distinguish one from another (ps vs ts) in ffmpeg demuxer? for example by analyzing the content of avformatcontext.iformat.name? [14:15:49 CEST] <nonex86> furq: for mpeg2ps iformat.name is "mpeg" as far as i remember [14:17:05 CEST] <furq> ts will be mpegts [14:17:10 CEST] <furq> at least according to ffmpeg -formats [14:23:59 CEST] <nonex86> ok, thank you [14:38:17 CEST] <Mandevil> my GoPro footage seems to have every other frame an I frame. [14:38:25 CEST] <Mandevil> Ridiculous, isn't it? [14:51:41 CEST] <soulshock> ffmpeg returns exit code 0 if an error occurs when reading from input file. is this expected behavior? makes it hard to detect errors [14:52:22 CEST] <furq> it returns 1 here [14:52:42 CEST] <soulshock> i.e. reading from a network drive and the network goes down. ffmpeg happily returns exit code 0. i'm using the win64 build from zeranoe [14:54:09 CEST] <soulshock> even if you pull the plug on your network cable while transcoding? [14:54:25 CEST] <kdehl> When I decode a H.264 file using OpenH264, I get as output three buffers, (which represent Y, U and V I suppose?). How do I save those buffers into a valid yuv file? [14:58:14 CEST] <kepstin> A 'yuv' file (raw video) is literally just the contents of the Y, U, and V buffers right after each other. [14:58:19 CEST] <kepstin> i guess? [14:58:30 CEST] <bencoh> indeed [14:58:37 CEST] <kdehl> Oh. [14:58:40 CEST] <kdehl> Hm. Okay. [14:59:05 CEST] <kdehl> I just hex dumped the output and compared it to the original file, and they didn't look very similar. [14:59:10 CEST] <kdehl> But maybe they are similar enough. [14:59:25 CEST] <BtbN> set the output pix_fmt to something interleaved if you want that. [14:59:27 CEST] <furq> well yeah one of them has been decoded [14:59:43 CEST] <kepstin> h264 is a lossy codec, of course it'll be different from the source. Hard to tell how similar/different by looking at hex [14:59:49 CEST] <kdehl> Yeah, I didn't expect it to be identical. [15:00:06 CEST] <kdehl> But I thought it would look more similar than they do. [15:00:21 CEST] <bencoh> there is absolutely no reason why they'd be even remotely similar :) [15:00:26 CEST] <kdehl> I'm glad to be wrong though, because this turned out to be simple. :) [15:00:37 CEST] <kepstin> you could use ffmpeg to convert them both to png or something if you want to compare them by eye [15:00:50 CEST] <kdehl> Oh. [15:01:24 CEST] <kdehl> I'm going to do some experimenting. [15:02:12 CEST] <kdehl> But one frame at a time, and Y, U and V frames in that order? [15:02:30 CEST] <kdehl> If I mix up U and V I would just get funny colors, no? [15:02:48 CEST] <bencoh> depends on the format, but yuv420p is usually in that order, yeah [15:03:03 CEST] <kdehl> It's yuv420p. [15:03:04 CEST] <kdehl> Great! [15:03:09 CEST] <kdehl> Thanks. :) [15:03:33 CEST] <kepstin> annoyingly, 'yv12' is basically the same as yuv420p, except that the u and v are switched :/ [15:03:36 CEST] <kdehl> :noh [15:03:39 CEST] <kdehl> Um. Oops. [15:08:33 CEST] <bencoh> :) [15:13:30 CEST] <kdehl> Hey, another question, can I ask the codec to tell me the width and height of the parsed video? [15:23:08 CEST] <kdehl> Ah. Found it. [15:23:49 CEST] <kdehl> SBufferInfo.UsrData.sSystemBuffer.iWidth [15:26:55 CEST] <BtbN> I'm quite sure that's not coming from ffmpeg. [15:27:30 CEST] <kdehl> No, OpenH264. [15:29:51 CEST] <bencoh> does openh264 implement more than baseline nowadays? [15:30:22 CEST] <bencoh> looks like it doesn't [16:58:54 CEST] <deweydb> I needed ffmpeg from source so i could have --enable-libfreetype, so I followed this guide: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu This guide seems to place FFMPEG into the user directory and the binarys into ~/bin. [16:59:30 CEST] <deweydb> I am also working with python av module, which wants to use libswresample and libavresample [16:59:40 CEST] <deweydb> (parts of ffmpeg) [17:00:13 CEST] <deweydb> but the python av module installer is failing because of my user directory installed version of ffmpeg. i.e. its not finding the libavresample and libavresample libraries. [17:00:20 CEST] <deweydb> how can i fix this? symlink? [17:06:39 CEST] <kdehl> Okay, um, an embarrassing question, how much bigger is the Y part compared to the U and V parts of yuv420? [17:07:07 CEST] <kdehl> Four? [17:07:16 CEST] <iive> y is 8 bits, u is 2 and v is 2, so they make 12bits [17:07:53 CEST] <kdehl> Ah, thanks. [17:08:15 CEST] <kdehl> No wonder this segfaults. I just assumed they'd be the same. [17:08:17 CEST] <iive> to be exact, y is full resolution, u is 1/2*1/2 smaller and so is v. [17:08:25 CEST] <kdehl> Right. [17:09:41 CEST] <iive> deweydb: if you have root, you can just install it in --prefix=/usr [17:09:59 CEST] <deweydb> k thanks [17:10:25 CEST] <iive> btw, i doesn't ubuntu come with ffmpeg package? [17:10:39 CEST] <deweydb> I needed ffmpeg from source so i could have --enable-libfreetype [17:12:51 CEST] <iive> freetype is not part of ubuntu package? [17:53:17 CEST] <rkantos> durandal_1707: would you have clues why youtube doesn't want to start a livestream with the stream that has the chroma key added to the overlay? [17:53:30 CEST] <rkantos> while it works with ffplay and without the chroma key in youtube [17:53:45 CEST] <BtbN> Is it running fast enough? [17:57:19 CEST] <durandal_1707> rkantos: whats output format? [18:36:29 CEST] <rkantos> BtbN: I thought that too, but I ran it on my own VM and it should be running fast enough [18:36:33 CEST] <rkantos> own computer VM I mean [18:36:41 CEST] <rkantos> otherwise I'm running it on a VPS [18:37:02 CEST] <BtbN> The chromekey filter is not exactly optimised, it eats a lot of CPU power. And if you don't filter and encode in realtime, YouTube might reject the stream. [18:39:31 CEST] <rkantos> durandal_1707: what do you mean? I'm using libx264 [18:40:18 CEST] <rkantos> libx264 + flv [18:41:05 CEST] <rkantos> is there a difference between colorkey and chromekey? [18:41:09 CEST] <rkantos> I meant colorkey [18:41:28 CEST] <rkantos> here's the feed that Youtube indeed seems to reject, as it first says it is starting, and then just stops: https://paste.ee/p/fDeLf [18:41:29 CEST] <BtbN> one operates on RGB colors, and is ment for exact color matching. [18:41:51 CEST] <BtbN> chromakey is YUV, and more fuzzy, for greenscreens and stuff. It's lacking spill-reduction though. [18:41:52 CEST] <rkantos> and the one working is here: https://paste.ee/p/RfBFO [18:42:08 CEST] <rkantos> Ok, I'm using colorkey [18:42:27 CEST] <rkantos> I think it is enough since I'm feeding a screen capture that I just want to remove all the black from [18:42:57 CEST] <rkantos> but yeah, imo it works fine with ffplay [18:43:45 CEST] <BtbN> that's what it's intended for, yes. [18:44:40 CEST] <durandal_1707> rkantos: make sure you use baseline profile [18:46:35 CEST] <bencoh> so you always need to go through colorspace conversion? :/ [18:46:56 CEST] <bencoh> that sounds silly ... [18:48:05 CEST] <BtbN> screen capture is RGB, colorkey uses RGB. Seems fine to me. [18:48:34 CEST] <bencoh> in that case, true [18:48:47 CEST] <durandal_1707> why is there no Luma key? [18:50:26 CEST] <BtbN> because nobody wrote a luma key filter. [18:51:01 CEST] <durandal_1707> why oh why I'm so sad! [18:51:20 CEST] <BtbN> what even is luma key? [18:52:04 CEST] <BtbN> Analyzing only the Y component of YUV? [18:52:33 CEST] <durandal_1707> how would you key black in yuv colorspace? [19:01:16 CEST] <durandal_1707> luma key just use single component for setting alpha [19:15:04 CEST] <rkantos> durandal_1707: how do I set it for the output? nothing is changed in output settings between the non-colorkeying and colorkeying though [19:16:48 CEST] <durandal_1707> rkantos: try adding -pixfmt yuv420p after filters [19:35:05 CEST] <rkantos> durandal_1707: what does that determine? [19:36:26 CEST] <bencoh> force output colorspace [19:44:05 CEST] <flydev> Please advise on [lrc @ 0x3319580] Format lrc detected only with low score of 5, misdetection possible! http://pastebin.com/XWeHax1w [19:50:03 CEST] <BtbN> whatever livestreamer is outputting, it's not something ffmpeg can make any usefull guess on what it is. [19:53:51 CEST] <flydev> it is h264 http://store.picbg.net/pubpic/52/37/1c02619c39c05237.PNG [19:54:01 CEST] <BtbN> raw h264? [19:54:24 CEST] <flydev> not sure, it plays fine in VLC [19:54:37 CEST] <BtbN> Did you try not giving the input codec? [19:55:02 CEST] <flydev> yes, it's way slower this way and same error [19:55:30 CEST] <BtbN> Well, livestreamer is messing something up then. You can try giving ffmpeg the correct container format via -f [19:55:57 CEST] <flydev> ffmpeg -vcodec h264 -f -re ..... [19:56:06 CEST] <flydev> or somewhere else? [19:56:47 CEST] <BtbN> don't specify the input codec, that's pointless. [19:57:00 CEST] <BtbN> And you'll have to give the correct container for -f [19:57:54 CEST] <flydev> please give me an example where to use -f besides output in this case [19:58:04 CEST] <BtbN> -f something [19:58:11 CEST] <BtbN> where something is the container you are feeding it. [19:59:19 CEST] <flydev> H.264 bitstream malformed, no startcode found, use the video bitstream filter 'h264_mp4toannexb' to fix it ('-bsf:v h264_mp4toannexb' option with ffmpeg) [20:01:26 CEST] <BtbN> What container is it even? [20:01:31 CEST] <BtbN> I'd guess it's mpegts? [20:03:08 CEST] <flydev> Stream #0:0: Video: h264 (High), yuv420p, 896x504 [SAR 1:1 DAR 16:9], 1744 kb/s, 25 fps, 25 tbr, 1k tbn, 50 tbc [20:03:52 CEST] <BtbN> That's not the container. [20:03:57 CEST] <BtbN> That's the video codec. [20:04:35 CEST] <flydev> Input #0, flv, from 'http://127.0.0.1:33912/': this? [20:05:17 CEST] <flydev> and give me example how to force this container in the commandline for piped output, please :) [20:05:35 CEST] <BtbN> well, just -f flv [20:05:51 CEST] <BtbN> But as that output is coming from ffmpeg, it must have already detected that. [20:06:29 CEST] <BtbN> What ffmpeg version are you using? It shouldn't prompt to manually add the bsf anymore. [20:12:09 CEST] <flydev> one of the last builds from github [20:12:50 CEST] <flydev> but where to put -f flv for INPUT? I got one for the output [20:12:58 CEST] <flydev> ffmpeg -analyzeduration 5000000 -probesize 5047480 -i http://127.0.0.1:33912/ -bsf:v h264_mp4toannexb -c:v copy -c:a copy -f mpegts "udp://127.0.0.1@239.4.4.4:44004" [20:13:06 CEST] <flydev> please suggest where to put the -f flv for input [20:14:29 CEST] <BtbN> anywhere before your -i [20:14:56 CEST] <BtbN> But ffmpeg should easily be able to auto-detect flv, and judging from your output, it did. [20:15:25 CEST] <lonley> hi all, did some one work with vp8? ( i maked a video with alpha, works in chrome, and now i need to extract it in my app, unfortunatly all images i get have no alpha, can some one help?) command i use to retrive images is ffmpeg64.exe -i output.webm -pix_fmt argb "0/img%d.png" [20:16:44 CEST] <flydev> yeah, only for external port output.... not working for piped output :( [20:17:08 CEST] <BtbN> livestreamer is doing something strange then. [20:17:51 CEST] <lonley> any formats that support alpha in video? (webm makes 297 kb file, i tryed some and got 80mb) [20:19:23 CEST] <flydev> yeah probably, it's scripting time :( i wanted to get this easily in ffmpeg and make it available anytime I need it via multicast.... but it won't be the easy way [20:20:11 CEST] <lonley> got smallest size 20mb with -vcodec qtrle [20:20:29 CEST] <lonley> but 20mb vs 300 kb [20:20:55 CEST] <BtbN> are you sure using your pipe method doesn't just write the console text from livestreamer to ffmpeg? [20:21:12 CEST] <BtbN> From how i know livestreamer, it starts the player-process it pipes to itself. [20:36:13 CEST] <flydev> Frankly I'm not sure about that [20:46:09 CEST] <Bray90820> durandal_1707: You around? [20:46:47 CEST] <durandal_1707> Bray90820: yes [20:46:57 CEST] <Bray90820> You said I might have a different file? [20:47:07 CEST] <durandal_1707> yes [20:47:50 CEST] <durandal_1707> I never got link to same file [20:47:51 CEST] <Bray90820> Should I upload one of the files that's experiencing this issue to dropbox or something so you can see it? [20:47:58 CEST] <Bray90820> Oh [20:48:01 CEST] <durandal_1707> yes [20:48:04 CEST] <Bray90820> Ok [20:48:28 CEST] <Bray90820> But note the link I sent you was the place I got the files from [20:49:20 CEST] <durandal_1707> Yes, but multiple seasons [20:50:00 CEST] <durandal_1707> I see on that page just bunch of episodes, in flash [20:50:28 CEST] <Bray90820> Ok [20:52:26 CEST] <Bray90820> That episode is there I just reorganized it after I downloaded it but i am uploading it [20:53:10 CEST] <durandal_1707> Bray90820: have you tried redownloading? [21:02:50 CEST] <Bray90820> Tried redownloading it got same error and it seems to do the same thing with every file I downloaded from that site [21:02:59 CEST] <Bray90820> Here is a link to the file https://dl.dropboxusercontent.com/u/33402675/06%20-%20Going%20the%20Extra%2… [21:03:31 CEST] <Bray90820> But if you're wondering it's episode number 46 on that site [21:03:35 CEST] <Bray90820> durandal_1707: [21:40:46 CEST] <durandal_1707> Bray90820: I just downloaded 46 episode and it plays fine [21:41:10 CEST] <Bray90820> durandal_1707: I'm asking why doesn't it convert to mp4 [21:42:19 CEST] <durandal_1707> perhaps because of faulty disk, dunno it can't decode it [21:43:21 CEST] <Bray90820> You mean I have a bad hard drive? [21:43:34 CEST] <durandal_1707> Bray90820: what's size of that file? [21:43:52 CEST] <durandal_1707> on your disk [21:44:08 CEST] <Bray90820> 274mb [21:53:22 CEST] <durandal_1707> Bray90820: I'm out of ideas, did you tried redownloading file? [21:53:54 CEST] <durandal_1707> It should not write about missing moov atom [21:54:22 CEST] <Bray90820> I did try redownloading it same issue same issue [21:56:51 CEST] <vdv> hello [21:58:38 CEST] <vdv> is it possible to rotate video, but preserve all metadata otherwise? (I used -vf "transpose=1" to rotate) [22:28:46 CEST] <durandal_1707> Bray90820: what ffmpeg version you use? [22:28:56 CEST] <Bray90820> How would I check that? [22:32:49 CEST] <durandal_1707> Bray90820: paste again new ffmpeg output? [22:34:26 CEST] <Bray90820> It's version 3.0.2 [22:34:27 CEST] <Bray90820> http://pastebin.com/raw/Az3Jz0Bt [22:44:51 CEST] <c_14> >[libx264 @ 0x7fd99b022a00] height not divisible by 2 (500x375) [22:45:30 CEST] <c_14> either copy the video, use a pixel format that doesn't require an even height, or scale so the height is even [22:53:17 CEST] <Bray90820> c_14: How would I scale it? [22:54:20 CEST] <c_14> -vf scale=iw:-2 [22:54:35 CEST] <Bray90820> Thanks [22:58:02 CEST] <Bray90820> It's converting now Thanks [23:03:19 CEST] <snorlax> hello, anyone here has any experience with using the av* libraries in a c# application? [23:10:27 CEST] <durandal_1707> Bray90820: you don't want to reencode video use -c:v copy [23:10:42 CEST] <Bray90820> durandal_1707: Why not? [23:11:34 CEST] <durandal_1707> You loose quality [23:11:58 CEST] <durandal_1707> unless you need specific codec [23:13:35 CEST] <Bray90820> durandal_1707: I literally can't tell a difference unless I put them side by side and pause them at the exact same frame [23:13:50 CEST] <Bray90820> And the mp4 takes a lot less space [23:14:08 CEST] <Bray90820> My video collection went from like 2.5TB to like 900GB [23:14:14 CEST] <durandal_1707> whatever, mp4 is container [23:15:08 CEST] <durandal_1707> transcode again and it willl go from 900gb to 10mb and be shit [23:18:44 CEST] <Bray90820> I don't plan on transcoding again [23:24:54 CEST] <CoJaBo> Bray90820: Shoulda gone with HEVC [23:25:13 CEST] <Bray90820> HEVC? [23:26:06 CEST] <CoJaBo> The latest codec; it's like a quarter or less of the bitrate of h.264, for the same quality [23:26:07 CEST] <Bray90820> You mean h.265 [23:26:23 CEST] <CoJaBo> Yeh, I always see it written as HEVC [23:26:42 CEST] <Bray90820> Ehh [23:26:46 CEST] <CoJaBo> The raspberry pi doesn't support it tho, at least not yet :/ [23:27:12 CEST] <Bray90820> What I have I can't tell a difference and a lot more devices support h.264 [23:28:27 CEST] <Bray90820> 794GB [23:28:39 CEST] <Bray90820> That's a lot better than 2500 [23:38:38 CEST] <CoJaBo> what was it encoded in before? [23:39:29 CEST] <kepstin> according to the command output, h264 [23:40:13 CEST] Action: kepstin might not be looking at the right output tho [23:40:48 CEST] <klaxa> half the bitrate, same quality, 50 times longer encode? [23:41:09 CEST] <klaxa> well to be fair, it's not *that* slow [23:41:46 CEST] <durandal_1707> audio was pcm [23:43:39 CEST] <viric> a quarter or less? is it really so good? [23:43:49 CEST] <viric> h265. [23:44:14 CEST] <klaxa> 50% is quoted all over the place at least [23:44:32 CEST] <furq> it is that slow compared to x264 medium [23:44:32 CEST] <klaxa> haven't read anyone claiming 25% [23:44:36 CEST] <furq> which is probably what he's using [23:44:41 CEST] <viric> does it encode much slower than h264? [23:44:46 CEST] <furq> yes [23:44:47 CEST] <klaxa> much much slower [23:44:51 CEST] <furq> >10x slower than x264 veryslow [23:44:56 CEST] <viric> ouch [23:45:13 CEST] <klaxa> it is to be expected [23:45:17 CEST] <furq> that's for x265 veryslow [23:45:24 CEST] <viric> ah ok [23:45:25 CEST] <furq> but it's not worth using x265 at anything faster than medium [23:45:40 CEST] <furq> it actually performed worse than x264 at the same encode speed last time i checked [23:46:04 CEST] <viric> very useful information [23:46:29 CEST] <furq> x265 medium is supposedly roughly on a par with x264 veryslow [23:46:41 CEST] <furq> except obviously less compatible [23:46:46 CEST] <klaxa> well, quality, bitrate and codec complexity are not related in a linear way [23:46:50 CEST] <c_14> and harder t odecode [23:47:22 CEST] <furq> plus people are often using it for 4k content [23:47:36 CEST] <furq> you can imagine how slow that'll be at decent settings [23:47:37 CEST] <viric> and they encode one frame a day? [23:47:40 CEST] <klaxa> dvbt-2 will use h265 too afaik [23:48:09 CEST] <viric> there aren't veryslow hardware encoders even for h264, are they? [23:48:14 CEST] <kepstin> iirc, some of the main improvements in h265 mostly help at higher resolutions, 4k in particular (bigger blocksizes and such) [23:48:32 CEST] <furq> viric: none of the consumer avc encoders are even as good as x264 faster [23:48:41 CEST] <viric> right [23:50:43 CEST] <Bray90820> CoJaBo: it was encoded in MKV [23:50:53 CEST] <Bray90820> That might have just been the container go [23:51:04 CEST] <Bray90820> *Tho [23:51:09 CEST] <Bray90820> Most of them were MKV [23:51:15 CEST] <klaxa> it, is, you can put almost anything in mkv [23:51:23 CEST] <klaxa> lol that comma [23:53:37 CEST] <viric> now I feel bad for encoding h264 at preset medium. [23:53:52 CEST] <viric> maybe veryslow would be worth it. [23:54:03 CEST] <viric> I'll test tomorrow. [23:57:50 CEST] <CoJaBo> Bray90820: MKV is actually a newer container than MP4.. [23:58:25 CEST] <Bray90820> Ehh like I said I like what I have and a lot more devices support it [23:59:04 CEST] <CoJaBo> Bray90820: Most MKVs I've seen tend to be x264 encoded even too; so I'm not sure how you got that drop in size without losing quality lol, you went from x264 to x264.. [23:59:30 CEST] <kepstin> well, from some h264 encode to h264 encoded with x264 [23:59:37 CEST] <durandal_1707> he compressed pcm to aac iirc [23:59:44 CEST] <Bray90820> CoJaBo: I did loose a slight bit of quality but it's really hard to tell [23:59:45 CEST] <kepstin> tho if the original was mkv, it was *probably* also done with x264 :) [00:00:00 CEST] --- Wed Aug 17 2016

1 0