Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

June 2018

1 participants
60 discussions

ffmpeg-devel.log.20180609
by burek 10 Jun '18

10 Jun '18

[00:00:50 CEST] <atomnuker> does anyone actually implement that? I thought subs in teletext was the state of the art nowadays [00:00:57 CEST] <JEEB> oh they do [00:01:26 CEST] <JEEB> there are some media serving things that take in live subtitles as TTML in MP4 or ISMV (lol) [00:01:49 CEST] <JEEB> while I just prefer having webvtt files linked somewhere for them subtitles [00:22:10 CEST] <January> atomnuker: 'subs in teletext' I'm having flashbacks... [00:22:30 CEST] <JEEB> that's normal, teletext subtitle pages [00:22:44 CEST] <January> 'normal' [00:22:51 CEST] <JEEB> for EU broadcast yes [00:23:00 CEST] <JEEB> for JP you have ARIB STD-B24 captions [00:23:14 CEST] <JEEB> for US/Korea/few others you have CEA-608/708 captions [00:23:26 CEST] <JEEB> (last of which is in the darn video track) [00:24:22 CEST] <January> I'm so happy I rarely deal with broadcast [00:28:10 CEST] <atomnuker> I had to implement the australian version which was just the ETSI version (or maybe it was the other way around) [00:28:31 CEST] <JEEB> ETSI is basically the DVB variant [00:28:38 CEST] <JEEB> so EU-based [00:30:30 CEST] <atomnuker> right, I never had to deal with non-dvb stuff [00:33:45 CEST] <atomnuker> huh, I wonder why south america which was pal switched to isdb [00:34:06 CEST] <JEEB> they will still be pushing out 50Hz I think [00:34:10 CEST] <atomnuker> at least I'm glad pal and (me)secam countries switched to dvb [00:34:21 CEST] <JEEB> it's mostly the ISDB transmission stuff I think [00:34:34 CEST] <JEEB> and ARIB EPG etc is pretty much what DVB does [00:35:17 CEST] <JEEB> there's some almost-like-HTML multimedia bollocks and proper styled captions support, but I'm not sure if those countries will even use that [00:35:32 CEST] <JEEB> because what they basically decided upon is just the radio part of ISDB [00:35:41 CEST] <atomnuker> does it already have javascript support so you can make it flash? [00:36:04 CEST] <JEEB> I don't think so, but I'm pretty sure you can make it flash in other ways [00:36:05 CEST] <JEEB> lol [00:36:53 CEST] <atomnuker> I bet there's someone somewhere in a dark basement with no windows who's working on adding java applet support in subtitles [00:41:46 CEST] <nevcairiel> the blu-ray java menu stuff is largely derived from some dvb java specs, i always wondered where those got used [01:04:49 CEST] <jamrial_> jkqxz: ping [01:49:58 CEST] <jdarnley> https://tweakers.net/aanbod/1634409/24-core-xeon-e5-v4-256gb-ecc-met-dual-1… [01:50:22 CEST] <jdarnley> I wonder if I could persuade anyone to buy me a ridiculously OP server. [01:54:14 CEST] <jamrial_> jdarnley: that's old by now [01:56:56 CEST] <jdarnley> Newer than everything else in my house [01:57:44 CEST] <nevcairiel> yeah thats broadwell, not even avx512! [01:58:07 CEST] <jdarnley> Oh wait. I guess I do have a Skylake sitting next to me but since it is a laptop it doesn't really count. [02:10:38 CEST] <January> nevcairiel: do we have anything notable using avx512 yet? [02:11:09 CEST] <jdarnley> I don't think there's any thing using it in ffmpeg [02:11:24 CEST] <jdarnley> x264 can though [02:12:49 CEST] <January> nice. I recently got a 4k UHD monitor, still waiting on a cable to actually use the HDR. What can I even do with it? When I get the cable I wanna test a bunch of stuff [02:14:00 CEST] <January> even without HDR it's a massive improvement, my previous monitor was horribly broken and displayed terribly bad washed out colours. Being able to actually see the difference between lossless and lossy content is always a plus... [02:16:31 CEST] <atomnuker> you formulated that as if with hdr it would be an improvement [02:19:13 CEST] <January> atomnuker: well I did assume there would be an improvement with HDR [02:21:42 CEST] <January> atomnuker: you dont seem to agree? [02:23:44 CEST] <atomnuker> not really, considering its supposed to make your eyes respond as if the brightness transitions are real [02:24:03 CEST] <atomnuker> so you're meant to be blinded if the video goes dim->bright->dim [02:24:35 CEST] <atomnuker> so you need a tone mapping algorithm anyway to reduce the deltas that studios overuse because its still a fad [02:24:48 CEST] <atomnuker> tbh I'd much rather prefer an oled display [02:25:04 CEST] <atomnuker> something where the darks are as dark as possible [02:40:22 CEST] <nevcairiel> oleds are only really worth it if you have a pitch black viewing room [02:40:48 CEST] <nevcairiel> otherwise the black advantage isnt really worth much [02:43:55 CEST] <atomnuker> the sun's annoying, nights are for working through [02:47:22 CEST] <nevcairiel> PC monitors in OLED will likely never happen though [02:47:30 CEST] <nevcairiel> they cant solve the image retention issues [02:47:48 CEST] <nevcairiel> maybe in micro-led [02:48:19 CEST] <atomnuker> you mean ghosting? its non-permanent, isn't it? [02:48:34 CEST] <atomnuker> *burn-in [02:49:12 CEST] <nevcairiel> not sure if its permanent-permanent, but its definitely visible for a while, and PCs often have a lot of static content on screens [02:49:18 CEST] <atomnuker> ghosting's not too bad as long as it quickly disappears and the refresh rate is high [02:50:29 CEST] <January> I have a BenQ EW3270U, I'm actually not sure how it compares to other UHD monitors though. What do you guys have? [09:10:55 CEST] <cone-107> ffmpeg 03Gyan Doshi 07master:7b80df677aa8: doc/filters: change subtitles example to hint at correct color syntax [20:58:54 CEST] <cone-510> ffmpeg 03Jacob Trimble 07master:cf81a9c07891: avformat/mov: Fix reading saio/saiz for clear content. [21:35:00 CEST] <cone-510> ffmpeg 03Carl Eugen Hoyos 07master:5686c4489a01: ffmpeg: Fail if the user requested impossible subtitle encoding. [00:00:00 CEST] --- Sun Jun 10 2018

1 0

ffmpeg.log.20180609
by burek 10 Jun '18

10 Jun '18

