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

[burek]

[03:53:06 CET] <No0n3Left> I have a two versions of a video with different audio tracks, however, one has a thing at the begining making the whole thing a bit out of sync with the other. Is there a way to figure out the offset of the video in order to trim the audio so I can mux both audio tracks into one video track so it has two alternative audio tracks that are in sync with the video?
[05:16:12 CET] <cheapie> Is there a way to force ffmpeg to read _past_ the duration specified in a file's header? I have an IVF file here with broken metadata - it plays in VLC, but the total length is shown as 00:00. I'm trying to remux it into a new (MKV) container with ffmpeg, but ffmpeg quits as soon as it reaches the indicated length (of 0) and won't actually copy anything over.
[05:16:41 CET] <cheapie> This is the command I'm using and the output: https://pastebin.ubuntu.com/p/ZFZqGfBvpn/
[05:19:43 CET] <cheapie> I'm also uploading the file in question, but that will take a while since my connection is pretty bad.
[13:12:35 CET] <cocktail> What is the difference between `ffmpeg -i a.mkv -c copy -map 0:2 -map 0:1 b.mkv` and `ffmpeg -i a.mkv -map 0:2 -map 0:1 -c copy b.mkv`?
[13:12:56 CET] <cocktail> The outputs of both commands are not exactly the same.
[13:14:08 CET] <cocktail> Both commands are supposed to produce the same output.
[13:17:38 CET] <cocktail> Should -map come before `-c copy`?
[13:17:44 CET] <JEEB> the -c copy is after -i INPUT, and before the output name
[13:17:48 CET] <JEEB> so at that point it doesn't matter
[13:18:16 CET] <cocktail> Two commands produce slightly different outputs.
[13:18:43 CET] <cocktail> Two outputs differ in size by one byte.
[13:18:55 CET] <cocktail> One output is one byte larger than the other.
[13:18:57 CET] <JEEB> did you actually check with vbindiff or something?
[13:19:13 CET] <cocktail> No
[13:19:17 CET] <cocktail> But, the size differs.
[13:19:39 CET] <JEEB> please do check what the diff is first, and if there's more diff than that :P
[13:26:48 CET] <cocktail> JEEB: `ffmpeg -i a.mkv -c copy -map 0 test1.mkv` and `ffmpeg -i a.mkv -map 0 -c copy test2.mkv` don't produce the same file according to vbindiff although test1.mkv and test2.mkv are of the same size.
[13:27:08 CET] <cocktail> There are a few differences between two files.
[13:27:14 CET] <cocktail> Only a few
[13:27:23 CET] <cocktail> Probably timestamps
[13:28:09 CET] <cocktail> I'm not sure, yet.
[13:28:35 CET] <JEEB> post a bug on trac if it still happens on master
[13:29:15 CET] <JEEB> might be minor but it's still weird if ffmpeg.c's (the command line API client) does semi-random differences that are something else than "creation date and tiem"
[13:29:23 CET] <JEEB> beceuse those bytes you kind of expect to be updated
[13:34:06 CET] <cocktail> For mp3, there is no difference.
[13:34:18 CET] <cocktail> For mkv with multiple streams, there are 6 blobs of differences.
[13:34:21 CET] <cocktail> 6 short blobs
[13:34:40 CET] <cocktail> The mkv has 7 streams.
[13:35:40 CET] <cocktail> Probably, different metadata.
[13:38:08 CET] <cocktail> I'm going to need a sample mkv.
[13:42:19 CET] <JEEB> something like http://www.cccp-project.net/beta/test_files/renderer_test_with_bt709_and_subs.mkv ?
[13:47:47 CET] <cocktail> The same command produces a slightly different output, depending on when it is executed.
[13:48:29 CET] <cocktail> If I swap the position of `-c copy` and `-map 0`, I can locate differences in the same spots.
[13:53:02 CET] <cocktail> JEEB: If I executed `ffmpeg -i a.mkv -c copy -map 0 test1.mkv`, `ffmpeg -i a.mkv -c copy -map 0 test2.mkv`, and `ffmpeg -i a.mkv -map 0 -c copy test3.mkv`, then test1.mkv, test2.mkv, and test3.mkv all differ at the same locations.
[13:55:36 CET] <cocktail> I guess the order of -map and `-codec copy` doesn't really matter.
[13:55:46 CET] <JEEB> sounds more like it
[13:56:13 CET] <JEEB> since the options in theory get applied to all inputs/outputs that the apply to, and in theory their order should not matter
[13:56:16 CET] <JEEB> within those locations
[13:56:32 CET] <JEEB> as in, there's the input and the output paths
[13:56:53 CET] <JEEB> those are the things that make a difference regarding positioning
[13:57:04 CET] <JEEB> if it's before an input, that's decoding/reading options
[13:57:21 CET] <JEEB> if it's after an output, it's encoding/writing options for the output that is coming next
[13:57:28 CET] <JEEB> argh
[13:57:31 CET] <JEEB> after an input I mean
[14:01:34 CET] <cocktail> How does -map affect stream specifiers for -codec?
[14:01:57 CET] <cocktail> Are -codec stream specifiers affected by -map?
[14:02:05 CET] <cocktail> Are they not?
[14:02:21 CET] <cocktail> I don't know whether -map is applied before -codec.
[14:02:37 CET] <JEEB> codec is applied after streams have been picked
[14:02:40 CET] <JEEB> and map does that
[14:02:55 CET] <JEEB> and yes, order of -maps does indeed matter
[14:03:11 CET] <JEEB> -map 0:v -map 0:a versus -map 0:a -map 0:v
[14:03:24 CET] <cocktail> So, -map affects -codec stream specifiers even if -map comes after -codec.
[14:03:40 CET] <JEEB> yes
[14:03:58 CET] <JEEB> the order of maps within an output configuration does matter since they seem to get picked as they come
[14:03:59 CET] <cocktail> This is making my head spin.
[14:24:13 CET] <cocktail> Anyway, I learned a lot today.
[14:24:17 CET] <cocktail> Thanks.
[15:55:57 CET] <multi_io> is it possible at all to crop a video (e.g. remove a strip at the bottom) without reencoding?
[15:56:37 CET] <multi_io> I mean an mpeg video, ideally mpeg 1 through 4
[15:57:34 CET] <JEEB> some formats have cropping info that's used to crop from the closest mod16/64 spot to the resolution needed, but that's quite limited
[15:57:42 CET] <JEEB> so if you need more than that, you're SOL
[15:58:30 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#mpeg2_005fmetadata
[15:58:35 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#h264_005fmetadata
[15:58:39 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#hevc_005fmetadata
[15:58:45 CET] <JEEB> relevant bit stream filters for those cases
[16:30:05 CET] <kepstin> keep in mind that cropping via metadata doesn't actually remove anything from the image, someone could remove the cropping metadata and see the whole thing.
[16:54:16 CET] <multi_io> hm, ok
[16:56:08 CET] <multi_io> JEEB: kepstin: but actually removing the cropped-out parts without reencoding isn't possible ever?
[16:56:25 CET] <JEEB> yup
[16:57:09 CET] <JEEB> or well, I'm not 100% sure if you could modify specific macroblocks to just contain a very simple thing, but that's actually N times harder to create then re-encoding
[16:57:18 CET] <JEEB> and there's no pre-made tools for that stuff as far as I know
[16:57:30 CET] <JEEB> not to mention that if then a future frame uses that macroblock/CTU for prediction
[16:57:36 CET] <JEEB> then you suddenly break that too
[17:00:09 CET] <multi_io> yeah, I was thinking of cropping along those blocks
[17:00:30 CET] <multi_io> I know it works with JPEG (
[17:00:51 CET] <multi_io> (jpegtran can do this if I'm not totally mistaken)
[17:00:59 CET] <JEEB> JPEG is really quite a bit simpler
[17:38:58 CET] <kepstin> the main issue is that predicted frames might reference data in the cropped out part, i think
[17:39:20 CET] <kepstin> so yeah, you can do it with mjpeg and that's about it :)
[17:40:14 CET] <kepstin> modern codecs you wouldn't be able to crop stuff in the top/left even if it was I frames only, because of spatial prediction.
[17:40:34 CET] <JEEB> yup
[17:44:13 CET] <multi_io> ok thanks
[18:46:20 CET] <FishPencil> x264 and x265's -preset option is supposed to improve quality/bit. Is there an actual noticeable different between say normal and veryslow? There's certainly a noticeable speed difference.
[18:47:20 CET] <JEEB> depends. either do 2pass comparisons with the same target bit rate, or tweak the CRF value until you get the same file sizes for all encoders
[18:47:39 CET] <JEEB> and generally, test with bit rates where actual differences would be visible
[18:48:08 CET] <FishPencil> I'm using 24 crf with 1080p, so I'd assume that isn't in the noticable range?
[18:48:20 CET] <FishPencil> (x265)
[18:49:25 CET] <JEEB> I don't even remember what CRF I last used with x265
[18:49:35 CET] <JEEB> also x264 while named similar and have similar features like CRF and presets and tunes
[18:49:38 CET] <FishPencil> Defaults to 28
[18:49:39 CET] <JEEB> *x265
[18:49:46 CET] <JEEB> is quite internally different to x264
[18:49:58 CET] <JEEB> so parallels can't be really struck as easily regarding various things
[18:50:00 CET] <FishPencil> I'd assume as much with a different spec
[18:50:24 CET] <JEEB> but yea, regarding the tests it really doesn't matter as long as you utilize a similar way of getting the result
[18:50:37 CET] <JEEB> and that f.ex. you compare the encodes with the same file size in all cases
[18:50:41 CET] <FishPencil> Is it safe to assume presets mean less the higher the bitrate/lower the crf?
[18:51:01 CET] <JEEB> presets are orthogonal to rate control
[18:51:12 CET] <JEEB> preset controls how much time the encoder uses for compression
[18:51:24 CET] <JEEB> rate control controls the usage of bits
[18:53:41 CET] <FishPencil> Are you aware of any existing studies on how the different presets effect visual quality?
[18:54:10 CET] <JEEB> only for the slower presets for x264 I think
[18:55:05 CET] <FishPencil> FFmpeg's wiki says that the visual quality will be the same regardless of the preset:
[18:55:09 CET] <FishPencil> https://trac.ffmpeg.org/wiki/Encode/H.265
[18:55:32 CET] <FishPencil> I thought the whole point of presets was specifically to control the quality of the encode
[18:55:55 CET] <JEEB> yea, that's not exactly correct. what's probably meant is that it's separate from rate control
[18:56:07 CET] <furq> if it actually works the same way as x264 then that's wrong, yeah
[18:56:31 CET] <JEEB> because if you're bit rate starved and you encode with a slower preset with the same resulting bit rate - your result will be of course better
[18:56:42 CET] <JEEB> or at least, if it's not then something's badly wrong
[18:57:08 CET] <JEEB> because slower presets are supposed to enable more features and more techniques to squeeze more juice out of the encode
[18:59:18 CET] <FishPencil> I might run some psnr tests to see how it effects purely on a metric standpoint. At this point I have no idea if the diff between medium and slow is massive
[18:59:45 CET] <JEEB> PSNR/SSIM need their respective tunes to be enabled for the comparison to be valid
[18:59:54 CET] <FishPencil> right
[19:00:07 CET] <JEEB> because metrics do not equate to visual quality so when you optimize for metrics you disable some psychovisual optimizations
[19:00:25 CET] <JEEB> otherwise the metric can go down but your result looks better :P
[19:01:42 CET] <FishPencil> They don't equate, but their whole point is to give an idea right?
[19:01:52 CET] <FishPencil> They must serve some purpose...
[19:02:10 CET] <JEEB> just use the matching tune to your metric when encoding is the bottom line
[19:02:32 CET] <JEEB> there's one for psnr and one for ssim in both x264 and x265 if I recall correctly
[19:04:24 CET] <FishPencil> Maybe it'd just be better if I did some visual comparisons...
[19:32:33 CET] <FishPencil> What's considered the "go to" test media to use? Big Buck Bunny?
[19:33:29 CET] <JEEB> derf's collection has various nice stuff https://media.xiph.org/video/derf/
[19:33:52 CET] <JEEB> tears of steel I'd probably use instead of BBB
[19:34:13 CET] <JEEB> or some of the Swedish TV's 12 or so year old 4K film samples
[19:34:21 CET] <JEEB> that stuff is still some of the best 4K content freely available
[19:34:48 CET] <JEEB> SVT_MultiFormat is the keyword for the swedish things
[19:35:54 CET] <durandal_1707> FishPencil: anime pr0n
[19:39:05 CET] <pagios> hi all, does anyone recommend a reliable ip camera with built in microphone to use for livestreaming conferences? I would like it to be a wireless ip camera that can stream using rtsp with audio and video. something like mevo but more flexible
[21:26:02 CET] <nitroxis> When streaming real-time video of the internet, is there any way to tell ffmpeg to drop frames if the upload is stalling/too slow? In my current setup, ffmpeg will keep buffering, probably until it hits a buffer size limit or until the RAM is full. This leads to more and more latency on the receiving end
[21:26:10 CET] <nitroxis> over the internet*
[21:27:10 CET] <JEEB> you'd probably want to implement that with your own API client
[21:27:41 CET] <nitroxis> Ideally, it would detect that it has X unsent frames and drop input frames until the frames are sent
[21:27:45 CET] <JEEB> since most likely if you knowingly drop stuff you probably want to reconfigure the encoder to output a random access point :P
[21:27:57 CET] <JEEB> oh, dropping on input?
[21:27:59 CET] <nitroxis> Well, I'm using the ffmpeg cli tool at the moment
[21:28:15 CET] <JEEB> yes, everyone is and at some point you're going to notice it's trying to be a generic tool
[21:28:29 CET] <JEEB> and then my recommendation would be to move to making your own API client
[21:28:57 CET] <JEEB> personally I'd probably want to separate live and non-live use case API clients
[21:29:05 CET] <nitroxis> I know, just thought that maybe it has such an option that I'm unaware of before I'm trying to build my own tool
[21:29:07 CET] <JEEB> ffmpeg.c right now is trying to serve so many things at once :P
[22:58:54 CET] <multi_io> is there an input option or filter to cut multiple chunks out of the input? I only found -t / -ss for cutting at the beginning/end.
[23:00:24 CET] <multi_io> would you use -ss/-t multiple times to create a separate stream for each contiguous segment and then concatenate them again?
[23:06:32 CET] <multi_io> looks like using the trim filter multiple times should work
[00:00:00 CET] --- Sun Dec  2 2018