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

[burek]

[00:29:47 CEST] <SoMuchForSubtlet> kepstin: I got my script working "found desired audio at index 2 and best video at index 12"
[03:21:53 CEST] <pa[m]> OK, I just tried for way too long to figure out how to use ffmpeg to go from sRGB to Rec 709.  Attempted on a grayscale, linear gradient, just to focus on the gamma.  There does not seem to be any filter that gives a result comparable to AE or Fusion.
[03:23:04 CEST] <pa[m]> by 'any filter' i mean i tried swscale, colormatrix and colorspace
[07:02:40 CEST] <friendofafriend> I see there's no way to mux h265 into an FLV for RTMP streaming.  Can someone recommend another protocol to use instead?
[07:30:09 CEST] <kepstin> what are you streaming too? (what's gonna play it?)
[10:55:39 CEST] <realies> can you pipe raw h264 to fffmpeg and pipe it into nc with a streamable container?
[12:45:44 CEST] <DHE> realies: I dont' see why not... just a matter of selecting a streamable container. but I'd like to point out ffmpeg can output to tcp or udp itself as well, no NC required
[14:10:17 CEST] <TypX> Hi, I'm a little confused by doc/examples/filtering_audio.c
[14:10:46 CEST] <TypX> why is the abffer set in the output AVFilterInOut
[14:11:02 CEST] <TypX> and abuffersink in the input AVFilterInOut?
[14:21:22 CEST] <JEEB> TypX: I think those are meta'ish filters
[14:21:32 CEST] <JEEB> doc/examples/filter_audio.c: * (input) -> abuffer -> volume -> aformat -> abuffersink -> (output)
[14:21:36 CEST] <JEEB> doc/examples/filter_audio.c: * abuffer: This provides the endpoint where you can feed the decoded samples.
[14:21:39 CEST] <JEEB> doc/examples/filter_audio.c: * abuffersink: This provides the endpoint where you can read the samples afte
[14:21:58 CEST] <TypX> JEEB: oh indeed
[14:22:02 CEST] <TypX> thanks
[14:25:12 CEST] <JEEB> I have some code of my own where I init those two first, then start building the chain so that the abuffersink gets linked at the end
[14:26:04 CEST] <JEEB> also avfilter_graph_dump() can be useful for debugging
[14:26:25 CEST] <JEEB> together with avfilter_graph_set_auto_convert(filter_graph, AVFILTER_AUTO_CONVERT_NONE)
[14:26:28 CEST] <JEEB> :)
[14:27:06 CEST] <JEEB> of course the latter means that you have to insert an aresample filter manually into the chain
[14:27:20 CEST] <JEEB> but it also means that lavfi will not automagically insert random stuff into the chain when it feels like it :)
[14:29:01 CEST] <DHE> I suspect 'output' and 'input' are meant to be relative to the program interacting with the filter rather than the filter itself. you interact with the [a]buffer[sink] objects, not really the filtergraph itself
[14:29:38 CEST] <JEEB> yes
[14:51:05 CEST] <DisgruntledCoder> hi there, is it possible with FFmpeg to get the specific channel mapping (in terms of L R C LFE LS RS etc...) of a given file, beyond what 'channel_layout' returns (which seems to be either wrong or just not meant to contain that info)?
[14:54:48 CEST] Action: DisgruntledCoder channels JEEB :D
[15:13:49 CEST] <Spaligor> hi guys
[15:15:07 CEST] <Spaligor> i need help, i'm trying to keep keep a stream buffer of last 5 minutes recorded from a camera
[15:15:39 CEST] <Spaligor> how can i do it? i've read about circular buffer and even did some of it by segmenting ecc
[15:15:57 CEST] <Spaligor> but there's a way to keep this 5 minutes recording and then save it to a file?
[15:25:54 CEST] <DHE> and he's gone
[15:28:15 CEST] <friendofafriend> I'd love a recommendation of an RTSP server.  I'm streaming a few h265 camera streams to my friend and a smartphone once in a while.  Is live555 the way to go?
[15:30:59 CEST] <ksk> friendofafriend: I dont really know what RTSP nor RTMP actually are, but you can convert one to the other and combine that with nginx from looking at the webz ;)
[15:31:56 CEST] <GuiToris> hey, how can I make a 25fps video from a 50fps video? ffmpeg -framerate 50 -i seq_%3d.png -framerate 25 output.mp4  didn't do the trick
[15:32:31 CEST] <ksk> GuiToris: just a quess: remove the "-framerate 50" argument?
[15:32:34 CEST] <ksk> guess*
[15:33:00 CEST] <GuiToris> the first one supposed to be the input framerate
[15:33:08 CEST] <friendofafriend> ksk: RTMP won't support h265 in an FLV container, it's an Adobe thing.
[15:33:22 CEST] <ksk> is that how ffmpeg works GuiToris? I am really a noob, but I am inclined to say no ;)
[15:33:34 CEST] <ksk> friendofafriend: ah okay. thanks.
[15:33:59 CEST] <GuiToris> ksk: yes?!
[15:35:00 CEST] <friendofafriend> GuiToris: Do you want to drop frames, or a video that runs at half speed?
[15:35:12 CEST] <GuiToris> friendofafriend, drop every other frame
[15:35:24 CEST] <GuiToris> the speed should stay the same
[15:35:54 CEST] <friendofafriend> GuiToris: ffmpeg -i <input> -filter:v fps=fps=25 <output>
[15:36:15 CEST] <ksk> GuiToris: so it rather seems "no!?" :P
[15:36:24 CEST] <GuiToris> ksk, please
[15:39:07 CEST] <GuiToris> thank you it works friendofafriend
[15:39:18 CEST] <GuiToris> ksk, I need the first -framerate 50 because my source is not a video
[15:39:32 CEST] <friendofafriend> Always welcome, GuiToris.  Glad to hear it.
[16:00:30 CEST] <Ristovski> Any idea why kmsgrab seems to cause weird color issues when encoding with VAAPI?
[16:00:42 CEST] <Ristovski> (normal encoding is broken, so can't test if it's specific to VAAPI)
[16:00:59 CEST] <Ristovski> Currently running ` ffmpeg -threads:v 2 -framerate 60 -f kmsgrab -i - -vf 'hwmap=derive_device=vaapi,scale_vaapi=w=1366:h=768:format=nv12' -c:v h264_vaapi -profile:v high -bf 0 -y output.mp4`
[16:01:17 CEST] <Ristovski> which works very well but it seems to mess certain colors, maybe because of the bgr0 format
[16:03:41 CEST] <Ristovski> It seems to "smear" colors, black/white text is text perfect but anything that has colors appears fuzzy
[16:04:34 CEST] <Ristovski> screenshot: https://pybin.pw/gDwf.png recording: https://pybin.pw/ctcS.png
[16:09:15 CEST] <durandal_1707> DisgruntledCoder: channelmap filter
[16:23:36 CEST] <kepstin> Ristovski: that's just a side-effect of the conversion to 4:2:0 sampling, it has less color resolution
[16:23:57 CEST] <Ristovski> kepstin: Ah, that sucks :/
[16:24:07 CEST] <Ristovski> kmsgrab indeed has almost no performance overhead
[16:24:09 CEST] <kepstin> totally expected. And your hardware encoder probably can't do 4:4:4, so if you want to avoid that you'd have to do software encoding.
[16:24:49 CEST] <Ristovski> x11grab works fine but not as efficient as kmsgrab
[16:25:10 CEST] <kepstin> x11grab vs kmsgrab won't make a difference in terms of this issue
[16:25:26 CEST] <Ristovski> Well it does for me, x11 grab has no such issues
[16:26:10 CEST] <kepstin> Ristovski: you must be using a different encoder or other different options then, because it's the conversion to 4:2:0 sampling that causes the issue
[16:26:35 CEST] <kepstin> note that libx264 (software encoder) can do 4:4:4 sampling which avoids the issue - but is less compatible with players.
[16:27:01 CEST] <Ristovski> `ffmpeg -init_hw_device vaapi=foo:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device foo -f x11grab -framerate 60 -video_size 1366x768 -i :0.0 -filter_hw_device foo -vf 'format=nv12|vaapi,hwupload' -c:v h264_vaapi -y output.mp4`
[16:27:14 CEST] <Ristovski> Seems pretty standard to me
[16:27:18 CEST] <Ristovski> and it works just fine
[16:27:56 CEST] <kepstin> i'd expect the exact same results from that, huh.
[16:28:28 CEST] <kepstin> if you could maybe give a screenshot of the issue? it could be something different from what I'm thinking it is.
[16:28:48 CEST] <furq> i assume it's the colours rather than the blurry text
[16:28:52 CEST] <Ristovski> furq: yes
[16:29:02 CEST] <Ristovski> Stuff like cyan appears as white
[16:29:23 CEST] <kepstin> oh, you're actually getting *wrong* colors, not *blurry* colors?
[16:29:30 CEST] <furq> i would guess scale_vaapi is just doing a shitty job of the rgb to yuv conversion
[16:29:37 CEST] <Ristovski> kepstin: well they are also blurry
[16:29:40 CEST] <furq> there's nothing else in that pipeline that could be to blame
[16:29:48 CEST] <furq> and yeah the blurriness is just going to happen. there's nothing you can do about that
[16:29:53 CEST] <kepstin> Ristovski: blurry is normal and expected, wrong is an issue.
[16:30:06 CEST] <Ristovski> kepstin: kmsgrab also produces a severely darker recording
[16:30:20 CEST] <Ristovski> furq: doesn't x11grab also do rgb to yuv?
[16:30:37 CEST] <furq> no and neither does kmsgrab
[16:31:21 CEST] <Ristovski> Let me try getting a better screenshot
[16:31:22 CEST] <kepstin> Ristovski: it would be good to try using kmsgrab to grab a single frame as png and see if it shows the same problem.
[16:31:28 CEST] <furq> yeah
[16:31:37 CEST] <kepstin> (or, i missed the screenshots originally, oops)
[16:31:52 CEST] <furq> well i assume one is print screen which isn't the same as what kmsgrab is outputting
[16:32:18 CEST] <furq> like i said i assume it's scale_vaapi but if you're running x11grab and scale_vaapi and it works then i have no idea
[16:32:20 CEST] <kepstin> that looks like chroma samples in the wrong location, tbh
[16:33:27 CEST] <kepstin> but that said, a single pixel width line of yellow over blue is impossible to represent in yuv 4:2:0 sampling
[16:33:31 CEST] <kepstin> so... :/
[16:33:47 CEST] <Ristovski> Hmm, when I do kmsgrab to get a png, OR when using kmsgrab with software encoding I get a pixel soup - https://pybin.pw/K52L.png
[16:34:30 CEST] <Ristovski> however, judging from the colors of the pixels (lol) it does appear to be fine
[16:35:07 CEST] <kepstin> yeah, so looks like an issue from the rgb to yuv 4:2:0 sampling. Avoid brightly colored single-pixel-wide lines, especially over backgrounds of different colors, and it'll be fine.
[16:35:51 CEST] <kepstin> that said it also looks like there's a color range issue, it's not properly converting from pc (full) range to video (limited) range
[16:36:10 CEST] <Ristovski> What about the weird corruption?
[16:36:17 CEST] <kepstin> dunno about that :/
[16:36:54 CEST] <Ristovski> I mean, odd that it works when encoding via vaapi
[16:38:41 CEST] <kepstin> anyways, if you're getting better results with that x11grab command instead of the kmsgrab one, it's probably because in the x11grab one the rgb to yuv conversion is done on the cpu in ffmpeg with a better algorithm :/
[16:39:39 CEST] <Ristovski> Hmm, the kmsgrab with corruption indeed seems to be perfect apart from the weird corruption
[16:44:22 CEST] <Ristovski> furq: and yes, x11grab with scale_vaapi works fine
[16:46:12 CEST] <Ristovski> here's a debug log of kmsgrab capturing a single frame which causes the corruption - https://bpaste.net/show/b3e090faf293
[17:14:18 CEST] <TheAMM> I'm not in the position to test this right now, so I have to ask instead: does -pass 1/2 work for libx265 instead of having to use -x265-params pass1/2?
[17:19:01 CEST] <kepstin> TheAMM: no, it's not wired up.
[17:32:23 CEST] <ncouloute> So I narrowed down my frame shifting issue is due to using the hwaccel qsv decoder. It was causing the 4 frame shift. Any flags that will fix that? When I use software decode I lose frames. So thats another issue that
[18:39:35 CEST] <ncouloute> For the software decoder. It only decodes 16093 of 16200 of the frames. One of the errors I see is. Application provided invalid, non monotonically increasing dts to muxer in stream 0: 2865>= 2865. I do notice that there appears to be a few frames of video of a future part of the video that plays inbetween each "clip". The HW decoders will decode all the frames properly. Any ideas?
[18:43:30 CEST] <JEEB> are you sure you are counting decoded frames?
[18:43:40 CEST] <JEEB> since that message comes from the muxer, not decode
[18:43:42 CEST] <JEEB> *decoder
[18:56:55 CEST] <blloyd> I am using libavcodec and friends from ffmpeg 4.1.3 to decode a h264 stream.  I am getting frequent invalid NAL errors.  Is there a way to continue decoding that frame or do I have to start on the next packet?  It seems after an error, the parser gets stuck in a near infinite loop just consuming bytes without outputting another frame.
[18:59:05 CEST] <ncouloute> I'm going off the frame=xxx after ffmpeg is done and what media info reports for both the container and the video stream. On the converted file it freezes frame until the next clip versus the original which plays a few frames of video from different part of the file.
[19:03:28 CEST] <JEEB> ffmpeg -vsync passthrough -v verbose -i FILE -map 0:v -f null -
[19:03:32 CEST] <JEEB> this should decode only
[19:03:41 CEST] <JEEB> through the ffmpeg.c command line app
[19:07:25 CEST] <ncouloute> okay let me try that
[19:18:01 CEST] <ncouloute> Here is what is says for input: 16200 packets read (650416459 bytes); 16093 frames decoded; Total: 16200 packets (650416459 bytes) demuxed
[19:36:46 CEST] <TheAMM> Have you determined you actually lose *frames*?
[19:37:04 CEST] <TheAMM> IIRC something something h264 frames can sometimes be spread over two packets
[19:38:00 CEST] <TheAMM> something about fields, saw mention of it in vapoursynth sources
[19:40:00 CEST] <ncouloute> I am losing frames.. but it is technically the same frames that are in different parts of the video. In those area of the converted files the video itself just shows the same frame for 3 seconds. Hopefully that makes sense
[19:41:15 CEST] <JEEB> what have you verified against that the stream is as passed decode'able A->B, just out of curiosity
[19:41:27 CEST] <JEEB> also is anything funky like field duplication being utilized
[19:45:28 CEST] <ncouloute> Not sure I know what you mean by the first part but the Original file is VFR and Interlaced (Separated Fields, TFF). So there could be something going on with the built in deinterlacer. The HW decoders(cuvid\qsv) seem to decode it correctly but it has other issues like frames being shifted
[20:29:20 CEST] <pa[m]> anyone know if it's possible to embed an icc profile name in a quicktime mov, such that Adobe programs understand what color space it's in?
[20:32:34 CEST] <JEEB> qtff documentation is probably your best bet regarding that
[20:32:55 CEST] <JEEB> https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/
[20:35:46 CEST] <JEEB> ok, seems like mov files output in QTIF (quicktime image) format have an iicc atom
[20:38:53 CEST] <saml_> is per video encoding parameter optimization worth effort?
[20:39:25 CEST] <saml_> given a video, find out the best ffmpeg arguments for that particular video
[20:52:56 CEST] <JEEB> latter sets the encoder's AVCodecContext to that, while if I understand setparams correctly it just sets the outgoing AVFrames' primaries to that
[20:53:21 CEST] <JEEB> a lot of encoders initialize when the encoder is initialized, so only the AVCodecContext part would get applied
[20:53:30 CEST] <JEEB> (if the encoder utilizes that value)
[20:53:49 CEST] <JEEB> in theory an encoder wrapper could wait until the first AVFrame is fed to it
[20:53:59 CEST] <JEEB> and would configure itself accordingly
[20:55:43 CEST] <JEEB> there's functionality in the libx264 wrapper to re-configure when some paramters change in the input AVFrames, but even after patching x264 a bit I never got that stuff to be applied with colorspace info. but I probably just failed at life / PEBKAC :P
[20:56:21 CEST] <JEEB> if I ever have the time again I might look into that again, but even when it seemed like you hit the "please reconfigure" switch it would still not do it
[20:56:38 CEST] <JEEB> (and this was before any pictures were fed to the encoder, so in theory the following picture would have been a random access point)
[20:57:01 CEST] <JEEB> which is the main thing that people talk about, that the configuration might get applied later
[21:13:25 CEST] <__Shepherd> this guy is trying to decode a ".axxc" file
[21:13:46 CEST] <ncouloute> It is not so much that I'm worried about the frames lost as there. It is that the timing is also thrown off as a result. I guess I should play around with the *synth programs and see if I can get them to decode it properly then pass that on to ffmpeg. I deal with a lot of garbage video.. so that may be the only way to convert it
[21:14:13 CEST] <__Shepherd> apparently it an encrypted audio file
[21:14:58 CEST] <__Shepherd> so gotta provide a key when passing it to ffmpeg
[21:15:47 CEST] <__Shepherd> he's got errors doing a stream copy
[21:15:57 CEST] <__Shepherd> looking at his log
[21:17:03 CEST] <__Shepherd> his decoding is stuck at the first frame and has outputed about 20MB of data... on the very first frame
[21:18:16 CEST] <__Shepherd> I had an issue like this in the past with an flv container but can't remember what was it that I did to fix that issue
[21:20:19 CEST] <__Shepherd> https://www.reddit.com/r/ffmpeg/comments/c21nxt/convert_axxc_format/
[22:35:28 CEST] <SortaCore> hey fellas
[22:35:50 CEST] <SortaCore> anyone know password-protected video codecs/container codecs? will be played back on Windoze
[23:21:35 CEST] <SortaCore> back in a bit, compy needs to reboto
[23:47:38 CEST] <FlipFlops2001> I've been re-encoding my videos to the h.265 format using ffmpeg piped to x265. Is there any advantage to "-hwaccel dxva2" or "-hwaccel auto" in this process? (Video processor: AMD 6670 supports DXVA2)
[00:00:00 CEST] --- Wed Jun 19 2019