[01:40:05 CEST] <wfbarksdale> does av_seek_frame handle making sure that, in the case of video and audio, that both streams can be decoded successfully from the resulting seek point? or do you need to do two seeks and check the resulting file position and use the earliest seek result?... it looks like avformat_seek_file handles this, but the API is still under construction [01:55:57 CEST] <wfbarksdale> also, i'm actually not finding any way to check the position of the AVFormatContext when demuxing [06:39:36 CEST] <scientes> is the DTS decoder multi-threaded [06:40:34 CEST] <scientes> (ac3) [06:44:50 CEST] <scientes> i've had problem with skipping on a h.264/5.1 video even with video off on vlc [06:55:28 CEST] <atomnuker> no, it isn't [06:56:58 CEST] <scientes> not even for differnt channels [06:57:06 CEST] <scientes> 5.1 [06:57:30 CEST] <atomnuker> no [06:57:35 CEST] <reepca> not sure where else to ask this, but I'm trying to use ffmpeg to take a picture with my webcam. However I have to have it running for over 2 seconds or the resulting image is very dark. I'd like to figure out a way to make that a one-time on-startup delay for an interactive application that uses ffmpeg. That is, I want to interactively specify to a running ffmpeg when frames should be captured and written. Or, alternatively, find a way [06:57:35 CEST] <reepca> to keep the camera "running", if that makes any sense, between invocations of ffmpeg. Any advice? [09:21:51 CEST] <cryptopsy> how do i losslessly trim? this was my command ffmpeg -i "${1}" -ab 320k -ac 2 -ar 48000 -ss "${3}" -t "${4}" -strict -2 "${2}" [10:05:24 CEST] <Mavrik> cryptopsy, -codec copy instead of ab, ac, ar [10:05:35 CEST] <Mavrik> That skips encode and just copies part of the stream [10:09:41 CEST] <cryptopsy> have to reboot, brb [11:28:42 CEST] <jpeg> I am trying to overlay an input with an alpha channel webm, by using the libvpx-vp9 encoding, it works fine, if I use a command I found through google, but not if I add filters/music to it (it overlays the webm with black background instead of transparency), here's both commands and the link mentioned: https://pastebin.com/ra0hCGGx what am I doing wrong or what flag am I missing? [11:32:04 CEST] <ChocolateArmpits> jpeg, try converting the jpg to a pixel format that has alpha channel support before directing it to overlay [11:32:28 CEST] <ChocolateArmpits> it may be that overlay takes the pixel format of the first input and uses that for output [11:32:57 CEST] <jpeg> I'll try to google that up, don't quite know how I would do that to be honest, thanks :) [11:34:53 CEST] <BtbN> jpg doesn't have transparency. Converting it to a format with alpha channel will only give you something fully intransparent as well [11:35:58 CEST] <jpeg> oh wait so I just need to convert it to png, now I get it, sorry makes sense, let's try that [11:36:12 CEST] <BtbN> that makes no sense, no. [11:36:26 CEST] <BtbN> There won't suddenly information show up which parts are meant to be transparent [11:37:14 CEST] <ChocolateArmpits> BtbN, well if he's scaling the webm and the jpg is smaller than that and the webm is transparent then the resultant image should have some transparency [11:37:32 CEST] <ChocolateArmpits> provided everything works, though it doesn't right now [11:37:49 CEST] <jpeg> I mean if I convert the input file to a png first and overlay that with the webm, then it should work as much as I understood, worth a test anyway [11:38:03 CEST] <ChocolateArmpits> then make sure the png has alpha as well [11:38:23 CEST] <ChocolateArmpits> doesn't matter if it's fully opaque [11:50:10 CEST] <jpeg> doesn't seem to work by using a png with alpha channel [11:50:21 CEST] <jpeg> sorry that it took so long, literally rendering on a potato [11:51:14 CEST] <jpeg> I feel it has something to do with some missing flag I am not setting or a flag I -am- setting, causing the issue, but I can't figure out what it is from the docs or googling [12:04:08 CEST] <furq> jpeg: i take it background.webm and background.jpg are fully opaque and you just want the transparent video overlaid on top [12:04:17 CEST] <jpeg> yes [12:04:22 CEST] <furq> weird [12:04:26 CEST] <furq> i don't see anything in there that wouldn't work [12:04:57 CEST] <furq> other than vp9 in mp4, which probably isn't what you want [12:05:01 CEST] <furq> that wouldn't cause the problem though [12:05:42 CEST] <jpeg> just tried setting pix_fmt to yuv420p which iirc does have transparency channel and it still overlay the transparent webm with black background [12:09:00 CEST] <jpeg> just to clarify, maybe I have stated something wrong before: I have a background image (tried both jpg and png) and I want to overlay a webm that has an alpha channel (a text that just fades in and out) [12:13:18 CEST] <BtbN> yuv420p does not have transparency [12:13:20 CEST] <BtbN> yuva does [12:15:39 CEST] <furq> scale shouldn't change the format anyway [12:17:21 CEST] <jpeg> BtbN just "yuva"? [12:17:27 CEST] <furq> yuva420p [12:17:32 CEST] <furq> don't set that as your output format though [12:17:59 CEST] <furq> maybe try format=yuva420p,scale=1920:1080 [12:18:02 CEST] <furq> or the other way round [12:18:07 CEST] <furq> it shouldn't be necessary though [12:18:40 CEST] <jpeg> ok will try [12:19:05 CEST] <jpeg> would it help btw if I'd pastebin the console output? [12:19:28 CEST] <furq> it couldn't hurt [12:20:09 CEST] <furq> also for debugging you probably want to use something other than vp9 [12:20:29 CEST] <jpeg> ok here it is for the current command: https://pastebin.com/sGsT5SLD [12:20:30 CEST] <furq> if the output after overlay is supposed to be fully opaque then it's not the encoder that's to blame [12:20:50 CEST] <furq> oh what [12:21:06 CEST] <furq> yuv420p with "alpha_mode=1" [12:22:00 CEST] <furq> maybe you do need to explicitly set yuva420p then [12:22:00 CEST] <jpeg> is that a clue to the issue? [12:22:24 CEST] <jpeg> well I did set the format and rendering rn, let's see [12:22:39 CEST] <furq> like i said, try encoding to something faster than vp9 for debugging [12:22:49 CEST] <jpeg> what would that be? [12:22:59 CEST] <furq> -c:v libx264 -preset ultrafast [12:23:25 CEST] <jpeg> ok let me do that [12:24:17 CEST] <jpeg> yeah seems to be faster, thanks, let's see once it finishes [12:26:37 CEST] <jpeg> still black background [12:28:47 CEST] <andoru> hello everyone [12:29:02 CEST] <andoru> does anyone know how to efficiently encode a still image video with VP9? [12:29:35 CEST] <andoru> basically it's an hour-long video file that only has the first frame repeated until the video ends (duration set with avisynth) [12:30:33 CEST] <andoru> I've tried to encode it with this command line: ffmpeg.exe -i "test.avs" -c:v libvpx-vp9 -lossless 1 output.webm [12:30:52 CEST] <andoru> it gave me a 60MB video file, and it was a bit slow [12:31:09 CEST] <andoru> while it's a decent result, I was wondering if it would be possible to do better? [12:31:22 CEST] <BtbN> set a super low framerate [12:31:42 CEST] <andoru> I did, the script is set to output 1FPS [12:31:54 CEST] <jpeg> furq I'll try to encode again with vp9 just in case [12:32:08 CEST] <BtbN> was more thinking like 1/length [12:32:33 CEST] <andoru> I don't quite follow [12:33:44 CEST] <andoru> you mean 0.1FPS? [12:35:19 CEST] <jpeg> furq nope with vp9 and format=yuva420p it's still adding the black background to the transparent webm [12:37:01 CEST] <andoru> what I was looking for were some encoder switches that would tell it to encode the first frame as lossless, while the subsequent frames would be empty copies of the first frame [12:37:43 CEST] <andoru> I was able to achieve this by setting the keyint in h264 to infinite, but I'm not aware of such a setting in VP9 [12:38:16 CEST] <furq> andoru: -g [12:38:23 CEST] <furq> that will obviously prevent you from seeking though [12:38:40 CEST] <andoru> oh, that's a no-no :/ [12:38:53 CEST] <furq> i mean infinite keyint in x264 would do the same thing [12:39:16 CEST] <furq> seeking will still sort of work in some players but it'll be really slow [12:39:17 CEST] <andoru> I was able to seek the h264 video (although slowly) [12:39:28 CEST] <andoru> yeah, then I'll try that [12:39:30 CEST] <furq> but some players will refuse to seek to anything other than an IDR frame [12:39:34 CEST] <andoru> thanks! [12:39:38 CEST] <furq> or whatever they call it in vp9 [12:46:28 CEST] <andoru> okay, I've added -g -1, also tried -g 9999 and -g 0, but all don't seem to help :/ [12:49:08 CEST] <jpeg> the googled command seems to work even if I apply it to an image: https://pastebin.com/JdwBeNUS I don't understand what the most recent command https://pastebin.com/wEa0QWEm does wrong, so that the webm has black background instead of transparency [12:49:31 CEST] <jpeg> is there anything else I could try that maybe would make it work? [12:50:21 CEST] <andoru> ah, nevermind [12:50:40 CEST] <andoru> I forgot I've set -crf 1 instead of -lossless 1 on my subsequent trials [12:51:19 CEST] <andoru> it works now with this command: ffmpeg.exe -i "test.avs" -c:v libvpx-vp9 -g 9999 -lossless 1 output.webm [12:51:28 CEST] <andoru> thank you for the help furq [15:15:13 CEST] <RedSoxFan07> Is it possible to keep PGS subtitles and also convert them to SSA and SRT? How? [15:16:11 CEST] <RedSoxFan07> Like this? -c:s copy -c:s ssa -c:s srt [15:16:45 CEST] <JEEB> it's not possible [15:16:51 CEST] <JEEB> PGS is picture based [15:17:02 CEST] <JEEB> you need to OCR it to get text out of it [15:17:04 CEST] <furq> you would normally be able to map the stream twice and -c:s:0 copy -c:s:1 srt [15:17:19 CEST] <furq> but yeah, you can't automatically convert image subs to text with ffmpeg [15:17:31 CEST] <JEEB> there's a filter for OCR, but unfortunately it doesn't return the text in a way that you can then utilize to make subtitle packets out of it [15:18:10 CEST] <furq> there are plenty of good OCR tools out there anyway [15:18:20 CEST] <furq> and once you've done that you can mux the srt back in and have both [15:20:13 CEST] <JEEB> yea, for a static piece of video there's plenty of tools [15:20:15 CEST] <JEEB> like subtitle edit [15:20:31 CEST] <JEEB> you have some cases where you'd want to take in broadcast picture subtitles [15:20:34 CEST] <JEEB> and OCR them into text [15:36:13 CEST] <johnch> Hi! Does ffmpeg run Ok on the Raspberry Pi? I notice varios plugins in the Pi repo but not ffmpeg itself. Will I have to compile from source? [15:38:48 CEST] <JEEB> FFmpeg can utilize the hw decoding stuff on the rpi, but if you're planning to do anything on the CPU that's not just churning out audio it's going to a road to pain [15:39:14 CEST] <JEEB> as in, FFmpeg will run on the rpi (Both armv7 and aarch64) [15:39:30 CEST] <JEEB> but it's more the utter slowness of the rpi platform that generally gets you limited [15:42:19 CEST] <johnch> JEEB: this is what I was worried about, spending a lot of time and effort only to get slow and laggy output. I have an audio stream set up in Icecast. Was thinking of adding video. [15:43:14 CEST] <JEEB> I think the rpi might have a hw decoder and encoder for H.264 (not 100% sure of the latter), but you can almost certainly give up on anything software based on that thing [15:43:59 CEST] <JEEB> and the hw encoder I'm not sure how well it does its bandwidth limiting so I'm not really sure how well it's suited for streaming. also the compression capabilities of a hw encoder are generally aimed towards low latency and speed, not compression ratios [15:44:37 CEST] <JEEB> so if you are thinking of actually doing the A/V coding on the rpi... [15:44:58 CEST] <JEEB> that has to be a really minimal thing, not sure if you'd even get scaling in there [15:45:17 CEST] <JEEB> since you'd have to make sure that you can decode the input with hw decoding chip, then just throw that into the hw encoder [15:45:34 CEST] <JEEB> at which point you might also think about just copying the source bit stream of video into the output as-is [15:48:36 CEST] <johnch> JEEB: yes, I think you are right about the H.264, but considering all other factors you mention trying to run video seems pretty marginal at best. [15:49:20 CEST] <johnch> JEEB: was thinking just streaming a single camera feed, but that might be to say, half a dozen clients. Sound like it would not cope anyway. [15:49:41 CEST] <johnch> JEEB: will probably just stick to providing the audio streams. [15:49:55 CEST] <johnch> JEEB: thanks for responding to my question. [15:50:42 CEST] <JEEB> the camera might either output its own crappy H.264 stream, or give you raw frames. although given how everything on the rpi is on the USB thing, I don't think raw video input is a good idea... [15:52:34 CEST] <johnch> JEEB: the cam I was going to experiment with (the only one I have) is a Sony Playstation Eyetoy. Most likely RAW video I would think, so I guess that puts paid to that idea..... [15:52:57 CEST] <JEEB> johnch: oh that thing. the ps2 one? I happen to still probably have one of those somwhere [15:53:13 CEST] <JEEB> those frames would be minimal I think, you could try plugging it to a linux VM and see what it exports [15:53:15 CEST] <johnch> JEEB: yes, the ps2 one. [15:53:34 CEST] <JEEB> I think it worked under linux surprisingly enough since it was some rebranded logitech thing [15:54:01 CEST] <JEEB> and then if it could output 4:2:0 YCbCr you could in theory output that to the hw encoder [15:54:12 CEST] <JEEB> (not 4:2:2 since that's not supported by almost any HW) [15:54:41 CEST] <JEEB> or you could maybe get JPEG from the camera [15:54:43 CEST] <johnch> JEEB: yes, works on my MINT setup just fine. Not sure how to check what it puts out though. [15:54:44 CEST] <JEEB> which is crappy [15:54:51 CEST] <JEEB> but at least wouldn't use CPU? [15:55:00 CEST] <JEEB> and you could pass that on as-is [15:59:31 CEST] <johnch> JEEB: I have it on VLC. Just trying to figure out if there is any info about what VLC is receiving from it [15:59:56 CEST] <JEEB> it's probably exported as a v4l2 device [16:00:11 CEST] <JEEB> so there should be some tools to check what it can output etc [16:01:53 CEST] <johnch> JEEB: found it. You are quite right, its a v4l2 device, motion jpeg video, 640x480, 4:2:2 YUV. Not sure what YUV means though. [16:03:02 CEST] <JEEB> YUV is a misnomer for YCbCr in digital space [16:03:12 CEST] <JEEB> (although FFmpeg also calls it so :)) [16:03:20 CEST] <JEEB> but yes, it's MJPEG [16:03:22 CEST] <JEEB> not raw video [16:03:44 CEST] <JEEB> so I would give up re-encoding that but rather would just pass those images through [16:03:55 CEST] <JEEB> I think the frame rate depended on the resolution and lighting [16:07:26 CEST] <johnch> JEEB: makes sens just to pass that through. Keeps overhead to a minimum, which as you say is essential here. I will perhaps experiment a bit. [16:07:42 CEST] <johnch> JEEB: does ffmpeg come in a deb package? [16:08:49 CEST] <johnch> JEEB: for ARM that is. I can see there is Debian which I assume is for Intel [16:09:37 CEST] <JEEB> it's most certainly buildable but no idea how old it is [16:10:39 CEST] <johnch> JEEB: ok, looks like I will have to build it then. Was hoping not to clutter the pi with dev tools... [16:11:08 CEST] <JEEB> then just look up how to cross compile with your rpi sysroot [16:11:29 CEST] <JEEB> it will also go much faster then [16:12:50 CEST] <johnch> JEEB: no idea what a rpi sysroot is, so just researching that and how to cross compile. never done that before. Thanks for your help. [16:13:41 CEST] <JEEB> sysroot can just be your / on rpi [16:13:54 CEST] <JEEB> which you can put somewhere on your system [16:14:10 CEST] <JEEB> there is some debian tools for getting it from the debian repos too [16:15:21 CEST] <johnch> JEEB: thnx. Just reading up on it. [16:28:43 CEST] <furq> does ffmpeg support the mmal mjpeg decoder yet [16:29:19 CEST] <furq> johnch: on a recent debian-ish os you should just need crossbuild-essential-armhf [16:30:08 CEST] <furq> and then just copy /opt/vc4 off your pi and pass that to --extra-cflags for mmal and omx [16:48:55 CEST] <debianuser> Hello. Short question. https://ffmpeg.org/ffmpeg.html mentions `-stdin` to "enable interaction on standard input" and `-nostdin` to disable those interactive commands. But where can I find a list of those interactive commands? [16:49:57 CEST] <furq> press ? while it's running [16:53:30 CEST] <debianuser> furq: Thank you! [17:02:47 CEST] <jpeg> furq would you have any other ideas on what I could try to maybe make the webm overlay to be transparent? I googled since we last tried and none of the solutions seemed to work, so I hoped you'd maybe know something else [17:06:31 CEST] <furq> i couldn't really suggest anything other than making sure you're on a recent ffmpeg [17:06:38 CEST] <furq> like i said, the same workflow seems to work fine here [17:08:38 CEST] <jpeg> I pulled the newest ffmpeg there is, guess it's just something strange happening [17:09:50 CEST] <furq> it's weird that scale breaks it but overlay doesn't [17:11:57 CEST] <jpeg> is it scale that breaks it though? [17:12:00 CEST] <jpeg> let me remove that and see [17:12:14 CEST] <furq> you're not adding anything else that would break it [17:16:05 CEST] <furq> oh wtf [17:16:13 CEST] <jpeg> removing it - it still breaks [17:16:16 CEST] <furq> apparently you need -c:v libvpx before -i or else the decoder doesn't handle transparency [17:16:29 CEST] <jpeg> oh seriously? lol [17:16:29 CEST] <furq> that's...dumb [17:16:38 CEST] <jpeg> where did you get that from, I went throughout the whole internet it feels [17:16:41 CEST] <jpeg> lets test [17:16:44 CEST] <jpeg> sounds promising [17:16:56 CEST] <furq> i saw it a few minutes ago on SO and assumed it was old news [17:17:00 CEST] <furq> since the post was two years old [17:17:05 CEST] <furq> but i just tried it out and it works [17:18:06 CEST] <jpeg> could you link me that page just so I could bookmark it for later use too? [17:18:21 CEST] <furq> https://video.stackexchange.com/a/19226 [17:18:47 CEST] <jpeg> thanks! rendering rn hopefully it works [17:18:58 CEST] <furq> yeah i remembered after seeing it that you had it in your first command [17:19:59 CEST] <furq> it obviously specifically goes before -i foo.webm [17:20:08 CEST] <furq> so if your image is first then it's after that [17:20:30 CEST] <jpeg> you're truly amazing! [17:20:32 CEST] <jpeg> it works holy shit [17:20:35 CEST] <jpeg> thank you so much [17:20:36 CEST] <furq> nice [17:21:35 CEST] <JEEB> yea I think the separate alpha plane is the only thing not supported by the lavc decoder for vp8/9? [17:21:52 CEST] <jpeg> not sure what that means [17:22:10 CEST] <furq> well apparently it works, you just need to explicitly flag the decoder [17:22:25 CEST] <furq> oh hang on [17:22:28 CEST] <JEEB> if you need to force libvpx it uses the libvpx lavc wrapper :P [17:22:29 CEST] <furq> ffvp8 is the default decoder isn't it [17:22:32 CEST] <JEEB> yes [17:22:34 CEST] <furq> yeah i just realised why that's not dumb [17:23:39 CEST] <jpeg> oh so it defaults to the wrong decoder if not specified? [17:24:00 CEST] <JEEB> not wrong, but one that doesn't specifically support the complteely separate alpha feature [17:24:16 CEST] <furq> is there any other way of doing alpha [17:24:49 CEST] <furq> outputting yuva420p with ffmpeg seems to give the same thing [17:25:04 CEST] <jpeg> so whats better livpx or yuva? [17:25:23 CEST] <furq> they're not the same thing [17:25:58 CEST] <JEEB> furq: the decoder most certainly doesn't support the alpha-in-there pix_fmt it seems tho? http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp8.c;h=62b9f8bc2… [17:25:59 CEST] <jpeg> only weird thing is that it doesn't fully fade out as in the webm [17:26:06 CEST] <jpeg> it gets stuck on ~10% visibility and stays on top [17:26:32 CEST] <furq> JEEB: the decoder doesn't [17:26:55 CEST] <furq> i mean that encoding yuva420p with libvpx with ffmpeg gives a file that ffprobe reports as yuv420p, alpha_mode 1 [17:27:08 CEST] <JEEB> uh-huh [17:27:10 CEST] <furq> which i assume means it has a separate alpha plane [17:27:11 CEST] <JEEB> probably a profile string [17:27:13 CEST] <JEEB> yes [17:27:27 CEST] <JEEB> VPx has a history with alpha planes [17:27:35 CEST] <JEEB> I wonder if it uses the same way as VP5/6 before [17:27:39 CEST] <furq> is that the only way of doing it with vpx [17:27:52 CEST] <JEEB> if you actually need an alpha plane, yes [17:27:55 CEST] <furq> right [17:28:02 CEST] <furq> ok this all makes more sense then [17:28:44 CEST] <jpeg> I wonder does the loop apply to the overlay too? maybe that's why it stays "fixed" at that one point, instead of fully playing it [17:28:48 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp6.c;h=645fc5c69… [17:28:58 CEST] <JEEB> I wonder if you could see if it's the same way as in VP6? [17:29:07 CEST] <JEEB> that seems to have some flag for has_alpha and open another decoder [17:29:35 CEST] <JEEB> so if someone cares enough it could be implemented (and with libvpx I guess you have reference code) [17:30:17 CEST] <JEEB> but with vp6 it literally looks like the alpha plane is being fed to a completely separate vp6 decoder [17:30:20 CEST] <JEEB> lol [17:30:58 CEST] <furq> oh yeah [17:31:15 CEST] <furq> JEEB: idk if you saw it but some guy was complaining that channelcount isn't set correctly in mp4s that don't have stereo audio [17:31:24 CEST] <furq> which doesn't break anything but mediainfo shows the wrong value [17:31:29 CEST] <furq> on the off chance you think that's worth fixing [17:31:31 CEST] <jpeg> fixed that issue, thank you so much again guys! [17:32:49 CEST] <JEEB> furq: can't quickly say off hand if it's what the spec notes or not [17:33:00 CEST] <furq> yeah i noticed l-smash does the same thing [17:34:04 CEST] <furq> there is a separate channelconfiguration tag which is set correctly [19:49:24 CEST] <foop> How can I insert an audio delay at a specific time in a video (not throughout the whole video)? The audio is in sync up until a certain time, where it suddenly becomes several seconds out of sync [19:56:05 CEST] <BtbN> split it, apply fix to broken part, re-combine [19:57:35 CEST] <ChocolateArmpits> it should be possible to adjust timestamps via asetpts and an expression that would increment timestamps after a certain timestamp [19:59:27 CEST] <BtbN> that forces you to re-encode the whole thing though, and is probably more work to figure out [20:03:03 CEST] <ChocolateArmpits> well using ffmpeg for this rather than let's say audacity is already amore work [20:03:08 CEST] <ChocolateArmpits> more* [20:25:20 CEST] <foop> thanks, I went with the splitting approach [20:56:42 CEST] <heliumclicks> Hey all, I'm trying to digitize some old tapes using an easycap device. It "works" but I find that the audio becomes more out of sync over time. The videos can be pretty long (2hrs+) so recording everything raw isn't really an option. https://pastebin.com/mTiAdPqB [21:10:04 CEST] <ChocolateArmpits> heliumclicks, what are the input formats? [21:12:50 CEST] <ariyasu> you could do the audio raw while encoding the video [21:13:17 CEST] <heliumclicks> How do I determine the input formats? It's coming from a v4l2 device [21:13:23 CEST] <ariyasu> depending on your hardware you could probable do -preset slow and a lower crf in realtime also [21:13:30 CEST] <heliumclicks> ariyasu... hmmm good point. I'll test that maybe [21:13:36 CEST] <furq> please don't put h264 in avi [21:13:37 CEST] <heliumclicks> i have pretty good hardware [21:13:56 CEST] <ChocolateArmpits> heliumclicks, well ffmpeg lists the format of the input, say framerate, audio rate, resolution [21:14:10 CEST] <furq> you could probably do lossless if this is just vhs [21:14:18 CEST] <furq> ffv1 and flac should compress pretty well [21:14:37 CEST] <furq> and also yes please don't use avi or mp3 in general in 2018 [21:14:43 CEST] <heliumclicks> I'm down to try whatever [21:14:47 CEST] <furq> but especially not with h264 [21:15:04 CEST] <heliumclicks> Essentially what happened is i started with vlc, but it did a pretty terrible job with lots of stuttering and clicking [21:15:25 CEST] <heliumclicks> i started working on an ffmpeg command line and hours later i just googled until i found someone trying to do something similar using a similar device [21:15:31 CEST] <heliumclicks> i imagine that person was as ignorant as i am [21:16:00 CEST] <furq> yeah 99% of ffmpeg command lines on the web are wrong in some way [21:16:10 CEST] <furq> and 90% are wrong in many ways [21:16:33 CEST] <heliumclicks> but i have 5600 bogomips per bitflipper so I think it should be able to stream video in 480p. [21:17:42 CEST] <furq> http://vpaste.net/FurMK [21:17:43 CEST] <furq> try that [21:18:40 CEST] <heliumclicks> Sure... let's see what we get. [21:18:42 CEST] <furq> that's lossless so it'll be a lot bigger, but still much smaller than rawvideo/pcm [21:18:50 CEST] <ChocolateArmpits> furq, that feels like it'll eat 100gigs for 2 hours lol [21:18:55 CEST] <furq> not for sd [21:18:58 CEST] <heliumclicks> Need to let it run for a minute or two to see if the audio goes out of sync [21:19:39 CEST] <furq> actually maybe it will lol [21:20:11 CEST] <ChocolateArmpits> furq, depends on the input pixel format [21:20:27 CEST] <furq> well raw yuv420p would be about 111GB [21:20:34 CEST] <ChocolateArmpits> ANd uncompressed 2 hours of yuv444 or rgb would be around 180gigs [21:20:36 CEST] <furq> i'd expect about half that for ffv1 [21:20:44 CEST] <ChocolateArmpits> heh you're making calculations as well [21:20:48 CEST] <furq> i sure am [21:21:16 CEST] <heliumclicks> i have about 60G free right now, plenty to test with [21:22:01 CEST] <ChocolateArmpits> the drift should be apparent with one hour of recording [21:23:21 CEST] <csierra_> I'm trying to extract a frame that is 1 pixel wide. In debian and Ubuntu, it comes out fine. In windows, the whole frame has a green tint. If I change the frame to 2 pixels, the green tint goes away. I'm using nightly version N-91254-g2bd26dea66 but it happened with the stable version as well. Any idea what could be causing it? [21:23:56 CEST] <heliumclicks> I get spurts of "Past duration 0.999.... too long" sometimes [21:24:07 CEST] <heliumclicks> er... too large [21:24:34 CEST] <ChocolateArmpits> something isn't keeping up [21:25:18 CEST] <heliumclicks> seems to work though [21:25:21 CEST] <heliumclicks> at least so far [21:25:38 CEST] <furq> what bitrate is it reporting [21:25:53 CEST] <heliumclicks> no this is great so far [21:26:21 CEST] <heliumclicks> around 36700 [21:26:25 CEST] <csierra_> https://paste.debian.net/hidden/912292c6/ is my output [21:26:32 CEST] <furq> that should easily fit in 60G then [21:26:41 CEST] <heliumclicks> climbing though... [21:26:43 CEST] <heliumclicks> at 38 now [21:26:53 CEST] <furq> anything under 60000 or so should be fine [21:28:10 CEST] <heliumclicks> yeah that little bit was 1.4G [21:28:57 CEST] <furq> i mean you don't have to go lossless, i was just pointing out that there are much smaller ways of doing it than rawvideo [21:29:12 CEST] <furq> if you're not planning on doing further processing then it's a bit of a waste [21:30:12 CEST] <heliumclicks> the audio is pretty awful quality as it is [21:30:30 CEST] <heliumclicks> lossless does not seem very worth it unless that's the only way to keep things in sync [21:30:49 CEST] <heliumclicks> i can batch process afterwards i guess [21:31:01 CEST] <furq> it won't make any difference at all to that [21:31:05 CEST] <ChocolateArmpits> well if lossless doesn't work, then you'll have to stretch the audio afterwards [21:31:23 CEST] <furq> if you're having audio issues then it makes sense to use flac audio, yeah [21:31:26 CEST] <furq> so you don't have to encode twice [21:32:00 CEST] <ChocolateArmpits> it's also possible to use the atempo filter if you know by how much the audio starts drifting after some time and if it's consistent [21:32:05 CEST] <furq> but yeah if you capture the video lossy then at least use -crf 18 and probably -preset slower [21:32:27 CEST] <furq> and also bear in mind you might need to deinterlace it if your capture device doesn't take care of that for you [21:32:32 CEST] <heliumclicks> ChocolateArmpits: it doesn't seem consistent [21:32:36 CEST] <furq> and crop out head switching noise etc [21:32:58 CEST] <heliumclicks> i don't know what you're referring to [21:33:08 CEST] <heliumclicks> BUT, based on the sample i just made, i think this is ok [21:33:37 CEST] <heliumclicks> ffmpeg can output to more than one stream at a time right? is there a good way to monitor what it's recording? [21:34:06 CEST] <ChocolateArmpits> heliumclicks, well it may not seem consistent at different times, bu the value by which the audio gets out of sync over time may be consistent, say 10 samples every minute or something of that nature [21:34:11 CEST] <heliumclicks> my plan was just to wait a few seconds and then start playing the file with ffmplay. the delay is fine, i don't need realtime [21:34:25 CEST] <heliumclicks> ChocolateArmpits: that's possible, but I don't have a good way to test it [21:35:20 CEST] <ChocolateArmpits> Why not stretch the audio using tempo filter so the end frames match to the video, then look at the rest of the video ? [21:35:35 CEST] <ChocolateArmpits> just to confirm [21:37:51 CEST] <ChocolateArmpits> As for audio quality of the tape itself, if your deck supports stereo/hifi audio try turning that on, audio quality is usually significantly better, provided the audio was recorded to those tracks properly [21:38:58 CEST] <ChocolateArmpits> otherwise it plays standard audio that's recorded on another physical track in a more plain way [21:49:05 CEST] <heliumclicks> interesting... i tried "ffmpeg -i test.mkv test.webm" on that lossless test file i just made and it's going at about 0.22x. To me that implies that it couldn't have kept up with the stream if i had tried to encode on the fly. Is that a reasonable conclusion or is there some other cause for it to be this slow? [21:49:30 CEST] <furq> the reason is that the default encoder for webm is libvpx and libvpx is slower than shit [21:49:41 CEST] <furq> especially for sd [21:49:45 CEST] <heliumclicks> aha [21:49:53 CEST] <furq> x264 is orders of magnitude quicker [21:50:19 CEST] <heliumclicks> shitty test then.. what do you suggest? Filesize matters so I can't leave it lossless. I need to send this out to family members eventually [21:50:31 CEST] <furq> just use x264 and aac in mkv [21:50:34 CEST] <heliumclicks> also they will expect to be able to play it without installing ffmpeg :) [21:50:47 CEST] <furq> like i said, you'll want to filter up front if you're encoding lossy to avoid generation loss [21:50:51 CEST] <furq> so any deinterlacing or cropping [21:50:56 CEST] <stockstandard> Hey everyone - I'm pulling ffmpeg into a DockerFile, but am referencing a specific version in the pull so every now and then when I go to refresh the docker container, the script breaks because the version that is referenced is not the latest... Could someone please advise on how I can update this 2 liner? [21:50:57 CEST] <stockstandard> https://pastebin.com/ExKpNsv5 [21:51:39 CEST] <furq> x264 and aac in mp4 is ideal for compatibility, but the issue with mp4 is that if the capture stops halfway through you'll be left with an unplayable file [21:51:53 CEST] <furq> so ideally you want to capture to mkv and then remux to mp4 when t's done [21:53:08 CEST] <heliumclicks> i see [21:53:43 CEST] <heliumclicks> any particular options you would suggest for producing a non-shitty x264+aac in mkv? [21:54:00 CEST] <heliumclicks> also thanks for your help so fra [21:54:04 CEST] <heliumclicks> far*, rather [21:54:11 CEST] <furq> -crf 18 -preset slower [21:54:40 CEST] <furq> try slow or medium if slower is too slow [21:55:00 CEST] <furq> aac should be fine at default settings [22:00:42 CEST] <heliumclicks> furq, ffmpeg -i test.mkv -c:a aac -c:v libx264 -crf 18 -preset slower compressed.mkv [22:00:50 CEST] <heliumclicks> so that, more or less? [22:01:02 CEST] <furq> sure [22:01:12 CEST] <furq> assuming you're happy with the cropping and interlacing [22:02:42 CEST] <heliumclicks> I'm still not sure what you mean by that. When i look at the output it seems fine? Is there something I am not noticing? [22:03:11 CEST] <furq> if you have black bars around the sides or switching noise at the bottom then you probably want to crop that out [22:03:35 CEST] <furq> and if you have sawtooth artifacts then you need to deinterlace [22:03:44 CEST] <furq> but your capture device might be doing that for you [22:04:02 CEST] <heliumclicks> cropping is fine, deinterlace looks like maybe i do have [22:04:11 CEST] <heliumclicks> yes definitely [22:04:17 CEST] <furq> add -vf bwdif=1 [22:05:14 CEST] <heliumclicks> testing [22:07:19 CEST] <heliumclicks> still hovering around 0.5x, even with -preset slow. I'm surprised [22:07:31 CEST] <JEEB> yea, x264 nowadays with modern CPUs is fast [22:07:42 CEST] <heliumclicks> i guess transcoding is slower than i remember [22:07:44 CEST] <furq> well 0.5x is no good for capturing so i assume that's slow [22:07:46 CEST] <JEEB> generally if you have a bottleneck it's somewhere else [22:08:33 CEST] <heliumclicks> I'm on a core i7 6600U @ 2.8GHz, so I suspect that's not it [22:08:44 CEST] <JEEB> but basically you can see if the results improve by fastening the preset [22:08:52 CEST] <JEEB> if it doesn't then it's something else [22:08:56 CEST] <heliumclicks> indeed [22:09:10 CEST] <furq> yeah i'm surprised 480p30 would be less than realtime on that [22:09:14 CEST] <heliumclicks> slower and slow seem to be both going at around 0.4x [22:09:25 CEST] <JEEB> if it does then x264 at that specific point (given nothing else changes) was your bottleneck [22:09:59 CEST] <furq> i guess that is a 15W CPU [22:10:18 CEST] <heliumclicks> it's a low power cpu yeah, lenovo x1 carbon [22:10:27 CEST] <heliumclicks> so this deinterlacing thing... [22:10:33 CEST] <heliumclicks> not a success, i would say [22:10:49 CEST] <heliumclicks> any lateral motion turns everything into wavy squiggles [22:11:07 CEST] <furq> maybe try bwdif=1:0 or 1:! [22:11:09 CEST] <furq> 1:1 [22:11:31 CEST] <furq> if it had artifacts before and bwdif is making it worse then it might be misdetecting the field order [22:12:02 CEST] <furq> also -preset fast should still be ok at crf 18 [22:12:35 CEST] <furq> you can generally compensate for using a faster preset by dropping the crf a bit [22:12:42 CEST] <heliumclicks> https://imgur.com/IOjP8eJ [22:12:43 CEST] <furq> obviously the filesize will duffer [22:12:57 CEST] <ChocolateArmpits> i'd only deinterlace SD stuff with QTGMC if intended for archival and you want to deinterlace [22:13:03 CEST] <furq> oof [22:13:12 CEST] <furq> that looks like your capture device is upscaling [22:13:22 CEST] <furq> in which case a regular deinterlacer isn't going to work well [22:13:28 CEST] <heliumclicks> hmm [22:13:58 CEST] <furq> maybe just leave that off then [22:17:47 CEST] <heliumclicks> you know what i think it is [22:18:08 CEST] <heliumclicks> this easycap thing is probably upscaling to PAL, but the input is ntsc [22:18:36 CEST] <heliumclicks> video was recorded in bolivia which uses ntsc... but this easycap dongle thing undoubtedly came from china and does who knows what [22:18:56 CEST] <furq> oh yeah that's 576p [22:19:01 CEST] <furq> that's probably not ideal then lol [22:19:01 CEST] <heliumclicks> yes [22:19:09 CEST] <heliumclicks> No it would seem not :D [22:19:13 CEST] <heliumclicks> but it's what we have [22:21:14 CEST] <furq> well yeah i guess just don't deinterlace it [22:21:19 CEST] <furq> but also don't throw away those tapes [23:07:30 CEST] <heliumclicks> furq: we'll keep the tapes, but they are 20+ years old at this point and already barely usable. A few of them broke as soon as they started to play :( [23:22:58 CEST] <ChocolateArmpits> They must've been kept in pretty harsh comditions if they are breaking like that [00:00:00 CEST] --- Sun Jun 10 2018

