Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2016

1 participants
62 discussions

ffmpeg-devel.log.20160805
by burek 06 Aug '16

06 Aug '16

[08:20:10 CEST] <bp0> how is AV_OPT_FLAG_EXPORT expected to be used? [09:12:32 CEST] <kd_ff_dev> Hello! I had a question about adding a new filter to libavfilter. I am planning to compile the entire ffmpeg library. Based on http://ffmpeg.gusari.org/viewtopic.php?f=25&t=1437, I created the vf_newfilter.c file, registered the filter by adding a line in the allfilters.c file. However, ./configure and make do not seem to recognize the new filter .. and does not compile it. Is it necessary to explicitly add a line to the Makefi [09:17:41 CEST] <kd_ff_dev> *mentioned in the link? (I had hoped not, as eventually, I am aiming to submit the filter ) [09:17:43 CEST] <bp0> yes [09:18:52 CEST] <bp0> in libavfilter/Makefile [09:19:05 CEST] <kd_ff_dev> ohh okay. [09:20:03 CEST] <kd_ff_dev> thanks! I was planning to insert a line in the main Makefile.. but didnt see any other filters explicitly mentioned, so got confused [09:20:14 CEST] <bp0> here is the commit that added the hdcd filter, for reference: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=0cfe16437fce4c2090d395… [09:20:26 CEST] <bp0> so something like that [09:20:59 CEST] <bp0> it does actually mention that first in the forum post you linked [09:21:48 CEST] <kd_ff_dev> ohh yes. Apologies [12:01:38 CEST] <cone-954> ffmpeg 03Shivraj Patil 07master:6803a298f433: Support for MIPS cpu P6600 [12:20:34 CEST] <cone-954> ffmpeg 03Paul B Mahol 07master:04a8bbca9289: avfilter/avf_showspectrum: add color rotation feature [13:51:26 CEST] Action: kwizart tries to follow up to the current state of enabling nvenc for distribution (RPM Fusion for Fedora) [16:22:08 CEST] <cone-954> ffmpeg 03Andreas Cadhalpun 07master:a16018461b2f: lavf: forward protocol_whitelist for the remaining cases [19:34:09 CEST] <cone-954> ffmpeg 03Michael Niedermayer 07master:be7150d49748: avformat/teeproto: set forgotten url_close() [21:06:34 CEST] <cone-954> ffmpeg 03Matthias Hunstock 07master:8431a6e654e5: decklink: fix: set fps on video stream v2 [21:49:07 CEST] <cone-954> ffmpeg 03Matthias Hunstock 07master:d8ee02a071e8: decklink: enhancement: format selection with AVRational v2 [22:27:17 CEST] <cone-954> ffmpeg 03Carl Eugen Hoyos 07master:82e53b3cef92: lavc/vaapi_encode_h26x: Fix a crash if "." is not the decimal separator. [22:27:35 CEST] <jkqxz> Is there anything funny I should know about pushing to release branches? [22:31:57 CEST] <jamrial> jkqxz: bug fixes and documentation only. no new API, features or components [22:32:01 CEST] <jamrial> that's about it, i think [22:35:51 CEST] <jkqxz> I was more meaning the git part. I see "cherry picked from commit xxx" notes on most commits, for example? [22:36:38 CEST] <jamrial> ah [22:37:05 CEST] <jamrial> that's automatically added by using -x with git cherry-pick [22:38:07 CEST] <jamrial> i don't think it's enforced but it certainly is encouraged [22:38:17 CEST] <jkqxz> Aha, that helps. Is there anything else like that that I should know? [22:49:38 CEST] <jamrial> i don't think so [22:58:30 CEST] <jkqxz> Ok. Thank you :) [23:00:16 CEST] <cone-954> ffmpeg 03Carl Eugen Hoyos 07release/3.1:c70b1ae93023: lavc/vaapi_encode_h26x: Fix a crash if "." is not the decimal separator. [23:01:11 CEST] <jkqxz> Oh, overtaken. That works too. [23:16:44 CEST] <cone-954> ffmpeg 03Steven Robertson 07release/3.1:5222f660d7fb: libavcodec/dnxhd: Enable 12-bit DNxHR support. [23:16:45 CEST] <cone-954> ffmpeg 03Paul B Mahol 07release/3.1:46732e6a55a4: avcodec/alacenc: allocate bigger packets (cherry picked from commit 82b84c71b009884c8d041361027718b19922c76d) [23:17:18 CEST] <bp0> speaking of small bug fixes for old versions, can this be applied in 3.1, 3.1.1? http://ffmpeg.org/pipermail/ffmpeg-devel/2016-July/196268.html [23:17:59 CEST] <bp0> commit message has type bing should be being :/ [23:18:03 CEST] <bp0> typo* [23:18:15 CEST] <bp0> comment about typo has a typo [23:31:17 CEST] <jamrial> bp0: that doesn't seem to have been commited to master yet [23:35:04 CEST] <bp0> jamrial, yeah, it was included in a later patch that added features, so perhaps wouldn't be appropriate to apply as a bugfix [23:35:13 CEST] <bp0> but that version is the simplest version of the fix [23:43:15 CEST] <nevcairiel> then send it to the ML with an appropriate message that its for 3.1 [23:43:31 CEST] <nevcairiel> and explanation :) [23:46:11 CEST] <jamrial> or reply/ping the patch you already sent and do the same [23:46:31 CEST] <bp0> I did send a message to the ML about it, in response to michael's notice regarding 3.1.2, will that be good enough? [23:46:44 CEST] <bp0> with a link referencing the patch [00:00:00 CEST] --- Sat Aug 6 2016

1 0

ffmpeg.log.20160805
by burek 06 Aug '16

06 Aug '16

[04:40:13 CEST] <leea> I increased the volume of a video by 40x. Now I have some annoying noise fragments that also got amplified. Is it possible to get rid of those some how? [04:40:34 CEST] <leea> I'm not sure what the right terms to search are but using some limiter and setting a floor? [07:43:59 CEST] <Kd_user> Hello! I am planning to modify vf_convolution.c to support strided convolutions. I wanted to know how can I add new options to the convolution filter? (i.e. after -vf, I wish to add option like x_stride, y_stride) [07:44:39 CEST] <Kd_user> I was confused about how to assign these to the Silter Context struct [07:46:01 CEST] <bp0> Kd_user, https://www.ffmpeg.org/doxygen/2.0/group__avoptions.html [07:46:28 CEST] <bp0> no, wait... https://www.ffmpeg.org/doxygen/trunk/group__avoptions.html [07:47:25 CEST] <bp0> see "Implementing AVOptions" [07:48:06 CEST] <Kd_user> @bp0 Thanks for the reply. This was very helpful :) [07:48:25 CEST] <bp0> np [08:23:14 CEST] <Mandevil> Hm, ffmpeg -h type=<codec> fails with "Unknown help option 'type'." [08:23:23 CEST] <Mandevil> But this exact syntax is in the help... [08:23:25 CEST] <Mandevil> What gives? [08:26:35 CEST] <Mandevil> Oh, it's suposed to be encoder,decoder,... [08:32:28 CEST] <Mandevil> Hm, can I conver colorspaces with ffmpeg? [08:32:31 CEST] <Mandevil> convert [08:34:38 CEST] <furq> Mandevil: https://ffmpeg.org/ffmpeg-filters.html#format-1 and/or https://ffmpeg.org/ffmpeg-filters.html#colorspace [08:34:47 CEST] <furq> or you can do both with zscale if you have it [08:34:47 CEST] <Mandevil> I found -pix_fmt [08:34:55 CEST] <furq> -pix_fmt is just an alias for -vf format [08:35:59 CEST] <Mandevil> Looks fairly involved. [08:36:19 CEST] <furq> what do you actually want to do [08:37:02 CEST] <Mandevil> I want to get dnxhd encoded video for testing purposes. [08:37:09 CEST] <Mandevil> But my source is incompatible. [08:37:14 CEST] <Mandevil> But I'll just get better source. [08:37:59 CEST] <furq> -vf format=yuv422p [08:38:03 CEST] <furq> looks like it should work [08:38:28 CEST] <Mandevil> Hm, 5DmkII file is not compatible with dnxhd either. [08:38:30 CEST] <Mandevil> WTF. [08:39:04 CEST] <Mandevil> BTW, colorspace is yuvj420p... what's that 'j' in the colorspace name? [08:40:07 CEST] <furq> jpeg [08:40:27 CEST] <furq> apparently you need to set the bitrate to one of the approved bitrates [08:40:27 CEST] <Mandevil> Uh? [08:40:45 CEST] <Mandevil> Why does 5DmkII footage has this colorspace? [08:41:12 CEST] <furq> mjpeg? [08:41:43 CEST] <Mandevil> furq: No, it's AVC. [08:41:54 CEST] <Mandevil> furq: And yes, setting the bitrate makes it work fine. [08:42:42 CEST] <furq> maybe it's using mjpeg internally and converting that to avc [08:43:29 CEST] <Mandevil> That would be odd. Doesn't it just denote full range instead of 16-235? [08:43:50 CEST] <furq> that makes more sense [08:44:01 CEST] <furq> i guess it just saves a colourspace conversion on the hardware encoder [08:45:48 CEST] <Mandevil> Yeah, that indeed makes sense. Video on 5d is fairly quirky, it's clearly an afterthought. [08:46:21 CEST] <Mandevil> VLC uses ffmpeg for en/decoding? [09:00:33 CEST] <Mandevil> ffms2 reads dnxhd video just fine it seems. Cool. [09:04:27 CEST] <Kd_user> Hello! I had a question about adding a new filter to libavfilter. I am planning to compile the entire ffmpeg library. Based on http://ffmpeg.gusari.org/viewtopic.php?f=25&t=1437, I created the vf_newfilter.c file, registered the filter by adding a line in the allfilters.c file. [09:04:53 CEST] <Kd_user> However, ./configure and make do not seem to recognize the new filter .. and dont compile it [09:05:36 CEST] <Kd_user> Is it necessary to explicitly add a line to the Makefile as mentioned in the link? (I had hoped not, as eventually, I am aiming to submit the filter ) [09:21:45 CEST] <Mandevil> "No such filter: 'in_range' Error opening filters!" [09:21:47 CEST] <Mandevil> Uh what? [09:22:08 CEST] <Mandevil> I use this ... -vf "in_range=full:out_range=mpeg" [09:27:34 CEST] <Mandevil> OK, it must be -vf "scale=in_range=full:out_range=mpeg" [10:28:58 CEST] <Guest24440> Hello guys! One quick question, I'm not quite sure does ffmpeg 3.1 have support for H265 (Intel HW acceleration)? [10:41:52 CEST] <jkqxz> Guest24440: Yes. It's usable via qsv/libmfx on Windows and via vaapi on Linux. [10:48:31 CEST] <Mandevil> Wonder how do I know what does -profile accept? [10:49:45 CEST] <vadim27> Hi! I'm trying to use ffmpeg 3.1 API for encoding/decoding webcam video with h264 codec. Where i can find some examples of encoding/decoding code? I have some problems with creating of AVCodecContext. For some reasons i must fill fields of AVCodecContexts manually. I need examples. Thanks! [10:58:07 CEST] <Soelen> hello everyone, want to create a video based on a sequence of png images [10:58:59 CEST] <Soelen> they start at 0257.png and end at 2000.png, when I use the command with the parameters "ffmpeg -f image2 -i %04d.png -start_number 0257 video.webm" [10:59:40 CEST] <Soelen> I get "Could find no file with path '%04d.png' and index in the range 0-4, %04d.png: No such file or directory", though I am in the right directory. Any ideas what I am doing wrong? : P [11:02:01 CEST] <jkqxz> Soelen: Put "-start_number 257" before the "-i". [11:04:45 CEST] <Soelen> jkqxz: oh yeah that was the trick, thank you! [12:50:11 CEST] <mrjoker> what is the difference between choosing "main" as profile and "none" as profile [13:01:06 CEST] <furq> mrjoker: the profile is normally automatically selected based on the other encoder parameters [13:01:39 CEST] <mrjoker> i don't understand [13:01:53 CEST] <mrjoker> i see "main" and "none" for x265 [13:02:02 CEST] <furq> oh, x265 [13:03:31 CEST] <furq> apparently none allows you to generate noncompliant streams [13:03:46 CEST] <furq> http://x265.readthedocs.io/en/default/cli.html#cmdoption--allow-non-conform… [13:04:50 CEST] <mrjoker> is that a good thing or bad thing [13:05:00 CEST] <furq> "Compliant HEVC decoders may refuse to decode such streams." [13:05:01 CEST] <furq> you tell me [13:05:50 CEST] <mrjoker> no idea [13:59:28 CEST] <soulshock> does ffmpeg on windows detect hyper-threading cores as real cores or hyper-threaing cores? [14:05:06 CEST] <BtbN> There is no distinction between HT and real cores for applications. [14:27:36 CEST] <soulshock> ok [14:28:28 CEST] <soulshock> I'm thinking the automatic calculation of number of threads (cores * 1,5) would be wrong with hyper threading [14:29:34 CEST] <BtbN> no, why would it? [14:30:04 CEST] <BtbN> The point of HT is to use all of the virtual cores, so the CPU can fill its pipelines more efficiently. [14:30:05 CEST] <DHE> why not give each thread something to do? an idle thread is wasted capacity [14:30:24 CEST] <DHE> and modern intel CPUs are actually quite good at hyperthreading [14:31:26 CEST] <soulshock> my thought was that the virtual cores have very little power compared to real cores. so calculating each virtual core as a real core would create too big a thread count [14:31:36 CEST] <soulshock> since each virtual core cannot give 100% same calculation power as real cores [14:32:14 CEST] <DHE> no. more like a core has a large amount of hardware available (cache, FPU, integer unit) but doesn't really use all of them simultaneously. so hyperthreading lets 2 threads use the same hardware and take advantage as they go [14:32:36 CEST] <DHE> 1 thread might stall for a few cycles because of complex FPU work, but the other thread can use the integer unit and work with pre-cached data [14:33:00 CEST] <DHE> sure, they butt heads from time to time, but +50% performance overall is a win [14:33:20 CEST] <soulshock> yeah I'm going to do some benchmarking with HT on and off [14:33:33 CEST] <soulshock> but I wanted to understand a bit better first, hence my question. cheers [14:34:21 CEST] <DHE> if you're not running a lot of threads anyway, HT off can be of benefit since it prevents accidental sharing of a core while leaving other cores completely idle. if you're actually running the CPU hard, hyperthreading will win [14:35:06 CEST] <DHE> there is a bad situation that can arise with cache sharing, but ffmpeg shouldn [14:35:21 CEST] <DHE> shouldn't have a problem if it's 1 instance [14:36:06 CEST] <soulshock> it's 1 instance with 3-9 result files simultaneously. different resolutions and bitrates [14:46:51 CEST] <furq> SouLShocK: i take it you mean actually disabling HT rather than running -threads 4 [14:47:11 CEST] <furq> since the latter probably won't use four hardware cores [14:50:31 CEST] <SouLShocK> furq yes [15:38:00 CEST] <Kadigan_KSB> Hi. I'm in a bit of a bind, and Google is not helping me much. I need to convert 1080p 4:2:0 material to XDCAM HD 50Mbps 4:2:2 50i TFF in a MOV container. Tips? [15:41:41 CEST] <kepstin> huh, according to the table on wikipedia, XDCAM MPEG HD422 in mp4/mov isn't a valid combination [15:42:13 CEST] <SouLShocK> hm that's interesting [15:42:21 CEST] <SouLShocK> we use XDCAM MPEG HD422 in MOV all the time [15:42:22 CEST] <kepstin> ffmpeg should be able to let you do that anyways if you want [15:42:24 CEST] <SouLShocK> have been for years [15:43:38 CEST] <SouLShocK> Kadigan_KSB: take a look at https://github.com/bcoudurier/FFmbc perhaps that can do what you want [15:43:48 CEST] <SouLShocK> under features: Create XDCAM HD422 files in .mov or .mxf [15:43:59 CEST] <kepstin> but yeah, it's just mpeg2 video in an mp4/mov container, nothing really exotic [15:45:13 CEST] <kepstin> hardest part is probably gonna be deciding how to convert the progressive input video to 50i [15:45:25 CEST] <kepstin> (what framerate is the input?) [15:45:28 CEST] <Kadigan_KSB> 25p [15:46:05 CEST] <kepstin> ok, then that's simple, you don't do anything to the video, just set some flags when encoding so the decoder thinks it's interlaced :/ [15:46:25 CEST] <kepstin> equivalent to a so-called "2:2" pulldown [15:46:34 CEST] <Kadigan_KSB> Will that pass by-hand scrutiny at delivery? [15:46:56 CEST] <Kadigan_KSB> (where in the specs they specifically say it's illegal to encode progressive) [15:47:21 CEST] <furq> you're not encoding progressive [15:47:24 CEST] <kepstin> well, basically what you do is encode a progressive video using the interlaced coding modes [15:47:26 CEST] <furq> you're just not encoding 50 fields per second [15:47:34 CEST] <kepstin> it's a bit less efficient, but should work fine [15:47:39 CEST] <furq> much like a "progressive" DVD [15:48:06 CEST] <Kadigan_KSB> I'm really in a bind here, our client delivered the specific outlets today, and it has a Monday delivery deadline :/ [15:48:31 CEST] <furq> there isn't any other solution if it's a 25p source [15:48:33 CEST] <Kadigan_KSB> (and I have absolutely NO experience with interlaced material delivery whatosever, much less XDCAM since I do HD in ProRes) [15:50:32 CEST] <SouLShocK> wouldn't the tinterlace filter work? [15:52:16 CEST] <furq> i don't think that will produce a watchable video [15:53:48 CEST] <Kadigan_KSB> So how do I tell it to output an interlaced video file? [15:54:00 CEST] <pointer> are there any good hardware guidelines on how much hardware I _should_ need to transcode a 41Mbps 4k HEVC stream down to 15-25Mbps in realtime? we were seeing 5-6fps on a VM with 12 cores from a 2cpu box w/E5-2680 v3 @ 2.50GHz [15:55:19 CEST] <Kadigan_KSB> Sometthing like -flags +ildct? -top 1? [15:55:55 CEST] <furq> -flags +ilme+ildct [15:56:15 CEST] <furq> that's for x264, i'm not totally sure if mpeg2 is the same [15:56:22 CEST] <BtbN> pointer, i don't think encoding 4K in real time is possible at all right now. [15:56:37 CEST] <BtbN> unless you use some hardware encoder. [15:56:48 CEST] <Kadigan_KSB> furq: I've seen it in two examples on the web already [15:56:51 CEST] <pointer> BtbN: that makes me sad :-\ [15:56:56 CEST] <Kadigan_KSB> but I'm getting an error opening the encoder [15:57:06 CEST] <DHE> BtbN: while I haven't tried it, benchmarks of libx264 on my E5-2698 at 1080p suggest it's doable. [15:57:10 CEST] <DHE> my wallet, however... :/ [15:57:18 CEST] <BtbN> DHE, yes, with x264 it's no problem. [15:57:26 CEST] <BtbN> With x265 though.. [15:57:32 CEST] <pointer> and 4k [15:57:53 CEST] <DHE> oh, I'm mixing up the two conversations... [16:00:47 CEST] <pointer> BtbN: yeah, we're trying a hardware encoder too... [16:04:00 CEST] <jkqxz> A desktop Skylake can do it, but the output quality is not good. [16:10:26 CEST] <pointer> jkqxz: it looks like what I have is 2x 12 core haswell-EPs [16:16:26 CEST] <pointer> is there any other software encoder that may be able to handle it if I throw enough hardware at it or is it really only possible at this point with an asic/fgpa solution? [16:21:07 CEST] <jkqxz> Why not a graphics card or non-server Intel processor? (A cheap Skylake Core i3 can do 60fps 4K transcode in Quick Sync, I believe recent NVidia cards can too.) [16:24:06 CEST] <pointer> jkqxz: I'm willing to try stuff... I need to take a 41Mbps 4k hevc multicast hevc stream and output a 25Mbps multicast stream... [16:24:25 CEST] <jkqxz> The tradeoffs to make software faster bring it down to the quality of the hardware encoders anyway, so using a huge Xeon like that is probably just wasting money and power. [16:28:20 CEST] <Venti^_> pointer: I'm able to encode a pretty difficult 60fps sequence with an E5-2797 at 47fps using superfast@20Mb/s, it hardly uses any cpu [16:29:21 CEST] <Venti^_> with libx264 [16:34:00 CEST] <rmoorelxr> is using ffmpeg to create rtmp stream that is then piped to red5 a thing that ppl do? [16:41:44 CEST] <Venti^_> realtime 4k hevc encoding is also possible, with a xeon, but you have to turn off so many features you are probably better off using h.264 [16:46:26 CEST] <rmoorelxr> is it possible to stream a file as it is being written [16:46:53 CEST] <c_14> rmoorelxr: depends on the file format [16:47:40 CEST] <rmoorelxr> h264 [16:47:57 CEST] <c_14> Raw h264 bitstream? [16:48:44 CEST] <rmoorelxr> i get a raw "h264" (in air quotes) byte stream from third party [16:48:56 CEST] <c_14> that should work [16:49:53 CEST] <rmoorelxr> do i have to reconstruct the stream every so often if i want the new content to stream? [16:50:11 CEST] <rmoorelxr> or can i somehow pipe the bytes directly [16:50:26 CEST] <c_14> as long as you're getting new data at least as fast as you're streaming it you should be fine [16:50:39 CEST] <pointer> Venti^_: I can get another CPU if that'll make the difference [16:52:34 CEST] <rmoorelxr> so if i build a stream from file being written, and then more file is written, the new content will be part of same stream? [16:52:55 CEST] <c_14> as long as you never hit EOF, yes [16:53:46 CEST] <rmoorelxr> what dark magic is this [16:54:00 CEST] <Venti^_> pointer: I think your hardware should easily be fast enough [16:54:41 CEST] <Venti^_> you just have a bottleneck somewhere... maybe hevc decoding, or you are encoding with too high of a preset [16:57:40 CEST] <pointer> Venti^_: I'm open to suggestions on what switches/options to use :) [16:58:50 CEST] <pointer> Venti^_: I can't change the source from 265 [16:58:52 CEST] <Venti^_> first I would check if you can decode the HEVC stream at the speed you need [16:59:15 CEST] <Venti^_> if you can't, maybe use a GPU to decode it [17:00:00 CEST] <Venti^_> and maybe to also encode... it's probably the easiest way if you have money to spend [17:01:42 CEST] <furq> pointer: -preset ultrafast [17:08:57 CEST] <pointer> Venti^_: what GPU would you recommend? [17:09:20 CEST] <furq> depends how many streams you need to transcode [17:09:46 CEST] <furq> iirc the quadros nvenc engines aren't any faster, they just don't have the artificial restriction on number of streams [17:09:48 CEST] <pointer> IIRC, it's 1 32-25Mbps 4k HEVC video stream and 2 audio PIDs... [17:09:52 CEST] <furq> quadros' [17:10:16 CEST] <furq> you'll need some recent nvidia card to do 4k hevc though [17:13:48 CEST] <Venti^_> something like 960 should be more than enough... just get the most expensive one you can afford [17:16:41 CEST] <ozette> if a video is 24fps and its duration is 10 seconds, does that mean there's 240 frames in the video? [17:17:01 CEST] <furq> one would hope so [17:17:15 CEST] <ozette> hope? [17:17:29 CEST] <Venti^_> looks like gtx1080 promises 10bit 4K 60fps, which is pretty nice [17:17:42 CEST] <ozette> are there exceptions? [17:19:06 CEST] <kadigan_> Say, can I use .mov to wrap MXF? [17:19:14 CEST] <furq> well for starters you probably actually have a 23.97fps video [17:19:22 CEST] <kadigan_> ie. ffmpeg -i file.mxf -???? output.mov ? [17:19:41 CEST] <furq> kadigan_: -c copy [17:19:47 CEST] <furq> i don't know if that'll work but otherwise you're not wrapping anything [17:21:57 CEST] <Venti^_> ozette: for interlaced video you might have double the number of pictures, but whether those are counted as frames depends on your definition of frame [17:22:09 CEST] <kadigan_> Well, the process did produce a .mov file, and it does seem to play in QTP [17:22:25 CEST] <kadigan_> -and- mediainfo claims it's XDCAM HD422, so... [17:22:41 CEST] <ozette> i am wondering about the definition of frame in ffmpeg so that's why i'm bothering at all [17:23:41 CEST] <ozette> i'd like to specify the amount of segments i want when segmenting a video file [17:24:16 CEST] <ozette> i have a 19 seconds long video, and tried several things, but the output stays the same: always 3 segments [17:24:41 CEST] <ozette> i was told that maybe it's because of the 'frames' [17:26:36 CEST] <Kadigan|Work> Nope, file rejected for technical reasons. [17:26:42 CEST] <furq> ozette: if you're cutting without reencoding then it's because of the keyframes [17:26:56 CEST] <furq> there's no way to predict where those are from the duration alone [17:27:32 CEST] <ozette> are keyframes and frames two different things? [17:27:36 CEST] <furq> there's also not much you can do about it even if you do know [17:27:40 CEST] <furq> and yes [17:27:58 CEST] <furq> a segment has to start on a keyframe [17:28:50 CEST] <ozette> i see [17:29:00 CEST] <ozette> because i have a 10 second long video which segments into 5 parts [17:29:17 CEST] <ozette> (m3u8) [17:29:36 CEST] <furq> if you want to have exact control then you need to reencode the video [17:29:57 CEST] <ozette> would it help if i read about keyframes in mpeg 4? [17:30:02 CEST] <furq> maybe [17:30:36 CEST] <ozette> i was hoping i could just say somthing like ffmpeg -i file.mp4 -segment 10 out.m3u8 [17:30:50 CEST] <furq> well you can do that but it'll reencode [17:31:26 CEST] <furq> https://en.wikipedia.org/wiki/Video_compression_picture_types [17:31:27 CEST] <ozette> oh [17:33:09 CEST] <ozette> not sure how ffmpeg can encode for me [17:33:27 CEST] <ozette> is it a flag? [17:34:46 CEST] <furq> the command you just pasted will reencode to whatever it thinks is the best codec for .m3u8 [17:34:49 CEST] <furq> which is presumably h264 [17:35:04 CEST] <furq> you need to specify -c copy to copy the streams from the input file [17:37:22 CEST] <ozette> ah.. i've seen people use -c copy [17:48:06 CEST] <pointer> furq and Venti^_: it looks like this is main10... so 7th gen should work [18:10:32 CEST] <pointer> furq and Venti^_: I'm working on getting a skylake cpu to try first...and also getting a 1070 [18:10:49 CEST] <pointer> furq and Venti^_: so the thought is that with GPU offload of the decode... it _may_ work? [18:20:35 CEST] <jkqxz> Skylake only has 8-bit encode/decode. Does the output have to be 10-bit? (Changing the format there might be a way of making the software encode significantly faster, too.) [18:27:03 CEST] <pointer> jkqxz: the input is 10bit... I'm not sure if the output has to be, I'll check [18:29:15 CEST] <pointer> jkqxz: the documentation says the the output can be Main or Main10 [18:36:14 CEST] <jkqxz> In that case you could try adding "-pix_fmt yuv420p" to your libx265 command-line and see if that makes it significantly faster (so that it is decoding as 10-bit but encoding as 8-bit). [18:36:47 CEST] <pointer> jkqxz: yuv420p? [18:37:30 CEST] <jiiimstr> hi. is there a list of supported video cards by ffmpeg? i think my card is left out and not supported - having confirmation would be nice (it's hauppauge colossus 1 / pci-e card) [18:38:30 CEST] <pointer> jkqxz: googling [18:41:30 CEST] <pointer> jkqxz: will that change it to 420p? that's what the documentation seems to indicate... [18:43:44 CEST] <c_14> jiiimstr: support for what? [18:48:16 CEST] <jiiimstr> c_14: i'm trying to figure out how to take that RTMP feed from my setup (xsplit pro+colossus) and pass it thru something (ffmpeg) to transmux into HLS.. this is over my field of knowledge by a large margin.. sorry for using wrong terms [18:48:40 CEST] <c_14> jiiimstr: that shouldn't use your gpu at all? [18:48:59 CEST] <c_14> ffmpeg doesn't use your gpu unless you try using something like nvenc and support for that depends on the card and your drivers [18:51:32 CEST] <jiiimstr> i never mentionned a gpu.. is a gpu a cause? capture card have onboard encoding, i was under the impression only CPU matter.. well, more stuff to confuse me. i think i just need a new capture card that has software that directly output HLS so I don't have to mess with that (sorry) incomprehensible stuff [18:53:06 CEST] <DHE> depends on the card. it might not output in a codec that's usable. some will output h264 directly, some don't [18:53:19 CEST] <DHE> h264 direct is good, hls splitting is easy [18:54:59 CEST] <c_14> jiiimstr: I misunderstood. I read video card and thought you meant gpu instead of video capture card. [18:57:47 CEST] <jiiimstr> my card is old and got prorietary drivers, it only works in xsplit pro :'( is someone in position to recommand a 1080p60fps video capture card that will be bestfriend with ffmpeg please? [18:58:43 CEST] <jiiimstr> drivers havent been updated in 3 years.. just for the record, it's an hauppauge colossus 1 pci-e [18:58:53 CEST] <BtbN> If you need Linux Support, there is pretty much only blackmagic. [18:59:11 CEST] <jiiimstr> i would rather stay on win7 if it is possible [19:00:50 CEST] <pointer> so I'm going to try to do the decode with the gtx 1070... how should I go about the encode...? the VA-api on linux or quicksync on windows or linux? or does it matter? [19:04:02 CEST] <furq> those are for intel [19:04:04 CEST] <furq> you want nvenc [19:06:27 CEST] <pointer> furq: can I do both the encode and decode on the card simultaneously? [19:07:24 CEST] <furq> nvenc is an encoder [19:07:45 CEST] <furq> i think you can use dxva2 for decoding on nvidia on windows [19:07:54 CEST] <furq> vaapi doesn't work according to the wiki [19:10:50 CEST] <furq> oh nvm apparently there's a cuvid decoder in ffmpeg now [19:12:01 CEST] <furq> you'll need a build with --enable-cuvid and --enable-nvenc [19:12:34 CEST] <BtbN> Enabling CUDA makes ffmpeg non-redistributable, so you'll have to build it yourself if you want that. [19:13:03 CEST] <furq> i can't imagine there'd be any builds with that anyway [19:13:06 CEST] <furq> it looks pretty new [19:26:51 CEST] <pointer> is there a way to make ffmpeg leave the PMT alone? it looks like it's munging it [19:35:22 CEST] <pointer> of slight interest... we were able to play back some video with VLC and get it through the downstream system successfully... we think it's because VLC wasn't munging the PMT/PIDs [19:38:05 CEST] <pointer> furq: am I going to have better luck going this on windows then? [19:38:34 CEST] <furq> cuvid should work on linux so it'll make no difference [19:38:42 CEST] <furq> i assume you'll get better results with that than with dxva2 [19:38:57 CEST] <pointer> kk, I'll get linux on this box then [19:39:42 CEST] <pointer> I have a skylake cpu now w/16GB memory...and someone will be back in around an hour with a GTX 1070 for me [19:40:05 CEST] <furq> you'll want vaapi for encoding on intel as well [19:41:16 CEST] <pointer> furq: I'm a little confused... am I going to use nvenc, or vaapi or both to encode? vaapi is the intel "open" api, right? [19:41:50 CEST] <furq> vaapi is the easiest way to encode with intel quicksync [19:41:58 CEST] <furq> nvenc is the nvidia hardware encoder [19:42:12 CEST] <furq> and cuvid is the nvidia hardware-accelerated decoder [19:42:56 CEST] <furq> the skylake will only make a difference if you're planning on using quicksync (unless you managed to find a 12-core skylake) [19:43:49 CEST] <furq> if you just want to use the 1070 then don't bother with vaapi [19:45:45 CEST] <pointer> furq: ubuntu 16.04 sound good? [19:45:53 CEST] <furq> i guess [19:46:01 CEST] <furq> you'll be compiling ffmpeg anyway so it doesn't make much difference [19:48:47 CEST] <pointer> furq: yeah, I just figured it would be easier to grab anciallary libraries I needed on ubuntu [19:49:07 CEST] <pointer> furq: s/anciallary/ancillary/ [19:49:07 CEST] <furq> i prefer debian but ubuntu is probably fine [19:54:00 CEST] <jkqxz> The libva in Ubuntu 16.04 is slow on Skylake - large performance bugs have been fixed since that release. (Ignore that if you only want to try nvidia.) [20:37:07 CEST] <pointer> well... crud... the zeranoe ffmpeg builds don't have cuvid in them [20:38:16 CEST] <pointer> or is that part of libavcodec? [20:39:04 CEST] <furq> you'll need to compile it yourself [20:39:10 CEST] <furq> the cuda stuff isn't redistributable [20:50:41 CEST] <danimal> I'm trying to transmux an mpeg-4 to an mpegts, but I keep getting dts<pcr errors unless I set the mux rate to 80% overhead or above? [21:50:28 CEST] <Dresk|Dev> So I'm compiling ffmpeg 2.8.6 through VS2015, I made my own solution file and configured options via config.h, etc. For the time being I'm playing around with static linking, since we use a very limited feature set of ffmpeg and it really doesn't add much to our binary size. However, we can't enable Whole Program Optimization on ffmpeg due to that delaying optimizations until the linker stage, which means ffmpeg won't [21:50:28 CEST] <Dresk|Dev> compile properly due to its dependency on DCE. Any ideas? [21:52:03 CEST] <shincodex> WRITE YOUR CRAP IN C SHARP FFMPEG [21:52:07 CEST] <shincodex> C# is taking over the world [21:52:35 CEST] <shincodex> Whole program optimization is suck [21:52:39 CEST] <shincodex> use yasm.exe [21:52:51 CEST] <shincodex> and allow ffmpeg to build there 12 year old written assemblies [21:53:15 CEST] <shincodex> cause ftlo doesnt seem to make a difference [21:53:24 CEST] <shincodex> though i have seen visual studios whole program optimization win wonders [21:53:30 CEST] <shincodex> cause windows defeats shit linux os [21:53:31 CEST] <corrideat> Hello. Do you know how can I convert DSF (DSD stream file) to DSDIFF? ffmpeg supports DSD to PCM conversion, apparently, but not between DSD formats [21:53:47 CEST] <Dresk|Dev> That's some, difficult to follow advice [21:54:08 CEST] <furq> Dresk|Dev: it's best not to listen to anything shincodex says [21:54:23 CEST] <Dresk|Dev> furq: Well I'll take it in stride [21:55:07 CEST] <shincodex> ^ [21:55:17 CEST] <shincodex> im going mad [21:55:18 CEST] <shincodex> right now [21:55:44 CEST] <shincodex> literally cause of .net taking over the world [21:56:56 CEST] <Dresk|Dev> Has anyone done static linking of ffmpeg and had success if you only need a few codecs and demuxers? I'm not sure if I even wanna pursue getting Whole Program Optimization to work with DCE if it's advocated against for good reason [21:57:23 CEST] <shincodex> I have [21:57:40 CEST] <shincodex> I have a library where i use only mjpeg/rstp/http/h264 [21:57:46 CEST] <shincodex> turned off everything else [21:58:14 CEST] <shincodex> avcodec to avformat to the other 2 are static compiled all in and i make a C++ wrapper to use the junk and its one .dll or .so for linux [21:58:28 CEST] <shincodex> but the im using mingw on windows side [22:01:09 CEST] <rmoorelxr> who doesnt love .net [22:25:39 CEST] <Dresk|Dev> How bad is ffmpeg 3.x compared to 2.x in terms of API? I mean are we looking at hours or days of work due to changes, or just some fundamentals? [22:54:22 CEST] <rmoorelxr> how to stream a file thats being written? [22:55:33 CEST] <rmoorelxr> i can pipe it wowza but it stops at EOF [23:03:47 CEST] <BtbN> ffmpeg -re -i thatfile.mkv rtmp://whatever [23:03:59 CEST] <BtbN> + -c copy [23:40:01 CEST] <PlanC> is it possible to have FFmpeg append contents to a file instead of overwriting it? [23:40:27 CEST] <PlanC> so right now I have "contains_content.avi" [23:40:37 CEST] <BtbN> Well, write to stdout, and use >> [23:40:51 CEST] <BtbN> But only very few containers actually "support" that. [23:41:01 CEST] <PlanC> BtbN: will that really work? [23:41:10 CEST] <BtbN> With mpegts, it should. [23:41:11 CEST] <PlanC> won't I get all the FFmpeg info with it as well? [23:41:32 CEST] <BtbN> But with any more complex container, it will fail horribly. [23:41:43 CEST] <BtbN> And even for mpegts I wouldn't recommend it. [23:41:46 CEST] <PlanC> I thought about it before but it just seems like a risky way of doing it as data could easily become corrupt [23:42:13 CEST] <PlanC> I'm not asking for much either [23:42:22 CEST] <PlanC> I just don't want FFmpeg don't clean/overwrite the file [23:42:49 CEST] <PlanC> http://stackoverflow.com/questions/33109284/how-to-get-ffmpeg-to-append-to-… [23:43:02 CEST] <PlanC> someone asked this in october of last year with the same reply [23:43:35 CEST] <BtbN> containers and video-streams are simply not made to work like that. [23:47:08 CEST] <PlanC> I see [23:47:30 CEST] <PlanC> but in a case (like mine) where I just want to have raw data appended to a file a feature like that would be super useful [23:49:48 CEST] <BtbN> It's not a feature that could be added. It just doesn't work that way. Save to a lot of individual files, and concat them later. [23:51:11 CEST] <PlanC> that's the only option there is I guess [00:00:00 CEST] --- Sat Aug 6 2016

