Ffmpeg-devel-irc
Threads by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
December 2015
- 1 participants
- 62 discussions
[00:08:06 CET] <shahriman> Is it possible to set camera parameters using the v4l2 device? From reading the code, it seems to me not possible today. But correct me if I am wrong.
[00:08:28 CET] <shahriman> I am referring to libavdevice/v4l2.c
[01:57:07 CET] <cone-442> ffmpeg 03Rainer Hochecker 07release/2.4:5e4ec87720a6: avformat/utils: estimate_timings_from_pts - increase retry counter, fixes invalid duration for ts files with hevc codec
[02:06:21 CET] <cone-442> ffmpeg 03Claudio Freire 07n2.4.12:HEAD: AAC encoder: fix OOB access in search_for_pns
[02:10:45 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:e5d771c84dea: avfilter/avf_showfreqs: avoid wasteful pow
[02:10:46 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:82f3d47b4f79: doc/developer: misc minor fixes
[02:35:05 CET] <cone-442> ffmpeg 03Andreas Cadhalpun 07release/2.8:2e54b8c379ba: mjpegdec: consider chroma subsampling in size check
[02:35:06 CET] <cone-442> ffmpeg 03Michael Niedermayer 07release/2.8:4608cc176b34: avutil/mathematics: Fix division by 0
[02:35:07 CET] <cone-442> ffmpeg 03Michael Niedermayer 07release/2.8:a9c721da12e3: avformat/matroskaenc: Check codecdelay before use
[02:35:08 CET] <cone-442> ffmpeg 03Rainer Hochecker 07release/2.8:5e105aca0145: avformat/utils: estimate_timings_from_pts - increase retry counter, fixes invalid duration for ts files with hevc codec
[04:43:30 CET] <Compn> argh\
[04:43:40 CET] <Compn> my first wild vp9 sample (from youtube)
[04:43:51 CET] <Compn> old media player doesnt have the codec yet haha
[04:44:24 CET] <J_Darnley> Does your fridge need a software update to play it?
[04:44:44 CET] <Compn> lol
[09:52:59 CET] <cone-185> ffmpeg 03Paul B Mahol 07master:45938f0301a8: avfilter/x86/vf_maskedmerge: move %define out of .nextrow
[10:12:20 CET] <ubitux> shahriman: yes, through avoptions
[10:12:45 CET] <ubitux> ffmpeg -h demuxer=v4l2
[11:45:50 CET] <ubitux> what is the point of ff_mutex_*?
[11:46:02 CET] <ubitux> it seems unused except in lavu/buffer.c
[13:37:19 CET] <nevcairiel> ubitux: you mean the defines for pthread functions? I have no clue why they were needed .. I suppose you can use them without worrying that threading may not be available, since they just eval to empty them
[13:54:21 CET] <cone-185> ffmpeg 03Ganesh Ajjanagadde 07master:08a96708a504: lavfi/vf_overlay: fix unitialized pointers
[14:02:53 CET] <cone-185> ffmpeg 03Ganesh Ajjanagadde 07master:bd3409f52a05: lavfi/vf_alphamerge: fix unitialized pointers
[15:25:54 CET] <durandal_1707> :(
[15:26:33 CET] <philipl> BtbN: Well, stuck my oar in on the nvEncodeAPI.h licensing discussion. Fun times.
[16:03:38 CET] <cbsrobot_> durandal_1707: I tried to make a useful output from the itur468 filter but did not succeed yet
[16:05:20 CET] <cbsrobot_> I'll try to find files where I know their itur486 value and see if I can get a meaningful output
[16:07:36 CET] <durandal_1707> its in metadata
[16:08:17 CET] <durandal_1707> use adrawgraph to visualize it
[16:10:25 CET] <durandal_1707> max value I get when playing white noise
[16:10:59 CET] <durandal_1707> see also jnoisemeter
[16:11:19 CET] <durandal_1707> If you are on linux
[16:11:22 CET] <cbsrobot_> yeah I saw it - but I want to compare it
[16:19:10 CET] <durandal_1707> so could you get jnoisemeter to display something?
[16:19:48 CET] <shahriman> <ubitux> ffmpeg -h demuxer=v4l2 <-- doesn't look like it support camera control, e. g. exposure.
[16:20:07 CET] <shahriman> Am I missing something?
[16:21:11 CET] <ubitux> if that's what you meant by parameters then i guess yeah
[16:23:46 CET] <shahriman> Hmm I see. What would you call it?
[16:24:30 CET] <ubitux> dunno; but parameters could have been refering to resolution and such
[16:26:50 CET] <shahriman> It is supported by V4L2, along with some other controls. Any thoughts on what's the best way to support such settings when available in the camera?
[16:27:28 CET] <shahriman> V4L2 supports things like ISO, exposure, scene mode and some other such stuff. Of course not all camera implements all of them.
[16:27:58 CET] <shahriman> all camera drivers*
[16:31:32 CET] <ubitux> well, add avoptions for each maybe
[16:32:52 CET] <durandal_1707> you want to change it on the fly?
[16:33:39 CET] <shahriman> The camera I am working with does support changing it on the fly (Without reopening the avdevice), but I don't strictly need it.
[16:34:02 CET] <shahriman> To be honest, the only control that I am interested in is scene mode.
[16:36:50 CET] <durandal_1707> than just modifi code and add options
[16:59:41 CET] <BtbN> philipl, i think it's more of an "i don't want that header in ffmpeg" discussion. I realy don't see an issue license wise.
[17:01:06 CET] <nevcairiel> I don't even understand from what standpoint Andreas is arguing, the strictest most literal obedience to the GPL overlords?
[17:08:23 CET] <thardin> relying no dlopen() seems a bit suspect
[17:10:17 CET] <nevcairiel> I wonder how things like libva would ever be allowed to exist then, they are open-source libraries designed to interface with drivers, which can be and are closed source
[17:10:42 CET] <thardin> it's a general solution
[17:13:50 CET] <thardin> let's see if I have this right: the wrapper is MIT but the actual .so file is proprietary?
[17:14:00 CET] <nevcairiel> yes
[17:14:09 CET] <BBB> Compn: see? you too are overtakn by the powers of vp9 now
[17:14:13 CET] <thardin> so lgpl compatible but obviously not gpl compatible
[17:14:31 CET] <BBB> only if you distribute them together
[17:14:38 CET] <nevcairiel> if that would be obvious, we wouldnt have the discussion
[17:14:44 CET] <nevcairiel> the .so is not distributed with ffmpeg
[17:15:04 CET] <nevcairiel> it comes from the nvidia graphics driver, which the distribution installs for you
[17:15:41 CET] <thardin> feels like something that ties into the general deblobbing discussion
[17:16:24 CET] <nevcairiel> its one of these clauses in the GPL that don't actually benefit the projects using GPL, but just the OSS overlords that want to make closed source hard =p
[17:16:35 CET] <thardin> you'd be encouraging the spread of nonfree software
[17:18:06 CET] <thardin> but then again, with this kind of thinking software should refuse to run on hardware with a single bit of nonfree code. which is kind of difficult :]
[17:19:00 CET] <nevcairiel> anything closely related to hardware has a big chance of being involved with some sort of closed source
[17:19:08 CET] <nevcairiel> be it firmware, drivers, uefi, what have you
[17:19:12 CET] <nevcairiel> microcode even!
[17:19:25 CET] <thardin> iirc the general approach is "play nice if there's a proprietary solution already. else go full GPL for maximum capitalist tear extraction"
[17:20:15 CET] <nevcairiel> in this case, a closed source app could just use the header and have all the features
[17:20:19 CET] <nevcairiel> while our gpl ffmpeg cannot
[17:20:24 CET] <nevcairiel> clearly seems like thats not wanted, is it?
[17:20:40 CET] <thardin> yeah, probably a case where you'd want to be pragmatic
[17:20:59 CET] <Daemon404> that's not the rms way
[17:21:09 CET] <thardin> you'd be surprised
[17:21:14 CET] <nevcairiel> nvidia went out of their way to fix the license of the header from proprietary to MIT
[17:21:28 CET] <nevcairiel> after j-b lobied them for it
[17:23:20 CET] <thardin> would this kind of thing belong in the kernel?
[17:24:21 CET] <thardin> oh, and can't it be called via libva?
[17:26:20 CET] <nevcairiel> Its an encoding interface, libva encoding sucks
[17:27:29 CET] <kierank> michaelni: can we commit the first in my big dirac patchset
[17:27:33 CET] <kierank> and see what happens to fate?
[17:28:21 CET] <thardin> ic
[17:34:03 CET] <TD-Linux> thardin, yeah though there is some userspace buffer management happening there too iirc
[17:48:23 CET] <kylophone> Finishing up another filter...
[17:48:29 CET] <kylophone> This one has a lookahead.
[17:48:32 CET] <thardin> hm. because it feels like something that should be handled "further up"
[17:48:47 CET] <kylophone> As far as I can tell, the request_frame() callback happens after each filter_frame().
[17:49:06 CET] <kylophone> Since this filter has a lookahead, there is still a buffer I need to push after AVERROR_EOF.
[17:49:20 CET] <kylophone> Should these extra samples be added to *outlink inside the request_frame() callback?
[17:49:31 CET] <kylophone> I'm assuming that trying to detect AVERROR_EOF by calling ff_request_frame() inside of filter_frame() is a bad idea.
[17:49:36 CET] <kylophone> Any ideas?
[17:50:45 CET] <michaelni> kierank, sure, first is ok the next few are ok too, didnt review all yet but that doesnt mean iam against any
[17:53:06 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:9553689854d6: diracdec: Move strides to bytes, and pointer types to uint8_t.
[17:57:09 CET] <Daemon404> kierank, got bored of cfhd? ;)
[18:30:23 CET] <Compn> kierank : so did they change cfhd from the time of those old binary codecs to today?
[18:30:30 CET] <Compn> maybe just added more bits.
[18:30:33 CET] <kierank> yeah more fields
[18:31:40 CET] <Daemon404> did they bump a version field or something
[18:40:11 CET] <kierank> no they have a tag/value structure
[18:40:35 CET] <Daemon404> ah
[18:49:06 CET] <kierank> for vc-5 they just added more tags
[18:49:17 CET] <Daemon404> and changed some codebooks?
[18:50:26 CET] <kierank> they used one of the many codebooks in cfhd
[19:25:12 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:3f07f12f65e5: diracdec: Template DSP functions adding 10-bit versions
[19:30:26 CET] <durandal_1707> kylophone: call filter_frame from request_frame
[19:31:58 CET] <kylophone> durandal_1707: Oh, nice. Thanks.
[20:11:33 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:3bb6ce1af9d9: diracdec: Rename lowdelay_subband to decode_subband because it is shared with HQ profile
[20:18:29 CET] <Daemon404> kierank, british rail price -_-
[20:18:50 CET] <Daemon404> a eurostar ticket to brussels, return, is cheaper than a ticket to devon from london, *with* a railcard
[20:19:34 CET] <kierank> yeah
[20:19:46 CET] <kierank> try booking devon to brussels
[20:19:51 CET] <kierank> it's possible on the eurostar site
[20:19:52 CET] <Daemon404> i have once
[20:19:59 CET] <Daemon404> ah in one ticket?
[20:20:01 CET] <Daemon404> never tried it
[20:20:10 CET] <kierank> yeah it's better that way
[20:20:14 CET] <kierank> because if your first train is delayed
[20:20:20 CET] <kierank> you are entitled to be moved
[20:20:22 CET] <Daemon404> makes sense
[20:20:42 CET] <Daemon404> also it's now cheaper to fly from london city than train
[20:20:49 CET] <Daemon404> too bad the schedule is meh
[20:33:38 CET] <Daemon404> the excessive gets are due to the way mp4 handles tracks
[20:33:46 CET] <Daemon404> you may have to seek for every packet read
[20:33:53 CET] <Daemon404> depending on how packets are stored in the file
[22:04:22 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:9f374c59061b: diracdec: Make slice parameters common between lowdelay and future hq profile
[22:27:31 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:8dcc99dc684d: diracdec: Extract version parameters
[22:38:08 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:8eb6acef928d: diracdec: Support new extended quantiser range
[22:40:09 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:8880ca230738: diracdec: Store version major/minor flags
[22:42:30 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:7424a6d0a589: diracdec: Read picture types by using parse_code
[22:47:26 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:cdf8c9038ddb: diracdec: Replace dirac parse codes with better ones
[23:14:23 CET] <cone-185> ffmpeg 03Kieran Kunhya 07master:3652dd5d0cee: diracdec: Fix FPE on invalid low_delay data
[23:52:31 CET] <cone-185> ffmpeg 03Rostislav Pehlivanov 07master:d8f13e783a55: diracdec: remove duplicate codeblock decoding
[00:00:00 CET] --- Fri Dec 11 2015
1
0
[05:40:45 CET] <cluelessperson> could someone help me figure out why ffserver is producing.... https://cluelessperson.com/stream/server/1.webm ?
[05:41:11 CET] <cluelessperson> specifically, it's stutt er ing, an d tha ts ann oy ing
[05:41:41 CET] <cluelessperson> Seems it stops happening when there's less activity occurring
[05:45:14 CET] <chungy> I think you might have answered your own question
[05:45:42 CET] <cluelessperson> chungy, not really?
[05:45:46 CET] <cluelessperson> would that be bitrate?
[05:46:09 CET] <cluelessperson> chungy, and by less activity, I mean less occuring in the movie, less action
[05:46:40 CET] <chungy> Ah hm, I assumed you meant it was streaming live
[06:21:56 CET] <cluelessperson> chungy, this movie is streaming, live
[06:22:07 CET] <cluelessperson> chungy, ffmpeg -> ffserver -> you
[07:02:26 CET] <shakirz1> hi everyone
[07:02:49 CET] <shakirz1> i m getting issue in ffmpeg multicast stream with muliple channels
[07:03:00 CET] <shakirz1> http://pastebin.com/HrUwnFQX
[07:03:14 CET] <shakirz1> see my ffprobe and ffmpeg command line
[07:03:35 CET] <shakirz1> plz anyone can help me to resolve this issue ?
[07:20:53 CET] <shakirz1> hi everyone
[07:21:02 CET] <shakirz1> i m getting issue in ffmpeg multicast with multiple channels
[07:21:10 CET] <shakirz1> http://pastebin.com/HrUwnFQX
[07:21:17 CET] <shakirz1> anyone can help me to resolve this issue
[08:00:29 CET] <tommd> Is specifying the framerate required for camera capture? I'm noticing both from the API and the CLI I get apparently uninitialized framerate fields and thus failed capture.
[08:00:43 CET] <tommd> If I manually specify the exact framerate supported then I'm good to go.
[08:13:49 CET] <flux> tommd, well, isn't that the answer then?-)
[08:20:05 CET] <tommd> flux: Well it doesn't generalize well.
[08:20:20 CET] <tommd> In my library I can't really guess the framerate for the users hardward.
[08:20:53 CET] <tommd> so I guess there must be a way to query the available devices so I can correctly set the framerate.
[08:24:33 CET] <tommd> flux: My origional question was more "is the failure with no set framerate a bug"
[08:25:42 CET] <tommd> I think this failure should be regarded as a bug. Failure as a default, when the valid value is known, only seems to make sense if a conflicting value was set manually by the user.
[08:36:42 CET] <flux> I would classify it as a missing feature
[08:37:01 CET] <flux> I bet code submissions to address that would be acceptable :)
[08:44:19 CET] <tommd> great
[08:48:51 CET] <yongyung> ffmpeg -r 180 -i "clip01%%04d.tga" -c:v libx264 -preset veryfast -qp 12 -pix_fmt yuv420p -movflags +faststart -tune fastdecode "clip01.mp4"
[08:48:56 CET] <yongyung> This is what I'm using to convert frames for editing, but I always get millions of "past duration too large" messages - I know it's just a warning but doesn't that still mean that I'm doing something wrong? Is there a way to fix that or to make ffmpeg at least shut up with the warnings while still showing the normal progress info?
[08:54:08 CET] <relaxed> yongyung: use -framerate instead of -r
[08:54:57 CET] <yongyung> relaxed: Hm, that did the trick. Is there any difference?
[08:56:43 CET] <relaxed> yes, the image2 demuxer takes -framerate
[08:58:34 CET] <relaxed> as for -r, http://ffmpeg.org/ffmpeg-all.html#Video-Options
[08:59:50 CET] <yongyung> So... is the output any different?^^
[09:01:24 CET] <yongyung> relaxed: I'm just wondering if there's a reason for me to reconvert some old footage or not
[09:03:21 CET] <relaxed> Using -r might cause framerate issues. Compare the outputs of the two.
[10:40:13 CET] <shakirz1545> Is there anyone who can help me for ffmpeg multicast streaming ?
[10:44:41 CET] <waressearcher2> shakirz1545: hallo
[10:44:47 CET] <shakirz1545> yes
[10:45:02 CET] <waressearcher2> shakirz1545: wie geht's ?
[10:46:10 CET] <shakirz1545> problem is that I m getting multiple channels from single link and try to convert it in mp4 file but its show me error
[10:46:16 CET] <shakirz1545> http://pastebin.com/HrUwnFQX
[10:51:51 CET] <shakirz1545> me fine
[10:54:18 CET] <shakirz1545> Mir geht es gut
[10:54:40 CET] <shakirz1545> werden Sie mir helfen, Ordnung in dieses Problem?
[10:55:17 CET] <waressearcher2> ich weiß nicht
[10:55:25 CET] <shakirz1545> mit Google Translate
[10:56:08 CET] <shakirz1545> OK danke
[11:03:41 CET] <dsl420> lol.. waressearcher2 ist dir langweilig? jeden hier auf deutsch zu begrüßen ist zwar nett, aber doch etwas merkwürdig ;) gibt bestimmt bessere kanäle als #ffmpeg für deutschen smalltalk :)
[11:04:28 CET] <furq> dsl420: hallo
[11:04:38 CET] <dsl420> hi
[11:57:56 CET] <shakirz1> Gibt es jemanden, der mir helfen kann, meine ffmpeg Multicast-Problem zu beheben
[12:27:13 CET] <dsl420> :)
[15:45:23 CET] <m0e> Hello, is this the right place/channel to ask about cross-compiling ffmpeg with librtmp support for a raspberry pi?
[15:49:46 CET] <waressearcher2> m0e: hallo
[15:57:22 CET] <m0e> waressearcher2: Im trying to follow this tutorial http://help.dacast.com/hc/en-us/articles/202357380-Stream-on-DaCast-under-L… but I dont want to compile it on the raspbery pi directly, so I bought a DigitalOcean 16 core instances to do the job
[15:57:43 CET] <m0e> so Im following this guide https://trac.ffmpeg.org/wiki/CompilationGuide/RaspberryPi
[15:57:47 CET] <m0e> to cross-compile
[15:58:20 CET] <m0e> I have multiple raspberry pi that needs to live stream
[15:58:29 CET] <m0e> using rtmp
[15:59:49 CET] <m0e> my problem is when I try to run the execute the configure script, I get ERROR: librtmp not found using pkg-config
[16:00:23 CET] <m0e> to execute*
[16:00:44 CET] <Bombo> m0e: did you compile that and install?
[16:01:30 CET] <m0e> wel yes, but I think because I didnt use the cross-compiler Bombo
[16:01:48 CET] <m0e> I tried to use the cross-compiler with librtmp
[16:02:12 CET] <Bombo> m0e: of course you need to compile it the same way
[16:02:16 CET] <m0e> but I kept having a problem that openssl is missing
[16:02:47 CET] <Bombo> m0e: and then point PKG_CONFIG_PATH to the lib dir where pkgconfig files are
[16:03:14 CET] <Bombo> m0e: then compile that too, welcome in dependency hell ;)
[16:03:28 CET] <m0e> my god...
[16:03:55 CET] <m0e> ok, gonna try that
[16:04:07 CET] <Bombo> (if you need ssl that is)
[16:04:31 CET] <Bombo> (if not you could probably disable it in configure --disable-openssl or something)
[16:06:25 CET] <m0e> I need it to work
[16:06:27 CET] <m0e> nothing more
[16:06:34 CET] <m0e> second day trying to get it work
[16:07:14 CET] <waressearcher2> so süß
[16:16:55 CET] <furq> m0e: which rpi
[16:17:06 CET] <m0e> furq: rpi 2
[16:17:40 CET] <m0e> if theres a better solutiom to stream from the pi camera over rtmp to a server
[16:17:47 CET] <furq> you can install regular debian jessie on an rpi2
[16:17:53 CET] <furq> which has ffmpeg with librtmp support in the repos
[16:18:28 CET] <m0e> aha
[16:18:48 CET] <m0e> I want something like
[16:18:49 CET] <m0e> ```
[16:18:53 CET] <m0e> ffmpeg -re -f lavfi -i testsrc -c:v libx264 -b:v 500k -an -s 1920x1080 -x264opts keyint=50 -g 25 -pix_fmt yuv420p -f flv "rtmp://p.ep246802.i.akamaientrypoint.net/EntryPoint flashver=FMLE/3.0\20(compatible;\20FMSc/1.0) live=true pubUser=123456 pubPasswd=789123 playpath=dclive_1_1@246802"
[16:19:03 CET] <m0e> it relies on rtmpdump I guess?
[16:19:20 CET] <m0e> Im using their service for a project
[16:19:53 CET] <m0e> and I have multiple raspberry pis live streaming
[16:21:31 CET] <furq> are you running that command on the rpi?
[16:21:49 CET] <furq> i can't imagine an rpi2 is going to get close to 25fps encoding 1080p x264
[16:22:09 CET] <m0e> no no, ignore the values
[16:22:19 CET] <m0e> max 640
[16:22:23 CET] <m0e> and 15-20fps
[16:22:44 CET] <m0e> I meant about the rtmp field
[16:22:52 CET] <furq> yeah that part should be fine
[16:23:05 CET] <m0e> ok, will give it a shot
[16:23:12 CET] <furq> http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/
[16:23:12 CET] <m0e> default ffmpeg from their repo yes?
[16:23:20 CET] <furq> there's a jessie image available there
[16:23:28 CET] <furq> there are probably others, i just debootstrapped mine
[16:24:18 CET] <furq> and yeah regular ffmpeg from the repo should be fine
[16:24:27 CET] <m0e> aha
[16:24:31 CET] <furq> unless they only added rtmp support in testing, which seems unlikely
[16:26:32 CET] <Bombo> http://www.raspbian.org/
[16:26:44 CET] <m0e> I hope so, downloading it right now
[16:26:46 CET] <m0e> raspbian doesnt provide ffmpeg
[16:26:49 CET] <furq> ^
[16:26:58 CET] <furq> there's no reason to use raspbian on an rpi2
[16:27:04 CET] <m0e> true
[16:27:13 CET] <Bombo> i got it on rpi1
[16:27:14 CET] <furq> it only exists because debian armhf doesn't run on armv6
[16:27:17 CET] <Bombo> its jessie too
[16:27:57 CET] <furq> you can't install debian jessie armhf packages on it though
[16:28:01 CET] <furq> they're compiled for armv7
[16:28:06 CET] <Bombo> i compiled ffmpeg on it when i had raspbian wheezy, took ~7h ;)
[16:28:19 CET] <Bombo> didn't try it on the new one yet
[16:28:33 CET] <m0e> furq: question, cant I use debians jessie repo to install ffmpeg?
[16:28:45 CET] <furq> on raspbian?
[16:28:46 CET] <m0e> on the current os
[16:28:48 CET] <furq> i have no idea, i've never used it
[16:28:48 CET] <m0e> yes
[16:28:55 CET] <furq> you might be able to
[16:29:31 CET] <furq> mixing debian repos is generally a quick path to dependency hell, though
[16:30:08 CET] <m0e> furq: from debians wiki Be carrefull, FFmpeg is not available on Debian 8 Jessie, to find out in which deposit the package is available, look here debpkg:libav or here debpkg:ffmpeg . It also possible to compile it by following the instructions available here: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[16:30:35 CET] <furq> it's in jessie-backports, or you can upgrade inplace to testing
[16:31:04 CET] <furq> https://packages.debian.org/jessie-backports/ffmpeg
[16:42:51 CET] <m0e> furq: installing on raspbian on, from their repo
[16:43:03 CET] <m0e> but it doesnt seem it require librtmp
[16:43:05 CET] <m0e> required*
[16:43:17 CET] <furq> i think librtmp is a build dependency
[16:44:02 CET] <m0e> mmm
[16:49:29 CET] <welpo> If I'm getting "Unknown encoder 'libvpx'" it means I'm missing that encoder, right? (not sure if docs are outdated for my version)
[16:51:15 CET] <welpo> Yeah I forgot to compile with --enable-libvpx
[16:51:37 CET] <furq> m0e: ignore that, librtmp is a dependency of libavformat
[16:51:57 CET] <furq> but weirdly on debian it's a dependency of libcurl so you probably already have it installed
[16:52:23 CET] <m0e> furq: it turned out its installed
[16:52:33 CET] <m0e> thanks, now to get the right command working
[16:52:57 CET] <m0e> this is the default command, which needs tweaking
[16:53:19 CET] <m0e> raspivid -n -vf -hf -t 0 -w 640 -h 360 -fps 20 -b 500000 -o - | ffmpeg -i - -vcodec copy -an -pix_fmt yuv420p -f flv "rtmp://p.ep394357.i.akamaientrypoint.net/EntryPoint flashver=FMLE/3.0\20(compatible;\20FMSc/1.0) live=true pubUser=210210 pubPasswd=124279 playpath=dclive_1_150@394357"
[16:53:54 CET] <m0e> so I need to pipe from raspivid
[16:54:08 CET] <m0e> not sure about the -pix_fmt though
[16:56:02 CET] <m0e> euhm
[16:56:06 CET] <m0e> getting *** Error in `ffmpeg': double free or corruption (!prev): 0x00d01f60 ***
[17:01:43 CET] <furq> m0e: maybe because of mixing armv6 and armv7 packages
[17:02:25 CET] <m0e> oh better now, seems its fixed
[17:02:25 CET] <m0e> RTMP_Connect1, handshake failed.
[17:02:25 CET] <m0e> I tweaked the args a bit
[17:07:25 CET] <welpo> I'm getting "ERROR: libvpx decoder version must be >=0.9.1" when compiling with --enable-libvpx. I followed https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu#libvpx exactly, what am I doing wrong?
[17:07:43 CET] <shahriman> m0e: I recommend instead of piping use V4L2.
[17:08:01 CET] <shahriman> It is simpler to use.
[17:08:43 CET] <TD-Linux> welpo, well 1.4.0 is old, you probably want 1.5.0 now
[17:08:43 CET] <c_14> welpo: upload your config.log to a pastebin site and link here
[17:08:56 CET] <shahriman> Using raspi-config enable the camera, then `sudo modprobe bcm2835_v4l2`. Afterwards, you can run "ffmpeg -i /dev/video0 ..." to read from your camera.
[17:09:15 CET] <welpo> might be old, TD-Linux, but compiler is asking for >0.9.1, which it is
[17:09:17 CET] <welpo> c_14: okay, sec
[17:09:44 CET] <welpo> here is my config.log, c_14: https://welpo.me/nani/config.txt
[17:11:21 CET] <c_14> welpo: Did you export PKG_CONFIG_PATH?
[17:12:10 CET] <m0e> shahriman: thank you
[17:12:14 CET] <m0e> will check it out now
[17:13:26 CET] <m0e> shahriman: I got *** Error in `ffmpeg': free(): invalid next size (normal): 0x01cbd230 ***
[17:13:30 CET] <welpo> c_14: No. Trying again
[17:14:20 CET] <shahriman> m0e: Just to be sure, are you using debian package or did you build yourself?
[17:14:30 CET] <m0e> no, I used the debian package
[17:14:58 CET] <m0e> thats what I get when I first run ffmpeg
[17:15:00 CET] <m0e> fmpeg version 2.8.1-1~bpo8+1 Copyright (c) 2000-2015 the FFmpeg developers
[17:15:01 CET] <m0e> built with gcc 4.9.2 (Debian 4.9.2-10)
[17:15:02 CET] <m0e> configuration: --prefix=/usr --extra-version='1~bpo8+1' --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/arm-linux-gnueabihf --incdir=/usr/include/arm-linux-gnueabihf --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite
[17:15:03 CET] <m0e> --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-openal --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid
[17:15:03 CET] <m0e> --enable-libzvbi --enable-opengl --enable-x11grab --enable-libiec61883 --enable-libdc1394 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv
[17:15:27 CET] <c_14> m0e: more than 3 lines of output to a pastebin service please
[17:15:44 CET] <m0e> c_14: sorry, will do next time
[17:19:02 CET] <shahriman> m0e: What do you get when you run `ffmpeg -i /dev/video0 -f null -`? Do you still get the error?
[17:19:30 CET] <m0e> shahriman: no it works fine
[17:20:05 CET] <m0e> if I do the same but with teh -f flag, I get Segmentation fault
[17:21:05 CET] <shahriman> m0e: What do you mean?
[17:21:38 CET] <m0e> shahriman: ffmpeg -i /dev/video0 -f flv rtmp data
[17:22:08 CET] <m0e> Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1024x768, 283115 kb/s, 30 fps, 30 tbr, 1000k tbn, 1000k tbc
[17:22:08 CET] <m0e> Segmentation fault
[17:22:16 CET] <shahriman> m0e: can you write a local file?
[17:22:27 CET] <shahriman> ffmpeg -i /dev/video0 -f flv local_file.flv
[17:22:56 CET] <m0e> yes it works
[17:24:22 CET] <furq> m0e: like i said it's probably because ffmpeg is armv7 on an armv6 base system
[17:24:40 CET] <m0e> furq: raspberry pi 2 is armv7
[17:24:44 CET] <m0e> Im on a rpi2
[17:24:48 CET] <shahriman> RPi 2 is not armv6
[17:24:54 CET] <furq> yeah but raspbian packages are compiled for armv6
[17:24:58 CET] <m0e> mmm
[17:25:00 CET] <shahriman> He is on Debian.
[17:25:08 CET] <furq> no he isn't
[17:25:10 CET] <m0e> no, Im raspbian using debian jessie packages
[17:25:15 CET] <m0e> on raspbian*
[17:25:15 CET] <shahriman> Ah
[17:25:21 CET] <shahriman> Why are you doing that?
[17:25:27 CET] <furq> i guess he didn't want to reinstall
[17:29:44 CET] <shahriman> furq: Packages compiled for armv6 should work fine on armv7 though, no?
[17:30:21 CET] <furq> yeah, but if you're getting segfaults from debian packages then mixing armv6 and armv7 packages would be the first thing i'd suspect
[17:31:56 CET] <welpo> Configured now without problems, c_14. Thanks!
[17:39:40 CET] <welpo> I want to hide the "Stream #0.0 -> #0.0", size and video info when I run ffmpeg (to integrate it in my scrips). Even when using -loglevel quiet that still shows. What can I do? ffmpeg version is 0.8.17-6:0.8.17-1
[17:39:55 CET] <m0e> ok, I seems like that issue happens randomly
[17:39:59 CET] <m0e> now, I tried it again
[17:40:02 CET] <m0e> I got
[17:40:07 CET] <m0e> "PublisherAuth, Authentication failed: unknown auth mode: [ AccessManager.Reject ] : [ authmod=adobe ] : ?reason=cannot_load_password_file
[17:40:08 CET] <m0e> rtmp server requested close
[17:40:32 CET] <c_14> welpo: eeeeeeeh, didn't you just compile from git?
[17:41:00 CET] <c_14> did you set path, execute using the full path?
[17:41:16 CET] <welpo> c_14: I'm compiling for my own usage, but I'm not the only one using this script so I want to make it compatible with other systems (in this case, the Debian package for ffmpeg)
[17:41:34 CET] <welpo> (it's still compiling, so I'm using the system's ffmpeg and just now noticed this)
[17:42:06 CET] <c_14> That's not ffmpeg from FFmpeg. It's an outdated broken thingy from libav
[17:42:12 CET] <c_14> New debian versions should have ffmpeg
[17:42:21 CET] <welpo> hm
[17:42:45 CET] <c_14> you can maybe get it from backports
[17:42:53 CET] <welpo> it disappeared from jessie so I think the system is using https://packages.debian.org/wheezy/ffmpeg
[17:43:08 CET] <welpo> in any case, I don't want to update the system's ffmpeg, but rather: Is there any way to silence THIS version of ffmpeg?
[17:43:58 CET] <c_14> It's in stretch and jessie-backports
[17:44:03 CET] <c_14> And I don't know
[17:44:08 CET] <c_14> other that 2&>/dev/null
[17:45:04 CET] <welpo> yeah, that's what I'll do I guess
[20:12:43 CET] <satt> Hey guys, trying to center inputs if required using (ow-iw)/2:(oh-ih)/2 as a pad argument, but sometimes I'm getting a negative value which doesn't work
[20:13:05 CET] <satt> Here's an example of a command
[20:13:18 CET] <satt> ffmpeg -i input1.mp4 -i input2.mp4 -filter_complex [0:v]scale=if(gt(ih\,iw)\,-2\,374):if(gt(ih\,iw)\,668\,-2),pad=374:668:(ow-iw)/2:(oh-ih)/2,setsar=sar=1/1[v0]; [1:v]scale=if(gt(ih\,iw)\,-2\,374):if(gt(ih\,iw)\,668\,-2),pad=374:668:(ow-iw)/2:(oh-ih)/2,setsar=sar=1/1[v1]; [v0] [0:a:0] [v1] [1:a:0] concat=n=2:v=1:a=1 [v] [a] -map [v] -map [a] output.mp4
[20:14:14 CET] <satt> Here's the error on the pad - [Parsed_pad_1 @ 0x7f8511408480] Negative values are not acceptable.
[20:16:00 CET] <kepstin> hmm. so something's gone wrong where either the height or width or the scale output is too big
[20:16:33 CET] <kepstin> which makes sense, since your if(gt(ih,iw) is checking whether the video is wider/narrower than a square, but you're resizing to a rectangle
[20:18:40 CET] <satt> That's what I figured - but I'm not sure how to go about fixing it - I'm new to ffmpeg. Basically I have to concatenate a lot of videos that might be in different resolutions
[20:20:50 CET] <kepstin> what an odd output size, width=374, height=668?
[20:21:29 CET] <satt> portrait video content, shot on a phone
[20:21:45 CET] <kepstin> anyways, you should rewrite the condition to do if(gt(iw/ih,374/668) to make it relative to the ratio you want rather than square
[20:21:45 CET] <satt> I'm taking the smallest dimensions of the inputs
[20:21:50 CET] <kepstin> that would probably be sufficient.
[20:22:17 CET] <satt> alright great thanks, I'll give that a try
[20:22:24 CET] <satt> appreciate the help!
[20:23:27 CET] <kepstin> and try the scale filter on its own without the pad to make sure it's giving you the dimensions you want on a bunch of test input files.
[20:27:54 CET] <satt> kepstin: Thanks yeah I'll definitely test that out too
[21:17:37 CET] <shevy> I am using ffmpeg to cut a .mp3 file; is there a way to tell ffmpeg to retain the original audio bitrate?
[21:18:09 CET] <shevy> The command I use right now is something like this: ffmpeg -i foobar.mp3 -ss 00:00:5.000 -t 00:05:53.000 output.mp3
[21:19:22 CET] <shevy> I noticed that the initial recording was 192.0 kbit/13.61%; the new file however was 128.0 kbit/9.07%, I assume that ffmpeg may have 128 as target format if nothing else is specified?
[21:20:45 CET] <c_14> Either use -c copy (the cuts won't be as precise) or set an audio bitrate. There is no "use the same bitrate" option
[21:20:55 CET] <furq> or use mp3splt
[21:33:42 CET] <shevy> ok
[21:49:23 CET] <klaxa> ><c_14> Either use -c copy (the cuts won't be as precise) or set an audio bitrate. There is no "use the same bitrate" option
[21:49:28 CET] <klaxa> not precise for mp3?
[21:50:04 CET] <klaxa> for mp3 cutting at frames should be precise enough, no?
[21:50:12 CET] <DHE> if you didn't specify -c copy then ffmpeg will transcode the audio
[21:50:15 CET] <fritsch> klaxa: no
[21:50:33 CET] <fritsch> cause of the reservoir there exists information in preceeding and following frame
[21:50:38 CET] <klaxa> no? how many samples in a frame?
[21:50:57 CET] <klaxa> ok
[21:51:05 CET] <DHE> fractions of a second
[21:52:49 CET] <klaxa> yeah, that's what i thought, i guess it depends on what you define as "precise"
[21:54:37 CET] <DHE> someone somewhere will try to get an audio cut at 0.01 second precision and complain when it isn't working and suddenly skips ahead 0.1 seconds
[21:54:47 CET] <DHE> (I don't know what the exact numbers are, I just made the above up on the spot)
[22:19:00 CET] <shevy> 0.01 is totally fine for me :)
[22:19:28 CET] <shevy> now if the .mp3 is 100 seconds, and I want to chop off the leading 5 seconds... and instead I'd end up with 30 seconds chopped up, then I'd worry!
[22:37:26 CET] <shevy> it worked fine, thanks, laters!
[00:00:00 CET] --- Fri Dec 11 2015
1
0
[00:01:46 CET] <ubitux> i'm looking for a sample where we get AVFrames with no pts
[00:02:00 CET] <ubitux> (i want to try the genpts flag)
[00:02:33 CET] <ubitux> any suggestion? i tried random avi & others in my small collection but -vf showinfo always shows meaningful pts
[00:02:47 CET] <ubitux> maybe i'm testing it wrong though and ffmpeg is doing smart stuff
[00:03:57 CET] <kierank> michaelni: ok I'll try to split the patches
[00:04:11 CET] <michaelni> kierank, thanks
[00:36:44 CET] <durandal_1707> anyone want to comment swaprect?
[01:03:34 CET] <kierank> michaelni: what sample is that
[01:04:37 CET] <kierank> which crashes
[01:27:26 CET] <michaelni> kierank, see inbox
[01:27:45 CET] <kierank> which email
[01:30:29 CET] <michaelni> hmm <kieran(a)kunhya.com>: host mx-biz.mail.am0.yahoodns.net[98.139.171.245] said:
[01:30:30 CET] <michaelni> 550 relaying denied for <kieran(a)kunhya.com> (in reply to RCPT TO command)
[01:31:42 CET] <kierank> yeah can you send to kierank(a)obe.tv
[01:34:56 CET] <michaelni> sent
[01:56:16 CET] <kierank> michaelni: sent a patch
[02:09:57 CET] <nullp0inter> i am getting the error: "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height" with this command: http://pastebin.com/fLnTMemT Can anyone tell me why it's wrong?
[02:20:48 CET] <J_Darnley> maybe you should post the actual error
[02:21:48 CET] <J_Darnley> It has been years since I first submitted the warning and error highlighting patch and people are still blind to it?
[02:26:51 CET] <nullp0inter> J_Darnley : not sure what you mean by highlighting, but does this help? http://pastebin.com/uuq1adz4
[02:27:18 CET] <J_Darnley> [libx264 @ 0xc8a880] width not divisible by 2 (853x480)
[02:28:48 CET] <J_Darnley> http://ffmpeg.org/ffmpeg-filters.html#scale-1
[02:32:43 CET] <nullp0inter> J_Darnley : testing using a formula and fixed heigh
[02:32:56 CET] <nullp0inter> J_Darnley : ty for the pointer, lets see if i can get this thing to work
[02:33:27 CET] <J_Darnley> "If one of the values is -n with n > 1, the scale filter will also use a value that maintains the aspect ratio of the input image, calculated from the other specified dimension. After that it will, however, make sure that the calculated dimension is divisible by n and adjust the value if necessary."
[02:33:38 CET] <J_Darnley> Hmm I bet that got cut off
[02:33:49 CET] <J_Darnley> "If one of the values is -n with n > 1, the scale filter will also use a value that maintains the aspect ratio of the input image, calculated from the other specified dimension."
[02:33:56 CET] <J_Darnley> "After that it will, however, make sure that the calculated dimension is divisible by n and adjust the value if necessary."
[02:39:30 CET] <nullp0inter> J_Darnley : thats helpful, trying now with -2:480
[02:45:56 CET] <nullp0inter> J_Darnley : that worked! thank you!
[04:04:07 CET] <cone-544> ffmpeg 03Ganesh Ajjanagadde 07master:42868ca569f3: avcodec/jpeg2000: replace naive pow call with smarter exp2fi
[04:04:07 CET] <cone-544> ffmpeg 03Ganesh Ajjanagadde 07master:c8905e0d67f5: swscale/utils: replace pow by exp2
[13:15:15 CET] <cone-442> ffmpeg 03Jean Delvare 07master:e74f1a121e94: avfilter/vf_delogo: round to the closest value
[13:39:11 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:cb93df0dcbd3: avcodec/aacsbr_tablegen: always initialize tables at runtime
[13:58:53 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:00c322014904: lavfi/show_palette: fix memory leak
[13:58:54 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:301c2784b350: lavfi/vf_overlay: fix memory leaks
[13:58:55 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:31f0d555e077: lavfi/vf_alphamerge: fix memory leaks
[13:58:56 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:924fcac52148: lavfi/af_channelmap: fix memory leak
[13:58:57 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:89bbf0197819: lavfi/af_amix: fix memory leak
[15:37:34 CET] <ubitux> 15:02 <Mandarinka> [14:43:44 CET] <BBB> nevcairiel: sse2 would be nice to have, but I think the curve of what kind of system has tends to trend towards higher-end, so sse4 baseline may just be ok
[15:37:36 CET] <ubitux> 15:02 <Mandarinka> Ubitux: I saw this in ffmpeg logs
[15:37:38 CET] <ubitux> 15:02 <Mandarinka> Intel didn't enable SSE4 on any of pre-Sandy Bridge Celerons or Pentiums, those were SSSE3-only until 2011. I don't know if it is meaningful to support such dualcores, but they would probably be good for 720p, while higher clocked ones (desktop ones, after OC, particularly the Westmere-based...) could perhaps be still capable of 1080p if they had assembly available.
[15:37:56 CET] <ubitux> 15:07 <Mandarinka> actually 65nm Core 2 also ends on SSEE3, so things like the original Core 2 Quads are in that group
[15:37:58 CET] <ubitux> 15:07 <Mandarinka> which are old but not hopelessly slow IMHO
[15:38:00 CET] <ubitux> 15:07 <Mandarinka> *SSSE3
[15:38:08 CET] <ubitux> just forwarding some follow up.
[15:38:28 CET] <BBB> I actually have one of those rare pre-sandybridge cpus with sse4 :-p
[15:38:45 CET] <BBB> we indeed used ssse3 as baseline for initial vp9 simd
[15:39:06 CET] <BBB> I just dont have a good solution for hevc that does not involve rewriting everything again
[15:39:16 CET] <nevcairiel> sse4 usage is probably just 1-2 instructions that could be macro'ed if someone cared
[15:40:10 CET] <nevcairiel> I would care if i had the time and knowledge to, but time is short enough as it is that I won't be learning this now ;)
[15:45:27 CET] <durandal_1707> anyone still needs hrtf like filter?
[16:28:36 CET] <cone-442> ffmpeg 03Michael Niedermayer 07master:e6971db12b8a: avformat/matroskaenc: Check codecdelay before use
[16:28:42 CET] <wm4> which distros are still Libav only?
[16:30:48 CET] <atomnuker> wm4: none, I think
[16:31:47 CET] <wm4> interesting
[16:57:39 CET] <cone-442> ffmpeg 03Michael Niedermayer 07master:8cfa912e250d: avformat/flacdec: remove unused return code assignment
[17:53:19 CET] <cone-442> ffmpeg 03Michael Niedermayer 07master:bc8b1e694cc3: avutil/mathematics: Fix division by 0
[18:02:35 CET] <ubitux> http://pastie.org/10621149
[18:02:37 CET] <ubitux> erm
[18:03:03 CET] <ubitux> 0 as DBL_MIN is pretty confusing
[18:03:34 CET] <Daemon404> should have printed ah hexfloat duh
[18:04:52 CET] <ubitux> i just realized DBL_MIN is actually strictly positive
[18:27:44 CET] <cone-442> ffmpeg 03Michael Niedermayer 07master:80ceb4696ab7: avformat/rmdec: Fix use of uninitialized variable
[19:03:28 CET] <atomnuker> https://0x0.st/-68.jpg
[19:04:24 CET] <RiCON> trippy
[19:30:38 CET] <J_Darnley> Spooky, scary skeletons with added scary filter!
[19:31:58 CET] <thardin> spoopy
[20:06:26 CET] <cone-442> ffmpeg 03Alex Agranovsky 07master:7fd1c85e5195: lavf/mpjpegdec: Fixed dereference after null check
[20:25:04 CET] <wm4> why even bother with ganesh
[20:39:54 CET] <cone-442> ffmpeg 03Andreas Cadhalpun 07release/2.4:073fcfe35800: mjpegdec: consider chroma subsampling in size check
[20:39:56 CET] <cone-442> ffmpeg 03Michael Niedermayer 07release/2.4:ab70292fd0c3: avutil/mathematics: Fix division by 0
[20:40:52 CET] <fritsch> nevcairiel: any idea when 2.8.4 is tagged - something still missing?
[20:43:30 CET] <michaelni> fritsch, i wanted to do a 2.8.4 release soon, anything you want backported ?
[20:45:15 CET] <fritsch> michaelni: thx for asking. No nothing that comes directly to my mind. There is currently a bug we have reported upstream concerning mp3 breakage with handbrake, but carl is looking after that
[20:45:53 CET] <fritsch> michaelni: perhaps: avformat/utils: estimate_timings_from_pts - increase retry counter, fixes invalid duration for ts files with hevc codec - then we could drop that from our custom patches
[20:46:12 CET] <fritsch> 2d8c2f1a28073d451c7db31291c333cb15ca3d0b that is
[20:47:33 CET] <michaelni> ok, ill backport that
[20:47:56 CET] <michaelni> will also backport it to other releases i maintain i guess unless it breaks something but i dont expect that
[20:49:45 CET] <fritsch> thx, much - the most critical bug, as said - is this mp3 bug: https://trac.ffmpeg.org/ticket/5047 - it seems handbrake produces such files by default
[20:49:52 CET] <fritsch> sadly I could not reach the handbrake maintainer yet
[20:51:21 CET] <Daemon404> fflogger, file it on their bug tracker
[21:38:30 CET] <wkelleher> howdy folks. working on a patch and I'm wondering if anyone can explain why in_picture->pict_type is being cleared during transcoding.
[21:40:01 CET] <wkelleher> I'd like to have pict_type available on the encoder's input AVFrame so I can optionally use it for scene change info
[21:41:00 CET] <nevcairiel> pict_type in encoder input is used by many encoders to force insertion of key-frames at pre-determined points
[21:41:19 CET] <nevcairiel> if every transcode would just blindly forward that info, it would seriously impact the performance of the encoders
[21:42:20 CET] <wkelleher> ok, that makes sense. how about optionally forwarding?
[21:43:03 CET] <Mavrik> Usually you don't want that forwarded at all, since there's no real gain for it, just quality loss.
[21:43:37 CET] <wkelleher> in this case, my encoder can't adaptively place i-frames
[21:43:57 CET] <wkelleher> but my hevc input stream has nice scene detection
[21:44:23 CET] <wkelleher> so I want to use the HEVC I-frame placement as a hint for the H.264 output
[22:37:02 CET] <cone-442> ffmpeg 03Claudio Freire 07master:124c3759386a: AAC encoder: fix OOB access in search_for_pns
[00:00:00 CET] --- Thu Dec 10 2015
1
0
[00:20:45 CET] <debdog> I have a video which is a tad overexposed, see: http://beggabaur.rocks/daten/shot0003.png
[00:20:45 CET] <debdog> now I wonder what would be the best way to get the grainy/noisy stuff away. by making it darker or using some grain/noise filter (and if so, which one?)?
[00:21:05 CET] <debdog> just to say, I am a total noob when it comes to that video stuff
[00:21:48 CET] <debdog> reading http://ffmpeg.org/ffmpeg-filters.html and found one grain and some noise related filters
[00:32:41 CET] <durandal_1707> depend what kind of noise..
[00:34:03 CET] <debdog> hum, dunno how to explain. noise from overexposed filming. like seen on that shot
[00:34:16 CET] <debdog> which actually is from that said clip
[00:38:04 CET] <debdog> hmm, I think I just try http://ffmpeg.org/ffmpeg-filters.html#toc-colorlevels first
[01:24:51 CET] <nullp0inter> i am trying to resize my videos to be mobile friendly however my ffmpeg command does not seem to be doing what i need it to do: http://pastebin.com/FK9nZfw3 anyone have any ideas?
[01:25:18 CET] <DHE> output file must come last
[01:25:21 CET] <nullp0inter> also, it seems that the audio is choppy and malformed when played on an iphone, no idea why
[01:26:14 CET] <nullp0inter> DHE, ty i will try that now
[01:53:00 CET] <nullp0inter> DHE i did that, but now im getting this error: http://pastebin.com/Vq6S7Raw
[01:53:53 CET] <nullp0inter> the moov part is a second pass
[01:56:55 CET] <jasom> debdog: the 3d denoise is a good place to start with denoising
[01:57:36 CET] <jasom> debdog: and that looks properly exposed; the only clipping is on the spots, which probably should clip
[01:57:54 CET] <nullp0inter> DHE ignore that i had the wrong lines
[01:58:53 CET] <jasom> debdog: https://ffmpeg.org/ffmpeg-filters.html#hqdn3d-1 <-- documentation there
[01:59:47 CET] <nullp0inter> can anyone tell me why i would get this error: Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[02:00:04 CET] <jasom> debdog: you may want to tune the chroma parameters a bit as there appears to be a lot of chroma noise in the shot you posted
[02:02:10 CET] <nullp0inter> this is my command producing that error: http://pastebin.com/fLnTMemT
[02:02:36 CET] <jasom> debdog: maybe 3:4:4:6 as a good starting point for the options
[02:31:08 CET] <cluelessperson> with ffserver, can you just disable the audio stream?
[03:00:24 CET] <relaxed> nullp0inter: pastebin.com your ffmpeg_vid.log
[03:01:38 CET] <relaxed> nullp0inter: you have -c:a copy and -c:a libfdk_aac
[03:02:04 CET] <pzich> there's also a good chance your scale is causing the width to be an odd number, and you need it to be a multiple of of two for 264
[03:04:59 CET] <relaxed> true, use scale=-2:480
[03:49:32 CET] <nedrocks> In order to fix an issue I have with audio streams not starting at the proper times (causes audio sync issues) I need to fill the first block of silence detected with silencedetect filter with.. something. Unfortunately Im having issues grabbing the first silent timestamp from the output of the silencedetect filter (see the marked line here: http://pastebin.com/EingS6EK) Can anyone give me some advice as to how to get this range more
[03:49:33 CET] <nedrocks> easily than parsing output from stderr?
[04:07:49 CET] <waressearcher2> nedrocks: hallo
[05:18:14 CET] <cluelessperson> Hi all. I'm trying to use ffserver, but the problem is I get this
[05:18:14 CET] <cluelessperson> 1.ffm: Pid 8954 exited with status 256 after 0 seconds
[05:18:32 CET] <cluelessperson> pretty much immediately, I think it may be a problem with the ffmpeg line
[05:18:51 CET] <cluelessperson> Launch ffmpeg -loop 1 -i test.mpg
[05:19:04 CET] <cluelessperson> does that look right?
[05:27:39 CET] <Prelude_Zzzzz> hey.. having trouble with vdpau and startx can anyone help?
[05:28:47 CET] <cluelessperson> Here's the full command and output. http://dpaste.com/0EVHGSQ
[05:28:51 CET] <cluelessperson> not sure what it's asking for
[05:29:11 CET] <cluelessperson> [libvpx @ 0xecd900] CQ level 0 must be between minimum and maximum quantizer value (2-31)
[05:29:12 CET] <cluelessperson> ?
[05:54:36 CET] <cluelessperson> at http://cluelessperson.com/stream/ You can see I have ffserver running, listening for 1.ffm at http://cluelesspreson.com/stream/1.webm You can see there's no output.
[05:59:53 CET] <waressearcher2> cluelessperson: hallo
[06:00:03 CET] <cluelessperson> waressearcher2, hi there
[06:00:10 CET] <waressearcher2> cluelessperson: wie geht's ?
[06:00:24 CET] <cluelessperson> waressearcher2, sorry?
[06:00:37 CET] <cluelessperson> german?
[06:01:00 CET] <waressearcher2> deutsch
[06:02:26 CET] <cluelessperson> waressearcher2, How are you?
[06:11:57 CET] <Admin_234234> hey question.. anyone know if vdpau can run without actually startX running ?
[06:12:09 CET] <Admin_234234> like using just the server CLI or whatever
[06:12:12 CET] <Admin_234234> need it for decoding
[07:55:19 CET] <cluelessperson> okay, so I've managed to get somethig streaming, but it only works if the webm/browser is already open, and THEN you start the stream
[08:06:38 CET] <waressearcher2> cluelessperson: es geht's
[08:07:02 CET] <cluelessperson> waressearcher2, :D https://cluelessperson.com/stream/1.webm
[08:52:53 CET] <waressearcher2> cluelessperson: http://www.youtube.com/watch?v=dQw4w9WgXcQ
[11:41:05 CET] <termos> I'm trying to create a 30 minutes delayed stream with FFmpeg and would like the possibility to resume if something happened without having to buffer up the 30 minutes delay on restart. Is there such a feature in FFmpeg?
[13:52:01 CET] <dantti> does somenone knows how a m3u8 playlist should look like if I have an infinite .ts file?
[14:05:14 CET] <DHE> I don't think that's supported by HLS
[14:11:05 CET] <dantti> DHE: doesn't HLS stands for Live stream? how can it be live otherwise?
[14:11:37 CET] <flux> by using multiple files?
[14:12:56 CET] <flux> I don't know however if ffmpeg is suitable for creating a live HLS..
[14:13:51 CET] <dantti> flux: but if you have multiple files your playlist has an end no?
[14:14:23 CET] <DHE> typically you delete the older videos after some period of time. there's an option for that under -hls_flags
[14:14:24 CET] <flux> I think the purpose is to update the playlist
[14:14:27 CET] <DHE> I'm doing live HLS. right now
[14:16:57 CET] <dantti> right, atm I have my own http stuff that writes the mpeg-ts directly to the socket not to write files
[14:17:10 CET] <dantti> so I guess I'd need to have a playlist with fake .ts files
[14:19:09 CET] <flux> I understand one idea behind these chunked representations is that they are easier to cache (ie. in a content delivery network) than big streaming files
[14:20:57 CET] <flux> does ffmpeg have live DASH streaming support? seems like it has some required parts but not a 'complete' solution
[14:21:21 CET] <DHE> having used HLS quite a bit there's more to it than that. clients seem to always download a whole chunk before they start playing - they don't do live playing from an HTTP transfer. so smaller chunks (to a point) are encouraged for faster playback initialization
[14:21:51 CET] <flux> I guess that's something a player can choose to do otherwise
[14:22:11 CET] <flux> but the point in downloading a full chunk before playing might be that the user is able to determine the connection bitrate, so they know which fragment to download next
[14:22:44 CET] <DHE> that seems to be the trend I've seen. so I chose 6 seconds as my starting point for chunking size
[14:23:01 CET] <DHE> dantti: ffmpeg has `-f hls` where you specify the .m3u8 file as the write target
[14:23:26 CET] <flux> https://github.com/sannies/rtp2dash with ffmpeg seems to be pretty close to a complete solution. but.. java :)
[14:34:50 CET] <dantti> DHE: how do you mean m3u8 as a write target? I want to avoid writing to files as I think it might damage internal storage
[14:34:59 CET] <DHE> wat?
[14:35:14 CET] <dantti> also I will only support 1client at time for vieweing the tablet's camera
[14:35:21 CET] <DHE> sounds more like you want live RTSP streaming
[14:35:43 CET] <dantti> well hls is more easily supported in ios and android as player
[14:37:19 CET] <dantti> at least afaik
[14:37:53 CET] <flux> dantti, you have flash internal storage?
[14:38:06 CET] <flux> dantti, maybe you can use ramdisk for storing the file
[14:39:27 CET] <dantti> flux: last time I checked a ramdisk requires root, also I could also store the files in a buffer on the app
[14:40:04 CET] <dantti> but writting to a socket doesn't seems like a bad decision after all it's live :P
[14:40:19 CET] <flux> ramdisk on what?
[14:40:36 CET] <flux> what kind of device do you have that uses flash but you don't have access to root?
[14:40:39 CET] <dantti> android
[14:40:50 CET] <dantti> those cheap android tablets
[14:40:55 CET] <flux> how about /tmp of /var/run/tmp? I don't know if they are limited.
[14:41:08 CET] <flux> (actually just /var/run)
[14:41:17 CET] <flux> they might be tmpfs
[14:41:48 CET] <flux> alternatively have your own program that keeps the data in the memory and have the web server query the data from it..
[14:41:49 CET] <dantti> android is such a jungle that I think the vendor can also change that..
[14:42:03 CET] <dantti> well that's the second idea
[14:43:17 CET] <dantti> but then the m3u8 should have say 5 segments, and does the player would loo it?
[14:45:20 CET] <flux> loop it? no, I don't expect it to loop it.
[14:45:37 CET] <flux> https://developer.apple.com/library/ios/technotes/tn2288/_index.html has examples of what the .m3u8 looks like while live streaming
[14:47:05 CET] <dantti> flux: thanks I'll have a look
[14:48:52 CET] <dantti> flux: so, after the end of the playlist the player fetches the m3u8 agains and it has different sequenceX.ts files right?
[14:48:59 CET] <flux> yes
[14:49:17 CET] <dantti> ok, now it makes a bit more sense :)
[16:23:23 CET] <debdog> jasom: thanks a lot! it wasn't easy and I needed quite some approaches. the original shot again: http://beggabaur.rocks/daten/shot0003.png and the result http://beggabaur.rocks/daten/shot0001.png
[16:23:23 CET] <debdog> I wasn't able to get rid of the noise entirely, then the other parts of the vid would have been bad. but it looks very good now!
[16:23:23 CET] <debdog> I could PM the URL to the entire video later, if you're interested. it's a laser show at Europa Park, Germany. we intend to upload it to vimeo or such, it'll be public then.
[16:35:34 CET] <eightfold> im trying to create a video encoded with h.264 that will be playable in safari
[16:35:42 CET] <eightfold> im not succeeding
[16:36:28 CET] <eightfold> via the html5 video element...
[16:36:41 CET] <eightfold> what ive done: ffmpeg -f gif -i input.gif -vcodec libx264 -level 21 -refs 2 -b 1100K -bt 1100K -threads 0 output.mp4
[16:36:49 CET] <eightfold> does safari need a mov container?
[16:40:59 CET] <kepstin> in safari on what os? this differs between desktop and mobile, I think
[16:41:55 CET] <kepstin> I think safari on mobile requires hls for video streaming
[16:42:08 CET] <eightfold> ive just tried on os x
[16:42:19 CET] <eightfold> could it be a mime type problem perhaps?
[16:47:10 CET] <TD-Linux> eightfold, you can't live stream a mp4 container
[16:52:27 CET] <kepstin> eightfold: assuming you're not live streaming (which it doesn't look like you are), you could try adding "-movflags faststart", which might help the browser load the video over http...
[16:52:51 CET] <kepstin> other than that, start looking in the browser web inspector console and network tab for issues...
[16:53:49 CET] <eightfold> no live streaming
[16:57:04 CET] <durandal_1707> debdog: what you used?
[16:58:24 CET] <cluelessperson> http://cluelessperson.com/stream/
[16:58:35 CET] <cluelessperson> I got it working. :)
[17:00:07 CET] <eightfold> hmm, did not help
[17:00:14 CET] <eightfold> the -movflags faststart
[17:00:22 CET] <eightfold> anything else in my line looking unnecessary
[17:00:29 CET] <eightfold> cut n paste job, of course
[17:17:31 CET] <eightfold> this is a mystery, nothing can get a h.264 encoded video to play in safari
[17:18:12 CET] <eightfold> using <video autoplay loop muted><source type="video/mp4" src="test.mp4"><source type="video/webm" src="test.webm"></video>
[17:23:13 CET] <debdog> durandal_1707: I've tried a lot of stuff, cannot find the command line atm. but the fines clip only was compressed, which made it a tad darker, and reduced gamma for about 10 %
[17:24:14 CET] <debdog> s/fines/final/
[17:50:23 CET] <qubodup> hello, can I record a screen capture at 1 frame per second but have the output file play it at 30fps without additional steps? http://superuser.com/questions/1010940/
[17:59:44 CET] <c_14> qubodup: use -framerate 1 as an input option and -r 30 as an output option
[18:01:07 CET] <dantti> on a new hls segment should I mark AVFrame->key_frame = 1?
[18:06:06 CET] <qubodup> c_14: unfortunately this doesn't work. the playback speed of the resulting video is 1fps
[18:07:31 CET] <qubodup> c_14: ffmpeg -framerate 1 -f x11grab -s 1280,720 -i :0.0+0,0 -vcodec libx264 -crf 0 -preset ultrafast -r 30 out.mkv
[18:07:39 CET] <popara> Hello Guys. One question
[18:07:55 CET] <popara> How i can make FFmpeg NOT to edit any timestamp from the input video?
[18:08:27 CET] <popara> The problem is that if an INPUT loose sound, but later come again, the FFmpeg is keep restreaming it without sound because it has mess up with the timestamps (i think)
[18:33:57 CET] <c_14> you can try copyts and/or vsync 0
[18:35:18 CET] <c_14> qubodup: use -vf setpts=N/(30*TB)
[18:45:07 CET] <DHE> <dantti> on a new hls segment should I mark AVFrame->key_frame = 1? # yes. the hls muxer will split the video on keyframes normally if you use that.
[18:51:03 CET] <excalibr> Not sure if this is a proper place to ask but anyone has any clue how gfy animated images are created? Can use you use ffmpeg to create gfy?
[18:51:56 CET] <furq> excalibr: ffmpeg -i source.gif dest.mp4
[18:52:05 CET] <furq> or dest.webm
[18:53:47 CET] <excalibr> furq, gfy format is essentially that? But how optimization on non changing region of the images is done?
[18:54:37 CET] <excalibr> Cause I heard or read somewhere that optimization is what made gfy much smaller and better than regular gif
[18:54:59 CET] <dantti> DHE: is the hls server api available for apps to use? tho I think being able to reconfigure the camera resolution depending on the connection might be easier if I implement that myself I guess
[18:58:09 CET] <prelude2004c> crazy disconnects :(
[18:58:19 CET] <prelude2004c> did anyone reply to something i did not see ?
[18:58:30 CET] <prelude2004c> icechat crashed :(
[19:00:12 CET] <[SLiM]D12> hey i have a dumb question
[19:00:33 CET] <[SLiM]D12> i know to download a video from m3u8 it's generally "ffmpeg -i "master.m3u8" -c copy output.ts
[19:00:33 CET] <prelude2004c> slim , no such thing... you haven't read mine :P haha
[19:00:44 CET] <[SLiM]D12> is there a way to define a specific bitrate of the file i want from the m3u8?
[19:00:51 CET] <[SLiM]D12> like not the best quality, but 2nd best for example?
[19:01:20 CET] <prelude2004c> slim, look inside that m3u8 .. if it has multi bit rates generally you can just go to that m3u8 directly for the desired bit rate
[19:01:33 CET] <[SLiM]D12> yeah i tried that, doesn't work
[19:01:35 CET] <prelude2004c> there is a master M3u8 , then sub m3u8s ( one for each bit rate ) and then the .ts files listed
[19:01:42 CET] <[SLiM]D12> gives me a 403 forbidden
[19:01:48 CET] <[SLiM]D12> even though i can download the single ts files within the m3u8
[19:01:59 CET] <[SLiM]D12> i get a forbidden when pointing to any m3u8 other than the master
[19:02:22 CET] <prelude2004c> sounds like a permissions issue ... odd really
[19:02:29 CET] <furq> excalibr: the optimisation is that it's a video
[19:02:31 CET] <[SLiM]D12> i know you can do it in livestreamer, and that works, but there are 2 720p streams, and livestreamer's picking the lower quality one
[19:02:38 CET] <[SLiM]D12> i want to pick the higher quality 720p stream
[19:02:46 CET] <furq> gif doesn't do inter-frame prediction
[19:17:02 CET] <prelude2004c> so any suggestions if not vdpau .. basically i want to lower cpu decoding and push it to GPU in order to do the transcosing
[19:17:24 CET] <prelude2004c> encoding is already working with nvenc so thats good
[19:18:31 CET] <prelude2004c> the probelm now is the decoding part that is still using cpu's to decode and then pass to GPU for encode. i want o use up the CPU decoding capabilies.. any suggestions or pointing in the right direction would be helpful
[19:25:17 CET] <lindenk> Hey, so I have a video that was recorded on a phone and, when played in mpv and vlc, it works fine, however, if I attempt to play it in windows media player, it's rotated 90 degrees counterclockwise. I attempted to rotate it with ffmpeg, however that just seemed to turn it 90 clockwise regardless of what I played it with. I'm guessing this is a problem with the metadata associated with the video, and I've
[19:25:19 CET] <lindenk> tried -metadata:s:v, however this made the video unplayable in wmp, but still right side up with mpv and vlc. Any ideas?
[19:25:48 CET] <lindenk> the video is encoded as an mp4
[21:05:33 CET] <floyddotnet> hello, i try to find out the right settings to convert a 720p h264 source to h265 720p with less quality losses. so i try 2-pass vbr 4 and also 1-pass crf 21 but both are very washy. take a look at http://screenshotcomparison.com/comparison/153693 and http://screenshotcomparison.com/comparison/153694 .. can you give me some hints what i'm doing wrong?
[21:24:33 CET] <BtbN> floyddotnet, you won't magicaly make it look better by re-encoding. Only worse.
[21:25:21 CET] <floyddotnet> not better, but compareable?
[21:25:35 CET] <floyddotnet> same quality less file size
[21:26:00 CET] <fritsch> yeah and 4 times the power consumption while decoding ...
[21:26:04 CET] <fritsch> hard disk space is cheap
[21:26:14 CET] <fritsch> (not mentioning the insane slow hevc encoding)
[21:28:04 CET] <floyddotnet> this is not the question ;) btw the target hardware has h265 4k@60fps hw-decoder
[21:28:33 CET] <fritsch> whatever you wast energy while transcoding
[21:28:36 CET] <fritsch> and reduce quality
[21:29:00 CET] <fritsch> if you are at it encode it 10 bits ... as it "compresses better" (TM) (R)
[21:31:00 CET] <floyddotnet> 10 bits, yes
[21:32:48 CET] <fritsch> yeah, no comment
[21:33:00 CET] <fritsch> you were a h264 hi10p user, too right?
[21:33:24 CET] <floyddotnet> oh .. you mean the source
[21:33:46 CET] <fritsch> no
[21:33:48 CET] <floyddotnet> i'm not sure .. Decodiertes Format: Planar 4:2:0 YUV
[21:34:01 CET] <fritsch> there is no source with 10 bit for bluray
[21:34:32 CET] <floyddotnet> no bluray
[21:34:49 CET] <fritsch> there is no mainline native content in 10 bit as of now
[21:35:06 CET] <fritsch> but coming soon
[21:36:07 CET] <floyddotnet> ffprobe-output for the source: Stream #0:0(eng): Video: h264 (High), yuv420p, 1280x536 [SAR 1:1 DAR 160:67], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
[21:36:28 CET] <fritsch> keep it as it
[21:36:31 CET] <fritsch> it won't get better
[21:37:18 CET] <floyddotnet> is there no way to convert it to h265 with near equal quality?
[21:37:41 CET] <fritsch> it makes no sense ...
[21:38:01 CET] <floyddotnet> this is not the question ;)
[21:38:07 CET] <fritsch> and at this resolution it also makes no sense
[21:38:45 CET] <floyddotnet> why .. h265 should resulting in a smaller file
[21:39:11 CET] <floyddotnet> estimated half file size at same qualitiy if i'm understand it right
[21:39:44 CET] <fritsch> :-(
[21:39:47 CET] <fritsch> yeah - read up again
[21:39:55 CET] <fritsch> or don't watch too much commercials
[21:40:17 CET] <floyddotnet> nobody say's something about commercials
[21:40:29 CET] <fritsch> argh - your information is wrong
[21:40:38 CET] <fritsch> you did watch too much commercials
[21:40:46 CET] <fritsch> about hevc
[21:41:00 CET] <floyddotnet> oh i understand .. sorry :)
[23:14:40 CET] <qubodup> c_14: -vf setpts=N/(30*TB) while recording doesn't seem to work
[23:41:04 CET] <prelude2004c> hey guys.. stumbled upon " NVCUVID " ... anyone know i could use that with ffmpeg ? i can't seem to find any good documentation online
[23:41:30 CET] <tp_> its like 30% savings for h265, but reencoding a h264 video for that reason is just wrong
[23:44:55 CET] <prelude2004c> tp that for me ?
[23:51:23 CET] <tp_> nope :P
[00:00:00 CET] --- Thu Dec 10 2015
1
0
[00:49:03 CET] <kierank> michaelni: ever looked at in-place idwt?
[02:52:50 CET] <cone-361> ffmpeg 03Marton Balint 07master:97795ba6c3a5: lavf/mxfdec: fix seeking before the first keyframe
[03:56:58 CET] <cone-361> ffmpeg 03foo86 07master:704654ea170c: avcodec/libdcadec: fix request_channel_layout
[03:56:59 CET] <cone-361> ffmpeg 03foo86 07master:704b278361ad: avcodec/libdcadec: implement logging callback
[03:57:00 CET] <cone-361> ffmpeg 03foo86 07master:de12aa51b6bf: avcodec/libdcadec: add some useful options
[03:57:01 CET] <cone-361> ffmpeg 03foo86 07master:ff6dd5851bff: avcodec/libdcadec: honor -err_detect option
[05:06:50 CET] <rcombs> ubitux: still sitting on a branch
[08:14:06 CET] <cone-607> ffmpeg 03Matthieu Bouron 07master:bd0a9f603d0c: fate/api-codec-param: fix codec context leak
[08:14:06 CET] <cone-607> ffmpeg 03Matthieu Bouron 07master:102842d5fbb7: fate/api-{jpeg,png}-codec-param: add missing codec dependencies
[08:14:06 CET] <cone-607> ffmpeg 03Matthieu Bouron 07master:5aca33c2cfc3: swscale/arm: add ff_nv{12,21}_to_{argb,rgba,abgr,bgra}_neon_16
[09:43:57 CET] <cone-607> ffmpeg 03Luca Barbato 07master:5f3a081b42b8: avi: Spin out the logic to position to the next non-interleaved stream
[09:43:58 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:6a6cfeb2e7c3: Merge commit '5f3a081b42b84404a40a52c80ef7a354cf048c56'
[09:50:19 CET] <cone-607> ffmpeg 03Kylie McClain 07master:bf12a81cc67d: configure: Replace `pr` since it is not provided by busybox
[09:50:20 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:d1b7cafae149: Merge commit 'bf12a81cc67d62dd45c58e29fa0e9177331cc151'
[09:51:02 CET] <cone-607> ffmpeg 03Martin Storsjö 07master:1077d8c8455b: configure: Add -framework CoreVideo when building the avfoundation indev
[09:51:03 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:8076711d4cf9: Merge commit '1077d8c8455b27688de37cd04f8cc253fb37944d'
[09:51:39 CET] <cone-607> ffmpeg 03Luca Barbato 07master:c5eb279e240a: g723: Add missing header
[09:51:40 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:3f9c64831cac: Merge commit 'c5eb279e240af6b7228a624cd7193732f2d5adaa'
[10:01:44 CET] <cone-607> ffmpeg 03Luca Barbato 07master:b805482b1fba: aac: Provide more information on the failure message
[10:01:45 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:92186f2d1006: Merge commit 'b805482b1fba1d82fbe47023a24c9261f18979b6'
[10:04:37 CET] <cone-607> ffmpeg 03Luca Barbato 07master:f7edcac040f7: avpicture: Suppress warning from deprecated code
[10:04:38 CET] <cone-607> ffmpeg 03Luca Barbato 07master:7d36474d1908: imgconvert: Re-enable the deprecation warnings
[10:04:39 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:68cb0dc8a3e8: Merge commit 'f7edcac040f73635fc1127489c9bb29ca8b43532'
[10:04:40 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:c9dbff60c69d: Merge commit '7d36474d1908d6267d4e11d4d9909f9604bd0c81'
[10:06:45 CET] <cone-607> ffmpeg 03Luca Barbato 07master:6788baebb368: log: Use a do {} while (0) for dlog
[10:06:46 CET] <cone-607> ffmpeg 03Hendrik Leppkes 07master:8142daca44d8: Merge commit '6788baebb3680d447eabdadf3f5743c8470a4611'
[10:38:35 CET] <xhpohanka> Hi, I need to reencode raw bitstream, where two 12bit pixels are packed into three bytes (pixel0[7:0] | pixel0[11:8] pixel1[3:0] | pixel1[11:4]). It seems to me that such pix_fmt is not yet supported so I'm trying to add it. If I understand it correctly I need to add format into avutil and also conversion function into swscale. Am I right, please?
[10:39:18 CET] <nevcairiel> yes, however note that handling such packed formats in swscale is rather annoying, to say the least.
[10:44:09 CET] <xhpohanka> I'm looking at monow format. It is at least similar (copying single bits). How do I now that output buffer is 16bit to store my 12bit pixels?
[10:58:30 CET] <xhpohanka> Or maybe better posed question. I see that most of pix_fmts provide lumToYV12 function but I need to keep all 12 bits. Can I handle that somehow?
[11:05:55 CET] <nevcairiel> depending on how your format is defined, it would expect to get a 16 bit buffer in which you can store your 12-bits entirely
[11:14:41 CET] <xhpohanka> at first i need to view the stream in ffplay, which functions should I implement in swscale? lumToYV12? YV12 has three planes (8bit Y and subsampled UV), I do not understand how to handle monochrome 12 bit there
[11:15:34 CET] <nevcairiel> lumToYV12 only handles the luma, there is a separate function for chroma, so its only the first plane
[12:07:24 CET] <ubitux> lol
[12:07:38 CET] <ubitux> the behaviour of this guy is surreal :)
[12:08:32 CET] <nevcairiel> speaking of surreal, why is it that adding an input format to swscale was relatively easy, but trying to support the same format as an output is making me give up
[12:20:42 CET] <nevcairiel> luckily i dont really need the output format support
[13:25:11 CET] <michaelni> kierank, yes, inplace idwt is fun
[13:27:26 CET] <kierank> michaelni: Is it hard?
[13:29:37 CET] <michaelni> no but coefficients must be initially placed in a somewhat fragmented way IIRC (like vertical + horizontal interlacing in multiple levels)
[13:30:33 CET] <michaelni> there are possibly also other ways to do it
[13:31:44 CET] <michaelni> IIRC snows idwt does use that funny ordering for the vertical idwt
[13:32:15 CET] <michaelni> i think i didnt do it horizontally to avoid fragmented memory accesses
[13:42:08 CET] <nevcairiel> 15 minutes wondering why my hwaccel doesnt work, just to remember that mingw just doesnt have the headers <.<
[13:55:04 CET] <nevcairiel> I faintly remember some discussion about concerns when using the same hwaccel pixfmt for different underlying pixel formats (ie. 420 and 444, or 420 and 420p10), anyone remember anything more concrete?
[13:55:08 CET] <nevcairiel> wm4 maybe?
[14:04:08 CET] <nevcairiel> The problem of course is that weird things happen when avcodec would now suddenly want to start decoding 10-bit hevc content through dxva2 but the user-app isn't aware of this
[14:32:37 CET] <cone-607> ffmpeg 03Rostislav Pehlivanov 07master:6e5dbe7267fc: aacenc_tns: use 4 bits for short windows
[14:32:38 CET] <cone-607> ffmpeg 03Rostislav Pehlivanov 07master:4c5136a48ba8: aacenc_ltp: disable LTP with high lambda values
[14:43:21 CET] <BBB> nevcairiel: hm, so & for hevc simd, I think keeping things as-is for now is probably ok
[14:43:44 CET] <BBB> nevcairiel: sse2 would be nice to have, but I think the curve of what kind of system has tends to trend towards higher-end, so sse4 baseline may just be ok
[14:43:55 CET] <BBB> avx2 certainly does help our appeal
[14:44:42 CET] <nevcairiel> who cares about appeal, is it actually faster?
[14:45:09 CET] <nevcairiel> personally I would like to see the 32-bit support though, even when most people pretend to not care, many of my users still run it
[14:45:28 CET] <ubitux> yes, i saw that in the last survey
[14:46:00 CET] <ubitux> some ppl saying avx2 (which is not that spread) doesn't matter but for low end pc optims are actually useful
[14:46:00 CET] <nevcairiel> but unfortunately my SIMD fu is too limited to try to do this on my own in any realistic timeframe
[14:46:32 CET] <BBB> I dont care enough about hevc to spend time on it, sadly
[14:48:27 CET] <nevcairiel> jamrial and kuroso once showed a bit of interest, maybe adapting existing simd is more something they would get into than writing new stuff
[14:49:06 CET] <ubitux> so we have these optims since ~ may 2014, right?
[14:49:44 CET] <nevcairiel> i think so
[14:49:49 CET] <ubitux> actually april
[14:49:54 CET] <ubitux> ok
[14:50:01 CET] <nevcairiel> but the MC optims are a bit in the rough
[14:50:20 CET] <nevcairiel> most of the others have been cleaned up and optimized, while the MC stuff is mostly verbatim from OpenHEVC
[14:50:33 CET] <nevcairiel> which shows in some areas
[14:52:11 CET] <BBB> the idct is the outstanding area
[14:52:20 CET] <nevcairiel> that doesnt exist at all, yes
[14:56:10 CET] <atomnuker> just heard from someone the ffmpeg flac encoder is better than libflac
[14:56:20 CET] <atomnuker> how much truth is there in that statement?
[14:56:26 CET] <nevcairiel> define better
[14:56:34 CET] <nevcairiel> faster? smaller files? sounds better?
[14:56:35 CET] <atomnuker> compression
[14:56:40 CET] <nevcairiel> (hint: one of those is a trap)
[14:56:47 CET] <atomnuker> rotational velocidensity degradation too
[15:02:24 CET] <TD-Linux> this sounds trivial to test
[15:07:59 CET] <RiCON> wasn't the flac adapted from flake?
[15:08:04 CET] <RiCON> native flac encoder*
[15:09:38 CET] <ubitux> same author
[15:10:39 CET] <RiCON> it was faster and had 4 extra compression levels compared to libflac at the time
[15:15:20 CET] <BtbN> I wonder which nvidia driver still supports NVENC SDK 6.
[15:23:04 CET] <durandal_1707> why morons close git pull requests?
[15:29:50 CET] <rcombs> nevcairiel: I suggested a while back in #libav that there should be some way to specify the stream's actual bit depth, planes, subsampling, etc&, independently of the pixel format it's actually being decoded to
[15:31:15 CET] <rcombs> like, you might decode an H.264 High bitstream to yuv420p or nv12 or any number of opaque formats, but regardless the actual stream is still 4:2:0 8bit/sample YUV
[15:31:52 CET] <BBB> thats not as easy as it sounds
[15:32:24 CET] <BBB> like, for vp9, the residual is completely differently coded between the two, that is, the techniques are the same, but the meaning of specific integer values is different and not easily translated without a performance hit
[15:32:50 CET] <rcombs> I have no idea what any of that means
[15:36:07 CET] <BBB> its not trivial to decode a 10bit vp9 bitstream to 8bit
[15:36:15 CET] <BBB> I believe for h264 its slightly easier but still not exactly trivial
[15:37:27 CET] <rcombs> sure, makes sense
[15:39:13 CET] <rcombs> not sure what that has to do with this, though
[15:39:45 CET] <BBB> youre suggesting to decode a high h264 bitstream to 8bpp yuv420p
[15:39:51 CET] <BBB> Im saying thats not as easy as it looks :)
[15:40:53 CET] <rcombs> I said High, not High 10
[15:41:18 CET] <rcombs> (and that was just an example)
[15:42:17 CET] <BBB> oh sorry misunderstood
[15:42:31 CET] <BBB> sorry about that
[15:42:57 CET] <BBB> so youd like to add, say, nv12 decoding into the decoder?
[15:50:39 CET] <rcombs> BBB: the software decoder? I mean, I guess that might be useful but it's not what I'm saying
[15:51:02 CET] <rcombs> BBB: I'm just saying that lavc should expose the stream's characteristics separately from the pixel format being decoded to
[15:54:29 CET] <nevcairiel> for hwaccel you can kinda look at sw_pix_fmt
[15:55:02 CET] <nevcairiel> not that its that important, or well, was until now, since all hwaccels only decoded 420p8
[15:55:58 CET] <nevcairiel> but what I'm really after I suppose is a flag to allow hwaccels to expose formats other than 420p8
[15:56:14 CET] <nevcairiel> so a user app could say "I know of these things", and wont just cause issues
[15:57:17 CET] <nevcairiel> the dxva2 specific hwaccel context has a flags field, i could throw one in there
[15:57:26 CET] <nevcairiel> however, it might be nice to have something central for all hwaccels
[15:58:42 CET] <BBB> agreed
[15:59:09 CET] <BBB> I found it kind of strange that we use pix_fmt to indicate that something is a hardware decoded picture
[15:59:53 CET] <rcombs> this came up originally because I wanted parsers to set pix_fmt
[15:59:54 CET] <nevcairiel> i dont mind that part, it describes the format of the AVFrame, which is accurate in that sense
[15:59:58 CET] <BtbN> Well, it kind of does make sense
[16:00:25 CET] <rcombs> but someone pointed out that that doesn't really make sense, because lavu/lavc pixel formats aren't inherent to a stream
[16:05:03 CET] <nevcairiel> in other news my P010 processing in swscale in plain dumb C sure is slow :D
[16:06:10 CET] <wm4> nevcairiel: yes; courmisch was a fan of creating a new pixfmt for each hw format, but nobody else liked it
[16:07:44 CET] <nevcairiel> adding new formats is the cheap way out
[16:08:21 CET] <nevcairiel> the current hevc dxva2 hwaccel supports everyhting required for 10-bit decoding
[16:08:33 CET] <nevcairiel> its just not turned on because I'm not sure how to protect it from breaking everywhere :D
[16:12:25 CET] <nevcairiel> unfortunately, we don't seem to have a logical place to add such a flag - other than making it hwaccel specific
[16:14:53 CET] <nevcairiel> we already have AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH
[16:14:57 CET] <nevcairiel> but no field to really set it on
[16:27:22 CET] <kierank> where do all these ffmpeg frame drops come from?
[16:27:26 CET] <kierank> what does it even mean
[16:27:35 CET] <kierank> drop=166?
[16:28:38 CET] <durandal_1707> pts?
[16:29:40 CET] <wm4> nevcairiel: well I don't know, maybe pixfmts should really be dynamic instead of fixed (so new pixfmts can be dynamically created at runtime with various specific attributes ike chroma subsampling, depth, hw format, etc.)
[16:30:01 CET] <wm4> and if not that, at least create a common mechanism to identify hw formats for hw accels
[16:30:02 CET] <nevcairiel> that sounds like an api change i dont want to do now :p
[16:30:52 CET] <kierank> it's raw video
[16:31:37 CET] <wm4> g-b wanted to do something like this (and actually unify all hwaccel pixfmts into 1)
[16:33:37 CET] <nevcairiel> there is always some sort of long-term plan to fix everything :)
[16:33:46 CET] <nevcairiel> in the meantime, i guess i'll just fix it dxva2 specific :p
[16:34:46 CET] <nevcairiel> I could just not fix it and force user apps to their hwaccel code by actually checking the formats they support
[16:34:50 CET] <nevcairiel> but thats probably evil
[16:37:23 CET] <wm4> why would user apps need to change something?
[16:37:29 CET] <wm4> they have to do the profile mapping themselves
[16:37:57 CET] <nevcairiel> i'm sure there is plenty apps that dont check any profiles
[16:38:10 CET] <wm4> these are buggy then
[16:38:16 CET] <nevcairiel> get_format is only called for 420 8-bit after all, so the need to check a profile is not really given
[16:38:25 CET] <wm4> but having profile mapping in lavc would be nice too
[16:38:29 CET] <wm4> (like vdpau has)
[16:38:48 CET] <wm4> wait what
[16:38:55 CET] <wm4> get_format is not called for 10 bit?
[16:39:10 CET] <nevcairiel> strictly speaking it is, but the list of formats does not include the hardware formats then
[16:39:36 CET] <nevcairiel> it only offers to use a hardware format on 420 8-bit
[16:40:08 CET] <nevcairiel> so if you just assume it can decode it fine, it'll work on 99% of all content anyway
[16:41:06 CET] <nevcairiel> now enter hevc 420 10-bit decoding, which requires you to pick a different decoder device and a different surface format for dxva2, and if you don't, everything breaks
[16:41:48 CET] <wm4> that sounds fucked up
[16:41:59 CET] <wm4> shouldn't it add the dxva hwaccel pixfmt?
[16:42:19 CET] <nevcairiel> I have no clue what you are saying
[16:43:45 CET] <nevcairiel> All I'm saying is that any half-naive dxva2 hwaccel user app will likely break if it suddenly starts to offer 10-bit decoding without any safeguards
[16:44:11 CET] <wm4> if I understand this right, the decoder entry point GUID is different for 10 bit formats?
[16:44:16 CET] <nevcairiel> yes
[16:44:32 CET] <wm4> so where's the problem? an API user would have to use that to cause real problems
[16:45:12 CET] <nevcairiel> the problem is that they just see "codec id HEVC, pixfmt DXVA_VLD, lets set up the default hevc dxva2 decoder"
[16:45:13 CET] <wm4> I recently had to fix profile checking in my own dxva code (which is really stolen from ffmpeg_dxva.c btw.), and it simply decoded 10 bit as 8 bit (with the usual artifacts)
[16:45:25 CET] <wm4> their own fault then
[16:45:42 CET] <wm4> you get equally fucked with h264 if you do this
[16:45:44 CET] <nevcairiel> get_format does not offer you the dxva pixfmt if its a 10-bit stream
[16:45:49 CET] <nevcairiel> not for hevc or h264
[16:45:55 CET] <nevcairiel> never has
[16:46:53 CET] <wm4> I don't remember when this happened, then
[16:47:12 CET] <wm4> but still, including the dxva format with 10 bit is less broken than not doing it
[16:47:21 CET] <wm4> if you really want to go this way, you have to add a new dxva pixfmt
[16:48:07 CET] <nevcairiel> I could just add a flag in the dxva_context which the user can set to indicate he knows wtf he is doing
[16:48:49 CET] <nevcairiel> or somewhere else
[16:49:01 CET] <wm4> isn't that what vdpau does?
[16:49:06 CET] <nevcairiel> it is
[16:49:14 CET] <nevcairiel> well kind of
[16:50:42 CET] <nevcairiel> the thing is, you can get away just fine without any profile checks right now
[16:51:00 CET] <nevcairiel> you would need a rather specific bitstream to run into that is not "Main" profile but still 4:2:0 8-bit
[16:51:47 CET] <nevcairiel> I could just enable it and claim that it always was the callers responsibility to check profiles
[16:52:23 CET] <wm4> I certainly didn't get away without a check
[17:01:53 CET] <nevcairiel> what profiles are there, maybe lossless?
[17:02:44 CET] <nevcairiel> technically you could use any higher profile and encode 4:2:0 8-bit in it, using some of the extra features
[17:02:49 CET] <nevcairiel> but i dont think i've ever seen this
[17:05:05 CET] <wm4> well, I think I just decoded 10 bit as 8 bit with dxva, but now I'm not so sure anymore
[17:05:33 CET] <nevcairiel> unless you hacked up avcodec, it wont let you do that
[17:08:01 CET] <nevcairiel> changes to user-code arent that complex https://github.com/Nevcairiel/FFmpeg/commit/264b3aaa99a70fde0f2664eb8fd26e1…
[17:08:14 CET] <nevcairiel> (P010 is not in master, support is added in an earlier commit)
[17:09:38 CET] <wm4> where does it tell lavc to allow 10 bit?
[17:09:52 CET] <nevcairiel> nowhere, that branch just enabled it
[17:10:14 CET] <wm4> what's P010 anyway? 10 bit packed in 16 bit MSB?
[17:10:58 CET] <nevcairiel> pretty much, MS has a page with images and everything https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).…
[17:11:12 CET] <nevcairiel> that github branch also adds P010 pixfmt and swscale input support
[17:11:54 CET] <wm4> hm looks like this format can be interpreted exactly like 16 bit yuv
[17:12:11 CET] <nevcairiel> not really, the chroma is interleaved, like NV12
[17:12:26 CET] <wm4> I mean, looking at its components
[17:12:46 CET] <nevcairiel> you could pretend its 16-bit and avoid a shift
[17:12:53 CET] <nevcairiel> i opted to actually shift in swscale however
[17:13:27 CET] <wm4> I assume that gives you room for SIMD overflow bits (like it was discussed so often)
[17:15:00 CET] <kierank> yup
[17:15:06 CET] <wm4> hm, there's also crap like Y210
[17:15:13 CET] <wm4> "Packed, 4:2:2, 10-bit."
[17:15:18 CET] <nevcairiel> yeah these fully packed formats are magic
[17:15:23 CET] <nevcairiel> but i've not seen them used for anything
[17:15:31 CET] <wm4> good
[17:16:15 CET] <nevcairiel> although Y210 isnt too bad
[17:16:25 CET] <nevcairiel> its just 16-bit YUY2
[17:16:34 CET] <nevcairiel> 2 byte per component
[17:16:36 CET] <nevcairiel> no bit packing
[17:16:39 CET] <wm4> (bad enough)
[17:16:52 CET] <nevcairiel> Y410 is really evil, where they pack 3x 10-bit into 32-bit
[17:16:54 CET] <nevcairiel> with 2 bits of alpha
[17:16:55 CET] <nevcairiel> :D
[17:17:09 CET] <wm4> with subsampling?
[17:17:17 CET] <nevcairiel> nah, the 4 in the name suggests 444
[17:17:24 CET] <wm4> then it's not that bad either
[17:17:52 CET] <nevcairiel> the numbers are pretty nice, 0/2/4 for the subsampling (420, 422, 444), followed by the bitdepth
[17:18:00 CET] <nevcairiel> P for planar, Y for packed
[17:18:08 CET] <nevcairiel> easy to remember ;)
[17:20:43 CET] <nevcairiel> in any case, P010 is the only of interest for a while, hardware is unlikely to adopt any higher formats for the next couple years
[17:37:34 CET] <jamrial> oh hey, conflicting hevc mc prototypes and assembly
[17:37:56 CET] <nevcairiel> i commented on that on the ML
[17:38:03 CET] <nevcairiel> if you want to recycle some of their asm, go ahead :D
[17:38:33 CET] <Daemon404> dont forget conflicting avfoundation impl
[17:40:06 CET] <jamrial> their asm can be improved somewhat. but the fact the prototypes are completely different makes it kinda hard to measure which implementation is faster
[17:40:34 CET] <jamrial> on sse2 cpus like Phenom theirs is faster, for obvious reasons
[17:41:39 CET] <jamrial> we can't even use the checkasm units they wrote, heh
[17:42:05 CET] <nevcairiel> their hevc decoder is years behind in features
[17:42:13 CET] <nevcairiel> they got the initial dump and not one single feature afterwards
[17:42:23 CET] <nevcairiel> probably dont even have 422/444 decoding
[17:42:28 CET] <nevcairiel> or 12-14 bits
[17:42:55 CET] <nevcairiel> 14 bits isnt actually a thing is it? maybe only h264
[17:43:50 CET] <nevcairiel> ah the 444 intra profile goes up to 16 even
[17:45:38 CET] <nevcairiel> Daemon404: that one was easy to skip, Thilo asked me to simply not merge anything as he wants to work on some improvements =p
[17:45:50 CET] <Daemon404> ;p
[18:00:43 CET] <cone-607> ffmpeg 03Clément BSsch 07master:503d8bf74a38: lavu/frame: use AVPALETTE_SIZE instead of 1024
[18:10:10 CET] <cone-607> ffmpeg 03Sebastian Dröge 07master:9aebea0a4de1: avcodec/h264: Set CORRUPT flag on output frames that are not fully recovered
[19:00:28 CET] <atomnuker> any analog of svq3_get_ue_golomb() which encodes instead?
[19:01:52 CET] <nevcairiel> dont think we really have golomb writing code
[19:10:42 CET] <atomnuker> nevcairiel: ffv1 and flac encoders use golomb
[19:11:40 CET] <nevcairiel> ah
[19:11:50 CET] <nevcairiel> well if its not in golomb.h, then invent it in there :)
[19:23:10 CET] <andrey_utkin> Hi! Could please anybody look at MJPEG RTP encoder issue with yuvj422p https://trac.ffmpeg.org/ticket/3823#comment:17 ? This pixel format becomes popular for IP cameras having no RTSP, and there are constantly issues with RTPizing it. I consider donation for fixing this.
[20:51:48 CET] <nevcairiel> wasnt that particular assertion supposed to go away with recent aacenc changes
[20:51:54 CET] <nevcairiel> or was that one that looked similar :D
[20:53:46 CET] <kierank> nevcairiel: not the same crash I believe
[20:53:52 CET] <kierank> well the same assert but a different sample
[20:54:03 CET] <nevcairiel> well, not that recent changes
[20:54:11 CET] <nevcairiel> slighty older
[20:54:16 CET] <kierank> fuzzing aac enc is awfully slow
[20:54:56 CET] <nevcairiel> " and fixing delta-SF-related assertion failures,
[20:54:56 CET] <nevcairiel> since now the limitation is enforced rather than asserted.
[20:55:02 CET] <nevcairiel> may have been a different assert ^^
[20:56:01 CET] <nevcairiel> or the patch lied/was out of date
[21:05:26 CET] <cone-607> ffmpeg 03Matthieu Bouron 07master:3d090653168c: fate/api-jpeg-codec-param: rename to api-mjpeg-codec-param
[21:10:13 CET] <llogan> it's been 6 months since i've had to update BadContent
[21:12:21 CET] <llogan> atomnuker: user on twitter is wondering if the aac VBR "worse results" comments on wiki are (still) accurate. https://twitter.com/Bardnet/status/673999220383350784
[21:13:23 CET] <nevcairiel> VBR is probably still not as good as CBR
[21:13:34 CET] <nevcairiel> but the "even" could be removed =p
[21:34:52 CET] <ubitux> haha who posted https://twitter.com/FFmpeg/status/667443251553636353 ?
[21:35:55 CET] <llogan> i did
[21:36:20 CET] <llogan> i simply liked how it looked even better than the output GIF
[21:45:03 CET] <ubitux> ok :)
[21:45:28 CET] <nevcairiel> why does the palette look like it has dupes
[21:45:35 CET] <nevcairiel> but its probably just similar colors
[21:48:02 CET] <kierank> atomnuker: lol carl closed ticket
[21:53:54 CET] <atomnuker> llogan: yes, vbr is still always going to be worse than cbr
[21:55:11 CET] <BtbN> That sounds strange, shouldn't vbr make it easier to achive a good quality?
[21:56:27 CET] <fritsch> it's not so easy to get that done correctly with a single pass
[21:56:40 CET] <TD-Linux> it requires a lot of tuning
[21:56:44 CET] <fritsch> as one needs to estimates and predict
[21:56:57 CET] <fritsch> I think one could create a sample where vbr fails heavily
[21:56:59 CET] <llogan> nevcairiel: i lazily checked in the GIMP and they were all slightly different, AFAICT
[21:57:12 CET] <TD-Linux> it's not impossible, libopus does open loop unconstrained VBR by default and it works great
[21:58:23 CET] <fritsch> yeah, nobody said it would be impossible - but doing cbr is much easier
[21:59:24 CET] <nevcairiel> you would think encoding to some quality target is easier than trying to hit a specific bitrate exactly
[22:53:55 CET] <TD-Linux> nevcairiel, the problem is specifying the quality target
[22:55:47 CET] <cone-607> ffmpeg 03Andreas Cadhalpun 07master:5b0da6999fdd: aacenc: update max_sfb when num_swb changes
[00:00:00 CET] --- Wed Dec 9 2015
1
0
[00:05:12 CET] <satt> hey guys, I'm scaling and padding inputs and the result is not centered. I thought pad autocentered if you didn't specify a x/y - I guess I was wrong?
[00:06:25 CET] <satt> here's a line of the filter_complex
[00:06:27 CET] <satt> [0:v]scale=if(gt(ih\,iw)\,-2\,320):if(gt(ih\,iw)\,480\,-2),pad=320:480,setsar=sar=1/1[v0];
[00:07:08 CET] <satt> to make sure it's centered, I'd have to add a x/y to the pad argument right?
[00:08:20 CET] <llogan> (ow-iw)/2
[00:37:50 CET] <satt> llogan: thanks - so just pad=320:480:(ow-iw)/2:(oh-ih)/2, right?
[00:40:54 CET] <llogan> satt: yes
[00:41:15 CET] <satt> awesome, thanks for your help!
[04:06:41 CET] <shivaya> hello, i am trying to use ffmpeg with some embedded linux inside ip camera
[04:06:59 CET] <shivaya> the hw is very limited, whole os runs from 40mb ram
[04:07:18 CET] <shivaya> is there a way to add bare bone ffmpeg
[04:07:59 CET] <shivaya> it should be as small as possible
[04:12:15 CET] <c_14> It's possible
[04:12:41 CET] <c_14> --disable-everything --disable-all
[04:12:44 CET] <c_14> Then enable whatever you need
[04:12:59 CET] <c_14> (probably at least avformat and avcodec)
[04:13:09 CET] <c_14> Are you using the libraries or the commandline?
[04:16:27 CET] <c_14> And since this is an ip cam, you'll probably also want avdevice
[04:16:43 CET] <c_14> Then it's just a matter of finding all the codecs and muxers/demuxers you need
[04:26:25 CET] <shivaya> command line
[04:26:36 CET] <shivaya> sounds like I will be having some fun :)
[04:26:41 CET] <shivaya> thanks
[04:26:55 CET] <c_14> Then you'll also want --enable-ffmpeg --enable-avfilter --enable-swscale and --enable-swresample
[04:27:01 CET] <c_14> --enable-small will probably also be good
[06:42:08 CET] <pinPoint> where is the libaac github update page again?
[08:51:04 CET] <k_sze> With .nut containers and H.264 and FFV1 codecs, is it possible to quickly get a list of keyframes using one of the ffmpeg command line tools? I know ffprobe can output lines like "key_frame=1", but it seems to actually read the whole video. Are keyframes indexed at the end of the .nut container?
[09:18:47 CET] <k_sze> Do FFV1 and H.264 use keyframes drastically differently?
[09:19:38 CET] <k_sze> If I seek to a keyframe in a H.264 video, and then get X frames forward, the time increases linearly with X (until the next keyframe).
[09:20:11 CET] <waressearcher2> k_sze: hallo
[09:20:38 CET] <k_sze> But with a FFV1 video, I seek to a keyframe, and then get X frames forward, the time does not increase linearly with X. keyframe+1 and keyframe+10 essentially use the same time.
[09:21:45 CET] <pzich> what version do you have, and what are you using to seek?
[09:25:17 CET] <k_sze> 2.5.3. And we are using the PyAV wrapper, which actually uses av_seek_frame
[09:57:21 CET] <k_sze> Also, I'm reading this: https://trac.ffmpeg.org/wiki/Encode/FFV1
[09:57:51 CET] <k_sze> Why does it say "For archival use, GOP-size should be "1"."?
[09:58:40 CET] <maco> hi everone
[09:58:42 CET] <maco> Hi, I've got ffmpeg running on my Pi it was working fine but suddenly it stopped working and giving me and Illegal instruction instruction when running executing this code ffserver -f /etc/ffserver.conf & ffmpeg -v verbose -r 5 -s 640x480 -f video4linux2 -i /dev/video0 http://localhost/webcam.ffm
[10:25:23 CET] <DMJC> I need assistance porting from the old libavformat api to the new one, can someone point me to a porting guide?
[10:25:48 CET] <DMJC> the codebase is still using av_register_protocol2
[10:49:13 CET] <JEEB> DMJC: see the examples in the source code repo
[10:49:23 CET] <JEEB> those should tell you about the new API usage
[10:49:35 CET] <JEEB> apichanges file should contain api changes but it should be simpler to just look at examples
[10:58:36 CET] <t4nk722> I want to add a CREDITS screen at the end of my video & I am using the 'drawtext' filter of ffmpeg. It loads the dynamically created credits text from a textfile(.txt). I would like to know , if there is any way to format the credit text?? I can place the text at a specific (X,Y) position , but if the content of the text is large , the text becomes unaligned.
[10:59:45 CET] <JEEB> use ASS rendering with libass for that
[10:59:55 CET] <JEEB> create ASS subtitles with Aegisub
[11:02:56 CET] <t4nk722> Can I set the (X,Y) position coordinates if i use ASS ?? I need the text to come in Center of my video.
[11:03:17 CET] <JEEB> yes, there's a whole lot of ways you can do that
[11:03:31 CET] <JEEB> just look at the ASS override tag documentation on aegisub's site
[11:09:38 CET] <t4nk722> Ok. I ill do that. Thanks for the help. :)
[11:10:01 CET] <pkeuter> i have asked this before but i havent yet found a good way to go with this. i want to play a file that is currently recording in the browsers video-element. its a h264 encoded file. i use -movflags frag_keyframe+empty_moov, but the browser wants to fully load the file before it starts playing. is there any workaround that you know of?
[11:12:36 CET] <JEEB> no
[11:12:48 CET] <JEEB> if your thing doesn't support fragments then you're out of luck
[11:13:04 CET] <JEEB> although I'm not sure if those are the correct flags for fragments
[11:17:02 CET] <pkeuter> according to the internets they are the correct flags
[11:17:06 CET] <pkeuter> :)
[11:17:22 CET] <pkeuter> but itŽs chrome.... it does support fragments, right?
[11:18:01 CET] <JEEB> no idea
[11:18:01 CET] <Mavrik> Chrome probably wants DASH for that kind of streaming :/
[11:18:15 CET] <JEEB> wouldn't expect it to support fragments since so few things do :P
[11:18:25 CET] <JEEB> and for DASH you have to use MSE
[11:18:36 CET] <JEEB> because of course only MS Edge supports mpd in video tags :)
[11:18:46 CET] <JEEB> (together with HLS m3u8, funny enough)
[11:19:35 CET] <pkeuter> god
[11:19:49 CET] <pkeuter> that kind of sucks
[11:20:33 CET] <pkeuter> so there is not a way to record and play at the same time?
[11:20:44 CET] <pkeuter> because vlc and wmp and all those players work just fine
[11:26:22 CET] <BtbN> pkeuter, don't record to a static file, but to non-live HLS/DASH instead.
[11:26:39 CET] <BtbN> You can play that in a Browser, and just remux it to a static file once done.
[11:27:38 CET] <furq> pkeuter: https://github.com/dailymotion/hls.js/
[11:27:41 CET] <pkeuter> BtbN, nice. How would i go with that?
[11:27:44 CET] <furq> you'll need that to play hls in a desktop browser
[11:27:54 CET] <BtbN> or dash.js for DASH
[11:28:00 CET] <furq> there is something similar for dash but i've never managed to get it working
[11:28:07 CET] <BtbN> I'd prefer DASH, as it doesn't involve scary remuxing-in-js
[11:28:30 CET] <BtbN> HLS is much easier to handle for everything else though
[11:28:38 CET] <BtbN> you can just get one big file via cat
[11:29:28 CET] <furq> also you need to use a short gop length for dash to work well
[11:29:40 CET] <furq> so if you just want to stream whatever you're encoding then hls is probably a better choice
[11:29:58 CET] <BtbN> same for HLS
[11:30:08 CET] <BtbN> It doesn't realy matter for a non-live list though
[11:30:13 CET] <furq> i've had no issues with that over hls
[11:30:15 CET] <BtbN> segments can just be 20s long
[11:30:32 CET] <BtbN> You can't make segments shorter than your gop, that just doesn't work, for both
[11:30:49 CET] <furq> that works fine for me with hls
[11:31:02 CET] <furq> i wasn't splitting with ffmpeg though
[11:31:34 CET] <BtbN> It can't, you can only split at an I/IDR frame.
[11:32:07 CET] <BtbN> The first frame of every ts or mp4 segment has to be independently decodable
[11:32:25 CET] <pkeuter> uhmmmmm huh
[11:32:37 CET] <pkeuter> so do i record with ffmpeg to hls?
[11:32:43 CET] <BtbN> or dash
[11:32:47 CET] <pkeuter> or dash
[11:32:53 CET] <furq> yeah
[11:32:58 CET] <furq> then remux the fragments into your final file
[11:33:15 CET] <pkeuter> man, i really dont have any idea on where to start with this
[11:33:25 CET] <BtbN> For hls, you don't need to remux at all, if you're fine with .ts
[11:33:46 CET] <BtbN> Well, you can do a cat-style concat for dash, too. But it's more complex.
[11:34:01 CET] <furq> afaik you just encode as you normally would but use out.m3u8 as your output file
[11:34:13 CET] <BtbN> Make sure to tell ffmpeg that it's not a live playlist though
[11:34:26 CET] <furq> then point the video tag to /output-dir/out.m3u8
[11:34:27 CET] <BtbN> otherwise players will seek to the end
[11:34:46 CET] <furq> or whatever the dash equivalent is
[11:34:48 CET] <pkeuter> so wait, can we go through this step by step?
[11:35:23 CET] <pkeuter> i got this decklink input. i want it to record to h264, for storage purposes. in the mean time i also want to show it in the browser
[11:35:46 CET] <pkeuter> so what i do is start an ffmpeg instance with the decklink input as source and then still encode it to h264?
[11:36:42 CET] <pkeuter> sorry if i am asking dumb questions
[11:36:55 CET] <pkeuter> i just dont know enough about this
[11:37:40 CET] <furq> yes
[11:38:18 CET] <pkeuter> but then how do i make a non live hls or dash stream?
[11:38:27 CET] <pkeuter> im serving it with node.js
[11:39:29 CET] <furq> afaik the default is non-live
[11:40:27 CET] <pkeuter> okay so im just using m3u8 as the output file
[11:40:30 CET] <furq> i think non-live will always play from the beginning of the file though
[11:40:36 CET] <furq> so you might want to use the tee muxer
[11:40:44 CET] <pkeuter> and then at the end i will remux it to a h264 file?
[11:40:53 CET] <furq> that's one way to do it
[11:41:15 CET] <BtbN> Why would you want a raw h264 file?
[11:41:21 CET] <furq> https://www.ffmpeg.org/ffmpeg-formats.html#hls-1
[11:41:36 CET] <pkeuter> its tv so someone needs to be able to edit it afterwards
[11:42:02 CET] <BtbN> raw h264 is horrible for that, why would you need that?
[11:42:08 CET] <BtbN> ts is just fine
[11:42:12 CET] <furq> oh actually i guess the hls muxer is live by default
[11:42:19 CET] <furq> -hls_list_size 0 for non-live
[11:42:31 CET] <pkeuter> ts is fine, but what is the difference? its just another container right?
[11:42:42 CET] <BtbN> It's a container at all?
[11:42:54 CET] <BtbN> "hls_flags single_file" also looks usefull.
[11:42:56 CET] <pkeuter> huh?
[11:42:57 CET] <furq> depends how much you like having audio
[11:43:08 CET] <pkeuter> i pretty much like having audio
[11:44:00 CET] <pkeuter> but i still dont get it.... what does hls have to do with ts
[11:44:16 CET] <furq> hls creates a bunch of .ts segments
[11:44:30 CET] <BtbN> Or one big file.
[11:44:34 CET] <furq> once you're done you can remux it to whatever you want
[11:44:44 CET] <BtbN> No need to remux them
[11:44:47 CET] <BtbN> just cat them together
[11:44:57 CET] <furq> or you can use the tee muxer and save to a file at the same time
[11:45:10 CET] <BtbN> There's not realy a point to that.
[11:45:30 CET] <furq> won't a non-live hls stream always play from the beginning of the recording
[11:45:46 CET] <furq> that's usually not desirable, although i didn't get an answer for that
[11:46:01 CET] <pkeuter> its fine that it starts at the beginning, as long as the user can seek
[11:46:25 CET] <furq> you'll only be able to seek through loaded segments
[11:46:34 CET] <BtbN> no.
[11:46:44 CET] <BtbN> The playlist contains all of them.
[11:46:52 CET] <BtbN> And contains all meta information needed for seeking.
[11:47:23 CET] <furq> never mind then
[11:49:22 CET] <pkeuter> lets see
[11:51:31 CET] <furq> 10:31:34 ( BtbN) It can't, you can only split at an I/IDR frame.
[11:51:48 CET] <furq> fwiw i just checked this and apparently nginx-rtmp is just ignoring the fragment size i specified and using the gop length of the source
[11:51:51 CET] <furq> so that's nice to know
[11:52:16 CET] <BtbN> it chooses the closest multiple of the gop length to your desired fragment size
[11:52:22 CET] <furq> that certainly explains why the fragment size was having no effect on latency
[11:52:22 CET] <BtbN> As that's the only option it has
[11:53:52 CET] <furq> i guess it doesn't do that with dash, which explains why this source was unwatchable over dash
[11:54:36 CET] <pkeuter> ok so unfortunately hls_flags single_file doesnt seem to work
[11:54:41 CET] <pkeuter> well it records to one file
[11:54:54 CET] <pkeuter> so thats fine, but it doesnt play
[11:55:28 CET] <pkeuter> another question: can i somehow share the decklink input between two ffmpeg instances?
[11:56:10 CET] <pkeuter> oh, and i dont get a duration
[11:58:02 CET] <pkeuter> all those problems
[12:04:30 CET] <pkeuter> BtbN, furq?
[12:04:54 CET] <BtbN> you don't get a duration?
[12:04:59 CET] <pkeuter> nope
[12:06:21 CET] <pkeuter> its all 0 seconds, and scrolling isnt very accurate either
[12:31:16 CET] <pkeuter> BtbN, is that normal when using hls?
[13:43:59 CET] <debdog> ahoy everybooody! does ffmpeg has an option to identify the contents of a container? something like "mplayer -identify -frames 0"
[13:55:58 CET] <waressearcher2> debdog: hallo
[13:56:25 CET] <debdog> o/
[14:00:03 CET] <waressearcher2> debdog: wie geht's es dir ?
[14:00:57 CET] <debdog> uhm, beschissen. aber will das schon wissen ;)
[14:01:32 CET] <debdog> naja, gerade gut. hab das erste mal ein video mit ffmpeg umgewandelt
[14:01:54 CET] <debdog> von 20 GB auf 1 GB ohne grossen qualitätsverlust, wie es scheint
[14:02:19 CET] <debdog> aber wäre hierfür nicht ein OT channel besser?
[14:02:35 CET] <debdog> will meine frage nicht verlabern
[14:03:42 CET] <waressearcher2> debdog: keine ahnung
[14:13:19 CET] <DHE> debdog: you want ffprobe
[14:48:04 CET] <debdog> DHE: thanks a lot!
[15:20:29 CET] <pkeuter> so how would i create a h264 dash file with ffmpeg?
[15:37:21 CET] <durandal_1707> isn't there muxer?
[21:41:04 CET] <TD-Linux> FYI ffmpeg might be seeing more Opus LBRR frames due to webrtc recordings now being a thing
[21:42:23 CET] <TD-Linux> in case someone is on a codec feature implementing bend :)
[22:49:35 CET] <KallDrexx> Hello all. I'm trying to load test transcoding performance on a GPU bare metal box I have access to using NVEC. I'm doing this by transcoding Big buck bunny 1080p to a RTMP server, then spawning a bunch of ffmpegs to pull down that stream and downscale it to 720p at 3M bitrate and push the it out to another rtmp server. I am then trying to watch the video on the 2nd rtmp server. Once I get to about ~5 ffmpegs I get a lot of buffering in the
[22:49:35 CET] <KallDrexx> video but no dropped frames or anything. The nvidia cards are running at 8% capacity and CPU is only at 4% on the transcode box. Any ideas on how to isolate if it's ffmpeg that's struggling or some other factor?
[00:00:00 CET] --- Wed Dec 9 2015
1
0
[00:00:17 CET] <kierank> I've started extracting the VLCs
[00:00:26 CET] <kierank> there are a lot of them
[00:23:26 CET] <durandal_1707> cbsrobot_: I found some 468 meter but couldn't get it work, so I dunno is the thing coded which is posted on ml, the right thing
[00:27:21 CET] <cehoyos> durandal_1707: Either the license of the new filter is incorrect or a configure hunk is missing.
[00:32:41 CET] <durandal_1707> its rfc and wip
[01:33:30 CET] <cone-469> ffmpeg 03Anshul Maheshwari 07master:162754c1e0df: Remove Redundant Entry of MPEG2 Video Desc
[01:33:31 CET] <cone-469> ffmpeg 03Muhammad Faiz 07master:54ed3ebbe491: avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
[02:13:21 CET] <kierank> durandal_170: ah figured it out
[02:36:32 CET] <cone-469> ffmpeg 03Michael Niedermayer 07release/2.5:ffe40ef9b494: Update Changelog
[02:36:33 CET] <cone-469> ffmpeg 03Andreas Cadhalpun 07release/2.5:d52b5f85f283: mjpegdec: consider chroma subsampling in size check
[02:54:08 CET] <cone-469> ffmpeg 03Muhammad Faiz 07n2.5.9:HEAD: avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
[05:51:37 CET] <cone-469> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:21fbc41214b8: cmdutils: use version accessor macros
[09:23:01 CET] <rcombs> ubitux: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184438.html <-- I think this patch isn't quite right
[09:23:50 CET] <rcombs> should probably keep the av_rescale_q on ts_end and just add the sub->end_display_time bit
[09:23:51 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:cd1b7e2bd758: vp9: fix pixel format changes with threading
[09:51:22 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:585083dd1fc3: vp9: add hwaccel hooks
[09:51:23 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:1e6cf7272fa8: avcodec: implement vp9 dxva2 hwaccel
[09:51:24 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:5068fb1e2417: ffmpeg_dxva2: support vp9 hwaccel
[09:54:44 CET] <BtbN> nice
[10:11:38 CET] <nevcairiel> this guy is still here? calls everyone an asshole and still expects help? =p
[10:17:14 CET] <ubitux> incompetent* assholes
[10:17:27 CET] <ubitux> rcombs: yeah i didn't have a look yet
[10:17:41 CET] <ubitux> rcombs: feel free to comment, i'll have a look later today probably
[11:18:27 CET] <cone-284> ffmpeg 03Simon Thelen 07master:6596c6fca7e8: fate: add limited_input_seek tests
[11:44:46 CET] <cone-284> ffmpeg 03Clément BSsch 07master:f98abe0ee778: avutil/threadmessage: add av_thread_message_flush()
[11:44:47 CET] <cone-284> ffmpeg 03Clément BSsch 07master:a26e4215b91a: fate/api: test threadmessage
[11:44:48 CET] <cone-284> ffmpeg 03Clément BSsch 07master:bd5c860fdbc3: avutil/threadmessage: split the pthread condition in two
[11:44:57 CET] <ubitux> aaah mails are much faster :)
[11:45:47 CET] <cbsrobot_> durandal_1707: thanks a lot. I had a look but I wonder shouldn't the weighting be done in the frequency domain ?
[11:47:54 CET] <cbsrobot_> in the showcqt filter I found the [a,b,c]_weighting functions that could be reused
[11:48:11 CET] <cone-284> ffmpeg 03Paul B Mahol 07master:e6690ce02f4a: avfilter/af_biquads: pass filter ctx to av_log calls
[12:15:28 CET] <ubitux> so i just tried http://ubitux.fr/pub/pics/_vp9-support-in-firefox.png
[12:15:45 CET] <nevcairiel> that looks ... broken
[12:16:24 CET] <ubitux> really? :D
[12:16:48 CET] <nevcairiel> i dont know, maybe the original was like that!
[12:16:57 CET] <ubitux> ffmpeg -f lavfi -i testsrc -c:v vp9 -t 10 out.webm
[12:17:04 CET] <ubitux> just tried this
[12:17:16 CET] <ubitux> chromium plays it fine
[12:22:54 CET] <nevcairiel> If I were a mean person, I would say its because of firefox's binary distribution and their evil hackery to support a wide range of ffmepg versions without re-compiling =p
[12:24:01 CET] <ubitux> that was my immediate though as well
[12:29:41 CET] <cone-284> ffmpeg 03Paul B Mahol 07master:b6d029c2efea: doc/filters: add more compand examples
[12:35:06 CET] <durandal_1707> cbsrobot_: that needs fft
[13:12:28 CET] <TD-Linux> ubitux, is that file 4:4:4? that was broken in firefox for a while, but should work on nightly
[14:02:50 CET] <thilo> Can I add file-specific cflags in configure? Using check/add_cflags adds compilation of every file...
[14:04:08 CET] <nevcairiel> thats rather hard
[14:04:23 CET] <nevcairiel> but i think you can put them in the makefile directly
[14:05:51 CET] <thilo> any other files exist that are doing it this way?
[14:06:40 CET] <ubitux> TD-Linux: yep, ok
[14:07:16 CET] <nevcairiel> thilo: swscale/x86/Makefile has one of the samples, $(SUBDIR)x86/swscale_mmx.o: CFLAGS += $(NOREDZONE_FLAGS)
[14:07:54 CET] <thilo> nevcairiel: ok i will have a closer look at it, thanks!
[14:18:35 CET] <cone-284> ffmpeg 03Alexandre Lision 07master:4f979418c723: avfoundation: Simple capture
[14:18:36 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:14b583475607: Merge commit '4f979418c723652ad4e43115118c57a44bd46b52'
[14:18:51 CET] <cone-284> ffmpeg 03Luca Barbato 07master:b0e8651a2a84: doc: Amend the MSYS2 Documentation
[14:18:52 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:4e01566941b5: Merge commit 'b0e8651a2a84553d08fbb2f7cb9697bd64fb1b55'
[14:20:38 CET] <cone-284> ffmpeg 03Petri Hintukainen 07master:7139489c452e: pgssubdec: fix API compability layer
[14:20:39 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:4a2058bf4e75: Merge commit '7139489c452ef8af6a745ec4e62056ee4ea4d6a8'
[14:26:35 CET] <nevcairiel> evil ubitux broke my fate :(
[14:26:59 CET] <ubitux> ow
[14:27:11 CET] <ubitux> the test i added doesn't work for you?
[14:27:35 CET] <nevcairiel> make: *** No rule to make target 'tests/api/api-threadmessage-test.exe', needed by 'fate-api-threadmessage'
[14:28:01 CET] <ubitux> wait fuck it seems i might have messed up sth else
[14:29:41 CET] <nevcairiel> hm where do these tests hook into the fate target anyway
[14:29:46 CET] <ubitux> nevcairiel: will fix this in asec
[14:31:23 CET] <cone-284> ffmpeg 03Clément BSsch 07master:d4b1b33e698b: avutil/threadmessage: fix build without HAVE_THREADS
[14:31:47 CET] <nevcairiel> ah i see
[14:31:52 CET] <ubitux> this is the first one
[14:32:07 CET] <ubitux> nevcairiel: is this the only fate api failing for you?
[14:32:14 CET] <nevcairiel> yes
[14:32:27 CET] <nevcairiel> because its protected by HAVE_PTHREADS, and i dont have pthreads
[14:32:34 CET] <nevcairiel> should probably be HAVE_THREADS
[14:33:00 CET] <nevcairiel> on top of that, tests\fate\api.mak should use the same condition when building
[14:33:14 CET] <ubitux> ok, got it
[14:33:30 CET] <ubitux> just curious, what's the output of make fate-list|grep fate-api?
[14:34:22 CET] <nevcairiel> all of them
[14:34:45 CET] <nevcairiel> all 7
[14:35:27 CET] <ubitux> ok
[14:35:34 CET] <ubitux> give me a sec
[14:36:25 CET] <nevcairiel> can you even turn off avutil
[14:36:29 CET] <nevcairiel> that seems unlikely
[14:36:44 CET] <ubitux> probably not
[14:36:46 CET] <nevcairiel> nothing would be build without it :D
[14:37:00 CET] <ubitux> you have HAVE_PTHREADS=no?
[14:37:08 CET] <nevcairiel> yes, because i have w32threads
[14:37:33 CET] <nevcairiel> the makefile building those tests checks for that, the makefile running the tests does not
[14:38:39 CET] <ubitux> so, the test fate-api-threadmessage depends on the binary $(APITESTSDIR)/api-threadmessage-test$(EXESUF)
[14:39:03 CET] <ubitux> and this prog should be built on this condition: APITESTPROGS-$(HAVE_PTHREADS) += api-threadmessage
[14:39:17 CET] <nevcairiel> yes, so the test also needs the same condition
[14:39:26 CET] <ubitux> why?
[14:39:34 CET] <ubitux> the test depends on the binary
[14:39:36 CET] <nevcairiel> because it otherwise doesnt find its prog and fails? :)
[14:39:42 CET] <nevcairiel> like now
[14:39:45 CET] <ubitux> if the binary doesn't exist/can't be built, it should fail
[14:39:58 CET] <ubitux> i mean not meet the requirement
[14:40:00 CET] <ubitux> mmh
[14:40:02 CET] <nevcairiel> so you are saying I should not be able to run fate until i get pthreads? =p
[14:40:22 CET] <ubitux> no no
[14:40:36 CET] <ubitux> i'm saying the test should not be added if the binary can't be built
[14:40:37 CET] <nevcairiel> just change FATE_API-$(CONFIG_AVUTIL) += fate-api-threadmessage to HAVE_PTHREADS, since avutil is likely to always be there anyway
[14:42:09 CET] <ubitux> ok ok.
[14:42:52 CET] <nevcairiel> or if you really want to check for avutil, do what the other tests did
[14:42:59 CET] <nevcairiel> move it inot the name and check later
[14:43:42 CET] <cone-284> ffmpeg 03Clément BSsch 07master:b98305f0ab01: fate/api: fix fate-api-threadmessage dependency
[14:43:51 CET] <ubitux> yeah the avutil thing doesn't matter
[14:44:08 CET] <ubitux> i'm more uncomfortable about the need for having twice the same dep
[14:44:16 CET] <ubitux> it looks fishy but ok
[14:44:32 CET] <ubitux> anyway, should be fixed, sorry :)
[14:46:24 CET] <nevcairiel> for more test coverage, may want to use the thread compat headers in that test at some point
[14:47:41 CET] <ubitux> yep, would be nice
[14:48:22 CET] <ubitux> nevcairiel: i can write a patch but won't be able to test
[14:48:32 CET] <ubitux> can i ask you to do the test when i'm done?
[14:48:34 CET] <nevcairiel> can api tests use config.h and everything?
[14:48:51 CET] <ubitux> no idea :)
[14:48:59 CET] <nevcairiel> or rather not since they are supposed to test from a users point of view?
[14:49:05 CET] <ubitux> that's one of the reason i was reluctant to do the getopt thing
[14:49:22 CET] <ubitux> yeah dunno, it's half assed between examples and actual api tests
[14:49:43 CET] <nevcairiel> if you can use internal api, just need to include libavutil/thread.h and hope for the best
[14:49:50 CET] <nevcairiel> but if not thats going to be annoying
[14:49:52 CET] <ubitux> but looking at the includes, it looks like integrated properly within the ff build
[14:51:12 CET] <cone-284> ffmpeg 03Luca Barbato 07master:f7986239f4db: dvenc: Validate the frame size before copying it
[14:51:13 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:255f8966b2b5: Merge commit 'f7986239f4dbec91c743c4c5eb0a2339bd325bf6'
[14:51:29 CET] <ubitux> we probably need an include-wrapper instead of this 11 lines conditional include everytime
[14:51:54 CET] <nevcairiel> for threading? thats avutil/thread.h :)
[14:53:00 CET] <nevcairiel> but it of course needs config.h, which the api tests seem to try to avoid
[14:54:02 CET] <ubitux> nevcairiel: http://b.pkh.me/0001-fate-api-add-w32-os2-support-for-fate-api-threadmess.p…
[14:54:21 CET] <ubitux> oh
[14:54:34 CET] <ubitux> why isn't this thread.h included in other areas?
[14:54:51 CET] <nevcairiel> its from libav i think, you know how adoption of those things goes
[14:55:38 CET] <ubitux> patch updated
[14:55:42 CET] <cone-284> ffmpeg 03Luca Barbato 07master:a0fa6d06b848: matroska: Warn when metadata references a non-existent element
[14:55:43 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:0ecec7449c58: Merge commit 'a0fa6d06b848f26b16ba12f0a9a4a85b93ab8022'
[14:55:51 CET] <ubitux> does this work for you?
[14:57:08 CET] <nevcairiel> builds and passes
[14:57:23 CET] <ubitux> ok pushing then
[14:58:57 CET] <ubitux> http://b.pkh.me/0001-avcodec-avutil-remove-pointless-manual-thread-includ.p…
[14:59:00 CET] <ubitux> need to test this as well
[14:59:37 CET] <cone-284> ffmpeg 03Michael Niedermayer 07master:b74b88f30da2: g723_1: Handle values at the ends of the table in lsp2lpc()
[14:59:38 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:2730a2013daa: Merge commit 'b74b88f30da2389f333a31815d8326d5576d3331'
[15:00:07 CET] <cone-284> ffmpeg 03Clément BSsch 07master:dc97ff8380c2: fate/api: add w32+os2 support for fate-api-threadmessage
[15:00:25 CET] <nevcairiel> ubitux: that one fails
[15:00:35 CET] <ubitux> yeah didn't test yet
[15:05:21 CET] <cone-284> ffmpeg 03Vittorio Giovara 07master:aac996cc0104: g723_1: Rename files to better reflect their purpose
[15:05:22 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:9cf74191eda3: Merge commit 'aac996cc01042194bf621d845bbe684549b5882e'
[15:05:51 CET] <durandal_1707> anyone on windows willing to test maskedmerge filter?
[15:21:39 CET] <j-b> seriously, forking a header inside the repo?
[15:22:43 CET] <BtbN> That's the question.
[15:23:03 CET] <BtbN> It shouldn't be a problem now, at least license-wise.
[15:26:48 CET] <ubitux> BtbN: 3k lines though :(
[15:27:10 CET] <ubitux> i can't deny that it simplifies the build a lot
[15:27:53 CET] <BtbN> I don't realy see another way to make it non-non-free, too. Other than artificialy limiting it to the SDK 6 header.
[15:27:54 CET] <cone-284> ffmpeg 03Vittorio Giovara 07master:165cc6fb9def: g723_1: Move sharable functions to a separate file
[15:27:55 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:6c9cc21bcca9: Merge commit '165cc6fb9defcd79fd71c08167f3e8df26b058ff'
[15:29:01 CET] <j-b> it blocks any further update
[15:29:24 CET] <BtbN> What update?
[15:52:49 CET] <cone-284> ffmpeg 03Mohamed Naufal 07master:f023d57d355f: lavc: G.723.1 encoder
[15:52:50 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:90c93fb12948: Merge commit 'f023d57d355ff3b917f1aad9b03db5c293ec4244'
[15:55:24 CET] <cone-284> ffmpeg 03Mohamed Naufal 07master:ca5f386e75c5: lavf: G.723.1 muxer
[15:55:25 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:d1256272b16a: Merge commit 'ca5f386e75c592ce25b8184516fd0d580ccb31bb'
[15:56:05 CET] <cone-284> ffmpeg 03Vittorio Giovara 07master:7f57ea143c55: vsrc_color: Drop unneeded variable
[15:56:06 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:ee367fadf5c1: Merge commit '7f57ea143c55ce5732ef7e31e4b75ae6c307af13'
[16:00:31 CET] <cone-284> ffmpeg 03Luca Barbato 07master:d017ed878a45: avi: Use the correct data type
[16:00:32 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:e92aa34d7ba5: Merge commit 'd017ed878a45171f2f6c69fb9d76401c3c494110'
[16:01:02 CET] <cone-284> ffmpeg 03Michael Niedermayer 07master:0fc61c6ab691: avi: Validate the stream-id for DV as well
[16:01:03 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:8cfa7beffc5c: Merge commit '0fc61c6ab6912a2f0c40fdd3f3c591bc2a33efd4'
[16:01:53 CET] <cone-284> ffmpeg 03Luca Barbato 07master:cb49bb10ca7f: build: Move -Wcast-qual to the extra_warnings
[16:01:54 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:357c62657a3d: Merge commit 'cb49bb10ca7fcff2e382d9d989232b1a7f28e7da'
[16:11:40 CET] <cone-284> ffmpeg 03Hendrik Leppkes 07master:312c83e05711: avcodec/g723_1: fix license header
[16:42:34 CET] <cone-284> ffmpeg 03Clément BSsch 07master:5e0c47d41c1d: avutil/threadmessage: fix build without HAVE_THREADS, new attempt
[16:56:47 CET] <mateo`> hello o/, is there any documentation regarding how libavfilter works internally ? init/negotiation/possible re-negotiation/deinit ?
[16:58:20 CET] <Daemon404> there is some txt file ubitux wrote
[16:58:27 CET] <Daemon404> i think its udner doc/
[16:59:06 CET] <ubitux> doc/writing_filters.txt doesn't really talks about the negotiation though
[16:59:13 CET] <Daemon404> ok
[16:59:22 CET] <mateo`> filter_design.txt seems good
[16:59:24 CET] <ubitux> doc/filter_design.txt from Nicolas might
[16:59:30 CET] <ubitux> but i'm not sure how up to date it is
[16:59:41 CET] <ubitux> i think it's actually pretty outdated
[16:59:45 CET] <mateo`> it's better than nothing
[17:00:40 CET] <mateo`> i'm looking at bringing back buffer pools to avfilter
[17:01:57 CET] <mateo`> but first, I need to figure out how the negotiation is happening
[17:02:25 CET] <ubitux> > foo86 <foobaz86(a)gmail.com>
[17:02:28 CET] <ubitux> a new mission for j-b
[17:03:01 CET] <ubitux> heh, actually some commits from him are already in the history
[17:03:10 CET] <JEEB> :D
[17:13:06 CET] <cone-284> ffmpeg 03James Almer 07master:a0050d9bf9b6: configure: fix vp9_d3d11va_hwaccel deps
[17:14:05 CET] <durandal_1707> mateo`: buffer pools, why?
[17:14:20 CET] <nevcairiel> did that ever break in reality anywhere? DXVA_PicParams_VP9 is even rarer than d3d11va headers =p
[17:15:06 CET] <mateo`> durandal_1707: because frames are being allocated / deallocated every time
[17:15:41 CET] <durandal_1707> no, they are not
[17:16:15 CET] <ubitux> if you do a simple vf scale they are
[17:16:20 CET] <mateo`> looking at libavfilter/video.c, they are
[17:19:39 CET] <mateo`> a buffer pool uses to be there (39f66edbeae5ccabefe38b2fcb25d6c242d868c0) but it has been removed with the api redesign
[17:22:27 CET] <ubitux> on a side note, the huge writing performance hit we get with the nv2rgb neon convert in sws is because of this
[17:24:31 CET] <nevcairiel> ..its slower because the buffer is "new"?
[17:24:37 CET] <nevcairiel> how does that make sense
[17:24:48 CET] <durandal_1707> what are numbers?
[17:25:49 CET] <ubitux> nevcairiel: yes; not in cache maybe
[17:25:59 CET] <ubitux> nevcairiel: more than half of the time is spent in the writing itself
[17:26:21 CET] <ubitux> this is easily reproducible by doing a memcpy on a new buffer vs the same buffer
[17:26:22 CET] <nevcairiel> frames are too large to be cached anyway
[17:26:29 CET] <ubitux> you get something like 21ms vs 5ms
[17:26:40 CET] <nevcairiel> arm is just weird
[17:36:17 CET] <mateo`> this is what it looks like on a beagle board black: http://pastie.org/10616395
[17:37:07 CET] <nevcairiel> clearly that is invalid because you actually alloc within the loop and measure that as well
[17:37:25 CET] <nevcairiel> oh wait, i mixed up lines
[17:38:01 CET] <nevcairiel> did you try clearing the memory before reading it, maybe it just doesnt like uninit memory
[17:39:01 CET] <nevcairiel> and your test is sligthly wrong, it says "new only dest", but its actually the source thats being created all the time
[17:42:27 CET] <mateo`> nevcairiel: yeah, i've put this "label" in a hurry
[17:45:15 CET] <cone-284> ffmpeg 03Clément BSsch 07master:a8bb81a05c51: lavc, lavu: use avutil/thread.h instead of redundant conditional includes
[19:40:18 CET] <Timothy_Gu> why is carl so interested in the version generation?
[19:44:03 CET] <cone-284> ffmpeg 03Timothy Gu 07master:006d3e97fc8f: cosmetics: Fix weird indentations
[20:08:01 CET] <llogan> Timothy_Gu: so he can bisect. (not particularly that ticket)
[20:08:26 CET] <llogan> i believe that weird version number is a result of using a shallow repo, but i didn't test
[20:10:30 CET] <llogan> or i should say using a shallow repo may also cause that
[20:14:29 CET] <Daemon404> unrelated to the bug at hand
[20:26:05 CET] <RiCON> ubitux: it seems you took one #if too many or forgot to remove #endif in http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a8bb81a05c519dd3f36cc341e5…
[20:26:12 CET] <RiCON> in libavutil/opencl.c
[20:26:45 CET] <nevcairiel> oh yeah the HAVE_THREADS probably should've remained
[20:27:05 CET] <ubitux> fixing in a second..
[20:28:34 CET] <RiCON> same in libavutil/threadmessage.c probably
[20:28:55 CET] <RiCON> or not, the two #endifs were removed too
[20:29:12 CET] <cone-284> ffmpeg 03Clément BSsch 07master:dd1d9b80c99e: lavu/opencl: restore #if HAVE_THREADS
[21:39:50 CET] <wm4> does anyone know what standard specifies RGB-in-h264 with bit depth greater than 8?
[21:40:17 CET] <wm4> because I have no idea how this is supposed to be mapped to a normalized range
[21:40:42 CET] <nevcairiel> ?
[21:40:47 CET] <fritsch> what is a normalized range in that regard?
[21:40:52 CET] <nevcairiel> increased bitdepth just moves the points accordingly
[21:41:22 CET] <wm4> what are the minimum and maximum values in N bit RGB? the 16 bit case confuses me, but maybe I'm just too stupid
[21:41:29 CET] <ubitux> rcombs: what happened to the ass fixes?
[21:41:41 CET] <ubitux> rcombs: not only your recent ones but also the parser bugs etc
[21:41:45 CET] <fritsch> wm4: 2^N -1?
[21:41:53 CET] <fritsch> again depending on limited or not?
[21:42:04 CET] <fritsch> not sure if that exists in rgb 888
[21:42:45 CET] <nevcairiel> you can just take the 8-bit scale and multiply it accordingly
[21:43:03 CET] <nevcairiel> for limited, 16-235 * 4 -> 64-940 for 10-bit
[21:43:17 CET] <wm4> I mean for ycbcr, the ranges are apparently 16*2^(N-8) and 235*2^(N-8)
[21:43:31 CET] <nevcairiel> yeah
[21:43:48 CET] <nevcairiel> *4
[21:43:48 CET] <wm4> would that imply that for RGB the range is 2^(N-8) and 255*2^(N-8)?
[21:43:51 CET] <nevcairiel> woops
[21:44:14 CET] <nevcairiel> full rgb always starts at 0
[21:44:27 CET] <nevcairiel> so simplified, 0 to 2^N - 1
[21:44:37 CET] <wm4> right, even for 8 bit
[21:45:06 CET] <wm4> ok, I guess the strict requirement for shifting in the yuv case just confused me, and there's no such thing for RGB?
[21:45:18 CET] <nevcairiel> some people handle limited range rgb
[21:45:22 CET] <nevcairiel> but its just a weird format
[21:45:24 CET] <wm4> (somehow I thought these would be handled the same way, apart from the color matrix)
[23:39:24 CET] <kierank> wm4: some people do this weird shifting thing for rgb
[23:39:26 CET] <kierank> swscale for example
[23:40:13 CET] <wm4> uh and what about 16 bit? or do they treat packed 16 bit and planar 16 bit differently?
[23:40:29 CET] <wm4> (there are 10 bit RGB formats in the sane world too, but I don't think swscale supports them)
[23:49:00 CET] <kierank> people shift from 8 to 16-bit with (foo << 8) | foo & 0xff;
[23:49:02 CET] <kierank> maintains full range
[23:49:25 CET] <wm4> yes but you don't do this with yuv
[23:49:41 CET] <kierank> correct
[23:50:43 CET] <wm4> so shifting for 10 bit gbrp (instead of just using the full 10 bit range) is inconsistent?
[23:52:20 CET] <kierank> depends if you are a full-range tard I guess
[23:52:44 CET] <kierank> as a limited range tard I would shift
[23:52:49 CET] <nevcairiel> the reason for that isnt too bad, wanting 255 become 1023
[23:52:53 CET] <nevcairiel> while limited range works out well
[23:53:04 CET] <nevcairiel> 235 << 2 == 940, perfect
[23:53:11 CET] <wm4> I don't care (who the fuck uses planar 10 bit RGB), I just like concistency and also a bit of correctness
[23:53:45 CET] <Daemon404> vapoursynth!
[23:53:47 CET] Action: Daemon404 runs
[23:53:57 CET] <nevcairiel> Daemon404: its vapourware
[23:54:11 CET] <Daemon404> no?
[23:54:12 CET] <wm4> vapoursynth is very much released
[23:54:36 CET] <nevcairiel> noone likes my bad puns :(
[23:54:41 CET] <Daemon404> :P
[23:54:57 CET] <wm4> to be fair, it remained true to its name for quite a while
[00:00:00 CET] --- Tue Dec 8 2015
1
0
[00:34:23 CET] <chaupv> Hi relaxed, JEEB
[00:34:30 CET] <chaupv> are you there?
[01:03:20 CET] <xintox> so what's a reasonable hls setting for low buffering?
[01:03:33 CET] <xintox> i've been doing -hls_time 3 -hls_list_size 10
[03:13:36 CET] <chaupv> Hey , relaxed?
[03:14:06 CET] <chaupv> Relaxed? you have been relaxing so long time... :)
[03:57:44 CET] <jaga_> ffmpeg won't authenticate to Flash Media Server.
[04:00:51 CET] <jaga_> http://pastebin.com/vp54NZad
[04:01:14 CET] <prelude2004c> hey guys
[04:01:19 CET] <jaga_> ffmpeg question: I'm trying to publish to an FMS server. I get this output with wrong password.
[04:01:39 CET] <prelude2004c> question... if i have an input that is not 16/9 and has black bars on each side.. is there some way for me to stretch it and remove the black bars of the video without transcoding it ?
[04:01:58 CET] <prelude2004c> i don't want to cuase cpu power just to remove the black bars and strech the video the the absolute left and right
[04:02:01 CET] <prelude2004c> any hint ?
[04:02:18 CET] <klaxa> you can't unless you do it on the player
[04:02:34 CET] <jaga_> I have it compiling in OK and running but I am getting an authentication
[04:02:34 CET] <jaga_> error.
[04:02:55 CET] <jaga_> I have also tried compiling with --enable -openssl.
[04:03:09 CET] <jaga_> Platform Ubuntu 15.10
[04:03:42 CET] <prelude2004c> damn
[04:31:39 CET] <chaupv> I compile ffmpeg and h264 separately with MSVC successfully but when I enable-lib246 --enable-gpl then error always occurs "ERROR: libx264 not found", but actually the x264 library has already been in PREFIX=/usr/
[04:31:54 CET] <chaupv> do you know why?
[04:50:13 CET] <chaupv> why ffmpeg can't answer correctly this question?
[05:29:07 CET] <prelude2004c> hey guys.. anyone nkow what -af volume=-10dB would not work ?
[05:29:22 CET] <prelude2004c> for some reason its not working anymore.. i set volume like -whatever and still the volume is the same.. strange.
[05:29:46 CET] <waressearcher2> prelude2004c: hallo
[05:36:03 CET] <prelude2004c> nevermind, figured it out :)
[05:39:24 CET] <waressearcher2> prelude2004c: das ist echt wunderschön
[05:50:51 CET] <prelude2004c> sorry i dont understand
[06:24:31 CET] <causa_sui> could ffmpeg make a "quadbox" from four separate input streams? as shown here: https://www.youtube.com/watch?v=xRpv3fO4MlY
[06:29:10 CET] <furq> causa_sui: https://ffmpeg.org/ffmpeg-filters.html#tile
[06:30:45 CET] <prelude2004c> anyone know how i can get vdpau going and decoding on my nvidia cards ? i don't use the UI as i plan on using this for ffmpeg decoding.. please help .. i been stuck for days
[06:31:10 CET] <furq> actually nvm that's just for images
[06:31:13 CET] <furq> causa_sui: https://trac.ffmpeg.org/wiki/Create%20a%20mosaic%20out%20of%20several%20inp…
[06:32:08 CET] <causa_sui> furq: thank you
[07:05:54 CET] <pinPoint> i see aac is finalized!! yes!
[07:16:12 CET] <pepee> I found a weird(?) bug in ffmpeg: if the input jpg images don't have the file extension, ffmpeg throws an error
[07:16:46 CET] <pepee> "Invalid data found when processing input"
[07:40:51 CET] <pinPoint> I thought aac was live already per twitter post? just tried -c:a aac and got -strict 2 error still
[07:40:56 CET] <pinPoint> boo
[08:10:58 CET] <droid909> hi
[08:13:15 CET] <droid909> why this gives me an error: ffmpeg -f dshow -i "2" -c:a libvo_aacenc -b:a 64k -ac 2 -y "\Users\user1\1.wav"
[08:13:23 CET] <droid909> Unknown input format: 'dshow'
[08:19:13 CET] <droid909> i figured
[08:22:49 CET] <waressearcher2> droid909: hallo
[08:46:20 CET] <droid909> waressearcher2: hi
[10:30:51 CET] <waressearcher2> droid909: wie geht's es dir ?
[11:07:43 CET] <droid909> waressearcher2: yup, thanks
[12:07:27 CET] <jimgray> my kernel is 2.6.32. The lastest static ffmpeg cannot run
[12:07:41 CET] <jimgray> FATAL: kernel too old
[12:07:42 CET] <jimgray> Segmentation fault
[12:08:12 CET] <jimgray> how to decide the sutable version for my centos6?
[12:12:47 CET] <JEEB> build it yourself or upgrade your kernel
[12:13:56 CET] <jimgray> JEEB: update kernel now
[12:14:23 CET] <Phrk_> Hi
[12:15:36 CET] <JEEB> jimgray: me? I'm upgrading my kernel just fine :P
[12:17:09 CET] <jimgray> JEEB: i said me
[12:26:38 CET] <Guest22966> Hi, I need to decode raw bitstream of 12bit monochrome video, where two pixels are encoded in three bytes. Pixel0[7:0] Pixel1[3:0] Pixel0[11:8] Pixel1[11:4]. Does current ffmpeg has support for such pixel format?
[12:45:01 CET] <waressearcher2> Guest22966: hallo
[12:45:07 CET] <waressearcher2> Phrk_: wie geth's ?
[12:47:00 CET] <Phrk_> someone know ffserver ?
[12:47:11 CET] <Phrk_> I don't understand how to accepte people from outside lan
[12:47:20 CET] <Phrk_> he say error http 301
[12:47:59 CET] <Phrk_> klaxa tried to help me yersteday we don't find any solution
[13:23:17 CET] <t4nk394> Hello
[13:23:53 CET] <t4nk394> How to Convert any video in MP4 using ffmpeg.
[13:24:14 CET] <fritsch> t4nk394: paste that last sentence without the final "." into google ...
[13:24:51 CET] <waressearcher2> !g
[13:25:03 CET] <t4nk394> I have try with below command
[13:25:21 CET] <t4nk394> ffmpeg -i $input -s 320x240 -ar 44100 -r 12 $output
[13:25:44 CET] <t4nk394> but converted file now support in HTML5 video tag
[13:25:59 CET] <fritsch> so - let's assume you want to understand what you are doing - what do you think does this command do?
[13:26:43 CET] <t4nk394> Any body have perfect solution
[13:34:33 CET] <waressearcher2> t4nk394: ffmpeg -i 1.avi -c:v mpeg4 -vb 2000k -ab 320k -ar 44100 -ac 2 -c:a libmp3lame -y -f avi 2.avi
[14:11:57 CET] <k_sze> Can the ffmpeg or ffplay commands be used to detect corruption in common file types (e.g. AVI, MOV, MPG, MKV, MTS)?
[14:12:52 CET] <k_sze> I see that ffplay has an -err_detect option, but can ffplay just try to decode a file as fast as possible and not actually output video or audio?
[14:13:09 CET] <Phrk_> i think it show this in the log
[14:16:14 CET] <k_sze> And I kinda need to use it in a script, just to check a large collection of videos after data recovery from a failed hard drive.
[14:16:36 CET] <Phrk_> ah sorry to much for me
[14:16:44 CET] <k_sze> So it would be nice if ffmpeg can indicate corruption via exit code
[14:16:54 CET] <Phrk_> Did you search the doc ?
[14:18:42 CET] <furq> k_sze: you can try with ffmpeg -f null but i have broken files which that doesn't flag up
[14:29:39 CET] <DHE> I use ffprobe -show_frames to decode the whole video. then watch for errors
[14:30:12 CET] <DHE> in terms of automating the process, that's up to you. you might also consider -print_format to select how the regular output is formatted
[14:44:52 CET] <k_sze> ah, ffprobe also has the -show_error option.
[14:46:50 CET] <k_sze> err, ffprobe -show_frames is so verbose.
[14:47:17 CET] <k_sze> I don't need that kind of verbosity in a script.
[14:47:32 CET] <k_sze> I guess I'll stick to ffmpeg
[14:49:53 CET] <k_sze> `ffmpeg -v error -xerror -i foo.mkv -f null -` should do, I think.
[14:50:12 CET] <k_sze> or even without the -xerror
[14:51:27 CET] <DHE> true, but it does force ffprobe to decode all frames.
[14:51:39 CET] <DHE> while not depending on any hardware and running as fast as the disk/CPU allows
[14:56:53 CET] <k_sze> woohoo, I'm burning all 8 cores of my CPU.
[14:57:26 CET] <k_sze> if only I know how to compile ffmpeg with nvenc on OS X.
[14:57:49 CET] <Phrk_> k_sze it's not that hard
[14:58:03 CET] <Phrk_> just use the basic compile way and add the good option
[14:59:51 CET] <Phrk_> --enable-nonfree \
[14:59:51 CET] <Phrk_> --enable-nvenc \
[15:01:15 CET] <Phrk_> Someone is good with ffserver here ?
[15:06:05 CET] <BtbN> There is no nvenc on OSX.
[15:07:23 CET] <k_sze> Not really convinced that it takes 4 cores to burn through 12 MB/s
[15:11:39 CET] <DHE> H264 is actually fairly hard on the CPU to decode. compared to, say, mpeg2 or xvid
[15:11:53 CET] <JEEB> you can disable CABAC if you really want to
[15:12:05 CET] <JEEB> if you are encoding the content that is
[15:12:12 CET] <JEEB> but yeah, CABAC + a lot of bit rate can be funky
[15:12:34 CET] <DHE> would that risk any decoding errors?
[15:12:54 CET] <JEEB> you can't skip it if the content is coded with CABAC :P
[15:12:55 CET] <k_sze> oh wait... there really is no NVENC sdk for OS X.
[15:12:57 CET] <k_sze> https://developer.nvidia.com/nvidia-video-codec-sdk#gpulist
[15:12:58 CET] <k_sze> :(
[15:13:17 CET] <JEEB> which is why I noted that it's the one alternative to have your content (that you encode) playable with a first-gen xbox
[15:13:28 CET] <JEEB> ("if you are encoding the content that is")
[15:17:04 CET] <Mavrik> k_sze, on OSX you have to use their videotoolbox
[15:17:56 CET] <Mavrik> And it'll pass it on to the HW encoder
[15:21:10 CET] <k_sze> Mavrik: videotoolbox??
[15:21:42 CET] <Mavrik> Yes, the OS X / iOS video processing API.
[15:22:01 CET] <Mavrik> Successor to VDA
[15:22:49 CET] <Mavrik> VDA works as well (IIRC ffmpeg supports it) but it's rather buggy and decode only.
[15:24:05 CET] <k_sze> And I suppose ffmpeg isn't taking advantage of that?
[15:24:28 CET] <Mavrik> I don't think the patch was merged.
[15:24:28 CET] <k_sze> I mean, at least currently no build option would enable ffmpeg to take advantage of that.
[15:48:25 CET] <Phrk_> Any help with ffserver ? :(
[16:19:27 CET] <durandal_1707> ask on ml?
[17:29:40 CET] <DHE> I'm trying to convert ismv (microsoft smoothstream, uses the 'mov,mp4,m4a,3gp,3g2,mj2' demuxer) to mpegts with transcoding. While it works, the output seems has bad PCR and only 1 PCR value comes in every 2 seconds. (The smoothstream chunks the video in 2s increments). Anyone know how to forcibly re-clock the video?
[18:48:00 CET] <pinPoint> so I encoded two files at 4000kbps. One in libx265 the other in libx264. x264 was 312MB, x265 was 303MB. Are the compressions they talk about x265 working?
[18:48:27 CET] <pinPoint> the 20%-50%?
[18:50:19 CET] <c_14> That's just the rate control being different
[18:51:20 CET] <pinPoint> i see
[18:51:34 CET] <pinPoint> this should force it to stick though yes? ffmpeg -i bbb_sunflower_2160p_30fps_normal.mp4 -c:v libx265 -preset veryslow -b:v 7501k -minrate 7501k -maxrate 7501k -an BBB_H265_VERY_SLOW_NOAUDIO_2160P_7501k.mkv
[18:52:48 CET] <DHE> you set a bitrate. both codecs will try to target that number, but without 2-pass mode there's going to be some error
[18:53:14 CET] <DHE> minrate and maxrate don't make a true cbr file, unfortunately. it just brings it a lot closer
[18:53:32 CET] <pinPoint> and the two pass method?
[18:54:05 CET] <DHE> 2-pass lets the codec see the whole video first, then it gets another chance to process it with information saved the first time around. bitrate tends to be much closer to the target
[18:54:26 CET] <DHE> not perfectly, but the variance might be closer to 2 megabytes
[18:54:28 CET] <pinPoint> i see
[18:55:15 CET] <pinPoint> so if the separation was 9MB. x264 v x265. If I do a 2-pass on x265, the file might get even smaller?
[18:56:23 CET] <DHE> not smaller. you set a target bitrate of 7501 kbit. which means you should be able to calculate the exact file size (muxing notwithstanding)
[18:56:35 CET] <DHE> afk
[18:56:36 CET] <pinPoint> on the documentation they used: /dev/null && \ in windows command... that is going to be different
[19:03:08 CET] <DHE> regarding my PCR issue, I think the issue is the PCR interval is initially calculated for the source material's timebase, but then timestamps start coming in with mpegts timebase so the PCR is way off kilter
[19:17:36 CET] <pinPoint> DHE: so 2pass will never get smaller files vs 1 pass?
[19:18:12 CET] <DHE> pinPoint: within the expected variance, setting the -b:v parameter will dictate the target file size
[19:18:29 CET] <DHE> 1pass or 2pass doesn't matter, the target size is exactly that
[19:19:16 CET] <pinPoint> ok
[19:31:29 CET] <KallDrexx> Hey all, I am struggling getting ffmpeg working with NVENC support on ubunut. I've installed the cuda libraries from the nvidia sdk (they show up in ldconfig -p), compiled ffmpeg with --enable-nvenc, yet ffmpeg still keeps telling me "Failed loading CUDA library" when I pass in -vcodec nvenc. Any ideas?
[19:32:48 CET] <KallDrexx> Looking at the ffmpeg source it appears that message occurs when trying to load the libcuda.so, but since ldconfig -p shows that library I'm unsure of what the actual issue is
[20:23:51 CET] <shincode> is YUVY just YUV 422?
[20:40:43 CET] <JEEB> another way of holding it, yes
[20:41:02 CET] <JEEB> the data is the same after you parse it, but it's packed differently
[20:41:27 CET] <shincode> Well turns out I have YUVY/I420 either or
[20:41:40 CET] <shincode> and I need it in a opencv Mat class :)
[20:42:09 CET] <fritsch> lol
[20:46:36 CET] <shincode> Mat imgMat = Mat(height * 1.5f, width, CV_8UC1, data); i hope that works
[20:46:54 CET] <fritsch> no that won't
[20:46:58 CET] <fritsch> it's just one layer
[20:47:03 CET] <fritsch> CV_8UC1
[20:47:11 CET] <fritsch> 0..255 byte image
[20:47:21 CET] <fritsch> ah now I got it
[20:47:30 CET] <fritsch> yeah, you might get that stored in there
[20:47:40 CET] <fritsch> but opencv cannot really know what to do with it
[20:55:51 CET] <shincode> what did you say
[20:55:56 CET] <shincode> before i lost the internet
[20:56:27 CET] <shincode> will i need to call cvtColor(myuv
[21:05:32 CET] <shincodex> come back to me!
[22:25:13 CET] <Prelude_Zzzzz> hey , anyone see something wrong with this : http://pastebin.com/kzA96Znt .. i am seeing an error : Enter command: <target>|all <time>|-1 <command>[ <argument>]
[22:25:13 CET] <Prelude_Zzzzz> Parse error, at least 3 arguments were expected, only 1 given in string 'anada.Movie0008.mkv movie8'
[22:25:16 CET] <Prelude_Zzzzz> nots rue where that is coming from
[22:27:01 CET] <shincodex> just paste it all in channel
[22:27:07 CET] <shincodex> it makes it more alive that way.
[22:28:19 CET] <Prelude_Zzzzz> haha
[22:28:24 CET] <Prelude_Zzzzz> ya i feel your pain
[22:31:35 CET] <llogan> Prelude_Zzzzz: we don't debug user scripts here. do you get that message with an unscripted, manual ffmpeg command? also, you're expected to always show the complete console output.
[22:32:25 CET] <Prelude_Zzzzz> well my script is not doing anything really... just pushing data to ffmpeg.. its odd.. i am going to try manually but this script barely does anyting except set variables
[22:56:10 CET] <Prelude_Zzzzz> http://pastebin.com/J4kR4R7G
[22:56:13 CET] <Prelude_Zzzzz> here is the full thing
[22:56:14 CET] <Prelude_Zzzzz> very odd
[22:56:19 CET] <Prelude_Zzzzz> i have no idea where its coming from
[22:57:38 CET] <Prelude_Zzzzz> iether im loosing it, or ffmpeg is :P
[22:57:54 CET] <Prelude_Zzzzz> and i am really not sure which way to vote right now
[23:00:50 CET] <Prelude_Zzzzz> maybe just maybe...
[23:01:21 CET] <Prelude_Zzzzz> maybe it has to go to file and i have to use concat becuase the while read f doesn't like to wait for one to be finished before doing the other .. very odd
[23:01:47 CET] <Prelude_Zzzzz> doesn't make sense though
[23:02:58 CET] <Prelude_Zzzzz> doesnt' make any sense :(
[23:33:33 CET] <llogan> you're still running a script
[00:00:00 CET] --- Tue Dec 8 2015
1
0
[00:45:26 CET] <cone-055> ffmpeg 03Rostislav Pehlivanov 07master:fcd9c6334a88: doc/encoders.texi: fix typo and clarify mpeg2_aac_low
[01:44:16 CET] <llogan> kierank: trac needs another reboot for Yet Another Kernel Update. could you do that when you get a chance whenever you're near the machine?
[02:04:03 CET] <Compn> If you are familiar with decibels you can also use dB:
[02:04:03 CET] <Compn> ffmpeg -i input.wav -af "volume=10dB" output.wav
[02:04:09 CET] <Compn> why "dB" case sensitive ?
[02:04:20 CET] <Compn> and then type "db" and get parse error. terrible
[02:06:11 CET] <J_Darnley> Good. Enforce accurate and correct units! /s
[02:26:14 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:cc80478463dd: avcodec/cabac_functions: Fix "left shift of negative value -31767"
[02:26:15 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:d3de02d9d442: avcodec/cabac: Check initial cabac decoder state
[02:26:16 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:c6b81e252e7a: avcodec/hevc: Check entry_point_offsets
[02:26:17 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:551e18aa9205: avcodec/jpeg2000dwt: Check ndeclevels before calling dwt_decode*()
[02:26:18 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:6bc2f5cc0b23: avcodec/jpeg2000dwt: Check ndeclevels before calling dwt_encode*()
[02:26:19 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:f9d6d02fd1d6: avcodec/hevc_cabac: Fix multiple integer overflows
[02:26:20 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:d8c0546ecdb0: avcodec/hevc: allocate entries unconditionally
[02:26:21 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:2b9e849c3712: avcodec/vp3: Clear context on reinitialization failure
[02:26:22 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:6e28d0d0475f: avcodec/utils: Use 64bit for aspect ratio calculation in avcodec_string()
[02:26:23 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:e5d162ae9bd5: avcodec/utils: Clear dimensions in ff_get_buffer() on failure
[02:26:24 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:439452a851f0: avformat/dump: Fix integer overflow in av_dump_format()
[02:26:25 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:60369668ca34: avutil/integer: Fix av_mod_i() with negative dividend
[02:26:26 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:582a6035bc8d: avutil/mathematics: Do not treat INT64_MIN as positive in av_rescale_rnd
[02:26:27 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:73870147f855: avcodec/mpeg4videodec: Check available data before reading custom matrix
[02:26:28 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:9b28bbb10c6b: avcodec/vp3: always set pix_fmt in theora_decode_header()
[02:26:29 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:eff24a1f13b1: avcodec/apedec: Check length in long_filter_high_3800()
[02:26:30 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:238c7c8276e5: avutil/mathematics: return INT64_MIN (=AV_NOPTS_VALUE) from av_rescale_rnd() for overflows
[02:26:31 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:c8ca4b327542: avutil/timecode: Fix fps check
[02:26:32 CET] <cone-055> ffmpeg 03Timo Teräs 07release/2.5:cfd1bc581099: mpegencts: Fix overflow in cbr mode period calculations
[02:26:33 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:f41c1d3bfeca: avcodec/vp3: Fix "runtime error: left shift of negative value"
[02:26:34 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:c108dfc6ccd8: avformat/smacker: fix integer overflow with pts_inc
[02:26:35 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:4b77e0a33ee7: avcodec/wmaprodec: Fix overflow of cutoff
[02:26:36 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:38c1ab17ea7e: avcodec/wmaprodec: Check bits per sample to be within the range not causing integer overflows
[02:26:37 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:752a6591b2db: avcodec/dirac_parser: Fix potential overflows in pointer checks
[02:26:38 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:87dbcf7cd28e: avcodec/dirac_parser: Add basic validity checks for next_pu_offset and prev_pu_offset
[02:26:39 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:9ce8308ee364: avcodec/dirac_parser: Check that there is a previous PU before accessing it
[02:26:40 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:5c0be549efc2: avcodec/hevc: Fix integer overflow of entry_point_offset
[02:26:41 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:5b41c961469a: swscale/utils: Fix for runtime error: left shift of negative value -1
[02:26:42 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:e4f90cbd0dd0: avcodec/pgssubdec: Fix left shift of 255 by 24 places cannot be represented in type int
[02:26:43 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:f217aca5ba79: avcodec/jpeg2000dec: Check bpno in decode_cblk()
[02:26:44 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:4a91e424dae8: avcodec/vp3: ensure header is parsed successfully before tables
[02:26:45 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.5:f0ae57aca4c9: avcodec/hevc: Check max ctb addresses for WPP
[04:41:30 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:31e54f41a023: avcodec/hevc: Check entry_point_offsets
[04:41:31 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:9d5bdca3d8af: avcodec/jpeg2000dwt: Check ndeclevels before calling dwt_decode*()
[04:41:32 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:9ce96a688b18: avcodec/jpeg2000dwt: Check ndeclevels before calling dwt_encode*()
[04:41:33 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:e34876954429: avcodec/hevc_cabac: Fix multiple integer overflows
[04:41:34 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:1cbc2cb5084e: avcodec/hevc: allocate entries unconditionally
[04:41:35 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:d32c9723a626: avcodec/vp3: Clear context on reinitialization failure
[04:41:36 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:ce6dd54711b3: avcodec/hevc: Check max ctb addresses for WPP
[04:41:37 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:fe89682d7c61: avcodec/utils: Use 64bit for aspect ratio calculation in avcodec_string()
[04:41:38 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:7372b42b184d: avcodec/utils: Clear dimensions in ff_get_buffer() on failure
[04:41:39 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:2fbf72358517: avcodec/h264_refs: Check that long references match before use
[04:41:40 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:3d69716baefd: avformat/dump: Fix integer overflow in av_dump_format()
[04:41:41 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:4d9999705f40: avutil/integer: Fix av_mod_i() with negative dividend
[04:41:42 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:460710500e17: avutil/mathematics: Do not treat INT64_MIN as positive in av_rescale_rnd
[04:41:43 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:8cd3def81d11: avcodec/mpeg4videodec: Check available data before reading custom matrix
[04:41:44 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:aab65146afd8: avcodec/vp3: always set pix_fmt in theora_decode_header()
[04:41:45 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:d295ddffe138: avcodec/apedec: Check length in long_filter_high_3800()
[04:41:46 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:e04b039b1528: avutil/mathematics: return INT64_MIN (=AV_NOPTS_VALUE) from av_rescale_rnd() for overflows
[04:41:47 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:f2258e98991c: avutil/timecode: Fix fps check
[04:41:48 CET] <cone-055> ffmpeg 03Timo Teräs 07release/2.8:aa9ac199b8c7: mpegencts: Fix overflow in cbr mode period calculations
[04:41:49 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:b8621a2e9860: avformat/riffdec: Initialize bitrate
[04:41:50 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:73966b01618e: avcodec/vp3: Fix "runtime error: left shift of negative value"
[04:41:51 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:0e3ec7db5334: avformat/smacker: fix integer overflow with pts_inc
[04:41:52 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:16c5da92d997: avcodec/wmaprodec: Fix overflow of cutoff
[04:41:53 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:ded0a0415377: avcodec/wmaprodec: Check bits per sample to be within the range not causing integer overflows
[04:41:54 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:b253035ab23d: avcodec/dirac_parser: Fix potential overflows in pointer checks
[04:41:55 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:cf79fd0317ed: avcodec/dirac_parser: Add basic validity checks for next_pu_offset and prev_pu_offset
[04:41:56 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:0fa92fee4338: avcodec/dirac_parser: Check that there is a previous PU before accessing it
[04:41:57 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:10fc3d690c8b: avcodec/hevc: Fix integer overflow of entry_point_offset
[04:41:58 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:af4454561338: swscale/utils: Fix for runtime error: left shift of negative value -1
[04:41:59 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:e5a404477153: avcodec/pgssubdec: Fix left shift of 255 by 24 places cannot be represented in type int
[04:42:00 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:ea4d9cb3e559: avcodec/jpeg2000dec: Check bpno in decode_cblk()
[04:42:01 CET] <cone-055> ffmpeg 03Michael Niedermayer 07release/2.8:d27d59fef7e3: avcodec/vp3: ensure header is parsed successfully before tables
[04:42:02 CET] <cone-055> ffmpeg 03James Zern 07release/2.8:cb4985ea9aa2: libvpxenc: remove some unused ctrl id mappings
[06:42:17 CET] <Timothy_Gu> What's so difficult about translating the OpenHEVC x86 intrinsics to assembly?
[10:03:01 CET] <cone-443> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:21c34cb26154: libavutil: add version component accessor macros
[10:10:09 CET] <cone-443> ffmpeg 03Paul B Mahol 07master:3e1724baf8aa: avfilter/af_stereotools: fix logic fail
[10:52:48 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.8:913c642c21dd: Update for 2.8.4
[11:36:08 CET] <nevcairiel> new nvidia encoder sdk was released, the encode api header is now licensed MIT. :)
[12:57:31 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:ab79e3d1a5f9: avcodec/libopusenc: Fix infinite loop on flushing after 0 input
[12:57:32 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:6f08086992c3: avcodec/truemotion1: Check for even width
[12:57:33 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:e5c9396a0293: avformat/dump: Fix integer overflow in aspect ratio calculation
[12:57:34 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:7ffe708297e9: avutil/common: Document FFABS() corner case
[12:57:35 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:c09fe0346d94: avutil/common: Add FFNABS()
[12:57:36 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:79b16c6e5e2f: avformat/mov: Fix integer overflow in FFABS
[12:57:37 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:f66787d3452c: swresample/swresample: Fix integer overflow in seed calculation
[12:57:38 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:ec35bb729cdd: avcodec/tta: Check init_get_bits8() for failure
[12:57:39 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:45c30d84b6c5: avcodec/svq1dec: Check init_get_bits8() for failure
[12:57:40 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:47b6ea314df6: avcodec/g2meet: Fix potential overflow in tile dimensions check
[12:57:41 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:873ee14b560f: avcodec/g2meet: Also clear tile dimensions on header_fail
[12:57:42 CET] <cone-443> ffmpeg 03Ganesh Ajjanagadde 07release/2.4:3ea20e60dc5d: avfilter/af_asyncts: use llabs for int64_t
[12:57:43 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:7cdd319b01cf: avcodec/mjpegdec: Fix decoding RGBA RCT LJPEG
[12:57:44 CET] <cone-443> ffmpeg 03Simon Thelen 07release/2.4:c6769b6d56be: lavf/webvttenc: Require webvtt file to contain exactly one WebVTT stream.
[12:57:45 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:b5b29b22c0f8: avcodec/rangecoder: Check e
[12:57:46 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:ac19d8eb3ac7: avcodec/ffv1dec: Explicitly check read_quant_table() return value
[12:57:47 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:a2a93b0a8f5d: avcodec/ffv1dec: Fix off by 1 error in quant_table_count check
[12:57:48 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:71fc26403f14: avcodec/x86/sbrdsp: Fix using uninitialized upper 32bit of noise
[12:57:49 CET] <cone-443> ffmpeg 03Andrey Utkin 07release/2.4:eaf03fa8304c: avformat/httpauth: Add space after commas in HTTP/RTSP auth header
[12:57:50 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:a3753ba10df1: avcodec/ffv1dec: Clear slice coordinates if they are invalid or slice header decoding fails for other reasons
[12:57:51 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:f0db50a57f7b: avcodec/ffv1dec: update progress in case of broken pointer chains
[12:57:52 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:99dd039d743d: avcodec/ffv1: Initialize vlc_state on allocation
[12:57:53 CET] <cone-443> ffmpeg 03Tobias Rapp 07release/2.4:1bb7529ac2ed: avutil/file_open: avoid file handle inheritance on Windows
[12:57:54 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:2f89546333b5: avcodec/mjpegdec: Check index in ljpeg_decode_yuv_scan() before using it
[12:57:55 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:5d9bee34f9ae: avcodec/mjpegdec: Reinitialize IDCT on BPP changes
[12:57:56 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:fe191124a9ca: avcodec/ffv1dec: Check for 0 quant tables
[12:57:57 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:51ac1ce9668f: libavutil/channel_layout: Check strtol*() for failure
[12:57:58 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:a3ff74c872ab: avformat/xmv: factor return check out of if/else
[12:57:59 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:76950e524733: avformat/xmv: Discard remainder of packet on error
[12:58:00 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:7ce70e6914bf: avcodec/dirac_parser: Fix undefined memcpy() use
[12:58:01 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:c15f5068ca83: avcodec/microdvddec: Check for string end in 'P' case
[12:58:02 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:d73a8ae70f15: avcodec/jpeg2000dec: Clip all tile coordinates
[12:58:03 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:ac302efb9151: avcodec/jpeg2000dec: Check for duplicate SIZ marker
[12:58:04 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:00dc345a83b8: avcodec/utils: Better check for channels in av_get_audio_frame_duration()
[12:58:05 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:f68ff799eb00: avcodec/ivi: Check image dimensions
[12:58:06 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:52d332b044eb: avcodec/flashsv: Check size before updating it
[12:58:07 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:99e080ec38ee: avcodec/dpx: Move need_align to act per line
[12:58:08 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:3879202d68ce: avcodec/error_resilience: avoid accessing previous or next frames tables beyond height
[12:58:09 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:0814b140b1d7: avcodec/dxtory: Fix input size check in dxtory_decode_v1_420()
[12:58:10 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:6ba69f60ecb6: avcodec/dxtory: Fix input size check in dxtory_decode_v1_410()
[12:58:11 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:9356635e761a: avcodec/takdec: Skip last p2 sample (which is unused)
[12:58:12 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:3449b47dc548: avcodec/smacker: Check that the data size is a multiple of a sample vector
[12:58:13 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:dccb80dd50ee: avcodec/wmaprodec: Check for overread in decode_packet()
[12:58:14 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:aa780a52717e: avcodec/jpeg2000: Use av_image_check_size() in ff_jpeg2000_init_component()
[12:58:15 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:9aa4b9c2a342: avcodec/jpeg2000: Check comp coords to be within the supported size
[12:58:16 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:50870dd3de5c: avcodec/jpeg2000dec: Check SIZ dimensions to be within the supported range
[12:58:17 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:f1058efc8160: avcodec/jpeg2000dec: Fix potential integer overflow with tile dimensions
[12:58:18 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:3cef69c576c5: avformat/utils: Do not init parser if probing is unfinished
[12:58:19 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:75fa9c0b39f1: avformat/matroskadec: Check subtitle stream before dereferencing
[12:58:20 CET] <cone-443> ffmpeg 03Martin Storsjö 07release/2.4:65d6748d9e42: rtmpcrypt: Do the xtea decryption in little endian mode
[12:58:21 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:ee5ba259d12d: avcodec/vp8: Do not use num_coeff_partitions in thread/buffer setup
[12:58:22 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:e9ec9be14679: avcodec/h264_slice: Limit max_contexts when slice_context_count is initialized
[12:58:23 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:e8054a9595fe: avcodec/cabac_functions: Fix "left shift of negative value -31767"
[12:58:24 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:20de3b007bbd: avcodec/cabac: Check initial cabac decoder state
[12:58:25 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:961a1f73e392: avcodec/hevc: Check entry_point_offsets
[12:58:26 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:c44ee37cbd05: avcodec/jpeg2000dwt: Check ndeclevels before calling dwt_decode*()
[12:58:27 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:b6932f643438: avcodec/jpeg2000dwt: Check ndeclevels before calling dwt_encode*()
[12:58:28 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:453542f14d3c: avcodec/hevc_cabac: Fix multiple integer overflows
[12:58:29 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:02764f12a671: avcodec/hevc: allocate entries unconditionally
[12:58:30 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:af3e5bdd0d32: avcodec/vp3: Clear context on reinitialization failure
[12:58:31 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:733510fb6583: avcodec/utils: Use 64bit for aspect ratio calculation in avcodec_string()
[12:58:32 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:95bdbfe85159: avcodec/utils: Clear dimensions in ff_get_buffer() on failure
[12:58:33 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:a3ec4b307b4f: avformat/dump: Fix integer overflow in av_dump_format()
[12:58:34 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:5cc411022e49: avutil/integer: Fix av_mod_i() with negative dividend
[12:58:35 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:53ddc450c80f: avutil/mathematics: Do not treat INT64_MIN as positive in av_rescale_rnd
[12:58:36 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:c3f268b01c89: avcodec/mpeg4videodec: Check available data before reading custom matrix
[12:58:37 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:516525a1031b: avcodec/vp3: always set pix_fmt in theora_decode_header()
[12:58:38 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:ce15d773d4f7: avcodec/apedec: Check length in long_filter_high_3800()
[12:58:39 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:f91e71cc68fb: avutil/mathematics: return INT64_MIN (=AV_NOPTS_VALUE) from av_rescale_rnd() for overflows
[12:58:40 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:4ecdd45d2410: avutil/timecode: Fix fps check
[12:58:41 CET] <cone-443> ffmpeg 03Timo Teräs 07release/2.4:ec94195b80d9: mpegencts: Fix overflow in cbr mode period calculations
[12:58:42 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:1aa415ffb152: avcodec/vp3: Fix "runtime error: left shift of negative value"
[12:58:43 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:0819598b008e: avformat/smacker: fix integer overflow with pts_inc
[12:58:44 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:f19d3fe8e951: avcodec/wmaprodec: Fix overflow of cutoff
[12:58:45 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:ae434647409d: avcodec/wmaprodec: Check bits per sample to be within the range not causing integer overflows
[12:58:46 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:142f8308a121: avcodec/dirac_parser: Fix potential overflows in pointer checks
[12:58:47 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:e5a2128ead24: avcodec/dirac_parser: Add basic validity checks for next_pu_offset and prev_pu_offset
[12:58:48 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:9459490c2ae9: avcodec/dirac_parser: Check that there is a previous PU before accessing it
[12:58:49 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:bafd5c3c80a4: avcodec/hevc: Fix integer overflow of entry_point_offset
[12:58:50 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:c02a9f1c6e8c: swscale/utils: Fix for runtime error: left shift of negative value -1
[12:58:51 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:c676db730e36: avcodec/pgssubdec: Fix left shift of 255 by 24 places cannot be represented in type int
[12:58:52 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:311de799a81e: avcodec/jpeg2000dec: Check bpno in decode_cblk()
[12:58:53 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:9ee155c745b5: avcodec/vp3: ensure header is parsed successfully before tables
[12:58:54 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:70720f3e4d9e: avcodec/hevc: Check max ctb addresses for WPP
[12:58:55 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:6c83283c3a00: avcodec/ffv1dec: Print an error if the quant table count is invalid
[12:58:56 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:3a1aaec9bbcc: avcodec/ffv1dec: Clear quant_table_count if its invalid
[13:46:01 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.4:9f0e36b10116: update for 2.4.12
[13:52:20 CET] <michaelni> atomnuker, did you see "http://fate.ffmpeg.org/report.cgi?time=20151206103056&slot=x86_32-debian-kf…" <-- aac-pns-encode failure
[13:53:24 CET] <michaelni> same failure also occurs with more recent gccs like gcc 4.4.5 (Debian 4.4.5-8)
[13:54:19 CET] <michaelni> also gcc 4.9.3 (Gentoo 4.9.3 p1.2, pie-0.6.3)
[13:54:30 CET] <michaelni> http://fate.ffmpeg.org/report.cgi?time=20151206110425&slot=x86_32-athlon64-…
[13:57:24 CET] <atomnuker> michaelni: at first I thought they were miscompiling but now I think about it I think the reference needs to be changed
[14:04:23 CET] <michaelni> isnt the test encodig a wav then decoding aand comparing to that wav ? or am i mixing something up?
[14:06:09 CET] <atomnuker> michaelni: the reference definitely changed, that's why they fail
[14:06:30 CET] <michaelni> you mean the .wav changed ?
[14:06:59 CET] <atomnuker> no, CMP_TARGET did
[14:09:05 CET] <michaelni> ahh yes, in ca203e9985cd2dcf42a0c0853940850d3a8edf3a
[14:10:13 CET] <michaelni> i guess ill leave that to you and claudio to fix
[14:11:05 CET] <michaelni> btw, if i should contact claudio about it, tell me
[14:12:14 CET] <atomnuker> michaelni: no, there was a commit later that broke it
[14:12:37 CET] <atomnuker> I remember FATE said it last succeeded before a Ganesh commit which improved the table accuracy
[14:13:12 CET] <atomnuker> and since the deviation is failing because it's lower it would make sense
[14:14:01 CET] <atomnuker> either way I'm getting CMP value of 616 on my machine rather than the 663 as is currently in the test
[14:14:25 CET] <atomnuker> I'll give it a test on another machine and I'll push a fix for that
[14:14:50 CET] <atomnuker> (along with some TNS fixes which solve the problems in the recent trac ticket)
[14:16:03 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.0:58986f0fa151: avcodec/ffv1dec: Check for 0 quant tables
[14:16:04 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.0:5628d6202217: avcodec/ffv1dec: Print an error if the quant table count is invalid
[14:16:05 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.0:2789b48b4ef5: avcodec/ffv1dec: Clear quant_table_count if its invalid
[14:16:07 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.1:fde9b80c17e1: avcodec/ffv1dec: Check for 0 quant tables
[14:16:08 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.1:d9593e075161: avcodec/ffv1dec: Print an error if the quant table count is invalid
[14:16:09 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.1:65f4425ad580: avcodec/ffv1dec: Clear quant_table_count if its invalid
[14:16:10 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.2:1aa1f4bbf45e: avcodec/ffv1dec: Check for 0 quant tables
[14:16:11 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.2:8a6a619cbeee: avcodec/ffv1dec: Print an error if the quant table count is invalid
[14:16:12 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.2:a9e4be1cdf6f: avcodec/ffv1dec: Clear quant_table_count if its invalid
[14:16:13 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.3:eb0a9cd68a25: avcodec/ffv1dec: Check for 0 quant tables
[14:16:14 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.3:1fff9947098b: avcodec/ffv1dec: Print an error if the quant table count is invalid
[14:16:15 CET] <cone-443> ffmpeg 03Michael Niedermayer 07release/2.3:0fde898f16cf: avcodec/ffv1dec: Clear quant_table_count if its invalid
[14:22:06 CET] <cone-443> ffmpeg 03Ganesh Ajjanagadde 07master:90409b6da88b: avformat/rtsp: free opts dictionary on failure of getnameinfo
[14:22:07 CET] <cone-443> ffmpeg 03Ganesh Ajjanagadde 07master:f1f323b6de03: avformat/movenc-test: correct varargs usage
[14:22:08 CET] <cone-443> ffmpeg 03Ganesh Ajjanagadde 07master:14886bebfe7a: avcodec/dvdsubdec: fix typo in dlog message
[14:22:09 CET] <cone-443> ffmpeg 03Ganesh Ajjanagadde 07master:65440916c17d: ffplay: use hypot()
[14:26:53 CET] <ubitux> alright, some (but not all) of my instances are going back.
[14:54:27 CET] <wm4> wow even gstreamer dropped Libav
[14:56:28 CET] <kierank> wow
[14:58:26 CET] <atomnuker> kierank: I don't seem to have access to avdev (permission denied (publickey))
[14:58:33 CET] <atomnuker> so I can't test my patches there
[14:58:43 CET] <kierank> yeah I reinstalled the machine
[14:59:46 CET] <atomnuker> I've uploaded them to the ML, so if people can see if the retuned CMP_TARGETs make FATE pass on the kfreebsd machines that'd be nice
[15:00:50 CET] <kierank> atomnuker: I'll try and setup the vpn tomorrow
[15:00:50 CET] <kierank> so you can use internaldev
[15:02:01 CET] <atomnuker> michaelni: ping since you test a system with a failing PNS on FATE (x86_32-debian-kfreebsd-gcc-4.4)
[15:03:41 CET] <cone-443> ffmpeg 03Timothy Gu 07master:9670165cc227: ffprobe: Do not print profile names in -bitexact
[15:03:42 CET] <cone-443> ffmpeg 03Timothy Gu 07master:b0669e7ccfef: fate/concatdec: Use -bitexact
[15:09:47 CET] <ubitux> coverage.ffmpeg.org in sync again
[15:10:14 CET] <ubitux> btw, small reminder, for anyone curious about the evolution of the code coverage, there is http://lucy.pkh.me/ffmpeg-coverage-snapshots/
[15:13:04 CET] <ubitux> mateo`: http://fate.ffmpeg.org/report.cgi?time=20151206141037&slot=x86_64-archlinux…
[15:13:16 CET] <michaelni> atomnuker, i dont see it on the ML yet but probably easier to push and see if fate gets fixed then trying to reproduce the issue outside a fate client
[15:13:29 CET] <michaelni> its not happening locally on x86-32 it seems
[15:14:28 CET] <michaelni> atomnuker, seems its reproduceable with --disable-asm on x86-32
[15:14:36 CET] <michaelni> ill test your patch once it appears
[15:14:42 CET] <ubitux> mateo`: also, http://fate.ffmpeg.org/report.cgi?time=20151206135755&slot=x86_64-archlinux…
[15:14:50 CET] <ubitux> it seems to be missing a dependency check
[15:15:15 CET] <michaelni> atomnuker, whats the subj of the patch/mail btw?
[15:15:35 CET] <atomnuker> aacenc: move the TNS search and filtering before PNS
[15:15:47 CET] <atomnuker> the other 2 patches are replies to this one
[15:17:26 CET] <michaelni> am i the only one who hasnt received these mails yet ?
[15:17:38 CET] <michaelni> they are in the ML acrhive
[15:17:56 CET] <ubitux> mails are taking some time to reach me too
[15:18:57 CET] <michaelni> TimNich, theres a mail latency problem (see above) (not sure this is a new or still a existing one) but it definitly needs to be fixed
[15:20:31 CET] <nevcairiel> i didnt get the mails yet either
[15:20:52 CET] <michaelni> TimNich, is there something i can do or look into to help about this mail issue ?
[15:21:58 CET] <nevcairiel> just got a mail datestamped 50 minutes ago
[15:22:00 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20151206142043&slot=x86_64-archlinux… erh..
[15:22:00 CET] <nevcairiel> something surely is slow
[15:23:02 CET] <ubitux> would this be because of "type const" vs "const type"?
[15:23:26 CET] <ubitux> int32_t const *samples_s32[2] = { (const int32_t *)samples0,
[15:23:28 CET] <ubitux> (const int32_t *)samples1 };
[15:23:42 CET] <ubitux> maybe we should write const int32_t *samples_s32?
[15:24:16 CET] <nevcairiel> const type *var and type const *var are semantically identical
[15:24:27 CET] <ubitux> yes, but maybe ubsan is confused?
[15:25:18 CET] <nevcairiel> i personally prefer the const before the type myself
[15:25:37 CET] <ubitux> i think that's what we use all over the code base anyway
[15:25:57 CET] <nevcairiel> not sure why index checks should fail from that, however
[15:29:31 CET] <kierank> can I be added to ffmpeg-security btw
[16:13:33 CET] <michaelni> TimNich, where does the spamassasin logs go ?
[16:30:07 CET] <ubitux> nevcairiel: vp9 tests are failing with threading
[16:30:26 CET] <ubitux> (not sure if it's because of your recent commits but i think it was related)
[16:30:34 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20151206144611&slot=x86_64-archlinux…
[16:30:37 CET] <nevcairiel> what did i do to vp9
[16:30:55 CET] <ubitux> didn't you add accel or sth?
[16:31:00 CET] <nevcairiel> not yet
[16:31:03 CET] <ubitux> ah
[16:31:10 CET] <nevcairiel> failure is probably related to bbb's recent changes
[16:31:12 CET] <ubitux> then maybe i should pokeBBB
[16:31:16 CET] <ubitux> yeah
[16:31:27 CET] <ubitux> it was time i needed to renable my fate instances...
[16:31:35 CET] <ubitux> so much issues :p
[16:31:45 CET] <ubitux> and valgrind instance not yet done
[16:33:01 CET] <nevcairiel> vp9_decode_update_thread_context probably needs to check for pix_fmt changes
[16:35:16 CET] <nevcairiel> more specifically, just copy s->pix_fmt between threads
[16:38:42 CET] <nevcairiel> lets test if i can fix it and send a patch
[16:43:16 CET] <ubitux> nice the new hetzner offer https://www.hetzner.de/ot/hosting/produkte_rootserver/ex41
[16:43:48 CET] <JEEB> wow
[16:44:04 CET] <nevcairiel> those things are getting cheaper every year
[16:44:06 CET] <JEEB> that's pretty nice as far as dedis go
[16:44:15 CET] <nevcairiel> i have a haswell variant from 2013 or so
[16:44:39 CET] <JEEB> I will see when I'll want to go over the 20eur I pay right now for my 8core atom
[16:44:55 CET] <ubitux> skylake 2x4TB at this price is pretty nice
[16:45:00 CET] <ubitux> btw, i see some ARM boxes as well
[16:45:15 CET] <ubitux> maybe i should order one for real arm fate instances
[16:45:32 CET] <nevcairiel> ubitux: i send a patch for vp9 to the ml
[16:45:42 CET] <Daemon404> ubitux, dont we have lots of arm instance
[16:46:15 CET] <ubitux> Daemon404: qemu mostly
[16:46:21 CET] <ubitux> nevcairiel: can't really review
[16:48:32 CET] <Daemon404> ubitux, every one i looked at just now seems real
[16:49:53 CET] <nevcairiel> ubitux: didnt you write half the decoder :D
[16:50:02 CET] <ubitux> not really
[16:50:20 CET] <ubitux> that's just what Ronald like to say :)
[16:54:35 CET] <Daemon404> wow SMC.
[16:57:46 CET] <nevcairiel> I wonder if I should send a patch for nvenc that removes the nonfree condition but instead requires the most recent version
[16:57:53 CET] <nevcairiel> making nonfree version dependent seems rather complex
[16:57:59 CET] <BtbN> huh?
[16:58:08 CET] <BtbN> Did they actualy fix their shit?
[16:58:10 CET] <nevcairiel> they released the 6.0 sdk
[16:58:15 CET] <nevcairiel> the header is now MIT licensed
[16:58:19 CET] <BtbN> wow
[16:58:27 CET] <BtbN> so it could even be bunbled, removing the dependency entirely?
[16:58:30 CET] <BtbN> -b
[16:58:42 CET] <nevcairiel> license wise, sure, i guess
[16:58:59 CET] <BtbN> I guess i'll just do that and send it to the ML
[16:59:27 CET] <BtbN> could just be called nvenc.h
[17:00:16 CET] <BtbN> woah, and the SDK is only 20MB now, no longer a 600MB blob, like the SDK v4
[17:00:28 CET] <nevcairiel> v5 already cleaned out a lot of the stuff
[17:00:51 CET] <nevcairiel> they also added the cuvid decoder into this sdk, so you dont need the full cuda sdk blob anymore
[17:01:08 CET] <BtbN> Why would anyone still use that?
[17:01:15 CET] <nevcairiel> dunno
[17:01:36 CET] <BtbN> The download is slow as hell though
[17:01:38 CET] <nevcairiel> the API is extremely simple to use, so for a quick nvidia transcode app it might work
[17:02:06 CET] <BtbN> Currently at an amazing 50KB/s
[17:02:17 CET] <nevcairiel> didnt notice slowness when i grabbed it earlier
[17:02:41 CET] <BtbN> down to 30 now
[17:03:15 CET] <nevcairiel> just tried again, download still fast
[17:03:21 CET] <BtbN> the hell
[17:03:58 CET] <BtbN> looks like only one of their servers is dead
[17:09:20 CET] <BtbN> So does that mean nvenc would now be enabled by default in lgpl builds?
[17:09:25 CET] <BtbN> So basicaly, removing all checks?
[17:09:46 CET] <nevcairiel> if it doesnt add runtime dependencies, then sure
[17:09:57 CET] <BtbN> All runtime deps are dlopene'd
[17:10:08 CET] <nevcairiel> but i'm sure someone will complain about bundling the nvidia header somewhere =p
[17:10:56 CET] <BtbN> From how I understand the MIT license, I'm free to do whatever I want with it. So if i'd make a stripped down version of it that complies with the ffmpeg style, why not?
[17:11:28 CET] <nevcairiel> personally I would probably use the untouched header, makes updating it in the future easier
[17:11:51 CET] <BtbN> I wouldn't change how it works, just style it propperly and remove most comments
[17:12:01 CET] <BtbN> And add Cygwin support ;)
[17:12:37 CET] <nevcairiel> people still care about cygwin?
[17:12:49 CET] <BtbN> It's my primary "platform", so I do.
[17:13:32 CET] <BtbN> All that's missing is a single check, that sets the stdcall convention when building on cygwin
[17:13:50 CET] <nevcairiel> does cygwin not set _WIN32?
[17:14:01 CET] <Daemon404> of course it wouldnt
[17:14:06 CET] <Daemon404> its supposed to emulate linux
[17:15:03 CET] <BtbN> This configure script... I hate it every time i have to touch it.
[17:15:23 CET] <nevcairiel> its not that bad when you get to know where things are
[17:15:39 CET] <BtbN> Currently searching what I have to change to enable nvenc by default
[17:16:04 CET] <nevcairiel> just remove the external nvenc component entirely
[17:16:24 CET] <nevcairiel> and treat it like an internal decoder
[17:16:27 CET] <nevcairiel> encoder*
[17:16:44 CET] <BtbN> It still needs ldl though
[17:17:19 CET] <BtbN> https://gist.github.com/BtbN/18ffe94bde0d84286c52 so, like this?
[17:18:38 CET] <nevcairiel> enabling it without any sort of tests might be risky though, who knows if the header works on every system out there, and there certainly arent binaries for every system
[17:20:08 CET] <BtbN> So basicaly just a "compile #include "nvenc.h"" test?
[17:20:32 CET] <BtbN> And limited to windows and linux
[17:22:55 CET] <nevcairiel> you could keep the generic nvenc component so it can be disabled entirely with the checks, and just enable it by default (add it somewhere around line 2980, maybe to the xlib line, its so lonely)
[17:23:26 CET] <Daemon404> wait wee still use libx11/xlib?
[17:23:35 CET] <Daemon404> i thought we moved to xcb based off of vlc's
[17:23:35 CET] <nevcairiel> of course
[17:23:51 CET] <nevcairiel> x11grab uses xlib
[17:24:01 CET] <BtbN> You mean, leaving in nvenc_encoder_deps="nvenc", call enable nvenc somewhere, and then do checks that disable it?
[17:24:02 CET] <Daemon404> we didnt backport xcbgrab?
[17:24:04 CET] <Daemon404> :V
[17:24:06 CET] <nevcairiel> and the vaapi ffmpeg.c module uses xlib
[17:24:16 CET] <BtbN> There is a vaapi ffmpeg.c module?
[17:24:43 CET] <nevcairiel> hm there isnt, whats this check used for then
[17:24:57 CET] <BtbN> propably vdpau, as it also needs an X display?
[17:25:20 CET] <nevcairiel> there is HAVE_VAAPI_X11, but its not used anywhere, apparently
[17:25:24 CET] <wm4> vaapi doesn't need xlib
[17:25:33 CET] <BtbN> Depends on how you use it
[17:25:38 CET] <BtbN> For ffmpeg, it doesn't.
[17:25:39 CET] <wm4> you can also use it with a wayland display, or use raw drm
[17:26:25 CET] <wm4> a ffmpeg_vaapi.c (if it ever exists) should probably use raw drm
[17:27:31 CET] <nevcairiel> Daemon404: we have xcbgrab, but what makes you think that replaced x11grab? =p
[17:28:02 CET] <wm4> nothing ever gets removed etc.
[17:28:17 CET] <Daemon404> nevcairiel, ... because it is better in every way?
[17:28:20 CET] <Daemon404> and just as portable
[17:28:28 CET] <nevcairiel> what do i care about files that never get compiled for me, if you care, send a removal patch =p
[17:28:29 CET] <Daemon404> NOBODY is going to be missing libxcb
[17:29:17 CET] <wm4> what if someone has a SunOS machine from 1986?
[17:32:29 CET] <BtbN> Hm, there is no appropriate check for a header that's part of ffmpeg
[17:32:48 CET] <nevcairiel> no, that concept is slightly odd =p
[17:47:20 CET] <BtbN> I'm not even sure how to propperly include that header. Is it safe to assume that the conftest scripts are built in the toplevel source dir?
[17:47:47 CET] <Daemon404> no
[17:47:54 CET] <Daemon404> out off tree builds are normal
[17:48:01 CET] <Daemon404> there's a var for that
[18:51:21 CET] <michaelni> TimNich, are you around ? ive figured out how to make mailman be verbose about SMTP connections but you know the mail stuff i dont
[19:08:38 CET] <BtbN> configure on cygwin takes forever...
[19:09:16 CET] <nevcairiel> even longer than on windows? =p
[19:09:44 CET] <BtbN> it forks _a lot_
[19:09:48 CET] <BtbN> and fork on cygwin is slow
[19:10:19 CET] <BtbN> msys doesn't try to emulate fork like cygwin does, so it's quite a bit faster.
[19:10:57 CET] <cone-458> ffmpeg 03Paul B Mahol 07master:45b451c89239: avfilter/af_alimiter: add 3 more options
[19:11:19 CET] <nevcairiel> mingw is already quite slow, if you compare to linux..
[19:11:50 CET] <BtbN> looks like nobody tried to build on cygwin for a while. The schannel stuff explodes. It propably shouldn't even try to build it.
[19:12:36 CET] <nevcairiel> i think i saw someone post about that on trac
[19:12:46 CET] <nevcairiel> but cba to cygwin
[19:12:57 CET] <BtbN> it spews so many errors that it exceeds my 50k line buffer in my terminal.
[19:13:43 CET] <jamrial> why do you need to ue cygwin anyway?
[19:13:50 CET] <BtbN> Because i want to use it.
[19:14:00 CET] <BtbN> And as it's a supported platform, stuff should build.
[19:14:31 CET] <nevcairiel> its a "supported" platform, one of those no core dev cares about or tests on =p
[19:14:54 CET] <nevcairiel> and its crazy enough to break easily
[19:15:28 CET] <jamrial> i don't see the appeal when you can build natively for windows, and even with pthreads emulation if that's what you want, but to each their own
[19:15:49 CET] <BtbN> I use Cygwin to have a propper terminal on Windows
[19:16:12 CET] <jamrial> you can use the cygwin environment and build using mingw
[19:16:26 CET] <jamrial> they have a mingw-w64 package
[19:16:26 CET] <BtbN> Sure, but then ffmpeg isn't aware of cygwin-paths
[19:18:24 CET] <nevcairiel> BtbN: https://trac.ffmpeg.org/ticket/5036
[19:18:25 CET] <BtbN> huh, aparently cygwin doesn't emulate fork anymore
[19:18:38 CET] <BtbN> they use the actual fork function from some low-level kernel interface
[19:19:39 CET] <BtbN> Was that patch ever sent?
[19:20:49 CET] <jamrial> apparently not
[19:20:53 CET] <wm4> BtbN: wow, do they? reference for this?
[19:21:29 CET] <nevcairiel> BtbN: probably not
[19:21:47 CET] <nevcairiel> if it works, should send it to the ML
[19:35:55 CET] <michaelni> TimNich, i maybe understand what is causing the latency issues, but not sure, i might be wrong too
[20:33:58 CET] <RiCON> someone's really passionate about Apple Graphics
[20:38:38 CET] <nevcairiel> he is just too stubborn to simply post the info requested =p
[20:39:09 CET] <nevcairiel> i think its funny that users can keep re-opening shit a developer closed, though
[20:46:43 CET] <RiCON> looks like he remuxed http://samples.mplayerhq.hu/V-codecs/SMC/aletrek-smc.mov with mkvmerge
[20:46:51 CET] <RiCON> and that remuxed file doesn't work
[21:03:33 CET] <cehoyos> Hi! Does git clone http://git.videolan work for anybody?
[21:03:40 CET] <cehoyos> What was the reason for the change?
[21:04:31 CET] <Compn> from http:// to git:// you mean ?
[21:04:42 CET] <Compn> have to ask in #videolan probably
[21:04:52 CET] <Compn> or maybe j-b..
[21:06:16 CET] <cehoyos> But I am curious if it works for FFmpeg: After all, we changed our homepage and since I didn't see any discussion on ffmpeg-devel, I assumed the discussion was here, wasn't it?
[21:07:58 CET] <nevcairiel> works for me, but cloning through http is not as verbose, so you wont get the typical status reporting as you used to get ... so just need to trust it works
[21:08:32 CET] <cehoyos> Well, it is verbose here, I get a lot of error reports (after waiting for a very long time)
[21:08:41 CET] <cehoyos> eror messages.
[21:09:00 CET] <nevcairiel> should talk to thresh then
[21:16:59 CET] <cone-458> ffmpeg 03Rostislav Pehlivanov 07master:b32e989e6c65: aacenc: move the TNS search and filtering before PNS
[21:17:00 CET] <cone-458> ffmpeg 03Rostislav Pehlivanov 07master:d55f83de4d41: aacenc_tns: tune and reduce artifacts
[21:17:01 CET] <cone-458> ffmpeg 03Rostislav Pehlivanov 07master:a0a39acd01ea: fate: change the CMP_TARGETs for the recent AAC encoder changes
[21:17:21 CET] <cehoyos> RiCON: I know that you want to help but how does the command line you provided allow to reproduce the issue in question?
[21:17:35 CET] <cehoyos> For the attached file
[21:18:17 CET] <RiCON> the issue's name comes from a comment tag in the matroska file
[21:18:39 CET] <RiCON> i don't have ffplay compiled, compiling now so i can test with it
[21:19:30 CET] <cehoyos> Please do not use ffplay!
[21:19:38 CET] <cehoyos> Just use "ffmpeg -i input -qscale 2 out.avi"
[21:19:55 CET] <RiCON> oh ok, you want the resulting file
[21:20:17 CET] <cehoyos> FFplay depends on an external library that sometimes is responsible for FFplay issues.
[21:20:21 CET] <nevcairiel> no, but you can test that way and play the avi
[21:20:52 CET] <atomnuker> Hey, Carl's back on irc!
[21:21:28 CET] <RiCON> ffmpeg doesn't really complain encoding or playing the .avi though
[21:21:43 CET] <RiCON> it's just black instead of showing what's in the original file
[21:22:14 CET] <cehoyos> That's fine.
[21:22:31 CET] <cehoyos> I mean this is what I need to understand the ticket.
[21:23:29 CET] <cehoyos> thresh does not react: May I revert the homepage patch?
[21:23:35 CET] <cehoyos> Hi, atomnuker!
[21:24:00 CET] <cehoyos> Or can somebody explain the reasoning, I probably miss something...?
[21:24:20 CET] <nevcairiel> the reasoning is that videolan would prefer if people used http instead
[21:24:20 CET] <atomnuker> cehoyos: you mean the git:// vs http:// one?
[21:25:03 CET] <atomnuker> yeah, that's pretty much it, thresh said he had bad memories of git:// and wanted to minimize usage on the videolan network
[21:25:29 CET] <cehoyos> This is exactly my question: What difference does it make?
[21:25:51 CET] <nevcairiel> git-daemon is shitty is the difference, and they dont want so much users on it
[21:25:51 CET] <cehoyos> Apart from the fact that I do not remember an issue with git:// (reported by users or myself) and http:// just doesn't work here.
[21:26:23 CET] <atomnuker> git:// is faster
[21:26:41 CET] <cehoyos> Is it really so difficult to understand what I request?
[21:26:43 CET] <atomnuker> though the main limit is still bandwidth
[21:27:06 CET] <cehoyos> RiCON: I never copy and paste but still: If you are a native speaker, please suggest a better wording...
[21:28:12 CET] <j-b> atomnuker: no, it should not.
[21:29:15 CET] <RiCON> i'm not native speaker, but if you're referring to the original person who opened the issue, i have no idea what was required to work
[21:30:19 CET] <cehoyos> What I mean is: I did not request attaching an output file (the issue is that this usually leads to developers testing the output file and not understanding the issue), I simply tried to ask for a command line that allows to reproduce the issue pasted together with its console output.
[21:31:38 CET] <cehoyos> j-b: git clone fails here with the new url, anything that can be done about it?
[21:32:25 CET] <RiCON> ok, so just a `mpv -v aletrek.mkv` followed by console output would be enough?
[21:32:46 CET] <j-b> cehoyos: ask thresh, he's around.
[21:32:56 CET] <j-b> cehoyos: the old urls still work.
[21:34:30 CET] <cehoyos> I opened a channel with him, he did not react so far.
[21:34:44 CET] <cehoyos> The problem is that the new url (that does not work here) is on the FFmpeg homepage.
[21:35:03 CET] <atomnuker> j-b: how come?
[21:35:08 CET] <cehoyos> (I was unable to find an explanation or discussion for the homepage change, only that it does not work).
[21:35:27 CET] <cehoyos> RiCON: No, because this isn't mpv-bugs...
[21:35:49 CET] <cehoyos> (And because - iirc - I asked for an "FFmpeg command line that allows ...")
[21:36:16 CET] <kierank> cehoyos: was discussed yesterday
[21:36:20 CET] <nevcairiel> j-b: definitely seems very slow right now to clone over http
[21:36:21 CET] <j-b> atomnuker: http is cachable
[21:36:25 CET] <kierank> On irc
[21:36:28 CET] <j-b> nevcairiel: ask thresh
[21:38:39 CET] <kierank> Anyone looking for paid asm work BTW?
[21:40:46 CET] <cehoyos> May I suggest to revert until the issues are solved?
[21:41:02 CET] <cehoyos> Or is there a big issue with git:// that I do not understand?
[21:41:42 CET] <kierank> I can revert when I get home yes
[21:51:06 CET] <cehoyos> Please do.
[21:54:00 CET] <cehoyos> atomnuker: Year-long experience has tought us to close a ticket and request to reopen if it is not fixed...
[21:59:19 CET] <RiCON> right, mpv still doesn't work with the mkv directly because it uses its own matroska demuxer.
[21:59:33 CET] <RiCON> forcing lavf as demuxer it plays the sample file fine
[22:27:03 CET] <kierank> cehoyos: reverted
[22:33:48 CET] <ubitux> kierank: what kind of asm?
[22:34:14 CET] <kierank> some x262 and some dirac
[22:34:31 CET] <ubitux> for x86?
[22:34:40 CET] <kierank> yes
[22:34:51 CET] <ubitux> only dirac is within ffmpeg?
[22:35:06 CET] <kierank> yes
[22:35:11 CET] <ubitux> i think durandal_1707 was looking for some asm to write recently
[22:36:08 CET] <durandal_1707> if its simple enough
[22:36:09 CET] <ubitux> i see some existing asm for dirac, what's missing?
[22:36:22 CET] <kierank> 10-bit
[22:36:49 CET] <kierank> and dequantisation
[22:37:05 CET] <ubitux> note: i won't have time, i'm just curious
[22:37:37 CET] <cehoyos> But the 10-bit code is missing from c as well, or am I wrong?
[22:37:58 CET] <kierank> cehoyos: see my latest patchset, more will be coming
[22:42:53 CET] <cone-469> ffmpeg 03Andreas Cadhalpun 07master:5adb5d9d894a: mjpegdec: consider chroma subsampling in size check
[23:04:46 CET] <J_Darnley> Re: cygwin. I haven't had my desktop turned on early enough to catch the old fate job I had scheduled.
[23:04:50 CET] <J_Darnley> BtbN ^
[23:06:12 CET] <J_Darnley> I really should have changed the time.
[23:57:18 CET] <durandal_1707> kierank: so how is cfhd going?
[23:59:45 CET] <kierank> durandal_1707: kinda ok, a bit confused about how to filter out junk bytes on new samples
[23:59:56 CET] <kierank> the junk bytes could clash with valid tags
[00:00:00 CET] --- Mon Dec 7 2015
1
0
[00:00:45 CET] <satt> or at least thats what I think I read/was told
[00:01:09 CET] <satt> I think the issue I'm running into is I'm trying to scale down as well as pad, in the same command...
[00:02:27 CET] <autofsckk> satt -> well man, im reading the docs about pad and it is as i told you pad=640:480:0:40:violet Add paddings with the color "violet" to the input video. The output video size is 640x480, and the top-left corner of the input video is placed at column 0, row 40
[00:02:41 CET] <autofsckk> that is w:h:x:y structure isnt it?
[00:04:03 CET] <autofsckk> if you put 0:0:320:568 as input area, you have a 0x0
[00:04:34 CET] <autofsckk> i have croped and scale after with no problem
[00:07:19 CET] <satt> totally is yeah. what I'm saying is that since x/y default to 0 you don't need to include them. my command works for most videos, except for when the input file is larger than the desired output like the error message says
[00:07:39 CET] <satt> Input area 0:0:320:568 not within the padded area 0:0:320:480 or zero-sized
[00:08:32 CET] <satt> 0:0:320:568 would be padding to 0x0, positioning the video at 320x568 - at least from what I understand
[00:09:46 CET] <satt> I appreciate the help man! but gotta run for a bit, back later
[00:10:57 CET] <autofsckk> what help :/ jajaja
[00:11:00 CET] <autofsckk> have a great day
[01:11:14 CET] <satt> back. hahah I appreciate you trying to help at least
[01:28:02 CET] <satt> Anyone know how I can solve this issue? I think it's caused from an input being larger than the area I'm padding to. I'm also scaling. Here's the error
[01:28:10 CET] <satt> Input area 0:0:320:568 not within the padded area 0:0:320:480 or zero-sized
[01:28:21 CET] <satt> command: ffmpeg -i INPUTS -filter_complex [0:v]scale=320:-2,pad=320:480,setsar=sar=1/1[v0]; [1:v]scale=320:-2,pad=320:480,setsar=sar=1/1[v1]; [2:v]scale=320:-2,pad=320:480,setsar=sar=1/1[v2]; [3:v]scale=320:-2,pad=320:480,setsar=sar=1/1[v3]; [4:v]scale=320:-2,pad=320:480,setsar=sar=1/1[v4]; [v0] [0:a:0] [v1] [1:a:0] [v2] [2:a:0] [v3] [3:a:0] [v4] [4:a:0] concat=n=5:v=1:a=1 [v] [a] -map [v] -map [a] out.mp4
[01:34:04 CET] <c_14> scale=if(gt(ih, iw), -2, 320):if(gt(ih, iw), 480, -2)
[01:34:11 CET] <c_14> instead of your current scale filters
[01:34:13 CET] <c_14> (probably)
[01:34:18 CET] <c_14> Note, you may need to escape things
[01:45:03 CET] <satt> ah thanks c_14, I'll give that a shot. Should I be keeping the pad arguments?
[01:45:11 CET] <c_14> yes
[01:45:36 CET] <satt> ok sweet
[01:58:11 CET] <satt> c_14: Looks like I need to escape or something, here's what I'm getting
[01:58:19 CET] <satt> Invalid size 'if(gt(ih'
[01:58:33 CET] <c_14> escape the comma
[01:58:54 CET] <satt> with a \ ?
[01:59:38 CET] <c_14> yes
[02:01:29 CET] <satt> cool thanks. it's running now
[02:05:49 CET] <satt> c_14 thanks so much! seems to have solved it!!
[04:20:46 CET] <luke11> hello, need help in compiling ffmpeg on debian 8
[04:21:13 CET] <luke11> im using this guide https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu but towards the end i am getting this error "ERROR: x265 not found using pkg-config"
[04:21:17 CET] <luke11> any suggestions?
[04:21:59 CET] <relaxed> luke11: https://bitbucket.org/multicoreware/x265/issues/212/new-libx265-not-found-i…
[04:22:46 CET] <luke11> thanks will give it a shot
[04:33:34 CET] <luke11> relaxed, didn't work for me unfortunately
[04:34:54 CET] <luke11> not sure where exactly i need to add <include stdbool.h> in the x265.h file
[04:36:35 CET] <relaxed> change it to --> #include <stdbool.h>
[04:36:43 CET] <luke11> will try, ty
[04:43:44 CET] <Admin_234234> hey everyone.. i am using ffmpeg hls segmenting with AES encryption... i have the whole ffmpeg stream with while 1 do ffmpeg ..... etc etc.. so basically if the stream fails it will reinitialize... the problem is sometimes i can't decrypt the channels and i have to restart them again for the decryption to happen again.. anyone know why its doing that.. if ffmpeg is restarted in the same session with the same script and stuff should it not
[04:43:44 CET] <Admin_234234> maintain the same keyinfo file ?
[04:49:05 CET] <waressearcher2> Admin_234234: hallo
[04:49:14 CET] <Admin_234234> hi
[04:49:21 CET] <waressearcher2> Admin_234234: wie geht's es dir ?
[04:49:31 CET] <Admin_234234> ?
[05:55:14 CET] <aphorise> Does ffmpeg support 3gp & 3gp2? - I'm trying to find a complete listing of supported containers.
[06:01:22 CET] <c_14> aphorise: it should. check ffmpeg -formats
[06:09:31 CET] <aphorise> c_14 thanks - do you think all video formats report a duration or is that attainable with: ffprobe -i sample.webm -select_streams v -show_streams 2>&1 | grep Duration # ?
[16:21:39 CET] <aphorise> `ffmpeg -formats` which video formats would potentially not provide its Durations? - I just trying to finalise a wrapper script using ffprobe && ffmpeg to confirm validity of files using -1 seconds less than the claimed length - just wondering which sorts of general `*.extension` I can enable as guide to supported container formats like `*.avi` which are supported for Demuxing
[16:40:02 CET] <Fjorgynn> hey
[19:23:19 CET] <aphorise> omg there are so many potential file extension that ffmpeg could parse ... I was going through a few of my old files & old line listings
[19:35:05 CET] <aphorise> Actually the vlc listing for videos seems to be the most sane + a few more that I have on my list
[19:38:15 CET] <prelude2004c> hey everyone.. check this out " http://pastebin.com/f1qHT061 " .. so i have the ffmpeg portion in a loop.. i am using the encryption and files exist.. why is it sometimes when ffmpeg restarts using the while 1 loop the encryption stops working? i hvae to then force a restart again to get the image back. It's as if when it restarts the ffmpeg using the while 1 loop, it breaks and the system doesnt know to encrypt using the key .. weird..
[19:38:15 CET] <prelude2004c> doesn't exist complaining tha thte keyinfo file and key file doesnt' exist.. very odd.. any suggestions ?
[19:40:00 CET] <prelude2004c> hey everyone.. check this out " http://pastebin.com/f1qHT061 " .. so i have the ffmpeg portion in a loop.. i am using the encryption and files exist.. why is it sometimes when ffmpeg restarts using the while 1 loop the encryption stops working? i hvae to then force a restart again to get the image back. It's as if when it restarts the ffmpeg using the while 1 loop, it breaks and the system doesnt know to encrypt using the key ..
[19:40:01 CET] <prelude2004c> weird..doesn't exist complaining tha thte keyinfo file and key file doesnt' exist.. very odd.. any suggestions ?
[20:00:36 CET] <Prelude_Zzzzz> anyone
[20:00:37 CET] <Prelude_Zzzzz> ?
[20:05:04 CET] <dod> Hi, how to know the version of a specific encoder within ffmpeg? (I want to check wich version of VP9 is used)
[20:22:55 CET] <Prelude_Zzzzz> hey anyone know if -af volume requires something compiled into ffmpeg ? i seem to be using the param, its not complaining about anything but .. the volume does not change
[20:49:28 CET] <Guiri> I'm getting a new error trying to use the -filter_complex to concatenate movies into a single RTMP stream: vf/-af/-filter and -filter_complex cannot be used together for the same stream.
[20:49:35 CET] <Guiri> I used -vf to resize the movies to 480p for the stream.
[20:58:55 CET] <Mavrik> Aaand?
[21:20:18 CET] <autofsckk> hi, what does "-b:v" means-do? where can i find the explanation of that on the help documents?
[21:21:53 CET] <Mavrik> autofsckk, it sets bitrate (-b) for video (:v)
[21:22:24 CET] <autofsckk> thanks Mavrik
[21:24:09 CET] <autofsckk> Mavrik -> do you know a good source of information on how to use maybe a script to put in all the things to be done to a conversion? im doing more filters and stuff to videos, but i find a little complicated to do it all in console, i read that it is possible to use an external file but cant find about it yet on the help how to do it
[21:24:32 CET] <Mavrik> Hrmf, no idea out of my head, perhaps try ffmpeg wiki?
[21:27:00 CET] <autofsckk> im amazed with ffmpeg, so powerful tool
[22:04:20 CET] <durandal_1707> autofsckk: -filter_script script
[22:07:47 CET] <autofsckk> ok durandal_1707 thanks
[22:29:21 CET] <Prelude_Zzzzz> <autofsckk>, video bit rate is what it means
[22:50:04 CET] <Phrk_> Hello
[22:51:02 CET] <Phrk_> Do you know how to allow external connection with ffserver ?
[22:51:02 CET] <Phrk_> I don't understand the doc
[22:54:08 CET] <Phrk_> Sorry lagg problem
[23:01:16 CET] <klaxa> Phrk_: i think there is a configuration for access restriciton
[23:01:21 CET] <klaxa> in the configuration file i mean
[23:02:43 CET] <klaxa> what are you doing, what is happening and what are you expecting to happen instead?
[23:08:32 CET] <Phrk_> ffserver say : HTTP/1.1" 301 208
[23:08:37 CET] <Phrk_> for my external ip
[23:08:44 CET] <Phrk_> but work for localhost
[23:09:17 CET] <Phrk_> the <feed part is only for ffmpeg ?
[23:09:29 CET] <Phrk_> and the <Stream part i try ACL allow everything
[23:15:53 CET] <Phrk_> i don't understand how to allow everything
[23:15:58 CET] <Phrk_> * don't work
[23:16:05 CET] <Phrk_> klaxa
[23:16:23 CET] <klaxa> can you pastebin your ffserver.conf?
[23:17:50 CET] <Phrk_> of course
[23:18:42 CET] <Phrk_> klaxa : http://hastebin.com/ifedimuroj.coffee
[23:20:49 CET] <Phrk_> Application error ? Sorry for that : http://pastebin.com/Gui33CmC
[23:20:50 CET] <klaxa> uh... hmm...
[23:21:06 CET] <klaxa> ah they fixed it
[23:21:11 CET] <klaxa> no i'm just pondering what could be the issue
[23:21:28 CET] <klaxa> how do you try to send the stream to the server?
[23:21:49 CET] <klaxa> just ffmpeg -i somefile.mkv http://someserver/feed1.ffm ?
[23:22:50 CET] <klaxa> 301 is redirection, maybe you are using the wrong url and it is trying to redirect you to ffmpeg.org?
[23:23:35 CET] <klaxa> ah, are you trying to watch a stream or send a feed?
[23:23:48 CET] <klaxa> Phrk_: ^
[23:24:47 CET] <Phrk_> when i send to stream to localhost
[23:24:53 CET] <Phrk_> everything is working
[23:25:12 CET] <Phrk_> but when i try to read it with like vlc, mpv, or ffplay
[23:25:22 CET] <Phrk_> i can only read it from localhost, klaxa
[23:25:41 CET] <klaxa> how do you try to read it?
[23:26:01 CET] <Phrk_> from lan : mpv http://127.0.0.1:8090/live.flv
[23:26:05 CET] <klaxa> you should be able to watch http://someserver/live.flv
[23:26:06 CET] <klaxa> yeah
[23:26:07 CET] <klaxa> hmm...
[23:26:22 CET] <Phrk_> when i try from internet ffserver say something
[23:26:24 CET] <klaxa> not sure how the ACL parts are parsed
[23:26:32 CET] <Phrk_> HTTP/1.1" 301 208
[23:27:00 CET] <klaxa> maybe they overwrite? (doubt it though) but maybe removing the superfluous ones (localhost and 192.168.178.25) could help?
[23:27:17 CET] <klaxa> hmm.. but that really shouldn't be
[23:28:00 CET] <klaxa> i'll try to use your config and see if i can reproduce
[23:28:02 CET] <Phrk_> ACL deny 1.0.0.0 1.255.255.255 would deny the whole of network 1 and allow everybody else.
[23:28:12 CET] <Phrk_> how i allow everybody
[23:29:45 CET] <klaxa> hmm...
[23:30:07 CET] <klaxa> address is not further specified, so i can't tell whether or not it accepts wildcards
[23:30:23 CET] <klaxa> but ACL allow 0.0.0.0 255.255.255.255 should cover all addresses right?
[23:33:25 CET] <Phrk_> :( [GET] "/ HTTP/1.1" 301 208
[23:33:55 CET] <klaxa> :(
[23:34:50 CET] <Phrk_> what bind ?
[23:34:58 CET] <Phrk_> cause i have a lot of ethernet card
[23:35:21 CET] <klaxa> if you get a connection it's not a networking error
[23:35:28 CET] <klaxa> or at least it should not be :S
[23:35:49 CET] <Phrk_> ye of course
[23:36:18 CET] <Phrk_> Well time for bed, try this tommorow will be better
[23:36:22 CET] <klaxa> gotta go, maybe i'll tinker with this later tonight
[23:36:25 CET] <Phrk_> Thanks
[23:36:29 CET] <klaxa> kk
[00:00:00 CET] --- Mon Dec 7 2015
1
0