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

[burek]

[01:24:10 CEST] <salviadud> I got a question about what happens when I converto Truehd (atmos) to DTS with the dca codec
[01:24:22 CEST] <salviadud> If I don't specify a bitrate
[01:24:33 CEST] <salviadud> I'm using an ffmpeg binary in windows
[01:25:18 CEST] <c_14> ffmpeg uses whatever's configured as the default
[01:25:23 CEST] <c_14> (which often isn't that great)
[01:26:45 CEST] <salviadud> Problem is that if I do a ffmpeg -i filename.mkv
[01:26:58 CEST] <salviadud> I can't see the bitrate on that truehd audio stream
[01:27:04 CEST] <salviadud> It just states that it is 24-bit
[01:27:27 CEST] <salviadud> So, is there like a -crf option for audio?
[01:27:42 CEST] <c_14> depends on the codec
[01:27:52 CEST] <salviadud> dca is experimental
[01:27:55 CEST] <c_14> some only have abr, others also have vbr settings
[01:27:59 CEST] <salviadud> I have to add -strict -2 to make it work
[01:28:12 CEST] <salviadud> I'm guessing it doesn't have many options
[01:28:22 CEST] <salviadud> How do I find out the options for dca?
[01:29:10 CEST] <c_14> ffmpeg -h encoder=dca
[01:29:16 CEST] <c_14> doesn't look like it has a vbr mode
[01:30:06 CEST] <furq> i'm pretty sure the dca encoder in ffmpeg is always 16-bit anyway
[01:30:33 CEST] <c_14> it says it's s32, but I wouldn't know
[01:30:44 CEST] <furq> yeah it does but i checked the output and everything else reckons it's 16/48
[01:30:57 CEST] <c_14> maybe it truncates then
[01:30:59 CEST] <furq> dts core is always 16/48
[01:31:09 CEST] <furq> and i don't think the encoder supports any of the extensions
[01:31:20 CEST] <furq> if it does then i assume you have to actually ask for them, which i didn't
[01:33:16 CEST] <furq> bye
[03:48:57 CEST] <Boobuigi> Does anyone know why "-ar 44100" would result in a LARGER file than "-ar 48000" with "-c:a libmp3lame"?
[03:49:47 CEST] <DHE> bits being spent on compression artifacts?
[03:51:14 CEST] <Boobuigi> I guess so.  Still, it's surprising.
[05:51:44 CEST] <Jonno_FTW> hi I'm having trouble reading in data from my ip camera, it keeps saying 404 and I can't figure out the url, any ideas?
[06:13:10 CEST] <Jonno_FTW> actually scrap that I gotit
[06:17:46 CEST] <fa0> Hello
[06:18:57 CEST] <fa0> I've been trying to mux avi to mkv and some of them give me, 'Can't write packet with unknown timestamp' and would not convert/mux, so I found that you are suppose to use '-fflags +genpts' is suppose to be the solution, can anyone tell me if this is correct?
[06:19:42 CEST] <fa0> When I use '-fflags +genpts' ffmpeg will now mux avi to mkv, but I wanted to make sure this is the best approach?
[11:30:21 CEST] <saeba> hello, i want to deinterlace a VHS capture and get a vertically shaking still image from using "yadif=1:0,mcdeint=fast:0", but a steady image using "yadif=1:0,mcdeint=fast:1". already did a wiki and several google searches on the topic but only found that yadif had the parity mixed up years ago. just yadif without mcdeint works as expected, so parity=0 is correct. can anyone confirm? i cannot supply my sample video since i am currently at work
[11:30:21 CEST] <saeba> , lunch break :)
[11:42:26 CEST] <furq> saeba: i just tested and they both look fine to me
[11:42:35 CEST] <furq> which is odd but then idk why mcdeint would even have a concept of field order
[11:44:05 CEST] <saeba> i cannot see a difference in motion. it was a still frame that revealed the shaking
[11:44:26 CEST] <saeba> also with swaped parity the file gets smaller, thus i suppose temporal compression gets better.
[11:44:27 CEST] <furq> i take it you're on a recent ffmpeg
[11:45:06 CEST] <saeba> yes, just downloaded it
[11:49:31 CEST] <saeba> mcdeint needs field order to know the spatial position of a deinterlaced frame's pixel in the original interlaced frame's field - as far as i understand it.
[12:02:07 CEST] <saeba> ugh, it seems yadif is the problem here. just verified that the video is tff. "yadif=parity=1" produces clean result, so 1 is tff, not bff. and then mcdeint is right to have the yadif parity swaped.
[12:08:22 CEST] <furq> weird
[12:08:40 CEST] <furq> yadif=1:1 gives the results you'd expect when i run it on a tff video
[12:10:21 CEST] <saeba> https://trac.ffmpeg.org/ticket/380 had this 7 yrs ago, but as a documentation error. the ticket was closed, so i assumed it was ok.
[12:11:15 CEST] <saeba> even funnier: yadif=parity=bff also works on the tff source. so using verbose parameters is not the solution.
[12:11:36 CEST] <furq> by "the results you'd expect" i mean it's broken
[12:13:57 CEST] <furq> oh wow they weren't kidding about extra_slow were they
[12:14:03 CEST] <furq> even nnedi is faster than this
[12:14:12 CEST] <dragmore88> hi, so im trying to do a i50 to p50 transcode, would yadif=1 be the best way to keep the quality? or are there better deinterlacer/framedoubler combos in ffmpeg?
[12:14:28 CEST] <furq> dragmore88: bwdif is slightly higher quality imo
[12:14:36 CEST] <furq> it's not a massive difference though
[12:14:51 CEST] <dragmore88> ok? could u elaborate a bit more on how it works?
[12:15:04 CEST] <furq> !filter bwdif @dragmore88
[12:15:05 CEST] <nfobot> dragmore88: http://ffmpeg.org/ffmpeg-filters.html#bwdif
[12:15:22 CEST] <furq> i couldn't give you any detail about how it actually works
[12:15:27 CEST] <furq> i've just tried them both
[12:15:45 CEST] <dragmore88> oki
[12:15:46 CEST] <dragmore88> tx
[12:15:54 CEST] <furq> if this is 1080i then either of those should be fine
[12:16:11 CEST] <dragmore88> 1080i50 -> 1080p50
[12:16:21 CEST] <furq> yeah there's no need to get fancy then
[12:16:26 CEST] <dragmore88> hehe ok
[12:16:27 CEST] <furq> yadif/bwdif both do a good job with clean sources
[12:16:32 CEST] <saeba> furq: thanks for confirming the yadif issue
[12:16:46 CEST] <furq> saeba: lol
[12:16:51 CEST] <furq> i think i've been unclear here
[12:16:58 CEST] <furq> using yadif bff on a tff source is broken here
[12:17:15 CEST] <furq> as you'd expect it to be
[12:17:43 CEST] <furq> i've just said the exact same words there haven't i
[12:17:47 CEST] <saeba> but i set yadif to tff
[12:17:52 CEST] <furq> it outputs frames in the wrong order
[12:18:26 CEST] <saeba> so yeah, it works ok, but the parameters are reversed... or the output, yes :)
[12:18:42 CEST] <furq> yeah i'm not seeing that here
[12:18:52 CEST] <furq> tff on a tff source works fine
[12:19:37 CEST] <furq> are you sure your source is tff
[12:19:50 CEST] <saeba> ah, i i got you wrong the whole time. and starting with that bias, all your explanations also shiftes to the opposite
[12:21:33 CEST] <furq> setfield=tff,separatefields should make it obvious if it's tff
[12:21:45 CEST] <saeba> yes, the source is tff. 2 hints: 1) Media Player Classic deinterlace set to bff gives the correct output. 2) having yadif and mcdeint set mismatching parities produces a clean result.
[12:22:01 CEST] <furq> did you mean tff instead of bff there
[12:22:30 CEST] <saeba> i'll try it out in a minute. bear with me, lunch is over and i gotta answer the phone frequently.
[12:22:57 CEST] <saeba> yes, MPC on tff
[12:36:09 CEST] <saeba> furq: setfield=tff,separatefields -> ok. setfield=bff,separatefields -> jitter.
[12:36:23 CEST] <furq> weird
[12:56:13 CEST] <dragmore88> hmm, howcome i ffprobe detects a file as progressive, whilst mediainfo says its interlaced.. is this just metadata parsing by ffprobe?
[12:57:08 CEST] <dragmore88> ffprobe : Stream #0:0(eng): Video: prores (apch / 0x68637061), yuv422p10le(bt709, progressive), 1920x1080, 187875 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 25 tbn, 25 tbc (default)
[12:57:33 CEST] <dragmore88> mediainfo : Scan type                                : Progressive
[12:57:33 CEST] <dragmore88> Original scan type                       : Interlaced
[12:57:33 CEST] <dragmore88> Original scan order                      : Top Field First
[12:57:33 CEST] <dragmore88> Bits/(Pixel*Frame)                       : 3.624
[12:58:30 CEST] <durandal_1707> dragmore88: what ffmpeg version?
[12:58:35 CEST] <dragmore88> 4.0
[12:59:06 CEST] <dragmore88> no, sec
[12:59:33 CEST] <dragmore88> yea 4.0
[12:59:39 CEST] <dragmore88> tried 3.3 and 4.0, same output
[13:00:00 CEST] <dragmore88> prores source and a mpeg2 source
[13:00:03 CEST] <dragmore88> same problem
[13:01:53 CEST] <durandal_1707> dragmore88: is it interlaced if you watch it?
[13:02:11 CEST] <dragmore88> correction, it fails on the prores file, but correctly tells it as field based in the mpeg2 version
[13:02:13 CEST] <dragmore88> let me check
[13:03:06 CEST] <dragmore88> hard to see really
[13:04:31 CEST] <durandal_1707> perhaps mediainfo reports scan type of original source...
[13:04:47 CEST] <dragmore88> how does it know that ?
[14:00:37 CEST] <saeba> furq: yadif was not at fault, tff and bff work as expected. during the numerous tests and very similar command lines and output file names i must have made an error.
[14:01:59 CEST] <saeba> but still yadif->mcdeint produces jitter on a still frame where only yadif or yadif->mcdeint with mismatching parity does produse a steady image.
[14:06:15 CEST] <saeba> hypothesis (still confirming, since also testing 'extra_slow'): mcdeint sees the image distortions on the still frame's borders and despite 'qp=1' has those border distortions influence the center still image's motion vectors. in case of  mismatching parity, maybe mcdeint cannot make as much sense of the distortions's motion and modifies the image less, thus producing a more steady image.
[14:06:45 CEST] <stu> Hello
[14:07:32 CEST] <stu> I'm wondering if someone can help me to save a udp multicast stream to a file, it works for around 2-4 minutes and then freezes until I terminate it
[14:08:12 CEST] <saeba> (the VHS still frame is an artifact where there was no image signal from the VHS vhs player in between RWND and PLAY, but it has fast altering interlaced(!) distortions at the upper and lower border)
[14:45:00 CEST] <kepstin> saeba: i generally don't recommend using mcdeint - it's very slow and doesn't really give better results than other more modern filters. Might I suggest trying bwdif?
[14:46:40 CEST] <DHE> stu: I'm going to ask a specific question. is the duration of recording exactly 4 minutes, 20 seconds? (within reasonable error margins)
[14:49:40 CEST] <stu> @DHE the last few times it's been around 3 minutes 32 seconds, but it's never been over 5 minutes
[14:50:38 CEST] <DHE> hmm... close enough maybe? I'm going to suggest it's a networking issue. you probably have managed switches that run IGMP snooping but no IGMP querier on the network
[14:52:05 CEST] <stu> I can stream it no problem in VLC though, would that not be impacted too if that was the case?
[14:52:44 CEST] <DHE> I can't comment on VLC specifically. do you have managed switches? like a switch with a commandline interface and serial port?
[14:53:29 CEST] <stu> Yes, I've managed switches
[14:54:31 CEST] <DHE> can you configure one as an IGMP querier for your vlan? or add such a device somewhere? I do think that's the issue
[14:55:58 CEST] <DHE> if it's a Juniper (Junos) switch I can help with that. else you're on your own.
[14:56:39 CEST] <DHE> the main piece of advice is that the device doing the IGMP querying will be slammed with all multicast traffic on the network so if you have a lot of multicast you should choose your querier wisely.
[15:02:29 CEST] <saeba> kepstin: thanks, i'll try bwdif out. finished my tests with other 'mode' and 'qp' settings for mcdeint and always ended up with worse results on a still frame than yadif plus no visible enhancement in motion. was about to stick to only yadif, but bwdif looks promising. i'll give it a try :)
[15:02:32 CEST] <stu> Ah ok, I'll look into that then, at least now I know what could possibly be the root cause of it
[15:04:28 CEST] <DHE> stu: it seems most likely given the suspiciously specific time of the stream stopping
[15:07:09 CEST] <stu> Perfect, thanks very much for your help :)
[15:21:41 CEST] <saeba> kepstin: ok, bwdif it is. slightly faster(?) than yadif and imperceptible differences in the result. also, slightly smaller file.
[15:25:55 CEST] <furq> bwdif is a bit slower in my experience
[15:26:21 CEST] <furq> nnedi gives good results but it's incredibly slow
[15:26:35 CEST] <furq> you could also try qtgmc but it's a big hassle to set up
[15:39:02 CEST] <saeba> furq: thanks, but i will stick to bwdif now. got a bunch (~100 hrs) of broken, unsorted VHS captures that i need to fix, edit and encode lying around since over 2 years. spent 2 years trying it with only avs scritps to avoid intermediate files but gave up since a/v sync problems and undefined behaviour when accessing frame indices around erroneously encoded sections (thanks hauppauge! ;)).
[15:41:41 CEST] <saeba> have been tuning ffmpeg for days now to get my interlaced 25fps-ish vfr cr4p to a lossless 50p encode and want to start avs editing anew. fiddling with the nuances of the deinterlacer would be tweaking around the 98% border.
[15:43:13 CEST] <saeba> heck, some of those tapes were moldy! screw that ^^. i just hope -c:a copy will not reveal new syncronization glitches, but it looks ok in my testfile.
[16:39:18 CEST] <dragmore88> anyone know why -channel_layout 63 in the ac3 encoder triggers a 5.1 layout for the AAC encoder in a dual track encode? https://pastebin.com/uYdKkV8b
[16:39:47 CEST] <dragmore88> i want a 2 channe stereo aac track + a 5.1 channel AC3 track in the same TS file
[16:43:41 CEST] <furq> dragmore88: you can only specify -filter_complex once
[16:43:49 CEST] <kepstin> dragmore88: that command line has multiple issues - i would think you should be getting an error due to one of the -map options not matching anything...
[16:44:06 CEST] <furq> merge both filterchains with a ;
[16:44:18 CEST] <kepstin> you also have a -filter:v that would be ignored as well
[16:44:28 CEST] <furq> and a -vf
[16:45:10 CEST] <furq> also rc-lookahead has nothing to do with the keyframe interval
[16:45:57 CEST] <kepstin> dragmore88: I don't actually see a -channel_layout option in there, but once you fix all the other problems with that command, you'll probably just have to add a stream specifier to it so it's only applied to the ac3 track.
[16:46:06 CEST] <furq> you shouldn't need it at all
[16:46:20 CEST] <furq> amerge with six mono tracks should guess that you want 5.1
[16:46:48 CEST] <dragmore88> i have 8 mono tracks, first 6 is for the ac3, last 2 is for the aac
[16:46:57 CEST] <furq> right but you're passing six mono tracks to amerge
[16:47:04 CEST] <dragmore88> yes
[16:48:01 CEST] <furq> if you just merge all those filterchains then it should all work fine
[16:48:12 CEST] <furq> right now it's ignoring all but the last one
[16:48:56 CEST] <kepstin> I'm really surprised it's not giving an error for the one -map option that references a name that's not in the filter graph.
[16:49:23 CEST] <furq> yeah that's weird
[16:49:42 CEST] <dragmore88> could u give me a syntax that would fix the audio tracks? i dont understand how to combine and split them
[16:49:59 CEST] <dragmore88> maybe we could put that up on the docs as this is a typical layout for prores
[16:51:09 CEST] <dragmore88> so how to cherry pick 0-5 monotrack, send them to the ac3 encoder and flag it as 5.1 in combination with picking track 6&7 -> aac
[16:51:27 CEST] <furq> http://vpaste.net/QUjUp
[16:51:49 CEST] <furq> like i said, you shouldn't need to flag anything
[16:53:05 CEST] <dragmore88> so we dont need to use the -ac 2 or 6 ?
[16:53:12 CEST] <furq> nope
[16:53:35 CEST] <dragmore88> hmm.. the documentation is giving a headake ;)
[16:53:40 CEST] <dragmore88> me*
[16:53:46 CEST] <furq> and yeah, while you're there, get rid of rc-lookahead
[16:53:53 CEST] <furq> that's not doing what you think it does
[16:54:00 CEST] <dragmore88> ok ?
[16:54:20 CEST] <dragmore88> i just need to enforce IDR frame at the gop start
[16:54:28 CEST] <furq> yeah lookahead has nothing to do with that
[16:54:35 CEST] <dragmore88> and Iframe inside a gop if a scenechange is happening
[16:54:46 CEST] <dragmore88> no i know, but read somewhere that it was reccomended
[16:54:53 CEST] <furq> also min-keyint higher than keyint doesn't seem right
[16:55:06 CEST] <furq> and also higher than force_key_frames
[16:55:29 CEST] <dragmore88> that syntax actuially works.. ffprobe confirms it
[16:55:38 CEST] <dragmore88> i DONT want a IDR frame inside a gop
[16:55:52 CEST] <dragmore88> https://superuser.com/questions/908280/what-is-the-correct-way-to-fix-keyframes-in-ffmpeg-for-dash
[16:56:04 CEST] <dragmore88> last post: ffmpeg <other_options> -force_key_frames "expr:eq(mod(n,<GOPSIZE>),0)" -x264opts rc-lookahead=<GOPSIZE>:keyint=<GOPSIZE * 2>:min-keyint=<GOPSIZE> <other_options>
[16:56:16 CEST] <furq> yeah you've got that the wrong way round
[16:56:20 CEST] <furq> oh nvm
[16:56:24 CEST] <furq> ok that's just weird then
[16:56:39 CEST] <dragmore88> check what that Reuben guy says
[16:56:40 CEST] <furq> but yeah i've never messed with dash so if it works for you then sure
[16:56:45 CEST] <dragmore88> im trying to understand it
[16:57:02 CEST] <dragmore88> well.. its not spesifically dash.. but a requirement our packagers has
[16:57:26 CEST] <dragmore88> but why should one remove the lookahead ?
[16:57:42 CEST] <furq> i mean 42 isn't a bad value, it's just something you don't need to touch
[16:57:51 CEST] <furq> and it's generally best to not touch settings that you don't need to
[16:58:22 CEST] <dragmore88> 46 u mean.. it was supposed to b 48
[16:58:25 CEST] <dragmore88> 23.98x2
[17:00:37 CEST] <furq> he gives his justification for it in the comments and it sounds pretty wrong to me
[17:00:55 CEST] <dragmore88> hehe.. well its miles over my head..
[17:01:10 CEST] <dragmore88> but ffprobe confirms the frame layout
[17:01:29 CEST] <dragmore88> regardless of the source framerate (23.98,24 and 25fps)
[17:01:41 CEST] <furq> well his justification is that it avoids wasting resources, which is potentially true, but then his reasoning behind it is flawed
[17:01:46 CEST] <furq> but either way it definitely won't affect the frame layout
[17:02:14 CEST] <dragmore88> so how would u write the syntax to get what i want ?
[17:02:35 CEST] <dragmore88> 2 sec gop, forced IDR at the start (keyframe) and scenecut inside a gop if needed
[17:02:50 CEST] <furq> like i said, if this guy's recommendation works for you then stick with it
[17:03:05 CEST] <furq> i'm just saying the lookahead bit definitely doesn't have any effect on that
[17:03:10 CEST] <dragmore88> oki
[17:04:06 CEST] <dragmore88> updated syntax : https://pastebin.com/u6J1NBcm
[17:04:08 CEST] <dragmore88> looks ok
[17:05:11 CEST] <dragmore88> if we remove -ac 2 for the aac encoder, it fails.. AC3 works without it
[17:05:48 CEST] <furq> uh
[17:05:56 CEST] <furq> the filters are still broken in this
[17:08:24 CEST] <dragmore88> strange that it works
[17:42:09 CEST] <mpeg> Why does this command not work with ffmpeg 4? it seems to work fine with 3.4.2 but on 4 it doesn't properly loop the video to the audio length, but cuts off after the video length, heres the full command: https://pastebin.com/tdntrM8L
[17:55:00 CEST] <c_14> regression in stream_loop probably
[17:55:49 CEST] <c_14> get a minimal working example (that works in 3.4.2 and doesn't in 4), open a bugreport and if you can bisect to find the git commit
[18:03:50 CEST] <dragmore88> furq, this seems to work now, see anything u wanna pick on ? https://pastebin.com/KvLiE4ky
[18:04:27 CEST] <dragmore88> furq, ffprobe confirms the IDR and I frame layout
[18:39:44 CEST] <kepstin> dragmore88: other than the -ac options being redundant, seems fine.
[18:41:04 CEST] <kepstin> (if it doesn't work without the -ac options, then there's still something mixed up in the filters or mapping - and that means that the tracks are being remixed and aren't what you're trying to do)
[20:55:16 CEST] <benbro1> what's the syntax to output to a named pipe?
[21:07:57 CEST] <DHE> on unix? a named pipe is a file on disk and may be treated as such
[22:09:43 CEST] <slavanap> Hi! Is there possible to replace video with static picture with ffmpeg?
[22:10:40 CEST] <ChocolateArmpits> slavanap, ffmpeg -i input.mp4 -i picture.jpg -map 1:v -map 0:a output.mp4
[22:11:22 CEST] <dragmore88> kepstin, well as i said earlier, if i omit the AC 2 on the AAC encoder it barfs... but ac3 = fine...
[22:12:01 CEST] <dragmore88> only thing now is to try to normalize the audio levels between the 2 tracks if thats even possible
[22:12:08 CEST] <slavanap> ChocolateArmpits, and how ffmpeg will determine total video duration? By audio? So I don't have to specify in explicitly?
[22:12:41 CEST] <ChocolateArmpits> i think so yes
[22:13:41 CEST] <kepstin> dragmore88: if you get an error without the -ac 2 on aac, then you're sending the wrong stream to the aac encoder.
[22:13:55 CEST] <kepstin> dragmore88: and adding the option only hides the problem by remixing the stream
[22:14:39 CEST] <kepstin> dragmore88: (well, there's other possible reasons why there might be problems, but i'd have to see the actual ffmpeg to say why)
[22:15:10 CEST] <kerio> do you fine folks know of any codec that's optimized for depth information?
[22:15:29 CEST] <dragmore88> kepstin,u mean the logoutput ? or anything else i can feed u ?
[22:15:34 CEST] <kepstin> dragmore88: with those -ac options, it's possible that if the streams are switched, you have 5.1 downmixed to 2 in the aac, and 2ch upmixed to 5.1 in the ac3 ;)
[22:15:38 CEST] <kerio> or do i just have to ffvhuff
[22:15:48 CEST] <kepstin> kerio: what do you mean by "depth information"?
[22:15:56 CEST] <kerio> z16 pixel format
[22:16:25 CEST] <kepstin> kerio: is that just 16bit integer, sincle plane?
[22:16:27 CEST] <kerio> either depth or disparity values
[22:16:42 CEST] <kerio> kepstin: yep, but with lots of areas that are zero or SHORT_MAX
[22:16:47 CEST] <kepstin> and I assume you want to avoid lossy codecs
[22:17:06 CEST] <kerio> well, a lossy codec could help with the noise in the data :^)
[22:17:16 CEST] <kerio> but yeah, ideally a lossless one
[22:17:19 CEST] <kepstin> h264 and h265 top out at 12bit, so you'd lose some precision there
[22:17:32 CEST] <kepstin> so you're basically left with stuff like ffvhuff or maybe ffv1 there
[22:17:42 CEST] <kerio> i could forcibly make it use less bits i guess
[22:18:10 CEST] <kepstin> ffmpeg can do that conversion for you (it's basically just truncating the low order bits, tho, iirc - maybe do some dithering)
[22:19:19 CEST] <kerio> no literally just throwing away pixels that are too far away
[22:20:04 CEST] <kerio> even at the highest precision, the range goes from 0 to 6 meters
[22:20:10 CEST] <kerio> and i only care about maybe 0-2m
[22:20:41 CEST] <ChocolateArmpits> kerio, you can try exr
[22:20:54 CEST] <kepstin> but yeah, if you have large areas of constant value, any codec should compress that fairly well, even lossless ones
[22:21:00 CEST] <ChocolateArmpits> if you can work with image sequences
[22:21:25 CEST] <kerio> aww, even just 14 bits ends up being 0-1.6m, which is a bit too short
[22:21:51 CEST] <kerio> however the default precision is 1mm, which ends up giving a range of 0-65m
[22:22:07 CEST] <kerio> and i might be fine with 1mm of precision
[22:22:46 CEST] <kepstin> you'd obviously lose precision with a lossy codec anyways, if you decide to go that way (they're designed to make stuff *look* similar, rather than be mathematically similar)
[22:22:48 CEST] <ChocolateArmpits> kerio, try out ffv1, it's a video format so might be easier to work with
[22:22:57 CEST] <slavanap> Now I got "Stream #0:0 -> #0:1 (aac (native) -> vorbis (libvorbis))", and -c:a copy doesn't work: https://paste.ubuntu.com/p/884bqvH48M/
[22:22:59 CEST] <kepstin> but yeah, i'd also recommend ffv1
[22:23:26 CEST] <kerio> i usually use ffvhuff for thermal data, which is a bit more similar to luminance
[22:23:31 CEST] <kerio> just because it's basically free
[22:23:35 CEST] <kerio> whereas ffv1 is quite slow
[22:24:29 CEST] <kepstin> slavanap: upgrade your ffmpeg. Newer versions should auto-insert the bsf needed to make that work
[22:27:15 CEST] <slavanap> Is there any official ppa for Ubuntu xenial with the latest ffmpeg version?
[22:27:27 CEST] <kepstin> hmm, though i thought the bsf was only needed when copying to mp4, not when copying from mp4
[22:29:19 CEST] <kepstin> there's no official ppas, but there's a fairly popular one with ffmpeg 3.4, which should be new enough to help with this.
[22:29:30 CEST] <slavanap> I thinks it's not bsf, ffmpeg can't write header with -c:a copy
[22:31:50 CEST] <slavanap> Hmm.. this seems pretty new : https://launchpad.net/ubuntu/+source/ffmpeg
[22:32:34 CEST] <slavanap> Just need to install package from bionic
[22:32:43 CEST] <kepstin> slavanap: that's not a ppa, that's just the page for ubuntu's regular ffmpeg package. If you upgrade from xenial to bionic, you'll get 3.4 :)
[22:32:59 CEST] <kepstin> I suspect you're gonna have to pull in a bunch of other packages too, not just ffmpeg.
[22:33:54 CEST] <slavanap> kepstin, always worked :D
[22:33:57 CEST] <kepstin> it might not be possible to install the bionic package, in the worst case (if it depends on a newer version of some core stuff)
[22:34:18 CEST] <kepstin> well, continue at your own risk :)
[22:34:59 CEST] <slavanap> not much, just got: ffmpeg fontconfig-config libc-bin libc-dev-bin libc6 libc6-dbg libc6-dev libegl1-mesa libfftw3-double3 libfontconfig1 libfontconfig1-dev libgbm1 libgnutls-openssl27 libgnutls30 libmp3lame0 libsdl2-2.0-0 libtasn1-6 libvorbis0a
[22:35:00 CEST] <slavanap>   libvorbisenc2 libwayland-egl1-mesa locales mpv
[22:35:45 CEST] <kepstin> lol, upgrading libc
[22:36:12 CEST] <kepstin> probably better to install bionic then switch to the bionic libc without anything else, imo :)
[22:36:32 CEST] <slavanap> I did this once with zetsy already. It's fine. And you can downgrade anytime
[22:37:49 CEST] <slavanap> YAY! It works now. Thanks!
[22:38:13 CEST] <slavanap> but output file is unplayable :D
[22:39:13 CEST] <slavanap> with Media Player Classic. VLC reads and plays it correctly
[22:41:30 CEST] <slavanap> Btw, is there any way to download video referenced by .m3u8 playlists with ffmpeg?
[22:42:43 CEST] <kepstin> slavanap: sure, ffmpeg can read hls as input and remux to a single local file.
[22:43:05 CEST] <slavanap> kepstin, so just -i http://to/.m3u8 ?
[22:43:09 CEST] <slavanap> Wow!
[22:43:09 CEST] <kepstin> slavanap: although depending on the video host, it's sometimes better to use youtube-dl instead.
[22:45:53 CEST] <slavanap> about libc, btw, I used to run xenial binaries on trusty. That works with trusty loader. I love Linux for this.
[22:46:31 CEST] <slavanap> *xenial loader
[22:49:18 CEST] <slavanap> moreover, ffmpeg static binary has output stability issues on different machines. I mean, you can't reproduce exact results with aac to wav conversion. But Ubuntu's avconv does not have such issues.
[22:54:53 CEST] <brimestone> hey guys is there a way to capture from an input source and record 60 sec chunk?
[22:56:14 CEST] <kepstin> brimestone: do you mean, create a series of files, each 60s long, as you continuously capture?
[22:56:27 CEST] <brimestone> @kepstin. yes
[22:57:09 CEST] <kepstin> brimestone: yes, using the 'segment' muxer. Note that you'll probably also have to also configure codec keyframe intervals and keyframe insertion settings to be compatible with your segment length.
[22:57:42 CEST] <brimestone> let me try that one. thanks
[23:21:09 CEST] <yaphes> I tried to record my screen and webcam by ffmpeg and I need to know the create time of this file. I was expecting the program will record down the timestamp in the metafile or somewhere so I used ffprobe to check the information
[23:22:02 CEST] <yaphes> But there is no create time block and if I use mediainfo to check the file, the encode time is UTC 1904-01-01 00:00:00, which I believe is a default time stamp.
[23:22:50 CEST] <yaphes> Can anyone tell me how to set this create time correctly? My goal is to extract the timestamp when the encoder created the first stamp.
[23:22:51 CEST] <BtbN> can always do something like -metadata date="$(date)"
[23:25:25 CEST] <yaphes> Is this metadata specify the create time of the file or the exact time of the first frame?
[23:26:54 CEST] <BtbN> it's specific to the moment date runs.
[23:27:35 CEST] <yaphes> then it should be the time when I run the ffmpeg command
[23:28:08 CEST] <BtbN> yes
[23:28:30 CEST] <yaphes> Is it possible to get the internal timecode of the moment the first frame being created?
[23:29:07 CEST] <yaphes> the timecode will be based on the local machine clock
[00:00:00 CEST] --- Wed Jun  6 2018