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

Thu Jul 13 03:05:01 EEST 2017

[00:13:52 CEST] <OldBrick> kepstin: Thanks for the suggestions. I also replaced the variables with constants for now.  Result is the same, it runs fine from command line, but not when run with systemd-run timer.  Oddly, I had to move the -t time option to the output side.
[00:14:41 CEST] <OldBrick> kepstin: the command now is ffmpeg -probesize 10M -analyzeduration 20M -c:v mpeg2video -i udp://@:5000?timeout=1500000 -t 00:01:00 -c:v copy -c:a copy  /home/av/bobdisk/rec1test.m pg &
[01:48:57 CEST] <rajkosto> hello i am using C api how do i demux h264 raw elementary stream
[01:49:12 CEST] <rajkosto> i need to group NALs by what frame they belong to
[08:56:57 CEST] <kimmer> Hi all. I would like to capture a livestream on youtube, but i cant figure out how ;) I'm on a windows mashine, and I have the ffmpeg and the youtube-dl, but I can seem to figure out how ffmpeg works this is the stream that i would like to grab. https://www.youtube.com/watch?v=Y0Ng2odBiio or
[08:58:59 CEST] <kimmer> I tried to use a shortner for the link, but does the link change if there is a courruption in the stream? Its a bicycle team that goes from northern Europe to Paris in their aid to support childdren with cancer - I have a family member riding and it came to me that it could be nice to have a record of the stream
[09:21:54 CEST] <kazuma_> kimmer https://trac.ffmpeg.org/wiki/Capture/Desktop
[09:22:11 CEST] <kazuma_> but you would be better off waiting for the stream to finnishe and just download it
[09:22:27 CEST] <kazuma_> there are also gui tools like obs than make screen capture easy
[09:24:40 CEST] <kerio> is there a facility in the ffmpeg cli to start/stop recording based on a signal of some sorts?
[09:24:52 CEST] <kerio> maybe a literal signal
[09:25:18 CEST] <kazuma_> end of stream or input file = it ends
[09:25:30 CEST] <kazuma_> you can do ctrl + c to force quit it
[09:25:42 CEST] <kazuma_> also
[09:25:47 CEST] <kerio> what about starting tho
[09:25:58 CEST] <kazuma_> you can hit the pause button on your keyboard to pause whatever it's prosessing
[09:26:05 CEST] <kazuma_> and hit return/enter to resume
[09:26:29 CEST] <kerio> this is for recording from a couple of webcams tho
[09:28:09 CEST] <furq> iirc sigstop and sigcont works
[09:28:18 CEST] <furq> although if it's a network source it might just end up timing out if you do that
[09:31:24 CEST] <kimmer> kazuma_ I know of the screen capture tools outthere, but - I cant find the recorded streams on the channel, and thats why i wanted to capture it live.... I'' fool around with it, and get the program to learn :) Indeed a nice tool yu have created.
[09:32:39 CEST] <furq> kimmer: what's wrong with just youtube-dl
[09:33:04 CEST] <furq> also afaik youtube should give the channel owner the option to archive the stream once they're done broadcasting
[09:33:29 CEST] <furq> i think it happens by default
[09:34:17 CEST] <kimmer> it gave me an error that ffmpeg wasent installed or something, and then I just wanted to grab the stream with ffmpeg...
[09:36:24 CEST] <kimmer> furq Well. Thise people have been cycleing for the past 5 days, and only sporatic streams are on youtube.. they are going down throu germany and France to Paris, but I guess that if they hit an aerea with no signal, the stream will stop, and the recording will stop aswell, and when signal reapear, the stream will pickup again.
[09:36:39 CEST] <kerio> no this is v4l2
[09:37:01 CEST] <furq> you probably just want to figure out why youtube-dl can't find ffmpeg
[09:37:21 CEST] <kerio> in a situations where the framerates are not stable but the timestamps do matter D:
[09:37:27 CEST] <kerio> *situation
[09:38:06 CEST] <kimmer> when I add up the hours they have been on the cycle, the hours dont add up, not even a 1/3'rd are on the channels archive....... I'll do that furq - I'll figure out why it dident picked up ffmpeg.. I'm currently on a windows mashine, is that an issue?
[09:38:22 CEST] <furq> shouldn't be
[09:38:57 CEST] <kimmer> mkai. thanks, I'll have a go with it - have a nice day
[09:45:14 CEST] <kimmer> ah, ofcourse - ffmpeg needs to be in the same directory as the youtube-dl . I git it to work now - tkankyou fellas, much apreciated
[11:41:43 CEST] <kerio> yo real quick
[11:41:54 CEST] <kerio> can i stream ffvhuff in mpegts
[11:46:02 CEST] <JEEB> kerio: no, but I bet you can do it in NUT or something else you can stream
[11:46:28 CEST] <JEEB> (NUT is what some people use between ffmpeg and ffmpeg to stream data with A+V)
[11:46:36 CEST] <JEEB> (usually raw audio/video)
[12:19:17 CEST] <VP9-in-MP4> Just some quick Feedback, I'm not staying for a response: I was trying to merge a video-only file & an audio-only file & I got this error msg...
[12:19:42 CEST] <VP9-in-MP4> [mp4 @ 0000000002621400] VP9 in MP4 support is experimental, add '-strict -2' if you want to use it.
[12:19:57 CEST] <VP9-in-MP4> Could not write header for output file #0 (incorrect codec parameters ?): Experimental feature
[12:20:29 CEST] <VP9-in-MP4> ...I tried the "-strict -2" thing, but the file didn't play in VLC, it had the fourcc of vp09 instead of vp90, then I tried to force the fourcc & that didn't help either (not change), then I found that going back to the origianl command (no "-strict -2" & no "-vtag") & simply changing the output file extention to .webm made the command/conversion work without problems.
[12:20:45 CEST] <VP9-in-MP4> I'd like to suggest this error msg suggest that: change the file extension to webm (or any other extension that supports vp9 video, something like: VP9 in MP4 support is experimental, add '-strict -2' if you want to use it...did you mean to use the .webm extension instead?
[12:55:20 CEST] <VP9-in-MP4> dang, this channel is dead, only people joining & leaving...at least I got responses to my report in #ffmpeg-devel
[12:56:43 CEST] <JEEB> VP9-in-MP4: people are not always at the keyboard :)
[12:57:33 CEST] <VP9-in-MP4> yes, I understand, but still only joins/leaves in this channel since I got here...I understand people aren't always here to respond...
[12:57:47 CEST] <JEEB> well you had only been for ~30min so not even long tbqh
[12:58:13 CEST] <JEEB> also yea, we generally expect people to understand what they want as the command line parameters are what you want
[12:58:19 CEST] <squ> you want vp9 in mp4?
[12:58:23 CEST] <VP9-in-MP4> 30 mins is about as long as I ever stay in IRC...I was only here to report that error msg I got...
[12:58:38 CEST] <JEEB> and yea, depending on your FFmpeg version the VP9 in mp4 muxing is either out of date or not
[12:58:45 CEST] <JEEB> I think it might have become non-experimental lately
[12:59:22 CEST] <VP9-in-MP4> squ: no, that's the error msg I got, I already solved the problem by just using the output file extension .webm -- I wasn't /trying/ to do vp9 in mp4, it's just what ffmpeg thought I wanted by me specifying .mp4 as the output file extension
[12:59:42 CEST] <squ> so, no problem
[12:59:45 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=5ff31babfccd16cdee6575ae015ff67e9a08e35d
[13:00:03 CEST] <JEEB> VP9-in-MP4: well you told FFmpeg you wanted mp4 :D
[13:00:15 CEST] <JEEB> so it told you "hold up a moment that's experimental"
[13:00:23 CEST] <JEEB> I do agree that the message should at least have the human-readable value
[13:00:25 CEST] <JEEB> instead of -2
[13:00:37 CEST] <JEEB> "-strict experimental" is the human-readable option
[13:00:54 CEST] <VP9-in-MP4> JEEB: yes, I told it I wanted mp4, only cuz that's the default file extension I type, I had no idea my input file was vp9 & I had no idea that vp9 in mp4 was non-standard...
[13:01:14 CEST] <JEEB> well it is standard now so you would have not gotten the error in the latest version
[13:01:17 CEST] <JEEB> see the commit I linked
[13:01:21 CEST] <squ> VP9 in MP4 support is quite readable
[13:02:03 CEST] <VP9-in-MP4> that's why I'm suggesting that that error msg should say something like this: VP9 in MP4 support is experimental, add '-strict -2' if you want to use it...did you mean to use the .webm extension instead?
[13:02:06 CEST] <squ> who invents such standards, vp9 not going to play on apple devices anyway
[13:02:28 CEST] <JEEB> you can specify mappings and register them at the mpeg-4 ra
[13:02:44 CEST] <JEEB> and at least netflix and a few other places have already started testing it
[13:02:56 CEST] <JEEB> because CENC is defined for ISOBMFF (aka "mp4"
[13:03:21 CEST] <squ> how netflix videos are received?
[13:03:24 CEST] <JEEB> VP9-in-MP4: but that is not what you might want. we put more trust in the user actually requesting what he thinks he needs
[13:03:32 CEST] <JEEB> squ: MPEG-DASH over the interwebs
[13:03:37 CEST] <JEEB> which is ISOBMFF fragments
[13:03:42 CEST] <squ> so, chrome?
[13:03:46 CEST] <JEEB> or firefox
[13:03:52 CEST] <JEEB> or mobile clients
[13:03:58 CEST] <squ> android & chrome
[13:04:06 CEST] <squ> nice standard :)
[13:04:17 CEST] <JEEB> well, at least it's a standard
[13:04:22 CEST] <JEEB> guess what is isn't
[13:04:23 CEST] <VP9-in-MP4> but what if the user isn't a video expert & doesn't know what the need? all I needed was "these 2 files merged", I did specify -c copy, cuz I didn't want transcoding, but I had no idea which file extension was best for my inputs
[13:04:24 CEST] <JEEB> *isn't
[13:04:38 CEST] <JEEB> VP9-in-MP4: then you learn, young grasshopper
[13:04:44 CEST] <VP9-in-MP4> yes, I did learn
[13:04:47 CEST] <squ> how is that a standard if it is all Google
[13:05:03 CEST] <JEEB> uhh
[13:05:11 CEST] <JEEB> mozilla also wanted VP9 in ISOBMFF
[13:05:29 CEST] <JEEB> I'm at work so I can't do the full research on who did work on it
[13:05:32 CEST] <squ> why? and what is isobmff
[13:05:38 CEST] <VP9-in-MP4> but that error msg suggesting -strict -2 sent me down the wrong path: it was suggesting I force an experimental thing, instead of simply using webm which is fully supported
[13:05:44 CEST] <JEEB> ISOBMFF is the official name for what you usually call mp4
[13:05:55 CEST] <squ> JEEB: sorry to disturb, I was just in kind of a shock to about vp9 in mp4
[13:06:07 CEST] <JEEB> ISO Base Media File Format
[13:06:07 CEST] <ritsuka> ISOBMFF is mp4 without the useless features no one uses anyway
[13:06:27 CEST] <JEEB> well it's the latest version of the spec since it has moved in the range
[13:06:37 CEST] <JEEB> I think it was part 1 at first, now part 12 (and 15 for AVC/HEVC mappings)
[13:07:06 CEST] <JEEB> squ: and it's squarely because a lot of other things aren't specified in Matroska. Including Matroska itself. that's a WIP thing done under the EU
[13:07:17 CEST] <JEEB> after Matroska becomes specified then WebM can also be specified
[13:07:19 CEST] <JEEB> as a spec
[13:07:35 CEST] <VP9-in-MP4> all these codecs & containers give me a headache...all I know is: VLC can play it...VLC can play any format. I think everyone should just design/pick the best audio & video codec/format/container & all use it
[13:08:00 CEST] <JEEB> also VLC at this point is old
[13:08:08 CEST] <JEEB> I mean the latest release of it
[13:08:16 CEST] <VP9-in-MP4> it's old? what's new then? ohh
[13:08:20 CEST] <squ> VP9-in-MP4: it turns out VLC with Google invent the standards
[13:08:25 CEST] <VP9-in-MP4> yeah VLC releases are kinda slow
[13:08:37 CEST] <JEEB> I've mostly used master for the past few years
[13:08:43 CEST] <JEEB> done my own builds if I needed it
[13:09:00 CEST] <JEEB> so a lot of the newer stuff just won't be in the stable releases of VLC until 3.0 is out
[13:09:13 CEST] <JEEB> (which has been "soon (TM)" for the past two VDDs at least ;))
[13:09:16 CEST] <squ> how had vp9 passed into mp4 I don't get it
[13:09:26 CEST] <VP9-in-MP4> oh u use master branch of VLC? (or ffmpeg?)
[13:09:29 CEST] <JEEB> both
[13:10:02 CEST] <JEEB> for FFmpeg you can use fate.ffmpeg.org as a monitor if the current master is OK to update to
[13:10:14 CEST] <JEEB> windows/linux, or ARM/MIPS/x86_64
[13:10:19 CEST] <squ> google says we want vp9 in mp4 (don't ask why?), okey let's make it standard lol
[13:10:20 CEST] <JEEB> a lot of stuff gets tested
[13:10:40 CEST] <VP9-in-MP4> I don't compile any of my own software, setting up that kind of build env is too much of a hassle...(don't get me wrong, I'm not a computer noob, but I just don't "compile" things)
[13:10:58 CEST] <JEEB> squ: I dunno why you're so against it. multiple vendors including el GOOG want it. and it's properly specified. what's not to like
[13:11:04 CEST] <JEEB> same as DTS specifies DTS in ISOBMFF
[13:11:09 CEST] <JEEB> or Dolby with its formats
[13:11:40 CEST] <JEEB> http://mp4ra.org/
[13:11:44 CEST] <squ> I thought vp9 will be dead when hevc is out and have decoder/encoder implemented in hardware
[13:12:07 CEST] <JEEB> well VP9 came out after HEVC and HEVC's main issues are in licensing
[13:12:17 CEST] <JEEB> it got real fucked by corps
[13:12:36 CEST] <squ> hevc goes into various hardware now
[13:12:41 CEST] <JEEB> so does VP9
[13:12:46 CEST] <squ> not sure about that
[13:12:48 CEST] <JEEB> my TV can do 10bit VP9 :P
[13:12:55 CEST] <squ> I see
[13:13:16 CEST] <JEEB> so due to the licensing shenanigans VP9, and then AV1 which was based on the VP10 with other groups joining, are getting traction
[13:13:21 CEST] <ritsuka> my 30¬ dvb-t decoder can decode hevc
[13:13:41 CEST] <ritsuka> it seems hevc is already everywhere
[13:13:52 CEST] <JEEB> it's used, yes. but people are actively looking at alternatives
[13:14:13 CEST] <JEEB> also it's generally not used for its gains as far as I can see :/ other than 10bit decoding being a thing that most HW decoders support
[13:14:17 CEST] <squ> ritsuka: yep, and one day, surprise, vp9 in mp4 becomes standard (by Google) no one to argue agaisnt that?
[13:14:37 CEST] <JEEB> (´4@)
[13:14:39 CEST] <ritsuka> it's "standard" as in "there is a specification for it"
[13:14:49 CEST] <JEEB> yes, and it's registered on mp4reg
[13:14:53 CEST] <JEEB> http://mp4ra.org/
[13:14:57 CEST] <ritsuka> so you won't have two different companies making two different ways to store it in mp4
[13:15:10 CEST] <JEEB> until it's on mp4ra your just hacking around, basically
[13:15:34 CEST] <JEEB> anyways, I've wasted enough time here :P
[13:19:27 CEST] <VP9-in-MP4> ya know what I just thought of?...in addition to the -c copy option, ffmpeg needs some option like --copy or --preserve-all, so it would read the input & preserve the codecs AND container from the input, even if you specify the wrong output file extension. It already KNOWS the input codec AND container, so it already knows what to suggest (or use) for output, if you could tell it --preserve-all
[13:22:03 CEST] <adhawkins> kepstin: Sorry, only just seen this. I didn't think I was trying to use more than one output?
[14:06:30 CEST] <Fig1024> when using FFMPEG C++ API, encoded data is moved using AVPacket, how are they allocated? is there an internal memory pool or is it all dynamically allocated on the heap?
[16:30:15 CEST] <danieeel> how to avoid the delay after printing the setup? i want to do some benchmarks and this ruins it
[16:36:04 CEST] <kepstin> adhawkins: the command you gave in the paste had multiple output filenames in the command...
[16:37:15 CEST] <kepstin> danieeel: what delay exactly are you referring to? ffmpeg should be going as fast as it can normally...
[16:37:43 CEST] <danieeel> it shows the pipeline setup for a sec, then it starts the coding
[16:38:31 CEST] <danieeel> or can i have a print of small statistics (fps) after each frame?
[16:38:43 CEST] <kepstin> danieeel: it starts encoding immediately, maybe just the status line isn't shown immediately?
[16:39:08 CEST] <kepstin> danieeel: note that current ffmpeg builds when using x264 behave a bit strangely, because x264 buffers a large number of frames internally
[16:39:24 CEST] <danieeel> i am doing v210 to prores  (on x86 and arm)
[16:42:01 CEST] <kepstin> maybe pastebin your ffmpeg output with a marker where you're seeing this "delay" so I can give more accurate feedback?
[16:42:31 CEST] <Asuran> guys, how can i list all options x265 does have supported in ffmpeg?
[16:42:44 CEST] <Asuran> even with -x265-params i cant set profile for example
[16:44:31 CEST] <kepstin> Asuran: you can use most of the options from https://x265.readthedocs.io/en/default/cli.html in the -x265-params (aside from some which are specific to the x265 cli, stull like input/output file options)
[16:45:13 CEST] <Asuran> profile wont be recognized
[16:45:30 CEST] <Asuran> psy-rd etc. does being recognized
[16:46:32 CEST] <Asuran> kepstin, it an one liner: ffmpeg -i %1 -c:v libx265 -preset:v slow -crf 19 -x265-params profile=main10 -c:a libopus -b:a 96k -vbr on -packet_loss 0 -compression_level 10 -application audio "%~n1".mkv
[16:46:38 CEST] <kepstin> Asuran: ok, if you look at https://x265.readthedocs.io/en/default/cli.html#profile-level-tier you'll see that the --profile option is listed as "CLI ONLY", which means it cannot be used in the options string.
[16:46:48 CEST] <Asuran> thanks kepstin
[16:47:03 CEST] <Asuran> so it means i need to get x265 standalone?
[16:47:08 CEST] <kepstin> Asuran: I think you can use the "-profile" ffmpeg option to set it, let me confirm
[16:47:23 CEST] <Asuran> not supported in trac wiki mentioned
[16:47:50 CEST] <kepstin> yeah, looks like it's not implemented. patch welcome, I guess? :/
[16:47:58 CEST] <furq> i wouldn't necessarily trust the wiki
[16:48:03 CEST] <furq> but it's not in -h encoder=libx265
[16:49:04 CEST] <kepstin> looks like it wouldn't be that hard to add, tbh., just a new string avoption and some code to call x265_param_apply_profile() at the end of setup, handle errors.
[16:55:48 CEST] <danieeel> kepstin: https://pastebin.com/1ppCEuzb
[16:56:21 CEST] <danieeel> the :33 is when i run the command but that progresses to :34 when encoding starts
[16:59:05 CEST] <kepstin> danieeel: looks like that's a slow spot when it's trying to probe the format of the input file. What's the command you're running? You might be able to speed it up by manually giving input file format options.
[16:59:52 CEST] <kepstin> weird that it's using image2 for what appears to be a raw video file
[17:00:01 CEST] <danieeel> kepstin: ffmpeg -benchmark -framerate 1 -s 4096x2160 -r 60 -vcodec v210 -i /dev/shm/yuv422.raw -color_primaries bt709 -color_trc bt709 -colorspace bt709 -c:v prores -profile:v 2 /dev/shm/prores.mov
[17:00:55 CEST] <danieeel> there is no v210 pixel format.. (which i used for 8bit yuv422 with rawvideo)
[17:02:45 CEST] <kepstin> danieeel: but there is a dedicated v210 demuxer, give "ffmpeg -benchmark -video_size 4096x2160 -framerate 60 -f v210 -i inputfile.raw ..." a try
[17:06:02 CEST] <danieeel> Unknown input format: 'v210'
[17:06:18 CEST] <kepstin> oh, ffmpeg 2.8 lol
[17:06:22 CEST] <kepstin> get a newer ffmpeg?
[17:07:16 CEST] <danieeel> i can have a look into that... better from sources, right?
[17:08:10 CEST] <kepstin> danieeel: for a quick test, grabbing the static binaries from the download page should be fine
[17:13:53 CEST] <danieeel> this is nvidia x2 box with ubuntu..  i am a gentoo guy so i have no clue how to get the binaries here, lol :) will do with sources
[17:14:12 CEST] <adhawkins> kepstin: Not that I can see...or am I missing something?
[17:14:28 CEST] <adhawkins> The only '-f' is right at the end.
[17:15:01 CEST] <adhawkins> converter.exe -y -threads 8 -i bbb_sunflower_2160p_30fps_normal.mp4 -crf 1 -maxrate 10000k -bufsize 20000k -vcodec libx264 -pix_fmt yuv420p -me_method hex -vf "fps=24" -fpre "presets\\cabletime.ffpreset" -acodec ac3 -ac 2 -ar 48000 -ab 160k -shortest -f mpegts -metadata "service_provider=Cabletime V2.0" bbb30-24.m2t-shortest -f mpegts bbb30-24.m2t -report
[17:15:03 CEST] <kepstin> adhawkins: your paste has expired so i can't reference it now...
[17:15:10 CEST] <kepstin> but you have two output filenames there
[17:15:13 CEST] <adhawkins> Ah, there is a '-f mpegts' with no filename in the middle...
[17:15:20 CEST] <adhawkins> Just pasted in the command.
[17:15:22 CEST] <kepstin> "bbb30-24.m2t-shortest"  and "bbb30-24.m2t"
[17:15:41 CEST] <adhawkins> Ok, wasn't aware of that...let me double check.
[17:16:04 CEST] <kepstin> adhawkins: it looks like a copy/paste error, tbh
[17:16:25 CEST] <adhawkins> That command line is actually being generated by some code, so that code is probably at fault.
[17:17:31 CEST] <adhawkins> Ah yes, copy and paste issue in the code. Let me try it again and see if it works without that duplication.
[17:18:37 CEST] <adhawkins> Is there somewhere I can do a paste that won't expire?
[17:19:54 CEST] <adhawkins> Will use gist.
[17:19:59 CEST] <adhawkins> Ok, just tried again. Result here:
[17:20:00 CEST] <adhawkins> https://gist.github.com/adhawkins/1cda47731a78133d664c209ef4b27e6a
[17:20:09 CEST] <adhawkins> Basically the same issue. Good spot though kepstin, thanks.
[17:20:10 CEST] <kerio> do you guys know if mpv can crop to an exact height
[17:20:11 CEST] <kerio> or something
[17:20:54 CEST] <kepstin> kerio: are you trying to crop a video with subsampled chroma to an odd height (or at an odd offset)? that's not gonna work...
[17:21:03 CEST] <adhawkins> The error on the console is '[error]: malloc of size 52486144 failed'
[17:21:06 CEST] <kerio> no i have a v4l2 device that outputs 640x512
[17:21:09 CEST] <kerio> and i want to show 640x480
[17:23:09 CEST] <kepstin> adhawkins: you aren't using a 32bit ffmpeg or something silly like that?
[17:23:31 CEST] <kepstin> adhawkins: x264 *eats* ram, particularly at 4k, so you really need a 64bit ffmpeg
[17:23:48 CEST] <adhawkins> Ah, I *am* using 32 bit...
[17:23:57 CEST] <adhawkins> Let me try with a 64 bit version.
[17:24:59 CEST] <adhawkins> kepstin: Genius, 64 bit version has got further at least. Thanks *so* much for the help, I'd never have thought of that.
[17:25:10 CEST] <adhawkins> Given how small the allocation was that was failing, I assumed it was something else.
[17:25:36 CEST] <kepstin> well, when most of the meory space is full, even a small allocation can fail
[17:26:02 CEST] <adhawkins> Yep, but given that the error was occurring right at the start of the process, I didn't really connect the two.
[17:28:19 CEST] <kepstin> kerio: mpv can do that, yeah. as for how - this really isn't the place? iirc it's documented in the man page...
[17:28:23 CEST] <kerio> ok apparently i need a panscan of 3/19
[17:28:24 CEST] <kerio> :|
[17:28:56 CEST] <kepstin> kerio: just use the crop filter
[17:29:11 CEST] <kepstin> syntax is almost the same as ffmpeg's
[17:30:59 CEST] <furq> you know mpv has an irc channel, right
[17:31:08 CEST] <furq> not a very good one, but still
[17:31:36 CEST] <danieeel> kepstin: it works now!
[17:31:37 CEST] <kerio> i love you as well furq <3
[17:36:22 CEST] <danieeel> kepstin: the multithreading is done on a frame to frame basis, or will we see benefit when encoding just 1 frame?
[17:40:38 CEST] <kepstin> danieeel: I don't know about how prores multithreading works, sorry.
[17:41:33 CEST] <adhawkins> kepstin: Yep, successfully converted. Thanks so much for your help.
[17:41:44 CEST] <danieeel> so it is not on system level, but each codec implements it in own way?
[17:43:15 CEST] <kepstin> danieeel: yeah, since there's so much variation in how the codecs actually work, the multithreading has to be implemented mostly in the codec itself. Some of the internal codecs use a slice or frame threading framework that ffmpeg provides, external ones like x264 implement threading completely on their own.
[17:48:59 CEST] <solrize> git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg
[17:49:02 CEST] <solrize> ->
[17:49:03 CEST] <solrize> fatal: unable to access 'https://git.ffmpeg.org/ffmpeg.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
[17:49:15 CEST] <solrize> hmm, this is with a just-installed debian 9 system
[17:50:29 CEST] <solrize> oh lol, it's a startcom certificate
[17:50:33 CEST] <solrize> please fix that, guys!!!
[18:03:36 CEST] <iive> solrize: my browser says ssl is verified by Gandi
[18:04:50 CEST] <solrize> Certificate chain
[18:04:50 CEST] <solrize>  0 s:/C=SE/ST=Skane/L=Lund/O=Reimar D\xC3\xB6ffinger/CN=ffmpeg.org
[18:04:50 CEST] <solrize>    i:/C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Class 2 IV Server CA
[18:05:06 CEST] <solrize> that's from openssl s_client -showcerts -connect git.ffmpeg.org:443
[18:05:12 CEST] <furq> yeah it's startcom
[18:05:17 CEST] <furq> this has been reported before
[18:05:26 CEST] <furq> the excuse then was that certs from before october 21st were still trusted
[18:05:30 CEST] <solrize> also get that on https://git.ffmpeg.org/
[18:05:36 CEST] <BtbN> Use git.videolan.org
[18:05:37 CEST] <furq> but google and mozilla are blacklisting those soon
[18:05:47 CEST] <solrize> google already did
[18:05:54 CEST] <BtbN> works fine in Chrome for me.
[18:06:06 CEST] <furq> they're being blacklisted in chrome 61
[18:06:11 CEST] <furq> unless that's already out
[18:06:13 CEST] <solrize> ic
[18:06:17 CEST] <iive> i do get different cert from git.ffmpeg and git.videolan
[18:06:21 CEST] <BtbN> 59 is stable
[18:06:27 CEST] <iive> i thought that the first is redirect to the latter
[18:06:30 CEST] <furq> https://threatpost.com/google-to-fully-distrust-wosignstartcom-ssl-certs-in-chrome-61/126729/
[18:06:33 CEST] <solrize> i think you're right, it was announced but isn't out yet.  what's videolan?
[18:06:49 CEST] <iive> vlc website
[18:07:05 CEST] <furq> http://git.videolan.org/?p=ffmpeg.git;a=summary
[18:07:11 CEST] <furq> or you could just use the github mirror
[18:07:18 CEST] <solrize> ok thanks
[19:35:54 CEST] <Asuran> by any chance, is there maybe some kind of preset db for x265/x264
[19:43:15 CEST] <kepstin> Asuran: what do you mean? both of those codecs have built-in presets, you should pretty much just use the slowest preset that's fast enough for your use case.
[19:43:37 CEST] <Asuran> x265 no still no look doc it seems like they didnt done some really
[19:43:47 CEST] <Asuran> i heard x264 had film for example
[19:45:08 CEST] <c_14> you mean tunes?
[19:46:01 CEST] <kepstin> yeah, that's documented https://x265.readthedocs.io/en/default/presets.html for x265, and probably best to see the x264 cli --help (or --fullhelp) output for that encoder.
[19:50:21 CEST] <Asuran> i doubt this works well its different much inside i believe
[19:50:24 CEST] <Asuran> anyways thanks
[20:19:16 CEST] <Asuran> c_14, kepstin is it maybe possible to force x265 show in output which commands (all) where passed?
[20:28:22 CEST] <DHE> Asuran: it doesn't quite work that way with the API. Though you may be able to find the saved encoder parameters in the output file. "strings filename.mp4 | grep x265" might turn something up for example
[20:33:07 CEST] <leif> Does anyone know how the command line `ffmpeg` tool is able to jump to the correct packet when encoding? Looking at `ffmpeg.c` the only av_seek_frame I see is for looping streams.
[20:33:42 CEST] <kepstin> Asuran: i seem to recall that x265 does include a pretty detailed list of all the parameters its using in the log. doesn't map directly to the command line options, but still.
[20:34:11 CEST] <leif> I ask because it looks like it just calls av_read_frame repeatedly, but when I run it with, say the `trim` filter, it is able to seek to the correct frame pretty quickly.
[20:34:32 CEST] <kepstin> leif: ffmpeg.c (by default) seeks to the nearest seekpoint prior to the desired time, then demuxes+decodes, discarding the result, until it reaches the exact time wanted.
[20:34:42 CEST] <leif> (Faster than I would assume it would take to just call av_read_frame, add it to the filtergraph, and repeat.
[20:34:46 CEST] <kepstin> if you use the -ss input option
[20:35:19 CEST] <kepstin> if you use the trim filter, then it just decodes from the start, and the trim filter discards frames...
[20:35:32 CEST] <leif> kepstin: I see.
[20:36:10 CEST] <leif> kepstin: thanks. That's what the code looked like. But I was amazed that the command:
[20:36:41 CEST] <leif> `ffmpeg -i demo.mp4 -filter_complex '[0:v]trim=start=50=end=60[fv]' -map '[fv]' out.mp4
[20:37:09 CEST] <leif> appeared to 'jump' to the point where it could write out quickly.
[20:37:20 CEST] <leif> Anyway, thanks.
[20:37:26 CEST] <kepstin> only trimming 50 seconds off the start? Yeah, decoding 50s worth of frames and discarding them would barely be noticable
[20:37:36 CEST] <kepstin> on a modern desktop pc anyways
[20:37:40 CEST] <nicolas17> encoding is the slow thing :)
[20:38:17 CEST] <leif> kepstin: Ah, okay, that makes sense.
[20:38:36 CEST] <leif> Which probably means I'm doing something wrong with my code. Thanks. :)
[20:39:08 CEST] <leif> (Namely, it takes much longer to get to the point where it does the encoding, but once it gets there it goes just about as fast.)
[20:39:31 CEST] <kepstin> leif: but yeah, "ffmpeg -ss 50 -i demo.mp4 -t 10 -map 0:v out.mp4" would be faster in general, since it will seek into the file and start decoding from there.
[20:40:02 CEST] <kepstin> it'll be noticable once you start grabbing chunks a couple hours into a long video :)
[20:40:09 CEST] <leif> kepstin: Yup, that absolutely makes sense.
[20:40:40 CEST] <leif> (Unfortunately, doing the equivalent of -ss wouldn't work in my case, as I am trying to make a preview feature for my video editor.)
[20:40:57 CEST] <leif> err...language/editor hybrid...thing...
[20:41:31 CEST] <leif> But ya, thanks. That helps a lot. :D
[20:41:49 CEST] <kepstin> why not? there shouldn't be any problem seeking all over a video file while it's open in an editor. It's basically necessary for an NLE to be reasonably efficient
[20:42:53 CEST] <leif> In principle ya, although I am currently compiling down to the filtergraph, and I would like to be able to seek to that output.
[20:43:46 CEST] <leif> Right now, I have the horrible solution of rendering a low-res output from the filtergraph, and seeking with that. But I will probably need to abandon the filtergraph.
[20:43:49 CEST] <kepstin> yeah, you can't seek in the output of a filter graph, but if you know enough and it doesn't have any stateful filters, you can seek the files :/
[20:43:57 CEST] <kepstin> seek the input files
[20:44:42 CEST] <leif> That is very true.
[20:45:06 CEST] <leif> By just taking the inverse (so to speak) of the filtergraph....that's a good idea.
[20:45:23 CEST] <leif> And I think I can do that. (I am not using any stateful filters at the moment.)
[20:45:49 CEST] <lindylex> How can I overlay two videos and keep the audio from both playing?  ffmpeg -i m.mov -i o.mp4 -filter_complex "overlay=x=40:y=40:eof_action=pass" -y my.mov
[20:47:35 CEST] <relaxed> -map 0 -map 1 -map -1:a would omit o.mp4's audio
[20:48:17 CEST] <relaxed> I guess only -map -1:a would work
[20:48:35 CEST] <lindylex> How do I keep both videos audio?  I would like to not omit.
[20:49:01 CEST] <kepstin> lindylex: you'd have to use an audio filter to mix the audio from both videos together
[20:49:35 CEST] <relaxed> oh, I misunderstood :/
[20:49:47 CEST] <lindylex> What does that look like?  The process I am not aware.
[20:50:54 CEST] <kepstin> lindylex: -filter_complex '[0:v][1:v]overlay=x=40:y=40:eof_action=pass; [0:a][1:a]amix'
[20:50:55 CEST] <lindylex> I have two videos.  I will overlay o.mp4 on top of m.mov.  I would like the audio for both to play.  I can do the overlay but only the audio from m.mov plays.
[20:50:55 CEST] <kepstin> should do it
[20:51:09 CEST] <lindylex> Ok thanks let me try.
[20:52:30 CEST] <lindylex> Thanks it worked perfectly.
[20:58:13 CEST] <lindylex> kepstin: [0:v] means the first video that is m.mov in my command?  :::  >>>  ffmpeg -i m.mov -i o.mp4 -filter_complex "[0:v][1:v]overlay=x=40:y=40:eof_action=pass; [0:a][1:a]amix" -c:v libx264 -preset slow -crf 0 -preset ultrafast -an -y my.mov
[20:59:07 CEST] <lindylex> kepstin:  [0:a] means the audio from video m.mov.  Is this correct?
[20:59:14 CEST] <kepstin> lindylex: yes, the first number is the file index, and the part after the : is the stream selector; here 'v' and 'a' mean "default video" and "default audio", but you can use stream numbers instead.
[21:00:11 CEST] <lindylex> I think I am begging to understand what this means.  One sec I will read about the amix in the docs.
[21:05:36 CEST] <lindylex> kepstin interesting if I had three video overlayed and wanted to hear all three audio I would have to specify inputs=3  And it might look like this?  -filter_complex '[0:v][1:v]overlay=x=40:y=40:eof_action=pass; [0:a][1:a][2:a]amix=inputs=3'
[21:07:02 CEST] <kepstin> lindylex: well, you'd have to use another overlay filter to add the video on top, but that's what the amix would look like yes
[21:07:55 CEST] <lindylex> Thanks for explaining.  I have a better comprehension now.
[22:20:59 CEST] <Purebe> Hello, it seems that it's possible to generate a url in libavformat, is it possible to convert something like this command into a libavformat scheme url? "ffplay -f dshow -video_size 1280x720 -pixel_format uyvy422 -rtbufsize 702000 -framerate 59.94 -i video="Decklink Video Capture""
[22:21:14 CEST] <Purebe> (I may have some fundamental misunderstandings here, but trying to figure it out, any advice would be appreciated)
[22:27:21 CEST] <Purebe> Maybe a better question to ask would be if "dshow" is a lbavformat scheme/protocol, or if it falls under a different scheme/protocol?
[22:28:38 CEST] <durandal_1707> no no and no
[22:29:56 CEST] <Purebe> Ok, thanks, at least I know that is a deadend now
[22:31:25 CEST] <Purebe> Is dshow a libavdevice?  Or how would you check to see if it is?
[22:32:14 CEST] <JEEB> ffmpeg -devices
[22:32:15 CEST] <JEEB> IIRC?
[22:32:38 CEST] <Purebe> Ah, that makes sense
[23:43:14 CEST] <Threads> is it possible to turn the first few frames into B frames ?
[23:43:18 CEST] <Threads> if so how
[23:45:49 CEST] <BtbN> no
[23:46:13 CEST] <BtbN> always starts at an I frame
[23:59:32 CEST] <kepstin> well, in theory the first few frames in pts order could be encoded in b frames in e.g. h264, i think? (obviously the first frame in dts order will still be an i frame)
[00:00:00 CEST] --- Thu Jul 13 2017