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

[burek]

[00:01:32 CEST] <nerium> relaxed: I tried this with the latest https://gist.github.com/oleander/94881304756dbe1ca413 but it didint work
[00:02:17 CEST] <StephenS> uhm how can I make timelapse, but from video?So actually to simulate that I have photos/frames..?
[00:03:17 CEST] <RedH8> Dump the frames to png
[00:03:45 CEST] <BtbN> You mean speed up a very long video?
[00:03:54 CEST] <RedH8> You can set a start and stop position and just dump sections if you want
[00:03:55 CEST] <BtbN> So you get a 5 minute video from a 24h recording?
[00:04:06 CEST] <RedH8> Oh my bad
[00:04:19 CEST] <StephenS> well not really
[00:04:25 CEST] <StephenS> but to get timelapse from 10-20s long video
[00:04:40 CEST] <BtbN> I'm not sure what you mean by timelapse then.
[00:04:41 CEST] <StephenS> I saw speed/slow down video thing on ffmpeg, but thats not what I actually want
[00:05:05 CEST] <RedH8> Do you want to create an image sequence?
[00:05:19 CEST] <RedH8> Like snowboard magazines or skateboard mags?
[00:05:21 CEST] <StephenS> nope
[00:05:31 CEST] <StephenS> but most likely to drop every <x> frame from video
[00:05:36 CEST] <RedH8> Kk ttying to grasp exactlt what ya want
[00:05:36 CEST] <StephenS> so to get timelapse effect
[00:05:41 CEST] <nerium> relaxed: So tcp seams to work, but not http
[00:05:48 CEST] <RedH8> Ahh ok
[00:06:40 CEST] <BtbN> So you do want to speed up the video...
[00:06:44 CEST] <RedH8> Lol just use a lower framerate on your target output
[00:06:50 CEST] <RedH8> It'll drop frames
[00:07:05 CEST] <BtbN> Won't change the duration though, which is the whole point of a timelapse.
[00:07:24 CEST] <RedH8> If you want some ugly choppy looking video yeah he'd have to speed it up somehow too
[00:08:11 CEST] <StephenS> how or even better, how could I slowdown 70% of video and last 30% to just make it regular?
[00:08:14 CEST] <BtbN> you propably want to use the setpts filter.
[00:08:25 CEST] <RedH8> Not that ive ever looked but is there any relating info in the header of the container relating to framerate?
[00:08:39 CEST] <BtbN> split the file, speedup the first one, then concat them again.
[00:09:07 CEST] <BtbN> Or write a crazy setpts formula that knows where 70% start and uses a diffrent calculation then.
[00:09:43 CEST] <StephenS> well I would rather do it all together :)
[00:09:58 CEST] <BtbN> Have fun figuring out the calculation formula then.
[00:12:07 CEST] <relaxed> nerium: did you read the man page? add -listen 1
[00:12:33 CEST] <TD-Linux> voice, they are still improving vp9 in libvpx (it's used on youtube so they care). vp10 is barely started at this point
[00:12:57 CEST] <StephenS> something like this ffmpeg -i ino.mp4 -filter_complex " [0:v]trim=0:10[v1]; [0:v]trim=10:30[v2]; [0:v]trim=start=30[v3]; [v2]setpts=PTS/0.5[slowv]; [v1][slowv][v3]concat=n=3:v=1:a=0[outv]" -map [outv] map 0:a -c:v libx264 -c:a copy output.mp4
[00:13:07 CEST] <StephenS> but says map is invalid
[00:13:31 CEST] <StephenS>  Unable to find a suitable output format for 'map'
[00:14:37 CEST] <relaxed> StephenS: I think you need to use the split filter first
[00:15:43 CEST] <nerium> relaxed: thanks
[00:15:56 CEST] <relaxed> hmm, but that will only give you two output labels
[00:16:07 CEST] <StephenS> something is wrong with map?
[00:17:30 CEST] <StephenS> ok it worked, but I added -map (dash)
[00:17:42 CEST] <StephenS> and it generated video, but its not slowed down at all
[00:44:23 CEST] <Lectem> Hi guys, I'm unsure if it was reported before, but on windows10 + msys2 + mingw32-w64, the configure script is broken. It doesnt recognize the os (Unknown OS 'msys_nt-10.0'.) and if I pass it --target-os=mingw32-w64 --host-os=mingw32-w64, it will fail to compile libavformat (libavformat/os_support.c:26:19: fatal error: netdb.h: No such file or directory)
[00:47:46 CEST] <RedHate> Lectem: did you manage to get it to build anyways? Quick little addition of "//" infront of the include of said header?
[00:52:02 CEST] <RedHate> Comment it out and attempt the  build again. If something references it then it will stop again.
[00:57:16 CEST] <RedHate> Or go compile netdb found https://www.google.ca/url?sa=t&source=web&rct=j&url=http://netdbtracking.sourceforge.net/&ved=0CBsQFjAAahUKEwjP7ZOTzcrIAhWBuoAKHVOeDCs&usg=AFQjCNFaoc834TkoEcz8CkvJ-DigzBUblg
[00:57:37 CEST] <RedHate> No fault of ffmpeg that you are missing prerequisite libraries.
[01:06:13 CEST] <Lectem> RedHate: netdb is replaced by winsock2 on mingw32-w64 iirc
[01:07:47 CEST] <RedHate> Ahh ok my bad net db is the unix tcp ip shit eh? Its been a while since ive dealt with thay
[01:07:50 CEST] <RedHate> That**
[01:08:12 CEST] <Lectem> yeah, its a system header
[01:08:15 CEST] <RedHate> And yeah indeed mingw uses winsock
[01:08:40 CEST] <RedHate> Id just comment all the network shit out who needs that anyways
[01:08:40 CEST] <RedHate> Lol
[01:08:52 CEST] <Lectem> well, rtsp and stuff ^^
[01:09:05 CEST] <RedHate> Fine fine fine *hissssssss*
[01:09:07 CEST] <RedHate> :)
[01:09:43 CEST] <Lectem> I think it used to compile just fine with older versions of mingw32-w64
[01:10:02 CEST] <Lectem> (in fact thats what is recommended on ffmpeg website, msys+mingw32-w64)
[01:10:08 CEST] <Lectem> msys2*
[01:10:51 CEST] <RedHate> Can you dump a .diff by comparing the two to trace the issue?
[01:11:17 CEST] <RedHate> Lots of work for something you shouldnt have to fix however
[01:11:25 CEST] Action: RedHate stfus
[01:16:22 CEST] <Lectem> I don't really remember what version of mingw32-w64 used to work, it was on my old computer
[01:26:39 CEST] <Lectem> actually nvm, I just cleaned reconfigured and all and now it seems to work...
[01:28:01 CEST] <RedHate> Did you set the paths for include / libraries or something?
[01:28:12 CEST] <RedHate> Or just a random bug?
[01:28:57 CEST] <RedHate> For my own reference lol incase heh
[01:39:47 CEST] <Lectem> to be honest, absolutely no idea why it suddenly worked
[01:40:15 CEST] <Lectem> I did a bunch of things like git clean -fd, make clean
[01:41:07 CEST] <RedHate> Weird yet excellent.
[02:54:12 CEST] <BullHorn> hello
[02:55:17 CEST] <BullHorn> i record 1440p30fps crf=21 video in OBS with x264 ultrafast preset. can i use ffmpeg cli to remux the video down with the same settings except using a slow preset?
[02:55:22 CEST] <BullHorn> basically to keep the same quality and reduce filesize?
[02:55:44 CEST] <BullHorn> people told me to use HandBrake but i already have ffmpeg cli and i think it should be able to do something like that?
[02:56:32 CEST] <DHE> you'd have to use the same source material. otherwise there will be degradation from chained transcoding
[02:57:09 CEST] <BullHorn> ok heres the thing
[02:57:39 CEST] <BullHorn> i record into .flv containers (incase the recording software crashes) and then use ffmpeg to remux it into .mp4 for further editing in premiere
[02:57:43 CEST] <BullHorn> thats what i use now: ffmpeg -i D:\Streaming\%1.flv -c copy -copyts F:\%2.mp4
[02:58:07 CEST] <BullHorn> convert flvpotato mp4tomato and it does it
[02:58:21 CEST] <BullHorn> how can i make it use the slow x264 preset during this conversion
[02:59:04 CEST] <DHE> as I said, it will degrade the image quality a bit...
[02:59:31 CEST] <DHE> replace "-c copy" with "-c:a copy -c:v libx264 -crf 21 -preset:v slow"
[02:59:48 CEST] <BullHorn> i guess i dont mind that, ill use crf 20 while recording
[02:59:51 CEST] <BullHorn> ill try
[03:05:53 CEST] <BullHorn> wow
[03:05:59 CEST] <BullHorn> 30s video from 350mb to 140mb...
[03:06:01 CEST] <BullHorn> thats awesome
[03:06:03 CEST] <BullHorn> but too slow
[03:06:07 CEST] <BullHorn> ill try medium preset now :)
[03:07:25 CEST] <RedHate> Thats disgusting. Wtf 140mb for 30 seconds of video gasp
[03:09:32 CEST] <BullHorn> its 1440p
[03:09:39 CEST] <BullHorn> 78% more pixels than 1080p
[03:09:44 CEST] <BullHorn> my mind was blown when i calculated this
[03:09:45 CEST] <BullHorn> :|
[03:10:27 CEST] <BullHorn> it makes most things look lossless but in arma3 you can still notice artefacts
[03:10:30 CEST] <BullHorn> good source for editing :)
[03:10:34 CEST] <BullHorn> thanks man, this really helped
[03:10:50 CEST] <BullHorn> ill be using the fast preset though
[03:10:53 CEST] <BullHorn> slow is WAY too slow
[03:11:02 CEST] <BullHorn> medium and fast have the same file size, surprisingly
[03:13:50 CEST] <TD-Linux> yeah there is no way to remux but it's pretty common for people to do a reencode from the live stuff
[03:14:19 CEST] <TD-Linux> generally you use a high bitrate with ultrafast preset to record, then a lower bitrate for the final verison
[03:14:30 CEST] <TD-Linux> (with a slower preset)
[03:14:43 CEST] <BullHorn> yep thats what im testing now
[03:15:00 CEST] <BullHorn> 30s ultrafast recording at crf=21, then converting to crf=23 with all presets, surprising results so far
[03:15:21 CEST] <BullHorn> faster and veryfast produce smaller files than slow, medium and fast
[03:15:29 CEST] <BullHorn> and more than x5 faster ;x
[03:15:40 CEST] <TD-Linux> yeah but the visible quality is lower
[03:15:56 CEST] <TD-Linux> crf is not an absolute quality setting
[03:16:17 CEST] Action: RedHate upscales 240 to 4k cus it looks amazing.
[03:16:23 CEST] <BullHorn> still, at crf=23 every ultrafast still looks pretty darn good
[03:16:23 CEST] Action: RedHate is being a smart ass
[03:17:16 CEST] <TD-Linux> yes, throw enough bitrate at anything and it will look great :)
[03:18:27 CEST] <BullHorn> yea so heres my results
[03:18:38 CEST] <BullHorn> veryslow, slow and medium = too slow
[03:18:45 CEST] <BullHorn> superfast and ultrafast = huge files
[03:19:12 CEST] <BullHorn> fast, faster and veryfast = same file size and barely noticeable difference
[03:19:17 CEST] <BullHorn> in quality
[03:19:21 CEST] <BullHorn> so ill stick to veryfast \o/
[03:19:47 CEST] <BullHorn> its a shame ffmpeg tells me so much info when it completes an encode, but it doesnt tell me how long it took
[03:20:13 CEST] <BullHorn> i guess i should just look at the fps
[03:25:45 CEST] <RedHate> Bullhorn i dunno about recent updates but the version i use only tells me how much has been encoded in seconds.
[03:26:19 CEST] <RedHate> Its annoying. Like the formula to give it hours  and minutes was to complex of an addition lol
[03:26:28 CEST] <BullHorn> its fine
[03:26:37 CEST] <BullHorn> i did all the reencodes, slow, medium, fast, etc
[03:26:40 CEST] <RedHate> Nope nope seconds is good enough use a calculatpr
[03:26:44 CEST] <RedHate> Calculator*
[03:27:56 CEST] <BullHorn> slow was 8fps, medium was 16fps, fast was 25, veryfast was 40, superfast was 55 and ultrafast was 95
[03:28:07 CEST] <BullHorn> superfast and ultrafast too big files so veryfast it is :)
[03:28:40 CEST] <DHE> the visual quality difference of using crf=X between the various presets should be non-existant for the same X number
[03:29:03 CEST] <BullHorn> i ever use a higher X number in the reencode, just incase
[03:29:07 CEST] <BullHorn> record with 21, reencode with 23
[03:29:12 CEST] <DHE> at least that's how it works with qp mode. crf might introduce changes since it studies the image to decide a qp value
[03:30:28 CEST] <TD-Linux> DHE, I don't think that's really true, even for qp mode
[03:30:45 CEST] <BullHorn> im testing the same thing with nvenc now instead of x264 and each line that it does prints this:
[03:30:46 CEST] <BullHorn> http://i.imgur.com/mAsc7sJ.png
[03:30:47 CEST] <TD-Linux> consider if a slower search find a better predictor, but in both cases the qp is high enough to skip the block
[03:30:49 CEST] <BullHorn> whats the meaning ;x
[03:59:24 CEST] <DHE> I'd try dropping the -copyts but check to see if anything happened to the video
[03:59:48 CEST] <DHE> TD-Linux: I was trying it earlier. unless I messed up my testeding psnr and ssim didn't change
[04:00:11 CEST] <DHE> wow I cannot type straight when I'm tired
[04:00:48 CEST] <TD-Linux> DHE, ah well tests always trump hypotheses :)
[04:02:52 CEST] <DHE> but I only tested qp mode. I'm trying to judge libx264 vs nvenc
[04:10:46 CEST] <DHE> I love nvenc for the speed, but I am definitely seeing the quality difference when frame-stepping...
[04:17:54 CEST] <BullHorn> DHE dropping -copyts didnt help
[04:17:58 CEST] <BullHorn> its even worse with some files
[04:18:11 CEST] <BullHorn> i get the Past duration 0.9something too large like 50 times between each ping
[04:18:33 CEST] <BullHorn> only happens when i reencode stuff that i used nvenc to record
[04:19:41 CEST] <BullHorn> http://i.imgur.com/M8V2i4F.png
[04:26:52 CEST] <Nosomy> have the way to calculate a filesize of m2ts-file which is a ts-file remuxed?
[04:35:39 CEST] <TD-Linux> ls -l
[05:27:40 CEST] <edman007> Hi, so I got an interesting one... I got a lot of JPGs that I want to make into a video, once I do that I want to apply the deshake algorithm to ensure the image is still...then I want to apply the timestamp from the jpg's exif to each frame...how would I do that?
[06:25:25 CEST] <foreverska> Is there a more machine readable form of the devices list?
[07:47:28 CEST] <waressearcher2> is it possible to make every frame a I-frame ?
[07:59:52 CEST] <Nosomy> yes
[08:00:43 CEST] <Nosomy> but this could be make stroboscope video.
[08:01:28 CEST] <Nosomy> if is libx264, -g 1 make this
[08:01:55 CEST] <Nosomy> keyint x264 param
[08:20:03 CEST] <waressearcher2> what is stroboscope  ?
[08:20:17 CEST] <waressearcher2> stroboscope video
[08:20:19 CEST] <waressearcher2> how is that
[08:22:04 CEST] <Nosomy> some pieces of frame like as those videos which causes epilepsy.
[08:23:24 CEST] <waressearcher2> like the once they should use in TV store ?
[08:24:49 CEST] <Nosomy> even if it does not cause the effect to the video, the bit rate goes up.
[08:33:12 CEST] <Nosomy> random sample with 107 frames, 1080p23.97:  --preset ultrafast  --qp 0 : 134240kbps ; the same with keyint 1 : 146553kbps;  Preset medium crf 23 (normal): 8614kbps; the same with keyint 1: 11172kbps
[08:35:01 CEST] <waressearcher2> what it means ?
[08:35:14 CEST] <Nosomy> ~20% more bitrate in average.
[08:35:27 CEST] <waressearcher2> -20% ?
[08:35:38 CEST] <waressearcher2> "~" means average ?
[08:36:12 CEST] <Nosomy> "~" means approximately
[08:52:43 CEST] <Nosomy> frame type decisions are better when made by the encoder.
[08:53:05 CEST] <waressearcher2> is your name a word play on word "Sodomy" ?
[08:53:23 CEST] <Nosomy> nop
[10:41:43 CEST] <||arifaX> How can I bring down cpu usage of this command. Just a still image as video: http://pastebin.com/cnsFVWfY
[10:54:27 CEST] <xsi> twitch caught, and it was live. But black screen
[10:55:16 CEST] <BullHorn> My 22nd Birthday in: -141782115secs
[10:55:25 CEST] <BullHorn> wrong button
[10:55:25 CEST] <BullHorn> lol
[10:55:39 CEST] <fritsch> and delay is negative :-)
[10:56:08 CEST] <BullHorn> yeah i havent touched this scripts since i was 21 years old, apparently :p
[10:56:22 CEST] <xsi> 31
[10:58:01 CEST] <fritsch> so, then you are 26 now and need to wait half a year to 27?
[10:58:13 CEST] <BullHorn> yes
[10:59:36 CEST] <chungy> chungy=> select '2015-10-18 01:55:16'::timestamp - '141782115 seconds'::interval - '21 years'::interval;
[10:59:36 CEST] <chungy>       ?column?
[10:59:36 CEST] <chungy> ---------------------
[10:59:36 CEST] <chungy>  1990-04-21 02:00:01
[11:00:39 CEST] <chungy> I think I'm off a year...
[11:00:46 CEST] <chungy> oh yeah, 22nd birthday, not 21st
[11:00:54 CEST] Action: chungy should go to bed
[11:00:55 CEST] <fritsch> :-)
[11:01:11 CEST] <fritsch> but guessing game has just started
[11:01:22 CEST] <fritsch> chungy: you cannot leave yet
[11:03:01 CEST] <chungy> Which game? :p
[11:03:24 CEST] <fritsch> guessing BullHorn's life
[11:03:38 CEST] <fritsch> BullHorn: any other script you could run?
[11:03:56 CEST] <BullHorn> i just deleted them all
[11:03:57 CEST] <BullHorn> :p
[11:04:14 CEST] <fritsch> too bad
[11:07:54 CEST] <BullHorn> so does anyone have an idea
[11:08:12 CEST] <fritsch> i even forgot the question sadly
[11:08:13 CEST] <BullHorn> why converting x264 flv to mp4 goes smooth
[11:08:23 CEST] <BullHorn> and nvenc flv to mpr results in these repeated warnings: http://i.imgur.com/M8V2i4F.png
[11:08:51 CEST] <klaxa> what ffmpeg version are you using?
[11:09:04 CEST] <klaxa> i think those warnings were "fixed" a few months ago
[11:09:15 CEST] <BullHorn> ffmpeg version N-75458-g198110d
[11:09:21 CEST] <BullHorn> its like 2-4 weeks old
[11:09:41 CEST] <klaxa> what's your command line?
[11:09:55 CEST] <BullHorn> ffmpeg -i D:\Streaming\%1.flv -c:a copy -c:v libx264 -crf 23 -preset:v veryfast -copyts F:\%2.mp4
[11:10:48 CEST] <klaxa> doesn't look obviously wrong
[11:11:05 CEST] <BullHorn> ill get 2.8.1 and try again
[11:11:42 CEST] <fritsch> where is nvenc involved here?
[11:11:54 CEST] <klaxa> yeah that too
[11:11:58 CEST] <BullHorn> nvenc is the way i record the source video
[11:12:18 CEST] <klaxa> what's the source?
[11:12:38 CEST] <BullHorn> stuff on my screen
[11:12:57 CEST] <klaxa> ok, thought if it wasn't a screencast you could save one encode
[11:13:34 CEST] <xsi> black screen: https://bpaste.net/show/824eddd59992
[11:13:43 CEST] <xsi> idk firstly launched
[11:14:40 CEST] <BullHorn> getting the same warnings with 2.8.1
[11:15:09 CEST] <klaxa> xsi: might want to regenerate your API key now ;)
[11:16:30 CEST] <klaxa> xsi: you're missing -s $SIZE and -i :0.0
[11:17:10 CEST] <klaxa> you want: ffmpeg -f x11grab -framerate $FRAMERATE -s $SIZE -i :0.0 -f alsa -ac 2 -i hw:0,0 -vb $BITRATE -vcodec libx264 -threads 0 -acodec libmp3lame -ab 128k -ar 22050 -s $SIZE -f flv "rtmp://live.twitch.tv/app/$KEY"
[11:17:29 CEST] <klaxa> (note that -framerate is "better" than -r)
[11:17:38 CEST] <klaxa> using -r
[11:17:47 CEST] <klaxa> *using -r as an input option may result in A/V desyn
[11:17:50 CEST] <klaxa> *desync
[11:17:53 CEST] <xsi> they were false because of use flags so i'd try
[11:17:54 CEST] <xsi> w8
[11:17:58 CEST] <xerox> twitch does rtmp?
[11:18:05 CEST] <klaxa> if x11grab can't provide frames fast enough
[11:18:23 CEST] <xerox> oh maybe it's their endpoint to use if you're streaming
[11:18:36 CEST] <klaxa> twitch also does rtmp
[11:18:44 CEST] <klaxa> but also hls
[11:19:27 CEST] <xerox> I use livestreamer to capture the streams, can you use ffmpeg directly?
[11:19:53 CEST] <klaxa> it's a lot more hassle to find out the correct rtmp parameters, i'm using livestreamer too
[11:20:28 CEST] <xerox> what options do you use? mine are livestreamer --ringbuffer-size=1024M --player-http -v --player ~/.bin/mplayer-stream
[11:21:11 CEST] <xerox> (where the last thing is a bash script that runs mplayer on the 127.0.0.1:randomport url that ls generates)
[11:21:18 CEST] <klaxa> >livestreamer -Q -O $stream best | /root/tools/ffmpeg/ffmpeg -i - -map 0:a -map 0:v -c copy -absf aac_adtstoasc -metadata creation=$(date +%s) "$date".mkv
[11:22:30 CEST] <xerox> nice
[11:22:37 CEST] <klaxa> mkvtoolnix doesn't like the aac i get from twitch, therefore the bitstream filter
[11:23:15 CEST] <xerox> I do flv->mp4 and more often than not get the aac error yeah
[11:23:31 CEST] <BtbN> It's just about the extradata, the aac itself is fine.
[11:23:39 CEST] <klaxa> ah
[11:24:03 CEST] <xerox> do you ever re-encode? twitch seems to use a lot of bandwidth even if the stream itself doesn't warrant it
[11:24:15 CEST] <klaxa> no i don't re-encode if possible
[11:24:27 CEST] <BtbN> Twitch uses as much bandwidth as the streamer decides to use. 3.5Mbit/s max.
[11:26:26 CEST] <xerox> there is some "mosty static image" content whose filesize, at crf 18, gets halved
[11:26:37 CEST] <xerox> or thereabouts
[11:27:22 CEST] <BtbN> Remvoign the cbr padding should also achive that.
[11:27:35 CEST] <xerox> how do you go about doing that?
[11:27:47 CEST] <BtbN> A simple -c copy pass should get rid of it.
[11:27:59 CEST] <xerox> hmm, that is not my experience
[11:28:25 CEST] <xerox> I use: ffmpeg -i ${FLV} -acodec copy -bsf:a aac_adtstoasc -vcodec copy ${MP4}
[11:30:18 CEST] <BtbN> There is no cbr padding then.
[11:30:27 CEST] <BtbN> acodec/vcodec is deprecated, btw.
[11:30:43 CEST] <xerox> didn't know that! what should I use instad?
[11:30:46 CEST] <BtbN> -c
[11:30:52 CEST] <BtbN> + stream specifiers
[11:30:57 CEST] <xsi> klaxa :0.0: Invalid argument
[11:31:09 CEST] <klaxa> gg wp
[11:31:25 CEST] <klaxa> can you pastebin your complete output?
[11:33:25 CEST] <BullHorn> i have no idea what might be causing the problem
[11:33:31 CEST] <BullHorn> ;/
[11:34:05 CEST] <xsi> https://bpaste.net/show/696d19c96207
[11:35:45 CEST] <klaxa> does ffmpeg -formats show x11grab?
[11:40:02 CEST] <xsi> https://bpaste.net/show/c56caddd5286
[11:41:30 CEST] <xsi> D
[11:41:40 CEST] <xsi>  D  x11grab         X11 screen capture, using XCB
[11:50:58 CEST] <c_14> xsi: what's your command line
[11:52:56 CEST] <xsi> ffmpeg -f x11grab -framerate $FRAMERATE -s $SIZE -i ":0.0" -f alsa -ac 2 -i hw:0,0 -vb $BITRATE -vcodec libx264 $
[11:53:04 CEST] <xsi> w8
[12:07:11 CEST] <xsi> https://bpaste.net/show/7d475699d713
[12:17:32 CEST] <c_14> Your command works for me.
[12:19:31 CEST] <c_14> But a video bitrate of 128k is _really_ low. You might want to increase that.
[12:30:04 CEST] <xsi> ok
[12:30:36 CEST] <xsi> bbl .
[12:32:50 CEST] <xsi> bbl
[14:11:50 CEST] <DHE> well, the eyeball tests are in. nvenc loses to x264 without a doubt
[14:15:12 CEST] <Phrk_> hello
[14:15:36 CEST] <Phrk_> I'm trying to use nvenc, is there any doc ? The only option is -preset ?
[14:21:28 CEST] <Mavrik> Huh, what's the catch at nvenc only supporting 2-pass mode with low latency presets?
[14:21:55 CEST] <DHE> -preset, -profile, -level, -g, bitrate settings, etc
[14:21:59 CEST] <DHE> also 'slow' does 2-pass
[14:22:17 CEST] <DHE> also 2pass isn't the same as x264 2-pass. I think it's an internal thing where it encodes the frame twice
[14:23:32 CEST] <Mavrik> Mhm, I just find it interesting that you'd do a low-latency encode preset and then let users do it twice.
[14:23:44 CEST] <Mavrik> Did you perhaps test it?
[14:24:33 CEST] <DHE> I'm focusing on the settings that matter to me. consequently I've mostly tested medium and slow presets.
[14:25:18 CEST] <DHE> in x264 parlance low latency means the encode() function reads a frame and spits out the encoded version directly. without low latency x264 might sit on a few dozen frames before it starts giving you outputs.
[14:25:39 CEST] <Mavrik> Mhm,
[14:25:42 CEST] <Phrk_> how do you use 2pass?
[14:26:01 CEST] <Mavrik> Just looking through doc, it seems that the point of 2-pass is really to get a nice CBR
[14:26:04 CEST] <Phrk_> Im not sure to understand, the best quality and most expansive preset is ?
[14:26:18 CEST] <Mavrik> Which then starts to make sense with low-latency, since they're probably using this profile to get Shield streaming working properly.
[14:26:35 CEST] <Mavrik> Totally flat bandwidth usage with low latency that is.
[14:27:06 CEST] <Phrk_> for encoding game ?
[14:27:59 CEST] <DHE> when consistency matters
[14:28:27 CEST] <Phrk_> and if i just want to encode hq video ?
[14:28:31 CEST] <DHE> also lowlatency mode means no b-frames since that requires out-of-order decoding and that the encoder must sit on a few frames to produce them
[14:29:10 CEST] <DHE> unfortunately when quality matters x264 wins hands down. even mixing x264 preset=fast and nvenc preset=slow
[14:29:27 CEST] <DHE> though nvenc in this scenario still does double the framerate
[14:29:56 CEST] <Mavrik> I doubt the realtime HW encoders will ever rival x264 quality wise.
[14:30:07 CEST] <Mavrik> It's just not possible to reach same quality if you wanna do it fast.
[14:30:27 CEST] <Mavrik> Since you can't afford a large lookahead and extensive search
[14:30:34 CEST] <ChocolateArmpits> But should nvenc be more power-efficient when compared to encoding on cpus ?
[14:30:39 CEST] <ChocolateArmpits> shouldn't*
[14:30:49 CEST] <Mavrik> I guess.
[14:31:02 CEST] <Mavrik> If they're actually using their encoder not CUDA.
[14:31:13 CEST] <Mavrik> Whe main GPUs are powerhungry beasts.
[14:31:22 CEST] <ChocolateArmpits> Like what is the general power efficiency when comparing a frame of similar quality encoded on nvenc and a typical cpu via x264
[14:31:29 CEST] <DHE> nvidia-settings reports distinct utilization stats for the video and main GU hardware...
[14:31:37 CEST] <Mavrik> Phrk_, there's a command that dumps all parameters for a codec (don't remember it right now though)
[14:31:43 CEST] <Mavrik> Phrk_, should give you all possible parameters for nvenc
[14:32:16 CEST] <Mavrik> ChocolateArmpits, it's probably an order of magnitute different
[14:32:29 CEST] <Phrk_> interesting
[14:32:30 CEST] <ChocolateArmpits> Mavrik: in favor of which ?
[14:32:30 CEST] <Mavrik> I haven't measured on desktop, but on mobile using the H.264 chip is extremely cheap power-wise.
[14:32:43 CEST] <DHE> ffmpeg -h full   > ffmpeg-help.txt    # then search the file for nvenc
[14:32:45 CEST] <ChocolateArmpits> the hardware solution, right ?
[14:32:54 CEST] <Phrk_> well for backup of a dvd i go x264 then
[14:32:57 CEST] <c_14> ffmpeg -h encoder=nvenc
[14:33:13 CEST] <Mavrik> ChocolateArmpits, yes.
[14:33:40 CEST] <DHE> those only show codec-specific parameters though. -b:v, -maxrate and -flags ildct also apply to nvenc
[14:33:49 CEST] <Mavrik> I noticed the same on my Mac (which I think defaults to QuickSync, not Nvenc - hard to tell though). But haven't relly benchmarked it.
[14:34:42 CEST] <Phrk_> nice
[14:35:07 CEST] <ChocolateArmpits> Mavrik: quicksync comes at different quality with different versions of hd graphics
[14:35:18 CEST] <Mavrik> But yeah, if you only have to do 2x bitrate from x264, then the HW decoder is actually rather good :)
[14:35:26 CEST] <ChocolateArmpits> The rule is the newer it is the better encoding results you can expect
[14:36:21 CEST] <Phrk_> Someone can explain me the 2pass thing, there is "rawvideo -y /dev/null" in my terminal but i dont understand why
[14:36:57 CEST] <ChocolateArmpits> Phrk_: in pass 1 only the passlogfile is relevant, you don't need to write the rendered file
[14:37:01 CEST] <DHE> in terms of x264 or nvenc? they mean different thing
[14:37:02 CEST] <DHE> s
[14:37:45 CEST] <Phrk_> x264
[14:37:48 CEST] <Mavrik> I guess that nvenc doesn't generate a passlog file, but just encodes it properly.
[14:37:56 CEST] <Mavrik> So no two executions.
[14:38:03 CEST] <Phrk_> OOOOKKK
[14:38:33 CEST] <DHE> what ChocolateArmpits says. x264 makes a lot file graphing parameters from the video during pass 1. for pass 2 it uses that to make better choices about encoding.
[14:38:42 CEST] <DHE> so the first pass you can just throw away the result
[14:38:57 CEST] <Phrk_> interesting
[14:38:57 CEST] <Mavrik> Yep... also you almost certanly shouldn't be doing 2-pass encoding on x264 :)
[14:39:02 CEST] <Mavrik> Except in some very rare use-cases.
[14:39:15 CEST] <Phrk_> What ?
[14:39:15 CEST] <DHE> (which I qualify for)
[14:39:23 CEST] <Phrk_> from mpeg2 ?
[14:39:47 CEST] <DHE> it does double the encoding time and is only really useful when you have file size or bitrate constraints
[14:39:48 CEST] <ChocolateArmpits> When you need to hit specific size requirements and you need the best quality for it
[14:40:17 CEST] <Mavrik> Yep, and even for bitrate constraints the -crf -maxrate is pretty much spot on quality wise without the huge speed penalty :)
[14:41:31 CEST] <ChocolateArmpits> It doesn't *really* double it. More like takes overall 1.6-1.7x time longer. Setting --pass 1 by default turns off a few things which speed up the encoding
[14:42:17 CEST] <Mavrik> DHE, what's your usecase? Mobile streaming?
[14:42:24 CEST] <DHE> basically yes
[14:42:48 CEST] <ChocolateArmpits> Mavrik: I object crf without a bitrate ceiling. set the bufsize and maxrate next to it
[14:43:08 CEST] <Mavrik> ?
[14:43:26 CEST] <Mavrik> DHE, yeah, that makes sense. We do live TV so can't do 2-pass really, The quality is still pretty great :)
[14:43:48 CEST] <ChocolateArmpits> well from my experience setting crf by itself can fluctuate the bitrate quite wildly
[14:43:53 CEST] <Phrk_> Do you have good preset for my 4,5gb dvd to 1gb or 2 (good quality)
[14:44:06 CEST] <ChocolateArmpits> in a number of cases it can break playback
[14:44:35 CEST] <Mavrik> ChocolateArmpits, huh?
[14:44:46 CEST] <Mavrik> In streaming environments yes, for stored content, no.
[14:44:56 CEST] <ChocolateArmpits> because the bitrate gets so high the playback media can't send the data fast enough, for example writing the file to a dvd and having too high bitrate due to crf
[14:45:47 CEST] <Phrk_> for storing on my computer and play on it
[14:47:26 CEST] <Mavrik> Phrk_, to get a 2GB filesize for a 2 hour movie, you need to set somewhere between 2000-2500 kbit bitrate.
[14:47:38 CEST] <Mavrik> So set that, do a slow profile and you're set.
[14:47:45 CEST] <Mavrik> Adjust according to taste.
[14:48:08 CEST] <Mavrik> If you don't care about hitting exactly 2GB, use a sane -crf parameter that still looks nice.
[14:48:15 CEST] <Phrk_> if i go lossless with x264, filesize will be bigger than the mpeg2 file ?
[14:48:17 CEST] <Mavrik> I guess somewhere around 22 or so.
[14:48:22 CEST] <Mavrik> No.
[14:48:50 CEST] <Phrk_> so what the most hq/sane -crf ?
[14:48:59 CEST] <Phrk_> i don't care about the size
[14:49:01 CEST] <Mavrik> ChocolateArmpits, unless you're doing some freak 4K encodes, that really shouldn't be a concern outside public internet.
[14:49:03 CEST] <Phrk_> just need to be smaller
[14:49:10 CEST] <Mavrik> Then you do care about the size.
[14:49:43 CEST] <Mavrik> Phrk_, crf 23 is default and it's good enough for pretty much most content.
[14:49:55 CEST] <Mavrik> The video should be smaller unless you have white noise :)
[14:50:14 CEST] <Mavrik> Use -preset slow or something to squeeze a bit more quality out of video.
[14:55:51 CEST] <furq> 2GB for a dvdrip is pretty huge
[14:56:40 CEST] <DHE> Mavrik: for live video how big a lookahead buffer do you use? or are you using zerolatency?
[14:56:56 CEST] <Mavrik> Oh no, zerolatency butchers the quality.
[14:57:03 CEST] <Phrk_> Thanks guys !
[14:57:04 CEST] <DHE> yes I know...
[14:57:08 CEST] <Mavrik> Afaik we just run the default slow preset.
[14:57:27 CEST] <Mavrik> Medium/fast for channels that aren't really popular.
[14:57:43 CEST] <Mavrik> 5 sec or so total delay from source to DVB emitter is acceptable atm.
[14:57:50 CEST] <DHE> slow? that must be hell on the CPU though
[14:58:21 CEST] <Mavrik> PAL + 48 core Xeons are just fine.
[14:58:33 CEST] <DHE> oh, sd content
[14:58:34 CEST] <Mavrik> But that's only a handful of channels that are watched the most.
[14:58:47 CEST] <Mavrik> HD is medium mosty AFAIK
[14:58:58 CEST] <Mavrik> fullHD is even encoded into 960x1080
[14:59:03 CEST] <Phrk_> yeah, -tune film -preset slow -crf 22 seem better quality than nvenc but same file size
[14:59:05 CEST] <Phrk_> cool
[15:00:33 CEST] <Mavrik> Phrk_, yp, you can even do like crf 24 (larger number - smaller file and worse quality) and see if it's still good enough for you.
[15:01:24 CEST] <Phrk_> ffmpeg is so powerfull
[15:01:44 CEST] <DHE> it is, but like any powerful tool you need to understand how to use it
[15:02:54 CEST] <DHE> I learned how to make a single ffmpeg process output multiple variants of the same video (all part of the streaming process) and then everything changed...
[15:08:10 CEST] <ChocolateArmpits> -tee is pretty great
[18:36:41 CEST] <sine0> anyone know why there is not a package for ffmpeg in the repo
[18:36:48 CEST] <sine0> of the debian distro
[18:38:30 CEST] <c_14> There is if your version of debian is new enough.
[18:45:36 CEST] <furq> sine0: jessie uses libav because politics are fun
[18:45:51 CEST] <sine0> oh ok.
[18:45:52 CEST] <furq> which is another good reason to not use debian stable
[18:46:29 CEST] <sine0> well I was going to go stretch, but i tried to install it on my laptop and had some shizz going on with systemd so i thought i would play safe on my main box with jessie
[18:49:19 CEST] <JEEB> well, I will also mention that the guy who maintained libav on debian seemed to do a whole lot more heavy lifting than the guy who seems to maintain FFmpeg there now
[18:49:50 CEST] <JEEB> although it's still a bad situation there since even if software is dead debian doesn't seem to want to either a) remove those packages or b) distribute multiple versions of FFmpeg/Libav's libraries
[18:50:34 CEST] <JEEB> of course this might just be my first act of communication I saw from the FFmpeg maintainer @ Debian, which was "no you cannot remove shit you deprecated 3 years ago"
[18:52:54 CEST] <JEEB> but in any case, ffmpeg should be rather simple to build with the requirements most people have
[18:53:08 CEST] <JEEB> due to the fact that pretty much every decoder is already in libavcodec
[18:53:13 CEST] <JEEB> so it's left to what encoders you want to use
[19:04:13 CEST] <furq> you could try installing the package from stretch
[19:04:42 CEST] <furq> but after a point it's simpler to just upgrade to stretch
[20:57:08 CEST] <edman007> Hi, I'm using the drawtext filter and %{n} does not actually print the frame number, for example it says it matches the frame number in the documentation, but frame 0 prints one, and then it increments by one or two each frame
[20:57:19 CEST] <edman007> why is it not accurate?
[21:08:37 CEST] <StephenS> ayo, is there a way to make a blinking video, on some parts, like the one taken in disco?
[21:44:46 CEST] <lahwran> hey folks, I'm looking around for libraries I could use to splice h.264 video frames together
[21:45:15 CEST] <lahwran> I'd like to take frames from a bunch of different files, and without uncompressing them, assemble them into a single video stream
[21:45:24 CEST] <lahwran> (all frames involved will be keyframes)
[21:45:54 CEST] <lahwran> is this something that libav* would help with?
[21:46:25 CEST] <lahwran> I would expect it would, since one of the steps will need to be reading/writing mp4 files
[21:46:43 CEST] <lahwran> can anyone give me pointers about how to do this?
[21:47:10 CEST] <DHE> can you do that without transcoding?
[21:47:23 CEST] <DHE> ffmpeg can let you assemble tiles of videos but the output will need to go through a video encoder at the end
[21:47:43 CEST] <lahwran> are you asking if it can be done, or are you asking if I'm willing to do it differently?
[21:48:11 CEST] <lahwran> I specifically am hoping that this will involve nothing but some copying and then generating mp4 headers
[21:48:32 CEST] <DHE> I'm suggesting what you're asking probably can't be done with ffmpeg directly. my guess is you'd need to unpack the H264 yourself and stitch the macroblocks together yourself
[21:48:37 CEST] <lahwran> oh sure
[21:48:41 CEST] <lahwran> yes
[21:48:45 CEST] <lahwran> I realize that
[21:48:54 CEST] <lahwran> I came here to ask if ffmpeg's libraries will help me do that
[21:49:27 CEST] <lahwran> probably they'll only help with the mp4-reading portion of the task, right?
[21:49:34 CEST] <lahwran> and I'll need to learn the h264 format myself
[21:50:06 CEST] <__gotcha> Is it possible to trim beginning of a video without recoding it ?
[21:50:17 CEST] <lahwran> heh, similar question to what I'm asking
[21:50:19 CEST] <DHE> there is an h264 "parser" which can help partially. but in the end you'll need to do it the hard way
[21:50:29 CEST] <DHE> __gotcha: you can only start playback on a keyframe, but yes
[21:50:36 CEST] <ChocolateArmpits> __gotcha: not in any conventional way, the trimmed file will have to be written
[21:50:48 CEST] <__gotcha> I have read about keyframes
[21:51:06 CEST] <__gotcha> s/read/heard/
[21:51:28 CEST] <lahwran> also, when I say splice frame together, what I mean is I have a bunch of mp4s, each named frame_%d.mp4, with exactly one frame in them. I'd like to turn them into a single video that is each frame in sequence.
[21:51:29 CEST] <__gotcha> where can I dig deeper to understand what they are
[21:51:44 CEST] <DHE> a keyframe is a single video frame that stands on its own. other frame types will depend on having intact previous frames to use as reference
[21:51:53 CEST] <DHE> so you couldn't start playing video from anything besides a keyframe
[21:52:40 CEST] <lahwran> (this probably seems insane, and I am aware of the concept of an XY problem; I'm not unaware of better options, I actually need to do this weird thing)
[21:53:03 CEST] <__gotcha> iow, at the beginning of a video, there is a full frame, ie keyframe then other frames are diffed
[21:53:12 CEST] <DHE> lahwran: oh.... that's a little more sane...
[21:53:14 CEST] <DHE> (barely)
[21:53:25 CEST] <__gotcha> and until there is another keyframe
[21:53:35 CEST] <__gotcha> and again following frames diffed
[21:53:56 CEST] <lahwran> it also needs to be as fast as humanly possible
[21:53:57 CEST] <DHE> __gotcha: basically yes
[21:54:00 CEST] <lahwran> :p
[21:54:13 CEST] <__gotcha> DHE: I know I am very fuzzy
[21:54:32 CEST] <__gotcha> but finally understand why I have lost time not understanding what was wrong
[21:54:41 CEST] <__gotcha> DHE: thanks
[21:54:42 CEST] <DHE> lahwran: if they all meet the same encoding criteria (eg: frame size) then it can be done. you'll probably have to timecode it yourself though.
[21:54:50 CEST] <lahwran> ok
[21:54:53 CEST] <lahwran> that's not too bad, then
[21:55:21 CEST] <lahwran> hm, why does each frame have a timecode?
[21:55:35 CEST] <lahwran> (this is an unrelated question, I'm just suddenly curious about h.264's design)
[21:55:46 CEST] <DHE> it's not h264 directly. let me put it this way. what's the framerate of a 1-frame video?
[21:56:26 CEST] <lahwran> hm. I thought the framerate was defined in a header
[21:57:02 CEST] <lahwran> does each frame have a real-time offset from the previous one, or perhaps from an absolute point? can you have variable-framerate video?
[21:57:11 CEST] <DHE> i'm not entirely sure about .mp4. but either way you're making a new .mp4 file out of just frames and each frame will have a time code of 0.00s from the source
[21:57:15 CEST] <furq> you can have variable framerate video
[21:57:20 CEST] <lahwran> huh I see
[21:57:28 CEST] <DHE> it does vary by the container. mpeg-ts and MKV famously do variable FPS
[21:57:37 CEST] <furq> some deinterlacers make use of that
[21:57:56 CEST] <lahwran> so each frame has its own time then, and you have to set it to be a fixed offset from the previous one; and this is how framerate is defined
[21:58:12 CEST] <lahwran> I'm going to read through the h.264 spec, but it's pretty intimidating
[21:58:42 CEST] <DHE> more or less. the ffmpeg libraries have assistance in the form of time bases. you can set the timebase as 1/30 (1, 30) and then frame numbers correspond to playback as you would expect
[21:58:52 CEST] <DHE> I think you'll see as you go
[21:59:02 CEST] <JEEB> AVC doesn't really have timestamps by itself. You *can* write timestamps into additional SEI (?) messages methinks
[21:59:08 CEST] <JEEB> but f.ex. x264 doesn't do that
[21:59:27 CEST] <JEEB> at most you have a header that is often abused to signal a "frame rate", even though technically it is not that
[21:59:34 CEST] <lahwran> oh hm
[21:59:38 CEST] <JEEB> containers are what usually contain timestamps
[21:59:43 CEST] <lahwran> if you leave off framerate, what will happen?
[21:59:49 CEST] <lahwran> ahh
[21:59:52 CEST] <lahwran> okay
[21:59:56 CEST] <lahwran> that is how I thought it worked
[22:00:04 CEST] <JEEB> usually decoders default to 25Hz if nothing is given
[22:00:13 CEST] <JEEB> and then containers override that
[22:01:08 CEST] <JEEB> and as I said, that field that is generally used for a "frame rate" with raw AVC is not really that
[22:01:27 CEST] <ChocolateArmpits> wouldn't it be wiser to use 25Fps term in stead of 25Hz ? interlaced content is 50Hz so saying 25Hz would seem like it would play half as slow, even though it has 25 frames
[22:01:29 CEST] <DHE> the x264 cli may not, but historically I found mencoder (really old version now) when dumping to raw .264 files still somehow "guessed" the right framerate...
[22:01:44 CEST] <JEEB> DHE: that's not timestamp data
[22:01:53 CEST] <JEEB> that's the thing that is generally used for "frame rate"
[22:02:09 CEST] <JEEB> which is also what x264 writes when you set a constant frame rate for it
[22:02:18 CEST] <DHE> that would work...
[22:02:29 CEST] <JEEB> timestamp data in raw AVC is not something you generally see
[22:02:50 CEST] <furq> lahwran: out of interest, have you tried concatenating the files with ffmpeg
[22:03:05 CEST] <lahwran> I have not, I don't really know how to use ffmpeg itself very well
[22:03:11 CEST] <lahwran> tell me more
[22:03:30 CEST] <lahwran> the main thing i know about ffmpeg is that if I do "ffmpeg -i a b" then it'll magically guess the right thing to do :p
[22:03:32 CEST] <furq> if they're all keyframes and all the same size i can't see any obvious reason why that wouldn't work
[22:03:39 CEST] <lahwran> huh interesting
[22:03:48 CEST] <lahwran> will it try to make them non-keyframe?
[22:04:16 CEST] <lahwran> part of why I want them to stay keyframes is that they don't have a lot of inter-frame compressibility
[22:04:16 CEST] <furq> i don't think so but i've never had a reason to find out
[22:04:21 CEST] <lahwran> cool
[22:04:39 CEST] <lahwran> how would one do this? just provide -i multiple times?
[22:04:43 CEST] <DHE> use of the concatenation feature and copying might work...
[22:04:54 CEST] <DHE> https://trac.ffmpeg.org/wiki/Concatenate
[22:05:00 CEST] <lahwran> oh cool
[22:05:01 CEST] <furq> ffmpeg -i %d.mp4 -c copy out.mp4
[22:05:01 CEST] <DHE> It's a somewhat tricky subject, so just read up on it
[22:05:13 CEST] <furq> and if that doesn't work then yeah, try using the concat filter/protocol
[22:05:21 CEST] <JEEB> uhh
[22:05:33 CEST] <JEEB> furq: I don't see that thing really working in any way
[22:05:57 CEST] <JEEB> you hae a single -i and then that shell thing will open up to multiple file names, unless that is handled by ffmpeg itself
[22:06:00 CEST] <JEEB> *have
[22:06:09 CEST] <furq> that works for multiple images according to the wiki
[22:06:12 CEST] <JEEB> yes
[22:06:20 CEST] <JEEB> that's a special thing with the image2 format thing methinks
[22:06:23 CEST] <furq> fair enough
[22:06:32 CEST] <furq> i don't have a bunch of single-frame mp4s here or i'd have tested it first
[22:06:35 CEST] <lahwran> hehe
[22:13:38 CEST] <StephenS> ayo, is there a way to make a blinking video, on some parts, like the one taken in disco?
[22:14:05 CEST] <lahwran> ok, so that worked pretty well
[22:14:46 CEST] <lahwran> it's not as fast as I hoped though. I suspect it's still transcoding it.
[22:22:37 CEST] <lahwran> hm, no, not still transcoding it, I don't think
[22:41:03 CEST] <DHE> lahwran: did you put "-c copy" in your commandline?
[22:45:04 CEST] <lahwran> yeah
[22:45:53 CEST] <lahwran> it's printing "[mov,mp4,m4a,3gp,3g2,mj2 @ 0x2d01460] Auto-inserting h264_mp4toannexb bitstream filter" a lot
[22:48:09 CEST] <DHE> odd, that usually means the container type was changed..
[22:53:45 CEST] <lahwran> oh man, ok
[22:54:00 CEST] <lahwran> when I try it with the concat protocol, it's MUCH faster
[22:54:13 CEST] <lahwran> much, much, much faster, as in I gave it 2500 and it was the same speed as 250
[22:54:42 CEST] <lahwran> ...oh...
[22:54:46 CEST] <lahwran> I don't think it's working...
[22:54:47 CEST] <lahwran> oops
[23:00:18 CEST] <lahwran> DHE: how do you set the framerate in the output container? will -framerate do that, or will it make it edit the timestamps on each frame?
[23:00:29 CEST] <furq> -r
[23:03:22 CEST] <lahwran> that's not working
[23:03:37 CEST] <lahwran> when I give it a crapton of .ts files as input and an mp4 as output, with this command:
[23:03:47 CEST] <lahwran> v="$(@ '"|".join(["/run/shm/frame.ts"] * 500)')"; time ffmpeg -nostats -loglevel 0 -f mpegts -i "concat:$v" -r 25 -c copy -y -an /run/shm/testsadf9.mp4
[23:04:08 CEST] <lahwran> then I check testsadf9.mp4, it says 12800 fps (!)
[23:04:43 CEST] <lahwran> it seems to have copied the frames ok, but since each frame was a single file, it had the time coding problem DHE warned me about originally
[23:04:55 CEST] <lahwran> I also tried -framerate
[23:04:57 CEST] <lahwran> neither of them did it
[23:05:25 CEST] <lahwran> @ is just a "run this python" command, so the bash variable v contains 500 repetitions of /run/shm/frame.ts
[23:05:57 CEST] <lahwran> oh, when I shut off quiet, it has a bunch of messages like:
[23:05:58 CEST] <lahwran> [mp4 @ 0x2eb0440] Non-monotonous DTS in output stream 0:0; previous: 494, current: 0; changing to 495. This may result in incorrect timestamps in the output file.
[23:07:04 CEST] <DHE> decode timestamps... yep, called it
[23:07:36 CEST] <lahwran> hehe
[23:07:58 CEST] <lahwran> DHE: any ideas how to fix it, considering that -r and -framerate appear to have done nothing?
[23:09:20 CEST] <lahwran> how do I specify whether -r is an input or an output option?
[23:09:25 CEST] <DHE> before you specify the output filename use "-r 30 -vsync drop"
[23:09:42 CEST] <lahwran> what does "vsync drop" do?
[23:10:00 CEST] <DHE> the commandline format of ffmpeg is:   ffmpeg [input1 opts] -i input1 [[input2 opts] -i input2]...   [output1 opts] output1 [[output2 opts] output2]...
[23:10:07 CEST] <lahwran> oic
[23:10:13 CEST] <lahwran> destroys input timestamps
[23:10:13 CEST] <DHE> it drops the video frame sync data forcing regeneration
[23:10:33 CEST] <lahwran> whoops, now it crashes
[23:10:39 CEST] <lahwran> av_interleaved_write_frame(): Invalid argument
[23:11:00 CEST] <lahwran> same command as I pasted above, except with -vsync drop added after -r 25
[23:12:30 CEST] Action: DHE is throwing science at the wall and seeing what sticks, honestly
[23:12:43 CEST] <lahwran> hehe
[23:12:53 CEST] <lahwran> that's apparently a valid way to cook pasta ;)
[23:13:18 CEST] <lahwran> I learned this recently. apparently the saying comes from that being an actually-used way of checking whether pasta is done
[23:14:34 CEST] <furq> it doesn't work as well with conchiglie
[23:18:47 CEST] <lahwran> seems to work quite well with conceptelli though
[23:19:12 CEST] <lahwran> looking around a bit, it seems that this is actually a known ffmpeg bug
[23:19:31 CEST] <lahwran> it had been around for a while unfixed in 2011
[23:39:34 CEST] <sebboh> Hello.  I have an avi file.  I'm trying to play it on my chromecast.  When I play an mp4 in chrome (on android) I can send it to the chromecast.  Can I just put the content of the avi into a mp4 container and try that?
[23:40:04 CEST] <DHE> sebboh: usually. can't hurt to try. ffmpeg -i input.avi -c copy output.mp4
[23:40:20 CEST] <sebboh> I'm on linux and I just installed ffmpeg, winff, and mediainfo.  Oh, ok, trying.
[23:40:31 CEST] <DHE> but it may depend on the codecs. worst case it doesn't work
[23:41:09 CEST] <Mavrik> AVI can have a lot of crap and I don't think chromecast does the most common DivX
[23:41:29 CEST] <DHE> there was a transition period when people put h264 in AVI. you might get lucky
[23:41:59 CEST] <DHE> and divx was mostly mpeg4 (sorta) so maybe?
[23:42:25 CEST] <sebboh> the avi is indeed divx.
[23:43:20 CEST] <Mavrik> worstcase is that you have to transcode :-
[23:43:22 CEST] <Mavrik> :/
[23:43:50 CEST] <Mavrik> DivX is a MPEG4 Part 2
[23:43:59 CEST] <Mavrik> I'm just not 100% if it's totally compatible.
[23:44:30 CEST] <DHE> I'd prefer XviD myself if it came to that...
[23:45:00 CEST] <Mavrik> Different encoder, same result :)
[23:49:41 CEST] <sebboh> oh, it is XviD.  The .mp4 I just created with -c copy doesn't play in the chrome (android) browser nor on the chromecast.  So, I should provide some other -c option, eh?
[23:51:03 CEST] <sebboh> Internet says: ffmpeg -i input.avi -f matroska -vcodec h264 -acodec aac -ac2
[23:51:08 CEST] <sebboh> Sound good to you folks?
[23:51:36 CEST] <sebboh> oh, what is pipe:1 ?
[23:52:13 CEST] <sebboh> ... nevermind, that's for redirecting the output somewhere, eh?
[23:55:53 CEST] <sebboh> oh gawd, four seconds of encoding time for one second of play time.  Time for a beer. :)
[23:59:11 CEST] <BullHorn> im getting a bunch of 'Past duration 0.999992 too large' errors when reencoding a video
[23:59:14 CEST] <BullHorn> i posted about this yesterday
[23:59:28 CEST] <BullHorn> can someone take a look at the file? or should i provide something else ;x
[23:59:38 CEST] <BullHorn> it only happens when i use NVENC in OBS, doesnt happen with quicksync or x264
[00:00:00 CEST] --- Mon Oct 19 2015