1 0

ffmpeg-devel.log.20180608
by burek 09 Jun '18

09 Jun '18

[01:32:24 CEST] <cone-822> ffmpeg 03Zhong Li 07master:550372d0c436: MAINTAINERS: add myself to qsv section [02:28:14 CEST] <jamrial> jkqxz: nice [02:28:51 CEST] <jamrial> i guess there's nothing useful that could be done for a jpeg metadata bsf? [02:29:22 CEST] <jkqxz> You could do some exif stuff if you wanted. [02:32:16 CEST] <jkqxz> But that's pretty complex and better delegated to other libraries. [03:32:39 CEST] <atomnuker> I wish there was a jpeg rotate bsf, but that would require almost fully decoding the image [03:46:35 CEST] <nevcairiel> didnt jpeg have this lossless easy rotation thing [03:50:23 CEST] <atomnuker> yeah, to do that you need to decode all coefficients, transpose them, rearrange the blocks, redo dc-prediction and reencode the image [08:48:41 CEST] <atomnuker> jkqxz: you should probably know kmsgrab works on a raspberry pi 3 (aarch64), with no screen attached [14:08:33 CEST] <durandal_1707> atomnuker: why are you so slow developer? [14:12:10 CEST] <atomnuker> hey, I've just got my motivation back to work on ffv2 again, so that's what I've been doing for the last few days [14:13:49 CEST] <durandal_1707> atomnuker: i see you have really serious problems - not completing anything, starting everything [14:14:58 CEST] <atomnuker> its a ton of work to complete something that will work as expected and not have any bugs at all, you know? [14:17:23 CEST] <durandal_1707> atomnuker: you will never finish atrac9 that way [14:18:46 CEST] <atomnuker> I'll finish it, just need a bit more time [14:29:30 CEST] <kierank> atomnuker: is this the same ffv2 as pengvado's? [14:36:47 CEST] <atomnuker> no, its different, its subtitle might as well be "I can't believe its not Daala!" [14:37:55 CEST] <atomnuker> it uses the untrimmed daala ec system, the daala transforms, the overlap filter as well [14:38:53 CEST] <atomnuker> but I've extended the lap filter to work with 64-point segments, the block splitting code to allow for arbitary rectangular splitting [14:40:21 CEST] <atomnuker> its still pretty much all rewritten, no code directly used from daala [14:41:21 CEST] <atomnuker> it does beat jpeg currently without any prediction at all, just using the lap filter and the same quantization as vc2 [14:43:19 CEST] <atomnuker> btw has anyone heard from pengvado in the last 3 years? [14:44:41 CEST] <JEEB> he has popped up every now and then [14:45:22 CEST] <atomnuker> my logs only go back 2 years, but I'm pretty sure I've never seen him since I've been around here [14:46:11 CEST] <January> I've only ever seen them in old x264 logs [14:48:01 CEST] <atomnuker> I've heard he's a millionare, you know, and he lives off of baked beans and doesn't have an aquapark [15:18:35 CEST] <atomnuker> kierank: btw iter has a livestream you can watch construction with - https://www.iter.org/news [15:18:47 CEST] <kierank> what happened to gagandeep [15:19:19 CEST] <kierank> atomnuker: being in france i assume they are striking [15:21:32 CEST] <atomnuker> no, they're working day and often at night [15:22:46 CEST] <atomnuker> (probably the japanese, they have a deal where they gave up their bid for location in return for more people involved in construction) [15:23:21 CEST] <atomnuker> kierank: was that ganesh? [15:23:27 CEST] <kierank> no [15:23:30 CEST] <kierank> gagandeep is my gsoc student [15:27:49 CEST] <cone-598> ffmpeg 03Sergey Lavrushkin 07master:d29c35b4d8f1: libavfilter/vf_srcnn.c: adds DNN module backend AVOption, changes AV_LOG_INFO message to AV_LOG_VERBOSE. [15:27:49 CEST] <cone-598> ffmpeg 03Sergey Lavrushkin 07master:648361c2faf3: libavfilter/dnn_interface.c: fix av_freep dnn_module. [21:14:41 CEST] <cone-598> ffmpeg 03Gyan Doshi 07master:9c12938ec504: ffmpeg: mark sseof as an input-only option [23:45:50 CEST] <cone-598> ffmpeg 03Marton Balint 07master:183db8a80bba: avformat/mxfdec: use MXFCodecUL struct to store essence description for data_essence_container_uls [23:45:51 CEST] <cone-598> ffmpeg 03Marton Balint 07master:f9e77586cb75: avformat/mxfdec: recognize SMPTE 436 VBI data [23:45:51 CEST] <cone-598> ffmpeg 03Marton Balint 07master:5d3f78383e0e: avformat/mxfdec: only disallow seek on metadata streams [23:45:53 CEST] <cone-598> ffmpeg 03Marton Balint 07master:d48fb904fa81: avformat/mxfdec: remove check for NULL MXFTrack in mxf_set_pts [23:45:53 CEST] <cone-598> ffmpeg 03Marton Balint 07master:d070d6f69df7: avcodec/avcodec.h: add AV_CODEC_ID_TTML [23:45:54 CEST] <cone-598> ffmpeg 03Marton Balint 07master:2bd26dea6636: avformat/mxfdec: add support for recognizing timed text streams [23:53:26 CEST] <JEEB> woah, I almost had a heart attack when I saw AV_CODEC_ID_TTML [23:57:22 CEST] <atomnuker> why? [23:57:55 CEST] <JEEB> I've got bad memories with it [23:58:26 CEST] <JEEB> (also the pants-on-head level TTML in MP4 spec) [00:00:00 CEST] --- Sat Jun 9 2018