1 0

ffmpeg-devel.log.20160804
by burek 05 Aug '16

05 Aug '16

[00:16:54 CEST] <CFS-MP3> the doc for the scale2ref filter is wrong (doesn't show input, for starters). I'd like to correct it but I need to make sure I got it correctly [00:16:55 CEST] <CFS-MP3> https://ffmpeg.org/ffmpeg-filters.html#scale2ref [00:17:01 CEST] <CFS-MP3> there the documentation says: [00:17:15 CEST] <CFS-MP3> Scale a subtitle stream to match the main video in size before overlaying [00:17:15 CEST] <CFS-MP3> 'scale2ref[b][a];[a][b]overlay' [00:17:57 CEST] <CFS-MP3> What's the reference video there, and why does it has two outputs? [00:24:14 CEST] <llogan> CFS-MP3: yes, it could be improvded to be more clear. ffmpeg -i main_video.mp4 -i logo.png -filter_complex "[1:v][0:v]scale2ref[resized][reference];[reference][resized]overlay" output.mp4 [00:32:37 CEST] <CFS-MP3> llogan I think even more than that :-) So in that example, the logo.png would be resized to the size of main_video, then the outputs are the logo resized main_video identical to the original? [00:35:02 CEST] <llogan> it will result in logo being overlaid over main_video. the logo would be the same width and height as main_video. [00:42:54 CEST] <cone-220> ffmpeg 03Anton Khirnov 07master:b13fc1e34401: h264: do not pass H264Context to h264_slice_header_parse() [00:42:54 CEST] <cone-220> ffmpeg 03Timothy Gu 07master:bca30ed2b67f: Merge commit 'b13fc1e344011949929975a3451f78f226aa1de3' [01:01:09 CEST] <cone-220> ffmpeg 03Anton Khirnov 07master:d1d7678040cd: h264: fix the check for mixed IDR/non-IDR slices [01:01:10 CEST] <cone-220> ffmpeg 03Timothy Gu 07master:796027f22154: Merge commit 'd1d7678040cd60148f97b372cb4291bcc45b2e22' [01:03:39 CEST] <CFS-MP3> fflogger are you sure? :-) [01:03:45 CEST] <CFS-MP3> This filter: -filter_complex [0:v][0:s]scale2ref[resizedsubs][video];[video][resizedsubs]overlay[finaloverlay] [01:03:55 CEST] <CFS-MP3> results on this: [01:04:36 CEST] <CFS-MP3> Stream mapping: [01:04:36 CEST] <CFS-MP3> Stream #0:0 (mpeg2video) -> scale2ref:default (graph 0) [01:04:36 CEST] <CFS-MP3> Stream #0:2 (dvbsub) -> scale2ref:ref (graph 0) [01:04:36 CEST] <CFS-MP3> overlay (graph 0) -> Stream #0:0 (libx264) [01:06:02 CEST] <CFS-MP3> so it seems liek it's taking 0:2 as reference (unless I getting it totally wrong) [01:09:19 CEST] <CFS-MP3> Sorry, I mean llogan [01:16:07 CEST] <jamrial> Timothy_Gu: don't merge those commits just like that, they need proper testing. our slice code differs a lot from libav [01:16:44 CEST] <jamrial> there's a reason i stopped where i did [01:16:49 CEST] <Timothy_Gu> jamrial: b13fc1e34401 is basically a noop [01:17:06 CEST] <Timothy_Gu> I can revert 796027f22154 if you want? [01:17:06 CEST] <jamrial> i know, i'm talking about the second one [01:18:18 CEST] <jamrial> poke michaelni or someone that can test h264 thorougly first, and let someone that knows this code better merge further commits [01:22:12 CEST] <jamrial> h264dec is a minefield [02:04:47 CEST] <Timothy_Gu> jamrial: okay, I'll revert that after merging the next one, which is a noop. [02:06:15 CEST] <Timothy_Gu> actually I'll just revert it [02:07:28 CEST] <cone-220> ffmpeg 03Timothy Gu 07master:e4af9be0f45c: Revert "Merge commit 'd1d7678040cd60148f97b372cb4291bcc45b2e22'" [02:09:09 CEST] <Timothy_Gu> michaelni: in case you didn't see, would you mind looking at d1d7678040cd60148f97b372cb4291bcc45b2e22 to see if it should be merged at all? [02:10:08 CEST] <Timothy_Gu> jamrial: thanks for the heads-up [02:35:17 CEST] <jamrial> BBB: vp8/9 alpha maybe? that was your first idea some weeks ago [02:35:26 CEST] <BBB> jamrial: oh right that was it! [02:35:41 CEST] <michaelni> Timothy_Gu, 796027f22154c799e0063e2457b31e0cfd1dddae LGTM, this seems a bugfix from a bug introduced in 51d8725a6e4c7f989d6f0f38b59cb54a2d72846c or earlier [02:46:38 CEST] <Timothy_Gu> michaelni: okay thanks [02:51:38 CEST] <cone-220> ffmpeg 03Anton Khirnov 07master:606fb6c032fa: h264: call the hwaccel frame_start() from h264_field_start() [02:51:39 CEST] <cone-220> ffmpeg 03Timothy Gu 07master:826c780c1209: Revert "Revert "Merge commit 'd1d7678040cd60148f97b372cb4291bcc45b2e22'"" [02:51:40 CEST] <cone-220> ffmpeg 03Timothy Gu 07master:d3426fb5921d: Merge commit '606fb6c032fa44d9fa1efd4971308c228f2ebfff' [03:03:06 CEST] <jamrial> Timothy_Gu: if you want to try the next three commits in this h264 batch then go ahead [03:03:21 CEST] <jamrial> Timothy_Gu: but first push them to some personal repo for michaelni to test, if he's ok with it. fate alone is unfortunately not enough to make sure things are working [03:04:45 CEST] <jamrial> it was not my intention to tell you to stop, just to be extra careful if you're not familiar with the code. h264_slice is a finicky thing [03:14:26 CEST] <sanmarcos> anybody know how can I memset a buffer in the YUV color space to be black? [03:14:27 CEST] <sanmarcos> black in YUV is Y=0, U=128, V=128 [03:14:31 CEST] <sanmarcos> I420 specifically [03:21:58 CEST] <Timothy_Gu> jamrial: yeah, I understand. It's rare for me to do merges, and obviously it shows [03:33:15 CEST] <BBB> sanmarcos: black can also be Y=16,U/V=128 [03:34:36 CEST] <BBB> sanmarcos: but you would memset(frame->data[0], frame->color_range == AVOL_RANGE_JPEG ? 0 : 16, frame->linesize[0] * frame->height); and then memset(frame->data[1 and 2], 128, frame->liensize[1 and 2] * frame->height >> 1); [03:45:21 CEST] <sanmarcos> BBB: hmmm [03:45:33 CEST] <sanmarcos> BBB: http://www.mit.edu/afs.new/athena/astaff/source/src-9.4/third/gst-plugins/g… [03:45:39 CEST] <sanmarcos> thinking about the fill_i420 function in there [03:49:40 CEST] <Timothy_Gu> sanmarcos: are you not sure how the function works or how the colors work? [03:50:27 CEST] <sanmarcos> I am compiling, (this is a modification to an existing codebase) [03:51:42 CEST] <sanmarcos> somebody suggested that for black, this should work [03:51:45 CEST] <sanmarcos> memset(vp->frm_buf->buf, 0x80, vp->frm_buf_size) [03:51:57 CEST] <sanmarcos> pj_bzero(vp->frm_buf->buf, vparam.fmt.det.vid.size.w*vparam.fmt.det.vid.size.h); [03:53:55 CEST] <sanmarcos> 0x80 being 128 of course [03:54:14 CEST] <Timothy_Gu> what's pj_bzero? [03:54:20 CEST] <sanmarcos> bzero essentially [03:55:20 CEST] <Timothy_Gu> technically yeah, that should work [03:55:51 CEST] <Timothy_Gu> albeit inefficient because you are filling the entire buffer with 0x80 before overwriting half of it with 0 [03:56:38 CEST] <Timothy_Gu> or maybe not half, 2/3 [04:09:40 CEST] <sanmarcos> Timothy_Gu: it works! it works! [04:10:24 CEST] <Timothy_Gu> sanmarcos: Do you know if your material is MPEG or not? [04:10:32 CEST] <sanmarcos> so memset buf + vparam.fmt.det.vid.size.w*vparam.fmt.det.vid.size.h with 0x80 with size vp->frm_buf_size - (vparam.fmt.det.vid.size.w*vparam.fmt.det.vid.size.h) [04:10:50 CEST] <sanmarcos> Timothy_Gu: it is a I420 buffer that will be filled with data decoded from OpenH264 [04:11:03 CEST] <sanmarcos> until the first keyframe comes in, it shows green (because 0 in YUV ends up green) [04:11:36 CEST] <Timothy_Gu> ah okay. Then instead of setting 0 you should set 16 [04:11:45 CEST] <sanmarcos> Timothy_Gu: why? [04:11:45 CEST] <Timothy_Gu> (like BBB mentioned) [04:12:10 CEST] <Timothy_Gu> https://www.wikiwand.com/en/YUV#/Studio_swing_for_BT.601 [04:12:23 CEST] <sanmarcos> 16/128/128 is like RGB 16/16/16 [04:12:30 CEST] <BBB> no [04:13:21 CEST] <sanmarcos> no? [04:13:34 CEST] <BBB> no [04:13:38 CEST] <sanmarcos> http://www.mikekohn.net/file_formats/yuv_rgb_converter.php [04:13:41 CEST] <sanmarcos> I got that from there [04:13:51 CEST] <BBB> 16/128/128 in mpeg domain (standard for older videos) is rgb 0/0/0 [04:14:04 CEST] <BBB> for jpeg domain, it is indeed 16/16/16 [04:14:20 CEST] <sanmarcos> I see, well either way I doubt anybody can see the differene between 16/16/16 and 0 0 0 [04:14:30 CEST] <sanmarcos> this YUV buffer is rendered on screen with OpenGL by the way [04:14:33 CEST] <BBB> the colors will be off [04:14:43 CEST] <BBB> by quite a bit [04:14:45 CEST] <BBB> anyway [04:14:47 CEST] <BBB> up to you [04:14:53 CEST] <sanmarcos> I will try both and see which one looks better? [04:14:53 CEST] <BBB> not telling you how to do your work ;) [04:15:03 CEST] <BBB> it depends on the video [04:15:05 CEST] <sanmarcos> you should, because I have very little experience in MPEG or color spaces [04:15:09 CEST] <BBB> jpeg/mpeg is a property of the video stream [04:15:15 CEST] <BBB> it is not a property of the color converter or whatever [04:15:20 CEST] <sanmarcos> BBB: this is just setting up the buffer, openh264 will overwrite it [04:15:31 CEST] <BBB> brb [04:15:58 CEST] <Timothy_Gu> You did say right now it shows green [04:16:07 CEST] <sanmarcos> yup [04:16:13 CEST] <Timothy_Gu> So even though it's overwritten, it's still gonna be displayed [04:16:25 CEST] <sanmarcos> what is? [04:16:30 CEST] <Timothy_Gu> The frame [04:16:38 CEST] <sanmarcos> the green isn't a frame [04:17:25 CEST] <Timothy_Gu> I meant the frame buffer [04:17:44 CEST] <sanmarcos> yes, the frame buffer is rendered through OpenGL even though a keyframe has not been rendered yet [04:17:47 CEST] <sanmarcos> https://trac.pjsip.org/repos/browser/pjproject/trunk/pjmedia/src/pjmedia/vi… [04:17:50 CEST] <sanmarcos> that is where it is set up [04:18:11 CEST] <sanmarcos> and this is the solution http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2016-August/019417.h… [04:19:12 CEST] <sanmarcos> either way, the solution works, it is inefficient as has been said, but that can be easily modified [04:23:00 CEST] <Timothy_Gu> sanmarcos: okay here [04:23:08 CEST] <Timothy_Gu> https://github.com/cisco/openh264/blob/38313b913d62e7f71967f51462dc0dc37f85… [04:24:29 CEST] <Timothy_Gu> not like it matters but [04:24:47 CEST] <sanmarcos> Timothy_Gu: why doesnt it matter? [04:24:55 CEST] <sanmarcos> the PJSIP code base doesn't seem to touch that parameter [04:24:58 CEST] <Timothy_Gu> becaues it's black :D [04:25:12 CEST] <sanmarcos> black colors don't matter? [04:25:45 CEST] <sanmarcos> is that something that the decoder takes care of, or something intrisnic to the data that is encoded? [04:26:00 CEST] <sanmarcos> if they are using the analog range or digital range [04:27:14 CEST] <Timothy_Gu> sanmarcos: it's intrinsic to the data [04:28:14 CEST] <sanmarcos> yeah there is no way for me to enforce this then, because while I can control my own clients, say set them to bFullRange = true (to get digital!) [04:28:23 CEST] <sanmarcos> but other clients who send me video may send it in analog [04:28:58 CEST] <sanmarcos> I doubt that sort of information is stored in the SDP header, it is most likely obtained when the openh264 decoder begins decoding [04:29:08 CEST] <sanmarcos> from which then I can make a choice wheter to paint with 0 or 16 [04:32:08 CEST] <sanmarcos> I'll check for PJMEDIA_FORMAT_I420JPEG as well [04:43:39 CEST] <sanmarcos> which of course, doens't come, so it is 420, I just don't know the bFullRange of it [06:41:39 CEST] <jya> BBB: does your VP8 or VP9 decoder use any of the av_opt_* api ? trying to determine if I can get rid of the entire opt/dictionary stuff. there's a lot of related strings which account for a fair chunk of memory once loaded [06:43:42 CEST] <Timothy_Gu> jya: Doesn't seem like vp9 does, but libavcodec in general needs it [06:44:19 CEST] <jya> Timothy_Gu: currently the only thing I need is vp8,vp9 and flac.. so removing anything I can helps :) [06:46:11 CEST] <Timothy_Gu> michaelni: would you mind reviewing these merges: https://github.com/TimothyGu/FFmpeg/commits/merge? From e0c8250 (inclusive) till 26648703 [06:47:45 CEST] <Timothy_Gu> jya: I assume you already removed other chunks in libavutil we don't use? [06:48:22 CEST] <jya> Timothy_Gu: most if it yes. basically only took what was required to make libavcodec compile [06:48:38 CEST] <jya> but i didn't go into individual file and trimmed them manually. [06:48:44 CEST] <jya> I only worked at a file level. [06:48:58 CEST] <Timothy_Gu> that should be fine [06:49:04 CEST] <jya> as I figure modifying the original file would cause pain whenever we wanted to update [06:49:41 CEST] <Timothy_Gu> did you remove any of these https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/Makefile#L23-L49 [06:53:03 CEST] <jya> Timothy_Gu: thanks... [06:55:17 CEST] <Timothy_Gu> not saying you _can't_ remove the giant libavcodec options table, but I wouldn't try it [07:16:18 CEST] <BBB> jya: nothing specific for vp8/9, no [07:16:36 CEST] <jya> BBB: awesome.. hope it stays that way [07:16:43 CEST] <BBB> likely will [07:16:54 CEST] <BBB> I Cant think of anything that wed want to make configurable [07:16:57 CEST] <jya> though removing the strings and all code related to av_opt only managed to shave 50kB [07:17:06 CEST] <jya> out of 3.7MB [07:17:15 CEST] <jya> bit disappointing [10:39:11 CEST] <michaelni> Timothy_Gu, your branch should be ok [10:41:11 CEST] <Timothy_Gu> michaelni: cool. Will merge tomorrow [16:05:30 CEST] <nevcairiel> Timothy_Gu: before you push, can you cleanup the double revert thingy in there? it looks rather ugly and hard to follow what exactly is going on now [16:11:11 CEST] <jamrial> nevcairiel: that's unfortunately already pushed [16:11:30 CEST] <nevcairiel> didnt he ask fore review just hours ago [16:12:05 CEST] <nevcairiel> i'm not sure I like everyone doing merges now with unclear experience in doing so [16:12:56 CEST] <jamrial> that's why i told him to first ask for review before doing so, especially with functionality changes in delicate code [16:13:21 CEST] <jamrial> and he didn't push everything in that github repo, just up to merge commit 606fb6c [16:14:07 CEST] <jamrial> what's already pushed was reviewed by michaelni. it sadly looks ugly because of the double revert, though [20:17:04 CEST] <cone-027> ffmpeg 03Anton Khirnov 07master:6efc4638584e: h264: always set redundant_pic_count during slice header parsing [20:17:04 CEST] <cone-027> ffmpeg 03Anton Khirnov 07master:e26c64148be8: h264: discard slices of redundant pictures right after parsing the slice header [20:17:05 CEST] <cone-027> ffmpeg 03Anton Khirnov 07master:58640fe89ec4: h264: handle frame recovery in h264_field_start() [20:17:06 CEST] <cone-027> ffmpeg 03Anton Khirnov 07master:49670e4218d3: avconv: add a function for determining whether a filtergraph is simple [20:17:07 CEST] <cone-027> ffmpeg 03Anton Khirnov 07master:73c6ec6d659b: avconv: create simple filtergraphs earlier [20:17:09 CEST] <cone-027> ffmpeg 03Anton Khirnov 07master:5e1840622ce6: avconv: fix handling attachments in init_output_stream [20:17:09 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:e0c8250a59ad: Merge commit '6efc4638584e1e14d1a6152186ba28f5d48a80c0' [20:17:10 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:de625312862a: Merge commit 'e26c64148be8a20ace7512d96503172fb5e9753b' [20:17:12 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:7f7cedd7139f: Merge commit '58640fe89ec4f2a3d67c0a2585fca8de34440857' [20:17:12 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:9aa3023672b3: Merge commit '49670e4218d34899a1c37abb7a11615efc16f757' [20:17:13 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:1b04ea1a6c23: Merge commit '73c6ec6d659bab11ac424a4ba6ce3a56246295ee' into merge [20:17:14 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:e5c79cd85492: Merge commit '5e1840622ce6e41c57d9c407604863d3f3dcc3ae' [20:17:15 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:26648703dbfb: ffmpeg_opt: Remove duplicated initialization of attachment stream [20:17:17 CEST] <cone-027> ffmpeg 03Timothy Gu 07master:f297d1e9e528: h264dec: Fix indentation [20:18:01 CEST] <Timothy_Gu> nevcairiel: yeah sorry about that [21:27:49 CEST] <cone-027> ffmpeg 03James Almer 07master:155f4e963021: avformat/avio: add a crc callback function for CRC-32 IEEE-LE [21:27:50 CEST] <cone-027> ffmpeg 03James Almer 07master:ce944e84892f: avformat/tta: remove custom crc callback function [21:27:51 CEST] <cone-027> ffmpeg 03James Almer 07master:376d4b3c0d9d: avformat: add a TTA Muxer [21:34:55 CEST] <jamrial> michaelni: patchwork gives a 502 bad gateway error [21:35:03 CEST] <jamrial> who was the one that set it up? [21:35:18 CEST] <michaelni> should be fixed, raz set it up [21:35:39 CEST] <jamrial> michaelni: works now, thanks [21:37:02 CEST] <llogan> too bad the listed maintainers email addresses are not obfuscated [21:42:07 CEST] <cone-027> ffmpeg 03James Almer 07master:be63ef3c4e63: avcodec/vdpau: clean up vdpau_internal.h [21:43:31 CEST] <michaelni> llogan, any idea how this can be changed ? [21:44:03 CEST] <llogan> i haven't looked into it yet, but i don't think it's a big deal. just a nit. [22:05:15 CEST] <llogan> michaelni: patchwork/templates/patchwork/project.html could be edited. maybe i'll do that later. [22:07:19 CEST] <durandal_1707> kierank: you alive? [22:07:26 CEST] <kierank> yes [23:37:51 CEST] <cone-027> ffmpeg 03Michael Niedermayer 07master:82a33c8d8584: avformat: Add av_get_frame_filename2() and AV_FRAME_FILENAME_FLAGS_MULTIPLE [23:37:52 CEST] <cone-027> ffmpeg 03Michael Niedermayer 07master:dd96a5847319: avformat/hlsenc: Use AV_FRAME_FILENAME_FLAGS_MULTIPLE, support tee: [23:37:53 CEST] <cone-027> ffmpeg 03Michael Niedermayer 07master:1fb8f6b75cb8: avformat/img2enc: Use AV_FRAME_FILENAME_FLAGS_MULTIPLE, support tee: [00:00:00 CEST] --- Fri Aug 5 2016

1 0

ffmpeg.log.20160804
by burek 05 Aug '16

05 Aug '16

[00:24:15 CEST] <Coder206> Hi! I hope you are doing well! I am trying to install FFmpeg as a dependency using Terminal in Fedora 24 and I received an error saying that it was not found. How do I install this without going through RPM fusion? [00:25:34 CEST] <c_14> Your only other bet (on Fedora) is to compile manually. [00:25:53 CEST] <Coder206> c_14: Thanks. [00:25:57 CEST] <llogan> If you only need the cli tool binary just use http://johnvansickle.com/ffmpeg/ [00:26:22 CEST] <c_14> Because he said dependency, I assumed he meant the libs. but if you only need the cli that'll work, yes. [00:28:13 CEST] <Coder206> c_14, llogan: I just need libavutil, libavformat and libavcodec, is it possible to do this without RPM or compiling? [00:30:06 CEST] <Coder206> *RPM Fusion [00:30:21 CEST] <c_14> None I know of. [00:30:30 CEST] <drv> what do you need them for? presumably there will be compiling involved anyway if you need the libs [00:31:15 CEST] <llogan> you can compile and simply not install anything to avoid package management mess [00:33:33 CEST] <Coder206> drv: They are a new requirement for the Mozilla Servo project. [00:34:26 CEST] <Coder206> lllogan: The project is trying to avoid compiling for this dependency. [00:34:36 CEST] <Coder206> * llogan: ^ [00:34:41 CEST] <Coder206> Sorry! [00:35:01 CEST] <drv> you could choose a distro that actually includes ffmpeg :) but otherwise, it will require compiling or a third-party repository [00:36:33 CEST] <Coder206> drv: So Fedora doesn't have it included? [00:37:02 CEST] <drv> I believe Fedora (Red Hat) doesn't include ffmpeg for patent concerns [00:38:23 CEST] <Coder206> drv: Thanks! [00:38:41 CEST] <Coder206> We are going with the compiling and not installing proposal by llogan [00:42:24 CEST] <Coder206> Thanks everyone [02:30:06 CEST] <nukke> having some problems with ffserver/ffmpeg. for ffserver I'm using the OGG example config at the bottom of this page: https://trac.ffmpeg.org/wiki/ffserver [02:30:53 CEST] <llogan> ffserver is going away. [02:31:15 CEST] <nukke> noooooooooooooooo [02:31:22 CEST] <nukke> any alternatives? :( [02:31:32 CEST] <nukke> trying to find a way to webcam with my cat over my weekend trip. [02:32:03 CEST] <llogan> http://ffmpeg.org/index.html#ffserv [02:33:00 CEST] <nukke> well, that's interesting. weirdest timing. [02:36:19 CEST] <nukke> ok VLC works. thanks llogan o_O [04:48:24 CEST] <funfunctor> Howdy [04:49:30 CEST] <funfunctor> Does ffmpeg have the ability to use the GPU's IP cores for dealing with codec? [05:14:54 CEST] <Sashmo_> can anyone suggest what the best way is to get the audio levels across separate PCM channels from a file? I'm trying to detect what volume if any per channel [05:25:46 CEST] <furq> Sashmo_: -filter_complex "channelsplit[left][right];[left]volumedetect;[right]volumedetect" [05:26:01 CEST] <Sashmo_> thanks furq Ill try that [05:36:24 CEST] <Sashmo_> furq: but I dont need to split the channels, they are already split into 8 mono channels 0:1->0:8 [05:37:36 CEST] <furq> -filter_complex "[0:1]volumedetect;[0:2]volumedetect... [05:37:49 CEST] <Sashmo_> hmm I tried that but let me try it again.... [05:38:51 CEST] <Sashmo_> furq: you're right... I misstyped it! [05:38:55 CEST] <Sashmo_> thanks again [11:05:58 CEST] <kdehl> What do "baseline @ L 10" and "baseline @ L 30" mean when I use file(1) on my two H.264 files? [11:06:24 CEST] <furq> kdehl: [11:06:31 CEST] <kdehl> The difference between the two videos is only that one is 90 pixels high, the other is 100. [11:06:38 CEST] <furq> https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles and https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels [11:06:39 CEST] <kdehl> furq: Yes? :) [11:07:18 CEST] <kdehl> furq: Right, I know baseline, but what do 30 and 10 stand for? [11:07:27 CEST] <furq> presumably level 1.0 and 3.0 [11:07:34 CEST] <kdehl> Ahhh. [11:07:37 CEST] <furq> or 1 and 3, since there is no .0 [11:07:57 CEST] <kdehl> Right. [11:08:18 CEST] <kdehl> Confusing output, really. Maybe one should file a bug report. [11:08:48 CEST] <jkqxz> file is just telling you the contents of the level_idc field at the beginning of the SPS. (It doesn't have any capability to do much more than that.) [11:09:16 CEST] <furq> i'm impressed that it even does that really [11:09:18 CEST] <kdehl> Is the SPS always the first NAL? [11:09:26 CEST] <kdehl> Heh. [11:09:34 CEST] <kdehl> file is impressive. [11:09:54 CEST] <furq> i forget what it was now but i remember it being completely wrong a few times [11:10:02 CEST] <furq> it's normally pretty good though [11:10:16 CEST] <jkqxz> No, though it usually is in raw streams. [11:10:37 CEST] <kdehl> jkqxz: Right. [11:11:05 CEST] <kdehl> The ones I've seen always have it as the first one. Then comes a PPS. [11:11:24 CEST] <kdehl> (That being said, I've only played around with this for a week.) [11:16:29 CEST] <jkqxz> The only (relatively) common case where it isn't is when you have a stream with AUD NAL units in. [11:23:00 CEST] <kdehl> Audio? [11:25:52 CEST] <kdehl> Ah. Access Unit Delimiter. [15:04:29 CEST] <akr> hello [15:04:32 CEST] <akr> anyone around? [15:05:13 CEST] <DHE> just ask/say what you want [15:05:46 CEST] <akr> I'm trying to stream my desktop over udp [15:05:59 CEST] <akr> here is the command line: ffmpeg -f x11grab -s 1600x900 -r 15 -i :0.0 -vcodec libx264 -an -f mpegts "udp://127.0.0.1:8554/" [15:06:23 CEST] <akr> when I try to play back the stream in ffplay, I get no image and loads of errors: "no frame!" [15:06:39 CEST] <akr> and I can't figure out what's wrong :) [15:08:27 CEST] <akr> I also tried to stream over rtsp, rewriting '-f mpegts' to '-f rtsp' and "udp://&" to "rtsp://&", but then I an error from ffmpeg: Could not write header for output file #0 (incorrect codec parameters ?): Connection refused [15:09:25 CEST] <akr> What I am trying to do, (in case these is some better ffmpeg setup for this), is to stream my desktop to serviio [15:13:32 CEST] <akr> serviio supports http, mmsh, mmst, rtp, and rtsp [15:15:08 CEST] <akr> I also tried streaming from vlc, but I was getting something like 1/60 fps and glitches [15:19:41 CEST] <DHE> well, you need an endpoint to receive the data. otherwise you get errors. rtsp requires a server, udp requires something to listen. [15:19:49 CEST] <DHE> for the latter you can get away with a multicast-based target [15:21:16 CEST] <akr> So you're saying it's impossible to stream using ffmpeg and receive using ffplay? [15:22:02 CEST] <akr> (I'm using ffplay only to test the stream btw) [15:23:50 CEST] <akr> anyway, my server is serviio [15:24:16 CEST] <akr> but I have trouble creating a stream in ffmpeg that even fflay can listen to [15:24:16 CEST] <DHE> the udp method should work if you launch ffplay first and wait for ffmpeg to start sending [15:24:30 CEST] <akr> hmm [15:24:32 CEST] <akr> will try [15:24:59 CEST] <DHE> also, just noticed this, I don't use a trailing / on the URL for udp:// [15:27:52 CEST] <akr> Okay, you were right about having to launch ffplay first when trying to stream through udp [15:28:09 CEST] <akr> the trailing / doesn't seem to matter [15:30:08 CEST] <DHE> you can also try the multicast method. set the destination IP to something in the 239.x.x.x range [15:30:52 CEST] <akr> I don't think serviio can listen to udp, though :( [15:31:04 CEST] <akr> So I need to get rtp or rtsp or mmsh working [15:32:34 CEST] <akr> rtp is weird, ffplay says it needs a config file to receive it, so how des serviio receive it? [15:32:45 CEST] <akr> serviio uses ffmpeg internally as well I think [15:33:14 CEST] <c_14> akr: it wants the sdp file [15:33:43 CEST] <c_14> when you use ffmpeg to create an rtp stream it outputs the sdp info to stdout, you can also use -sdp_file to write it to a file [15:33:49 CEST] <c_14> Then feed that to ffplay [15:33:55 CEST] <akr> Yeah I saw that [15:34:09 CEST] <akr> but then I do "ffmpeg -protocol_whitelist file -i stream.sdp" [15:34:22 CEST] <akr> and I get "Protocol not on whitelist 'file'!" [15:34:44 CEST] <akr> *ffplay [15:37:02 CEST] <akr> Also, any idea what's wrong with my rtsp command line? [15:37:47 CEST] <akr> that is: ffmpeg -f x11grab -s 1600x900 -r 15 -i :0.0 -vcodec libx264 -an -f rtsp "rtsp://127.0.0.1:8554/" [15:38:20 CEST] <akr> oh, do I have something running on the other side with rtsp as well? [15:38:31 CEST] <akr> have to have* [15:39:16 CEST] <akr> Doesn't seem like it [15:40:09 CEST] <c_14> akr: playing the sdp file in mpv seems to work, so it's probably just a bug in the ffmpeg/ffplay commandline programs [15:42:02 CEST] <jokke> hey [15:42:20 CEST] <jokke> i'm trying to find good settings for encoding screencasts with vp8 [15:42:32 CEST] <jokke> so far everything looks pretty crappy [15:43:14 CEST] <jokke> i tried playing around with -crf going down as far as 4 and -b:v upto 2M [15:43:42 CEST] <c_14> akr: rtsp needs a server listening on the other side [15:46:20 CEST] <akr> c_14: hm, but I get 'connection refused' when I try to start ffplay first, pointing it to an rtsp url [15:46:42 CEST] <c_14> akr: you need -rtsp_flags listen [15:47:27 CEST] <akr> Ah. [15:47:51 CEST] <akr> But now I get "Invalid data found when processing input" in ffplay once I try to start the stream. [15:48:01 CEST] <akr> and ffplay exits [15:52:00 CEST] <karklud> is it possible to get ffprobe to output the duration of file, solely based on information found in the file header - and not by looking at the actual size of the file? [15:52:19 CEST] <karklud> i need to retrieve the duration of a file which is in the progress of being transferred to my machine [15:52:27 CEST] <karklud> so the file isn't complete [15:52:41 CEST] <karklud> and ffprobe is giving me the wrong results [15:53:10 CEST] <DHE> sounds like that information isn't directly available. different formats have different requirements and may involve seeking to the end to read timestamps, etc. [15:53:10 CEST] <karklud> i'm using the arguments -show_streams -show_format [15:53:39 CEST] <karklud> yeah, so i guess a general solution can't exists, but there's no way of getting the information out IF it exists? [15:54:15 CEST] <karklud> the use case will mostly be WAV's and AIFF files anyway, so more often than not the information will be available after having received less than 1kb of data [16:06:37 CEST] <Mandevil> What's wrong with this commandline: ffmpeg.exe -i src.mov -c:0:0 copy -c:0:1 aac dst.mov [16:06:43 CEST] <Mandevil> It says 'aac' is invalid codec. [16:07:26 CEST] <DHE> old version that doesn't have the aac encoder? [16:07:26 CEST] <Mandevil> Any coded I choose is rejected as invalid. [16:07:37 CEST] <Mandevil> It's on the -codecs list! [16:07:44 CEST] <DHE> with the 'E' flag? [16:07:49 CEST] <Mandevil> Yes. [16:07:57 CEST] <c_14> -c:0:0 and -c:0:1 aren't valid mappings (in this context) [16:07:58 CEST] <Mandevil> If I put some pcm there it will say the same thing. [16:08:18 CEST] <c_14> I assume you want -c:0 and -c:1 [16:08:34 CEST] <furq> or -c:v and -c:a [16:08:41 CEST] <Mandevil> OK, let me try. [16:08:46 CEST] <c_14> the mappings for the -c flag refer to the output streams per-output [16:09:27 CEST] <Mandevil> It works. [16:09:32 CEST] <Mandevil> Ah, ok. [16:09:34 CEST] <furq> i wonder what -c:0:0 even does [16:09:40 CEST] <furq> it's not a valid stream specifier [16:11:17 CEST] <Mandevil> Thank you for help :) [16:24:37 CEST] <Mandevil> Hm, when I transcode MJPEG->ProRes (for example), the resulting video has lower contrast... [16:25:36 CEST] <Mandevil> The source and destination are both YUV. [16:25:49 CEST] <Mandevil> (though the source is 4:2:0 and destionation is 4:2:2) [16:26:26 CEST] <Mandevil> I assume the dynamic range is little squashed in the target video, but why? [16:43:45 CEST] <kepstin> Mandevil: jpeg usually is interpreted as using "full range" or "pc range", with the full values 0-255, but video uses limited range where black is at 16 and white is at 235, iirc. Assuming the players are all working properly, both should *appear* the same at playback... [16:44:39 CEST] <kepstin> there could be some incorrect conversions going on at some point, too :/ [16:45:47 CEST] <Mandevil> VLC clearly doesn't play it correctly then? [16:45:56 CEST] <Mandevil> Because the video loaded in Resolve looks fine. [16:46:06 CEST] <Mandevil> But in VLC it looks grayish, low contrast. [16:46:09 CEST] <kepstin> hard to say. I'd suggest using mpv with the opengl output to compare [16:46:15 CEST] <kepstin> could be a vlc issue [16:46:22 CEST] <Mandevil> mpv? [16:59:48 CEST] <bencoh> or could be that your transcoder doesn't put the proper flag/field/whatever in your resulting stream [17:00:51 CEST] <bencoh> (bt601 vs bt709?) [17:02:09 CEST] <kepstin> hmm, bt601 vs bt709 won't make a big constrast difference, it's a bit more subtle than that [17:08:09 CEST] <bencoh> ah right, he meant contrast, nevermind [17:08:28 CEST] <bencoh> not shifted red and stuff like that [17:08:43 CEST] <Mandevil> My transcoder is ffmpeg :) [17:11:07 CEST] <Mandevil> When I use -c:0 libx264, the video plays alright in VLC. [17:11:15 CEST] <Mandevil> When I use -c:0 prores, it's wrong. [17:11:45 CEST] <c_14> try the other prores encoder? [17:11:51 CEST] <Mandevil> "The other"? [17:11:54 CEST] <c_14> There's 2 [17:11:59 CEST] <Mandevil> In ffmpeg? [17:12:12 CEST] <c_14> either _aw or _ks [17:12:15 CEST] <c_14> yes [17:13:46 CEST] <Mandevil> Hm, the _ks is much slower. [17:14:49 CEST] <Mandevil> The result from both _ks and _kw is same as contrast is concerned. [17:15:25 CEST] <Mandevil> Maybe VLC is not playing ProRes correctly. [17:15:39 CEST] <c_14> try ffplay or mpv or something maybe [17:16:19 CEST] <Mandevil> Tried MPC. [17:16:40 CEST] <Mandevil> Funny thing... it's about halfway between VLC playing source and VLC playing ProRes. [17:17:10 CEST] <akr> DHE: I managed to get the stream going with VLC, but it freezes after 1 frame :/ [17:17:21 CEST] <akr> All in all, rather poorly spent ~6 hours. [17:19:21 CEST] <Mandevil> So i tried quicktime player. [17:19:40 CEST] <Mandevil> In QT all three files are equally gray :-O [17:22:05 CEST] <Mandevil> In ffplay it's the same as in QT. [17:22:29 CEST] <Mandevil> I'm losing track of what's actually right. [17:24:12 CEST] <BtbN> sounds like limited vs. full range RGB? Or is that what bt601/709 is about? [17:24:19 CEST] <Mandevil> Yes, that's what it is. [17:24:53 CEST] <Mandevil> ffplay even says it's yuvj420p(pc, bt470bg/unk [17:25:05 CEST] <Mandevil> But it looks gray, low contrast. [17:25:15 CEST] <Mandevil> Compared to what VLC plays from _source_ file. [17:26:01 CEST] <Mandevil> My quest is to understand what's how is this supposed to work. [17:27:38 CEST] <Mandevil> s/what's// [17:42:51 CEST] <Mandevil> Hm, various sources on the net tell me that I should setup my nvidia driver to use full range for video. [17:42:59 CEST] <Mandevil> When I do it, it sorta works. [17:43:46 CEST] <Mandevil> Actually no. [17:43:48 CEST] <Mandevil> It's still the same. [17:46:16 CEST] <Mandevil> Ha! Found it. [17:46:42 CEST] <Mandevil> For some reason I had picture processing switched on in VLC and it only worked on the MJPEG source (no idea why only on that...). [17:46:49 CEST] <Mandevil> Once switched off, it all looks the same. [18:44:44 CEST] <t4nk0361> Hello, where could i download a ffmpeg version with --enable-demuxer='flac,gif,image2,image2pipe,matroska' ? [18:44:53 CEST] <t4nk0361> for windows [18:45:12 CEST] <furq> https://ffmpeg.zeranoe.com/builds/ [18:45:45 CEST] <t4nk0361> thanks furq but the builds their have not this option by default enabled... [18:46:13 CEST] <furq> all of those demuxers are enabled by default [18:46:43 CEST] <t4nk0361> sure? https://ffmpeg.zeranoe.com/builds/readme/win64/static/ffmpeg-20160803-d3426… [18:47:08 CEST] <furq> yes [18:47:23 CEST] <furq> you don't need to explicitly enable them, they're enabled by default [18:47:40 CEST] <t4nk0361> i could not find them on the link above [18:48:11 CEST] <t4nk0361> i try to merge two mpg files together and get a "Invalid data found when processing input" error [18:48:23 CEST] <t4nk0361> i try to use this solution: https://trac.ffmpeg.org/ticket/4854 [18:52:15 CEST] <t4nk0361> does someone know a solution for that? [19:10:03 CEST] <kepstin> t4nk0361: the solution is to use an ffmpeg build that has the mpg demuxer enabled, just like the reply on the ticket says [19:10:13 CEST] <kepstin> the build you were using before has it explicitly disabled. [19:11:56 CEST] <t4nk0361> could someone create a build with the enabled one? [19:23:17 CEST] <Pxl_> whats up everyone [19:23:39 CEST] <thebombzen_> kepstin: I'm doing a follow-up of yesterday. I tried using -itsoffset with -ss and -vf subtitles and it produced a corrupt mkv file [19:24:25 CEST] <thebombzen_> that is, specifically ffmpeg -ss 15:00 -itsoffset 15:00 -i input.mkv -map 0:v -vf subtitles=input.mkv -c ffv1 output.mkv [19:24:42 CEST] <thebombzen_> however without -itsoffset it worked. [19:25:21 CEST] <thebombzen_> kepstin: we discussed this yesterday. i.e. it produced a corrupt file that was 1.8 kB despite being a 10second H.264 video [19:28:02 CEST] <thebombzen_> http://pastebin.com/0VkRMRCB [19:28:59 CEST] <thebombzen_> that's for -itsoffset. without it is this; http://pastebin.com/CG3At0xf [19:36:35 CEST] <thebombzen_> for the record, -copyts also didn't work [19:36:41 CEST] <thebombzen_> as in it produced the same kind of corrupt file. [19:37:01 CEST] <Pxl_> Having an issue with concat that part (~2 secs) of my first clip is getting cut off. any ideas? Videos are fine pre concat. http://pastebin.com/K4fgYDB7 [19:38:14 CEST] <thebombzen_> Pxl_: I literally just got scolded for not pasting the exact command and complete console output [19:38:22 CEST] <thebombzen_> so I'd recommend doing that [19:40:10 CEST] <Pxl_> I like to live life on the edge. lol. But that is the exact command and here is console http://pastebin.com/4M6PWRsT [19:41:39 CEST] <rmoorelxr> I'm getting a video feed from a DVR type device and I don't have direct access to its cameras. I get a stream of bytes that should be h264. Is it possible to pipe this output to ffmpeg for live streaming? [20:03:27 CEST] <kepstin> thebombzen_: huh, that's *really* strange, particularly since there's no apparent errors in the video encoder command output [20:04:45 CEST] <kepstin> thebombzen_: just for fun, have you tried with a different video codec (e.g. libx264)? [20:05:18 CEST] <thebombzen_> same problem [20:06:23 CEST] <kepstin> hmm. the last thing I can think of is that it's having issues with the not-starting-at-0 timestamps, try adding ",setpts=PTS-STARTPTS" to the end of your -vf string (after the subtitles filter) [20:06:42 CEST] <thebombzen_> kepstin: hoh [20:06:49 CEST] <thebombzen_> it appears to be a glitch in the mkv muxer [20:06:54 CEST] <thebombzen_> output.mp4 worked [20:07:02 CEST] <kepstin> yeah, it did look muxer-specific [20:07:34 CEST] <kepstin> you could also use 'nut' if it's just a temporary output file, then switch it to something else after :/ [20:07:49 CEST] <kepstin> (in theory, nut can hold anything ffmpeg can generate) [20:09:00 CEST] <thebombzen_> didn't know that. I use mkv for temp files. I'll keep that in mind and possibly submit a bug report [21:20:38 CEST] <thebombzen_> kepstin: using -vf setpts=PTS-STARTPTS also allows me to mux the matroska [21:20:59 CEST] <thebombzen_> also the matroska muxer errors with the pts that it doesn't like [21:22:39 CEST] <kepstin> yeah, I guess it just has problems with pts starting ad non-zero :/ [21:23:26 CEST] <kepstin> that setpts=... stuff just applies an offset to move everything to start at 0. (it will desync the audio unless you do the same thing there, I think) [21:25:11 CEST] <thebombzen_> apparently -vsync drop didn't work. I'll probably try the setpts stuff [21:25:37 CEST] <thebombzen_> whats' the practical difference between -itsoffset and -copyts? [21:51:54 CEST] <kepstin> -copyts passes through the timestamps from the input file completely untouched. -itsoffset runs the timestamps from the input file through ffmpeg's cleanup algorithm, then applies a simple offset to them afterwards. [21:52:40 CEST] <kepstin> (the cleanup algorithm, among other things, normalizes the timestamps to start at 0) [00:00:00 CEST] --- Fri Aug 5 2016

1 0

ffmpeg-devel.log.20160803
by burek 04 Aug '16

04 Aug '16

[00:19:36 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:ec234ccea4e5: mem: Order function prototypes semantically [00:54:17 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:708d9e9fbad4: Doxyfile: Set STRIP_FROM_INC_PATH to project root [03:20:56 CEST] <cone-228> ffmpeg 03Steven Robertson 07master:e1be80aa11cc: libavcodec/dnxhd: Enable 12-bit DNxHR support. [05:38:37 CEST] <cone-228> ffmpeg 03James Almer 07master:613c86299ffe: avcodec/h264dec: move ff_h264_ps_uninit prototype to h264_ps.h [06:36:00 CEST] <Timothy_Gu> jamrial: any more comments on the jni patch? [06:50:11 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:f29ffbc87d06: avutil/hash: Add more detailed Doxygen documentation [06:54:49 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:952c4cf7d0dd: rational: Extend Doxygen [06:54:50 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:a4d7a6d1dd51: mathematics: Extend and edit Doxygen [07:15:35 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:58c7bf789f0b: doxygen: Standardize root-level modules [07:31:31 CEST] <jamrial> Timothy_Gu: not really [07:31:51 CEST] <Timothy_Gu> jamrial: Okay I'll push it then. [07:32:20 CEST] <Timothy_Gu> and also, jni is only there in 3.1 [07:32:50 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:4e2a8c49202d: jni: Return ENOSYS on unsupported platforms [07:32:51 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:fd242479c666: mediacodec: Return ENOSYS on unsupported platforms [07:33:12 CEST] <cone-228> ffmpeg 03Timothy Gu 07release/3.1:327033d913f7: jni: Return ENOSYS on unsupported platforms [07:41:24 CEST] <cone-228> ffmpeg 03Burt P 07master:e0b8cba0580e: af_hdcd: add flags to AVOption defs [07:47:14 CEST] <cone-228> ffmpeg 03Patrick Felt 07master:e9659d1a0b77: decklink: Remove unneeded spaces in initializers [09:20:33 CEST] <mateo`_> Timothy_Gu: i'm late but thanks for the jni/mediacodec patches [09:21:22 CEST] <Timothy_Gu> mateo`_: Those patches were pretty trivial so I just pushed them. Hope you don't mind. [09:22:54 CEST] <mateo`_> Timothy_Gu: I don't (and I'm happy seeing people improving this part of the code) [09:24:48 CEST] <Timothy_Gu> Great [09:33:53 CEST] <mateo`_> Speaking of MediaCodec, I'll try to decouple the input/output parts and port to the new decoding API [09:39:00 CEST] <nevcairiel> mateo`_: you should be aware that there is no compat layer in place, so any decoder using the new API also requires user code to use the new API [09:40:44 CEST] <Timothy_Gu> nevcairiel: do you know of any restrictions that prevent ffmpeg.c from using the new api? [09:41:40 CEST] <mateo`_> nevcairiel: oh, I was hoping there was some compat layer (which would have done the buffering on the input packet in case the send_packet would have returned EAGAIN) [09:42:00 CEST] <nevcairiel> that could result in infinite buffering, so no [09:42:45 CEST] <nevcairiel> Timothy_Gu: iirc there were some bugs that prevented an easy migration because ffmpeg.c does weird things, but other then that someone just has to do it [09:43:12 CEST] <Timothy_Gu> okay, so just what I expected [10:46:51 CEST] <BtbN> Compn, Timothy_Gu, h264 with aac. cut into a lot of small flv segments by nginx-rtmp. Then combined again with ffmpeg concat demuxer. [15:21:25 CEST] <cone-578> ffmpeg 03Carl Eugen Hoyos 07master:8916ad956a1e: doc/filters: Fix option ranges for the sab filter. [16:14:29 CEST] <cone-578> ffmpeg 03Michael Niedermayer 07master:6cd9a8b67a95: ffplay: Fix invalid array index [16:14:30 CEST] <cone-578> ffmpeg 03Michael Niedermayer 07master:c5cc3b08e56f: avformat/oggdec: Fix integer overflow with invalid pts [17:22:38 CEST] <durandal_1707> kierank: you have atmos papers? [20:07:16 CEST] <cone-492> ffmpeg 03Michael Niedermayer 07master:b1ce80037276: avformat/teeproto: Support parsing protocol options [20:33:18 CEST] <cone-492> ffmpeg 03Paul B Mahol 07master:4be8ab70a628: avfilter/af_astats: extend bitdepth calculation [00:00:00 CEST] --- Thu Aug 4 2016

1 0

ffmpeg.log.20160803
by burek 04 Aug '16

04 Aug '16

[00:04:21 CEST] <yoan> Hey guys, I need to smooth the brightness of 500 jpeg pictures to create a clean timelapse, what option would you use? [00:05:22 CEST] <yoan> I found -morph that might do the job but I don't want to add new pictures, just adjust brightness of each picture according to the previous and the next ones [00:08:25 CEST] <yoan> Oops I wanted to join #imagemagick instead :) [00:09:14 CEST] <yoan> Anyway if you have advices to make nice (and smooth) timelapses from HD webcam pictures feel free to tell :) [05:04:30 CEST] <Legimet> Hi [05:05:39 CEST] <Legimet> I'm using eye tracking glasses which can be made to output raw H.264 packets [05:06:03 CEST] <Legimet> and I'm trying to figure out how I can combine these files into an mp4 [05:07:50 CEST] <Legimet> Each frame is in a separate file [05:09:01 CEST] <Legimet> my attempt to do this: http://pastebin.com/w6dHa0fR [05:09:17 CEST] <Legimet> any ideas? [06:06:37 CEST] <alyawn> I used git bisect to figure out where RTSP broke for me [06:07:05 CEST] <alyawn> this is the first 'bad' commit: http://pastebin.com/wJnnH21b [06:34:07 CEST] <alyawn> if I comment out this line https://github.com/FFmpeg/FFmpeg/blob/00e122bc0f2a4d867797f593770f9902f275b… it no longer crashes [10:09:30 CEST] <kdehl> Um. So what is cbk in the openh264 API? [12:59:48 CEST] <whald> hi! is there an alternative to av_read_frame which does not read full (video-) frames but gives back smaller units like h264 slices which can be fed to an decoder? [13:00:58 CEST] <BtbN> I don't think there is anything in lavc capable of doing so. Unless you add an actual hwaccel to lavc itself. [13:01:28 CEST] <whald> (i'm trying to get my latency down and also to spread out the cpu load, so i don't have to read a full frame and then decode it but rather have reading off the network and decoding interleaved) [13:02:00 CEST] <whald> BtbN, how does that relate to hwaccels? could you please elaborate? [13:02:22 CEST] <flux> whald, maybe you could look into how av_read_frame does its magic and work on that? [13:04:42 CEST] <whald> flux, seems i'll have to go that route. just thought someone here has already been there. :-) [13:05:04 CEST] <bencoh> you want a "framer" that outputs slices instead of frames, basically? [13:06:04 CEST] <whald> bencoh, i think so? [13:06:38 CEST] <BtbN> That's all internal to the lavc h264 decoder. Only the hwaccels get access to the slice data, as they are essentialy a part of it. [13:08:37 CEST] <whald> i'm not exactly sure how all this fits together, but maybe i don't actually need slices but rather "demuxed bitstream", and the h264 dec would figure out the slice bondaries or whatever itself anyway. true? [13:08:50 CEST] <BtbN> I'm not sure if you can register a new hwaccel from outside of lavc. But I'm quite sure the required functions and structures for that are private api. [13:09:12 CEST] <bencoh> what is "demuxed" bitstream? [13:09:36 CEST] <BtbN> Probably what falls out of lavformat? [13:09:43 CEST] <whald> bencoh, i mean the raw h264 bitstream, without the mpegts headers (i'm using mostly mpegts) [13:10:00 CEST] <bencoh> then you just need a regular demuxer/framer, but one that doesn't add latency [13:10:01 CEST] <BtbN> If your decoder is fine with that, sure. But most hardware accelerators aren't. [13:10:31 CEST] <bencoh> whald: how do you use avformat? feed it with buffers, or straight from network? [13:10:32 CEST] <BtbN> Might want to use the annexb bsf on top. [13:12:21 CEST] <whald> bencoh, i'm letting avformat do the network reading and then use av_read_frame and feed that to avcodec_send_packet followed by avcodec_receive_frame [13:12:50 CEST] <bencoh> yeah well then you already get a "huge" latency/buffering hit there [13:13:05 CEST] <whald> bencoh, my observation was that every send_packet is followed by an successfull receive_frame, which made me wonder how that can be. [13:13:14 CEST] <bencoh> I dont like advertising here but you might want to have a look at upipe.org and its mpegts demuxer / h264 framer at some point .... [13:15:10 CEST] <BtbN> And why not just use lavf? Sounds like what you want. It does not do anything to the bitstream though, it just demuxes it. [13:15:39 CEST] <BtbN> lavc takes the bitstream, and gives you decoded frames. [13:15:48 CEST] <BtbN> So if you want the bitstream, don't use it? [13:16:33 CEST] <whald> bencoh, i'm having a look. maybe you can tell me why i would get that "huge" latency hit? is there anything besides that the demuxer seems to buffer a full frame? [13:19:42 CEST] <bencoh> haven't had a look at that for a long time (>year), so ... [14:28:08 CEST] <jn_jn> hi all, :D can someone help me improve this command? http://pastebin.com/j15dDTsu [14:40:20 CEST] <biapy> hi [14:46:15 CEST] <jn_jn> hi [15:17:05 CEST] <DHE> jn_jn: so what's wrong with it? [15:17:26 CEST] <DHE> only thing that stands out is you didn't really specify a primary bitrate [15:54:28 CEST] <kdehl> So, um, you guys seem to know H.264 pretty well, so I'll just throw this question out here. I'm confused: One frame can contain several bitstreams which in turn consist of several NALs? [15:55:02 CEST] <kdehl> What is the difference between a bitstream and a NAL anyway? [15:55:26 CEST] <JEEB> bitstream is a single stream of things, usually a single stream (video, audio, subtitles)... [15:55:33 CEST] <JEEB> NAL is an AVC, HEVC thing [15:55:43 CEST] <JEEB> a packet, if to say so [15:56:21 CEST] <JEEB> you have parameter sets (setup packets in a way), SEI (extra info), VCL (Video Coding Layer) NALs [15:56:24 CEST] <JEEB> as some examples [15:56:31 CEST] <JEEB> last one actually contains compressed pictures [15:56:39 CEST] <kdehl> Aha. So a H.264 frame can contain both a video and an audio stream, for example? [15:56:42 CEST] <JEEB> no [15:56:49 CEST] <kdehl> Hm. Okay. [15:56:52 CEST] <JEEB> usually a bit stream is a single parse'able thing [15:57:02 CEST] <JEEB> either a container or a single stream that would otherwise be put into a container [15:57:05 CEST] <kdehl> Alright. [15:57:17 CEST] <JEEB> usually you mean a single stream's bit stream [15:58:07 CEST] <kdehl> Hm. Okay. [16:02:05 CEST] <kdehl> So a single frame does not comsist of several bitstreams? [16:02:10 CEST] <kdehl> *consist [16:03:17 CEST] <DHE> a container is something like MP4, MKV, and so on. it contains several streams (video, audio, alternative language audio, subtitles, and so on) [16:03:26 CEST] <kdehl> This is a code snippet that I have added (probably inaccurate) printfs to: [16:03:28 CEST] <kdehl> https://paste.kde.org/pygsc2r0r [16:03:35 CEST] <DHE> as a codec H264 has per-frame chunking for its own metadata divisions [16:03:46 CEST] <kdehl> DHE: Right. [16:18:32 CEST] <jn_jn> DHE, sry for my late, what you mean with specify a primary bitrate? [16:19:05 CEST] <DHE> jn_jn: -b:v parameter [16:21:12 CEST] <jn_jn> ok, but in this case, since i'm a noob in this kind of things, which one would be the right parameter? ty in advance [16:21:42 CEST] <DHE> if you're using -maxrate you're probably looking for cbr or constrained vbr, in which case I usually go with the same as maxrate [16:44:38 CEST] <doktorodd> Hi there! I am having a trouble using a pipe input. I am trying to receive an RTMP stream via netcat (nc -l -vvv -p 1935) and pipe it to ffmpeg (ffmpeg -v debug -y -analyzeduration 15M -probesize 15M -i pipe:0 out.mp4) - I see that my client connects but then all I get is `pipe:0: Invalid data found when processing input` [17:32:24 CEST] <cryptopsy> ffprobe is showing a field 'lyrics-None-eng' , is that the name of the field in the id3v2 spec? [17:33:04 CEST] <cryptopsy> i don't remember that being in the spec, i thought it was called 'Comment' [17:33:19 CEST] <cryptopsy> but its aligned with date, encoder, title, album, artist, and the other fields [17:34:14 CEST] <cryptopsy> i would like to edit such a field on other files, how can i do that? [18:38:47 CEST] <bp0> cryptopsy, try mp3tag? [18:40:48 CEST] <cryptopsy> i dont see the lyrics "tag" in ncmpcpp [18:41:00 CEST] <cryptopsy> and the comment tag in ncmpcpp is showing as empty, what is it? [18:43:05 CEST] <bp0> or similar tool specifically for that [18:46:38 CEST] <bp0> try something like exiftool or mutagen-inspect to dump and see the actual tag used [18:47:45 CEST] <cryptopsy> exiftool shows the field as 'User Defined Text' [18:47:55 CEST] <cryptopsy> what standard specifies this field? [18:51:51 CEST] <c_14> cryptopsy: http://id3.org/id3v2.3.0#Unsychronised_lyrics.2Ftext_transcription ? [18:52:08 CEST] <cryptopsy> id3v2, ok i thought it could have been an earlier version [18:52:38 CEST] <c_14> The formal standard is here http://id3.org/id3v2-00 [18:53:10 CEST] <c_14> v1 only has comment afaik [18:54:49 CEST] <cryptopsy> i did not know exif can look at mp3 files [19:08:38 CEST] <wallbroken> c_14, there is a better precision with 32bit ffmpeg or 64bit ffmpeg? [19:08:59 CEST] <c_14> Shouldn't matter (except maybe in asm) [19:09:37 CEST] <c_14> There may be a few locations where ffmpeg doesn't use fixed-length data types, but it shouldn't be important in those cases. [19:09:48 CEST] <wallbroken> c_14, somebody told me that 32bit has more precision [19:10:11 CEST] <c_14> Why would 32bit have more precision? [19:10:13 CEST] <c_14> There's less bits. [19:10:45 CEST] <wallbroken> <jkqxz> No, 32-bit has more precision. It uses the legacy x87 FPU which keeps things in 80-bit internally, while SSE gives you the normal 64-bit precision. [19:11:53 CEST] <c_14> internal-precision usually isn't that important since you'll lose most (if not all) of it during rounding to get back to 32 (or 64) bit [19:12:07 CEST] <c_14> Depends maybe on how many operations you can chain without rounding [19:13:06 CEST] <wallbroken> c_14, i need to chose between 32bit and 64 and i do not care about the encoding speed [19:14:14 CEST] <c_14> I don't think it'll matter, honestly. [19:15:04 CEST] <wallbroken> i need to choose, i do it with throwing a coin? [19:15:28 CEST] <c_14> Whatever's cheaper/easier for you. [19:15:31 CEST] <klaxa> 32 bit will probably be unsupported earlier than 64 bit (just a guess) [19:19:10 CEST] <wallbroken> unsupported by what? [19:19:37 CEST] <klaxa> linux distros maybe? i don't know [19:19:48 CEST] <DHE> you can still compile with -m32 [19:48:47 CEST] <CFS-MP3> Are the DVB subtitles known to use a larger font in ffmpeg than they do on a TV? I'm comparing the output from [0:v][0:s]overlay[v] which I thought would provide the exact image as on a TV but the font in this case is larger [19:56:29 CEST] <CFS-MP3> scratch the question, it cannot be a font issue since DVB is bitmap based... so I'm quite puzzled here [19:57:27 CEST] <klaxa> maybe your dvd player/bluray player/whatever scales differently than ffmpeg [20:01:57 CEST] <CFS-MP3> klaxa it's a TV :-) [20:02:39 CEST] <klaxa> then it falls in the category "whatever" [20:25:46 CEST] <dexstair> Hey guys, I'm trying to use ffmpeg to test out vaapi encoding. I installed ffmpeg with ./configure --enable-vaapi but when I try pass a video to ffmpeh I get an unrecognised option vaapi_device. am I missing something? [20:29:40 CEST] <kepstin> dexstair: you're probably just running the wrong ffmpeg executable (maybe an old system one rather than the one you just built) [20:30:58 CEST] <dexstair> ahh, where would the one I built be? I'm getting better at using 'nix, but I'm still a little clueless about this stuff. I was a little worried about building and installing ffmpeg, knowing that I already had one installed [20:32:35 CEST] <dexstair> the executable in /usr/local/bin gives me the same issues [20:35:03 CEST] <kepstin> dexstair: did you install the newly built one? [20:35:15 CEST] <dexstair> sudo make install, yup [20:35:25 CEST] <kepstin> you can try running it directly from the build directory (e.g. with a full path, or cd there and run ./ffmpeg) [20:35:35 CEST] <dexstair> I tried that [20:36:30 CEST] <kepstin> hmm. where did you get the ffmpeg source? is it a 3.1 (or 3.1.1) tarball? or git? [20:36:30 CEST] <dexstair> my only steps for installing were to cd into the newer ffmpeg directory ./configure --enable-vaapi make sudo make install [20:36:46 CEST] <jkqxz> Did you actually build the lastest version? (Ideally from straight from git, though 3.1.1 is also new enough.) [20:37:08 CEST] <dexstair> I'm using Fedora 24, have I missed out building an encoder? [20:37:18 CEST] <dexstair> 3.1.1 is what's installed [20:38:06 CEST] <dexstair> straight from the ffmpeg website. [20:38:16 CEST] <dexstair> are there any logs I can show you? [20:38:28 CEST] <kepstin> hmm. I wonder if you're missing some dependencies, and --enable-vaapi silently ignored that rather than caused configure to fail [20:38:40 CEST] <kepstin> dexstair: pastebin the output from ./configure --enable-vaapi maybe? [20:39:24 CEST] <jkqxz> The configure output should show "h264_vaapi" in the encoders section. If it doesn't, you can look in config.log to find out why not. [20:41:49 CEST] <dexstair> http://pastebin.com/Vkb685Mi I'm getting fairly proficient in the cli. amusing myself with stdin stdout. anywho, here's the log. [20:43:46 CEST] <kepstin> yeah, it didn't enable any of the hwaccels there [20:44:00 CEST] <kepstin> you're probably missing the vaapi system libraries [20:44:34 CEST] <kepstin> (imo, that really should be an error if you use --enable-vaapi, but ffmpeg's configure script is... rather nonstandard) [20:44:54 CEST] <dexstair> http://pastebin.com/g7vJtaXJ config.log [20:45:44 CEST] <dexstair> I have the intel drivers installed and I'm able to do a rudimentary vaapi encode within transmageddon [20:47:01 CEST] <kepstin> you said you're on fedora, right? try installing the 'libva-devel' package [20:47:10 CEST] <dexstair> cheers [20:48:27 CEST] <dexstair> installed, I'll try building again [20:49:50 CEST] <dexstair> I can see vaapi encoders listed in the ./configure output [21:13:50 CEST] <dexstair> vaapi encoding is working, but 1080p content still uses a fair amount of cpu usage [21:14:07 CEST] <dexstair> the one error/warning I get is mp4 @ 0x2f40fa0] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead. [21:16:07 CEST] <jkqxz> What are you using to do the decode? A full hardware transcode will run with close to zero CPU use, but if the decode isn't in hardware as well then you will quickly be constrained by that. [21:16:55 CEST] <dexstair> ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i /mnt/f892940f-33f7-47ae-9fd5-140c53b4b697/Videos/Anime/Paranoia\ Agent\[BDRIP\]\[1080P\]\[H264\(Hi10P\)_FLAC\]\ \(with\ a4e\ subs\)/\[Paranoia\ Agent\]\[01\]\[BDRIP\]\[1080P\]\[H264\(Hi10P\)_FLAC\]\ \(with\ a4e\ subs\).mkv -an -vf 'format=nv12|vaapi,hwupload' -c:v h264_vaapi output.mp4 [21:17:16 CEST] <kepstin> dexstair: vaapi decoder doesn't support 10bit, so you're out of luck there :/ [21:17:23 CEST] <kepstin> (it's a hardware limitation) [21:17:33 CEST] <dexstair> Haha, okay :) makes sense. [21:18:22 CEST] <dexstair> Thank you for all the help :D I'm now up and running, and you're all incredibly helpful people. [21:18:54 CEST] <kepstin> keep in mind that the hardware h264 encoders are generally pretty fast, but not particularly good efficiency. In most cases (unless you're really cpu/speed limited for some reason), x264 is a better option. [21:20:02 CEST] <dexstair> I have a bunch of old media that I need to re-encode. I brought my haswell for QS/VAAPI capability due to it being very very energy efficient. [21:43:32 CEST] <thebombzen_> okay so I've asked this question many times and afaik I've never gotten an answer to it [21:44:52 CEST] <thebombzen_> when you use -vf subtitles=subsfile.mkv, if you use fastseeking (i.e. -ss before -i), then it'll start the subtitles at the beginning of the stream. this means if you use -ss 2:00, the video will start two minutes in, but the subtitles will be the ones that would display at 0:00 if you were to play the video [21:45:28 CEST] <kepstin> right, because the seeking is per-input, so it only applies to the video, not to the separate input stream used to read the subtitles. [21:45:36 CEST] <thebombzen_> however, if you use slowseeking (-ss after -i), then it'll work as expected. [21:46:00 CEST] <thebombzen_> slowseeking, has the problem that it's slow though. Ideally, there'd be some kind of -ss option in -vf subtitles, but I have never seen it. [21:46:13 CEST] <kepstin> ah, that's because of interesting quirks with how seeking handles timestamps [21:46:49 CEST] <thebombzen_> is there some kind of -vsync option to allow this to work with fastseeking? [21:46:59 CEST] <kepstin> I do agree that the 'subtitles' filter could use a seek or timestamp offset option [21:47:42 CEST] <kepstin> you can probably get it to work by using the '-copyts' input option, or using the '-itsoffset NN' option with the same value as your '-ss' [21:48:29 CEST] <thebombzen_> before I run something wrong and say "it doesn't work," do you mean something like: ffmpeg -ss 2:00 -copyts -i file.mkv -vf subtitles=file.mkv <output>? [21:49:37 CEST] <kepstin> yes, or 'ffmpeg -ss 120 -itsoffset 120 -i [...]' (which i think might be a bit better, since -copyts bypasses ffmpeg's cleanup processing [21:49:48 CEST] <kepstin> ) [21:51:12 CEST] <thebombzen_> would -vsync passthrough be a "cleaner" way to not regenerate TS? [21:52:43 CEST] <kepstin> I think it's orthogonal, since the 'start at zero' is applied before the vsync option is? [21:52:46 CEST] <kepstin> not sure [21:52:52 CEST] <kepstin> would have to test and see :/ [22:11:42 CEST] <CFS-MP3> Is this the correct way to use ref2scale? [0:s][0:v]scale2ref[s][v];[v][s]overlay[vf] [22:11:49 CEST] <CFS-MP3> scale2ref I mean :-) [22:12:09 CEST] <CFS-MP3> All other variants seems to cause problems with the output stream, but this one on the other hand does nothing [22:21:24 CEST] <thebombzen_> kepstin: okay so I tried -itsoffset and it created a corrupt file [22:21:37 CEST] <thebombzen_> like an mkv that was supposed to 15 seconds but was 1.8 kB in size [22:22:05 CEST] <kepstin> weird. I guess the output muxer didn't like the timestamps not starting at 0. [22:22:19 CEST] <kepstin> pastebin the (complete) ffmpeg command line and output please? [22:25:10 CEST] <thebombzen_> CFS-MP3: does scale2ref have two outputs? I see that it does in the docs but that seems wrong [22:25:32 CEST] <thebombzen_> also it says it uses the reference video as the basis. Try putting [0:v] as the input first [22:46:34 CEST] <codespells> Need to make a 1min sample of my source video. Can I crop a video to 1 min and -c:a -c:v the codecs? [22:47:27 CEST] <furq> yes but it probably won't end up at exactly one minute [22:48:07 CEST] <furq> if you're copying streams then you can only cut on keyframes [22:48:39 CEST] <codespells> thats ok. Just need a short sample that I am using with AviSynth with. [22:49:04 CEST] <Kadigan> Then cut it a bit wider than 1min (slack on both ends) and You'll be fine. [22:50:35 CEST] <codespells> So how would I go about doing that? ffmpeg -i xxx -c copy xxx.avi but not sure about how to crop? [22:50:56 CEST] <furq> -ss 01:23:45 -i foo -t 60 [22:51:10 CEST] <furq> or put -ss after -i for slower/more accurate seeking [22:51:18 CEST] <codespells> thx furq. [22:51:59 CEST] <Kadigan> -ss can also seek to specific frames, though it takes timecode as input (so fractionals), just for future reference [22:52:49 CEST] <codespells> have a feeling the word crop is not what I am doing? Would would I google for this? [22:53:06 CEST] <Kadigan> No, cropping is used for cutting a part of the frame [22:53:11 CEST] <Kadigan> (so smaller subset of an image) [22:53:26 CEST] <Kadigan> You want cutting, I assume, or even maybe extracting. [22:53:36 CEST] <Kadigan> (try 'split' as well) [22:53:44 CEST] <Kadigan> What other issue are You having? [22:54:17 CEST] <Kadigan> (also, s/fractionals/fractions) [22:55:08 CEST] <codespells> well for one to get MT working with temporal denosing without a fat mem leak =P [22:55:40 CEST] <Kadigan> I'm sorry, MT? [22:55:42 CEST] <furq> avisynth has a range selection function doesn't it [22:55:44 CEST] <codespells> QTGMC stuff and my crappy plugin. [22:55:50 CEST] <Kadigan> Ah, probably motion tracking? [22:55:54 CEST] <furq> multithreaded avisynth [22:55:58 CEST] <Kadigan> Ahhh... [22:56:02 CEST] <codespells> yeah. [22:56:06 CEST] <furq> fwiw i had much better luck with vapoursynth [22:56:10 CEST] <Kadigan> Yeah, not my area of expertise :D [22:56:11 CEST] <furq> it's a bit slower but also less likely to segfault [22:56:21 CEST] <furq> which is nice when your encodes take 8+ hours [22:56:47 CEST] <codespells> this is what I am toying with http://www.coertvonk.com/technology/videoediting/restoring-video8-hi8-10849 [22:57:14 CEST] <codespells> Hear good stuff about vapoursynth. Gonna give it a try. [22:57:21 CEST] <furq> you'd have to rewrite that script then i guess [22:57:51 CEST] <furq> although at least part of that is redundant with ffmpeg anyway [22:58:14 CEST] <codespells> yeah tons of it is redundant. All the calls to the plugins etc [22:58:35 CEST] <furq> specifically the loadsource stuff isn't needed [22:59:26 CEST] <furq> and qtgmc can do decent denoising for you [23:02:09 CEST] <codespells> Using QTGMC for its really nice deinterlace and a plugin that I have tried to reverse engineer for the noise called neat. Problem is that plugin is crazy advanced and the "code" I got is really hard to read [23:02:45 CEST] <codespells> Not cracking it. Just want to see what they did with wavelets [00:00:00 CEST] --- Thu Aug 4 2016

1 0

ffmpeg-devel.log.20160802
by burek 03 Aug '16

03 Aug '16

[00:02:23 CEST] <cone-764> ffmpeg 03Burt P 07master:d574e22659bd: af_hdcd: Process stereo channels together, fix #5727 [00:02:24 CEST] <cone-764> ffmpeg 03Burt P 07master:bea17a3d5705: af_hdcd: Warn if there is any resampling or format conversion in the link chain [00:13:54 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:996f13413b04: h264: fix warnings in fill_filter_caches_inter() [00:13:55 CEST] <cone-764> ffmpeg 03James Almer 07master:01f0598b18e9: Merge commit '996f13413b0415097e2a184d161462ffb3ceb647' [00:15:31 CEST] <jamrial> ubitux: there, reduced the h264 queue a bit :p [02:09:18 CEST] <sanmarcos> anybody have experiecne with Openh264 here? [02:35:57 CEST] <Compn> there is a patch to include an openh264 lib in ffmpeg on the ml [02:36:13 CEST] <Compn> sanmarcos : is that what you are asking about ? [02:55:42 CEST] <RiCON> openh264 can be included in ffmpeg already [02:55:50 CEST] <RiCON> the problem was including the git version [03:03:18 CEST] <rcombs> atomnuker: how's AAC perf work going? [10:15:36 CEST] <atomnuker> rcombs: 90% done for the past 3 months :( [10:15:50 CEST] <rcombs> what's holding back that last 10%? [12:03:59 CEST] <Bitterblue> Does the timestamp of a blank subtitle (num_rects=0) in a PGS stream signify the last point where the previous (valid) subtitle should be displayed, or the first point where it shouldn't be? [12:18:01 CEST] <michaelni> Bitterblue, this is a good question, iam not sure this was considered before but to me the first point of non display seems more logic to me [12:20:01 CEST] <Bitterblue> Indeed. [12:20:39 CEST] <Bitterblue> On the other hand, Suprip thinks it's the former. [12:26:58 CEST] <Bitterblue> There is no public specification, is there? [12:32:12 CEST] <robUx4> nevcairiel: you might want to check this https://mailman.videolan.org/pipermail/vlc-commits/2016-August/036684.html [12:32:41 CEST] <robUx4> it's code borrowed for ffmpeg_dxva2 [12:33:16 CEST] <robUx4> I have a HEVC 4K file that would trigger a crash without this [12:33:39 CEST] <robUx4> and it crashed at the first BeginFrame() call [12:35:35 CEST] <robUx4> I noticed it by increasing the number of threads used (I know, it's bad) which in turn increases the number of buffers allocated [12:36:17 CEST] <robUx4> there was a limit where the CreateSurface would fail with OutfMemory [12:36:44 CEST] <robUx4> but with -1 that amount the CreateSurface works but BeginFrame crashes [12:37:18 CEST] <robUx4> so I assume it's the internal +1 of CreateSurface that is actually meant to be internal [12:39:55 CEST] <robUx4> if you want the file https://drive.google.com/file/d/0B-WXvZryGokkX3hVaDdMMlhHcFE/view?usp=shari… [12:40:11 CEST] <robUx4> (I had to remux the .ts to .mkv so it actually works in VLC) [12:40:37 CEST] <nevcairiel> the method is clearly documented as creating one front buffer and N backbuffers, i can only assume they do something else quirky [12:40:56 CEST] <nevcairiel> their code is entirely unrelated to ffmpeg_dxva2.c [12:41:42 CEST] <nevcairiel> also the rar is password protected [12:43:42 CEST] <robUx4> "hevc10b" [12:46:42 CEST] <nevcairiel> not sure where the notion comes from that its an "internal thing", the msdn docs are quite clear on how the function works [12:46:45 CEST] <robUx4> it might try to allocate an extra buffer internally, but there's no memory available [12:47:09 CEST] <robUx4> (there's plenty but it may be a per process/decoder limit) [12:47:57 CEST] <robUx4> at least that's the way I managed to get rid of the crash [12:48:20 CEST] <robUx4> by not using the decoder if the allocation would fail with the +1 [12:49:15 CEST] <robUx4> https://msdn.microsoft.com/en-us/library/windows/desktop/ms696227(v=vs.85).… [12:49:39 CEST] <robUx4> I'm not sure I understand the caller is supposed to provide N rather than N - 1 [12:50:18 CEST] <nevcairiel> all the docs say is that it creates "BackBuffers + 1" surfaces, so you can translate that in code anyway you like [12:50:47 CEST] <robUx4> it's ambiguous [12:51:20 CEST] <robUx4> so I prefer the call that doesn't crash in tricky conditions [12:51:25 CEST] <nevcairiel> maybe due to an error condition you accidentally called it with sys->surface_count = 0, which resulted in passing -1 to the function? [12:51:47 CEST] <robUx4> no it's 24 that fails [12:52:13 CEST] <robUx4> we were passing 23 and it would crash on BeginFrame() [12:52:16 CEST] <nevcairiel> anyway i've never had any issue reports of such crashes [12:52:39 CEST] <robUx4> how many people use HEVC 4K with dvxa2 ? [12:53:06 CEST] <robUx4> also, they might use it the way you say it should: no threading [12:53:20 CEST] <robUx4> so they'd never reach 24 [12:53:30 CEST] <robUx4> with single thread it would be 20 [12:53:43 CEST] <cone-228> ffmpeg 03Petru Rares Sincraian 07master:7be021d9495b: fate: add test for tremolo filter [12:53:44 CEST] <cone-228> ffmpeg 03Lucas Cooper 07master:3d7ea1d39e09: doc/filters: Add stats_version documentation to PSNR filter [12:54:10 CEST] <robUx4> only with my local VLC build where I force multithread (to test issues) has the issue [12:54:58 CEST] <nevcairiel> i actually use 24 in my own software for performance improvements, never had issues [12:55:14 CEST] <robUx4> you pass 24 or 23 ? [12:55:20 CEST] <nevcairiel> 23 of course [12:55:22 CEST] <nevcairiel> 24 surfaces [12:55:38 CEST] <robUx4> maybe it depends on the hardware/driver [12:56:13 CEST] <robUx4> I don't know why it says OutOfMemory with 24, the 950 GTX card has 2 GB of RAM [12:56:34 CEST] <nevcairiel> this has been tested on a 2gb 960 at least and not crashed there [12:56:42 CEST] <robUx4> note: I allocate P010 surfaces, not NV12 [12:58:26 CEST] <robUx4> also do you mark the front buffer somewhere or tell DXVA2 which buffer is the front ? [12:58:41 CEST] <nevcairiel> its really all the same buffer type [12:58:47 CEST] <robUx4> or keep one buffer from the array for the libavcodec code ? [12:58:50 CEST] <nevcairiel> the allocation function just splits that somehow [12:59:23 CEST] <robUx4> otherwise if you pass N-1 there's a buffer that's allocated but noone knows about it [12:59:33 CEST] <nevcairiel> it gets passed into the output surface array [12:59:53 CEST] <nevcairiel> thats why the docs say it needs to be N+1 in size [13:02:18 CEST] <robUx4> the "output surface array" is in the DXVA API ? [13:02:27 CEST] <nevcairiel> from CreateSurface [13:02:46 CEST] <nevcairiel> you pass it an array it writes the surfaces into, it writes N+1 surfaces into this array [13:03:02 CEST] <nevcairiel> The address of an array of IDirect3DSurface9 pointers allocated by the caller. The size of the array must be 1 + BackBuffers (enough for the back buffers plus one front buffer). [13:10:20 CEST] <robUx4> indeed if I call CreateSurface() with 1, it fills 2 surfaces in the array [13:13:09 CEST] <nevcairiel> hence where the -1 came from [13:13:32 CEST] <nevcairiel> if yo uwant 2 surfaces, pass it a 1 [13:14:24 CEST] <nevcairiel> why it crashes for you i cannot answer, maybe its related to the multithreading on other levels and not just the surface count [13:17:04 CEST] <robUx4> no, I verified with and without mulithreading it's the same thread that does the BeginFrame call, nothing else is called before [13:17:36 CEST] <robUx4> that's why I found it odd that it would know how many threads are used when in fact only 1 is used [13:31:55 CEST] <robUx4> nevcairiel: different workaround https://patches.videolan.org/patch/14186/ [13:32:55 CEST] <nevcairiel> if anything that sounds like an issue in the driver not handling an oom condition properly somewhere [13:33:04 CEST] <nevcairiel> so you just test for some extra free memory [13:34:03 CEST] <robUx4> yes, it's a "workaround" as I know it's likely to crash later [13:34:59 CEST] <robUx4> a crash on BeginFrame() sounds like a bug in the driver anyway [13:39:39 CEST] <robUx4> that's NVIDIA and on Intel I get a crash on another API call... [16:22:57 CEST] <cone-228> ffmpeg 03Carl Eugen Hoyos 07master:8ee113afa138: lavf/rmdec: Do not return EIO on EOF. [16:45:23 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:fbe22355b7d4: build: Make API documentation depend on config.mak [16:51:04 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:19d7098c9e7b: avutil: Group hash functions separately in Doxygen [16:51:05 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:0a7a4e33f303: avutil: Add detailed Doxygen description to a few hashes [16:51:06 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:39211cb9aab3: murmur3: Add Doxygen documentation [17:08:48 CEST] <cone-228> ffmpeg 03Carl Eugen Hoyos 07master:5aede0512021: lavu/hwcontext_vaapi: Fix compilation if VA_FOURCC_ABGR is not defined. [18:01:25 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:1fcf24321625: mathematics: Make function prototypes identical to definitions [18:41:23 CEST] <cone-228> ffmpeg 03Paul B Mahol 07master:82b84c71b009: avcodec/alacenc: allocate bigger packets [19:41:22 CEST] <BtbN> Best feature of patchwork: Being able to download a patch. Getting a patch out of my mails was so annoying. [19:44:08 CEST] <bp0> indeed [19:44:16 CEST] <JEEB> aye [19:44:38 CEST] <JEEB> are they curl'able btw? I hadn't tried that out yet [19:44:43 CEST] <bp0> yes [19:45:08 CEST] <bp0> both mbox and raw [19:45:15 CEST] <JEEB> najs [19:46:58 CEST] <bp0> 2nd best feature (imo) is the message id is right there at the top for git send-email --in-reply-to [19:47:20 CEST] <JEEB> I think the mail archives also had that? [19:47:49 CEST] <BtbN> Is there a problem with super long passwords with patchwork? [19:48:04 CEST] <BtbN> registered with a 32 character one, and can't login with it now. [19:49:04 CEST] <bp0> I used a very long one, without problem [19:50:22 CEST] <bp0> JEEB, if it did, I never knew it [19:51:20 CEST] <BtbN> guess something went wrong with my Password Manager then. Resetting it to the same exact password worked fine. [20:18:58 CEST] <durandal_170> j-b: you give money for doing new decoders in lavc? [20:22:04 CEST] <cone-228> ffmpeg 03LoRd_MuldeR 07master:8ab200fb8ade: avfilter/af_dynaudnorm: improve pre-filling code [20:26:13 CEST] <cone-228> ffmpeg 03Michael Niedermayer 07master:35e7fc60301e: avformat/tee: Factor parse_slave_options() out [21:16:32 CEST] <cone-228> ffmpeg 03James Almer 07master:7a9a8afc8253: avcodec/ttaenc: split off hybrid filter processing as ttaencdsp [21:16:33 CEST] <cone-228> ffmpeg 03James Almer 07master:efc9d5c4bc40: x86/ttaenc: add ff_ttaenc_filter_process_{ssse3,sse4} [22:01:59 CEST] <cone-228> ffmpeg 03Patrick Felt 07master:5469293758c9: cosmetics: Correct comments in decklink_dec [22:22:50 CEST] <BtbN> Anyone happens to have an idea about what youtube is doing with its video processing? I uploaded a bunch of videos recently, all from the exact same source, just cut. Some of them are 1080p60 now, others 1080p50. The source was at a consistent 60 fps. [22:37:19 CEST] <Compn> BtbN : what codec ? [22:37:34 CEST] <Compn> what tool did you use to cut them? [22:37:39 CEST] <Compn> let me guess... prores and fcp ? [22:40:33 CEST] <Timothy_Gu> 13:37 < Compn> BtbN : what codec ? [22:40:34 CEST] <Timothy_Gu> 13:37 < Compn> what tool did you use to cut them? [22:40:34 CEST] <Timothy_Gu> 13:37 < Compn> let me guess... prores and fcp ? [22:41:30 CEST] <Compn> thanks Timothy_Gu, you are good people. [22:45:06 CEST] <Timothy_Gu> welcome [23:25:57 CEST] <cone-228> ffmpeg 03Carl Eugen Hoyos 07release/3.1:9a345b235fbd: lavu/hwcontext_vaapi: Fix compilation if VA_FOURCC_ABGR is not defined. [00:00:00 CEST] --- Wed Aug 3 2016

1 0

ffmpeg.log.20160802
by burek 03 Aug '16

03 Aug '16

[00:08:07 CEST] <wallbroken> jkqxz, so, i do it with 32bit version? [02:18:47 CEST] <ycon_> Hi all, I need to re-encode my audio of my mp4 video to be Mp3 (as its the only format my vid supports) [02:19:15 CEST] <ycon_> I ran this- but it didn't work ffmpeg -i Video.mpt -acodec libmp3lame audioreformat.mp4 [02:19:23 CEST] <ycon_> *ffmpeg -i Video.mp4 -acodec libmp3lame audioreformat.mp4 [02:20:50 CEST] <furq> what does "didn't work" mean [02:21:05 CEST] <furq> also you probably want -c:v copy or else it'll reencode the video [02:27:34 CEST] <ycon_> furq: didnt work, as in it created a file that was cut short of the total time [02:27:49 CEST] <ycon_> May have been my computer stuffing up ha. So where do I use -c:v copy? LIke this? [02:27:50 CEST] <ycon_> ffmpeg -i Slide_Downstairs_2.m4v -c:v copy -acodec libmp3lame mp3.mp4 [02:27:56 CEST] <furq> yes [04:01:03 CEST] <sauh97> Hi! I'm converting videos to play on my phone, and I'd like to scale and crop them in such a way to fix my screen as best as possible. [04:02:14 CEST] <sauh97> I'm using "scale=w=427:h=240:force_original_aspect_ratio=decrease" but I'd like ffmpeg to crop the video in such a way so there aren't any 'black bars' when I play it back on my phone [04:16:08 CEST] <sauh97> Found solution: -vf "crop=in_h*16/9:in_h,scale=-1:240" [04:16:13 CEST] <sauh97> Thanks anyhow :) [04:17:21 CEST] <xpack> I keep getting errors when compiling ffmpeg following the guide [04:17:38 CEST] <xpack> ffmpeg/libavcodec/x86/dirac_dwt_init.c:140: undefined reference to `ff_vertical_compose53iL0_sse2' [04:17:53 CEST] <xpack> collect2: error: ld returned 1 exit status make: *** [ffmpeg_g] Error 1 [04:20:39 CEST] <furq> xpack: build with --disable-decoder=dirac [04:20:57 CEST] <furq> also maybe submit a bug report, this is the second time i've seen this reported [04:43:24 CEST] <xpack> Thanks @furq that fixed the compilation error [09:20:45 CEST] <seanrdev> I am attempting to merge multiple avi video files. I keep getting timestamp errors. Any idea where to start looking? [10:53:49 CEST] <spirou> good morning [10:54:47 CEST] <Fjorgynn> /me is here [11:00:26 CEST] <spirou> if I want to save a graphical subtile to a separate file what shall I cal the out filenamne? [11:01:18 CEST] <spirou> ffprobe don't really list it it though (but perhaps that is "Stream #0:0[0x1bf]: Data: dvd_nav_packet"?), vlc say "DVD Subtitles (spu )" [11:03:25 CEST] <spirou> the film is in a .iso file (file says "UDF filesystem data (version 1.5)", mediainfo says "Format: ISO 9660") [14:50:00 CEST] <kdehl> What is IDC (or idc?) in H.264? I see it everywhere, but I can't find a description of it. [14:57:43 CEST] <bencoh> kdehl: IDR? [14:57:46 CEST] <jkqxz> As in profile_idc or chroma_format_idc? I don't know what it stands for, but it marks syntax elements in the bitstream which take more than two discrete values. (Elements taking only two values are "flag", elements with ranges don't get a suffix.) [14:57:50 CEST] <bencoh> or IDC? [14:59:43 CEST] <kdehl> Yeah, I meant idc. [14:59:54 CEST] <kdehl> jkqxz: Alright, thanks. [15:00:09 CEST] <kdehl> Weird that you can't find what it stands for though. [15:00:24 CEST] <kdehl> At least I know what it means now. [15:23:46 CEST] <zuloyd> hi [15:24:56 CEST] <zuloyd> is it possible to distribute encoding of a live stream onto multiple servers in the network? [15:26:18 CEST] <DHE> yes, but you might want to use something better suited than ffmpeg. an outage will likely jam up the whole system [15:26:29 CEST] <zuloyd> any recommendations? [16:03:02 CEST] <hero_biz> hi guys. [16:03:25 CEST] <hero_biz> I have a small question which answer is probably no, but just want to make sure. [16:04:11 CEST] <hero_biz> if we encode an mkv with ffmpeg which has ordered chapters, is it possible to merges chapters while encoding or not? [16:17:26 CEST] <c_14> no, ffmpeg does not (as of yet) support ordered chapters [16:20:05 CEST] <hero_biz> reordering is super irritating. [16:21:48 CEST] <c_14> if mpv (which has encoding support) does everything you want you could try using that. It has it's own mkv demuxer (which supports ordered chapters) [16:23:54 CEST] <hero_biz> I need a console encoder. I think think I could use mpv [16:25:57 CEST] <furq> that seems like a weird thing for mpv to support [16:26:02 CEST] <furq> are people pining for the good old days of mencoder [16:26:51 CEST] <hero_biz> hm.. [16:27:28 CEST] <hero_biz> I still don't know why process that I use for reordering chapters will fails sometimes. [16:28:02 CEST] <hero_biz> I encode all parts with same settings and add I frames to main video where I should place chapters. [16:28:18 CEST] <hero_biz> then I split main video on those I frames. [16:28:34 CEST] <hero_biz> and finally merges splits and chapter files together. [16:28:55 CEST] <hero_biz> I think think process should not mess up things. [16:29:58 CEST] Action: hero_biz thinks maybe a faulty subtitle mess up everything???? [16:45:40 CEST] <kdehl> Um. Probably a silly question, but about the Emulation Prevention Bytes in, H.264. How does a decoder know that it _is_ an emulation prevention byte, and not just valid encoded video data? [17:22:41 CEST] <PhoenixBR> Hi there guys! [17:26:52 CEST] <PhoenixBR> A simple question: which ffmpeg command can I use to transform a .mp4 video (1280x720, 9990kbps, 30fps) to a .mp4 video with the half of this size and bitrate, reducing the size of the file? [17:50:52 CEST] <intracube> PhoenixBR: do you mean half resolution? [17:55:23 CEST] <PhoenixBR> intracube: yeah, could be [17:55:32 CEST] <intracube> ffmpeg -i input.mp4 -b:v 5000k output.mp4 [17:56:06 CEST] <PhoenixBR> intracube: and the half size? [17:56:10 CEST] <intracube> ffmpeg -i intput.mp4 -b:v 3000k -vf scale=640:360 output.mp4 [17:56:24 CEST] <intracube> you can get away with a lower bitrate since it'd be quarter the area [17:56:28 CEST] <PhoenixBR> intracube: perfect! let me try [17:56:48 CEST] <BtbN> 3kbps is quite excessive for 360p [17:56:56 CEST] <BtbN> 3000 [17:57:35 CEST] <PhoenixBR> BtbN: which resolution do I have try? [17:57:37 CEST] <intracube> depends what quality you're going for, but yeah, assuming h.264, it could be 2000k and still fairly good quality [17:59:51 CEST] <intracube> the audio will also be re-encoded. instead you might want to copy from the original file as-is [18:00:14 CEST] <intracube> ffmpeg -i intput.mp4 -c:a copy -b:v 2000k -vf scale=640:360 output.mp4 [18:15:55 CEST] <PhoenixBR> intracube BtbN thanks guys! [18:16:01 CEST] <intracube> np [18:16:02 CEST] <PhoenixBR> it worked! [18:17:52 CEST] <PhoenixBR> A more advanced question: I generated a green screen video: ffmpeg -f lavfi -i color=green:s=704x576:r=24000/1001 -f lavfi -i anullsrc -ac 2 -t 1 greenscreen.ts [18:18:55 CEST] <PhoenixBR> then I concatenated with a .ts video like this: ffmpeg -i greenscreen.avi -i 1.avi -filter_complex "[0:v:0] [1:v:0] [0:v:0] concat=n=3:v=1 [v]" -map "[v]" -pix_fmt yuv420p -vcodec rawvideo output.avi [18:19:17 CEST] <PhoenixBR> ops, sorry, .ts version: ffmpeg -i greenscreen.ts -i 1.ts -filter_complex "[0:v:0] [1:v:0] [0:v:0] concat=n=3:v=1 [v]" -map "[v]" -pix_fmt yuv420p -vcodec rawvideo output.ts [18:20:00 CEST] <PhoenixBR> that means, 1 second of the greenscreen video before and after the original video 1.ts [18:22:10 CEST] <PhoenixBR> the output.ts video do not work [18:22:35 CEST] <PhoenixBR> unless i take off the -vcodec rawvideo parameter [18:23:13 CEST] <PhoenixBR> *remove this parameter [18:23:22 CEST] <PhoenixBR> What I am doing wrong? [18:24:39 CEST] <PhoenixBR> But I really need the original video quality in the output video [18:24:47 CEST] <intracube> does .ts stream format support raw video? [18:24:50 CEST] <intracube> I'm not familiar with the filter_complex syntax [18:27:15 CEST] <Kadigan> Here's a question: I have a video that's exactly 45 seconds long. I run 'ffmpeg -i video.mov -c copy -ss 15.00 -vframes 375 middle15s.mov' and everything is fine for video, but I get a little bit of the audio from beyond the 375 frames. [18:27:24 CEST] <intracube> I was going to suggest using -c:v copy to copy over the raw stream, but I'm not sure if that works with the concat option [18:27:29 CEST] <Kadigan> This happens when I specify v/a codecs as well. (the rate is 25fps) Ideas? [18:28:45 CEST] <Kadigan> (and I know I get audio 'from beyond', because the audio lasts for 365 frames (10f silence, 365f audio), so even if it 'overshot' by a frame or two I should be in the 10f of silence, yet I get about 15f of audio from the next segment, ie. 375 video frames + 390 audio frames) [18:35:42 CEST] <PhoenixBR> intracube: another way to connect this .ts videos? [18:36:10 CEST] <intracube> PhoenixBR: I never found an easy way with ffmpeg [18:37:01 CEST] <PhoenixBR> intracube: do you recommend another toll? [18:37:07 CEST] <PhoenixBR> tool* [18:38:01 CEST] <intracube> I can't think of one atm [18:38:39 CEST] <PhoenixBR> intracube: it's ok, thanks! [18:42:28 CEST] <intracube> PhoenixBR: just tried the first command here and it seems to work: https://trac.ffmpeg.org/wiki/Concatenate#demuxer [18:43:15 CEST] <intracube> I didn't add the full folder structure to the file list since it complained about an 'unsafe filename' [18:43:38 CEST] <intracube> file 'clip_01.ts' [18:43:43 CEST] <intracube> file 'clip_02.ts' [18:43:46 CEST] <intracube> etc [18:44:11 CEST] <intracube> txt file in the same folder as the video clips [18:45:01 CEST] <average> is there an ffmpeg planet ? (news aggregator) [18:45:08 CEST] <average> where do people get their ffmpeg news/posts ? [18:45:41 CEST] <average> like for example if I'm into ffmpeg, where do I go to get my fix ? [18:48:09 CEST] <bencoh> average: I just follow both irc channels and do git fetch when I feel like it (or have a specific need) [18:48:31 CEST] <average> bencoh: that's fine and reasonable [18:48:37 CEST] <bencoh> you can check the mailing-lists as well [18:48:42 CEST] <average> but supposing I'm more at the user-level [18:49:00 CEST] <average> the internals level is a bit of a different space [18:49:19 CEST] <PhoenixBR> intracube: but have you tried with .ts files? [18:50:01 CEST] <bencoh> average: rss and/or mailing-list then? [18:50:42 CEST] <intracube> PhoenixBR: yep [18:50:55 CEST] <intracube> the file plays ok in VLC, but not mplayer for some reason [18:50:55 CEST] <PhoenixBR> intracube: let me try it [18:54:16 CEST] <average> bencoh: rss would be great, like you know how many large OSS projects have a planet [18:54:50 CEST] <average> bencoh: I mean a news aggregator (it just so happens that the software running that aggregator is called planet or venus http://www.planetplanet.org/ ; http://www.intertwingly.net/code/venus/ ) [18:55:17 CEST] <average> bencoh: like if there was something like that, that would be a one-stop-shop for ffmpeg users to get their fix [18:56:05 CEST] <bencoh> I doubt there is [18:56:59 CEST] <alyawn> I'm attempting to stream an mpegts source to an rtsp output and I'm consistently getting a crash with the newer ffmpeg (3.1.1 and current HEAD). I can seem to figure out if this is a known issue or not. Are any of you seeing this issue? [18:57:41 CEST] <alyawn> http://pastebin.com/fz7JyMD3 [18:59:27 CEST] <bencoh> alyawn: I guess you could try and bissect, since you already know how to build from git :) [19:00:15 CEST] <alyawn> sure thing bencoh [20:25:32 CEST] <NetworkingPro> hey everyone [20:25:53 CEST] <NetworkingPro> Anyone know where I could find a doc with examples of transcoding and RTSP stream to mjpeg? [20:26:04 CEST] <NetworkingPro> Ive googled and cant seem to find it. [20:37:51 CEST] <DHE> if you can find an example of rtsp in, and an example of mjpeg out, you can just stitch them together most of the time [20:46:18 CEST] <Guest56501> I want a copy of the images in a video - i think video images are bmp? anyway I need the best (copy) of EVERY image. is this the best way to do it? ffmpeg -i *.mp4 -q:v 1 output_%04d.bmp ffmpeg -i *.mp4 -q:v 1 output_%04d.jpg ffmpeg -i *.mp4 -q:v 1 output_%04d.png [20:48:39 CEST] <DHE> there is no quality option for png, png is lossless [20:57:58 CEST] <Guest56501> ok but the rest is ok? it will give best quality? [21:31:38 CEST] <kdehl> Um. So. A question. The scale2ref filter, why does it take two outputs? I'm just interested in the rescaled video stream, not the stream that I used as a size reference... [21:32:34 CEST] <kdehl> I must have misunderstood something. [21:34:46 CEST] <kdehl> This works: [21:34:47 CEST] <kdehl> ffmpeg -i left.mp4 -i right.mp4 -y -an -filter_complex "[0]pad=w=in_w*2[padded]; [1][0]scale2ref[0][right_scaled]; [padded][right_scaled]overlay=W/2" output.avi [21:35:40 CEST] <kdehl> But I'm not sure how. That first output connection (or whatever you call it) of scale2ref, why is that 0? That refers to left.mp4, does it not? [22:09:43 CEST] <brontosaurusrex> how do i say: -vf "crop to height if height<width else reverse" ? [22:35:46 CEST] <brontosaurusrex> cough [23:41:06 CEST] <mikjaer> I am recording a video stream with a magewell hdmi->usb adapter using ffmpeg, but when i take out the hdmi cabel and reinsert it (or another on) while the recording is running ffmpeg freezes the last frame and keeps recording the sound only ... how do i proceed debugging this? [00:00:00 CEST] --- Wed Aug 3 2016

1 0

ffmpeg-devel.log.20160801
by burek 02 Aug '16

02 Aug '16

[00:38:27 CEST] <kierank> anyone an aes member? [05:57:01 CEST] <cone-942> ffmpeg 03Timothy Gu 07master:fd2cde02346c: Doxygen: Re-enable JAVADOC_AUTOBRIEF [10:46:14 CEST] <l3eta> So I have a question relating to a bug that is on ArchLinuxARM - Veryon. I'm not sure if it's just firefox or if it's ffmpeg itself. [10:46:45 CEST] <l3eta> Veyron* [12:04:14 CEST] <jya> a quick one. what are the parser useful for? I've found that for decoding vp9 , the vp9 parser was required (but had different requirement between LibAV and FFmpeg)... Looking at extracting the flac decoder with our copy of ffmpeg, and was wondering if the flac parser was required. [12:04:31 CEST] <jya> We don't use ffmpeg for demuxing, so we manually create the AVPacket ourselves [12:27:24 CEST] <michaelni> jya, it depends on the demuxer if the parser is required, for vp9 it would be best to talk to BBB(ronald) he seems not here atm [12:28:35 CEST] <nevcairiel> many parsers split or combine frames into an appropriate size for decoders to handle, ie. the vp9 parser splits superframe into the individual frames within the superframe so the decoder gets single frames to handle [12:28:48 CEST] <nevcairiel> it can then also depend on the container how its stored in there [12:30:34 CEST] <nevcairiel> avformat should use parsers automatically, but if you have your own demuxing, you might need to replicate the rules that control if a parser is being used or not depending on the container format [12:45:30 CEST] <rcombs> also sometimes reports info (like sampling rate, channel count, etc) that's not always in the container, without needing to invoke the full decoder [13:00:35 CEST] <jya> nevcairiel: ok... right now we pass the frames coming from our demuxer into the parser (currently only used for vp9) and then to avcodec [13:01:14 CEST] <jya> i can't recall now which vp9 decoder required the parser, if it was the LibAV one or FFmpeg [13:01:20 CEST] <nevcairiel> ours does [13:01:30 CEST] <nevcairiel> the libav vp9 decoder is quite behind on features [13:01:41 CEST] <nevcairiel> they ported an initial version once but didnt port any of the improvements [13:02:06 CEST] <jya> yeah, we have a video where the vp9 decoder will return an error if the data isn't first truncated [13:02:20 CEST] <jya> it doesn't seem to create move the pointer to the data, just the size [13:03:07 CEST] <jya> (that one http://people.mozilla.org/~jyavenard/tests/mse_webm/youtube-error.html) [13:03:43 CEST] <jya> the size of the flac parser is small, so I'll just extract that too [13:03:55 CEST] <jya> and not worry about it [13:04:52 CEST] <nevcairiel> parsers are generally not "huge", except maybe for h264/hevc or such where simply parsing the bitstream can get complicated already [13:04:57 CEST] <jya> michaelni: for the asan failure we reported earlier, the issue is in the parser. it returns a size greater than the data it was being fed [13:05:44 CEST] <jya> nevcairiel: we've never used the h264 parser, never noticed an issue. We've always found the data as found directly into the mp4. no filtering / parsing of any kind [13:05:56 CEST] <nevcairiel> mp4 doesnt need it, generally [13:05:59 CEST] <nevcairiel> but mpegts would [13:07:03 CEST] <michaelni> BBB ^ [13:08:11 CEST] <michaelni> the vp9 parser currently expects that if it got a lets say 5k frame and consumed 1k that it next would get 4k or more data, if that is not true it could output sizes too big i think [13:08:20 CEST] <michaelni> i dont know if that is the issue [13:10:00 CEST] <jya> michaelni: if it uses the sizes found in the stream itself with no validation, that would definitely be an issue [13:10:16 CEST] <BBB> the libav vp9 decoder has no parser [13:10:21 CEST] <BBB> but it also has no frame MT [13:10:25 CEST] <BBB> (which requires the parser) [13:11:01 CEST] <BBB> jya: the vp9 parser validates all sizes against the input buffer, from what I remember, but feel free to look at the parser code, its tiny so should be easy to validate [13:11:44 CEST] <jya> BBB: i didn't look into the bug, right now we've simply added a quick check that if the size coming out of the parser is greater than the input, to simply error [13:12:01 CEST] <BBB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp9_parser.c;h=2e… [13:12:05 CEST] <jya> hoping that won't cause regression (like if the buffer was buffering data) [13:12:06 CEST] <BBB> full parser code is there [13:12:15 CEST] <nevcairiel> the parser can in fact buffer data across multiple frames [13:12:22 CEST] <nevcairiel> so it can give you more output then it consumed input [13:12:55 CEST] <BBB> not the vp9 one [13:13:05 CEST] <BBB> the vp9 parser only splits [13:13:11 CEST] <nevcairiel> but in general [13:13:49 CEST] <BBB> jya: check the line 111-133 [13:14:02 CEST] <BBB> jya: thats the splitting [13:14:41 CEST] <BBB> jya: it checks against remaining size etc., so I think it should be safe? [13:15:16 CEST] <nevcairiel> meh gitweb is broken, if you try to view the log of an individual file it shows all merge commits that didnt even affect that file [13:15:28 CEST] <nevcairiel> i somehow remember having that before and i fixed it somehow in my own install of it [13:16:22 CEST] <BBB> michaelni: I think you could actually just do an exact size check [13:16:46 CEST] <BBB> michaelni: so if input size on iter 0 was N and out was M, then we could assert that the next call (iter 1) has input size N-M [13:16:49 CEST] <jya> BBB: an overflow then maybe [13:18:25 CEST] <BBB> michaelni: so if n_frames > 0 assert(sum(s->size[0..n_frames-1]) == size) [13:19:18 CEST] <BBB> michaelni: and you can change s->size[n] to be s->Size[n - 1] + actual_size to make that easier and then just calculate sum(s->size[..] as s->size[n_frames - 1] but maybe thats too fancy [13:19:41 CEST] <BBB> (plus that would actually have overflow opportunities, whereas current code should be safe afaics) [13:20:07 CEST] <michaelni> BBB does the API actually require the packet size not to change ? [13:20:49 CEST] <BBB> I dont know [13:20:56 CEST] <BBB> thats how we use it in ffmpeg.c [13:21:08 CEST] <BBB> you want to reset the parser state if size != sum(s->size[..])? [13:21:16 CEST] <BBB> (with a warning/error in console of course) [13:21:30 CEST] <michaelni> i dont know, you are the author of the parser [13:21:44 CEST] <BBB> with API you mean av_parser API right? [13:21:50 CEST] <michaelni> yes [13:22:10 CEST] <BBB> I think its fine to reset state if n_frames > 0 && size != sum(s->size[0..n_frames-1]) [13:22:17 CEST] <BBB> that may be easiest [13:26:23 CEST] <michaelni> if the parser is run with some fifo then it could be size > sum [13:32:44 CEST] <BBB> vp9 does not support that though [13:32:55 CEST] <BBB> vp9 can only come from known packet sizes [13:33:00 CEST] <BBB> which are in the container [13:33:08 CEST] <BBB> the parser does nothing more than split [13:41:20 CEST] <jya> michaelni: shouldn't an error being returned preferred? [13:43:55 CEST] <michaelni> BBB the != check breaks fate [13:44:11 CEST] <BBB> Ill check [13:45:01 CEST] <michaelni> BBB my patch atm: http://pastebin.com/VrJFXn2K [13:45:10 CEST] <michaelni> failure in fate-matroska-remux [13:45:11 CEST] <BBB> we dont include the superframe index in s->size [13:45:13 CEST] <BBB> let me add that [13:47:37 CEST] <michaelni> jya, i dont know, there isnt much a parser can do and its not supposed to loose data [13:48:43 CEST] <michaelni> the error would only be known when the next size mismatching frame comes in, that next frame doesnt neccessarily have an error [13:49:03 CEST] <jya> BTW, IRC may not be that appropriate to discuss such problem [13:49:54 CEST] <nevcairiel> whats wrong with irc? [13:52:04 CEST] <BBB> michaelni: http://pastebin.com/RK9bRJCx [13:53:00 CEST] <BBB> michaelni: the superframe is like this: [[frame 1] [frame 2] [frame 3] [superframe index]] [13:53:13 CEST] <BBB> superframe index is marker size1 size2 size3 marker [13:53:23 CEST] <BBB> and marker tells you how many sizes/frames there are [13:53:35 CEST] <BBB> so adding superframe index size fixes your patch [13:53:46 CEST] <BBB> passes fate-matroska-remux fate-vp9 here [13:56:31 CEST] <nevcairiel> it seems to read the size array backwards, from 3 to 1, right? does it store them that way in the superframe index or did it swap them somewhere that i missed? [13:57:22 CEST] <nevcairiel> oh it reads the entire thing backwards, doesnt it [13:57:53 CEST] <michaelni> BBB, patch LGTM and passes full fate here [13:58:40 CEST] <jya> michaelni: can't you get an overflow on the size_sum += s->size[i]; data if it's coming from outside ? (and as such, potentially rubbish) [13:59:19 CEST] <jya> though would likely fail the != test [14:00:21 CEST] <michaelni> jya it should have been checked before its set, but BBB is the author of this not me, he should know better [14:01:38 CEST] <nevcairiel> s->size is checked during reading that it doesnt exceed the packet size, so to get such a high value to cause an overflow you would also need a very huge packet from the start [14:02:21 CEST] <michaelni> the input packets size must fit in an int though so this should not be possible [14:02:35 CEST] <nevcairiel> right, it should not overflow an int if the size fits into an int [14:03:27 CEST] <Bitterblue> Is it safe to call avcodec_decode_subtitle2 from multiple threads with the same AVCodecContext? [14:03:38 CEST] <nevcairiel> not at the same time [14:03:51 CEST] <nevcairiel> you can switch threads if you want, but you cant call it simultaneously from different ones [14:04:05 CEST] <BBB> nevcairiel: it prevents memmoves [14:04:21 CEST] <BBB> nevcairiel: if you read forward, you have to memmove the remaining items from n to n-1 after every turn [14:04:22 CEST] <nevcairiel> BBB: yeah just took me a moment to figure out how these things are filled [14:04:49 CEST] <nevcairiel> patch should be fine then [14:05:15 CEST] <nevcairiel> although to trigger this issue someone would have to call the parser wrong, its not something that seems like it would come from bad input, or? [14:05:28 CEST] <nevcairiel> well maybe if the superframe index contains crap data [14:05:42 CEST] <nevcairiel> but it would just randomly slice the frame, not overread inside the parser or something [14:07:23 CEST] <Bitterblue> Aha. Would that explain why sometimes I'm getting AVSubtitles with rects[0].data[0]=NULL? Otherwise the AVSubtitle looks valid. [14:07:27 CEST] <jya> nevcairiel: the parser no.. but the decoder being called later would [14:07:44 CEST] <nevcairiel> jya: if it crashes on bad input then thats another bug to file [14:07:58 CEST] <nevcairiel> and something BBB would probably interested in [14:08:03 CEST] <nevcairiel> +be [14:08:10 CEST] <jya> it doesn't crash, ASAN shows out of bound memory access [14:11:06 CEST] <michaelni> BBB, nevcairiel should i push the patch with ronalds fixes ? or post to ML or wait ? [14:11:17 CEST] <nevcairiel> ML is always safer [14:13:09 CEST] <jya> michaelni: we can ask for the patch to be verified first [14:26:11 CEST] <BBB> conceptually speaking [14:26:19 CEST] <BBB> I think the reason mozilla is affected by this but ffmpeg.c is not [14:26:31 CEST] <BBB> is that mozilla likely calls parser/decoder together [14:26:35 CEST] <BBB> where demuxer is separate [14:26:43 CEST] <BBB> whereas we merge parser/demuxer stages [14:26:46 CEST] <BBB> and decoder is called separate [14:27:00 CEST] <BBB> on error, you discard remaining input [14:27:23 CEST] <BBB> so the parser is then called with a new packet from the demuxer which might be smaller than the cached size internally from the previous (now discarded) packet [14:27:32 CEST] <BBB> ffmpeg.c never does that, neither does chrome [14:27:49 CEST] <BBB> because the demuxer/parser live together and decoder acts separately [14:28:03 CEST] <BBB> jya: is that about correct? [14:28:44 CEST] <jya> that is correct. the parser is combined with the decoder [14:29:14 CEST] <jya> we use nestegg as demuxer [14:29:35 CEST] <BBB> michaelni: ok so I think that explains everything then [14:30:09 CEST] <BBB> michaelni: Id post patch to ML for comments for a few hours, but you have approval to commit already from me so feel free to commit when you feel its been out long enough for other people to comment on or whatever [14:31:32 CEST] <michaelni> BBB patch sent [14:31:47 CEST] <jya> can you make sure it makes it to 3.1? [14:32:13 CEST] <michaelni> yes ill backport it [14:32:23 CEST] <michaelni> please someone hit me with a stick if i forget [16:30:10 CEST] <BBB> jya: with michaels/my patch, you dont need to reset the parser [16:30:23 CEST] <BBB> jya: I know we do that, but you dont have to, its not strictly required [16:30:47 CEST] <jya> that's with the vp9 parser, what about others? [16:31:10 CEST] <jya> may as well do it, it's cheap enough... but thanks for letting me know, then I know it doesn't need to be uplifted [16:31:23 CEST] <jya> (mozilla slang for backported) [16:40:02 CEST] <BBB> jya: its cheap, thats true [16:40:09 CEST] <BBB> jya: as for other parsers, I dont know :) [17:10:13 CEST] <michaelni> BBB are the frames following a decoder error useless till the next "packet" ? if not it would make sense to pass them to the decoder even after an error [17:10:43 CEST] <BBB> theyre useless [17:10:50 CEST] <michaelni> ok [17:10:51 CEST] <BBB> with ffvp9 at least [17:11:41 CEST] <michaelni> for other codecs they could contain decodable information [17:19:44 CEST] <BBB> michaelni: they are decodable [17:19:57 CEST] <BBB> michaelni: but they are by definition not keyframes, and you need keyframes to reset the references [17:20:12 CEST] <BBB> michaelni: look, I think its easier if mozilla would keepinputting the existing frame into the decoder [17:20:18 CEST] <BBB> but this is fine also [17:20:22 CEST] <BBB> in practice it makes no difference [17:20:33 CEST] <michaelni> sure, ok [17:21:18 CEST] <cone-764> ffmpeg 03Michael Niedermayer 07master:77b0f3f26d33: avcodec/vp9_parser: Check the input frame sizes for being consistent [17:56:58 CEST] <cone-764> ffmpeg 03Michael Niedermayer 07release/3.1:e4eab67a0aed: avcodec/h264_parser: Set sps/pps_ref [17:56:59 CEST] <cone-764> ffmpeg 03Sasi Inguva 07release/3.1:7c01fa962e7f: libx264: Increase x264 opts character limit to 4096 [17:57:00 CEST] <cone-764> ffmpeg 03Kacper MichajBow 07release/3.1:caf32880fdf9: libavutil/opt: Small bugfix in example. [17:57:01 CEST] <cone-764> ffmpeg 03Kacper MichajBow 07release/3.1:87d5146fb7b9: libavformat/rtpdec_asf: zero initialize the AVIOContext struct [17:57:02 CEST] <cone-764> ffmpeg 03Xinzheng Zhang 07release/3.1:88e3e6b94305: avformat/flvdec: splitting add_keyframes_index() out from parse_keyframes_index() [17:57:03 CEST] <cone-764> ffmpeg 03Xinzheng Zhang 07release/3.1:b4922daeadd2: avformat/flvdec: parse keyframe before a\v stream was created add_keyframes_index() when stream created or keyframe parsed [17:57:04 CEST] <cone-764> ffmpeg 03Michael Niedermayer 07release/3.1:8f6a95a103b4: avcodec/vp9_parser: Check the input frame sizes for being consistent [18:19:25 CEST] <jamrial> michaelni: could you test https://github.com/jamrial/FFmpeg/commits/master? merged the next four commits from libav [18:20:13 CEST] <jamrial> they are kinda trivial and fate passes here, but just to be sure [18:46:02 CEST] <bp0> looking at AVOption, there are flags AV_OPT_FLAG_EXPORT and AV_OPT_FLAG_READONLY, is it possible to get the value of such options in a fate test? [19:08:33 CEST] <michaelni> jamrial, seems working fine [19:08:55 CEST] <jamrial> michaelni: ok, thanks! [19:09:26 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:f638b67e5790: h264: move the parameter set definitions to a new header file [19:09:27 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:70b1dcef2d85: h264: tighten the valid range for ref_frame_count [19:09:28 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:b24dafe10572: lavc: drop unnecessary h264dec.h includes [19:09:29 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:1cf2f3d334f5: h264_sei: drop an unnecessary h264dec.h include [19:09:30 CEST] <cone-764> ffmpeg 03James Almer 07master:8c7932884d09: Merge commit 'f638b67e5790735f34620bf82025c9b9d6fc7216' [19:09:31 CEST] <cone-764> ffmpeg 03James Almer 07master:9ee1f0336563: Merge commit '70b1dcef2d859ae6b3e21d61de928c3dd0cf1aa4' [19:09:32 CEST] <cone-764> ffmpeg 03James Almer 07master:7c8bf2dc2ba0: Merge commit 'b24dafe10572254ff0decc18b0d7c3d3707d5a29' [19:09:33 CEST] <cone-764> ffmpeg 03James Almer 07master:4c121ad5466a: Merge commit '1cf2f3d334f52849aae2be868bad1e5fa5f59aa0' [19:28:12 CEST] <bp0> michaelni, is there some problem with the other 5 patches in the hdcd set? [19:41:35 CEST] <michaelni> bp0, not that i know [19:42:14 CEST] <bp0> can they be applied then? [19:44:40 CEST] <bp0> or perhaps will they be applied, or would you apply them please, whichever is the most deferential and not demanding version of that question [19:56:24 CEST] <michaelni> bp0, it seems "[FFmpeg-devel] [PATCH 6/7] af_hdcd: Process stereo channels together, fix #5727" does not apply after the other patches [19:58:03 CEST] <bp0> well that is weird, they were all made in a separate branch, without any other changes between. how does that happen? [19:58:16 CEST] <bp0> I will look into it, I guess [20:01:52 CEST] <cone-764> ffmpeg 03Burt P 07master:bbf0b4fa88a3: MAINTAINERS: Add myself for af_hdcd [20:01:53 CEST] <cone-764> ffmpeg 03Burt P 07master:6517177d975b: af_hdcd: Improve error detection logging [20:01:54 CEST] <cone-764> ffmpeg 03Burt P 07master:b90d0ab4be3d: af_hdcd: add force_pe filter option [20:01:55 CEST] <cone-764> ffmpeg 03Burt P 07master:12759cc0345c: af_hdcd: Move code detect/check into own function [20:30:47 CEST] <bp0> michaelni, I figured out the catch, it is very minor, can I just give you a diff to apply before the patch, or does it need to be a whole git commit? [20:31:38 CEST] <michaelni> bp0 please give me a proper git patch or git branch to cherry pick from [20:42:45 CEST] <bp0> ok, I will [20:56:45 CEST] <bp0> michaelni, so I can send a small commit that should be applied before the other patch, and that will work? [21:00:05 CEST] <michaelni> bp0, is it supposed to be applied as 2 commits /patches ? [21:00:24 CEST] <michaelni> if yes then send otherwise they should be stashed into one [21:00:25 CEST] <bp0> yeah, it would have to be applied, then apply the patch that failed [21:00:42 CEST] <bp0> and it should not fail [21:01:26 CEST] <michaelni> bp0, the question i had/meant was is it intended to be 2 commits ? aka is that how it should be split ? [21:01:57 CEST] <michaelni> or do you want to update the patch and have just 1 commit ? [21:02:42 CEST] <michaelni> its very easy with git to update and change things [21:02:56 CEST] <bp0> I... don't know. What is best? [21:03:09 CEST] <bp0> I'm pretty much at the edge of my git capabilities with this solution [21:04:00 CEST] <michaelni> bp0, i am not talking about git :) i mean the change should it be split in 2 or 1 [21:04:21 CEST] <bp0> oh, I think one might be better [21:04:51 CEST] <bp0> it is the position of some {} that fails to patch, nothing really so important [21:05:27 CEST] <bp0> the new pre-patch just fixes those curly bracket positions so that the original patch will work [21:05:42 CEST] <michaelni> ahh [21:06:28 CEST] <michaelni> do you have that problematic patch locally in some branch ? [21:06:43 CEST] <michaelni> or you are on a clean master with nothing ? [21:07:13 CEST] <bp0> yeah, I do have it in a branch [21:08:02 CEST] <michaelni> so if you are on master, try a git cherry-pick [here goes the hash from that commit you want to rebase] [21:08:41 CEST] <michaelni> git log [that branch where the commit is] shows the hashes (the long ugly hexadecimal numbers) [21:11:04 CEST] <michaelni> "git cherry-pick " will likely give a trivial conflcit and explain how to solve it [21:11:10 CEST] <bp0> alright, so it failed again, but now.. there will be conflict markers or something? [21:11:19 CEST] <michaelni> there should be [21:15:49 CEST] <bp0> ok, so then I've got a new version of that commit, and I can send it to the ML as a v2? or what do I have now? [21:17:22 CEST] <michaelni> yes you can send it as v2 [21:17:54 CEST] <michaelni> same way as you did previously should work [21:22:26 CEST] <bp0> ok, if using git send-email without --compose, can I still change the subject to [PATCH v2] somehow? --subject="" didn't do it [21:26:29 CEST] <bp0> hmm, even using --compose and just not writing a message, then subject reverts to [PATCH] [21:27:33 CEST] <jamrial> bp0: just use git format-patch and edit the subject in the resulting file [21:27:41 CEST] <jamrial> then git send-email that file [21:27:59 CEST] <wbs> --subject-prefix="PATCHv2" should do it [21:29:06 CEST] <bp0> wbs, very good, thank you [21:29:10 CEST] <bp0> thank you too jamrial [21:29:15 CEST] <bp0> and, of course, michaelni [21:30:48 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:5c2fb561d94f: h264: add H264_ prefix to the NAL unit types [21:30:49 CEST] <cone-764> ffmpeg 03James Almer 07master:f41048f6ec56: Merge commit '5c2fb561d94fc51d76ab21d6f7cc5b6cc3aa599c' [21:37:21 CEST] <Fyr> Here's something I ought to say. [21:37:27 CEST] <Fyr> I hate FFMPEG. [21:37:40 CEST] <Fyr> I hate it with every inch of my body. [21:37:50 CEST] <Fyr> if all its developers died painfully, the world would be a better place. [21:37:57 CEST] <Fyr> I accurse you! Die painfully! [22:04:46 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:8281cd5cb805: h264_cabac: drop an always true condition [22:04:47 CEST] <cone-764> ffmpeg 03James Almer 07master:fd4eb56528e1: Merge commit '8281cd5cb80582d668ce0848e0e035b383f161f6' [22:35:11 CEST] <Compn> lol that was an interesting comment [22:36:40 CEST] <Loriker> nothing productive [22:38:59 CEST] <Compn> http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2015-November/003217.html [22:39:03 CEST] <Compn> guy was asking about flac decode [22:39:04 CEST] <Compn> :D [23:41:36 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:bc7f42685146: h264: drop tests whether the codec id is AV_CODEC_ID_H264 [23:41:37 CEST] <cone-764> ffmpeg 03James Almer 07master:517dd04f6df3: Merge commit 'bc7f4268514624e1286ea76d27a89a56b4ee18e1' [23:43:15 CEST] <Timothy_Gu> jamrial: is there a script available for merging? [23:49:12 CEST] <jamrial> Timothy_Gu: ubitux sent a patch with one and some relevant documentation a few weeks ago [00:00:00 CEST] --- Tue Aug 2 2016

1 0

ffmpeg.log.20160801
by burek 02 Aug '16

02 Aug '16

[02:39:21 CEST] <wallbroken> 32bit ffmpeg vs 64bit ffmpeg, i encoded the same video but i have different output, why? [02:58:37 CEST] <gro> Hallo @all [03:00:50 CEST] <gro> could somebody help me with some coding problems? [03:07:31 CEST] <gro> does someone know, how i can mute audio programmatically? i tried to set the channels with av_dict_set(&opts, "channels", 0, 0) but it has no effect [03:20:52 CEST] <DHE> as in toggle mute while running, or just generate silence for use in an audio track? [03:26:32 CEST] <gro> as an option to stream the video without audio [03:28:05 CEST] <gro> i'm streaming my gopro to youtube and would like have the option to mute the audio [03:49:48 CEST] <gro> @DHE some ideas? [04:01:24 CEST] <DHE> why not just discard it? most formats will accept a video file containing no audio stream at all [04:03:14 CEST] <gro> ok so only use the video stream [04:04:18 CEST] <gro> thanks, i will try this later. [04:05:53 CEST] <gro> is there a list with all av_dict options i can use? i tried to debug ffmpeg with some options like -an but i cant figure out how to find them [04:14:03 CEST] <DHE> they're not all ffmpeg commandline options. you'll find a ton of accepted parameters under libavcodec/options_table.h and similar for libavformat. the ffmpeg-specific ones are mostly under ffmpeg_opt.c [04:14:16 CEST] <DHE> and that's not even counting the codec-specific and format-specific options [04:15:12 CEST] <DHE> it's why the docs say the AVDictionary you pass in gets stripped of all passed options and anything not processed is left behind. helps ffmpeg take one set of parameters and just deal with them [04:17:06 CEST] <gro> sounds reasonable :) [04:21:25 CEST] <gro> Thank you for your help! [04:42:29 CEST] <ferdna> anyone doing hls streaming? [04:42:43 CEST] <ferdna> i get this message in ffserver: [04:42:51 CEST] <ferdna> Sun Jul 31 20:39:32 2016 [hls @ 0x1173210]failed to rename file .tmp to [05:00:32 CEST] <DHE> let me guess, you're uploading via webdav [05:13:17 CEST] <ferdna> DHE, is that to me? [05:13:32 CEST] <DHE> yes [05:13:43 CEST] <ferdna> no i am not... [05:13:50 CEST] <ferdna> i am running ffserver [05:15:35 CEST] <DHE> wait, just ".tmp" as a filename? no other name? sounds like it failed to rename to the empty string... [05:15:52 CEST] <DHE> and I'd bet ffserver doesn't handle HLS very well. you're better off using ffmpeg and apache instead [05:16:12 CEST] <ferdna> DHE, same problem as here: [05:16:12 CEST] <ferdna> http://ffmpeg.gusari.org/viewtopic.php?f=12&t=2611 [06:48:56 CEST] <ferdna> DHE [06:48:58 CEST] <ferdna> that was it [06:49:02 CEST] <ferdna> thank you very much [09:11:27 CEST] <Fyr> guys, concatenation of video and audio separately gives desync. can FFMPEG convert into LPCM? [09:38:09 CEST] <jiggunjer> Fyr: input files same codecs? [09:38:16 CEST] <Fyr> sure [09:42:21 CEST] <Fyr> what container FFMPEG can make use of to mux ALAC? [09:45:19 CEST] <relaxed> Fyr: m4a [09:45:31 CEST] <Fyr> m4a == mp4 [09:45:59 CEST] <relaxed> yes [09:46:40 CEST] <relaxed> matroska too [09:46:41 CEST] <Fyr> why on Earth FFMPEG refuses to mux ALAC into mp4 and does that when muxing into M4A? [09:47:13 CEST] <relaxed> well, m4a is similar to mp4 [09:47:23 CEST] <relaxed> it's apple's audio container [09:49:59 CEST] <relaxed> Fyr: it will work with ... -f ipod output.mp4 [09:50:08 CEST] <Fyr> oh, thanks [09:50:13 CEST] <Fyr> I hate FFMPEG. [09:52:12 CEST] <JEEB> m4a most probably has different identifiers in the container, and likely "-f ipod" is just going to do that instead of finding it out by the extension [09:52:15 CEST] <JEEB> :P [10:24:21 CEST] <Fyr> does FFMPEG support variable framerate with MP4? [11:16:56 CEST] <carado> hi ! mpv tv:// can read from my webcam fine (although it prints some errors, http://paste.awesom.eu/84lp ) but ffmpeg prints Invalid data found when processing input and quits immediately ( http://paste.awesom.eu/W4Ck ). what can I do ? [13:39:07 CEST] <Fyr> JEEB, do you happen to know why concatenation of four files gives crap in the joints and desync while concatenating one-by-one gives normal video/audio? [13:41:08 CEST] <JEEB> nfi [13:41:16 CEST] <JEEB> esp. since you're using the stuff that works without re-encoding [13:41:29 CEST] <JEEB> never used that stuff and I just know none of them are perfect [13:48:25 CEST] <senyai> Hi! Could you guys check what's wrong with this file? https://arseniy.net/demo.avi - I'm using latest ffmpeg and avcodec_send_frame/avcodec_receive_packet interface, and I can't play it with vlc. [13:49:50 CEST] <Fyr> so, I'm discovering the completely new territory where no developer ever set foot on it. [13:50:30 CEST] <Fyr> senyai, it cannot be played with PotPlayer, Light Alloy. ffprobe gives almost nothing. [13:54:38 CEST] <JEEB> Fyr: no - some developer made the things for some specific use case and now people are of course thinking it's a generic solution which it isn't ;) [13:54:53 CEST] <Fyr> ='( [13:55:20 CEST] <JEEB> because "more features is better even if they're not perfect" [13:55:32 CEST] <JEEB> (well, things are never perfect but you know what I mean) [13:55:58 CEST] <Fyr> a tool must do one thing and do that perfectly. [15:03:03 CEST] <shincodex> why [15:03:07 CEST] <shincodex> is there two timeouts [15:03:10 CEST] <shincodex> rtsp stimeout timeout [15:03:17 CEST] <shincodex> http timeout [15:03:29 CEST] <shincodex> pass in timeout to rtsp avinput dies and says option doesnt exist [15:04:00 CEST] <shincodex> timeout should imply a generic word for timeout on anything [15:04:06 CEST] <shincodex> socket, curl call or wtf ever [15:04:27 CEST] <shincodex> microseconds is a bit extreme [15:04:35 CEST] <spooooon> rtsp is very particular and silly, it could be the socket timeout, and the GET/SET_PARAMETER timeout [15:04:49 CEST] <shincodex> everything is silly [15:04:53 CEST] Action: shincodex suicides [15:05:05 CEST] <spooooon> I'm not 100% sure as I don't know the code, but I do know rtsp very particular about things it shouldn't be [15:05:05 CEST] <shincodex> best part of waking up is ffmpeg code in your cup [15:05:41 CEST] <shincodex> im thankful at least [15:05:47 CEST] <shincodex> I have a visual studio debugger attached to it [15:05:57 CEST] <Fyr> xD [15:05:57 CEST] <spooooon> I would guess stimeout is the socket timeout, and timeout is the GET_PARAMETER timeout(which rtsp rfc says SET_PARAMETER should be preferred btw!) [15:06:09 CEST] <shincodex> cause i would plug pull my network and connect to a rtsp camera and it be like infinite loop [15:06:19 CEST] <shincodex> and im like i bet some dude set a infinite timeout ina poll somewhere [15:06:21 CEST] <shincodex> YEP! THEY DID [15:06:43 CEST] <spooooon> oh god you haven't read the rfcs as well [15:07:18 CEST] <shincodex> someday xrdp needs to support copy paste from windows to linux [15:07:30 CEST] <shincodex> so i can paste this protocol link [15:07:34 CEST] <shincodex> of timeout and stimeout [15:59:34 CEST] <hero_biz> hi guys [15:59:39 CEST] <Fyr> hi [16:00:00 CEST] <Fyr> guys, how do native speaker call people, whose hands grow from their asses? [16:00:06 CEST] <hero_biz> guys, I have downmixed a 5.1 audio to streo with this command: [16:00:22 CEST] <hero_biz> ffmpeg -i audio.mkv -vn -ac 2 -c:a libfdk_aac -b:a 48k audio2.aac [16:00:53 CEST] <hero_biz> but when I was checking I noticed 5.1 audio is 25min and 11 sec while stero audio is only 25 min. [16:00:58 CEST] <hero_biz> any idea why this happens? [16:01:53 CEST] <Fyr> hero_biz, if i were you, I would convert them into wav and compared in Audacity. [16:03:13 CEST] <hero_biz> when length of 2 audio streams differ, they practically should differ,isn't it? [16:03:18 CEST] <hero_biz> O.O [16:25:32 CEST] <shincodex> i plug pull and pass in timeout and ffmpeg gives error -138 and av_strerror doesnt return junk [16:25:38 CEST] <shincodex> ETIMEDOUT doesnt = -138 either [19:29:16 CEST] <shincodex> is there a av_ignore_options_youdontgiveashitabout_instead_of_failing_avopeninput function? [19:30:15 CEST] <JEEB> that's bad design, so no [19:30:37 CEST] <JEEB> you set something so clearly you wanted something [19:30:59 CEST] <JEEB> it's like autoconf based configure scripts ignoring unknown parameters [19:31:02 CEST] <JEEB> which is !?! [19:31:16 CEST] <shincodex> AV_GUESS_FORMAT [19:31:20 CEST] <shincodex> !!!!!!111 [19:31:42 CEST] <shincodex> holycrap thats rare googling and its like boom there it is! [19:32:06 CEST] <shincodex> actually i had to revolve my eyeballs around the example code the google link posted [19:32:10 CEST] <JEEB> I did avio stuff before and when calling libavformat I didn't have to specify that [19:32:19 CEST] <shincodex> Well heres the trick [19:32:20 CEST] <JEEB> it would probe what the thing could be by default [19:32:39 CEST] <shincodex> avformat_open_input [19:32:59 CEST] <shincodex> if i use timeout when its RTSP it goes fail no such dictionary option [19:33:09 CEST] <shincodex> and im like that seems wrong cause docs say there is [19:33:12 CEST] <shincodex> whatev... ditch it [19:33:16 CEST] <shincodex> stimeout works... [19:33:40 CEST] <shincodex> http is like ? whats stimeout? whatever ill load anyways [19:33:48 CEST] <shincodex> avformat_open_input success! [19:35:58 CEST] <shincodex> not that one [19:36:02 CEST] <shincodex> guess_stream_format [19:36:04 CEST] <shincodex> seems to be it [19:49:59 CEST] <shincodex> oh no... its like filestreams only [19:50:02 CEST] <shincodex> oh no [20:11:36 CEST] <shincodex> its rtsp [20:11:39 CEST] <shincodex> it does suck [20:11:46 CEST] <shincodex> so does this options thing. [20:11:52 CEST] <shincodex> if timeout > 0 oh start listening [20:12:31 CEST] <shincodex> else timeout -1 oh nevermind use stimeout for socket poll timeout where as regular timeout on http is for socket timeout [20:32:17 CEST] <wallbroken> 32bit ffmpeg vs 64bit ffmpeg, i encoded the same video but i have different output, why? [20:33:25 CEST] <Fyr> underpants gnomes? [20:46:49 CEST] <jkqxz> wallbroken: What codecs are you using? [21:04:01 CEST] <wallbroken> jkqxz [21:04:19 CEST] <wallbroken> ffmpeg.exe -i "Audio.mp3" -i "video.avi" -map 0:a -map 1:v -af atempo=2395.767375/2498.120625 -c:v copy 1.avi [21:07:16 CEST] <jkqxz> So video is copied but you haven't specified anythng for audio so it will use some random default (aac, maybe?). At least specify the audio codec you want on the output. [21:09:07 CEST] <wallbroken> jkqxz, the audio output by default is mp3 abr [21:09:11 CEST] <jkqxz> After that, I would guess floating point in the audio stuff. Is that 32-bit vs. 64-bit x86? If so, the 32-bit is probably using the x87 FPU while the 64-bit will SSE. They don't have the same precision and won't get the same answers. [21:09:49 CEST] <wallbroken> ok, and is better to do it with 32 or 64 bit? [21:10:44 CEST] <jkqxz> The answers will be different, but it's unlikely that one will be in any sense better than other. [21:12:08 CEST] <jkqxz> In general you are better off using 64-bit, but that is because it tends to be faster rather than anything to do with the quality. [21:33:51 CEST] <wallbroken> jkqxz, so, quality will be identical? [21:48:09 CEST] <jkqxz> wallbroken: Yes. [22:10:41 CEST] <wallbroken> jkqxz, but you said "64 bit get more precision" [22:14:12 CEST] <jkqxz> No, 32-bit has more precision. It uses the legacy x87 FPU which keeps things in 80-bit internally, while SSE gives you the normal 64-bit precision. [22:15:25 CEST] <jkqxz> Anyway, the precision in either case is generally much more than is relevant to any calculation done on audio. It just affects the low bits and makes the results differ irrelevantly. [22:21:32 CEST] <thebombzen_> not really an FFmpeg question, but do you guys see any real downside nowadays to compiling libx264 as 10-bit? [22:22:23 CEST] <thebombzen_> I've been compiling it as 10-bit so it'll default to High10, and so far no decoder has complained to me, but I also haven't tried to convert a video for a dumbphone in a long time. [22:22:42 CEST] <thebombzen_> Is there any practical reason for NOT doing 10-bit H.264? [22:26:42 CEST] <ritsuka> 10bit is not supported by a lot of hardware decoders [22:26:51 CEST] <jkqxz> Only that it won't work with most devices and proprietary decoders (including hardware). If you're happy to always decode in software with lavc then it's awesome. Otherwise, not so much. [00:00:00 CEST] --- Tue Aug 2 2016

1 0