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

[burek]

[00:11:29 CEST] <kyleogrg> anyone know what libvpx-vp9 parameters will mimic youtube's videos?
[00:11:42 CEST] <kyleogrg> For 240p, 360p, 480p, etc
[00:22:03 CEST] <Lal> Uh, no idea, but I do know that youtube publishes the recommended encoding settings at https://support.google.com/youtube/answer/1722171?hl=en and some info about their transcodes at https://support.google.com/youtube/answer/2853702?hl=en
[00:22:22 CEST] <Lal> Sorry I can't be of more help, but you could probably extract what you need from that.
[00:23:27 CEST] <kyleogrg> thanks
[00:23:28 CEST] <kepstin> kyleogrg: I assume they're probably using something similar to the "Constrained Quality Recommended Settings" listed on https://sites.google.com/a/webmproject.org/wiki/ffmpeg/vp9-encoding-guide
[00:23:41 CEST] <kyleogrg> if i downloaded some youtube videos,
[00:23:55 CEST] <kyleogrg> could i run some analysis on them and infer the proper settings?
[00:24:08 CEST] <kyleogrg> like gop size, min/max bitrate?
[00:24:50 CEST] <kepstin> kyleogrg: you could probably figure out gop size and max bitrate (if you used some very complex/hard to encode examples)
[00:25:08 CEST] <TD-Linux> you could also look at altref placement and quantizers to figure the rest out
[00:25:09 CEST] <kyleogrg> kepstin: how could i do that?
[00:25:10 CEST] <kepstin> be harder to figure out the crf they're using (assuming they're doing constrained quality)
[00:25:53 CEST] <kyleogrg> TD-Linux: sorry, i don't really follow
[00:25:54 CEST] <kepstin> kyleogrg: ffprobe with -show_streams -show_frames should give the needed info for basic stuff.
[00:26:09 CEST] <kyleogrg> kepstin: i'll try that.  haven't used ffprobe much
[00:26:19 CEST] <kepstin> but to get anything more, you have to be familiar with the binary encoding of vp9 streams :/
[00:26:48 CEST] <kepstin> which is probably not much like the binary language of evaporators.
[00:27:13 CEST] <kepstin> er, moisture vaporators ;)
[00:27:41 CEST] <kyleogrg> i just want to get as close as possible
[00:28:20 CEST] <kepstin> the really annoying thing is that it's hard to get both an original video and a re-encoded vp9 video from youtube so you can do test encodes to try to match it
[00:28:28 CEST] <kepstin> since they only do vp9 encodes for "popular" videos
[00:28:34 CEST] <Lal> Remember that some downloaders, like youtube-dl, are able to download the non-transcoded source file if you pick the maximum quality example (I've been able to download higher resolutions that what youtube lists on my own uploads
[00:28:45 CEST] <Lal> And have been able to confirm that they match in size)
[00:29:02 CEST] <kyleogrg> Lal: really, the actual source?  i have youtube-dl.
[00:29:11 CEST] <kepstin> lets see. oh hey, there's at least one video on my channel with a vp9 encode, and I still have the original file that I uploaded to youtube for that
[00:29:17 CEST] Action: kepstin should try doing some test encodes :)
[00:29:57 CEST] <Lal> If I'm remembering correctly, the download from youtube-dl matched with the download from the download from Google Takeout
[00:30:12 CEST] <Lal> But that ONLY applies to the highest resolution
[00:30:17 CEST] <kyleogrg> kepstin: whoa, using ffprobe with those two options spits out a huge amount of info
[00:30:19 CEST] <Lal> Everything else should be fine
[00:30:47 CEST] <Lal> But, there's a chance I'm misremebering, since this was a while ago
[00:30:49 CEST] <kepstin> kyleogrg: yep, it should include the type of each frame (so you could e.g. write a script finding the keyframe interval), and have enough info to determine bitrates
[00:30:59 CEST] <Lal> So, if you find differing information, by all means, tell me
[00:31:02 CEST] <kepstin> kyleogrg: it's not really human-readable :)
[00:31:23 CEST] <Lal> Youtube's Keyframe interval is between 2 and 4, I thought
[00:31:41 CEST] <kyleogrg> Lal: that's interesting, i wonder which video might have the original as well
[00:31:56 CEST] <kepstin> should be something around there, yeah. They use DASH for serving the higher-end formats, so the keyframe interval should match the segment length
[00:31:59 CEST] <kyleogrg> kepstin: how could you calculate bitrate based on keyframe interval?
[00:32:09 CEST] <kepstin> kyleogrg: you don't
[00:32:21 CEST] <kepstin> kyleogrg: you use other information also printed by ffprobe to get that :)
[00:32:58 CEST] <medya> does ffmpeg set the container format only based on the extension of the output file ?
[00:33:14 CEST] <kyleogrg> is there an easy way to find the min and max bitrates?  mediainfo?
[00:33:15 CEST] <kepstin> medya: it autodetects from the extension, but you can override with the -f option
[00:34:09 CEST] <medya> @kepstin do you have an example
[00:34:16 CEST] <medya> and list of the possible options
[00:34:26 CEST] <medya> and does the container have no effect on the size?
[00:35:10 CEST] <kepstin> medya: you just put "-f formatname" before the output filename, doesn't really need an example
[00:36:17 CEST] <TD-Linux> kyleogrg, no, the bitstream only contains quantizers
[00:36:30 CEST] <kepstin> medya: running "ffmpeg -formats" will list the available formats, ones with 'E' can be used for output. many are special-purpose :)
[00:36:38 CEST] <TD-Linux> libvpx controls the bitrate using the quantizers
[00:36:51 CEST] <TD-Linux> so you need to figure out what options to libvpx with your input video create similar quantizers
[00:37:07 CEST] <kepstin> medya: different containers can have different amounts of overhead - the amount of extra bytes the container adds per frame on top of what the codecs use
[00:37:36 CEST] <kepstin> medya: but in most cases, you don't have to worry about it, it's small percentage differences
[00:37:42 CEST] <furq> blue_misfit: scenecut doesn't do anything if you're using keyint_min anyway
[00:37:44 CEST] <kyleogrg> TD-Linux: when you say quantizers... what encoding commands are you talking about
[00:37:57 CEST] <furq> but it looks like -1 actually disables it whereas 0 just sets the threshold so low it never gets triggered
[00:38:01 CEST] <TD-Linux> none, it's lower level
[00:38:02 CEST] <medya> cool thanks @kepstin
[00:38:39 CEST] <TD-Linux> you put in a bitrate, then libvpx allocates some number of bits for each frame, then chooses a quantizer for each frame
[00:38:44 CEST] <TD-Linux> you only have the last bit, so you need to work backwards
[00:38:58 CEST] <kyleogrg> complicated
[00:39:04 CEST] <TD-Linux> (well, you have the # of bits per frame too, so you could start there)
[00:42:22 CEST] <kyleogrg> maybe there's a shortcut way to approximate it?
[00:43:47 CEST] <kyleogrg> for instance, my downloaded 720p youtube video has 1205k bitrate according to mediainfo
[00:48:20 CEST] <kepstin> kyleogrg: you'll need to download a bunch of videos to compare, since they're probably using the constrained quality mode, so some videos will hit the max bitrate, others might be well below.
[00:52:34 CEST] <kyleogrg> kepstin: okay.  and to set the keyframe interval i use -g?
[00:54:30 CEST] <kepstin> kyleogrg: for dash streaming like youtube, you'll always want to set -keyint_min to the same value so you get fixed keyframe positions
[00:54:41 CEST] <kepstin> s/always/also
[00:58:18 CEST] <kyleogrg> kepstin: so what is -g?  my encodes were not seeking well in vlc, and when i googled i saw a suggestion to use -g 25.
[00:58:51 CEST] <kyleogrg> "-g 	Maximum keyframe interval (frames)"
[00:58:52 CEST] <kyleogrg> okay
[00:59:06 CEST] <kepstin> interesting, youtube's vp9 encodes are *not* using -keyint_min
[01:00:10 CEST] <kyleogrg> ok, how did you find that out?
[01:00:29 CEST] <kepstin> by looking at the output of ffprobe -show_frames
[01:00:42 CEST] <kepstin> they keyframes are all irregularly spaced
[01:01:26 CEST] <kyleogrg> kepstin: what's your guess as to the max keyframe?
[01:05:26 CEST] <ozette> no matter if i set the configuration options of --enable-static and --disable-shared, the resulting ffmpeg is still asking for the libavdevice.so, anyone knows if there's an option in here which makes it so the libs aren't statically linked? https://paste.fedoraproject.org/412683/47190697/
[01:05:43 CEST] <kepstin> video I have isn't good for figuring that out. You'll want to find a video that basically just has a still image
[01:06:02 CEST] <kyleogrg> kepstin: you mean a slideshow, or literally one image?
[01:06:19 CEST] <furq> ozette: did you run make clean
[01:06:23 CEST] <furq> and/or make distclean
[01:06:26 CEST] <kepstin> kyleogrg: literally one image.
[01:07:44 CEST] <furq> i have one but there's no 720p vp9 for some reason
[01:07:47 CEST] <furq> also it's 6fps
[01:08:20 CEST] <furq> oh nvm yes there is
[01:08:41 CEST] <furq> https://www.youtube.com/watch?v=8wuWoZAIazg
[01:08:41 CEST] <furq> hf
[01:09:16 CEST] <kepstin> interesting. when comparing my 1080p and 720p videos on youtube, the 720p has fewer frames that ffprobe reports as keyframes, but all the remaining keyframes are in the same location.
[01:09:37 CEST] <furq> also i notice firefox is actually using vp9 in favour of h264 now
[01:09:45 CEST] <furq> it took long enough
[01:09:48 CEST] <kyleogrg> furq: yeah
[01:10:08 CEST] <kyleogrg> kepstin: furq's video has only one image
[01:12:06 CEST] <kepstin> furq's video has a keyframe every 30 frames, which would be every 5 seconds
[01:12:53 CEST] <ozette> furq: hmm no i never did
[01:12:57 CEST] <kyleogrg> kepstin: so the keyframe interval depends on the type of video?
[01:13:36 CEST] <kepstin> kyleogrg: I suspect the keyframe interval is set in seconds, not frame count - which isn't supported directly by ffmpeg (you can calculate it from the framerate, of course)
[01:14:15 CEST] <kepstin> I wonder how youtube's encoder handles vfr videos
[01:14:18 CEST] <kyleogrg> kepstin: ah, so -g 5 should be five seconds?
[01:14:28 CEST] <furq> -g 5 is every five frames
[01:14:36 CEST] <kepstin> no, that's 5 frames (which in most videos is way less than 1 second)
[01:14:44 CEST] <furq> as he said you'd need to calculate it from the framerate
[01:14:50 CEST] <kyleogrg> oh, i had it backwards
[01:15:18 CEST] <kyleogrg> so 5 * 29.97 is 149.85.  so -g 149.85?  or -g 150?
[01:15:28 CEST] <kepstin> has to be an integer
[01:17:14 CEST] <kyleogrg> kepstin: and then i just won't use min rate option, right?
[01:18:20 CEST] <kepstin> minrate should almost never be used
[01:18:59 CEST] <kepstin> (if you needed minrate, you'd already know that you need minrate)
[01:19:22 CEST] <furq> i assume you're both talking about keyint_min
[01:19:50 CEST] <kepstin> oh, I though kyleogrg was talking about -minrate
[01:19:50 CEST] <kyleogrg> yeah
[01:20:01 CEST] <kyleogrg> I'm talking about keyint_min
[01:20:19 CEST] <kepstin> Yes, use -keyint_min if you're doing segmented streaming e.g. DASH
[01:20:47 CEST] <kyleogrg> and it should also be 150?
[01:20:57 CEST] <kepstin> should be set to the same thing as -g
[01:21:25 CEST] <furq> if youtube's not using it for dash then i suspect you don't need it, and it'd be better to not use it in general
[01:21:38 CEST] <kepstin> hmm, i'm not sure whether or not they're using it
[01:21:40 CEST] <furq> i remember it causing issues with nginx-rtmp though so ymmv
[01:21:58 CEST] <kepstin> for dash, you do want aligned keyframes between different formats so format switching works cleanly
[01:22:08 CEST] <furq> that's true
[01:22:19 CEST] <furq> although i assume they'd always be aligned between the same codec
[01:22:44 CEST] <kyleogrg> so youtube use the same keyframe interval across different resolutions?
[01:22:46 CEST] <furq> certainly with vp9 if you're using 2-pass
[01:23:02 CEST] <furq> or with x264 with 2-pass but it's less common to use that
[01:23:26 CEST] <kepstin> furq: my quick check indicated that youtube's vp9 encode the 720p had fewer keyframes than 1080p, but those that remained were in the same spot
[01:23:34 CEST] <kepstin> so I suppose it could be
[01:23:59 CEST] Action: kepstin is trying to get a copy of one of youtube's dash manifest files to see how they are indicating segments.
[01:24:49 CEST] <ozette> furq: finally, this seems more like it, the binary is 15mb
[01:25:01 CEST] <ozette> it was 280kb at first, thanks :)
[01:29:26 CEST] <blue_misfit> kepstin, thanks for the info
[01:29:36 CEST] <blue_misfit> I'd prefer to not set keyint-min at all, actually
[01:29:55 CEST] <blue_misfit> just setting keyint and scenecut seems to be the simplest thing
[01:30:28 CEST] <blue_misfit> I remember there being some issues with setting keyint = keyint-min with x264 standalone encoder many years ago... not sure if that's still relevant
[01:42:57 CEST] <kepstin> hmm. ok, so youtube's dash isn't splitting the video into individual separate segments, instead each segment is the whole video length (more or less; they might use multiple segments for really long videos? not sure)
[01:43:20 CEST] <kepstin> but they do have the 'subsegmentAlignment="true"' flag set
[01:43:38 CEST] <blue_misfit> @kepstin, I'd imagine they use range requests?
[01:43:50 CEST] <kyleogrg> kepstin: what does this mean regarding keyframes?
[01:44:20 CEST] <kepstin> yeah. THe dash manifest gives the location of the initial header within the file (byte offset and length) for the browser to read the file metadata with a range request
[01:44:45 CEST] <kepstin> and then the browser presumably reads the matroska cues list to determine keyframe locations
[01:46:43 CEST] <kyleogrg> kepstin: are you saying the keyframes aren't consistently 5?
[01:46:57 CEST] <blue_misfit> exactly
[01:47:17 CEST] <blue_misfit> you can do adaptive gop with ABR, you just have to be clever about it :)
[01:47:27 CEST] <kyleogrg> blue_misfit: then what's the keyframe range?
[01:47:29 CEST] <kepstin> kyleogrg: keyframes in real videos I've seen on youtube aren't consistently 5s. However, that's the *max* keyframe interval, as far as I can tell, so basically what you'd set with -g
[01:47:40 CEST] <blue_misfit> not sure what range they use
[01:47:48 CEST] <kyleogrg> kepstin: okay, and should I set a minimum?
[01:47:48 CEST] <blue_misfit> typical DASH would be anywhere from 2-10 seconds
[01:48:08 CEST] <kepstin> kyleogrg: I suspect that youtube is not setting a minimum
[01:48:23 CEST] <kyleogrg> okay
[01:48:43 CEST] <kepstin> like, on one of my videos, there's two keyframes on 6 frames apart (at about 24fps)
[01:49:19 CEST] <nandex> hi, I'm creating mp4 video from images but when I plays from a web, the video has too lag. somebody know how to fix this?? ffmpeg -framerate $FPS -i $DIR/$FILENAME%d.png -c:v libx264 -profile:v high -crf 20 -b:v 1M -pix_fmt yuv420p output.mp4 -audio.aac -c:a aac -b:a 128k
[01:50:04 CEST] <kyleogrg> kepstin: okay.  i guess i asked before, but are the keyframes the same for each resolution?
[01:50:07 CEST] <kepstin> nandex: what exactly do you mean by "lag"? does the video require extra buffering at some point?
[01:50:50 CEST] <nandex> the video takes a lot of time to start and is a video of 3 seconds
[01:51:23 CEST] <kepstin> kyleogrg: I suspect the max keyframe interval is always around 5s, but can't prove it. Since they've indicated that there are aligned keyframes in the dash manifest, I assume they use the same settings on all video sizes.
[01:51:23 CEST] <drv> add -movflags faststart
[01:51:46 CEST] <kyleogrg> kepstin: okay, i appreciate all the help
[01:51:46 CEST] <nandex> with the same flags?
[01:52:06 CEST] <kepstin> nandex: yes, just add that.
[01:52:16 CEST] <nandex> ffmpeg -movflags faststart -framerate $FPS -i $DIR/$FILENAME%d.png -c:v libx264 -profile:v high -crf 20 -b:v 1M -pix_fmt yuv420p output.mp4 -audio.aac -c:a aac -b:a 128k
[01:52:29 CEST] <drv> it's an output option, so it needs to go after the input stuff
[01:52:41 CEST] <nandex> ok,  ;)
[01:53:03 CEST] <kepstin> nandex: note that with libx264, you can't set both '-crf' and '-b:v' at the same time, it is ignoring one of them
[01:53:10 CEST] <kepstin> (i don't know which one)
[01:53:35 CEST] <nandex> I think that crf is better
[01:53:53 CEST] <kepstin> it usually is, yeah. Just remove the -b:v option.
[01:57:46 CEST] <nandex> Do you recommended to me something for do this?? first I use ffmpeg to get the frames and audio, and then I use this command to get this video_out
[02:00:49 CEST] <witChdoCtOr> hello
[02:07:05 CEST] <nandex> I have the same problema, I put the video in a server and takes about 10secs to start
[02:07:15 CEST] <nandex> is too because video only has 3 seconds
[02:10:12 CEST] <nandex> ffmpeg -i $DIR/$FILENAME%d.png -c:v libx264 -profile:v high -crf 20 -pix_fmt yuv420p -movflags faststart out.mp4 -i audio.aac -c:a aac -b:a 128k. when add the out.mp4 to a server it takes a lot of time to start
[02:13:00 CEST] <furq> that's not a valid command
[02:13:10 CEST] <furq> oh nvm yes it is
[02:13:38 CEST] <furq> wait, no it isn't. there's no output file for audio.aac
[02:14:36 CEST] <nandex> is the same video file, no?
[02:14:42 CEST] <furq> no
[02:14:52 CEST] <furq> out.mp4 should be the last argument
[02:15:04 CEST] <furq> also you probably don't need to reencode the audio
[02:15:45 CEST] <nandex> but, why video takes about 10seconds to start to play?
[03:10:49 CEST] <witChdoCtOr> what does -crf do?
[03:18:13 CEST] <DHE> it's a compression mode that is intended to provide a constant "perceived" quality in a single pass. the more complex/motion-busy the scene, the lower the per-frame quality
[03:18:58 CEST] <DHE> where 0 is close to lossless and bigger modes mean more quality loss
[03:22:15 CEST] <witChdoCtOr> Couldn't find in help just realized I don't have libx264
[03:22:41 CEST] <witChdoCtOr> Does anyone here work with the libs?
[03:22:49 CEST] <DHE> quite a bit yeah
[03:23:43 CEST] <witChdoCtOr> have you used the new 3.1 ABI?
[03:25:09 CEST] <DHE> with codecpar?
[03:25:19 CEST] <witChdoCtOr> Yes!
[03:26:19 CEST] <DHE> it should still be in the deprecation phase. using the old API should log warnings but still work
[03:27:17 CEST] <witChdoCtOr> It is, but I am writing new code
[03:27:52 CEST] <witChdoCtOr> I got my decode to work but having issues creating the raw output, when I don't have an input to copy from
[03:42:43 CEST] <witChdoCtOr> https://gist.github.com/anonymous/de262eba06458b7dbf6b601d16ac7316
[04:22:58 CEST] <witChdoCtOr> https://gist.github.com/LinuxwitChdoCtOr/74c1721dd7688cf1d16509ea2a52d231
[05:15:04 CEST] <witChdoCtOr> hello
[09:18:25 CEST] <speedio> i have a wmv video on 30mb which i want to convert to mp4(x264).. i tried settings like maxrate 800 and preset ultrafast.. but the file gets huge, from 300mb-2gb.. how can i just convert it so it stays around 30-50mb?
[09:19:56 CEST] <furq> well for starters, don't use preset ultrafast
[09:20:56 CEST] <nonex86> x264? check qp option
[09:36:33 CEST] <speedio> ok will check qp option
[11:08:15 CEST] <Spring> Unknown encoder 'libfdk_aac'
[11:09:31 CEST] <Spring> hmm, would have expected zeranoe's builds to have it
[11:10:08 CEST] <c_14> builds with libfdk-aac aren't redistributable
[11:10:14 CEST] <Spring> oh
[11:10:43 CEST] <JEEB> for many use cases the internal AAC encoder is already usable though with the latest FFmpeg
[11:10:52 CEST] <JEEB> HE-AAC is one use case where it isn't (yet)
[11:10:58 CEST] <Spring> cool beans, that's just 'aac' right?
[11:11:00 CEST] <JEEB> LC-AAC should be usable tho
[11:11:13 CEST] <JEEB> yup, that should be it
[11:12:40 CEST] <Spring> the Tune settings for x264 are separate from the filters options, correct?
[11:15:34 CEST] <Spring> yeah, it is.
[11:16:02 CEST] <ozette> should i --enable-ffprobe explicitly to have it build?
[11:17:22 CEST] <Spring> btw why is the CRF quality so different between h264 and VPx?
[11:17:41 CEST] <Spring> CRF 33 in VPx is completely different from CRF 33 in x264
[11:18:13 CEST] <viric> I have seen different quality with same CRF within x264
[11:18:30 CEST] <Spring> viric, with the same source file?
[11:18:32 CEST] <viric> no
[11:18:37 CEST] <Spring> mine is the same
[11:18:54 CEST] <viric> For recordings of one camera, the CRF values acted similar
[11:19:05 CEST] <viric> When I switched to a recording of another (similar) camera, the result changed a lot
[11:19:11 CEST] <viric> for my taste.
[11:20:37 CEST] <ozette> i have an old ffprobe which i did not rebuilt, brought over from another system w/ same arch. it doesn't quite seem to run well.
[11:20:49 CEST] <ozette> line 33 and 34 http://paste.debian.net/791071/
[11:21:06 CEST] <Spring> is it because VP9 has a maximum CRF of 63 while x264 only 50?
[11:21:27 CEST] <Spring> *51
[11:22:32 CEST] <Spring> need to work out how to calculate the equivalent quality for the same input
[11:35:23 CEST] <ozette> when i configure the ffmpeg source, it says enabled programs ffmpeg and ffprobe, but it only builds ffmpeg
[11:36:39 CEST] <ozette> i must say that at the end i receive this error, not sure if it's supposed to build ffprobe after this:
[11:36:45 CEST] <ozette> strip: Unable to recognise the format of the input file `ffmpeg'
[11:36:48 CEST] <ozette> Makefile:127: recipe for target 'ffmpeg' failed
[11:36:50 CEST] <ozette> make: *** [ffmpeg] Error 1
[11:36:52 CEST] <ozette> y
[11:37:53 CEST] <Guest19512> Hi everybody. I'm glad if somebody could help me. I have a mp4 video file which should be sliced into 4 areas simultaneously. These 4 slices then should be streamed to 4 different clients.
[11:38:12 CEST] <ozette> i believe this is because the resulting ffmpeg is meant for another architecture and make tries to somehow execute a part of it? it runs fine on the target system
[11:38:39 CEST] <ozette> i'm not familiar with 'strip'
[11:40:36 CEST] <bencoh> if you're cross-compiling then it should (?) use $toolchain-strip instead
[11:40:46 CEST] <ozette> Guest19512: help with what? you know how to slice?
[11:41:00 CEST] <ozette> bencoh: i see
[11:41:50 CEST] <ozette> what's the configure option for that? --strip=$toolchain-strip ?
[11:41:56 CEST] <Guest19512> ozette: no, I don't. Final goal is: Have one video file -> slice into 4 pieces -> stream to client -> convert it into ppm
[11:42:46 CEST] <bencoh> ozette: I'd expect ffmpeg buildsystem to do that automatically in a crossbuild situation ... otherwise I'd say it's a bug :)
[11:42:55 CEST] <bencoh> or something wrong with your build
[11:43:15 CEST] <kdehl> nonex86: Hey.
[11:43:21 CEST] <kdehl> nonex86: It works now. Thank you so much!
[11:43:32 CEST] <bencoh> I do see strip_default="${cross_prefix}${strip_default}"
[11:43:33 CEST] <nonex86> kdehl, hey, nice, welcome :)
[11:43:35 CEST] <bencoh> in configure
[11:43:41 CEST] <kdehl> :)
[11:44:06 CEST] <kdehl> nonex86: My main since yesterday has been a integer division. Incredibly embarrassing.
[11:44:13 CEST] <kdehl> 3 / 2 * 100 != 100 * 3 / 2
[11:44:23 CEST] <bencoh> ozette: do you --cross-prefix=foobar ?
[11:44:25 CEST] <ozette> bencoh: well there's a --cross-prefix kind of thing, which i'm not using atm
[11:44:30 CEST] <ozette> ha
[11:44:31 CEST] <bencoh> well ... ;)
[11:44:34 CEST] <kdehl> Or even 100 * 3 / 2 != 100 * (3 / 2)
[11:44:53 CEST] <ozette> alright will try that
[11:44:57 CEST] <kdehl> *an integer division
[11:45:13 CEST] <bencoh> ozette: as a rule of thumb, never expect build systems to work properly in a crossenv just by overriding CC :)
[11:46:11 CEST] <nonex86> result comparands are floating point values ? ;)
[11:46:54 CEST] <kdehl> nonex86: I'm too used to the real world, where they are exactly that!
[11:48:25 CEST] <nonex86> well, fp values can cause the problems too :)
[11:48:49 CEST] <kdehl> To be honest I don't think I've ever programmed using floating point values.
[11:49:41 CEST] <nonex86> and in your case (3/2) will give 1 in case of integer
[11:49:53 CEST] <kdehl> Indeed.
[11:50:07 CEST] <nonex86> so, result is correct  100*3/2 != 100*(3/2)
[11:50:44 CEST] <kdehl> That expression is correct, yes. But the fact that it is correct took me a couple of ours to figure out.
[11:50:55 CEST] <nonex86> :)
[11:51:49 CEST] <kdehl> Naturally I found a problem with the _encoding_, after decoding the file.
[11:52:03 CEST] <ozette> bencoh: good point
[11:55:38 CEST] <Spring> Tried subtracting '7' from the VPx CRF value for the Mp4 (based on some previous tests) however this will fall apart if a much lower value is added
[12:02:58 CEST] <ozette> yay no errors, and got me a ffprobe :)
[12:11:29 CEST] <EmleyMoor> I'm trying to concatenate two .MOV files from my dashcam (or all but the first minute of one with just the first 10 seconds of another) but cannot see a way to do it that actually works...
[12:15:04 CEST] <EmleyMoor> The concat protocol just results in a freeze where the first file ends
[12:15:56 CEST] <EmleyMoor> As for the concat demuxer, I can't see how to actually use it.
[12:18:58 CEST] <iive> EmleyMoor: by protocol you mean the -filter complex ... concat one?
[12:19:33 CEST] <iive> it have requirement that the input must start from timestamp 0
[12:20:38 CEST] <iive> so sometimes it helps if you just stream copy the parts you need into new files (aka -c copy) and then use these files as inputs
[12:22:32 CEST] <EmleyMoor> iive: No, that's the filter, not the protocol
[12:23:15 CEST] <EmleyMoor> I can't get the filter to work either, says: Cannot find a matching stream for unlabeled input pad 4 on filter Parsed_concat_0
[12:29:27 CEST] <EmleyMoor> Don't care which method, but need to get one of them to work
[12:30:43 CEST] <ozette> ffprobe fails to make thumbnails, wondering if it's a lib i'm missing when ffprobe returns this to me:
[12:30:46 CEST] <ozette> [NULL @ 0x31708a0] Unable to find a suitable output format for '/path/video/thumbs/d06acc15edd0af66065af378605c2fa9/tn_1.png'
[12:31:19 CEST] <iive> ffmpeg -i v1.mp4 -i v2.mp4 -filter_complex '[0:0] [0:1] [1:0] [1:1]  concat=n=2:v=1:a=1 [v] [a] -map '[v]' -map '[a]'
[12:31:55 CEST] <iive> the above is incomplete example for 2 files. you need to specific video and audio codec and output file.
[12:31:58 CEST] <ozette> ffprobe v3.1.2
[12:32:43 CEST] <iive> ozette: no, missing library would prevent the program from running.
[12:33:24 CEST] <EmleyMoor> Ah - just a question of getting all the numbers right
[12:34:18 CEST] <ozette> iive: i mean a non --enabled library, even then?
[12:35:06 CEST] <iive> ozette: i'm not that familiar with ffprobe, but I think it doesn't have an output... so the error message is a bit puzzling.
[12:35:18 CEST] <ozette> hmm i see
[12:35:23 CEST] <iive> what is your command line?
[12:35:45 CEST] <ozette> actually i'm using a library to generate the command for me, one moment i'll try to figure it out
[12:36:04 CEST] <ozette> it's puzzling to me too, because my application works on x64
[12:36:53 CEST] <ozette> now i built ffmpeg and ffprobe for this particular one armada-xp processor, and both programs look 'ok'
[12:38:11 CEST] <ozette> thumbnail step however fails, not sure if anyone gets any wiser from this: http://paste.debian.net/791071/ .. i'll try to find out the actual command
[12:44:05 CEST] <iive> my blind guess at this point is that you are missing "-i" option
[12:44:43 CEST] <iive> nah, ffprobe doesn't need it.
[12:46:11 CEST] <ozette> mhm
[12:46:27 CEST] <iive> it output file information (from demuxer). It probably tries to decode the image and it can't find pixel format for it.
[12:46:30 CEST] <ozette> the way i create the thumbs is also according to an example, which works fine on my other workstation
[12:46:45 CEST] <ozette> so it doesn't know png?
[12:46:46 CEST] <iive> is the png created by ffmpeg itself?
[12:47:24 CEST] <ozette> yea, it's supposed to
[12:47:40 CEST] <ozette> but i see no png in the directory
[12:48:30 CEST] <ozette> currently looking for a way with this lib to output the input to a file or something
[12:48:32 CEST] <iive> ozette: when the decoder is run, sometimes it could output more than one format, so there is code to negotiate the format.
[12:48:49 CEST] <iive> probably this is the output it talks about.
[12:49:55 CEST] <iive> what does `file tn_1.png` say?
[12:53:06 CEST] <Spring> what's the difference between -maxrate and -b:v when used for x264? In VP9 -b:v is used to set a max bitrate cap. Is there any difference?
[12:53:30 CEST] <ozette> iive: there's no tn_1.png unfortunately
[12:55:25 CEST] <Spring> confusingly there's a Stack Exchange answer which states -b:v is used to specify a constant bit rate
[12:56:04 CEST] <ozette> what exactly is `file tn_1.png` supposed to do?
[12:56:22 CEST] <iive> ozette: indeed, it prints info of mp4 file.
[12:56:48 CEST] <iive> it should tell some info about the file, aka, resolution color format.
[12:57:17 CEST] <ozette> oh, you mean the video?
[12:57:25 CEST] <iive> i haven't got much sleep today, so i'm not quite sharp knife.
[12:57:43 CEST] <ozette> haha don't mind
[12:57:54 CEST] <iive> ozette: find the exact command line (with arguments) and you might have an answer.
[12:58:27 CEST] <ultrav1olet> upload.ffmpeg.org ftp is down
[12:58:34 CEST] <ultrav1olet> when can I upload files to?
[12:58:43 CEST] <ozette> iive: sure, i'll try to find out, the lib i'm using abstracts things so..
[12:58:51 CEST] <ozette> this is the output of file on the video btw SampleVideo_1280x720_1mb.mp4: ISO Media, MP4 Base Media v1 [IS0 14496-12:2003]
[12:59:41 CEST] <VamoMenem> Spring you can use -b:v 250k  -bufsize 250k
[12:59:54 CEST] <VamoMenem> to get 250k constant bitrate , look here. https://trac.ffmpeg.org/wiki/Limiting%20the%20output%20bitrate
[13:00:52 CEST] <Spring> VamoMenem, so that sets a constant bitrate? If I have say CRF 20 -b:v 20M what would that do?
[13:01:31 CEST] <Spring> trying to figure out the equivalent settings from VPx -> h.264 and the docs are a bit different
[13:03:32 CEST] <ultrav1olet> iive: upload.ffmpeg.org ftp is down. Where can I upload files to?
[13:04:38 CEST] <VamoMenem> Spring is very tricky get constant bitrate in libx264. If that not work for you can try to do -b:v 9M -minrate 8M -maxrate 10M
[13:05:22 CEST] <VamoMenem> in my case allways get a litte more than 10M. Documentatin recomends using min, max and b:v in the same value, but not worked for me
[13:05:54 CEST] <Spring> it probably does set a constant bitrate but I'm only looking for a max bitrate cap and was trying to understand the differences in syntax from one encoder to the other
[13:06:35 CEST] <JEEB> VamoMenem: maxrate and bufsize and general ABR are something passed onto libx264, but minrate is a thing inside lavc itself. I would generally never use it myself
[13:06:49 CEST] <Spring> I've read somewhere that -bufsize is required for -maxrate, is there a simple calculation for how much bufsize would be needed?
[13:07:03 CEST] <JEEB> it is just a figure you should configure between your player and encoder
[13:07:13 CEST] <JEEB> the more is needed the more the player has to buffer to be sure
[13:07:29 CEST] <JEEB> maxrate*2 would be two seconds worth of buffer, for example
[13:07:42 CEST] <JEEB> and yes, I was just going to say that you in general should never use just maxrate, but also define bufsize
[13:08:15 CEST] <JEEB> these of course only limit the maximum bit rate over bufsize
[13:09:09 CEST] <JEEB> in most cases you really don't want a really constant constant bit rate, so that's OK for 99% of all uses
[13:09:32 CEST] <JEEB> (that way the encoder can also be more adaptive regarding where to use bits)
[13:09:46 CEST] <VamoMenem> JEEB yesterday y checked everithing! in certain situations min max and buf and b:v can help
[13:10:15 CEST] <JEEB> b:v is the general rate control mode
[13:10:36 CEST] <JEEB> maxrate and bufsize are implemented in libx264 and minrate is a libavcodec hack that *can* work
[13:10:53 CEST] <JEEB> but I would generally not use it due to it not being a libx264 feature
[13:11:29 CEST] <Spring> just to be clear, bufsize isn't just for streaming, or is it? Just wanting to cap CRF quality at a certain max bitrate.
[13:12:02 CEST] <JEEB> it is for all use cases where you need to limit bit rate to a specific rate over a buffer
[13:12:11 CEST] <JEEB> media, internets, limited bandwidth in general
[13:12:12 CEST] <VamoMenem> helps if you need not exed a bitrate. maxrate can exced it. setting minrate to a lower desired value (ej to get 300kbps set min to 200, b:v 250 and max 300) do the jobe
[13:12:52 CEST] <JEEB> if you just need a general maximum then I recommend you do a CRF encode first and then use 2pass to a specific ABR in case the CRF encode is too big
[13:13:06 CEST] <JEEB> (or just set bufsize very large, but I'm not sure how well that will work
[13:13:19 CEST] <iive> ultrav1olet: the `host` command says that this address is alias for streams.videolan.org ...
[13:13:51 CEST] <VamoMenem> nice, but if you want a low latency scenario a big bufsize is not an option.
[13:14:30 CEST] <VamoMenem> is my case, i dont try using 2pass yet but readed about it
[13:14:59 CEST] <JEEB> of course not, I'm just saying for Spring :P since he seems to just want to use CRF + specific ABR rate in case CRF gets too big
[13:15:25 CEST] <JEEB> not specifically bufsize+maxrate VBV/HDR
[13:17:08 CEST] <Spring> yeah, basically just trying to reproduce in x264 -crf <value> -b:v <value> from VPx which does that.
[13:17:24 CEST] <JEEB> that doesn't do that
[13:18:02 CEST] <Spring> JEEB, this is wrong? https://trac.ffmpeg.org/wiki/Encode/VP9
[13:18:34 CEST] <Spring> seems to works for me
[13:18:38 CEST] <JEEB> not necessarily, I'm just saying that it doesn't do exactly what you think it does and that crf+ABR isn't a thing that should be (it generally means something different as it originally did in libx264)
[13:18:51 CEST] <JEEB> it's just how the CRF option got mapped in libvpx :P
[13:19:13 CEST] <brontosaurusrex> What should I say if i want interlaced prores encoding?
[13:19:48 CEST] <Spring> makes it a tad confusing :)
[13:19:55 CEST] <JEEB> anyways, two alternatives. you either use like a ten+ second buffer, or you just do a full unlimited CRF and then unlimited 2pass to a specific ABR if the CRF is too big
[13:20:08 CEST] <JEEB> Spring: yeah I have generally been against using the same option name for things that don't actually have it
[13:20:33 CEST] <JEEB> CRF came from libx264 originally and people just decided to map other encoders' "constant quality" like modes (whatever that actually means) to it
[13:21:12 CEST] <Spring> no wonder the CRF values aren't equivalent
[13:21:43 CEST] <Spring> so with a 10+ second buffer what kind of an effect would that have if someone is just playing it in their browser?
[13:22:16 CEST] <JEEB> if you don't set a buffer in the player at all, nothing really :P it just means that the maximum usable video bit rate is limited to the maxrate over bufsize
[13:22:44 CEST] <JEEB> so you have X megabits being the maximum bit rate, and bufsize is X*10 for example
[13:23:16 CEST] <JEEB> whether or not it hits that rate depends on your CRF value, preset and the content itself
[13:23:31 CEST] <ultrav1olet> iive: and streams.videolan.org is an alias for jones.videolan.org
[13:23:41 CEST] <Spring> I'll try some tests, thanks
[13:34:35 CEST] <Spring> appears to work, nice
[13:34:48 CEST] <Spring> the buffer is 200M lmao
[13:40:28 CEST] <ozette> iive: i found out the input the lib uses, the first line (very long) is actually what it's trying to output (20 images) http://paste.debian.net/791090/
[13:41:28 CEST] <ultrav1olet> when I'm trying to conver flash video (H.264 codec) to any other video format, my ffmpeg changes its framerate from 30 to 15
[13:41:28 CEST] <ozette> the last two lines is what makes my ffmpeg exit
[13:41:45 CEST] <ultrav1olet> Why does it do that?
[13:42:06 CEST] <migzi> hi guys, iam having a problem getting atempo to run, i have a video file 22:00.01 length , and a audio file, length 21:07.90,  i want to use atempo as accurate as possible to adjust the audio speed
[13:42:23 CEST] <migzi> can someone help me to calculate the right speed
[13:42:25 CEST] <JEEB> ultrav1olet: it should keep the input timestamps unless there's a bug or you're setting the input rate
[13:42:44 CEST] <JEEB> or output rate
[13:42:50 CEST] <ultrav1olet> JEEB: that's all I do: ffmpeg -i source -c:v libx264 -preset veryslow out.mkv
[13:43:06 CEST] <JEEB> yeah, that shouldn't touch the amount of pictures or the timestamps of them
[13:43:47 CEST] <iive> ozette: well, it's definitely not ffprobe, it is classic ffmpeg :D
[13:43:50 CEST] <ultrav1olet> source: Stream #0:1: Video: h264 (Baseline), yuv420p(tv), 640x480 [SAR 1:1 DAR 4:3], 30.30 fps, 15 tbr, 1k tbn, 60 tbc
[13:44:07 CEST] <ultrav1olet> result: Stream #0:0: Video: h264 (High), yuv420p, 640x480 [SAR 1:1 DAR 4:3], 15 fps, 15 tbr, 1k tbn, 30 tbc (default)
[13:44:18 CEST] <ultrav1olet> WTF?
[13:44:19 CEST] <JEEB> ultrav1olet: but did you check the actual timestamps :P
[13:44:25 CEST] <durandal_1707> migzi: divide one number with another, in seconds
[13:44:34 CEST] <ultrav1olet> JEEB: how can I do that?
[13:44:45 CEST] <JEEB> like, try playing is the simplest
[13:44:49 CEST] <migzi> i did, 42 is the difference
[13:44:54 CEST] <migzi> ah divide oke
[13:45:02 CEST] <JEEB> if you suddenly lost half of the pictures it should be clearly visible
[13:45:20 CEST] <ultrav1olet> JEEB: what should I see?
[13:45:48 CEST] <ultrav1olet> mpv_identify.sh also says the source is 30fps
[13:45:49 CEST] <migzi> thank you
[13:45:53 CEST] <JEEB> if it looks OK it's most probably just some container data that ffmpeg/ffprobe is using to calculate the numbers, and how the files are created lead to different variables :P
[13:46:13 CEST] <JEEB> ultrav1olet: I mean it should be rather obvious if you suddenly lost half of the input pictures or the video was slown down
[13:46:24 CEST] <ultrav1olet> it looks ok to me
[13:46:33 CEST] <JEEB> then it is, and it's just the difference in containers
[13:47:02 CEST] <ultrav1olet> the difference which results in every other frame being lost?
[13:47:03 CEST] <JEEB> and how ffmpeg/ffprobe go get the general (initial) data
[13:47:07 CEST] <JEEB> no
[13:47:14 CEST] <JEEB> if it looks ok then you haven't lost jack shit
[13:47:31 CEST] <JEEB> it's just how the tool shows the average initial picture rate data
[13:47:38 CEST] <Spring> do presets change any of the options you set or just the speed/compression?
[13:47:39 CEST] <ultrav1olet> ticker 4643 - see the attached file, it's a flash video
[13:47:41 CEST] <JEEB> you can use ffprobe or something to actually output the data on the pictures
[13:47:47 CEST] <ultrav1olet> ticket
[13:47:50 CEST] <Spring> eg: ultrafast, slow, etc
[13:48:19 CEST] <JEEB> ultrav1olet: what I mean is that it's OK and for whatever reason your initial file data gets interpreted differentl for the initial shown information
[13:49:01 CEST] <JEEB> you can do more checking if you absolutely want, but my guess is it's just the input file and the initial data that leads to the difference in shown information in the tool you're using (and mpv also uses the same data for the initial stats)
[13:49:19 CEST] <JEEB> instead of those stats, the actual PICTURE TIMESTAMPS are used for any sort of playback or transcoding
[13:49:21 CEST] <ultrav1olet> JEEB: can I dump raw frames then?
[13:49:29 CEST] <ultrav1olet> I mean the number of them
[13:49:40 CEST] <JEEB> yes, ffmpeg -i input -f null -
[13:49:42 CEST] <ultrav1olet> This will give the correct asnwr
[13:49:45 CEST] <JEEB> that will decode them all
[13:49:50 CEST] <JEEB> do that for both
[13:50:21 CEST] <JEEB> ffmpeg should output how many pictures it decoded
[13:50:47 CEST] <Spring> this seems to explain it http://stackoverflow.com/questions/14306205/do-ffmpeg-h264-compression-presets-affect-the-video-quality
[13:50:54 CEST] <ultrav1olet> I see literally thousands of "Application provided invalid, non monotonically increasing dts to muxer in stream 0: 25739 >= 25739"
[13:51:15 CEST] <JEEB> yes, that just means that the FLV file is kind of derped
[13:51:23 CEST] <JEEB> but it should still decode :P
[13:52:09 CEST] <JEEB> Spring: it's generally just the speed/vs compression ratio. do note that because they change the internals the results with the same CRF value between presets is different
[13:52:22 CEST] <JEEB> it might not be too big of a difference but I still have to note it
[13:52:31 CEST] <JEEB> because some people go from medium to veryslow for example
[13:52:35 CEST] <JEEB> and expect a smaller file
[13:52:58 CEST] <JEEB> but then as the algorithms actually "see/compress more" than with the faster preset you actually can get a somewhat larger file
[13:52:58 CEST] <migzi> durandal_1707:    22 min (1320) / 21:07.9 (1267,9) results in 1.041091568735705 new audio size is 00:21:07.95  PERFECT
[13:52:58 CEST] <bencoh> Spring: x264 --fullhelp for an answer to how presets affect settings
[13:53:06 CEST] <migzi> thanks so simple
[13:53:08 CEST] <Spring> yeah, looking at these results there's not much of an advantage filesize wise, http://blogs.motokado.com/yoshi/2011/06/25/comparison-of-x264-presets/
[13:53:13 CEST] <ozette> iive: yea.. my mistake x)
[13:53:16 CEST] <Spring> though quality may improve
[13:53:24 CEST] <ozette> but i recall this part of my program not working if ffprobe was not around
[13:53:36 CEST] <JEEB> Spring: you shouldn't take such comparisons as general recommendations
[13:53:40 CEST] <ultrav1olet> JEEB: I divided the number of frames by the video length, got 19.387
[13:53:49 CEST] <ultrav1olet> RTMP sucks
[13:53:55 CEST] <JEEB> ultrav1olet: FLV can have variable rate and all just fine
[13:54:11 CEST] <ozette> anyhow why would this input work on my other systems, but not on this armada xp one with ffmpeg v3.1.2
[13:54:14 CEST] <JEEB> it has 1000 ticks per second, and all pictures then have a timestamp according to that
[13:54:15 CEST] <ozette> the command doesn't look weird to me
[13:54:37 CEST] <ultrav1olet> then when I reencode this video what target fps will ffmpeg choose?
[13:54:46 CEST] <JEEB> FPS  is not a thing that ffmpeg chooses
[13:54:52 CEST] <JEEB> it takes in input timestamps
[13:54:56 CEST] <JEEB> and uses those
[13:55:03 CEST] <JEEB> FPS in containers died ages ago :P
[13:55:09 CEST] <JEEB> AVI was one of the last ones to do that
[13:55:12 CEST] <ultrav1olet> JEEB: are you saying the target video will also have a varying FPS?
[13:55:31 CEST] <ultrav1olet> God
[13:55:35 CEST] <JEEB> yes, ffmpeg will not touch the amount of pictures or their timestamps
[13:55:56 CEST] <JEEB> well, depends on the output container timebase of course, some want smaller some want bigger :P
[13:56:46 CEST] <JEEB> ultrav1olet: basically if you run the ffmpeg thing on both input and output files and decode them they should have the same amount of pictures
[13:57:03 CEST] <ultrav1olet> you mean "frames"
[13:57:06 CEST] <JEEB> no
[13:57:08 CEST] <JEEB> pictures
[13:57:12 CEST] <JEEB> pictures can be frames or fields
[13:57:18 CEST] <ultrav1olet> OMG
[13:57:30 CEST] <ultrav1olet> I feel like a very old man
[13:57:54 CEST] <JEEB> I think very few decoders in libavcodec output field picture of course :)
[13:58:11 CEST] <JEEB> but since both are possible I like to use the general term that is also used in specifications
[13:58:24 CEST] <ozette> old men are full of wisdom
[13:59:09 CEST] <witChdoCtOr> Would anyone mind looking at some code and tell me how messed up I am?
[13:59:13 CEST] <JEEB> Spring: the way you do it usually is you pick a sample or a couple of them, pick 500 picture samples from it/them (like five or so of them), and then encode that first with different presets and then with different CRF values
[13:59:28 CEST] <JEEB> that way you first find the slowest preset that is still fast enough for you
[13:59:40 CEST] <JEEB> and then you find in that preset the highest CRF that sitll looks good for you
[14:00:11 CEST] <Spring> encoding still images you mean?
[14:00:18 CEST] <JEEB> no
[14:00:28 CEST] <Spring> just small clips then
[14:00:34 CEST] <JEEB> it's simpler with something like avisynth or vapoursynth but you can cut ~500 picture samples
[14:00:41 CEST] <JEEB> four or five or them should be enough
[14:00:48 CEST] <JEEB> that way you could have different types of content there
[14:00:57 CEST] <JEEB> and it takes less time than encoding a full movie or something
[14:00:59 CEST] <ultrav1olet> JEEB: thanks a lot!
[14:01:44 CEST] <Spring> for my purpose I'm testing 15-20 second clips of similar content, since that's what it'll be used for
[14:02:00 CEST] <JEEB> ok
[14:02:03 CEST] <Spring> and comparing encoding times, quality and filesize
[14:12:03 CEST] <iive> ozette: that command tries to make snapshots at different possitions in the file.
[14:12:31 CEST] <iive> the movie seems to be standard yuv420p
[14:19:35 CEST] <ozette> iive: true, it does try that
[14:20:02 CEST] <iive> ozette: could you try a simpler case e.g. `ffmpeg -i file.mp4 -vframes 1 test.png` ?
[14:20:11 CEST] <ozette> will try
[14:23:41 CEST] <ozette> iive: interesting.. http://paste.debian.net/791095/
[14:23:55 CEST] <ozette> unable to find suitable output format for test.png
[14:24:17 CEST] <ozette> same result, with this simple case
[14:26:33 CEST] <iive> i have an older ffmpeg version(3.3.? git), and it works but produces this warning "[image2 @ 0x2974600] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead."
[14:27:02 CEST] <ozette> oh
[14:27:05 CEST] <iive> so it is quite likely that you've hit a regression. the evil plan still produces evil fruit.
[14:27:16 CEST] <iive> ozette: if you can, try 3.3.1 and 3.3.0
[14:27:21 CEST] <ozette> :(
[14:27:24 CEST] <ozette> yea, i will try 3.1.1
[14:27:30 CEST] <radia> try this command; ffmpeg -i input.mp4 -ss 00:00:00.00 -t 00:00:05.0 -vf scale=960:-1 -c:v libvpx-vp9 -pass 2 -qmin 0 -qmax 50 -b:v 1000K -c:a libopus -b:a 64K -vbr on -threads 1 -speed 1 -tile-columns 0 -frame-parallel 0 -auto-alt-ref 1 -lag-in-frames 25 -g 64 -aq-mode 0 -sn -f webm output.webm
[14:27:31 CEST] <ozette> my other workstations run 3.1.1
[14:27:47 CEST] <iive> try 3.3.1
[14:27:48 CEST] <ozette> and there all works well, should've figured..
[14:28:05 CEST] <ozette> alright, will do that
[14:28:25 CEST] <iive> it's better to find where it broke
[14:31:59 CEST] <ozette> radia: tried that as well, but not sure what -vbr is, it's unrecognized
[14:33:05 CEST] <iive> -vbr is tla for variable bitrate
[14:33:10 CEST] <kepstin> ozette: you built that ffmpeg with --disable-muxer=image2
[14:33:19 CEST] <kepstin> ozette: that's the muxer that makes png files :/
[14:33:33 CEST] <ozette> oh, that sounds familiar
[14:33:55 CEST] <witChdoCtOr> https://gist.github.com/LinuxwitChdoCtOr/74c1721dd7688cf1d16509ea2a52d231
[14:34:33 CEST] <witChdoCtOr> My current output is messed up
[14:34:34 CEST] <iive> ozette: try `ffmpeg -formats | grep image2`
[14:34:42 CEST] <witChdoCtOr> Output #0, mp4, to 'enc.mp4':
[14:34:43 CEST] <iive> to check if you have it.
[14:34:43 CEST] <witChdoCtOr>     Stream #0:0: Unknown: none (h264_nvenc) ([33][0][0][0] / 0x0021)
[14:34:45 CEST] <witChdoCtOr> av_dump_format enc.mp4
[14:34:46 CEST] <witChdoCtOr> [mp4 @ 0x16ebd60] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
[14:34:48 CEST] <witChdoCtOr> [mp4 @ 0x16ebd60] dimensions not set
[14:34:49 CEST] <witChdoCtOr> ERROR:avformat_write_header::
[14:34:54 CEST] <iive> witChdoCtOr: use pastebin site
[14:35:54 CEST] <witChdoCtOr> sorry new at irc
[14:35:55 CEST] <ozette> iive: http://paste.debian.net/791097/ shows two 'D's at image2 and image2pipe
[14:36:29 CEST] <ozette> already doing make clean and a configure with those two --disabled removed
[14:36:44 CEST] <iive> ozette: D is demuxer, You need to have E too
[14:36:51 CEST] <iive> e.g.
[14:37:05 CEST] <iive> DE image2          image2 sequence
[14:37:38 CEST] <ozette> aha
[14:37:47 CEST] <iive> well, I was too quick to blame the evil plan.
[14:37:48 CEST] <ozette> noted
[14:38:14 CEST] <ozette> 3.3.1 is a git release?
[14:38:39 CEST] <witChdoCtOr> http://pastebin.com/download/0cWYRr76
[14:38:41 CEST] <iive> no
[14:38:59 CEST] <iive> it is a release release
[14:39:03 CEST] <ozette> i don't see any releases after laplace
[14:39:41 CEST] <iive> ozette: i thought it is regression, but kepstin had better theory and the grep seems to confirm it.
[14:39:54 CEST] <ozette> yea, thanks kepstin :)
[14:39:55 CEST] <iive> so compile the latest release, without the --disable and it should work.
[14:40:06 CEST] Action: ozette makes notes
[14:59:18 CEST] <witChdoCtOr> why use pastebin over gist ?
[15:01:49 CEST] <kepstin> gist is fine if you want. people here use 'pastebin' as a generic term
[15:02:59 CEST] <iive> gist is ok, I thought you are going to paste some huge log, and it's recommended if there are more than couple lines to use some pastebin site.
[15:04:29 CEST] <witChdoCtOr> gotcha noob here
[15:05:28 CEST] <witChdoCtOr> but I knew not to spam here, have been in other chats before...
[15:06:05 CEST] <witChdoCtOr> did anyone look at my code?
[15:07:35 CEST] <iive> sorry, today i'm not in condition to read code :Z
[15:09:33 CEST] <witChdoCtOr> np undetand
[15:11:16 CEST] <ozette> i think i'm getting close, by dropping the disabled muxers of image2, ffmpeg formats now displays DE, but still missing png i believe: http://paste.debian.net/791107/ line 31
[15:11:34 CEST] <iive> witChdoCtOr: about the error, you might want to read some recent documentation. e.g. thing like width and height were sotred in .codec param that is the same as the one used by codecs,  It has been phased out and new structure is used.
[15:11:46 CEST] <ozette> png encoder*
[15:11:53 CEST] <witChdoCtOr> codecpar
[15:12:02 CEST] <witChdoCtOr> yea, 3.1 ABI
[15:12:14 CEST] <kepstin> ozette: you have a bunch of really weird and useless --disable and --enable options on your configure. you should probably remove most of them
[15:12:19 CEST] <iive> the codecpar. most of the time you just have to change codec to codecpar, but there are some thing different.
[15:12:20 CEST] <witChdoCtOr> notice the call avcodec_parameters_to_context
[15:12:42 CEST] <iive> the encoder still complains that codecpar is not set and that codec is used...
[15:12:51 CEST] <iive> the muxer... sorry
[15:12:52 CEST] <ozette> kepstin: true
[15:13:51 CEST] <witChdoCtOr> yea got some tips from libav-user at ffmpeg.org
[15:14:24 CEST] <witChdoCtOr> I noticed the same thing, got rid of the deprecated compile warnings, it still outputs to the log
[15:15:22 CEST] <ozette> will remove all disables except for ffserver and ffplay
[15:15:59 CEST] <shincodec> get rid of texi
[15:16:06 CEST] <shincodec> html build from configure and the suit of garbage
[15:16:20 CEST] <shincodec> thankfully deleted it and the make file didnt shite itself
[15:16:40 CEST] <shincodec> with all these changes going to claim it as mine and call it ffmpeg-thebetterhalf
[15:17:05 CEST] <shincodec> hey hey... everything is bigger in... texi
[15:17:10 CEST] <shincodec> you know like texas?
[15:18:24 CEST] <iive> ozette: yeh, good idea. probably the encoder depends on something you've disabled. I thought png uses gzip for compression. but I don't see that one disabled in your pastebin... so no idea.
[15:19:28 CEST] <ozette> iive: there was a disable bzlib, not sure if that's being used instead
[15:19:50 CEST] <ozette> i dropped it in my new config
[15:20:01 CEST] <shincodec> you ever set a camera stream to 20fps
[15:20:07 CEST] <shincodec> but its giving you 17-18 really?
[15:20:31 CEST] <iive> ozette: png should depend/select just zlib
[15:20:51 CEST] <ozette> lmao my previous config even said --disable-bzlib twice
[15:21:01 CEST] <ozette> so bad
[15:21:02 CEST] <iive> ozette: yeh... just to be sure :D
[15:21:09 CEST] <ozette> :p
[15:25:24 CEST] <Fyr> is it possible to output rawvideo from a window into a file?
[15:25:32 CEST] <shincodec> i had enable-pic twice
[15:25:36 CEST] <shincodec> one at beginning and end
[15:25:50 CEST] <shincodec> its all good in the blob of configure though
[15:28:08 CEST] <witChdoCtOr> ffmpeg -f x11grab -r 60 -video_size 1024x768 -i :0.3 -c:v rawvideo -pix_fmt yuv420p output.avi
[15:28:26 CEST] <witChdoCtOr> Fyr
[15:28:43 CEST] <Fyr> thanks
[15:29:02 CEST] <Fyr> witChdoCtOr, is it possible to do the same on Win7?
[15:29:17 CEST] <Fyr> it's a win program.
[15:29:20 CEST] <witChdoCtOr> yes but its not x11grab
[15:29:42 CEST] <Fyr> it shows a text so fast that I can't catch it.
[15:29:51 CEST] <witChdoCtOr> think it does directX something
[15:31:45 CEST] <witChdoCtOr> do ffmpeg -devices
[15:32:42 CEST] <Fyr> thanks
[15:32:53 CEST] <Fyr> funny, that I have a caca device.
[15:33:04 CEST] <witChdoCtOr> Not a windows guy but see this https://ffmpeg.org/ffmpeg-devices.html dgigrab
[15:33:46 CEST] <witChdoCtOr> YMMV
[15:34:13 CEST] <VamoMenem> im experimenting issues whit h264_nvenc and android devices. like baseline lvl 3.1 is not working good on h264_nvenc
[15:34:33 CEST] <witChdoCtOr> can't you redirect stdout on windows?
[15:34:47 CEST] <witChdoCtOr> How do you mean "not working good"?
[15:35:26 CEST] <VamoMenem> video in android devices hangs and freezez
[15:35:49 CEST] <witChdoCtOr> encoding?
[15:36:50 CEST] <VamoMenem>  -vcodec h264_nvenc  -b:v 300k -g 25  -preset hq  -profile:v baseline -level:v  3.1
[15:37:32 CEST] <VamoMenem> i tested injecting params by myself based on stacksoverflow ask about ffmpeg and android compatibility but no success
[15:37:32 CEST] <DHE> what about the audio? you may need to use a specific codec or settings, like AAC stereo only
[15:38:03 CEST] <ozette> well.. this still has the 'encoder (codec png) not found for output stream' 'error configuring complex filters', should i explicitly --enable-encoder=png?
[15:38:06 CEST] <DHE> I've seen android players (3rd party) have a fit with any other audio settings (within my own constraints)
[15:38:09 CEST] <VamoMenem> yes, audio its ok -acodec  libfdk_aac   -ar 48000 -b:a 64k
[15:38:12 CEST] <ozette> this build'
[15:38:49 CEST] <VamoMenem> yes, happened yed to me when use libx264 in the past. now when change to nvenc the firts thing i do is check audio codec
[15:39:46 CEST] <witChdoCtOr> -pix_fmt yuv420p ???
[15:40:16 CEST] <witChdoCtOr> I can't get nvenc without the pix_fmt
[15:41:50 CEST] <VamoMenem> i just do a resize before, -vf "hwupload_cuda,scale_npp=w=480:h=270:format=same:interp_algo=linear" \
[15:42:16 CEST] <witChdoCtOr> 300K seems small for gop=25
[15:42:37 CEST] <witChdoCtOr> ahh small screen! lol
[15:42:52 CEST] <VamoMenem> yes!! :D
[15:43:15 CEST] <VamoMenem> i think because of the resize i can start whitout pix_fmt i put it now to check
[15:43:22 CEST] <witChdoCtOr> it did not perform for me at baseline so I always use -profile:v high
[15:43:27 CEST] <BtbN> pix_fmt is CUDA anyway
[15:44:01 CEST] <BtbN> And nvenc only support YUV420, so if it doesn't fail entirely, you're good on that end.
[15:45:28 CEST] <witChdoCtOr> ^^^ that is what I meant...<>
[15:46:16 CEST] <witChdoCtOr> anyone know how to setup a raw stream with the new 3.1 ABI?
[15:46:29 CEST] <witChdoCtOr> https://gist.github.com/LinuxwitChdoCtOr/74c1721dd7688cf1d16509ea2a52d231
[15:48:06 CEST] <VamoMenem> yes, i checked right now and get an format error if use  -pix_fmt yuv420p
[15:48:32 CEST] <VamoMenem> i dont know what happend , this cfg worked good for android in libx264
[15:48:47 CEST] <VamoMenem> but if i use h264_nvenc nope
[15:51:08 CEST] <witChdoCtOr> what gpu?
[15:51:38 CEST] <witChdoCtOr> by hang you mean the video stops? but the encode is still running?
[15:51:46 CEST] <VamoMenem> is a quadro m4000
[15:51:55 CEST] <nonex86> nv12 == yuv420p?
[15:52:04 CEST] <nonex86> because cuvid support only nv12 ;)
[15:52:19 CEST] <VamoMenem> works fine in ios or pc, but in android phones image hangs, freeze or jump
[15:52:27 CEST] <VamoMenem> and chunks waits to start
[15:53:24 CEST] <VamoMenem>  nv12 == yuv420p ?
[15:53:29 CEST] <witChdoCtOr> not really
[15:53:43 CEST] <witChdoCtOr> but nvenc should support both
[15:53:44 CEST] <JEEB> same data in different way
[15:53:56 CEST] <JEEB> nv12 is half-packed, yuv420p is fully planar
[15:54:01 CEST] <witChdoCtOr> same but different
[15:54:12 CEST] <Spring> this is nuts
[15:54:13 CEST] <witChdoCtOr> get all technical there...
[15:54:42 CEST] <JEEB> basically GPU vendors started liking having the chroma in a single buffer packed together (CbCrCbCr...)
[15:54:51 CEST] <nonex86> than yuv420p is wrong, at least on current cuvid implementation i used nv12 as output surface
[15:55:04 CEST] <VamoMenem> i should test using format=nv12 instead yov420p?
[15:56:12 CEST] <BtbN> There is no cuvid involved in that command, nonex86.
[15:56:13 CEST] <nonex86> cant say anything related ffmpeg interop, i just write my own decoding codepath using cuvid and i used nv12
[15:56:14 CEST] <witChdoCtOr> if you have the wrong format nvenc will fail with error
[15:56:27 CEST] <BtbN> And cuvid is a decoder anyway, so it just outputs nv12, and nothing else.
[15:57:36 CEST] <witChdoCtOr> nvenc does not decode AFAIK
[15:57:36 CEST] <Spring> *_* no wonder my outputs were different one of my conditional functions wasn't written correctly
[15:57:41 CEST] <Spring> GAWD
[15:57:48 CEST] <BtbN> nvenc is not cuvid.
[15:57:49 CEST] <Spring> (don't mind me)
[15:57:53 CEST] <VamoMenem> i use, and in production right now,  ffmpeg            -c:v h264_cuvid  -i udp://239.255.2.1:5004/         -vf "hwupload_cuda,scale_npp=w=480:h=270:format=same:interp_algo=linear"   -acodec  libfdk_aac   -ar 48000 -b:a 64k    -vcodec h264_nvenc -pix_fmt nv12 -b:v 300k -g 25  -preset hq  -profile:v baseline -level:v  3.1
[15:58:06 CEST] <BtbN> h264_cuvid does not exist.
[15:58:08 CEST] <VamoMenem> i use 3 cuda process
[15:58:15 CEST] <JEEB> Spring: sounds like the usual story :P all software sucks, but at least in some cases your stuff might work
[15:58:19 CEST] <VamoMenem> really 1 in nvidia smi but all cuda
[15:58:24 CEST] <BtbN> It's just a decoder
[15:58:24 CEST] <nonex86> i just doubt they will use yuv420 in one case and nv12 in other...
[15:58:32 CEST] <VamoMenem> coder, rezise and encoder
[15:58:34 CEST] <BtbN> nvenc supports both just fine.
[15:58:35 CEST] <nonex86> thats all i try to say :P :)
[15:58:54 CEST] <witChdoCtOr> nod @ JEEB kinda works is ok too sometimes
[15:58:56 CEST] <VamoMenem> only 20% of thread usage, is nice
[15:59:08 CEST] <BtbN> Also, why are you using hwupload_cuda, when you are aparently decoding with cuvid?
[15:59:15 CEST] <BtbN> that's a pointless roundtrip to the RAM
[15:59:31 CEST] <VamoMenem> yes, i decode whit h264_cuvid
[15:59:33 CEST] <witChdoCtOr> if it is working don't fix it!
[15:59:38 CEST] <BtbN> so it downloads from vram, just to upload it again
[16:00:02 CEST] <VamoMenem> i test whitout hwupload_cuda
[16:00:08 CEST] <witChdoCtOr> lol its a traveling ram ...
[16:00:14 CEST] <VamoMenem> wait a sec
[16:00:28 CEST] <BtbN> You have to add hwaccel cuda for a pure hw-chain to work.
[16:02:04 CEST] <VamoMenem> if i dont use hwupload i get Impossible to convert between the formats supported by the filter 'graph 0
[16:02:22 CEST] <BtbN> You have to add hwaccel cuda for a pure hw-chain to work.
[16:04:12 CEST] <VamoMenem> checking
[16:05:02 CEST] <VamoMenem> Option hwaccel (use HW accelerated decoding) cannot be applied to output file h264_cuvid
[16:06:24 CEST] <witChdoCtOr> does that do much with decoding?
[16:06:30 CEST] <witChdoCtOr> hwaccel?
[16:07:20 CEST] <BtbN> VamoMenem, you messed something up if it thinks h264_cuvid is your output file.
[16:07:57 CEST] <BtbN> witChdoCtOr, it decodes on the hardware.
[16:08:02 CEST] <ozette> even with --enable-encoders still the png encoder error: http://paste.debian.net/791113/ i'm lost, not sure what i'm missing
[16:08:57 CEST] <bencoh> ozette: ffmpeg -codecs|grep png, and check your configure output
[16:09:10 CEST] <VamoMenem> BtbN when i start whit ffmpeg     -hwaccel i got that error
[16:09:32 CEST] <BtbN> you messed up some options then, like, putting in after -i or something like that.
[16:09:59 CEST] <VamoMenem> this is the input ffmpeg     -hwaccel        -c:v h264_cuvid  -i udp://239.255.2.1:5004/
[16:10:06 CEST] <BtbN> you forgot the cuda part...
[16:10:14 CEST] <BtbN> so -c:v is the paramter you pass to hwaccel
[16:11:00 CEST] <VamoMenem> must be ffmpeg             -c:v h264_cuvid  -i udp://239.255.2.1:5004/ -hwaccel ?
[16:11:06 CEST] <BtbN> ...
[16:11:08 CEST] <BtbN> hwaccel cuda!
[16:11:42 CEST] <VamoMenem> this is working
[16:11:44 CEST] <VamoMenem>  -c:v h264_cuvid   -i udp://239.255.2.1:5004/ \
[16:12:10 CEST] <VamoMenem> -vf "hwupload_cuda,scale_npp=w=480:h=270:format=same:interp_algo=linear" \
[16:12:12 CEST] <witChdoCtOr> [mp4 @ 0x12e9d60] Tag [33][0][0][0]/0x00000021 incompatible with output codec id '0' ([0][0][0][0])
[16:12:26 CEST] <ozette> bencoh: what does ..V..S signify?
[16:12:28 CEST] <ozette> http://paste.debian.net/791114/
[16:12:30 CEST] <VamoMenem> -vcodec h264_nvenc -b:v 300k -g 25  -preset hq  -profile:v baseline -level:v  3.1
[16:12:45 CEST] <BtbN> I don't get what's so complicated about adding -hwaccel cuda, and getting rid of the then unneeded re-uploader
[16:12:47 CEST] <VamoMenem> but in android videos dont work well
[16:12:58 CEST] <VamoMenem> haaa okok
[16:13:19 CEST] <BtbN> It won't change anything about the result video though, just make the whole process more efficient.
[16:13:21 CEST] <Fyr> hey, durandal_1707.
[16:13:35 CEST] <Fyr> how's it going with ffmpeg-mt?
[16:13:38 CEST] <VamoMenem> i undestand, i have to put ffmpeg             -c:v h264_cuvid  -i udp://239.255.2.1:5004/ -hwaccel cuda
[16:13:53 CEST] <hexhaxtr1n> Hi! I downloaded a movie that is 3.22GiB of size. I want to use ffmpeg on it for about 15 hours. It doesn't matter what it does. It just needs to use lots of resources and last about 15 hours. How can I do this?
[16:13:56 CEST] <BtbN> Android probably just doesn't support some h264 feature nvenc uses.
[16:14:02 CEST] <VamoMenem> and later dont use hwupload_cuda
[16:14:15 CEST] <VamoMenem> im right BtbN?
[16:14:18 CEST] <bencoh> ozette: remove the grep and you'll see :)
[16:14:28 CEST] <BtbN> I'd put it first, but I'm not sure if it matters.
[16:14:33 CEST] <witChdoCtOr> spam
[16:14:37 CEST] <Fyr> hexhaxtr1n, is it a porn?
[16:14:46 CEST] <hexhaxtr1n> Fyr: it's Warcraft.
[16:14:52 CEST] <Fyr> ='(
[16:14:54 CEST] <VamoMenem> ok i check in the two ways
[16:14:56 CEST] <witChdoCtOr> sorry, ffmpeg -h without grep is spam
[16:15:05 CEST] <ozette> bencoh: i see, so the E is missing
[16:15:19 CEST] <ozette> i wonder why though
[16:16:19 CEST] <nonex86> lok'tar ogar
[16:16:48 CEST] <hexhaxtr1n> Anyone?
[16:17:34 CEST] <bencoh> ozette: config.log :)
[16:17:56 CEST] <witChdoCtOr> play at 1 fps
[16:18:14 CEST] <VamoMenem> BtbN nice! now i use 10% of trhead
[16:18:42 CEST] <witChdoCtOr> what does 10% of thread mean?
[16:18:59 CEST] <VamoMenem> youre fine  -hwaccel cuvid  go first
[16:19:17 CEST] <VamoMenem> in a six core amd, ffmpeg is using 10% of one core
[16:19:19 CEST] <VamoMenem> of cpu
[16:19:47 CEST] <witChdoCtOr> gotcha ... small screen size
[16:19:59 CEST] <VamoMenem> whitout -hwaccel cuvid uses 20% and whitout a nvenc 80%
[16:20:10 CEST] <witChdoCtOr> I use 60% of a core at 1920x1200
[16:21:02 CEST] <VamoMenem> you resize the input whit scale_npp?
[16:22:09 CEST] <witChdoCtOr> no scaling just x11 to h.264 capture the entire desktop
[16:22:34 CEST] <witChdoCtOr> I was streaming it udp/ts to vlc on another computer
[16:22:39 CEST] <witChdoCtOr> ws kinda cool
[16:22:44 CEST] <VamoMenem> i do this -c:v h264_cuvid  -i to decode first
[16:23:05 CEST] <VamoMenem> to less cpu usage when decode the source
[16:23:12 CEST] <witChdoCtOr> dont think I have h264_cuvid
[16:23:31 CEST] <VamoMenem> ffmpeg -decoders | grep cuvid
[16:23:48 CEST] <BtbN> you need to compile a non-free version with cuda support yourself.
[16:23:59 CEST] <ozette> bencoh: it lists a pnc_encoder and apnc_encoder, anything else i should look for?
[16:24:15 CEST] <VamoMenem> is not too hard to do
[16:26:03 CEST] <bencoh> png?
[16:26:22 CEST] <VamoMenem> just install nvidia drivers, copy nvidia sdk Samples/common/inc headers and install cuda utils
[16:26:44 CEST] <VamoMenem> then compile whit  --enable-nvenc \
[16:26:45 CEST] <VamoMenem>   --enable-cuda \
[16:26:45 CEST] <VamoMenem>   --enable-libnpp \
[16:26:45 CEST] <VamoMenem>   --enable-nonfree
[16:27:03 CEST] <witChdoCtOr> Its already rendered on the screen so why render again
[16:27:03 CEST] <witChdoCtOr> gotcha nope can't use non-free or gpl
[16:27:03 CEST] <witChdoCtOr> until I have my own encoding code working x11grab is working ok
[16:27:04 CEST] <VamoMenem> c_14 helps me last night
[16:27:09 CEST] <VamoMenem> :)
[16:28:25 CEST] <VamoMenem> i think, exist a way to check the profile and leves in detail to compare using ffprobe?
[16:29:16 CEST] <witChdoCtOr> where should I be setting the codec is in the AVStream?
[16:29:26 CEST] <ozette> looked for anything png related
[16:29:28 CEST] <witChdoCtOr> err codec id
[16:29:28 CEST] <VamoMenem> i want to compare h264_nvenc and libx264 to check why android isnt compatible whit h264_nvenc
[16:30:49 CEST] <sfan5> VamoMenem: mediainfo can tell your the h264 profile & level
[16:31:34 CEST] <VamoMenem> and more detailed stuff like ibp frames?
[16:31:54 CEST] <VamoMenem> i think h264_nvenc is doing somthing wrong in baselevel
[16:31:57 CEST] <witChdoCtOr> is there a shortcut to getting screen names into this edit window
[16:32:06 CEST] <sfan5> no idea whether it does that
[16:32:16 CEST] <VamoMenem> i will check
[16:32:47 CEST] <witChdoCtOr> think I am getting close
[16:32:50 CEST] <witChdoCtOr> Stream #0:0: Video: none (h264_nvenc) ([33][0][0][0] / 0x0021), yuv420p, 1024x768, q=-1--1, 5000 kb/s, 60 tbn
[16:33:00 CEST] <witChdoCtOr> [mp4 @ 0x23b5d60] Tag [33][0][0][0]/0x00000021 incompatible with output codec id '0' ([0][0][0][0])
[16:34:30 CEST] <VamoMenem> what codec you use to decode?
[16:35:11 CEST] <witChdoCtOr> I am not creating a NEW stream output
[16:35:39 CEST] <VamoMenem> i used h264_nvenc to decode and h264_cuvid to encode, but i cant use  hevc_cuvid to decode and h264_cuvid to encode
[16:35:43 CEST] <VamoMenem> i dont not know why
[16:38:30 CEST] <ozette> how to enable the png encoder?
[16:42:44 CEST] <BtbN> VamoMenem, cuvid is decoder-only.
[16:42:47 CEST] <BtbN> nvenc is encoder only.
[16:42:58 CEST] <BtbN> And hevc only works on maxwell.
[16:43:02 CEST] <BtbN> or Pascal, obviously.
[16:43:28 CEST] <durandal_1707> ozette: install zlib?
[16:44:02 CEST] <witChdoCtOr> his M4000 is maxell
[16:44:12 CEST] <witChdoCtOr> same gpu I am using
[16:44:17 CEST] <BtbN> Which generation?
[16:44:23 CEST] <witChdoCtOr> first
[16:44:27 CEST] <witChdoCtOr> 107
[16:44:33 CEST] <witChdoCtOr> GM107 I think
[16:44:42 CEST] <BtbN> So that only supports hevc encoding then, no decoding.
[16:44:55 CEST] <witChdoCtOr> I think that is correct
[16:45:07 CEST] <witChdoCtOr> I am not using hevc so unsure
[16:45:28 CEST] <witChdoCtOr> wiki has a chart
[16:46:14 CEST] <witChdoCtOr> but I was pretty sure ffmpeg will barf if you request an unsupported encode/decode
[16:46:57 CEST] <witChdoCtOr> does the generation matter for performance?
[16:47:05 CEST] <nonex86> btw, hevc on maxwell/pascal is decoder only or encoder too?
[16:47:20 CEST] <witChdoCtOr> I know I can only encode two streams with 1st gen
[16:47:25 CEST] <BtbN> it supported encoding it before it supported decoding...
[16:47:28 CEST] <BtbN> for... reasons.
[16:47:48 CEST] <BtbN> So there are cards, like the GTX980 or 970, that can encode HEVC, but can't decode it.
[16:48:13 CEST] <witChdoCtOr> I have a 970 on my windows box and I thought it did both
[16:48:17 CEST] <nonex86> yeah, remembered something like that, thats why i asked, really strange
[16:48:19 CEST] <BtbN> No, encode-only.
[16:48:38 CEST] <nonex86> and what about 10x0? decoding too?
[16:48:48 CEST] <BtbN> Why would they use older silicon?
[16:48:59 CEST] <BtbN> The 950 and 960 support decoding just fine, because they are newer.
[16:50:22 CEST] <witChdoCtOr> nvidia uggg same chip on different cards does different things because of firmware and driver
[16:50:29 CEST] <ozette> durandal_1707: i have a zlib already installed, version 1.2.8
[16:50:52 CEST] <BtbN> no idea what you're talking about.
[16:50:57 CEST] <BtbN> They obviously don't use the same chip.
[16:51:04 CEST] <BtbN> Otherwise it would work everywhere.
[16:51:09 CEST] <witChdoCtOr> my 760 Ti ~$100 works the same as having (2) K620 ~$300
[16:51:24 CEST] <witChdoCtOr> No not the 970 that is a different chip
[16:51:24 CEST] <BtbN> The 980 and 970 just were released first. And the decoder chip wasn't done. So it's not on there.
[16:51:41 CEST] <witChdoCtOr> but the M4000 K620 and 750 Ti all have the same gpu
[16:52:54 CEST] <witChdoCtOr> s/b 4000M  oops
[16:53:10 CEST] <witChdoCtOr> not the Quadro M4000 which is newer gpu
[16:56:36 CEST] <ozette> included --enable-parser=png, but honestly, i don't know if it will help anything
[16:57:18 CEST] <ozette> ive been bringing over ffmpeg builds to my workstation for about 5 hours.
[16:58:05 CEST] <ozette> x)
[17:01:13 CEST] <bencoh> at least it takes a minute or so to build .... not 1h like back in the days on my powerpc laptop :)
[17:01:36 CEST] <ozette> hahah
[17:02:24 CEST] <ozette> imagine the amount of times i build ffmpeg
[17:54:53 CEST] <ozette> i give up, don't know how to enable png, still only ..V..S supported to PNG and APNG
[17:56:25 CEST] <nonex86> pity olimpic games doesnt have discipline like building ffmpeg, you take gold for sure :)
[17:58:47 CEST] <ozette> lol, but i gave up
[18:03:17 CEST] <bencoh> ozette: afaict ffmpeg should have builtin png encoding support, so that's pretty weird
[18:03:24 CEST] <bencoh> (see libavcodec/pngenc.c)
[18:07:31 CEST] <ozette> i see, it's there yes
[18:10:44 CEST] <ozette> even so, these config options don't seem to do the trick: http://paste.debian.net/791145/ .. so maybe i DO need to try another version of ffmpeg instead of laplace
[18:11:13 CEST] <ozette> but first.. i need a few minutes to catch my breathe and accept this defeat
[18:13:01 CEST] <jkqxz> Are you missing zlib?  png support depends on it.
[18:13:33 CEST] <ozette> well.. i have zlib 1.2.8 installed on the building system
[18:14:10 CEST] <jkqxz> But that's a cross build.  Is zlib in the sysroot you are using or otherwise accessible to the cross compiler?
[18:15:09 CEST] <ozette> hmm good point
[18:15:45 CEST] <ozette> i don't have a zlib for the target architecture
[18:16:33 CEST] <ozette> so..
[18:16:48 CEST] <ozette> hm weird, i do have zlib-devel though
[18:17:43 CEST] <ozette> not sure if the cross compiler can access zlib, no errors during build
[18:18:38 CEST] <DHE> it would need a libz library to link against for the cross target, whether static or dynamic
[18:24:23 CEST] <ozette> i have both zlib and zlib-devel, including libz.so.1
[18:24:52 CEST] <jkqxz> Inside the sysroot?
[18:26:02 CEST] <jkqxz> configure should detect it automatically - look for CONFIG_ZLIB in the generated config.h.
[18:30:07 CEST] <ozette> jkqxz: CONFIG_ZLIB is defined 0
[18:31:17 CEST] <ozette> and there's no libz.so.1 in the sysroot of the cross compiler
[18:33:18 CEST] <ozette> libutil.so.1 is the last one in the list
[18:33:50 CEST] <ozette> so.. the person who made this toolchain did not add zlib, correct?
[18:34:21 CEST] <DHE> presumably. or there's a special method to include additional libraries
[18:34:29 CEST] <DHE> zlib is common enough that it's surprising to not be available
[18:34:36 CEST] <ozette> would it be OK if i copied my own libz.so.1 to this syroot?
[18:35:23 CEST] <DHE> no
[18:35:25 CEST] <ozette> or would i need to find a zlib for the target arch
[18:35:28 CEST] <ozette> i see
[18:35:30 CEST] <jkqxz> That's not a toolchain feature, though, so if it's just a toolchain then you wouldn't expect it.  (You would if it's meant to be a whole usable sysroot with all normal libraries, such as a distributon install.)
[18:36:07 CEST] <DHE> you should be able to build zlib as a cross-compiler target and install into the sysroot for immediate use
[18:36:28 CEST] <DHE> just be careful you don't accidentally do something like overwrite your host zlib with the cross target version
[18:36:39 CEST] <ozette> lol yea.. that would be funny
[18:37:23 CEST] <ozette> alright, i will try to build zlib with this toolchain then
[19:07:15 CEST] <witChdoCtOr> happy dance!@@!
[19:07:41 CEST] <witChdoCtOr> I can not start a raw stream using the 3.1 ABI
[19:07:46 CEST] <witChdoCtOr> now
[19:08:09 CEST] <witChdoCtOr> trick is    avcodec_parameters_from_context
[19:13:06 CEST] <shincodec> jpeg decoder still jpeg camera
[19:13:15 CEST] <shincodec> which junk do i turn on after -disable-all
[19:13:22 CEST] <shincodec> parser/decorder jpeg?
[19:13:30 CEST] <shincodec> does it have demuxer/muxer?
[19:22:10 CEST] <shincodec> no?
[19:31:23 CEST] <pgorley> shincodec: you can run ./configure to list the different options
[19:31:58 CEST] <pgorley> you might want to look at --list-decoders, --list-demuxers, etc
[19:43:16 CEST] <shincodec> no no
[19:43:17 CEST] <shincodec> its ok
[19:43:20 CEST] <shincodec> i found my answer
[19:43:32 CEST] <shincodec> jpeg really is mjpeg end stream
[19:43:41 CEST] <shincodec> refresh over and over and over and over again
[20:03:30 CEST] <shincodec> heheheheh
[20:03:47 CEST] <shincodec> is there a av_goget_anotherframe_after_eof
[20:26:16 CEST] <AriaDesu]> Hi. My video comes out with the wrong colors. Green and purple. Input is a series of PNGs.
[20:27:15 CEST] <AriaDesu]> ffmpeg -f image2 -i ..\NewFolder\videoplayback%03d.png -b:v 512k out.webm
[20:28:22 CEST] <TD-Linux> AriaDesu], you may want to add -pix_fmt yuv420p
[20:28:49 CEST] <AriaDesu]> I tried. Maybe I was missing the p. Lemme try again
[20:29:00 CEST] <TD-Linux> otherwise you will get a 4:4:4 webm that only firefox can play
[20:29:14 CEST] <furq> i thought it was only chrome that could play it
[20:31:22 CEST] <furq> oh i guess firefox added it a few months ago
[20:33:28 CEST] <AriaDesu]> It works now, thanks
[20:33:50 CEST] <TD-Linux> looks like chromium stable can play it too
[20:33:55 CEST] <TD-Linux> https://bugzilla.mozilla.org/show_bug.cgi?id=1215089
[20:33:57 CEST] <AriaDesu]> I needed yuva420p, it had wrong colors with yuv
[20:35:11 CEST] <furq> chrome apparently supported it as soon as it was added to libvpx
[20:35:49 CEST] <furq> which i guess is good but it would also be really dumb if it didn't
[20:36:49 CEST] <AriaDesu]> Ok, now how do I make it loop? stream_loop -1 is for the input?
[20:36:53 CEST] <furq> on which note, does firefox support yuva420p yet
[20:37:30 CEST] <AriaDesu]> Well, my video plays in Firefox and Chrome
[20:37:42 CEST] <AriaDesu]> Which I think should be yuva420p =P
[20:37:51 CEST] <furq> firefox still doesn't support alpha
[20:38:21 CEST] <AriaDesu]> There is no actual alpha in the video. But it plays
[20:39:13 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#loop
[20:39:52 CEST] <AriaDesu]> Just -loop without a number?
[20:41:25 CEST] <durandal_170> AriaDesu]: how much it is long?
[20:41:35 CEST] <AriaDesu]> 4 seconds
[20:42:01 CEST] <AriaDesu]> 101 frames
[20:42:12 CEST] <durandal_170> size?
[20:42:31 CEST] <AriaDesu]> 1mb
[20:42:58 CEST] <durandal_170> I mean video dimensions
[20:43:30 CEST] <AriaDesu]> 2048x810
[20:44:28 CEST] <durandal_170> if you have enough free memory try loop filter, otherwise try your luck with -stream_loop option
[20:44:53 CEST] <durandal_170> -loop is for input images
[20:45:02 CEST] <AriaDesu]> What is loop filter and how?
[20:46:38 CEST] <durandal_170> if you want to loop without transocding use -stream_loop
[20:48:16 CEST] <durandal_170> for loop filter, just follow docs
[20:50:37 CEST] <ozette> in config.h, should the define CONFIG_ZLIB be 1 if zlib is in the sysroot of my cross-toolchain?
[20:52:44 CEST] <JEEB> ozette: it should be listed in external libraries :P
[20:52:50 CEST] <JEEB> of the configure script's output
[20:53:02 CEST] <JEEB> and also in config.log you should find it checking for zlib
[20:53:06 CEST] <JEEB> and finding it
[20:53:29 CEST] <ozette> so.. if my config.mak says
[20:53:35 CEST] <ozette> !CONFIG_ZLIB=yes
[20:53:40 CEST] <ozette> all is well?
[20:54:10 CEST] <ozette> it's not in my config.log
[20:57:21 CEST] <radia> What do I write to tell ffmpeg to use VP8 instead of VP9?
[20:57:33 CEST] <radia>  -c:v libvpx-vp8 didnt work
[20:59:18 CEST] <JEEB> ozette: config.log most definitely has entries for zlib :P
[21:00:31 CEST] <JEEB> not necessarily the define but there are multiple checks it runs on it so searching for "zlib" in it will bring you results
[21:01:16 CEST] <ozette> well i placed the lib/ include/ and share/ of the zlib i compiled in the sysroot of the toolchain, but i'm not convinced
[21:01:30 CEST] <ozette> guess i'll just try and see
[21:01:41 CEST] <JEEB> it's not that hard, there's multiple places where FFmpeg's configure checks for zlib and it prints the result out at the end of the configure script...
[21:01:45 CEST] <TD-Linux> radia, just libvpx should work
[21:01:48 CEST] <JEEB> as in, if it's using zlib or not :P
[21:04:57 CEST] <ozette> JEEB: okay true heh, but i don't see zlib and under enabled encoders i don't see 'png'
[21:29:29 CEST] <ozette> ha ha ha :'(
[21:39:10 CEST] <ozette> i don't know..
[21:39:37 CEST] <ozette> my config.log at some point says png_encoder=yes, but i don't know what to make up from this: https://paste.fedoraproject.org/413070/14719810/
[21:39:57 CEST] <ozette> the build i just made still doesn't have png encoder enabled
[21:40:41 CEST] <ozette> zlib is in sysroot, but not sure if it's found by cross compiler, or how i can verify, because i don't see any zlib stuff after the ./configure and config.h says #define CONFIG_ZLIB 0
[21:41:02 CEST] <drv> /usr/local/arm-unknown-linux-gnueabi/bin/../lib/gcc/arm-unknown-linux-gnueabi/4.9.3/../../../../arm-unknown-linux-gnueabi/lib/libz.so: file not recognized: File format not recognized
[21:41:16 CEST] <drv> so the zlib you put in the sysroot is probably not the right architecture
[21:41:52 CEST] <ozette> whaat ..
[21:41:52 CEST] <Jnorthrup> what the fuck does "See x265 --help for a list of options."
[21:41:57 CEST] <Jnorthrup> ffmpeg -hcodec=x264 does nothing
[21:42:13 CEST] <ozette> the zlib was compiled with this exact toolchain :/
[21:42:50 CEST] <ozette> hmm
[21:43:55 CEST] <iive> Jnorthrup: i'm not familiar with this syntax
[21:45:14 CEST] <iive> Jnorthrup: it's usually ffmpeg <...> -c:v libx264 <...>
[21:45:57 CEST] <ozette> isn't line 10949 just a warning by the way?
[21:46:30 CEST] <Jnorthrup> sorry iive ffmpeg -h codec=x265 does nothing  i want to dump the options supported.  the docs mention the executable help.  i fear the docs mention the libx265 executable here...
[21:46:56 CEST] <Jnorthrup> option tokens look cribbed from x264 thankfully
[21:47:26 CEST] <iive> at least for x265, options are passed directly to the lib
[21:47:38 CEST] <ozette> i moved the libz files to $toolchain/lib/ as well as $toolchain/sysroot/lib, and this message seems to concern the first path
[21:48:06 CEST] <shincodec> hmmm
[21:48:16 CEST] <shincodec> how to reset end of file
[21:48:22 CEST] <drv> that's ffmpeg -h encoder=libx264
[21:48:24 CEST] <shincodec> without closing and opening again
[21:48:29 CEST] <drv> (or libx265)
[21:48:35 CEST] <iive> Jnorthrup: it's libx264 and probably libx265
[21:48:48 CEST] <iive> all external encoders are named lib*something*
[21:48:48 CEST] <shincodec> avformat_reset
[21:48:49 CEST] <shincodec> no?
[22:26:59 CEST] <Jnorthrup> dahnke
[00:00:00 CEST] --- Wed Aug 24 2016