1 0

ffmpeg.log.20180608
by burek 09 Jun '18

09 Jun '18

[01:03:38 CEST] <YaMoonSun> Hey there; I'm trying to clip a segment from a video and the output seems to have a second or two more audio than it does video. Why is that? [03:40:06 CEST] <Woodpecker> Does ffmpeg have any mimetypes associated with it? Just making a script to use with concat, and I am pretty ocd with this sort of thing. [03:59:28 CEST] <kepstin> Woodpecker: ffmpeg doesn't really use mime types at all, its format autodetection is based on filenames and probing content only [03:59:58 CEST] <kepstin> many formats it can read have mime types assigned, of course. [04:01:59 CEST] <atomnuker> actually it does use mime type for probing [04:04:55 CEST] <kepstin> i suppose if you your source is e.g. http [04:05:05 CEST] <kepstin> or if you're writing a custom app that provides it via the api [04:05:54 CEST] <Woodpecker> kepstin: okay. I am just going to write .ffmpeg ;p [04:07:32 CEST] <kepstin> if you're using mime types to set up file associations for something that simply runs ffmpeg internally, just look up mime types for all the containers you care about and add them :/ [05:15:03 CEST] <nickd1239012> newbie here - can anyone help me figure out how to extract a scte 35 message from a stream ? [05:33:11 CEST] <nickd1239012> anyone? [06:00:01 CEST] <nickd1239012> newbie here - can anyone help me figure out how to extract a scte 35 message from a stream ? [09:13:11 CEST] <crigges> Hello, Iam currently trying to build FFmpeg with openh264 under windows using msvc by following this guide https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC The build without openh264 already works fine, however for me it's not 100% clear where exactly I can link external libraries explained in this part: [09:13:21 CEST] <crigges> "In order to build FFmpeg with support to external libraries, you need to make sure that the libraries and headers are placed in a location specified by the INCLUDE and LIB directories referenced by the VC compiler and linker." [11:39:28 CEST] <vishal733> testing.. [11:41:04 CEST] <vishal733> Hello. I notice an issue when I try to create short samples of a large video using ffmpeg. The number of audio channels in container of output video always seems to be 2 (where-as originally audio channels could be mono, 2, 5.1, 7.1). It this a bug, or am I missing some parameter in my ffmpeg command.. [11:41:09 CEST] <vishal733> Here's the command I use: [11:41:26 CEST] <vishal733> ffmpeg -ss 40 -i in.mp4 -t 125 -vcodec copy -acodec copy -map 0 -avoid_negative_ts 1 out.mpr [11:41:34 CEST] <vishal733> ffmpeg -ss 40 -i in.mp4 -t 125 -vcodec copy -acodec copy -map 0 -avoid_negative_ts 1 out.mp4 [11:42:28 CEST] <vishal733> And here's the output of mediainfo on out.mp4 (Audio Channels=2, AudioChannels_Orig=1).. here in.mp4 is a mono audio channel video [11:42:30 CEST] <vishal733> https://pastebin.com/86CULNMS [11:42:58 CEST] <vishal733> ffmpeg version: 4.0 [11:52:02 CEST] <durandal_1707> vishal733: give info about in.mp4 [11:54:22 CEST] <vishal733> sure [11:55:07 CEST] <vishal733> #durandal_1707: mediainfo details for input video: https://pastebin.com/HeJKaFiT [11:57:50 CEST] <Zexaron> visha1773: it could be, but why not just force the channels then to make it workaround [12:00:43 CEST] <Zexaron> with the ac command [12:01:55 CEST] <Zexaron> but I would have to check logs again about more details regarding sorround mixing, been some time we had a big discussion of that here, but probably might not be necessary for your case [12:04:49 CEST] <vishal733> #Zexarom: sure. I guess forcing the output channel should work for me.. (at least for mono) [12:05:07 CEST] <vishal733> in case of 5.1 audios.. I will have to figure out if it's possible to force audio channels simply like that [12:05:17 CEST] <vishal733> in any case, I guess this is a bug, and should be resolved.. [12:05:47 CEST] <vishal733> and I have noticed this bug across multiple videos.. when cropping segments from videos with diff. num of channels [12:05:55 CEST] <vishal733> thanks. didn't know about the ac command earlier [12:07:45 CEST] <vishal733> So even this command doesn't solve it for me: ffmpeg -ss 40 -i in.mp4 -t 125 -vcodec copy -acodec copy -ac 1 out.mp4 [12:08:37 CEST] <vishal733> nor this: ffmpeg -ss 40 -i in.mp4 -t 125 -vcodec copy -ac 1 out.mp4 (audio being re-encoded here) [12:10:41 CEST] <vishal733> nor this: ffmpeg -ss 40 -i in.mp4 -t 125 -ac 1 out.mp4 (both audio and video being re-encoded here) [12:24:37 CEST] <Zexaron> visha1773: if you don't specify -ac, the default is 2, stereo, so that's maybe overriding things, may not be a bug [12:25:13 CEST] <Zexaron> however, if you use copy, then that should override the default, so maybe you're right [12:26:19 CEST] <furq> uh [12:26:28 CEST] <furq> channel count should absolutely not be touched if you're copying the audio [12:26:36 CEST] <furq> are you sure it's mapping the correct stream [12:28:01 CEST] <vishal733> I can share the video with you guys.. [12:28:29 CEST] <vishal733> I already shared the command I've used. along with mediainfo for input, and output.. [12:29:00 CEST] <Zexaron> probably not going to make a difference unless is some kind of a weird corrupt file [12:29:04 CEST] <vishal733> furq: Regarding this "are you sure it's mapping the correct stream".. how can I be confirm your ponit? [12:29:36 CEST] <furq> nvm i didn't see the mediainfo of the input [12:29:49 CEST] <furq> the mediainfo of the output looks pretty suspect though [12:29:49 CEST] <vishal733> Zexaron: I don't think there's anything wrong with this file [12:30:23 CEST] <vishal733> furq: tell me more.. what's odd about the output mediainfo? [12:30:42 CEST] <furq> 2 channels, but channel positions: front C [12:30:54 CEST] <furq> one of those must be wrong [12:31:06 CEST] <furq> what does ffprobe -show_streams say [12:31:07 CEST] <vishal733> yes. and there's also a field Channels_Original, which is one [12:31:32 CEST] <vishal733> I read about this on mediainfo wiki. So number of channels info is contained both in container, and via raw stream [12:31:36 CEST] <Zexaron> why don't you try using ffprobe --analyzeduration 99999 -probesize 999999 filepath to get more accurate details , mediainfo can't always be trusted [12:31:43 CEST] <vishal733> so AudioChannels is what is value stored in container [12:31:46 CEST] <furq> afaik ffmpeg will only ever automatically up/downmix if the encoder doesn't support the requested layout [12:31:50 CEST] <Zexaron> and the show_streams ofcourse [12:31:57 CEST] <vishal733> but actual raw stream contains one channel (as denoted by Channels_Original) [12:32:04 CEST] <vishal733> sure [12:32:06 CEST] <vishal733> will try [12:32:07 CEST] <furq> and aac definitely supports mono and 5.1 [12:33:02 CEST] <furq> nvm i just tested it [12:33:22 CEST] <furq> i would probably call that a mediainfo bug [12:33:55 CEST] <vishal733> so with ffprobe it does say mono [12:33:59 CEST] <vishal733> let me fetch the details.. [12:34:17 CEST] <vishal733> I think it could still be a bug with ffmpeg. It writing a different audio channels at container level [12:34:19 CEST] <furq> don't bother, you can do it synthetically [12:34:36 CEST] <furq> ffmpeg -f lavfi -i testsrc=d=1 -f lavfi -i sine=d=1 test.mp4 [12:34:42 CEST] <furq> gives the same issue with mediainfo [12:35:28 CEST] <vishal733> you should read this: https://sourceforge.net/p/mediainfo/feature-requests/413/ [12:36:32 CEST] <vishal733> anyways. my application can handle the difference b/w AudioChannels, and AudioChannels_orig.. I use AudioChannels_original whenever available. [12:36:47 CEST] <furq> i tested with a different mp4 muxer and i still get the same issue with mediainfo [12:36:51 CEST] <furq> so i'm calling that their bug [12:37:02 CEST] <vishal733> ok! [12:37:23 CEST] <vishal733> I tried encoding using Adobe Media Encoder. and mediainfo returned values correctly. [12:37:26 CEST] <vishal733> anyways.. [12:37:30 CEST] <furq> weird [12:38:34 CEST] <vishal733> You can readup even this thread: https://sourceforge.net/p/mediainfo/discussion/297610/thread/79c07d9a/ [12:38:44 CEST] <vishal733> anyways. could be mediainfo bug. but I would doubt that.. [12:39:16 CEST] <furq> the first reply in that thread is pretty much what i was thinking [12:39:25 CEST] <vishal733> and if possible for you guys to specifically figure out information about AudioChannels in container, v/s in actual raw stream. that might make us extra sure where the bug lies [12:39:34 CEST] <furq> i guess lavf/lsmash are just not setting a field in the metadata [12:39:42 CEST] <vishal733> I see [12:40:21 CEST] <vishal733> you suspect they are not setting a field in metadata, or filling it wrongly instead? [12:41:00 CEST] <furq> probably just not setting it at all [12:41:09 CEST] <vishal733> ok.. [12:41:18 CEST] <furq> idk though i'm not an isobmff guru [12:41:48 CEST] <vishal733> and it's not even possible for me get into these details right now. Occupied with my daily work! [12:42:07 CEST] <furq> yeah if channels_original is always present then you should use that anyway [12:42:25 CEST] <vishal733> yes. and that works.. [12:42:27 CEST] <furq> apparently everything else just looks at the bitstream [12:42:35 CEST] <vishal733> I just thought I'd inform the ffmpeg community about this bug though [14:10:03 CEST] <defanor> i've noticed rather strange ffmpeg/ffplay behaviour with some streams: `ffplay <rtsp stream url>` fails with UDP timeout, retries with TCP, and hangs on that (-loglevel debug shows just "hello state=0"), while `ffplay -rtsp_flags prefer_tcp <same url>` works. it's possible that something is wrong with those streams, but is/was there a known bug like that, or some hints on how to investigate it? [14:10:36 CEST] <defanor> -rtsp_flags prefer_tcp seems to work for me as a workaround, just curious now [16:26:17 CEST] <if_gaga1> hello guys, can i send some commads, like zoom, unzom to ffmpeg while he running and streaming rtsp video? smth like ffmpeg fifo control socket? [16:30:18 CEST] <furq> if_gaga1: https://ffmpeg.org/ffmpeg-filters.html#zmq_002c-azmq [16:31:27 CEST] <if_gaga1> furq: thnx, yep i know about filters, can i apply some filter/send remote command to ALREADY running ffmpeg? [16:31:27 CEST] <furq> you might also be able to wire up sendcmd/asendcmd to a fifo, i've never tried [16:31:38 CEST] <furq> and yes that's specifically what zmq does [16:32:47 CEST] <if_gaga1> oh shi~, thanks furq, looks like that what i'm looking for [17:10:10 CEST] <waterworks> I'm trying to build ffmpeg with nvenc support but it complains it can't find ffnvcodec when it's listed in pkg-config --list-all. https://pastebin.com/DezFQtAb nvenc test is passed at line 14137. MSYS2 VS2017 [18:50:13 CEST] <analogical> hi is it possible to flip a video 90 degrees with ffmpeg without re-encoding the file?? [18:53:05 CEST] <analogical> flip -> rotate [18:57:04 CEST] <ariyasu> no [18:57:19 CEST] <ariyasu> using transpose will re-encode the video [19:01:17 CEST] <furq> analogical: you can set the rotate metadata [19:01:24 CEST] <furq> -metadata:s:v:0 rotate=90 [19:01:38 CEST] <furq> or rotate=0 if this is a phone video that's already been rotated [19:36:42 CEST] <analogical> furq, could you put that into context please? [19:44:14 CEST] <furq> mp4 (and maybe some other formats) has a rotation flag in the metadata [19:44:22 CEST] <furq> if it's set then players will rotate it on playback [19:44:56 CEST] <furq> if your file doesn't have it set then -i foo.mp4 -map 0 -c copy -metadata:s:v:0 rotate=90 bar.mp4 [19:46:04 CEST] <furq> but normally when people ask this, they've recorded something on a phone and it's not the orientation they expect, in which case the flag might already be set [19:46:27 CEST] <analogical> I would be nice to understand what all those settings do [19:47:39 CEST] <Mavrik> It's worth noting that a sizable chunk of players ignore that flag and you get video wrongly rotated anyway. [19:48:07 CEST] <analogical> I tried this ffmpeg -i input.mp4 -c copy -metadata:s:v:0 rotate=90 output.mp4 and it worked [19:49:31 CEST] <analogical> what does :s:v:0 mean? [19:51:33 CEST] <JEEB> steam, video, nr0 [20:25:14 CEST] <romano2k> hello! i'd like to change the framerate of a video from 23,976 fps to 30 fps without resampling it, so that 1 frame from the original would remain 1 frame into the output. how is this operation called? how can i do it with ffmpeg? [20:25:54 CEST] <Mavrik> You probably need to fix timestamps using setpts [20:26:04 CEST] <Mavrik> That is setpts video filter [20:26:18 CEST] <Mavrik> Of course that will desync your audio [20:26:53 CEST] <BtbN> so you want to speed it up? [20:27:20 CEST] <romano2k> BtbN: yes it'll be quicker [20:27:34 CEST] <BtbN> setpts should be able to do that [20:27:35 CEST] <romano2k> Mavrik: may i do this without transcoding? [20:27:52 CEST] <BtbN> I don't think you can, with ffmpeg.c at least [20:28:05 CEST] <romano2k> https://ffmpeg.org/ffmpeg-filters.html#setpts_002c-asetpts i'm not sure how to use this [20:28:13 CEST] <furq> don't use filters for that [20:28:23 CEST] <furq> romano2k: what container and codec is it [20:28:28 CEST] <BtbN> you could re-mux to raw h264, and then re-remux that to your container, with your desired rate [20:28:44 CEST] <BtbN> any audio will be messed up then though [20:28:45 CEST] <furq> chances are mkvmerge or l-smash will do it [20:28:50 CEST] <Mavrik> Hm, yeah, using container tools would probably be better than ffmpeg [20:28:59 CEST] <furq> and also yeah you'll need to reencode the audio [20:29:00 CEST] <romano2k> furq: the source is this Vimeo video grabbed using youtube-dl in MP4 with H264 : https://vimeo.com/241838243 [20:29:04 CEST] <furq> right [20:29:16 CEST] <furq> l-smash or mkvmerge will both deal with that [20:29:16 CEST] <romano2k> i don't need the audio [20:29:19 CEST] <furq> ok good [20:29:32 CEST] <furq> do you care if it's in mp4 [20:29:37 CEST] <romano2k> not really [20:29:48 CEST] <furq> even better [20:29:54 CEST] <romano2k> in the end i'd like to cut some parts with Final Cut Pro X, but i can handle this [20:30:22 CEST] <furq> mkvmerge -o out.mp4 --default-duration $idx:30fps --fix-bitstream-timing-information $idx:1 in.mp4 [20:30:26 CEST] <romano2k> so i need to demux to a raw h264 stream, then remux specifying the rate i want? [20:30:49 CEST] <Mavrik> Do what furq tells you with mkvmerge directly on mp4 :) [20:30:56 CEST] <romano2k> yes i'll try right away [20:31:15 CEST] <romano2k> can you explain what the options do? specifically the $idx:1 part? [20:31:21 CEST] <furq> change $idx to the index of your video stream [20:31:24 CEST] <furq> which is most likely 0 [20:31:55 CEST] <furq> and uh [20:31:58 CEST] <furq> -o out.mkv obviously [20:32:41 CEST] <furq> for reference, if you happen to have l-smash available, muxer -i in.mp4?fps=30 -o out.mp4 [20:34:25 CEST] <romano2k> i'm using macOS with brew.sh, which has mkvtoolnix but not l-smash, so i'll stick to mkvmerge for now [20:34:38 CEST] <romano2k> is there an official website in something else than japanese for l-smash? [20:35:19 CEST] <furq> https://github.com/l-smash/l-smash [20:35:29 CEST] <furq> there's no real english docs other than what's in --help [20:36:05 CEST] <romano2k> and not even a README.md on the github, that's a shame :-/ i'll have a look anyway [20:36:07 CEST] <furq> i assume mp4box can do it as well but people in here yell at me whenever i mention mp4box [20:36:49 CEST] <furq> l-smash is easy enough to build though [20:37:56 CEST] <romano2k> what is its purpose anyway? :) [20:38:10 CEST] <romano2k> your mkvmerge command worked, thank you for that [20:38:24 CEST] <furq> it's just a bunch of mp4-related tools [20:39:34 CEST] <romano2k> actually the mkvmerge process went fine, but Final Cut Pro says that it's not able to import it. it doesn't know the file duration. any quick fix? (something related to headers maybe?) [20:39:42 CEST] <furq> does fcp support mkv [20:39:48 CEST] <romano2k> no it doesn't [20:39:57 CEST] <furq> you should be able to remux it to mp4 with ffmpeg now [20:40:21 CEST] <romano2k> i found it strange that we muxed to mp4 with mkvmerge ;-) [20:40:27 CEST] <furq> oh right [20:40:32 CEST] <furq> yeah that was a typo, it was muxing to mkv [20:40:42 CEST] <romano2k> got it, thanks, i'll remux with ffmpeg [20:41:29 CEST] <romano2k> "ffmpeg -i verspera-30fps.mkv verspera-30fps.mp4" will just remux it, right? [20:41:35 CEST] <furq> you need -c copy [20:41:47 CEST] <romano2k> ok [20:42:21 CEST] <romano2k> done! thank you so much :-) [20:43:50 CEST] <romano2k> by the way, do you guys know why we stick to 23.976 and 30000/1001 rates instead of 24 and 30 or 60, in the digital age with 60 Hz screens? [20:45:03 CEST] <JEEB> leftover from analog broadcast times. blu-ray does let you do exactly 24Hz, at least. [20:45:11 CEST] <JEEB> (although most discs are still 24/1.001) [20:46:31 CEST] <romano2k> i know it's a leftover, but are there good reasons to stick to these rates? compatibility issues at some point? do you know if there are plans to change? [20:47:18 CEST] <JEEB> no idea about possible changes to that, that's 100% up to the broadcasters since their stuff effectively controls what people have to output [20:47:35 CEST] <JEEB> and I don't think there's a good reason for digital only stuff to have the /1.001 rates [20:47:59 CEST] <kerio> that would be US analog broadcast [20:48:11 CEST] <kerio> EU analog broadcast was 25 on the dot, aiui [20:48:26 CEST] <JEEB> 50Hz, 50 fields per sec yes [22:18:47 CEST] <kepstin> probably one of the main reasons is to allow mixing old and new content on tv channels which use a fixed encoder config like 1080i [22:19:37 CEST] <kepstin> since there's so much content already at that rates, everybody continues to use them so they remain compatible [22:19:46 CEST] <JEEB> yup' [22:19:57 CEST] <Mavrik> also software only lets you export at those rates [22:20:01 CEST] <Mavrik> and then cameras only support those rates [22:20:25 CEST] <Mavrik> and everyone just says "eh, noone else supports other rates anyway" :P [22:21:52 CEST] <kepstin> we just need to redefine the length of a second to be 1.001 old seconds, that'll fix everything. [23:23:16 CEST] <romano2k> kepstin: haha sure :-D [23:26:48 CEST] <Crigges> Hello, Iam trying to build ffmpeg with openh264 under windows using msvc by following this guide: https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC I don't understand exactly where I need to link the external librarys as described here: [23:26:53 CEST] <Crigges> "In order to build FFmpeg with support to external libraries, you need to make sure that the libraries and headers are placed in a location specified by the INCLUDE and LIB directories referenced by the VC compiler and linker." [23:27:33 CEST] <Crigges> The build without external librarys already works fine. Do I need to use pkg-config? [00:00:00 CEST] --- Sat Jun 9 2018

