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

[burek]

[00:00:25 CEST] <t4nk834> i need help
[00:00:34 CEST] <t4nk834> Invalid file index 1 in filtergraph description [0:v]yadif,scale=hd1080,setsar=1[b];[b][1:v]overlay=main_w-overlay_w-10:main_h-overlay_h-10.
[00:00:48 CEST] <t4nk834> without yadif i have logo
[01:17:07 CEST] <hseg> How do I replace the last second of a video by a black screen?
[01:17:29 CEST] <hseg> i.e. I'd like the audio to keep playing, but no video data to be provided.
[01:23:12 CEST] <furq> hseg: -vf "drawbox=t=iw:enable='between(t,999,1000)'"
[01:23:17 CEST] <furq> assuming the video is 1000 seconds long
[01:26:25 CEST] <hseg> Nice. t=iw makes the thickness of the box edges the entire width of the frame?
[01:26:44 CEST] <furq> it sets the thickness to whatever the video width is
[01:26:49 CEST] <hseg> and enable controls when the filter runs.
[01:26:57 CEST] <furq> if you have vertical videos you'll probably want to make that more robust
[01:27:25 CEST] <hseg> In what way isn't that robust?
[01:27:48 CEST] <furq> never mind i'm stupid
[01:28:08 CEST] <hseg> The left and right edges of the box will cover the entire video, right?
[01:28:13 CEST] <furq> yeah
[01:28:25 CEST] <hseg> Nice, thank you.
[01:28:46 CEST] <hseg> Will only be able to test this tomorrow, as it's getting quite late here.
[01:29:08 CEST] <hseg> BTW, any idea why inputs don't support -to?
[01:30:18 CEST] <furq> nothing that springs to mind
[01:30:29 CEST] <hseg> (also, I suppose I could put that filter within whatever filter_complex I'm using the video in)
[01:30:45 CEST] <furq> yeah -vf and -filter_complex will overwrite each other
[01:31:02 CEST] <hseg> OK
[01:33:52 CEST] <hseg> Missed your answer re -to if you answered it.
[01:34:01 CEST] <furq> 00:30:17 ( furq) nothing that springs to mind
[01:34:42 CEST] <hseg> Ah. It's annoying, since it means that whenever I'm clipping I need to compute durations instead of giving start/stop timestamps.
[01:35:28 CEST] <furq> if you're reencoding you can use -vf trim
[01:36:08 CEST] <furq> it doesn't take duration specs though so you'd need to calculate seconds
[01:36:45 CEST] <furq> actually it says it does but i remember people complaining that it either doesn't actually or it's impossible to escape correctly
[01:38:52 CEST] <hseg> Hm. That looks useful, thanks. I'm reencoding because the concat filter is the only way I found that robustly concated stuff, but recent experiments suggest that I could have just used the demuxer instead to save time.
[01:39:14 CEST] <hseg> Eh. It's an overnight job anyway, so I don't care as much.
[01:46:55 CEST] <hseg> Thanks, and goodnight!
[02:14:52 CEST] <jpsharp> okay, next question.  I'm using ffmpeg to play an rtmp stream out to /dev/fb0.  Everything bops along until what looks like the rtmp server changes files and the DTS from the server drops to 0.  ffmpeq subsequently freaks out and stops playing video.
[02:15:16 CEST] <jpsharp> I have +igndts in my -fflags, but ffmpeg still complains and hangs.
[10:28:34 CEST] <k_sze[work]> Is there a way to get some meaningful error message in case sws_getContext fails?
[10:28:36 CEST] <k_sze[work]> https://www.ffmpeg.org/doxygen/3.1/group__libsws.html#gaf360d1a9e0e60f906f74d7d44f9abfdd
[10:31:25 CEST] <nonex86> enable debug in ffmpeg api
[10:31:32 CEST] <nonex86> verbose level for example
[10:32:04 CEST] <k_sze[work]> But that's going straight to stderr, right?
[10:32:26 CEST] <nonex86> you can redirect it
[10:32:40 CEST] <nonex86> by providing own log function
[10:32:50 CEST] <nonex86> if you hate stderr
[10:35:04 CEST] <k_sze[work]> This? https://www.ffmpeg.org/doxygen/3.1/group__lavu__log.html#ga14034761faf581a8b9ed6ef19b313708
[10:42:16 CEST] <nonex86> k_sze[work]: exactly
[10:47:44 CEST] <k_sze[work]> There's no description of what the arguments are supposed to be. :(
[10:48:00 CEST] <nonex86> ?
[10:48:16 CEST] <nonex86> as a last resort you can use source code of ffmpeg
[10:48:24 CEST] <nonex86> this helps ;)
[10:49:14 CEST] <nonex86> static void log_callback(void*, int, const char*, va_list);
[10:49:29 CEST] <nonex86> av_log_set_callback(FFMPEGLib::log_callback);
[10:49:45 CEST] <nonex86> void FFMPEGLib::log_callback(void *avcl, int level, const char *fmt, va_list vl)
[10:49:50 CEST] <nonex86> just an example
[10:50:07 CEST] <nonex86> 		_vsnprintf_s(buf, kBufSize, _TRUNCATE, fmt, vl);
[10:50:07 CEST] <nonex86> 		OutputDebugStringf("[0x%08x][FFMPEG] %s", GetCurrentThreadId(), buf);
[10:51:18 CEST] <nonex86> and pass the message to ffmpeg default callback - av_log_default_callback(avcl, level, fmt, vl);
[10:51:23 CEST] <nonex86> if you need
[10:51:25 CEST] <nonex86> thats all
[11:21:20 CEST] <k_sze[work]> Is it generally ok if I call avcodec_close or avcodec_free_context with an AVCodecContext that hasn't been flushed yet?
[14:12:29 CEST] <ootje> what is the -filter_complex equivalent of    -loop 1 -i image.png -t 2  ?    tried   -filter_complex "movie=image.png:loop=0, setpts=PTS-STARTPTS" -t 2  but it just renders on and on and on without stopping. tried adding ", trim=0:2" also but nope
[14:38:00 CEST] <Kadigan_KSB> Hey. Quick question: when I encode webm using ffmpeg, I invariably end up with a opsnr.stt file. What flag do I need to use to disable this behavior? (from what I can see on the web, it's PSNR packet data?)
[14:39:13 CEST] <Kadigan_KSB> I can work around the issue by deleting it afterwards, but can I disable this?
[15:04:52 CEST] Action: Kadigan_KSB sighs
[15:08:02 CEST] <Kadigan_KSB> http://pastebin.com/raw/7FKArVAX -- here you go
[15:09:08 CEST] <furq> Kadigan_KSB: looks like your libvpx was built with --enable-psnr
[15:09:16 CEST] <Kadigan_KSB> (The AVOption error is in reference to -b:a, since the input.mov file does not have an audio channel)
[15:09:20 CEST] <Kadigan_KSB> Yeah, I was afraid of that.
[15:09:29 CEST] <furq> what distro is that
[15:10:01 CEST] <Kadigan_KSB> As in version?
[15:10:11 CEST] <furq> if you want
[15:10:18 CEST] <furq> i mostly just wanted to make a mental note to avoid it
[15:10:41 CEST] <Kadigan_KSB> http://pastebin.com/raw/1hFLpvKh
[15:10:55 CEST] <furq> i meant your linux distro
[15:10:59 CEST] <Kadigan_KSB> Ah, no.
[15:11:07 CEST] <Kadigan_KSB> It's OS X 10.9.5
[15:11:08 CEST] <furq> oh right, llvm
[15:11:10 CEST] <furq> yeah
[15:11:16 CEST] <furq> is this ffmpeg from homebrew or something
[15:11:22 CEST] <Kadigan_KSB> Yeah, MacPorts.
[15:11:46 CEST] <furq> if ports means like freebsd ports then it shouldn't be too hard to rebuild libvpx
[15:12:03 CEST] <furq> but yeah you should report that upstream, it's definitely wrong for that to be default
[15:12:04 CEST] <Kadigan_KSB> Well, it works perfectly well for my needs. The leftover file is merely a nuisance.
[15:13:36 CEST] <Kadigan_KSB> Anyway, thanks for the assist. :)
[16:05:15 CEST] <Kadigan_KSB> Hm... I have a second issue. :/
[16:05:26 CEST] <Kadigan_KSB> This one is much more about color grading that actual compression, but here goes.
[16:05:48 CEST] <Kadigan_KSB> I check my videos at each step of the way, and they all look fine -- until they get to YouTube, or some other online player, whatever.
[16:06:00 CEST] <Kadigan_KSB> For some reason I'm seeing a HUGE shift towards magenta.
[16:06:13 CEST] <furq> what's the source pixel format
[16:06:15 CEST] <Kadigan_KSB> Now, from what I can google up, this may be related to color profiles.
[16:06:40 CEST] <furq> if it's not yuv420p then youtube will convert to that, and evidently it's not very good at it
[16:07:09 CEST] <furq> if it's already yuv then it's probably not that
[16:07:24 CEST] <Kadigan_KSB> It's most likely yuv422p10le
[16:07:37 CEST] <Kadigan_KSB> (Prores source from a Canon cam)
[16:07:42 CEST] <furq> it never hurts to do the format conversion yourself
[16:07:44 CEST] <Kadigan_KSB> (well, Prores-encoded)
[16:08:08 CEST] <Kadigan_KSB> Oh, wait -
[16:08:12 CEST] <furq> assuming you're already transcoding
[16:08:14 CEST] <Kadigan_KSB> for youtube I encode to .mkv
[16:08:19 CEST] <Kadigan_KSB> and I do pix_fmt yuv420p
[16:08:24 CEST] <furq> never mind then
[16:08:52 CEST] <Kadigan_KSB> I also check the .mkv, at least using VLC (I'm on a Mac, it's hard to use the wonderful myriad of WINDOWS tools :D)
[16:09:05 CEST] <Kadigan_KSB> and it checks out. But then on uploading, it doesn't.
[16:09:08 CEST] <furq> check it with mpv in opengl mode if you can
[16:09:21 CEST] <furq> it does sound like some kind of colourspace issue though
[16:09:25 CEST] <Kadigan_KSB> What is MPV?
[16:09:29 CEST] <furq> which isn't something i've ever had to deal with
[16:09:38 CEST] <furq> https://mpv.io/
[16:09:57 CEST] <Kadigan_KSB> I'm working on calibrated displays, so there's a big chance the ICC profile gets saved to the video at SOME point.
[16:10:11 CEST] <furq> i didn't know icc profiles in video was even a thing
[16:10:34 CEST] <furq> but if it is then it's probably safe to assume youtube wants nothing to do with it
[16:11:01 CEST] <Kadigan_KSB> Actually, from what I'm lead to believe by folk at CreativeCow,
[16:11:15 CEST] <Kadigan_KSB> it's ffmpeg and other tools that don't, and YouTube/Vimeo apparently RESPECT the profiles.
[16:12:03 CEST] <furq> if the transcoded version plays back ok then that shouldn't be the issue
[16:12:09 CEST] <furq> unless it's being passed through as metadata
[16:13:17 CEST] <Kadigan_KSB> I thought I had that killed via -map_metadata -1
[16:14:41 CEST] <furq> maybe vlc is using your monitor's default icc and youtube is using a different one
[16:14:50 CEST] <Kadigan_KSB> It's possible.
[16:15:34 CEST] <wildefyr> best way to compile ffmpeg on windows under msys? configure complains heavily about not to use msys, but instead use mingw, but I thought msys was built on mingw?
[16:16:45 CEST] <Kadigan_KSB> wildefyr: there's an msys-based autobuilder for building under win32 and win64
[16:16:51 CEST] <Kadigan_KSB> -- what I know
[16:16:53 CEST] <wildefyr> link?
[16:17:19 CEST] <Kadigan_KSB> https://github.com/jb-alvarado/media-autobuild_suite
[16:17:31 CEST] <wildefyr> that'd be great, but I'm attempting to build ffmpeg with the nvidia sdk to enable the nvenc encoder
[16:18:08 CEST] <Kadigan_KSB> furq: I have mpv -- what do I do?
[16:18:36 CEST] <furq> mpv --vo=opengl filename
[16:18:50 CEST] <nonex86> i build ffmpeg on msys with ms vc++ without any problems
[16:18:59 CEST] <furq> there are some options for using icc profiles as well
[16:19:37 CEST] <furq> https://mpv.io/manual/stable/#video-output-drivers-target-prim
[16:19:41 CEST] <furq> that and a few below it
[16:19:55 CEST] <wildefyr> nonex86, it's odd, configure refuses to 'make' a MakeFile
[16:20:06 CEST] <wildefyr> latest git version here
[16:20:09 CEST] <Kadigan_KSB> Well, I don't know if it ran in OpenGL (seeing as Mac OS X has only OpenCL?) but it looked fine.
[16:21:58 CEST] <nonex86> ffmpeg version 3.1.4 Copyright (c) 2000-2016 the FFmpeg developers
[16:21:58 CEST] <nonex86>   built with Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x64
[16:21:58 CEST] <nonex86>   configuration: --toolchain=msvc --enable-static --disable-shared --enable-avresample --enable-gpl --enable-libx264 --enable-libx265 --enable-libvpx --enable-libmp3lame --enable-libmfx --enable-nvenc --enable-nonfree --enable-libkvazaar --enable-libvorbis --enable-libopus --enable-libxvid
[16:22:04 CEST] <nonex86> something like that...
[16:23:26 CEST] <wildefyr> okay I'll --toolchain=msvc
[16:24:57 CEST] <nonex86> ah.. forgot one thing, 1) i patched configure script myself 2) i did some modifications to result makefile :)
[16:25:43 CEST] <nonex86> ...two things to be correct, yeah :)
[16:25:49 CEST] <wildefyr> yeah that's probably what I am going to have to do myself..
[16:25:51 CEST] <wildefyr> what a pain
[16:28:43 CEST] <termos> Does anyone know why the sound is not playing on this stream? rtmp://cp353594.live.edgefcs.net/live/1003_1003_1364k@316197
[17:04:52 CEST] <Kadigan_KSB> http://s10.postimg.org/u6nkqoj61/Screen_Shot_2016_10_19_at_17_03_13.png this is the kind of difference I see between (left) HTML5 video and (right) local playback of the file after downloading it from the HTML5 video element.
[17:04:56 CEST] <wildefyr> is there really any benefit to using cbr over vbr?
[17:04:58 CEST] <Kadigan_KSB> That's just sad.
[17:05:13 CEST] <wildefyr> cvf*
[17:05:29 CEST] <Kadigan_KSB> cvf?
[17:05:38 CEST] <furq> cfr?
[17:05:41 CEST] <wildefyr> nah I did mean cbr
[17:05:50 CEST] <furq> not really
[17:06:11 CEST] <Kadigan_KSB> There is, if you're streaming or using a device that has fixed buffer requirements.
[17:06:13 CEST] <furq> some devices require cbr but those are few and far between
[17:06:24 CEST] <furq> it's pretty much worthless for streaming
[17:06:28 CEST] <furq> just use vbv for that
[17:06:46 CEST] <wildefyr> i thought as much
[17:06:50 CEST] <furq> assuming we're talking about x264 here
[17:06:57 CEST] <wildefyr> well x265
[17:07:20 CEST] <furq> that's more or less the same afaik
[17:07:39 CEST] <furq> x264 doesn't have a true cbr mode, the closest you can get is vbv and padding undersized packets
[17:07:56 CEST] <furq> which is required for bluray iirc
[17:08:05 CEST] <furq> but if you're not specifically targeting something along those lines, it's pointless
[17:10:19 CEST] <ritsuka> Kadigan_KSB: which player? probably one is doing color correction and the other YOLO
[17:16:27 CEST] <Kadigan_KSB> ritsuka: OS X preview app (should be using QT)
[17:16:50 CEST] <ritsuka> and the browser?
[17:19:48 CEST] <Parker__> Hey ffmpeg, I'm trying to convert a series of rendered .ppm frames into a lossless movie
[17:19:51 CEST] <Parker__> ffmpeg -i untitled.%05d.ppm -c:v libx264 -preset veryslow -qp 0 out.mkv
[17:20:03 CEST] <Parker__> seems to work, but the resulting movie is very blurry compared to the ppm files going in.
[17:20:40 CEST] <BtbN> make sure you use a lossless pixel format as well
[17:20:49 CEST] <DHE> -pix_fmt yuv444 maybe?
[17:21:01 CEST] <DHE> note that some players, especially hardware players, can't play these back
[17:21:43 CEST] <Parker__> Mmm
[17:22:14 CEST] <nonex86> btw, about qp=0, will libx264 convert it to qpmin? or 0 will be used?
[17:22:30 CEST] <kepstin> Parker__: is the input rgb images? if so, you probably want to use '-c:v libx264rgb' instead
[17:22:42 CEST] <kepstin> Parker__: of course, that'll have even less compatibility :)
[17:23:13 CEST] <kepstin> nonex86: qp=0 is a special value that switches the encoder to lossless mode.
[17:23:19 CEST] <Parker__> I just want to make clean videos of my molecular dynamics movies :(
[17:23:31 CEST] <Parker__> not sure if still RGB
[17:23:32 CEST] <nonex86> kepstin: i see, thanks
[17:24:22 CEST] <DHE> nonex86: qpmin and qpmax are for quality (ie: target bitrate) mode to put a cap on how high or low it will go
[17:25:12 CEST] <nonex86> DHE: roger, thanks :)
[17:25:25 CEST] <Parker__> Mmm, ffmpeg -r 25 -pix_fmt yuv420p -i untitled.%05d.ppm  -c:v libx264rgb -preset veryslow -qp 0 out.mkv
[17:25:28 CEST] <Parker__> and ffmpeg -r 25 -pix_fmt yuv420p -i untitled.%05d.ppm  -c:v libx264rgb -preset veryslow -qp 0 out.mkv
[17:25:31 CEST] <Parker__> and ffmpeg -r 25 -pix_fmt yuv420p -i untitled.%05d.ppm  -c:v libx264 -preset veryslow -qp 0 out.mkv
[17:25:36 CEST] <Parker__> still look very blurry
[17:26:22 CEST] <DHE> Parker__: try this:  ffmpeg -r 25 -i untitled.%05d.ppm -pix_fmt yuv444  -c:v libx264 -preset slow -qp 0 out.mkv
[17:26:48 CEST] <kepstin> the only way the libx264rgb one could look blurry is if your player is rendering them incorrectly, that will exactly preserve the pixels from your input as-is.
[17:26:58 CEST] <Parker__> I'm on linux using VLC
[17:27:17 CEST] <kepstin> DHE: I'm pretty sure most versions of ffmpeg will use yuv444 by default in this case? (and print out a warning about it)
[17:27:34 CEST] <kepstin> Parker__: it would be helpful if you pastebin the ffmpeg full output somewhere.
[17:27:53 CEST] <Parker__> Yes
[17:27:58 CEST] <Parker__> okay also this is really weird
[17:28:03 CEST] <DHE> kepstin: i'm not 100% sure honestly. yuv420p (unless overridden) sure sounds like a sane default for x264
[17:28:09 CEST] <Parker__> watching the video for the first time on VLC, it is blury
[17:28:11 CEST] <Parker__> letting it loop
[17:28:14 CEST] <Parker__> it becomes clear...
[17:28:22 CEST] <kepstin> Parker__: sounds like a vlc bug then :/
[17:28:28 CEST] <furq> Parker__: try with mpv
[17:29:00 CEST] <DHE> .. what if you play the .ppm files directly with ffplay?
[17:29:20 CEST] <furq> and yeah x264 defaults to yuv444p with an rgb source
[17:30:16 CEST] <Parker__> Installing MPV now
[17:30:20 CEST] <Parker__> how do you play with ffplay DHE?
[17:30:45 CEST] <furq> i expect `ffplay img%05d.ppm` works
[17:31:03 CEST] <Parker__> ffply looks great
[17:31:49 CEST] <Parker__> kepstin: furq it is a VLC bug
[17:31:52 CEST] <Parker__> MPV looks great
[17:31:55 CEST] <Parker__> so does ffplay
[17:32:00 CEST] <Parker__> thanks for the help everyone!
[17:35:05 CEST] <wildefyr> morale of the lesson: mpv is god
[17:50:03 CEST] <bryan_> hello everybody
[17:53:25 CEST] <bryan_> i am trying to add dri2 api calls in ffmpeg gstreamer plugin...it is getting compiled but at runtime it shows undefined reference to dri2 library...how can i link dri2 lib inside ffmpeg plugin?
[17:54:53 CEST] <bryan_> i want to resolve dri2 symbols at compile time itself
[18:00:09 CEST] <jkqxz> bryan_:  You'd need to add libxcb-dri2 (presumably this is using XCB?) to the ffmpeg configure script.  See the other X extensions which are already there (libxcb-shm, say).
[18:00:40 CEST] <jkqxz> Also I'm rather curious what you're going to do with it...
[18:02:09 CEST] <bryan_> jkqxz: thank you...will try that..
[18:03:41 CEST] <bryan_> i am using libdri2.so library..
[18:10:39 CEST] <jkqxz> Huh, legacy libX11.  Can I suggest using xcb instead?
[18:13:13 CEST] <jkqxz> If you really want to use it libX11-style, you need to add a line like the one at configure:5978 for shm.  It can probably just go at the top level.
[18:20:29 CEST] <jacereda> hi
[19:36:54 CEST] <Kentoo> Hi, I am using libav, is it possible to open an output file without truncating it? I mean I want to edit it, for example adding a subtitle stream
[19:37:36 CEST] <kepstin> Kentoo: no, you'll generally have to read the file as input, and remux to a new file (which can be renamed back)
[19:38:14 CEST] <Kentoo> kepstin: alright, thank u
[19:38:15 CEST] <kepstin> none of the video container formats are designed for in-place editing, it would be really complicated and require moving a lot of data around, just writing to a new file is easier (and probably faster too)
[19:38:30 CEST] <Kentoo> kepstin: so all video editing software use the method u said?
[19:39:00 CEST] <kepstin> pretty much yeah. There's a few specialized tools for specific formats that allow limited in-place changes, but not anything like adding a new stream.
[20:03:30 CEST] <ac_slater> hey guys. Does anyone have a diagram for 10bit YUV422?
[22:18:36 CEST] <kuroro_> hello. im thinking about using static build of ffmpeg for android via https://johnvansickle.com/ffmpeg/
[22:18:52 CEST] <kuroro_> but im not sure which one to choose (armhf or armel) version
[22:20:43 CEST] <furq> you probably want armhf
[22:21:17 CEST] <kuroro> is it for more device compatibility? (more devices use armhf?)
[22:21:58 CEST] <furq> armhf normally refers to armv7
[22:22:11 CEST] <furq> some older phones will need armel
[22:22:23 CEST] <furq> and some very new phones will use aarch64, which i guess you'll need to build yourself
[22:23:27 CEST] <furq> i'm not sure if those builds will work on android though
[22:24:18 CEST] <kuroro> "i'm not sure if those builds will work on android though" - ah, so there might something different in android that might make them not work then..
[22:24:26 CEST] <furq> different libc
[22:24:50 CEST] <furq> i don't know whether that'll actually break anything though
[22:25:27 CEST] <kuroro> i see
[00:00:00 CEST] --- Thu Oct 20 2016