[Ffmpeg-devel-irc] ffmpeg.log.20190318

Tue Mar 19 03:05:01 EET 2019

[00:21:56 CET] <net|> was wondering if anyone knows why i get mjpeg error after it compiled with it
[00:22:07 CET] <net|> Cannot find a proper format for codec 'mjpeg' (id 7), pixel format 'none' (id -1)
[00:22:29 CET] <net|> was trying to get this working http://wiki.webmproject.org/adaptive-streaming/instructions-to-do-webm-live-streaming-via-dash
[00:26:38 CET] <hanetzer> there we go.
[00:30:14 CET] <hanetzer> so, here's a question. I have about 15m of h264 video from a security camera, and I'm trying to coerce ffmpeg into transcoding it from that to hevc using vaapi. it produces a file, but the resultant video is pretty much entirely grey with the exclusion of large noticeable motions in it (mostly static vid of an office with me in it working at a pc)
[00:31:24 CET] <hanetzer> the last thing I tried was `ffmpeg -init_hw_device vaapi=foo:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device foo -i testing.mp4 -filter_hw_device foo -vf 'format=nv12|vaapi,hwupload' -c:v hevc_vaapi output.mp4
[00:31:40 CET] <JEEB> sounds like the vaapi decoding is failing
[00:31:50 CET] <JEEB> try removing vaapi from before -i
[00:32:11 CET] <JEEB> also I'm not sure how much you gain with that
[00:32:26 CET] <JEEB> your input is probably badly compressed AVC with artifacts, and your output will be badly compressed HEVC :D
[00:32:43 CET] <JEEB> (since hw encoders are meant for low latency and "it doesn't utilize CPU" use cases)
[00:49:48 CET] <thebombzen> is there any reason not to use software decoding and encoding here?
[01:09:17 CET] <hanetzer> yeah, the amount of streams
[01:09:51 CET] <hanetzer> something like 32 video feeds, runnign throug a ryzen 2700x machine
[01:10:17 CET] <hanetzer> JEEB: honestly the original video is quite clear, 1920x1080
[01:10:47 CET] <hanetzer> oh wait...
[01:11:34 CET] <hanetzer> so, I was viewing the resultant encoded file via vlc (version currently unknown) on a win10 machine
[01:11:55 CET] <hanetzer> however, it plays back fine on vlc-3.0.6-r1 on my gentoo box
[01:28:27 CET] <dongs> jeeb, nice
[01:28:33 CET] <dongs> thats the 100meg .tlv sample then
[01:28:38 CET] <dongs> since it was from channel 881
[01:30:19 CET] <JEEB> yea
[01:30:36 CET] <xxxmaker> hi everybody i work in adult industry
[01:30:49 CET] <dongs> what a coincidence, me too
[01:32:45 CET] <xxxmaker> dongs usa or europe? or somewhere else
[01:33:11 CET] <JEEB> dongs: added a bit more handling of the descriptors http://up-cat.net/p/2865cb7d
[01:33:38 CET] <JEEB> although I guess the network side of things is less interesting :P
[01:34:16 CET] <dongs> yeah for a single stream it doesnt matter. not like you're gonna use this info to find other muxes/channels
[02:13:57 CET] <ossifrage> hanetzer, try doing the conversion without any hardware accel and see how it looks
[02:14:47 CET] <hanetzer> ossifrage: will do, though I'm currently in a 4hr crunch to finish some homework
[02:20:20 CET] <hanetzer> ossifrage: and I'll have to test it on the same hardware which I'm away from (since my linux vlc can read it, I must assume its the windows one that's the problemish for now)
[02:22:07 CET] <ossifrage> hanetzer, depending on the camera SOC, I suspect you'll find that the encoder on the camera is better then what you get out of your gpu
[02:23:22 CET] <hanetzer> its a hi3521a from hisilicon, with nextchip ahd stuff
[02:23:38 CET] <ossifrage> hanetzer, ah I'm working on firmware for a hi3519a camera right now
[02:24:06 CET] <hanetzer> ossifrage: oh nice. I'm actually fairly knowledgeable about those; are you talking about the mpp kernel modules/userspace libs?
[02:24:37 CET] <ossifrage> Userspace stuff, I don't work for hisilicon
[02:24:39 CET] <hanetzer> as in, foss drivers? because if so, do tell and I'd be more than willing to help :D
[02:24:42 CET] <hanetzer> nor I.
[02:25:02 CET] <hanetzer> I just own a fair amount of their chinesium consumer electronics
[02:25:05 CET] <ossifrage> I'm doing an opensource firmware replacement project
[02:25:24 CET] <hanetzer> nice, got a repo?
[02:25:39 CET] <ossifrage> Buy a camera with the hi3519a and a support sensor and you get something that is less horrible
[02:26:06 CET] <ossifrage> hanetzer, it isn't public yet, I'm still in early devel and trying to find a suitable donor camera
[02:27:17 CET] <ossifrage> I only have drivers 2 sensors and the cameras you can buy (cheaply) on aliexpress all use a sensor I don't have a driver for :-(
[02:27:29 CET] <hanetzer> what sensor?
[02:27:45 CET] <ossifrage> The camera I have has a imx334
[02:27:59 CET] <hanetzer> k, I'll look into that. do you hang out here often?
[02:28:06 CET] <ossifrage> (the SDK only has a driver for the imx290 and imx334)
[02:28:27 CET] <ossifrage> hanetzer, yeah I have been
[02:28:28 CET] <hanetzer> I don't follow that logic
[02:28:51 CET] <hanetzer> camera has imx334 and sdk has imx334 seems like no problem
[02:29:12 CET] <ossifrage> The camera I'm using was $600 and from a company that I think has gone bust
[02:29:36 CET] <xxxmaker> anybody here who is video/camera expert ?
[02:30:01 CET] <ossifrage> It is basically a naked eval board (and they didn't even ship it with the right cables)
[02:30:51 CET] <ossifrage> (it was from Taobao, so not a good candidate for my project)
[02:30:56 CET] <xxxmaker> anybody here who is expert in video production or shooting camera?
[02:33:58 CET] <another> just ask your question instead of meta-questions
[02:35:28 CET] <xxxmaker> another are you able to visit  NSFW  website
[02:36:55 CET] <xxxmaker> yes or no
[02:37:02 CET] <another> not really
[02:37:51 CET] <xxxmaker> you cannot help me then
[02:38:44 CET] <xxxmaker> anybody here who is expert in video production or shooting camera?  (who is able to visit NSFW websites) ?
[02:44:21 CET] <hanetzer> ossifrage: nice. have you been just repackaging their mpp or are you actually going for a full foss stack rewrite?
[02:44:32 CET] <xxxmaker> anybody here who is expert in video production or shooting camera?
[03:15:00 CET] Last message repeated 1 time(s).
[03:15:46 CET] <dongs> xxxmaker: how many times you gonna ask that?
[03:15:58 CET] <xxxmaker> till somebody says yes
[03:16:10 CET] <dongs> or till you get banned, what's more likely outcome
[03:16:19 CET] <dongs> i've got some 4K cams, but i'm far from expert
[03:16:35 CET] <xxxmaker> dongs i see, are you able to visit NSFW website?
[03:16:43 CET] <xxxmaker> dongs nice to meet you
[03:17:02 CET] <dongs> I'm actually making JAV but like, it doesn't really need any skill
[03:17:33 CET] <dongs> its mostly the post that takes time, blurring out all those pubic hairs
[03:17:42 CET] <dongs> tracking the position and shit.
[03:17:52 CET] <dongs> luckily there's j-software for windows thats designed specifically for this purpose
[03:18:42 CET] <xxxmaker> how hard is it to blurr out hairs?
[03:20:02 CET] <dongs> just tedious mostly
[03:20:07 CET] <dongs> not hard
[03:20:14 CET] <xxxmaker> is it illegal to NOT blurr them out?
[03:20:19 CET] <dongs> correct
[03:20:32 CET] <dongs> well, if the stuff is to be sold/rented legitimately
[03:21:12 CET] <xxxmaker> japanese have weird fetishes
[03:21:28 CET] <xxxmaker> that i cannot comprehend
[03:23:26 CET] <xxxmaker> dongs can i post you some links
[03:27:09 CET] <hanetzer> JEEB: yep, looks like vlc on the windows box is a 2.x release :P
[03:27:24 CET] <dongs> what is teh question, i can probably gather it from textual description
[03:28:40 CET] <xxxmaker> dongs i am just wondering why one video look ook and one video look so bad,   same lighting/location
[03:28:50 CET] <xxxmaker> dongs i am just wondering why one video look good and one video look so bad,   same lighting/location
[03:30:34 CET] <dongs> ok lets see
[03:30:55 CET] <xxxmaker> i am sure you can figure out which one is which
[03:31:08 CET] <dongs> . hopefully that site doesn't ban japan
[03:31:17 CET] <dongs> ah it works jsut slow as balls
[03:31:24 CET] <xxxmaker> dongs are you japanese?
[03:32:31 CET] <dongs> man you gotta host this shit somewehre less retarded. the site is literally dead
[03:32:40 CET] <xxxmaker> it's super fast here
[03:33:42 CET] <xxxmaker> try using   wget  http://url
[03:33:48 CET] <dongs> what do you think im doing
[03:33:56 CET] <xxxmaker> what speed you getting?
[03:34:01 CET] <dongs> none
[03:34:02 CET] <dongs> Connecting to trailer-stream-ht.realitykingscontent.com (trailer-stream-ht.realitykingscontent.com)|208.99.84.114|:443... connected.
[03:34:05 CET] <dongs> HTTP request sent, awaiting response...
[03:34:05 CET] <dongs> its not even connecting.
[03:34:19 CET] <dongs> it connected once and downloaded a ~500byte 'gateway timeout" message
[03:34:26 CET] <xxxmaker> try   http  not https
[03:34:52 CET] <dongs> that works slightly better
[03:35:08 CET] <xxxmaker> how fast ?
[03:35:20 CET] <dongs> 100k+- but pauses often
[03:35:30 CET] <xxxmaker> that is weird
[03:36:01 CET] <xxxmaker> i get 3Mbyte/s  here
[03:36:09 CET] <dongs> 2019-03-18 11:36:00 (56.2 KB/s) - Connection closed at byte 4388268. Retrying.
[03:36:11 CET] <xxxmaker> not bit, but byte
[03:36:17 CET] <dongs> yeah i mean, if you're local to the hosting sure it will be fast
[03:37:07 CET] <dongs> ya now its just failing with gateway timeout.
[03:37:09 CET] <dongs> man, your internet sucks
[03:37:39 CET] <xxxmaker> i can try sending directly by dcc
[03:37:58 CET] <xxxmaker> but i can't see that being better
[03:38:23 CET] <dongs> it will download eventually i think
[03:38:29 CET] <dongs> shit's slow but its moving after a few retries.
[03:39:00 CET] <xxxmaker> is that normal that  Asian country have hard time downloading from  USA hosts ?
[03:39:16 CET] <xxxmaker> is that normal that  Asian countries have hard time downloading from  USA servers?
[03:39:39 CET] <pink_mist> very normal. this is why sites like AWS have options to have hosts in those countries
[03:39:51 CET] <pink_mist> like, on both sides of the link
[03:39:59 CET] <xxxmaker> pink_mist are you able to visits NSFW site?
[03:40:19 CET] <pink_mist> yes, but I've got no clue about ffmpeg stuff really, so not sure what the use would be
[03:40:29 CET] <xxxmaker> pink_mist what country are you in?
[03:40:32 CET] <pink_mist> sweden
[03:40:58 CET] <xxxmaker> pink_mist how fast can you download that
[03:41:18 CET] <pink_mist> 100%[====================================================================================================>]  17.05M  9.81MB/s    in 1.7s
[03:41:23 CET] <dongs> xxxmaker: eva looks much better, the aubrey colors are garbage
[03:41:27 CET] <xxxmaker> lol 9.81MB/s
[03:41:36 CET] <pink_mist> well, because I'm on a 100Mbit link
[03:41:38 CET] <xxxmaker> that's faster than mine
[03:41:49 CET] <pink_mist> I bet if I was on a Gbit link it'd be faster than that
[03:41:49 CET] <xxxmaker> and i am not in europe
[03:42:09 CET] <xxxmaker> dongs  exaclty,  why is that do you think
[03:42:26 CET] <dongs> yeah second link over http:// downloaded at 5.6meg here. it just sounds like whatever hosting service is beat up with traffic
[03:44:50 CET] <pink_mist> second link: 100%[====================================================================================================>]  20.28M  10.3MB/s    in 2.0s
[03:44:58 CET] <xxxmaker> lol 10.3MB/s
[03:45:05 CET] <xxxmaker> that's really fast
[03:45:14 CET] <xxxmaker> but you are in europe
[03:45:19 CET] <xxxmaker> how is that possible
[03:45:47 CET] <pink_mist> between US and EU the links are much much faster than between Asia and US
[03:46:16 CET] <pink_mist> plus it's 3:45 am here, so most people are asleep
[03:46:23 CET] <pink_mist> thus a bit less network usage
[03:48:30 CET] <xxxmaker> pink_mist actually iplocation is saying the ip is located in  Netherland
[03:48:56 CET] <pink_mist> hah, well alright, that explains it then :P
[03:48:57 CET] <xxxmaker> but i don't know how accurate that info is
[03:49:30 CET] <pink_mist> do note that I didn't get the same IP as dongs got ...
[03:49:34 CET] <xxxmaker> pink_mist now can you view the 2 videos and tell me which one is bad and good
[03:50:13 CET] <xxxmaker> pink_mist what IP did you get then?
[03:51:34 CET] <pink_mist> Resolving trailer-stream-ht.realitykingscontent.com (trailer-stream-ht.realitykingscontent.com)... 64.210.135.16, 64.210.135.28, 64.210.135.18, ...
[03:51:48 CET] <xxxmaker> wow totally different IP than mine
[03:52:36 CET] <pink_mist> I'd agree with dongs that eva looks much better
[03:52:46 CET] <xxxmaker> pink_mist  right, so why is that
[03:52:54 CET] <xxxmaker> i am trying to figure out why
[03:53:01 CET] <xxxmaker> same lighting/location
[03:53:15 CET] <xxxmaker> same codec/format
[03:55:20 CET] <pink_mist> if you hadn't said it was the same lighting I would have guessed on that ... but then I have no idea :/
[04:01:43 CET] <pink_mist> oh, a third one too, let me check
[04:02:24 CET] <pink_mist> looks good to me
[04:02:37 CET] <xxxmaker> yes exactly
[04:02:53 CET] <xxxmaker> try to understand why
[05:19:17 CET] <xxxmaker> anybody here who is expert in video production or shooting camera?
[05:23:33 CET] <fling> xxxmaker: hey
[05:23:42 CET] <xxxmaker> fling are you expert?
[05:23:50 CET] <fling> also ask at #photogeeks and #photography
[05:23:56 CET] <fling> What is your question? :D
[05:23:59 CET] <xxxmaker> i see, thanks
[05:24:09 CET] <xxxmaker> fling first, are you able to visit  NSFW sites
[05:24:18 CET] <fling> I am.
[05:24:23 CET] <xxxmaker> good
[05:25:08 CET] <xxxmaker> watch 2 videos and tell the difference
[05:32:27 CET] <xxxmaker> fling ??
[05:46:44 CET] <fling> xxxmaker: where are the videos? Have I missed a link?
[05:47:30 CET] <xxxmaker> fling do you see it now?
[05:51:21 CET] <fling> sorry, no
[05:51:31 CET] <xxxmaker> i did  /notice fling
[05:51:45 CET] <fling> ok see it
[05:52:13 CET] <xxxmaker> sorry i typed one link twice
[05:54:49 CET] <fling> xxxmaker: what do you mean by difference? :P
[05:54:58 CET] <xxxmaker> did you watch both videos?
[05:55:39 CET] <xxxmaker> yes or no
[05:55:57 CET] <fling> Yes.
[05:56:41 CET] <xxxmaker> one has good color/sharp and one has bad color/not-sharp
[05:56:50 CET] <xxxmaker> can you tell which one is bad
[05:57:24 CET] <fling> Both are bad
[05:58:00 CET] <xxxmaker> no one is good
[05:58:32 CET] <fling> the one from 2015 is better than one from 2012
[06:00:19 CET] <xxxmaker> you mean 2014 ?
[06:00:21 CET] <fling> you can probably get dmc-gx7 or something even better from injapan.ru for cheap for shooting such things.
[06:00:35 CET] <fling> Stop using your phone for shooting videos ;P
[06:01:50 CET] <fling> I got years from the metadata.
[06:02:21 CET] <xxxmaker> oh
[06:03:58 CET] <fling> with micro four thirds hardware you can get a fine fast lens with wide aperture but it will still give you the deep depth of field
[06:04:05 CET] <fling> xxxmaker: which is good for shooting in the dark
[06:04:20 CET] <fling> xxxmaker: this way the picture will stay sharp in you will open the aperture
[06:05:11 CET] <fling> s/in/if/
[06:56:00 CET] <jgb> everybody:  https://www.cloudflare.com/ssl/encrypted-sni/  do you pass all 4 test   : if not you have issues with security
[07:59:38 CET] <jgb> i noticed  ffmpeg.exe has  one  .exe file and has no  additional  .dll file or nothing.    is that possible for all  apps?
[09:20:08 CET] <jgb>  hi i am doing a survey:  what is the first 5  third party application do you install  after  doing  clean installation of windows:   thanks
[11:04:24 CET] <pink_mist> either: 1: linux, or if I'm going to be playing games: 1: firefox 2: cygwin 3: xplorer² 4: steam 5: cccp
[11:42:49 CET] <th3_v0ice> How can I force muxer to send a packet even if its DTS is not monotonically increasing? How is FFmpeg achieving this? Because if I understand correctly from the info that FFmpeg is printing it just increaseses DTS by (int)1, in case that the packet's DTS from the input is not monotonically increasing and the packet is still sent by the muxer. In my case, I am doing the same, but muxer seems
[11:42:49 CET] <th3_v0ice> to be dropping packets, nothing is written to the output.
[11:44:38 CET] <DHE> that's what ffmpeg the CLI tool does. libavformat does reject it
[11:52:15 CET] <th3_v0ice> I am not sure what to do then. I tried calculating precisely what the next DTS should be, but it proved that in some scenarios, variable packet duration, it cause audio sync issues.
[11:52:58 CET] <th3_v0ice> What should I do then? Increase the DTS that is problematic by what amount? So it doesnt cause sync issues.
[12:13:40 CET] <fling> th3_v0ice: this is interesting, tell me if you will figure out how do to this and/or if it will help.
[12:28:03 CET] <dongs> Media Type 0:
[12:28:04 CET] <dongs> --------------------------
[12:28:04 CET] <dongs> Audio: AAC 64000Hz 3ch 403kbps
[12:28:18 CET] <dongs> JEEB: ^ some weird shit
[12:28:59 CET] <JEEB> :D
[12:29:10 CET] <dongs> im not sure if this is correct. hold on
[12:29:12 CET] <JEEB> reminds me of some people using 3.1ch
[12:29:24 CET] <JEEB> and almost every audio API then proceeding to take that in as 4ch
[12:29:40 CET] <dongs> http://bcas.tv/paste/results/LxCWeK58.html
[12:29:47 CET] <dongs> i donno wats going on, could be my shit busted too
[12:30:02 CET] <dongs> the other guy is taking a look now to see wat i fucked up
[12:41:59 CET] <dongs> Audio: AAC 64000Hz 28ch 349kbps
[12:42:01 CET] <dongs> ah yes.
[12:44:47 CET] <dongs> ideo: HEVC 7680x4320 59.94fps [V: hevc main 10, yuv420p10le, 7680x4320]
[12:54:38 CET] <dongs> kek, mpv uses 80% cpu
[12:54:42 CET] <dongs> decodign this at like 1/2 framerate
[12:54:54 CET] <dongs> mpc-hc is OK tho, liek 2%
[12:55:31 CET] <durandal_1707> dongs: you are not using hw decoder
[12:55:48 CET] <dongs> no shit
[12:56:12 CET] <dongs> which is why mpc-hc is playing it ok
[12:56:20 CET] <dongs> i donno, id idnt expect mpv to decode it in harwdare
[12:56:22 CET] <dongs> was just testing mostly
[13:20:34 CET] <satoshi2> 2 hours later autobuild suite is still installing and compiling shit
[13:20:44 CET] <satoshi2> what a hog
[13:26:23 CET] <aboxer> #join gstreamer
[13:32:41 CET] <BtbN> "autobuild suite"
[13:32:52 CET] <BtbN> there is nothing like that ffmpeg offers, you'll have to complain to who made it
[13:42:25 CET] <JEEB> dongs: hwdec=d3d11va-copy or just d3d11va should work
[13:42:38 CET] <JEEB> just not enabled by default, but I think LAV doesn't enable that either
[13:43:16 CET] <faLUCE> Do you know if with the current version of libavcodec I can mux (mpegts+h264) video non keyframes before muxing a keyframe? I remember that I could do that safely with 2.8.7 and, pheraps, the muxer itself discarded the non keyframes.
[13:43:30 CET] <JEEB> I don't think it would care?
[13:43:51 CET] <JEEB> I'd be surprised if the muxer would wait until you gave it a RAP packet (keyframe flag)
[13:45:23 CET] <faLUCE> JEEB: is this info stored into "flag" field of avframe or into "key_frame" ? or both? (I don't have key_frame on av_packet)
[13:46:50 CET] <JEEB> AVPacket has the keyframe flag and setting that correctly is the encoder's job
[13:47:11 CET] <JEEB> since you were talking about a muxer AVFrame doesn't even relate
[13:47:28 CET] <faLUCE> ok, but where is this this value? in the "flags" field?
[13:47:40 CET] <faLUCE> (of avpacket)
[13:48:23 CET] <faLUCE> the api doc doesn't say anything about this field
[13:49:06 CET] <JEEB> yes, it has bit fields (AV_PKT_FLAG_KEY) unfortunately they're not listed right next from it
[13:49:12 CET] <JEEB> pkt->flags |= AV_PKT_FLAG_KEY*pic_out.b_keyframe; <- so AV_PKT_FLAG_KEY
[13:49:22 CET] <JEEB> that's from libx264.c for example
[13:49:31 CET] <JEEB> it sets that flag on the AVPacket if x264 tells it it's a RAP
[13:49:56 CET] <faLUCE> so, before sending the first packet to av_write_frame() should I check if it's keyframe?
[13:50:05 CET] <JEEB> depends on what you want to do?
[13:50:16 CET] <faLUCE> I have to record a muxed file
[13:50:20 CET] <JEEB> yes?
[13:50:27 CET] <JEEB> do you want to start at a RAP or not?
[13:50:46 CET] <faLUCE> ok, but I remember that I did not have to do that in the 2.8.7 version
[13:50:51 CET] <JEEB> you still don't
[13:50:56 CET] <JEEB> where did you get that idea?
[13:51:23 CET] <faLUCE> I mean: if I record a file, it should start with a keyframe
[13:51:38 CET] <JEEB> I don't think it ever filtered
[13:51:41 CET] <JEEB> if it did that's funky
[13:52:00 CET] <JEEB> also check if packets containing the parameter sets are muxed in first
[13:52:07 CET] <JEEB> those you want first in any case
[13:52:11 CET] <JEEB> 725
[13:53:40 CET] <faLUCE> what is 725 ?
[13:53:50 CET] <faLUCE> (and yes, they are muxed)
[14:22:29 CET] <satoshi2> BtbN it is linked on the compilation guide
[14:22:38 CET] <satoshi2> but it seems completely broken
[14:22:57 CET] <satoshi2> on a clean win8 install it borked now while compiling ffmpeg
[14:23:22 CET] <satoshi2> undefined references to clCreateImage and a bunch of other cls
[14:33:25 CET] <dongs> im pretty sure nobody in here builds this stuff on a real OS
[14:33:31 CET] <dongs> do they even provide a visual studio build project?
[14:33:36 CET] <dongs> or is it all retarded MakeFiles
[14:35:34 CET] <DHE> configure and retarded makefiles, thankyou
[14:45:29 CET] <BtbN> the compilation guide? If you mean the wiki, that is also just someone put there themselves, nothing official.
[14:48:53 CET] <satoshi2> yes
[14:50:50 CET] <JEEB> dongs: there are people who depend on having MSVC-built FFmpeg, so while we're doing the retarded thing of not duplicating our build system, we do even test it http://fate.ffmpeg.org/report.cgi?time=20190317214954&slot=x86_64-msvc15-windows-native
[14:57:33 CET] <dongs> cool
[14:57:56 CET] <dongs> prefix=c%3a/dev
[14:57:58 CET] <dongs> the fuck
[14:58:08 CET] <JEEB> we basically trolled MS to support C99 in MSVC in 2012-2013
[14:58:21 CET] <JEEB> because we made a thingamajig that preprocessed C99 into C89
[14:58:24 CET] <JEEB> for MSVC
[14:58:37 CET] <JEEB> and then in 2013 MS announced that they could build FFmpeg with MSVC 2013
[14:58:47 CET] <JEEB> (without that stuff)
[15:00:18 CET] <JEEB> and yea, the path stuff takes forward slashes on windows as well IIRC
[15:00:22 CET] <JEEB> so c:/ would also work
[15:00:44 CET] <JEEB> why it became c%3a is probably up to the FATE webui
[15:06:55 CET] <satoshi2> what would make ffmpeg complain about libopenh264.dll ?
[15:07:14 CET] <BtbN> Something being wrong with openh264
[15:08:47 CET] <satoshi2> nevermind, found it
[15:09:11 CET] <satoshi2> it creates a folder somewher else with the exes and required dlls
[16:59:49 CET] <satoshi2> JEEB i love you in a non twi way
[17:00:07 CET] <satoshi2> just tested on a AD and it worked
[17:00:43 CET] <satoshi2> on the dumped mp4 file the video just stopped when the ad started, and returned playing after the time passed
[17:01:47 CET] <satoshi2> resumed playing*
[17:09:13 CET] <satoshi2> ah, it misses a few seconds of video due to that ad
[17:09:37 CET] <satoshi2> the playback skips a few seconds ahead
[17:10:21 CET] <satoshi2> i guess the resolution change is confusing the player/demuxer
[17:12:51 CET] <JEEB> probably closer to timestamp stuff :/
[17:58:10 CET] <ncouloute> So it seems as if after my files are deinterlaced the timestamps are changed. Is there no way to get the exact same frame timing after deinterlacing on vfr content. Seems like a nasty combination. Although it seems as if showinfo is giving me the frame timing after the built in ffmpeg deinterlacing. So I could use those just harder to parse than the Matroska V2 Timecodes file.
[18:29:43 CET] <satoshi2> "Looks like the playlist containing the EXT-X-DISCONTINUITY tag is the one with ads (and the following ones until the next tag)"
[18:29:52 CET] <satoshi2> they are following standards for the ADs at least
[18:29:56 CET] <JEEB> yea
[18:30:17 CET] <JEEB> we just need to re-calculate timestamps so that they become consistent
[18:52:48 CET] <retal> faLUCE hi, do you remember my problem with disappearing lines?
[19:20:46 CET] <faLUCE> hello retal, yes, should has been the patch you used
[19:21:28 CET] <retal> faLUCE, yes y found prublem :) git apply ../ffmpeg_NVIDIA_gpu_acceleration.patch
[19:21:47 CET] <faLUCE> (for all others: do you know is there a way to force the encoder to produce a keyframe? I tried by setting avframe->key_frame = 1  but had no effect
[19:21:49 CET] <faLUCE> )
[19:22:22 CET] <faLUCE> retal: anyway, if you still want to use that patch it should not be difficult to re-patch it
[19:23:08 CET] <retal> faLUCE, but i think i need use that patch , because i need nvresize
[19:24:01 CET] <faLUCE> retal: did you check if the patch has been updated ?
[19:24:52 CET] <retal> i dont now , i download from http://developer.download.nvidia.com/compute/redist/ffmpeg/1511-patch/ffmpeg_NVIDIA_gpu_acceleration.patch
[19:25:05 CET] <retal> then git reset --hard b83c849e8797fbb972ebd7f2919e0f085061f37f
[19:26:22 CET] <faLUCE> retal: you should ask to people that made that patch. Even if we modify the patched code, in order to compile fine,  it could be unstable at runtime
[19:28:45 CET] <retal> faLUCE, i dint know who wrote this patch, also it will take take long time. So no other way compile ffmpeg with nvresize ?
[19:30:01 CET] <faLUCE> retal: as said before, the problem is not to compile it. The problem is that you can have an unstable program
[19:30:23 CET] <retal> oh
[19:30:42 CET] <faLUCE> anyway, paste again the patch, I tell you how to modify it (then you can try the result)
[19:31:02 CET] <faLUCE> I mean, paste the patched libx264.c
[19:31:32 CET] <retal> ok, in 30 min i let you kbow
[19:34:23 CET] <faLUCE> (solved: I set avrame->pict_type)
[19:36:41 CET] <faLUCE> (now I wonder if is there anything similar for an audio frame)
[20:15:14 CET] <kepstin> audio codecs don't have any concept like keyframes
[20:16:08 CET] <kepstin> you can generally start decoding audio at any frame, although depending on the codec and decoder you may have to discard the first N decoded samples before you get something useful.
[20:20:01 CET] <faLUCE> kepstin: this is why I don't get errors when the decoder picks unuseful frames before useful ones ;-)
[20:20:20 CET] <brejeiro> Hello, is it possible to change the mouse cursor image that goes to the video, when recording the desktop?
[20:52:49 CET] <xxxmaker> x265 1.9:[Windows][GCC 4.9.0][64 bit] 8bit
[20:52:49 CET] <xxxmaker> Encoding settings              : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=3 / merange=57 / rect / amp / max-merge=3 / temporal-mvp / no-early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=300
[20:52:49 CET] <xxxmaker> / min-keyint=30 / scenecut=40 / rc-lookahead=30 / lookahead-slices=4 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=6 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0
[20:52:49 CET] <xxxmaker> / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30
[20:52:49 CET] <xxxmaker> Default                        : Yes
[21:02:24 CET] <kepstin> brejeiro: it's supposed to be using the system cursor image, so in theory you could do that by changing the system cursor them. What OS and capture device are you using?
[22:27:43 CET] <retal> faLUCE, a am ready. I have new ffmpeg src's just pulled, x264
[22:27:53 CET] <retal> what shuld i do now ? :)
[00:00:00 CET] --- Tue Mar 19 2019