1 0

ffmpeg-devel.log.20180607
by burek 08 Jun '18

08 Jun '18

[00:14:41 CEST] <cone-482> ffmpeg 03Ruiling Song 07master:e4006a474f68: lavu: add calling convention for OpenCL callback. [01:40:04 CEST] <January> Compn: ping [02:41:45 CEST] <Compn> January : pong [02:42:15 CEST] <Compn> January : are you a contributor or committer ? i forgot... [02:42:34 CEST] <January> Compn: I have git access [02:42:37 CEST] <Compn> ok [02:42:43 CEST] <Compn> is your nick registered ? [02:42:47 CEST] <January> yes [02:42:50 CEST] <Compn> k [02:43:05 CEST] <Compn> there you go [02:43:06 CEST] <January> also can you ping an op in #freenode to get my cloak updated, they didnt want to do it without your approval [02:43:09 CEST] <January> for some odd reason [02:43:14 CEST] <Compn> ergh [02:44:15 CEST] <January> Compn: thanks :^) [02:45:39 CEST] <Compn> sure sure [02:45:58 CEST] <Compn> but its June... [02:45:59 CEST] <Compn> :P [02:46:46 CEST] <January> I should register a nick for every month and just change it month instead of only every 2 years [13:08:04 CEST] <jdarnley> Why can't I find pmovzx in Agner's instruction tables for Skylake? Am I blind? [13:08:56 CEST] <jdarnley> Yes I am because it is right there, James! [13:09:06 CEST] <nevcairiel> complaining helps [13:18:42 CEST] <jdarnley> Unknown latency for y,m but y,x is 3. 2 uops like the x,m form. [13:19:15 CEST] <jdarnley> No wonder it seems to be no faster [13:37:30 CEST] <cone-728> ffmpeg 03Gyan Doshi 07master:47a818323ba0: doc/general.texi: clarify FDK-AAC licensing & usability [13:43:34 CEST] <cone-728> ffmpeg 03Jun Zhao 07master:3bab7b70da97: lavu/hwcontext_opecl: fix the build warning [13:43:34 CEST] <cone-728> ffmpeg 03Jun Zhao 07master:3161df5b0c2d: lavfi/opencl: remove redundant header. [13:43:36 CEST] <cone-728> ffmpeg 03Jun Zhao 07master:3769aafb7c9a: configure: fix check for opencl [17:03:14 CEST] <Gramner> jdarnley: instructions with memory args are generally identical to doing a memory load to a temporary register and then executing the instruction, just with a more compact encoding and no need for the temporary register. the exception is things like broadcast instructions that can in most cases be done without any extra execution unit usage compared to a regular memory load [17:06:47 CEST] <Gramner> for SIMD that is. for GPR instructions zero- and sign-extension is also free compared to normal memory loads [17:57:33 CEST] <jdarnley> Shit! shufps requires alignment of its memory arg. [17:59:25 CEST] <jamrial> all non vex instructions do, save for those where unaligned access is explicit, like movdqu [19:54:10 CEST] <cone-927> ffmpeg 03Michael Niedermayer 07master:d91a0b503d7a: avcodec/shorten: Sanity check nmeans [19:54:11 CEST] <cone-927> ffmpeg 03Michael Niedermayer 07master:a711efe922b2: avcodec/shorten: Fix a negative left shift in shorten_decode_frame() [19:54:12 CEST] <cone-927> ffmpeg 03Michael Niedermayer 07master:606c71482314: avcodec/shorten: Fix undefined shift in fix_bitshift() [19:54:13 CEST] <cone-927> ffmpeg 03Michael Niedermayer 07master:f2abd36b3863: avcodec/shorten: Fix multiple integer overflows [22:36:50 CEST] <jdarnley> > The code to fix it is very simple [22:37:00 CEST] <jdarnley> yet no patch is provided [22:47:03 CEST] <JEEB> of course [00:00:00 CEST] --- Fri Jun 8 2018

1 0

ffmpeg.log.20180607
by burek 08 Jun '18

08 Jun '18

