[Ffmpeg-devel-irc] ffmpeg.log.20180830
burek
burek021 at gmail.com
Fri Aug 31 03:05:01 EEST 2018
[01:50:30 CEST] <fling> Ke: does it work?
[01:50:49 CEST] <fling> Ke: you should not worry about mem2mem as long as it is v4l device
[01:51:33 CEST] <fling> Ke: because v4l devices use inputs/outputs and controls available via v4l
[01:52:03 CEST] <fling> Ke: you use input and output with ffmpeg and switch controls with v4l2-ctl
[01:52:28 CEST] <fling> Or is there any trickery involved? Tell me more about what you have there.
[04:28:28 CEST] <breakslowbot> Hello
[04:30:52 CEST] <breakslowbot> ffmpeg.nightly don't have support for .NETframework v4.5.2 wich one I should use?
[04:31:35 CEST] <yagiza> Hello!
[04:31:47 CEST] <pi--> So, I have a repeatable test illustrating strange behaviour. A video formed by concatenating two other videos glitches in VLC.
[04:32:04 CEST] <breakslowbot> hello yagiza
[04:32:23 CEST] <breakslowbot> I am new here
[04:32:40 CEST] <pi--> https://paste.pound-python.org/show/9g22Vq4VVWYM77Yfh5AH/
[04:32:57 CEST] <pi--> Might this be of any interest as a bug?
[04:32:58 CEST] <yagiza> breakslowbot
[04:34:26 CEST] <yagiza> When I switched to custom I/O for RTP encoding, I have an error -5 (I/O error) on avformat_write_header().
[04:34:43 CEST] <breakslowbot> can someone help me setting up ffmpeg on C#?
[04:34:47 CEST] <yagiza> My costom I/O procedures never invoked.
[04:35:32 CEST] <yagiza> Is it possible to use RTP encoding with custom I/O procedures?
[04:46:40 CEST] <poutine> pi--, I don't think you're encoding using the same parameters for the 2nd video as the 1st one had
[04:46:50 CEST] <poutine> you'll likely need to use the concat filter and transcoding rather than transmuxing
[08:07:03 CEST] <Ke> fling: sorry did not try yet
[12:03:17 CEST] <AnrDaemon> Can somebody please tell me, what's wrong with this filter? https://pastebin.com/YF6KGtkP
[12:10:16 CEST] <BtbN> Error when evaluating the expression '(540-h*min(720/w,540/h))/2'
[12:22:29 CEST] <AnrDaemon> WHICH error?
[12:22:46 CEST] <AnrDaemon> I don't see anything particularly wrong with it.
[12:24:43 CEST] <durandal_1707> AnrDaemon: have you copy pasted that command from somewhere?
[12:24:52 CEST] <AnrDaemon> Nop.
[12:25:45 CEST] <AnrDaemon> I'm puzzled by the fact it complains about the last block only.
[12:26:48 CEST] <AnrDaemon> Ok, documentation says it only supports iw/ih. Let me try.
[12:29:36 CEST] <AnrDaemon> https://pastebin.com/YF6KGtkP
[12:29:51 CEST] <AnrDaemon> IDK what's going on. Honestly. :(
[12:36:08 CEST] <durandal_1707> AnrDaemon: you get negative width for pad argument
[12:36:38 CEST] <AnrDaemon> Why?
[12:38:03 CEST] <AnrDaemon> According to https://ffmpeg.org/ffmpeg-filters.html#toc-Options-1, if one of the w:h is negative, it claculates it based on the other component, preserving image scale rouded to the abs(negative)
[12:38:53 CEST] <AnrDaemon> https://ffmpeg.org/ffmpeg-filters.html#Options-1
[12:41:33 CEST] <durandal_1707> AnrDaemon: then x/y are too big
[12:42:13 CEST] <AnrDaemon> O.o
[12:42:30 CEST] <AnrDaemon> The streams layout is attached. I don't see anything particularly wrong with it.
[12:46:30 CEST] <durandal_1707> [Parsed_pad_2 @ 0665fac0] Input area -120:0:840:540 not within the padded area 0:0:720:540 or zero-sized
[12:46:48 CEST] <AnrDaemon> I see it, but don't understand& or may be I do.
[12:46:58 CEST] <AnrDaemon> Lemme try one thing.
[12:51:17 CEST] <AnrDaemon> https://pastebin.com/YF6KGtkP :WALL:
[12:51:29 CEST] <AnrDaemon> Forcing SAR/DAR makes no diff.
[13:09:48 CEST] <AnrDaemon> I'm about to give up and calculate everything my hands. :(
[13:15:58 CEST] <AnrDaemon> scale=w=720:h=540:force_original_aspect_ratio=decrease
[13:31:31 CEST] <ariyasu> -profile:v high422 -pix_fmt yuv420p
[13:31:35 CEST] <ariyasu> this is wrong for a start
[13:32:03 CEST] <ariyasu> you cant use both 4:2:2 and 4:2:0
[13:32:10 CEST] <AnrDaemon> ariyasu: I'm open for suggestions.
[13:32:48 CEST] <AnrDaemon> I admit, parts of it is copied from various "make html5 ready video" tutorials.
[13:35:52 CEST] <ariyasu> forgetting your command for a min
[13:35:58 CEST] <ariyasu> what are you actually trying to do
[13:38:17 CEST] <AnrDaemon> I'm trying to automate video processing before uploading to the website.
[13:39:30 CEST] <AnrDaemon> The content is educational, so SUPER HIGHT QUALITY 1080p is rather useless.
[13:40:28 CEST] <AnrDaemon> And in process, I'm testing it on my <khm> collection.
[13:40:35 CEST] <Nacht> Why the 4:3 output ?
[13:40:44 CEST] <AnrDaemon> Just for test.
[13:40:52 CEST] <AnrDaemon> It could be anything, really.
[13:40:58 CEST] <Nacht> What exactly do you hope the pad to do ?
[13:41:23 CEST] <AnrDaemon> Solved it already, kind of. Will have to check on non-sar=1 video first though.
[13:41:41 CEST] <Nacht> Cause, judging from the string. If you input an 1920x1080, it will get scaled to 960x540 and it will exceed the size of the pad
[13:42:20 CEST] <AnrDaemon> Not with scale=w=720:h=540:force_original_aspect_ratio=decrease
[13:46:47 CEST] Action: AnrDaemon finally found the right documentation parts. *blush*
[15:12:45 CEST] <AnrDaemon> Thanks everybody for being my rubber ducky for today.
[15:27:24 CEST] <AnrDaemon> Hm, may be a stupid question, but& can I save two video streams in one file? I.e. both M4V and VPX ?
[15:35:01 CEST] <Ke> AnrDaemon: you mean concatenated or parallel?
[15:35:08 CEST] <AnrDaemon> Parallel.
[15:35:22 CEST] <Ke> I would assume mkv can do this
[15:35:37 CEST] <Ke> I would recommend looking at mkvmerge tool
[15:35:41 CEST] <Ke> in mkvtoolnix
[15:45:04 CEST] <AnrDaemon> Thanks.
[15:52:58 CEST] <DHE> AnrDaemon: there's also a "tee" output muxer to save simultaneously. useful for both streaming and saving to disk.
[15:53:06 CEST] <AnrDaemon> Is it safe to exclude video strem from first pass encoding?
[15:53:15 CEST] <DHE> ..?
[15:53:24 CEST] <AnrDaemon> Err, audio stream :D
[15:53:32 CEST] <AnrDaemon> Sorry, thinking too many things at once.
[15:54:14 CEST] <Ke> hmm do you actually mean streaming, mkvmerge might not do that
[15:54:25 CEST] <AnrDaemon> Nop.
[15:54:52 CEST] <DHE> sure, though usually the savings isn't very much. slowest codec I've used recently still encodes at 20x realtime. so that saves 3 CPU minutes for an hourlong video
[15:55:18 CEST] <AnrDaemon> I can imagine that. Was just wondering :)
[15:55:50 CEST] <AnrDaemon> M4V firstpass was noticable faster than VPX one, and I've seen it only encoding video stream.
[16:20:25 CEST] <AnrDaemon> Any way to specify some global defaults? I'm tired of adding -hide_banner -nostdin -nostats to every command.
[16:28:45 CEST] <AnrDaemon> -map 0:v -map -0:a?"
[16:28:50 CEST] <AnrDaemon> Works. :)
[16:44:55 CEST] <colegatron> Hi all. I have found ffmpeg and I am wondering if it is possible to capture audio/video (two different browser tabs, but can also be two different browsers, ff and chrome, if it helps), without mixing audios.
[16:44:58 CEST] <colegatron> is that possible?
[16:45:29 CEST] <colegatron> I am using ubuntu, so pulseaudio server
[16:48:51 CEST] <colegatron> just to clarify; the requirement is capture each browser tab in a different mpeg/flv/whatever
[16:53:19 CEST] <Lokie> hello, I am trying to join pictures into a video and I want to specify the framerate
[16:53:45 CEST] <Lokie> I am using "ffmpeg -y -pattern_type glob -i '*.JPG' -c:v copy -r 15 output.mp4" but it seems ignored
[16:53:45 CEST] <kepstin> Lokie: use the `-framerate X` input option (goes before the -i)
[16:54:37 CEST] <Lokie> it's ignored
[16:54:51 CEST] <Lokie> ffprobe shows fps 25
[16:54:59 CEST] <DHE> ffmpeg -y -framerate 30 -pattern_type glob -i '*.JPG' ...
[16:55:04 CEST] <DHE> order matters in ffmpeg. a lot
[16:55:42 CEST] <Lokie> there we go, thank you!
[16:55:57 CEST] <DHE> note that's what kepstin said as well
[16:56:01 CEST] <Lokie> is -framerate different to -r cause I did try -r before -pattern and it didn't work
[16:56:28 CEST] <c_14> yes
[16:56:29 CEST] <DHE> -framerate is an option to the image demuxer since it fakes a movie from still images. -r is an ffmpeg option for rate conversion
[16:56:46 CEST] <Lokie> aha so that was the problem
[16:56:49 CEST] <Lokie> thank you all
[17:09:55 CEST] <AnrDaemon> Lokie: Before -i
[17:22:52 CEST] <fpiraneo> Hi all. Ive a question about encoding a video with ffmpeg 4.0.2; Ive two different builds of ffmpeg: The first under the latest freebsd and the second under osx; in both cases I use the x265 codec; in the freebsd version all video are encoded with pixel format yuv420p12le; in the osx version all video are encoded with pixel format yuv420p; same pixel format are video encoded with ubuntu 18.04 build.
[17:23:22 CEST] <fpiraneo> Now: the -pix_fmt parameter seems to doesnt have effect.
[17:23:46 CEST] <fpiraneo> Any idea about is welcome; follows the command I use for encoding:
[17:24:16 CEST] <fpiraneo> ffmpeg -y -i INPUT -t 00:00:05 -c:v libx265 -pix_fmt:v yuv420p -preset medium -s hd720 -crf 23 -c:a copy -strict -2 -f matroska OUTPUT
[17:25:12 CEST] <BtbN> why -strict -2?
[17:25:33 CEST] <fpiraneo> Let me check some notes...
[17:25:49 CEST] <BtbN> it should be doing nothing
[17:26:18 CEST] <BtbN> but the command seems ok otherwise, so that freebsd build must be messed up
[17:26:48 CEST] <fpiraneo> Well& I cannot find any note about but I remember that without the -strict -2 ffmpeg gave me some error while rescaling.
[17:27:23 CEST] <fpiraneo> Consider that on freebsd I use the official ports. Nothing more, nothing less...
[17:27:58 CEST] <fpiraneo> But, when I try to change the pixformat on osx, ffmpeg always encode with yuv420p.
[17:29:04 CEST] <fpiraneo> Some other notes: On VLC both pixformat plays fine! Ive issues when playing on my OSMC media player, based on raspberrypi 3
[17:29:19 CEST] <fpiraneo> So I began to dig to see whats happening.
[17:30:52 CEST] <kepstin> fpiraneo: x265 can be built in various different ways, you can either get a single bit depth build or multi bit depth
[17:31:03 CEST] <kepstin> it might be that on one of your systems you have an 8-bit-only x265 build
[17:32:04 CEST] <fpiraneo> kepstin: How can I check how x265 is built? Using ffmpeg commands I mean...
[17:32:28 CEST] <kepstin> "ffmpeg -h encoder=libx265" will print out the supported pixel formats
[17:32:54 CEST] <fpiraneo> Ok Ill do it now& and Ill post the result& just a sec.
[17:33:51 CEST] <fpiraneo> on osx: Supported pixel formats: yuv420p yuv422p yuv444p gbrp gray
[17:34:30 CEST] <kepstin> ok, so on osx you have an 8-bit only x265 build (there's no 10le or 12le formats)
[17:34:38 CEST] <fpiraneo> Supported pixel formats: yuv420p yuv422p yuv444p gbrp yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le
[17:34:45 CEST] <fpiraneo> The latter on freebsd.
[17:34:59 CEST] <kepstin> and on freebsd you have a multi-bit-depth x265, supports 8, 10, and 12bit video
[17:35:15 CEST] <fpiraneo> It should be ok to encode in yuv420p BUT it seems that the -pix_fmt is not taken into account&
[17:35:33 CEST] <fpiraneo> With ffprobe I still get a yuv420p12le
[17:35:41 CEST] <kepstin> using -pix_fmt yuv420p (in the correct location in the command line) should cause the freebsd system to encode with yuv420p
[17:35:58 CEST] <kepstin> note the *in the correct location in the command line*, that's important ;)
[17:36:01 CEST] <fpiraneo> Good point!! The right position.
[17:36:15 CEST] <fpiraneo> I post again the command I use:
[17:36:30 CEST] <fpiraneo> ffmpeg -y -i INPUT -t 00:00:05 -c:v libx265 -pix_fmt:v yuv420p -preset medium -s hd720 -crf 23 -c:a copy -strict -2 -f matroska OUTPUT
[17:36:38 CEST] <fpiraneo> This make sense for you?
[17:37:01 CEST] <kepstin> hmm, that should be correct. Note that the :v on pix_fmt is redundant, it only applies to video anyways.
[17:37:17 CEST] <kepstin> please pastebin the complete output of ffmpeg on freebsd
[17:37:29 CEST] <fpiraneo> Ok give me a sec!
[17:39:21 CEST] <fpiraneo> Lot of printout is coming& sorry for that.
[17:39:28 CEST] <fpiraneo> ffmpeg version 4.0.2 Copyright (c) 2000-2018 the FFmpeg developers
[17:39:32 CEST] <fpiraneo> built with FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
[17:39:33 CEST] <fpiraneo> configuration: --prefix=/usr/local --mandir=/usr/local/man --datadir=/usr/local/share/ffmpeg --pkgconfigdir=/usr/local/libdata/pkgconfig --enable-shared --enable-pic --enable-gpl --enable-postproc --enable-avfilter --enable-avresample --enable-pthreads --cc=cc --disable-alsa --disable-libopencore-amrnb --disable-libopencore-amrwb --disable-libass --enable-libbs2b --disable-libcaca --disable-libcdio --disable-libcelt --disable-chromaprint --enable-libco
[17:39:35 CEST] <fpiraneo> --disable-libdc1394 --disable-debug --enable-htmlpages --enable-libdrm --enable-libfdk-aac --disable-libflite --enable-fontconfig --enable-libfreetype --enable-frei0r --disable-libfribidi --disable-libgme --disable-libgsm --enable-iconv --disable-libilbc --disable-libjack --enable-libkvazaar --disable-ladspa --enable-libmp3lame --enable-libbluray --disable-librsvg --disable-libxml2 --disable-lv2 --enable-mmx --disable-libmodplug --disable-libmysofa
[17:39:35 CEST] <DHE> do NOT do that
[17:39:36 CEST] <fpiraneo> --disable-openal --disable-opencl --enable-libopencv --disable-opengl --enable-libopenh264 --disable-libopenjpeg --enable-optimizations --enable-libopus --enable-libpulse --enable-runtime-cpudetect --disable-librubberband --disable-sdl2 --disable-libsmbclient --disable-libsnappy --disable-sndio --disable-libsoxr --disable-libspeex --enable-sse --disable-libssh --disable-libtesseract --enable-libtheora --disable-libtwolame --enable-libv4l2 --enable-vaapi
[17:39:36 CEST] <DHE> oh shit...
[17:39:38 CEST] <fpiraneo> --enable-vdpau --disable-libvidstab --enable-libvorbis --disable-libvo-amrwbenc --enable-libvpx --disable-libwavpack --disable-libwebp --enable-libx264 --enable-libx265 --disable-libxcb --enable-libxvid --disable-outdev=xv --disable-libzimg --disable-libzmq --disable-libzvbi --disable-gcrypt --enable-gmp --disable-librtmp --enable-gnutls --disable-openssl --enable-version3 --enable-nonfree --disable-libaom --disable-libsrt
[17:39:39 CEST] <fpiraneo> libavutil 56. 14.100 / 56. 14.100
[17:39:41 CEST] <fpiraneo> libavcodec 58. 18.100 / 58. 18.100
[17:39:42 CEST] <fpiraneo> libavformat 58. 12.100 / 58. 12.100
[17:39:44 CEST] <fpiraneo> libavdevice 58. 3.100 / 58. 3.100
[17:39:45 CEST] <fpiraneo> libavfilter 7. 16.100 / 7. 16.100
[17:39:47 CEST] <fpiraneo> libavresample 4. 0. 0 / 4. 0. 0
[17:39:48 CEST] <fpiraneo> libswscale 5. 1.100 / 5. 1.100
[17:39:50 CEST] <fpiraneo> libswresample 3. 1.100 / 3. 1.100
[17:39:51 CEST] <fpiraneo> libpostproc 55. 1.100 / 55. 1.100
[17:39:53 CEST] <fpiraneo> Input #0, matroska,webm, from '1_org/13x01 - Decolliamo.mkv':
[17:39:54 CEST] <fpiraneo> Metadata:
[17:39:56 CEST] <fpiraneo> encoder : libebml v1.3.3 + libmatroska v1.4.4
[17:39:57 CEST] <fpiraneo> creation_time : 2017-10-15T05:06:38.000000Z
[17:39:59 CEST] <fpiraneo> Duration: 00:41:32.84, start: 0.000000, bitrate: 6102 kb/s
[17:40:00 CEST] <fpiraneo> Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn, 47.95 tbc (default) (forced)
[17:40:02 CEST] <fpiraneo> Metadata:
[17:40:03 CEST] <fpiraneo> BPS : 5332031
[17:40:05 CEST] <fpiraneo> BPS-eng : 5332031
[17:40:06 CEST] <fpiraneo> DURATION : 00:41:32.840000000
[17:40:08 CEST] <fpiraneo> DURATION-eng : 00:41:32.840000000
[17:40:09 CEST] <fpiraneo> NUMBER_OF_FRAMES: 62321
[17:40:11 CEST] <fpiraneo> NUMBER_OF_FRAMES-eng: 62321
[17:40:12 CEST] <fpiraneo> NUMBER_OF_BYTES : 1661487790
[17:40:14 CEST] <fpiraneo> NUMBER_OF_BYTES-eng: 1661487790
[17:40:15 CEST] <fpiraneo> _STATISTICS_WRITING_APP: mkvmerge v8.5.2 ('Crosses') 64bit
[17:40:17 CEST] <fpiraneo> _STATISTICS_WRITING_APP-eng: mkvmerge v8.5.2 ('Crosses') 64bit
[17:40:18 CEST] <fpiraneo> _STATISTICS_WRITING_DATE_UTC: 2017-10-15 05:06:38
[17:40:20 CEST] <fpiraneo> _STATISTICS_WRITING_DATE_UTC-eng: 2017-10-15 05:06:38
[17:40:28 CEST] <durandal_1707> lol
[17:40:34 CEST] <DHE> hahaha
[17:40:39 CEST] <DHE> Sigyn: thx
[17:47:41 CEST] <AnrDaemon> What can I do about [vc1 @ 05acef80] Error in WVC1 interlaced frame
[17:47:41 CEST] <AnrDaemon> Error while decoding stream #0:1: Invalid data found when processing input
[17:49:06 CEST] <AnrDaemon> I highly doubt it is actually interlaced.
[17:49:16 CEST] <kepstin> I did say "pastebin" :/
[17:49:34 CEST] <kepstin> should have use the !pb macro i guess.
[17:49:58 CEST] <DHE> yes you did
[17:50:06 CEST] <AnrDaemon> Oh. "Scantype: mixed"
[17:50:06 CEST] <DHE> seems like nobody listens
[17:50:50 CEST] <AnrDaemon> Lies. I did.
[18:04:32 CEST] <fpiraneo> Hi all, Im sorry but I did a big mistake publishing all the output line from my console.
[18:04:38 CEST] <fpiraneo> Now, Im back.
[18:05:08 CEST] <AnrDaemon> fpiraneo: Was it so friggin hard to read the channel join notice before posting?
[18:05:48 CEST] <fpiraneo> I was discussing about a freebsd build of ffmpeg that seems not to take account of -pix_fmt parameter.
[18:06:24 CEST] <fpiraneo> AnrDaemon: Sorry for that but it seems the only way to provide a full and complete answer to a question&
[18:06:58 CEST] <AnrDaemon> Somebody kick him again to refresh the join message& please.
[18:07:15 CEST] <fpiraneo> So& rolling back: I use this command under freebsd:
[18:07:32 CEST] <fpiraneo> ffmpeg -y -i INPUT -t 00:00:05 -c:v libx265 -pix_fmt:v yuv420p -preset medium -s hd720 -crf 23 -c:a copy -strict -2 -f matroska OUTPUT
[18:08:08 CEST] <fpiraneo> And the video is still encoded with yuv420p12le pixel format&
[18:10:19 CEST] <BtbN> From how I understand libx265, the lib can only do either 8, 10 or 12 bit encoding, depending on how it was compiled.
[18:10:30 CEST] <BtbN> So if freebsd decided to build a 12 bit one...
[18:10:58 CEST] <fpiraneo> And I got this: https://pastebin.com/QuD1Rqa5
[18:11:19 CEST] <fpiraneo> (Sorry again but I didnt knew pastebin&)
[18:11:42 CEST] <furq> build x265 from ports
[18:11:48 CEST] <furq> there's a make config option to enable 10 and 12-bit
[18:12:00 CEST] <fpiraneo> No& this is the interesting point:
[18:12:01 CEST] <fpiraneo> Supported pixel formats: yuv420p yuv422p yuv444p gbrp yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le
[18:12:14 CEST] <BtbN> Yes, it supports taking them
[18:12:17 CEST] <BtbN> but will output 12 bit
[18:12:23 CEST] <fpiraneo> How freebsd reports to me with ffmpeg -h encoder=libx265
[18:12:31 CEST] <fpiraneo> And I used the port version of x265
[18:12:42 CEST] <BtbN> They built a 12 bit only version then
[18:13:50 CEST] <fpiraneo> BtbN: Are you sure? Its seems that the build support also the 8 bit! (look ad yuv420p as first one)
[18:14:16 CEST] <BtbN> Well, then there clearly is no problem.
[18:14:25 CEST] <AnrDaemon> fpiraneo: Not all pixel formats supported by all codecs.
[18:14:48 CEST] <furq> that list is from the help for x265
[18:14:50 CEST] <AnrDaemon> fpiraneo: And unfortunately, there's no way to get this information directly from ffmpeg :/
[18:14:56 CEST] <furq> ...yes there is
[18:15:00 CEST] <furq> you run the command he said
[18:15:01 CEST] <AnrDaemon> Share please.
[18:15:03 CEST] <fpiraneo> AnrDaemon: This is the output of the command asking the pixel format support for the codec!
[18:15:10 CEST] <AnrDaemon> I've been hit by the same issue.
[18:15:12 CEST] <furq> 17:12:23 ( fpiraneo) How freebsd reports to me with ffmpeg -h encoder=libx265
[18:15:15 CEST] <fpiraneo> I make another pastebin: jiust a sec
[18:15:22 CEST] <BtbN> it lists the supported input formats. What the codec then does with it is up to its internals.
[18:15:28 CEST] <BtbN> If that involved converting to 12 bit, so it will do.
[18:15:53 CEST] <fpiraneo> https://pastebin.com/Hdzhty6H
[18:16:46 CEST] <fpiraneo> BtbN: So the listed format are valid *INPUT* formats, not outputs?
[18:16:55 CEST] <AnrDaemon> furq: Exactly. It happily chws the input, but complaints when you try to set output.
[18:16:58 CEST] <BtbN> Video Encoders do not have output pixel formats.
[18:17:02 CEST] <BtbN> They output packets
[18:17:43 CEST] <fpiraneo> Ok. So can you please suggest me how to deal with this issue?
[18:18:05 CEST] <BtbN> Get a libx265.so that supports what you want.
[18:18:08 CEST] <fpiraneo> I need to recompile or modify the port of the codec?
[18:19:15 CEST] <fpiraneo> I suppose I have to ask to x265 room to get more infos& ;-)
[18:21:19 CEST] <fpiraneo> Ok gentleman, thank you for your help!
[18:21:28 CEST] <fpiraneo> And sorry again for the huge past& ;-)
[18:21:39 CEST] <fpiraneo> *paste
[18:41:46 CEST] <Zgrokl> hey is there a way to limit ffmpeg to core 1 and 2 and ffmpeg process 2 to core 3 and 4
[18:42:07 CEST] <Zgrokl> i try with taskset -c 0,1 ffmpeg, seem to work but not really good
[18:43:11 CEST] <BtbN> taskset is how you do it on Linux.
[18:57:12 CEST] <DHE> taskset is the standard tool, yes. it may not cover 100% of CPU usage as other related kernel activities like interrupts and drivers may use other CPUs
[19:17:49 CEST] <Zgrokl> DHE is there a way to get 100% ? like set a nice ?
[19:19:08 CEST] <Zgrokl> and you think it's better to make taskset -c 0,1 ffmpeg -threads 0 (or threads 2 ?)
[19:19:33 CEST] <BtbN> The thread count auto-detecting will not take notice of the taskset I think
[19:19:40 CEST] <BtbN> so you'll need to set it to something sensible manually
[19:50:20 CEST] <ChocolateArmpits> When generating sub-second segments in HLS, ffmpeg seems to always make EXT-X-TARGETDURATION equal 0 which fails with most javascript players. Is this a bug or is it supposed to be rounded that way ?
[19:52:44 CEST] <JEEB> ChocolateArmpits: not sure about zero specifically but IIRC it is indeed rounded towards smaller int
[19:52:54 CEST] <JEEB> let me try and get you the reference from when I tried to post a patch for it
[19:53:20 CEST] <JEEB> https://patchwork.ffmpeg.org/patch/8130/
[19:55:46 CEST] <JEEB> of course if the duration is closer to 1 than 0 then technically it should be 1 and not 0
[19:56:05 CEST] <ChocolateArmpits> in relation to the midpoint that is ?
[19:56:43 CEST] <JEEB> well, in float seconds that is
[19:58:01 CEST] <DHE> The target duration must be an integer, and each segment must be <= its duration. So rounding up is okay and a minimum of 1 would also be fine.
[19:58:13 CEST] <ChocolateArmpits> well now it's 0
[19:58:28 CEST] <JEEB> DHE: https://tools.ietf.org/html/rfc8216#page-22
[19:58:40 CEST] <ChocolateArmpits> yeah I'm looking at it
[19:58:41 CEST] <DHE> I'm looking at it right now
[19:59:45 CEST] <JEEB> but yea, I tried to add ceil to that and got herped a derp back with a bug + the spec
[20:00:19 CEST] <ChocolateArmpits> ceiling would make justifiable sense when segment length is less than 1, no?
[20:00:26 CEST] <DHE> I have a TV box vendor who mishandled the field and used it for seekbar timing information. due to the rounding sometimes "now" was past the duration of the video.
[20:10:17 CEST] <_Mike_C_> Hello again, I asked a question yesterday about the nvenc encoder not returning pkt's. I've made debug versions of the dll's and gone as deep as I can into the ffmpeg code (it skips a lot of functions). It appears like my problem involves the NvencContext in the output_ready() function inside of nvenc.c
[20:11:47 CEST] <_Mike_C_> the flush parameter is false, and it gets down to the bottom of the function before returning false
[20:12:02 CEST] <_Mike_C_> nb_ready appears to be 16, nb_pending appears to be 0
[20:12:51 CEST] <_Mike_C_> which can only mean that the ctx->async_depth is really high for some reason? I was not able to create my own NvencContext or see what is going on inside it.
[20:15:35 CEST] <_Mike_C_> Could someone offer some advice on where to go from here/how to further diagnose/ fix the problem?
[20:29:35 CEST] <_Mike_C_> Or maybe someone could explain to me what NvencContext->async_depth is?
[20:31:07 CEST] <BtbN> It's where the async_depth avoption gets written to.
[21:14:37 CEST] <_Mike_C_> Sorry I got DCed after I asked a question. If anyone answered me, could you please copy the text again.
[21:26:03 CEST] <Fenrirthviti> _Mike_C_: [13:31:08] <BtbN> It's where the async_depth avoption gets written to.
[21:28:36 CEST] <_Mike_C_> BtbN, is that something I have to write? Or something internal. I don't see it as an option when I look at the h264_nvenc option list
[21:28:44 CEST] <_Mike_C_> Fenrirthviti, thank you
[21:28:50 CEST] <BtbN> If you are unhappy with the default
[21:28:58 CEST] <BtbN> but it's generally fine and you don't need to care about it.
[21:29:48 CEST] <_Mike_C_> Can you think of why my output_ready function is returning false then? From the best I can tell, nb_ready is 16, nb_pending is 0 and the second check in line 1941 is returning false
[21:30:11 CEST] <_Mike_C_> aka nb_ready + nb_pending >= ctx->async_depth seems to be returning false
[21:31:23 CEST] <BtbN> It just means you haven't fed enough input yet
[21:31:43 CEST] <_Mike_C_> Unfortunately it never returns true
[21:32:00 CEST] <_Mike_C_> despite me continually feeding the encoding context frames
[21:32:59 CEST] <BtbN> You are doing something wrong then.
[21:33:38 CEST] <_Mike_C_> Could you direct me in a better way to troubleshoot this?
[21:33:53 CEST] <_Mike_C_> Everything works just fine with software encoders
[21:36:33 CEST] <_Mike_C_> prior to this returning false and no pkt being returned from the avcodec_recieve_packet, I recieve a 0 return value from avcodec_send_frame
[21:37:12 CEST] <_Mike_C_> which, I have assumed, means it successfully completed sending a frame to the encoder
[21:39:12 CEST] <BtbN> That's what it means, yes.
[21:39:47 CEST] <BtbN> There are multiple ways to go at this
[21:40:06 CEST] <BtbN> feed frame, loop over receive packet until EAGAIN, feed frame, and so on
[21:40:20 CEST] <BtbN> Or feed frames until EAGAIN, then drain the packages, and start over
[21:40:21 CEST] <BtbN> both works
[21:40:28 CEST] <_Mike_C_> I am using the first method
[21:41:11 CEST] <_Mike_C_> I'm sorry to keep bugging you, its just frustrating because I don't have the ability/documentation to troubleshoot this myself.
[21:41:40 CEST] <_Mike_C_> I've followed the examples and everything works perfectly as it should, but there must be something extra that I haven't done thats needed with the H264_nvenc encoder
[21:42:05 CEST] <BtbN> There really isn't. ffmpeg.c accesses all of them in the same generic way, and it just works there.
[21:42:23 CEST] <_Mike_C_> Is there something platform specific that could be breaking it because I am on windows?
[21:42:31 CEST] <BtbN> no
[21:42:38 CEST] <BtbN> if there was, it would error on init
[21:45:17 CEST] <_Mike_C_> How else can I troubleshoot the fact that no matter how long I run it for, the output_ready function returns false?
[21:46:10 CEST] <_Mike_C_> The avcodec_send_frame function is even returning EAGAIN, signifying the input buffer is full
[21:46:11 CEST] <BtbN> No idea, but I'd assume you do not properly send frames, cause if you send frames constantly without reading anything, you would eventually get an EAGAIN on send
[21:46:19 CEST] <_Mike_C_> I do
[21:47:00 CEST] <_Mike_C_> I let it run for a bit and it starts returning EAGAIN, but the out_ready is still returning EAGAIN as well
[21:47:15 CEST] <BtbN> On what path?
[21:47:19 CEST] <_Mike_C_> er it returns false, which in turn returns EAGAIN
[21:47:50 CEST] <_Mike_C_> What do you mean "path"?
[21:48:26 CEST] <BtbN> From what path in that function does it return 0
[21:49:19 CEST] <BtbN> Where do your frames come from? Do they have proper, non AV_NOPTS_VALUE, pts set on them?
[21:50:10 CEST] <_Mike_C_> I cannot dive into that code (the debugger skips past a lot of stuff) but I see both av_fifo_size functions execute and I know that the parameter flush is false, so I am assuming its the final reutrn statement that returns 0, aka line 1941
[21:50:46 CEST] <BtbN> The only idea I'd have is that you never set a proper pts on your input frames, so the re-ordering logic is waiting on something to work with
[21:50:47 CEST] <_Mike_C_> Yes the frames have proper pts values
[21:51:01 CEST] <BtbN> If all else fails, put debug-prints in there
[21:51:03 CEST] <_Mike_C_> Do they have to have numbers starting from 0 before fed to the encoder?
[21:51:25 CEST] <_Mike_C_> I'm currently using pts values returned from the decoder
[21:51:30 CEST] <BtbN> As long as they aren't NOPTS_VALUE you're good.
[21:51:47 CEST] <BtbN> You can also temporarily set avctx->max_b_frames = 0 to rule out that branch.
[21:52:15 CEST] <_Mike_C_> I have done that, its set to 0
[21:53:53 CEST] <BtbN> And you say nb_ready is 16, and pending 0?
[21:54:42 CEST] <_Mike_C_> yes
[21:54:52 CEST] <BtbN> How can you even see that if you can't step into the function?
[21:55:41 CEST] <_Mike_C_> actually, maybe its not. It takes me inside of the av_fifo_size function and I just did the math myself, but maybe the
[21:56:18 CEST] <_Mike_C_> on the first run of the function the return value is 16
[21:56:28 CEST] <_Mike_C_> one the second run, its 0
[21:56:46 CEST] <BtbN> That can be really anything
[21:56:46 CEST] <_Mike_C_> Maybe the divide by sizeof(NvencSurface*) is messing up the variable number
[21:56:59 CEST] <BtbN> No, it returns the actual size
[21:58:41 CEST] <BtbN> 16 is also super low. A single surface is larger than that.
[21:59:18 CEST] <BtbN> I'll just assume your debugger is doing nonsense
[21:59:48 CEST] <_Mike_C_> Im using the visual studio debugger
[21:59:56 CEST] <_Mike_C_> when it steps me into the av_fifo_size function
[22:00:13 CEST] <_Mike_C_> the first time, f->wndx is 16 and f->rndx is 0
[22:00:29 CEST] <_Mike_C_> the second time its 16 and 16
[22:00:40 CEST] <BtbN> No idea what that is
[22:01:19 CEST] <_Mike_C_> they're some pointers in the AFifoBuffer : (
[22:01:34 CEST] <BtbN> I never looked at that code, the buffers just work
[22:02:09 CEST] <BtbN> Anyway, with what you are telling, the only actual answer I can give you is "You are doing something wrong"
[22:03:22 CEST] <_Mike_C_> Unfortunately I don't know how to figure out what that is, I've followed the examples and have a working product with software encoders. Its something about using this hardware encoder (possibly on windows) and ive tracked down the fail location the best I can.
[22:03:59 CEST] <_Mike_C_> That last return statement in output_ready returns false even with the input buffer returning EAGAIN
[22:09:12 CEST] <_Mike_C_> I suppose I'll take your advice and put in debug print statements, recompile and recheck the values I'm getting. Hopefully I can come back to you with better information
[22:46:21 CEST] <Pistos> I am rendering a video using kdenlive. It has a slider in the render dialogue which I am *guessing* refers to options sent to ffmpeg: "Encoder speed", which, when you hover over it, says "Codec speed parameters: preset=ultrafast" So, assuming this really does pass this to ffmpeg, my question is: Is this tradeoff encoding time vs. file size? Or something else? Will changing the preset affect quality, or
[22:46:23 CEST] <Pistos> just file size? Reference: https://trac.ffmpeg.org/wiki/Encode/H.264
[22:48:38 CEST] <BtbN> That depends on the other settings.
[22:52:29 CEST] <kepstin> Pistos: that sets an option specific the the libx264 encoder (and I guess libx265 uses a similar option too)
[22:53:13 CEST] <kepstin> Pistos: assuming other options are set the same, changing the speed option mostly affects encoding time vs file size, but can also make some minor quality changes.
[23:05:30 CEST] <BtbN> If it's set to a fixed bitrate, changing the preset will affect the quality a whole lot
[23:06:05 CEST] <kepstin> ah, yeah, i sometimes forget that people use modes other than crf ;)
[23:17:37 CEST] <pi-> poutine: Thanks! That was it!
[23:30:18 CEST] <Pistos> Okay, thanks for the info, guys.
[23:31:28 CEST] <Pistos> Well, the kdenlive interface seems to have this output in a textfield, which presumbly is trying to tell me some of the command line params being passed to the underlying ffmpeg, melt, etc.: properties=x264-medium f=mp4 vcodec=libx264 acodec=aac g=120 crf=%quality ab=%audiobitrate+'k'
[23:31:45 CEST] <Pistos> In the dialogue box, I have the %quality (I assume) set to 24, and audio 192
[23:32:35 CEST] <Pistos> I've played with %quality at 15 and 45 for a short fragment of my video, and the video quality is noticeable when it's as high as 45 for crf, but difference between audio 64 and audio 192 is inaudible to my ears (for this particular source recording).
[23:33:34 CEST] <Pistos> So, assuming I'm relatively okay with larger file sizes, choosing ultrafast as a preset should be okay?
[23:35:12 CEST] <BtbN> veryfast is usually the fastest not completely shit option
[23:36:31 CEST] <Pistos> BtbN: Thank you.
[23:36:50 CEST] <Pistos> I'm rendering a clip now with various settings, putting them to the eye- and ear-test.
[23:42:13 CEST] <Pistos> I can't tell the difference with my eyes or ears: Given exiftool reporting Avg Bitrate of 2.91 Mbps (smaller file) vs. 9.69 Mbps (larger file), which is supposedly better quality?
[23:42:50 CEST] <Pistos> Render time was a difference of double (half).
[23:49:09 CEST] <iive> you might want to enable psnr and ssim statistics, they can give you some objective numbers.
[23:57:10 CEST] <kepstin> Pistos: in general, you want to pick the slowest preset that is "fast enough" for your application, then choose a crf value that provides the quality level you want.
[23:59:49 CEST] <Pistos> I have a 17.5 minute video which, with this machine, settings, effects, etc., takes 2 hours to render. I'm just getting impatient :) , and am looking for ways to speed up render time without noticeably sacrificing quality.
[00:00:00 CEST] --- Fri Aug 31 2018
More information about the Ffmpeg-devel-irc
mailing list