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

[burek]

[00:22:40 CEST] <sine0> ok hear me out. is it possible to do any kind of color grading / brightness color processing with ffmpeg? like some kind of gui tool to tweak a single frame in gimp etc and the process using data in ffmpeg
[00:28:53 CEST] <JEEB> sine0: there's some lut support so if you have something that lets you preview the result of the lut so you can adjust it, then you could execute it later
[00:29:48 CEST] <JEEB> for things where preview is needed I usually utilize vapoursynth with Vapoursynth Editor. the output of vapoursynth can then be fed into something like ffmpeg.c for encoding.
[00:32:40 CEST] <sine0> ahh coo coo
[00:32:45 CEST] <sine0> +l
[01:43:00 CEST] <miscapples> Is ffmpeg able to spit out the base64 version of any image?
[01:43:15 CEST] <miscapples> If so, how?
[01:44:00 CEST] <JEEB> well you'd first have to define "base64 version"
[01:44:21 CEST] <JEEB> do you mean the compressed file? do you mean the raw RGB image?
[01:52:13 CEST] <miscapples> JEEB: I don't know. I just know that in HTML, these days, you are able to do a base64: thing instead of actually referring to a file on a file system.
[01:52:35 CEST] <miscapples> JEEB: And I have a PNG or JPEG image which I'd like to turn into that format so it works in HTML context.
[01:53:45 CEST] <JEEB> just use a short python script or something to write out the image as base64 :P
[01:53:56 CEST] <JEEB> pretty sure there are command line tools already for it too
[01:54:47 CEST] <miscapples> You mean it's as simple as simply doing base64($image_contents)?
[01:54:51 CEST] <JEEB> FFmpeg in theory could have a base64 "protocol" where you could write a jpeg or png output like "base64://blah.jpg" but I don't think FFmpeg has that
[01:55:15 CEST] <miscapples> That blah.jpg part confuses me.
[01:55:25 CEST] <JEEB> just a file name to have an extension :P
[01:55:33 CEST] <JEEB> which lets FFmpeg guess that you want jpeg
[01:55:39 CEST] <JEEB> without -f jpeg or -f mjpeg
[01:56:19 CEST] <JEEB> anyways, if you already have images that you want to base64'ify, there's plenty of tools for that
[01:56:28 CEST] <JEEB> literally just standard base64 encode the bytes in the files
[01:56:29 CEST] <JEEB> done
[01:56:30 CEST] <JEEB> :P
[01:59:11 CEST] <JEEB> also coreutils has base64 which encodes and decodes
[01:59:26 CEST] <JEEB> so yes, there's a base utility that lets you make base64 out of files and standard input
[01:59:39 CEST] <miscapples> Cool. Got it working.
[02:00:23 CEST] <miscapples> But anything but really small/simple images is probably madness.
[02:00:39 CEST] <miscapples> For example, embedding huge base64 blobs in each e-mail sent to a lot of people = :|
[02:00:47 CEST] <JEEB> yes
[02:01:06 CEST] <miscapples> Are those kinds of images "spared" from the blocked-by-default security thing in e-mail clients, BTW?
[02:01:25 CEST] <miscapples> The reason they are blocked is because they make external requests normally, right?
[02:01:29 CEST] <JEEB> yea
[02:01:33 CEST] <miscapples> Not because the images themselves can contain malicious data?
[02:01:44 CEST] <JEEB> you don't need requests for that so I would guess you could get the clients to load stuff like that
[02:01:52 CEST] <JEEB> but I have no idea how those things work exactly
[02:02:06 CEST] Action: JEEB hits the sack, 4 hours to $dayjob and some sleep is needed
[02:02:10 CEST] <miscapples> Me neither, and it's a nightmare to attempt to set them up to "test".
[02:02:16 CEST] <miscapples> That sucks.
[02:02:21 CEST] <miscapples> Thanks for the help.
[02:02:38 CEST] <miscapples> I recently smashed my clock radio, so now the only thing I can go by is my natural feeling of tiredness.
[11:21:18 CEST] <termos> Is there en ETA on the next major FFmpeg release? Last one was in November
[11:25:21 CEST] <pink_mist> ffmpeg releases happen when they're done. there is no timeline. officially ffmpeg is meant to be used from git master
[11:25:46 CEST] <pink_mist> the only reason releases are done at all is because distros feel better that way afaik
[11:26:47 CEST] <pink_mist> either way, 4.1.3 is much more recent than november
[11:28:00 CEST] <pink_mist> well ok, I suppose there is a loose timeline in that new versions are expected approximately every 6 months
[11:28:07 CEST] <pink_mist> but it's far from hard and fast afaik
[11:45:51 CEST] <JEEB> supposedly we're entering a release time soon
[11:46:02 CEST] <JEEB> there was a mailing list post some time ago reminding people of this
[12:40:55 CEST] <termos> ah okey, just from a stability standpoint i'd feel safer running on an official release
[12:41:53 CEST] <JEEB> we do have FATE of course (fate.ffmpeg.org)
[12:42:03 CEST] <JEEB> and generally I think master gets more automated testing?
[12:42:19 CEST] <JEEB> although there are some release FATE machines
[12:42:39 CEST] <DHE> there's something to be said about API stability, even though ffmpeg is good about its deprecation cycles
[18:33:27 CEST] <Shezi> A quick question for clarification. If I am streaming a local video to a remote rtmp server with some encoding the speed stays 0.98x to 1x. If I take the input from a http url for the same ffmpeg encoding command, the speed drops to 0.28x . We have 10 Gbps connection, so the bandwidth is not an issue at all. Can some body provide some information for this issue?
[18:36:06 CEST] <Shezi> Both files are same.
[18:36:13 CEST] <Shezi> Any body? thanks
[20:15:18 CEST] <Shezi> Hi can any body help with my above query
[20:15:20 CEST] <Shezi> ?
[20:21:13 CEST] <DHE> there isn't nearly enough information there. I'm inclined to assume there's something wrong with the sending host in HTTP mode.
[20:22:26 CEST] <TheAMM> My guess is seeking, but I don't know the details of ffmpeg's HTTP deals
[20:23:07 CEST] <TheAMM> It's also technically possible you're saturating your connection with up/down at the same time but you've surely considered this and checked all bottlenecks
[20:23:48 CEST] <TheAMM> You can test piping from curl to ffmpeg, so you'll be sure that ffmpeg doesn't do weird byte-range requests (but again, dunno if ffmpeg would do them)
[20:34:24 CEST] <Shezi> Actually -c copy works very well without any issues. Even bitrate lower than 4000k also works ok
[20:34:52 CEST] <Shezi> But when the bitrate is higher than 4000k then during encoding the speed drops down alot
[20:38:37 CEST] <Shezi> I have checked there is no bottleneck related to saturating bandwidth.
[20:39:13 CEST] <Shezi> How do you pipe from curl to ffmpeg , do you have some command?
[20:39:17 CEST] <Shezi> I mean example.
[20:40:44 CEST] <DHE> curl http://inputurl | ffmpeg -i - [...]
[21:00:58 CEST] <Shezi> Ok thanks
[21:01:02 CEST] <Shezi> Will try
[21:01:15 CEST] <Shezi> i will get back to you. Many thanks for this.
[22:19:09 CEST] <Shezi> Actually I tried with curl, but it seems it downloads the whole file. My download speed was 113 MB/s.
[22:19:48 CEST] <Shezi> I just don't understand one small thing. The same file from http if used with -c copy option get streamed without issues at 1x speed.
[22:20:16 CEST] <Shezi> But doing an encoding with all available threads the speed drops to 0.28x. If I use the same encoding command on the same file which is stored locally then the speed is again 1x.
[23:33:20 CEST] <Shezi> It seems I found the issue. Some how if the stream has multiple streams then from http url it takes the speed of 0.28x . If I leave only audio and video and remove other streams, and put the file in web server and try to access it. Then it works fine.
[23:33:38 CEST] <Shezi> I just do ffmpeg input -c copy output
[23:33:46 CEST] <Shezi> To strip the other streams
[00:00:00 CEST] --- Thu May 23 2019