[00:49:03 CEST] <ZiNC> Hi. [00:49:07 CEST] <kepstin> wfbarksd_: note that "seeking to the last packet and checking" doesn't work on some formats, e.g. mpeg-ts, where the timestamps can reset in the middle of the stream. [00:49:51 CEST] <ZiNC> Is there a way to check what video formats/levels ffmpeg's hardware decoder detects and can use? [03:00:48 CEST] <debianuser> Hm... Hello. I'm reencoding some mpeg2 videos into h264 and I noticed that, while I haven't set any video filters, ffmpeg automatically deinterlaces the video for me. I don't really mind, but... how can I select which deinterlacer to use for that? [03:06:05 CEST] <ZiNC> I don't know, but if you want the best quality deinterlacing you may have to use AviSynth scripts and a whole bunch of plugins. [03:06:18 CEST] <ZiNC> And a whole lot more CPU time. [03:07:31 CEST] <furq> debianuser: unless something drastically changed then it doesn't deinterlace automatically [03:07:44 CEST] <furq> but you do have to manually set the interlaced flags on the output if you want to encode interlaced [03:08:33 CEST] <furq> iirc just `-x264-params tff=1` should work [03:10:58 CEST] <ZiNC> For high quality deinterlacing search for QTGMC. It's a hassle to collect and get running, and with good performance, unless there are neat packages around that didn't exist when I last used it. [03:12:06 CEST] <furq> qtgmc does a great job on sd mpeg2 [03:12:11 CEST] <furq> but if you do use it then use it through vapoursynth [03:12:14 CEST] <debianuser> Well, maybe I misunderstand something... Does the "yuv420p(tv, top first)" mean that the video is interlaced? [03:12:19 CEST] <debianuser> Stream #0:0[0x100]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 704x576 [SAR 12:11 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbc [03:12:26 CEST] <furq> debianuser: it means it's signaled as tff [03:12:41 CEST] <furq> iirc all dvd sources are signaled as tff even if they're progressive [03:13:04 CEST] <furq> so if the output looks progressive in a player and you definitely don't have deinterlacing enabled then that's probably what's going on [03:13:30 CEST] <furq> the only way to tell for sure is to check and see if the input looks interlaced [03:14:00 CEST] <furq> and hope that it doesn't because that makes your life vastly simpler [03:40:04 CEST] <debianuser> Hm... I can upload a small sample... [03:52:15 CEST] <debianuser> https://www.sendspace.com/file/5x771b (frags.zip, 3.38MB) - two fragments inside. If you watch first fragment frame by frame in its last frame you may see: https://i.imgur.com/Ws6qArB.jpg which looks very interlaced. But! If you cat those two files together (`cat frag*.ts > both.ts`) and play them frame by frame, you won't see that frame there. How could that be? [03:57:22 CEST] <furq> doesn't look interlaced to me in mpv [03:58:12 CEST] <furq> https://0x0.st/s__W.png [03:58:16 CEST] <furq> that's the last frame i get in frag1.ts [04:05:45 CEST] <debianuser> I was dumping it with `mplayer -vo png`. So either mpv deinterlaced that last frame for you, or mplayer somehow interlaced only the last frame of the video for me. :) [04:06:10 CEST] <furq> i would assume mplayer just didn't fully decode the last frame [04:06:46 CEST] <furq> if it's signaled as tff then it's still technically a field-based input, it's just that both fields are from the same frame [04:07:41 CEST] <furq> anyway yeah that looks progressive to me but you might want to check a few different spots in the full program [04:08:07 CEST] <furq> broadcast is more than happy to switch between interlaced and progressive (or between tff and bff if they're feeling particularly evil) [04:11:30 CEST] <debianuser> "i would assume mplayer just didn't fully decode the last frame" -- good idea, that's possible too, my mplayer is old and probably buggy. [04:12:36 CEST] <debianuser> "signaled as tff then it's still technically a field-based input, it's just that both fields are from the same frame" - Ah! And those fields are still interlaced? Is there any way to check that, e.g. to dump individual "fields" within frame, or, maybe, see them in ffprobe, for example? [04:15:16 CEST] <furq> debianuser: -vf separatefields [04:28:44 CEST] <debianuser> furq: I think I understand everything now. Thanks a lot for your help and explanations! [06:22:04 CEST] <JC_Yang> questions about avformat_new_stream(fmt_ctx, NonNull_Known_Codec), what else do I need to fill in the AVStream.codecpar? for video, maybe width and height? and how about audio? since the documents in avformat.h suggest prefer manually initialize to avcodec_parameters_copy(), but does not mentioned how to in case when avformat_new_stream is passed with NonNull_Known_codec. [07:39:34 CEST] <sarab> Hi, can i ask questions related to ffmpeg? [07:41:39 CEST] <sarab> i want to play and record a device simultaneously. i can do it individually but how to do it simultaneousy as it says device resource busy [09:37:49 CEST] <MJBauer> Hi. Is it possible to record a rtsp stream in a ring-buffer and save a single image N seconds before an event which is triggerd with a bash SIGNAL? [09:38:04 CEST] <MJBauer> or any other trigger... [10:11:58 CEST] <JC_Yang> yes, you can. it's not a complex task, provided that you've got big enough ram, it's an easy task [10:29:25 CEST] <MJBauer> JC_Yang: RAM should not be the problem. Can you explain roughly how this can be done? [10:40:04 CEST] <JC_Yang> cache the video frames for a long enough time with keyframe as head of the buffer to ease decoding and when you need to take save the frame, feed a decoder with all the frames in the buffer and simply count which frame you need to capture, then save the decoded pic to file, done. remember frame contain pts, combine with "keyframe as head" as the buffer, it provides good enough guidance for "how to choose what to cached". is this what you asked for? [10:44:42 CEST] <Mavrik> I did something like that once - I ran a demuxer on RTSP stream and only decoded each keyframe, encoded it into JPEG and stored it into memory. [10:45:08 CEST] <Mavrik> That JPEG could be retrieved via HTTP at any time so you always got an decently up to date thumbnail of a stream with rather lowish CPU cost. [10:52:15 CEST] <MJBauer> JC_Yang: yes, this would suite my requirements. However, @Mavrik 's solution looks much easier. [10:53:23 CEST] <MJBauer> @Mavrik: you solution will need more cpu i guess.. [10:54:16 CEST] <Mavrik> I guess. [10:54:18 CEST] <MJBauer> Do you think a raspberry pi 3B+ can handle 4 video streams (720p) at once? It is connected with cable ethernet. [10:54:24 CEST] <Mavrik> You can always just store demuxed frame. [10:54:31 CEST] <Mavrik> And decode it when you need it. [10:54:41 CEST] <Mavrik> Which is pretty much what JC_Yang recommended :) [10:55:03 CEST] <MJBauer> How would i store a demuxed frame and decode it later? [10:55:08 CEST] <furq> MJBauer: it should be ok if you're only decoding keyframes [10:57:17 CEST] <MJBauer> furq: how much keyframes are there typically in a rtsp stream? 1 per second? [10:57:38 CEST] <furq> probably less than that [10:58:41 CEST] <JEEB> it really depends on the stream [10:59:34 CEST] <Mavrik> Yeah, it can be anything from "every frame is a keyframe" to "there's one keyframe at the start" :) [10:59:53 CEST] <MJBauer> how can I determine it? Is there something like a "stat" tool to see the video-stream properties? [11:00:28 CEST] <JEEB> ffprobe can output information on a running stream [11:00:54 CEST] <furq> well you'll know if it's every frame because the pi will start choking to death [11:01:18 CEST] <MJBauer> furq: XD true [11:01:42 CEST] <furq> for 720p h264 i would expect somewhere between once every 2 and 10 seconds [11:01:46 CEST] <furq> but yeah, it could be anything [11:02:46 CEST] <JC_Yang> some streams have pretty long keyframe interval, so "cached then decoded all and get the very frame you want" might be a better approach [11:03:33 CEST] <MJBauer> every 2 to 10 secs would be not frequent enough :( [11:04:24 CEST] <furq> if it's always the same rtsp streams then just check and see [11:04:52 CEST] <MJBauer> JC_Yang: would i use cache:URL (as said in https://ffmpeg.org/ffmpeg-protocols.html#cache )? [11:06:29 CEST] <JC_Yang> don't have ideas, that's not a part that I'm familiar with [11:11:44 CEST] <MJBauer> JEEB: ffprobe displays me the following: Stream #0:1: Video: h264 (Constrained Baseline), yuv420p(progressive), 240x160, 24 fps, 24 tbr, 90k tbn, 48 tbc [11:12:08 CEST] <MJBauer> which one of that is the keyframe-rate? [11:12:18 CEST] <JEEB> MJBauer: you would have to output packets or frames [11:12:27 CEST] <JEEB> those then can contain a flag for being a random access point [11:18:27 CEST] <MJBauer> Wouldn't it be possible to "restream" with a delay of, let's say, 5 seconds and then issue a snapshot with ffmpeg on that delayed-stream? [11:18:31 CEST] <Mavrik> There's no such thing as keyframe rate. [11:18:55 CEST] <Mavrik> Any frame can be a keyframe depending on encoder decision :/ [11:19:33 CEST] <MJBauer> so i don't need to worry about if it is a keyframe or not? [11:19:58 CEST] <MJBauer> Mavrik: thank's for pointing out. I am new to video-processing... [11:24:15 CEST] <MJBauer> after reading more discussions in the net, i would like to change my original question. [11:25:06 CEST] <MJBauer> How can i setup a rtsp live stream with a timeshift of 5 Minutes, so i can grap a snapshot at specific time from the timeshift-stream? [11:25:32 CEST] <JEEB> RTSP sounds like VLC might support serving it better [11:25:36 CEST] <JEEB> no idea about timeshift [11:25:42 CEST] <JEEB> usually a feature of the serving side [11:25:51 CEST] <JEEB> so I recommend #videolan for RTSP serving needs [11:30:09 CEST] <MJBauer> JEEB: so it qould be videolan doing the timeshift and ffmpeg grabbing a still image of the stream? [13:13:44 CEST] <kerio> whoever came up with libavformat needs jesus btw [13:55:42 CEST] <DHE> kerio: how many different file formats you have to deal with? there's a lot each with their own quirks. from files that don't have an actual "fps" value saved anywhere to files that are actually network streams [13:56:35 CEST] <kerio> i just need a way to store a single ffvhuff or ffv1 stream [14:02:27 CEST] <kerio> actually i wonder if i can just retrieve the bitstream [14:05:16 CEST] <kerio> how do i parse a ffvhuff bitstream [16:10:37 CEST] <kerio> ok i think i understand how to use libavformat [16:10:52 CEST] <kerio> and whoever wrote it still needs jesus [16:13:14 CEST] <atomnuker> its simple - create an avf context, create a stream, populate the codecpar context from an avctx (if you've got one, or do it manually), then write a header, write packets in a loop and write a trailer [16:13:44 CEST] <atomnuker> make sure to mark the stream avpackets belong to if you're writing interleaved audio and video streams [16:24:32 CEST] <zevarito> hi guys, is anyone familiar with the encoder message input picture width (x) is greater than stride (y) ? [16:25:25 CEST] <zevarito> I am having troubles encoding hls, look like a strange issue since it only happen when I simultaneously reproduce the stream [16:31:16 CEST] <DHE> API warning from mpegts muxer: "frame size not set", which seems to be a side-effect of AAC encoding. know how to fix this? [16:31:55 CEST] <DHE> from my own checking: function get_audio_frame_duration() returns 0 because AAC has no fixed packet/frame duration and at mpegts initialization time it doesn't have anything to use as a guess [16:37:49 CEST] <DHE> for now I'm just going to ignore it [16:55:00 CEST] <upgrade> hi all, its possible to capture stream from youtube and restream to another rtmp server? [16:55:22 CEST] <upgrade> using youtube-dl, for example [16:55:45 CEST] <DHE> well, yes. ffmpeg should accept the URLs youtube-dl can provide [16:56:51 CEST] <upgrade> can u tell when i must read about this? [17:27:04 CEST] <waterworks> I'm trying to build ffmpeg with nvenc support. The configure script says it cannot find ffnvcodec but the headers are installed and is listed in pkg-config --list-all. MSYS64 32 bit VS2017 https://pastebin.com/DezFQtAb [18:54:41 CEST] <anill> How to make ffmpeg run as daemon on windows.? [19:15:54 CEST] <anill> DHE: Hi [19:19:10 CEST] <DHE> sorry bus [19:19:12 CEST] <DHE> busy [19:21:12 CEST] <ariyasu> what do you mean a daemon? [19:21:19 CEST] <ariyasu> so you can call it from anywhere? [19:21:31 CEST] <ariyasu> you can add it to your path to do tha [21:57:40 CEST] <migu3x> Hello I'm using ffmpeg to download .ts streams with following command ```ffmpeg.exe -i 'source.m3u8' -c copy out.ts``` but when the video gets to 8 hours I start getting discontinuity errors and it stops capping/downloading [21:58:01 CEST] <migu3x> Any idea how I can prevent this from happening? Is it a MPEG-TS file issue? [22:07:00 CEST] <migu3x> I will be sitting here expecting somebody knows the answer [22:08:38 CEST] <tom13> how large does the file get [22:09:06 CEST] <JEEB> I think libavformat should handle discontinuities and generally discontinuities happen every... twenty-something hours [22:09:09 CEST] <migu3x> different sizes [22:09:19 CEST] <JEEB> of course it depends on how far into the timestamps you are when it starts [22:09:24 CEST] <JEEB> oh right, HLS [22:09:37 CEST] <migu3x> What sohuld I do? [22:09:39 CEST] <JEEB> the HLS demuxer isn't actually noted as "this has discontinuities" [22:09:47 CEST] <JEEB> even though it uses mpeg-ts underneath [22:09:49 CEST] <JEEB> which has it [22:09:49 CEST] <migu3x> I mean the timestamps [22:10:17 CEST] <JEEB> also, do note that something dumber might be able to just rip it for you [22:10:20 CEST] <DHE> MPEG-TS internal timestamps overflow/wrap around every 26.5 hours or so. on a live stream you could join it at any point along that timeline. [22:10:33 CEST] <JEEB> because you literally just need to concatenate the MPEG-TS files [22:10:51 CEST] <JEEB> so you download the playlist and download segments, rince n' repeat [22:12:46 CEST] <migu3x> you meean download al .ts files [22:12:49 CEST] <migu3x> separately and join them? [22:13:03 CEST] <JEEB> or just have a script that writes their bytes into a single file to begin with? [22:14:34 CEST] <migu3x> hows that? [22:14:52 CEST] <migu3x> They have EXT--X-KEY it isn't as simple as just grabbing the .ts urls [22:15:19 CEST] <migu3x> And I'm not sure but I think the m3u8 gets updated over time and the segments aren't linealy numerated [22:15:32 CEST] <migu3x> numbered* [22:32:08 CEST] <migu3x> and when capturing with VLC [22:32:20 CEST] <migu3x> i get a strange "nothing to play" debug message and doesnt download anything [22:52:41 CEST] <salviadud> I was here a couple of days ago, when I asked a really good question and my internet lagged me out, so unfortunate, I must ask again. [22:53:08 CEST] <salviadud> I have a .mkv file with 7.1 atmos audio (truehd) [22:53:34 CEST] <salviadud> I am converting that audio stream to DTS with dca, but I am not playing with any bitrate options [22:53:49 CEST] <salviadud> I want to know if there's some equivalent for quality, like -crf [22:54:03 CEST] <salviadud> Or maybe I should just keep it that way (sounds fine to me) [22:54:50 CEST] <furq> i'm pretty sure dts core is always cbr [22:55:04 CEST] <salviadud> constant? [22:55:38 CEST] <furq> only dtsma is vbr, and i don't think ffmpeg supports encoding that anyway [22:55:40 CEST] <furq> and yes constant [22:55:57 CEST] <salviadud> So, if I don't specify a bitrate [22:56:10 CEST] <salviadud> It will default to whatever the original stream is? [22:56:19 CEST] <furq> no it'll default to whatever the default for the encoder is [22:57:07 CEST] <furq> which is apparently 1411kbps [22:57:15 CEST] <furq> i guess for dts-wav compatibility or something [22:57:30 CEST] <salviadud> so, on an 8 channel stream [22:57:35 CEST] <salviadud> 7000 kbps aprox? [22:57:51 CEST] <salviadud> at least, I mean [22:57:58 CEST] <furq> dts core maxes out at 1536kbps iirc [22:58:10 CEST] <salviadud> No matter the number of chans? [22:58:13 CEST] <furq> right [22:58:22 CEST] <furq> that should be more than enough for 7.1 though [22:58:38 CEST] <furq> bearing in mind raw stereo pcm at 48k is 1536kbps [22:58:51 CEST] <furq> and dts is lossy [22:59:29 CEST] <salviadud> I get this from the -codecs parameter ---> DEA.LS dts [22:59:39 CEST] <salviadud> It seems it could be lossless as well [23:00:39 CEST] <furq> shrug [23:00:41 CEST] <furq> i've never used it [23:01:43 CEST] <salviadud> Well, it is experimental [23:01:53 CEST] <salviadud> I'm going to trust the default values I guess [23:02:53 CEST] <JEEB> wouldn't that be the decoder that has lossless? [23:03:27 CEST] <salviadud> JEEB, it would seem that way [23:03:50 CEST] <furq> oh right yeah [23:03:51 CEST] <JEEB> yea since caps_internal has just THREADSAFE | INIT_CLEANUP [23:03:57 CEST] <JEEB> the decoder has XLL support yes [23:04:04 CEST] <furq> i notice -profile dts_hd_ma is a thing [23:04:06 CEST] <JEEB> XLL being what the marketing side calls DTS-HD MA [23:04:10 CEST] <furq> but it doesn't seem to do anything for the encoder [23:04:12 CEST] <migu3x> Any idea about what I said? [23:04:27 CEST] <JEEB> XLL being something like eXtension LossLess [23:04:30 CEST] <furq> at least dts_96_24 is auto-resampling to 48k [23:04:35 CEST] <furq> so i'm guessing the others don't work either [23:04:42 CEST] <JEEB> yea, it's basic DTS [23:04:51 CEST] <JEEB> I don't think anyone /wants/ to code DTS [23:04:58 CEST] <salviadud> I do [23:05:03 CEST] <JEEB> my condolences sir [23:05:09 CEST] <salviadud> My AMP doesn't support atmos [23:05:15 CEST] <JEEB> if it's a blu-ray just encode PCM [23:05:22 CEST] <JEEB> well, uh [23:05:23 CEST] <JEEB> ATMOS [23:05:32 CEST] <salviadud> truehd codec [23:05:36 CEST] <JEEB> (do note there's like N different things under the Dolby Atmos name) [23:05:43 CEST] <furq> pcm is going to get pretty big for 7.1 [23:05:45 CEST] <JEEB> no, Atmos are different extensions [23:05:54 CEST] <furq> but if it's just going straight to an amp then i guess who cares [23:05:57 CEST] <JEEB> yea [23:06:10 CEST] <JEEB> if you're on HDMI or something just rock PCM [23:06:37 CEST] <JEEB> you're not going to gain anything by first decoding and then encoding into some lossy format (or even lossless to be honest) [23:06:43 CEST] <salviadud> It's a samsung smart tv that does the initial read, then it passes through optical [23:06:50 CEST] <JEEB> optical [23:06:57 CEST] Action: salviadud laughs [23:06:57 CEST] <JEEB> well that pushed out any lossless tuff [23:06:59 CEST] <JEEB> *stuff [23:07:07 CEST] <salviadud> Yeah, it's an old amp [23:07:10 CEST] <JEEB> then just encode AC3 [23:07:13 CEST] <JEEB> if you need 5.1 [23:07:16 CEST] <salviadud> So, I'm guessing regular DTS is pretty good [23:07:20 CEST] <JEEB> no it is not [23:07:23 CEST] <salviadud> It does support 7.1 [23:07:23 CEST] <JEEB> DTS is goddamn awful [23:07:32 CEST] <JEEB> without extensions no it doesn't [23:07:52 CEST] <JEEB> and I see mono, stereo, 2.2, 5.0, 5.1 in the list of supported audio layouts [23:07:53 CEST] <salviadud> What extensions do I need for 7.1? [23:07:55 CEST] <JEEB> in the dcaenc [23:08:03 CEST] <JEEB> let me see from the decoder [23:08:24 CEST] <furq> oh [23:08:27 CEST] <furq> it's XXCH apparently [23:08:30 CEST] <JEEB> yes [23:08:30 CEST] <furq> whatever ffmpeg calls that [23:08:47 CEST] <furq> dts_es [23:09:14 CEST] <JEEB> furq: there's plenty of XXCH strings in the code base so that name is utilized [23:09:18 CEST] <furq> [dca @ 0000000000546be0] Specified channel layout '7.1' is not supported [23:09:24 CEST] <JEEB> well yes I just noted that [23:09:26 CEST] <furq> i get that with -profile:a dts_es [23:09:27 CEST] <furq> so yeah [23:09:28 CEST] <salviadud> So, if I want to encode as DTS with those extensions, I run -c:a dca with some flag? [23:09:36 CEST] <JEEB> you cannot, nobody wrote that code [23:09:42 CEST] <furq> yeah you need to use some other encoder [23:09:43 CEST] <JEEB> and DTS is a god-awful audio format [23:09:48 CEST] <furq> i'm not aware of any other free one [23:10:03 CEST] <JEEB> only the lossless extensions save it for that use case although I'd much rather use PCM or TrueHD for blu-rays [23:10:09 CEST] <salviadud> I do seem to need to turn up the volume, compared to AC-3 [23:10:45 CEST] <JEEB> anyways, AC3 or AAC is what you probably want to bit stream, but almost nothing but set-top-boxes support the latter [23:10:53 CEST] <JEEB> if you need 5.1 over SPDIF [23:11:25 CEST] <JEEB> not lossless of course because you barely have enough bandwidth for raw 2ch 48kHz 24bit audio track on SPDIF [23:11:58 CEST] <salviadud> I don't get it though, if my DTS audio stream is larger than the equivalent AC-3 stream, why is it worse? [23:12:08 CEST] <furq> does the eac3 encoder support 7.1 [23:12:21 CEST] <JEEB> oh we have eac3 encoder [23:12:21 CEST] <JEEB> lol [23:12:24 CEST] <furq> [eac3 @ 0000000000574bc0] Specified channel layout '7.1' is not supported [23:12:25 CEST] <furq> nice [23:12:43 CEST] <JEEB> yea it very much looks like a minor extension to ac3enc [23:12:45 CEST] <salviadud> So, I'm just getting more audio channels on DTS? [23:12:51 CEST] <JEEB> no, you're not? [23:13:04 CEST] <JEEB> I don't know what on earth you're comparing [23:13:32 CEST] <salviadud> Let me give you an example [23:13:33 CEST] <furq> dts core only does 5.1 [23:13:50 CEST] <furq> if you're just transcoding with default arguments then i guess it's automatically downmixing [23:13:59 CEST] <salviadud> Ohhh, I get it [23:14:15 CEST] <salviadud> My 7.1 truehd gets downmixed to 5.1 with dts_core [23:14:25 CEST] <furq> right [23:14:33 CEST] <salviadud> Still, it spits out a higher bitrate than with AC-3 [23:14:46 CEST] <salviadud> So, isn't that better quality? [23:14:53 CEST] <furq> pcm is higher bitrate than flac [23:14:53 CEST] <JEEB> no? [23:15:00 CEST] <JEEB> also you can set the darn bit rate [23:15:12 CEST] <JEEB> what the default is up to everyone's surprise and amazement [23:15:15 CEST] <JEEB> welcome to FFmpeg [23:15:44 CEST] <salviadud> flac uses compression, pcm is raw [23:16:17 CEST] <salviadud> Well, it sounds just the same, but I have to turn up the volume up a notch+ [23:16:30 CEST] <salviadud> Just saying, from experience. [23:16:35 CEST] <salviadud> Comparing AC-3 with DTS [23:16:45 CEST] <JEEB> yes, some of the formats have random normalization in the specification [23:16:48 CEST] <kepstin> opus at 96kbps will sound better than mp3 at 128kbps, bitrate comparison between codecs doesn't make sense. [23:16:58 CEST] <JEEB> that is, the proprietary ones [23:17:00 CEST] <furq> thank you for a better example [23:17:10 CEST] <JEEB> which would explain random volume differences with Patents Paid decoders [23:22:12 CEST] <furq> do you think he ever found that hidden porno message [00:00:00 CEST] --- Fri Jun 8 2018

1 0

ffmpeg-devel.log.20180606
by burek 07 Jun '18

07 Jun '18

[00:32:33 CEST] <tmm1> can ffmpeg cli copy data streams? [01:46:59 CEST] <jamrial> again? [01:47:06 CEST] <jamrial> BBB: ^ [01:50:55 CEST] <kierank> ffmpeg can handle ac3 in wave, right? [02:04:02 CEST] <BBB> hm... [02:06:25 CEST] <jamrial> BBB: they bumped the pkg-config file version at least [02:14:28 CEST] <atomnuker> kierank: it should, riff and riffenc mention it [02:14:44 CEST] <kierank> atomnuker: was a bug in upipe actually [03:24:02 CEST] <cone-950> ffmpeg 03Sasi Inguva 07master:fe6c4f0c47d4: lavf/mov.c: Set st->start_time for video streams explicitly. [04:01:01 CEST] <cone-950> ffmpeg 03Vittorio Giovara 07master:c9fcdac11874: Use the same name for stereo3d frame/packet side data [04:07:50 CEST] <cone-950> ffmpeg 03foo86 07master:b74877206e5f: fate: add Dolby E test [10:50:19 CEST] <nevcairiel> how is one supposed to use the dolby e decoder anyway? all dolby e strreams i have come in s302m, and you cant exactly chain decoders without manual API use [11:10:47 CEST] <kierank> you can't the api sucks [11:11:10 CEST] <kierank> move to upipe [11:13:09 CEST] <nevcairiel> you must love drowning in boilerplate if you like upipe so much =p [11:13:31 CEST] <kierank> i love having things working as well [11:13:38 CEST] <kierank> and not being stuck by legacy design [11:17:49 CEST] <durandal_1707> please someone ban kierank, he is traitor [11:37:16 CEST] <durandal_1707> Compn, michaelni: when you gonna give op to kierank ? [12:15:00 CEST] <atomnuker> kierank: using upipe doesn't mean you escape legacy design [12:15:30 CEST] <atomnuker> 3 timestamps, in some weird legacy 29mhz or something timebase [12:16:02 CEST] <kierank> yes because it has an understanding of realtime [12:16:06 CEST] <kierank> unlike ffmpeg [12:16:15 CEST] <kierank> instead of just making timestamps on the fly [12:16:52 CEST] <atomnuker> welp, I'm a fan of anything not based on real world things so that's a plus in my book :P [12:17:31 CEST] <atomnuker> its not _that_ hard to chain decoders, just init 2 of them with separate contexts and move the avbufferref of the avframe to the avpkt input of the second decoder [12:22:01 CEST] <atomnuker> we could maybe hack up a bsf to init a context and convert for you, though that sounds like a bad idea [12:23:19 CEST] <atomnuker> it'll need extra avpacket side data to tell it the packet's codec_id (s302m) and it'll compare that to what the avctx has been init'd as (dolby_e) and perform the conversion if its allowed [13:34:02 CEST] <Compn> oooo what did i do [13:34:10 CEST] <Compn> i didnt do that [13:34:29 CEST] <Compn> added kierank though [13:35:05 CEST] <Compn> probably they werent identified [13:35:09 CEST] <Compn> still in access list [13:43:32 CEST] <atomnuker> Compn: add JEEB and jdarnley while you're at it [13:43:45 CEST] <jdarnley> no thanks [13:46:43 CEST] <Compn> atomnuker : see, this is one reason why i dont add people from third party requests [13:46:46 CEST] <Compn> some people dont want/like it [13:48:31 CEST] <atomnuker> I don't think JEEB wouldn't mind [13:51:57 CEST] <JEEB> wat [13:52:15 CEST] <Compn> double negative hard to read [13:52:19 CEST] <Compn> JEEB : you want ops here ? [13:52:25 CEST] <JEEB> should be OK [13:52:33 CEST] <Compn> [07:34] -ChanServ- 62 JEEB +AViv (contributor) [modified 2y 10w 6d ago] [13:52:38 CEST] <Compn> he already in the list [13:52:39 CEST] <Compn> :P [13:52:41 CEST] <JEEB> lol [13:52:51 CEST] <Compn> but not with +o it seems [13:53:20 CEST] <Compn> is ok a yes/no ? [13:53:41 CEST] Action: Compn losing interest fast [13:57:01 CEST] <JEEB> y [13:57:43 CEST] <Compn> ah there we go [13:57:55 CEST] Action: Compn press wrong buttons [13:58:04 CEST] <Compn> beep boop beep [13:58:45 CEST] <Compn> if anyone else wants ops, doesnt want ops, wants voice, doesnt want voice whatever just tell me thanks [14:00:29 CEST] <kierank> durandal_1707: when you getting op? [14:01:22 CEST] <Compn> hes already in there [14:01:37 CEST] <Compn> under his old nickname it looks like [15:39:18 CEST] <cone-482> ffmpeg 03John Cox 07master:ad94f1c8abe6: configure: fix arm inline asm checks [15:51:08 CEST] <cone-482> ffmpeg 03John Cox 07release/4.0:72a34d233299: configure: fix arm inline asm checks [19:48:43 CEST] <Chloe> Compn: gib ty [20:50:25 CEST] <cone-482> ffmpeg 03Michael Niedermayer 07master:79c6047c3668: avcodec/truemotion2: Fix overflow in tm2_apply_deltas() [20:50:26 CEST] <cone-482> ffmpeg 03Michael Niedermayer 07master:936f4a2c2e14: avcodec/mjpegdec: Fix integer overflow in ljpeg_decode_rgb_scan() [20:50:27 CEST] <cone-482> ffmpeg 03Michael Niedermayer 07master:424a81df107b: avcodec/shorten: Check non COMM chunk len before skip in decode_aiff_header() [22:36:39 CEST] <cone-482> ffmpeg 03Carl Eugen Hoyos 07master:c8de4448bda1: lavc/profiles: Mention AAC-LC only once. [00:00:00 CEST] --- Thu Jun 7 2018

1 0

ffmpeg.log.20180606
by burek 07 Jun '18

07 Jun '18

[01:08:59 CEST] <shfil> hi, as far I know pcm_s16le doesn't contain info about channels layout, I know that I need set it for swr resample, should I do something more? [01:14:52 CEST] <kepstin> shfil: what's the context? you're building an api application? Where is the audio coming from? [01:15:45 CEST] <kepstin> there are some container formats which can hold pcm_s16le that have channel layout info available (or have standard layouts, at least) [01:16:16 CEST] <shfil> https://github.com/rwengine/openrw/pull/420/commits/dea8f0f9c006371ec6adc1c… [01:16:24 CEST] <kepstin> if you have raw s16le stuff, I guess you'll have to say what it is yourself. [01:17:17 CEST] <shfil> there are short wav files [01:17:57 CEST] <shfil> it almost works well, except quiet scrapping/interferences on the radio/ticking. [01:18:15 CEST] <shfil> sound something like that [01:18:26 CEST] <kepstin> from wav, I *think* you should be fine if the codec parameters are being sent from the formatcontext to codeccontext properly [01:21:06 CEST] <shfil> something like this is ok? https://github.com/rwengine/openrw/pull/420/files#diff-e9cc6b7c0e9b40ae49ea… [01:21:15 CEST] <kepstin> (the stuff on line 221/222 looks like a really verbose way to write a memcpy) [01:22:18 CEST] <kepstin> shfil: yeah, looks like the codec params are being copied correctly there, at a glance. [01:24:08 CEST] <shfil> it's weird because decoding directly works, but after resampling to stereo there are some quiet artifacts. [01:26:57 CEST] <kepstin> shfil: are the artifacts happening on sample loops? it looks like you're not flushing the resampler at the end of the file. [01:27:52 CEST] <kepstin> so any buffered samples from the end of the file could be missing from your result [01:28:52 CEST] <kepstin> (call swr_convert_frame with NULL input frame when you're done to get the remaining samples) [01:30:32 CEST] <shfil> should I add some extra loop for it? [01:31:48 CEST] <kepstin> no, just call it once after you're done with the loop over input should be fine [01:34:06 CEST] <shfil> you mean loop `while ((receiveFrame = avcodec_receive_frame(codecContext, frame)) == 0) {`or that copying data [01:34:26 CEST] <kepstin> after the avcodec_receive_frame loop [01:36:57 CEST] <kepstin> call swr_convert_frame once on each frame you get from avcodec_receive_frame, then afterwords call it once with NULL input frame [01:38:05 CEST] <shfil> sorry for many dump question, should I increase range of resampled or use frame? [01:38:21 CEST] <shfil> (I mean variables) [01:39:38 CEST] <kepstin> shfil: i'm not sure what you mean? The variable 'resampled' is an AVFrame. [01:40:42 CEST] <shfil> `resampled` is output frame for swr_convert_frame, `frame` is input frame. [01:42:16 CEST] <kepstin> shfil: you should only call swr_convert_frame with an output frame that doesn't have any buffers (i.e. it's newly allocated, or you've "deref"ed it) [01:43:16 CEST] Action: kepstin would advise not re-using an AVFrame you got from the decoder for that. [01:44:38 CEST] <kepstin> (the reason is that swr_convert_frame calls av_frame_get_buffer, which is documented to leak memory if called on a frame that already has a buffer) [01:45:44 CEST] <kepstin> oh, i'm misreading that. [01:46:04 CEST] <kepstin> excuse my misinformation there - if the frame has an already allocated buffer, it'll just fill that [01:46:58 CEST] <kepstin> (if called on a frame without a buffer, it allocates a new buffer guaranteed to hold all the samples it could output - if you provide a buffer, it will only output what fits, and will internally queue stuff that doesn't fit) [01:48:15 CEST] <shfil> so do you think it's source of problem? [01:49:18 CEST] <shfil> (if I understand) [01:51:27 CEST] <kepstin> my suspicion is that if you have looping audio, then the missing samples (from the resampler delay) at the end of the file with your current code might cause artifacts at the loop point. [01:52:00 CEST] <kepstin> if you have problems elsewhere, then it's a different problem :/ [02:03:37 CEST] <shfil> thanks for help, I'll take closer look at tomorrow. ;) [03:08:40 CEST] <tom13> are there any effective super-resolution type advanced filters that can motion-interpolate / auto-tween 24,25,30 fps video to 60fps [03:09:15 CEST] <tom13> i've been talking with people about this since um. 2003 [03:09:25 CEST] <tom13> gettin a bit old [04:13:00 CEST] <Moocow9m_> hello, I'm trying to build ffmpeg and got an error while configuring. (Slightly striped log for 512KB limit)LOG: https://pastebin.com/HqpCH5wv [04:13:20 CEST] <Moocow9m_> Seems to be having a hard time linking vorbis [04:14:03 CEST] <Moocow9m_> I am able to compile older versions of ffmpeg but 4.0 and up seems to do this [04:24:31 CEST] <tdr> on my system, vorbis provides /usr/lib32/pkgconfig/vorbis.pc /usr/lib32/pkgconfig/vorbisenc.pc /usr/lib32/pkgconfig/vorbisfile.pc /usr/lib64/pkgconfig/vorbis.pc /usr/lib64/pkgconfig/vorbisenc.pc /usr/lib64/pkgconfig/vorbisfile.pc [04:24:45 CEST] <tdr> (built w/ 32 + 64 bit versions) [04:25:42 CEST] <Moocow9m_> It seems to be more with ogg methods in vorbis (also I have pkg-config set to both .pc files) [04:26:19 CEST] <Moocow9m_> I mean vorbis.pc(multiple) files and ogg.pc file [04:26:20 CEST] <tdr> ERROR: vorbis not found using pkg-config [04:27:42 CEST] <Moocow9m_> line 12785 checks for vorbis with no error. it starts testing with vorbis then errors [04:44:10 CEST] <Moocow9m_> @tdr I have this variable set before ./configure: PKG_CONFIG_PATH=/d/db6/build/S/VS1564R/Release/x264/lib/pkgconfig:/d/db6/build/S/VS1564R/Release/openjpeg/lib/pkgconfig:/d/db6/build/S/VS1564R/Release/ogg/lib/pkgconfig:/d/db6/build/S/VS1564R/Release/vorbis/lib/pkgconfig:/d/db6/build/S/VS1564R/Release [04:44:33 CEST] <Moocow9m_> It has paths to the needed .pc files [05:54:27 CEST] <kepstin> tom13: ffmpeg has one builtin, "minterpolate". Your results may vary :/ [05:55:46 CEST] <tom13> ty kepstin [05:56:11 CEST] <tom13> i haven't looked into the motion interpolation of modern televisions [05:56:20 CEST] <tom13> but i think it began in early 2000s with LG [10:02:48 CEST] <DeDaDo_> Hello every one. Good morning, good evening and good afternoon to every one located in different time zones. [10:03:47 CEST] <DeDaDo_> I have a question regarding video rotation. I have a video which has meta data of rotation 180 degrees. As per ffmpeg , ffmpeg will autorotate video. Is this case valid for RTMP Streaming as well? [10:14:40 CEST] <DeDaDo_> ? [10:18:54 CEST] <tom13> i have been looking into rem ote desktop [10:19:29 CEST] <tom13> and ffmpeg can h264 screengrab and pipe out the pc x session or portion of screen [10:19:40 CEST] <tom13> with a lag about 80ms [10:20:37 CEST] <tom13> now all someone needs is make a script that sets up that on the server, and another on remote device for playback and forwarding of inputs [10:21:22 CEST] <tom13> nomachine nx can do h264 now also, but it is overkill for some quick gaming [10:28:08 CEST] <Mavrik> That still sounds like x2 of what Steam/GeForce Now do. Where is the lag coming from? [10:31:15 CEST] <tom13> i do not know what they use [10:31:59 CEST] <tom13> i think h264 needs to buffer a few frames for its encoding [10:32:58 CEST] <tom13> and playback devices need some too [10:33:27 CEST] <tom13> i am curious if you know anyone who did this [10:42:27 CEST] <DHE> x264 can be run in zerolatency mode which brings encoder latency as low as it can. framing is up to you [11:42:10 CEST] <DeDaDo_> Any one can help in my query please? [11:45:31 CEST] <Mavrik> DeDaDo_: hmm, I don't think ffmpeg will autorotate video by default [11:45:37 CEST] <Mavrik> unless you're applying a filter? [11:54:09 CEST] <DeDaDo_> Mavrik, the video has a rotation value of 180, so ffmpeg will still not auto rotate it? [11:54:24 CEST] <Mavrik> ffmpeg won't do auto anything [11:54:37 CEST] <Mavrik> Because it assumes you don't want things to randomly rotate [11:54:50 CEST] <Mavrik> It'll just pass through the rotation flag (which I assume is set) if destination container supports it [11:56:16 CEST] <DeDaDo_> ok, so its up to the destination player to read that flag and render the video [11:56:18 CEST] <DeDaDo_> ? [11:57:17 CEST] <Mavrik> yep [11:57:35 CEST] <Mavrik> I'm decently sure RTMP doesn't support that flag tho [12:00:04 CEST] <DeDaDo_> ok thanks Mavrik for all the information. [12:29:03 CEST] <slavanap> Is there any ability with ffmpeg to detect muted audio segments in video? [12:41:46 CEST] <BtbN> silencedetect [14:14:16 CEST] <slavanap> BtbN, thanks! `ffmpeg -nostats -hide_banner -i 2016.05.31.mp4 -af silencedetect=n=-50dB:d=5 -vn -f null -` works like a charm! [14:43:02 CEST] <xmbswc> what was the --option to disable <depending on tty/console> [14:43:56 CEST] <DHE> -nostdin ? [14:44:50 CEST] <xmbswc> thanks, will text, is probably it [14:46:40 CEST] <Guest671> Hi, I'm trying to build ffmpeg with --enable-libsrt, and I'm getting "ERROR: srt >= 1.2.0 not found using pkg-config" [14:47:04 CEST] <Guest671> Does it mean ffmpeg does not support srt above 1.2.0 [14:47:37 CEST] <DHE> if you compiled it manually, you may need to set PKG_CONFIG_PATH [14:47:45 CEST] <xmbswc> seems to do DHE thanks [14:50:49 CEST] <Guest671> Already set it [14:50:53 CEST] <Guest671> PKG_CONFIG_PATH=/home/hao/repo/Transcoder/Release/libsrt/lib/pkgconfig ./configure --prefix=/home/hao/repo/Transcoder/Release/ffmpeg --enable-shared --enable-demuxer=mpegts,mpegvideo,image2 --enable-muxer=mpegts --enable-protocol=file,udp,rtp --enable-filter=overlay --enable-zlib --enable-libsrt --disable-doc [14:51:11 CEST] <Guest671> this is my build command [15:23:29 CEST] <zh_> PKG_CONFIG_PATH=/home/hao/repo/Transcoder/Release/ffmpeg/lib/pkgconfig ./configure --prefix=/home/hao/repo/Transcoder/Release/ffmpeg --enable-shared --enable-demuxer=mpegts,mpegvideo,image2 --enable-muxer=mpegts --enable-protocol=file,udp,rtp --enable-filter=overlay --enable-zlib --enable-libsrt --disable-doc [15:23:34 CEST] <zh_> ERROR: srt >= 1.2.0 not found using pkg-config [15:24:43 CEST] <JEEB> less ffbuild/config.log [15:24:47 CEST] <JEEB> see what happened [15:43:24 CEST] <zh_> usr/bin/ld: warning: libcrypto.so.1.0.0, needed by /home/hao/repo/Transcoder/Release/ffmpeg/lib/libsrt.so, not found [16:37:49 CEST] <mas886> Hello there, I'm getting a resolution format I don't want with the following command "ffmpeg -i - -vcodec rawvideo -pix_fmt yuv420p -threads 0 -f v4l2 /dev/video1" [16:38:01 CEST] <mas886> Is there anything I can do to force 1080? [16:43:20 CEST] <Mavrik> can you pastebin the output of the command_ [16:45:08 CEST] <mas886> Mavrik: https://pastebin.com/tZdt6rfJ [16:46:10 CEST] <mas886> I use thisto capture my DSLR camera as a webcam [16:47:59 CEST] <Mavrik> mas886: well it seems like your input from the stdin pipe is already in a crappy resolution [16:48:04 CEST] <Mavrik> so it's not ffmpeg that can do anything abou tit [16:50:35 CEST] <mas886> Mavrik: Hm, too bad, thanks! [16:50:39 CEST] <furq> i'm surprised that even works [16:50:49 CEST] <furq> i thought you always needed to explicitly set -video_size when reading rawvideo from stdin [16:50:54 CEST] <furq> and -framerate [16:51:21 CEST] <Mavrik> I guess it can automagick itself from JPEG headers :) [16:51:40 CEST] <furq> oh right it's mjpeg [16:51:57 CEST] <furq> duh [19:29:00 CEST] <waterworks> I'm trying to build FFmpeg with nvenc support, I've installed the ffnvcodec headers and they are found in the PKG path, but I get the error message "ERROR: nvenc requested, but not all dependencies are satisfied: ffnvcodec". The config.log shows it passing the nvenc tests and then just failing at the very end with that message. [19:43:49 CEST] <JEEB> waterworks: post config.log on pastebin/gist/0x0.st and link here? [19:47:02 CEST] <waterworks> JEEB: https://pastebin.com/2cTxajfe [19:50:18 CEST] <JEEB> waterworks: seems like it fails with the "Wdeclaration-after-statement" flag [19:50:29 CEST] <JEEB> seems to be the only test trying that [19:50:54 CEST] <JEEB> I don't think it was tested really hard with MSVC [19:51:08 CEST] <JEEB> or not [19:51:23 CEST] <JEEB> that's a separate feature check [19:51:54 CEST] <waterworks> Multiple tests fail in different feature checks. It can compile fine without nvenc specified, so that means it reads the libx264 pkg correctly but not the nvenc one. [19:52:48 CEST] <JEEB> well if you look at that nvenc test I don't think it even fails [19:53:25 CEST] <BtbN> it looks like the ffnvcodec tests aren't even run [19:54:06 CEST] <BtbN> Or produce no log output. ffnvcodec needs to be found by pkg-config, and the version has to end in .2 [19:54:17 CEST] <BtbN> well, at least .2 [19:54:32 CEST] <JEEB> I see no enable-nonfree there [19:54:39 CEST] <JEEB> waterworks: are you patching that out of configure? :P [19:54:40 CEST] <BtbN> Why would it be there? [19:54:47 CEST] <waterworks> The nvenc test is run at 14137. [19:54:47 CEST] <JEEB> nvidia stuff? [19:54:53 CEST] <BtbN> is not non-free [19:54:59 CEST] <JEEB> ok [19:55:12 CEST] <JEEB> right because of the RE'd'ish header :P [19:55:31 CEST] <BtbN> The header is just released by nvidia under MIT [19:55:34 CEST] <waterworks> My ffncvodec version is 8.1.24.3 [19:55:36 CEST] <BtbN> so there is no issue in the first place [19:56:03 CEST] <JEEB> ok [20:17:39 CEST] <waterworks> The error doesn't make much sense. [20:22:40 CEST] <BtbN> What does pkg-config --cflags ffnvcodec output? [20:24:03 CEST] <BtbN> and --modversion [20:28:14 CEST] <waterworks> $ pkg-config --cflags --modversion ffnvcodec Ignoring incompatible output option "--modversion" -IB:/msys64/home/CF/ffmpegbuild/include [20:37:10 CEST] <waterworks> ffnvcodec version is 8.1.24.3 [20:39:41 CEST] <feliwir> Hey, i am libav to decode a bink video. The problem i am having is that av_read_frame is always crashing when i reach EOF [20:39:54 CEST] <feliwir> I am doing this in C#, but the bindings aren't the issue [20:40:27 CEST] <JEEB> with the API I've generally been capable of finishing up by following https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [20:40:47 CEST] <JEEB> which is the basic documentation on how to decode/encode with the push/pull API [20:41:15 CEST] <feliwir> JEEB, i've been following this guide [20:42:25 CEST] <feliwir> and Reading frame/demuxing: https://github.com/OpenSAGE/OpenSAGE.FFmpeg/blob/master/src/OpenSage.FFmpeg… [20:42:50 CEST] <feliwir> Decoding: https://github.com/OpenSAGE/OpenSAGE.FFmpeg/blob/master/src/OpenSage.FFmpeg… [20:43:05 CEST] <feliwir> and i am crashing on the av_read_frame when almost all frames have been read [20:43:44 CEST] <feliwir> C# simply tells me "Memory corruption". Not very helpful [20:44:14 CEST] <feliwir> Is there some API misusage i am doing? [20:45:43 CEST] <feliwir> Help would be very appreciated [20:53:44 CEST] <feliwir> JEEB, you maybe? [20:54:38 CEST] <JEEB> tired after work so not touching certain things right now [21:03:57 CEST] <feliwir> Alright :) I guess C# code is one of them [21:38:56 CEST] <diverdude> hi. i made a windows c++ program and i need to install this: https://www.microsoft.com/en-us/download/details.aspx?id=52685 before i install the program....if i dont install that it will not run. Is there any way i can bundle this in the installer? I think its because of ffmpeg i need this [21:39:51 CEST] <JEEB> pretty sure there's a way to bundle those with your installer, but you only get that if you use the non-static CRTs [21:45:17 CEST] <feliwir> he, you helped him :D [21:51:22 CEST] <JEEB> feliwir: did I have to read a line of code? [21:55:14 CEST] <diverdude> JEEB: the non-static CRT's ? What is that? DLL files? [21:58:06 CEST] <feliwir> JEEB, i can describe the code to you [22:18:06 CEST] <tom13> someone make a ffmpeg remote-desktop for me [22:18:07 CEST] <waterworks> BtbN: Think it [22:18:27 CEST] <waterworks> 'd be worth to post tomorrow as well? [22:19:05 CEST] <BtbN> ffmpeg master and ffnvcodec builds fine for me on msvc. Must be something with your build env. [22:19:35 CEST] <waterworks> What could I have different? [22:19:54 CEST] <BtbN> no idea [22:20:11 CEST] <waterworks> Msys2 as well? [22:25:06 CEST] <waterworks> The only thing I do is start msys from a VS2017 environment and then use CC=cl before configure. [22:25:17 CEST] <waterworks> I hate using msys but whatever. [22:34:49 CEST] <waterworks> BtbN: You mind sharing what you have done to your build environment since what I have is all default? [22:35:08 CEST] <BtbN> Nothing special really [22:35:20 CEST] <BtbN> I'm using Cygwin as base though [22:35:37 CEST] <BtbN> But you do pass --toolchain=msvc to configure? [22:35:59 CEST] <waterworks> Yes [22:36:33 CEST] <waterworks> If I take that away then it cant find x264. [22:46:30 CEST] <waterworks> Better to use cygwin or something? [22:47:13 CEST] <BtbN> it shouldn't matter really [22:49:11 CEST] <waterworks> ffnvcodec shows up in pkg-config --list-all so there's no chance I've set up something wrong [22:49:39 CEST] <waterworks> And again that it obviously passes the nvenc test as shown in the config.log [22:50:03 CEST] <BtbN> it doesn't even seem to do it, which is weird [22:50:39 CEST] <waterworks> Is it not the one on line 14137? [22:50:49 CEST] <BtbN> that's the code for it. [22:51:00 CEST] <BtbN> and it's for nvenc, not ffnvcodec [22:51:25 CEST] <waterworks> ffnvcodec is just the headers though [22:56:35 CEST] <BtbN> That's all there is to it. [22:57:01 CEST] <waterworks> I know [22:58:24 CEST] <BtbN> Yeah, just confirmed it again, works fine for me and it detected with no configure commandline except toolchain=msvc [23:00:23 CEST] <waterworks> Pretty pathetic you even need to install a separate thing to even build but whatever. [23:07:25 CEST] <waterworks> Can't get it to work at all through msys2 [23:14:07 CEST] <wfbarksd_> is it fairly comon that the pts + duration of the last packet in a stream is less than the duration of the stream as reported on the AVStream from the demuxing context? [23:27:07 CEST] <BtbN> the timestamp can be anything, really. It does not indicate the stream length [23:27:25 CEST] <BtbN> they do not necesarily start at 0, or are monotonic [23:48:38 CEST] <wfbarksd_> So i guess the only way to get the "true" duration of the stream is to seek to the last packet and check? [23:48:45 CEST] <wfbarksd_> Btbn: [23:49:16 CEST] <BtbN> pretty much, yeah. [23:49:30 CEST] <BtbN> Or trust the container, if it specifies a duration [00:00:00 CEST] --- Thu Jun 7 2018

1 0

ffmpeg-devel.log.20180605
by burek 06 Jun '18

06 Jun '18

[01:47:54 CEST] <cone-139> ffmpeg 03Michael Niedermayer 07master:dce80a4b47ef: avcodec/amrwbdec: Fix division by 0 in find_hb_gain() [01:47:55 CEST] <cone-139> ffmpeg 03Michael Niedermayer 07master:e7dda51150b7: avcodec/opus_silk: Change silk_lsf2lpc() slightly toward silk/NLSF2A.c [02:48:52 CEST] <cone-139> ffmpeg 03Lou Logan 07master:1f75756c7194: doc/filters: mention required compile options for some filters [06:22:46 CEST] <rcombs> does lavc support HEVC tiling [06:25:11 CEST] <atomnuker> nope, not yet [06:25:39 CEST] <rcombs> is it possible to combine arbitrary HEVC packets together into a single packet with tiling [06:26:50 CEST] <atomnuker> I think so, the tiles are independent [06:27:01 CEST] <rcombs> might be a good solution to HEIF tiling, then [06:27:19 CEST] <rcombs> the demuxer could read the tile metadata and combine the 48 packets into one [06:29:21 CEST] <atomnuker> a bsf could do it too [06:31:23 CEST] <atomnuker> do they do the same tiling with h264? [06:50:43 CEST] <rcombs> nobody does h264 in HEIF afaik [06:50:56 CEST] <rcombs> atomnuker: bsfs can't take multiple input streams [06:51:21 CEST] <rcombs> plus that'd require you to pass all the inputs in manually, even if they did [07:02:21 CEST] <atomnuker> multiple input streams? my idea was to make the demuxer export all the tiles as packets in a single stream and have a bsf to combine them [07:03:33 CEST] <rcombs> hmm, I guess you could do that [07:03:55 CEST] <rcombs> they're coded as independent streams in the MP4, though [07:04:05 CEST] <rcombs> well, in that they're streams at all [07:04:25 CEST] <rcombs> but two tiles are coded the same way as two separate images, just with another blob containing data about how to merge them [07:04:40 CEST] <rcombs> atomnuker: how much do you know about HEVC tiling syntax anyway [07:05:00 CEST] <atomnuker> not much at all [07:05:09 CEST] <atomnuker> I think nevcairiel and wm4 were discussing this months ago [11:33:32 CEST] <cone-361> ffmpeg 03Paul B Mahol 07master:4d93c63e785d: avcodec/magicyuvenc: write max huffman length and extradata too [11:33:33 CEST] <cone-361> ffmpeg 03Paul B Mahol 07master:ddf6ff9dc6e6: avcodec/magicyuvenc: mark as not more experimental [15:52:57 CEST] <cone-361> ffmpeg 03Sergey Lavrushkin 07master:d8c0bbb0aa45: Adds TensorFlow backend for dnn inference module. [17:20:45 CEST] <cone-361> ffmpeg 03Sasi Inguva 07master:318d0fcbfe56: lavf/mov.c: Fix timestamps to be strictly monotonic for video also. [00:00:00 CEST] --- Wed Jun 6 2018

1 0

ffmpeg.log.20180605
by burek 06 Jun '18

06 Jun '18

[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-keyfr… [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

1 0