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

Mon Nov 18 03:05:02 EET 2019

[00:37:30 CET] <dw1> how can i copy video and subtitles and a specific audio stream? i get an error with ffmpeg -map 0:v -map 0:s -map 0:a:$stream -i input.mkv -c:v copy -c:s copy -c:a aac output.mkv
[00:37:54 CET] <dw1> oh it comes after -i
[00:39:09 CET] <dw1> nm think i got it
[00:41:31 CET] <DHE> yeah order of options matters relative to the inputs and outputs
[00:44:28 CET] <dw1> basically want to copy all video and subtitles (if exist) and a select audio
[00:45:12 CET] <dw1> not working - it's grabbing 2 audios and no video
[00:52:43 CET] <DHE> 0:x will only grab a single stream based on automatic selection. I think you'll have to enumerate what's available and go hog with -map 0:0 -map 0:1 [...]
[00:53:02 CET] <DHE> or a similar 0:v:0 syntax
[00:56:02 CET] <dw1> think my script was messed up
[00:56:10 CET] <dw1> lemme try some more
[01:00:17 CET] <dw1> think this works ffmpeg -i input.mkv -map 0:v -map 0:s? -map 0:$astream -c:v copy -c:s copy -c:a aac output.mkv 👍
[01:12:09 CET] <FlipFlops2001> ffmpeg64: When encoding to native AAC, I notice that ffmpeg is using only 4 threads. Is the code in Lavc58.62.100 32bit, or has this been written as such for other reasons, i.e. quality?
[01:12:34 CET] <void09> any way to get ffmpeg to treat dvd .vob files as a single video so I can take screenshots at various timestamps without knowing/worrying which vob they are in ?
[01:12:40 CET] <furq> the aac encoder is singlethreaded
[01:12:43 CET] <furq> most audio encoders are
[01:13:09 CET] <furq> void09: use something like tccat
[01:14:15 CET] <void09> so ffmpeg doesn't know how to do that?
[01:15:02 CET] <void09> also I want a cross platform solution
[01:15:21 CET] <FlipFlops2001> furq: Isn't tccat a linux program?
[01:17:03 CET] <Reinhilde> sounds like it should be a unix program
[01:17:11 CET] <Reinhilde> linux is not the only thing in the world ;-P
[01:17:32 CET] <void09> I use linux, but I wanted a cross platform solution (for the noobs)
[01:18:30 CET] <FlipFlops2001> Q on HEVC encoding: Any thoughts, good or bad about the "analyze-src-pics" parameter?
[01:19:55 CET] <SpiritHorse> void09: dvdshrink on windows.  you're going to have a hard time finding a tool that is ported to both and is also worth anything
[01:20:39 CET] <furq> don't use dvd shrink
[01:20:47 CET] <furq> if you want a pgc vob use pgcdemux
[01:20:48 CET] <void09> SpiritHorse: I have my own program which I want to do that from, has to be automatic. dvdshrink is crap
[01:21:04 CET] <furq> i don't know of anything you can pipe to ffmpeg on windows though
[01:21:55 CET] <void09> I don't want to demux anything.. just take screenshots. input is a VIDEO_TS dvd folder. output is .png files at specific timestamps from the movie
[01:22:06 CET] <void09> well I guess it can be called demuxing
[01:22:25 CET] <SpiritHorse> that seems something that can be scripted with concat
[01:22:26 CET] <void09> but it has to be automatic, not interactive
[01:23:54 CET] <nicolas17> you can just concat the .vob files at the byte level and get a valid file, right?
[01:23:55 CET] <void09> I wanted to avoid writing something like.. detect largest .vob files that are from the same "chapter" or whatever they're called on dvd, make a list of them, sort them, get duration of each, and then map out a timestamp to a specific vob file and its own corresponding timestamp
[01:24:14 CET] <nicolas17> in which case the ffmpeg concat protocol will work too
[01:24:35 CET] <void09> would it know how to seek such a concat?
[01:24:42 CET] <nicolas17> I think so yeah
[01:24:45 CET] <SpiritHorse> try it and see?
[01:25:02 CET] <void09> I don't know any ffmpeg, need an example :P
[01:25:28 CET] <nicolas17> ffmpeg -ss 1:00:00 -t 5 -i "concat:VTS_01_1.VOB|VTS_01_2.VOB|VTS_01_3.VOB" foo.mp4
[01:26:16 CET] <nicolas17> don't include VTS_01_0.VOB since that's the menu
[01:26:27 CET] <furq> uh
[01:26:31 CET] <furq> that's not always true
[01:26:41 CET] <furq> oh nvm 0
[01:26:59 CET] <nicolas17> my source is wikipedia, so
[01:27:02 CET] <nicolas17> it may be wrong
[01:27:31 CET] <void09> i've seen some movies that use VTS_07_01 for the main film
[01:27:37 CET] <nicolas17> oh yeah
[01:27:40 CET] <void09> and VTS_06 05 etc for extras
[01:27:44 CET] <nicolas17> that's totally possible
[01:28:19 CET] <void09> but what's with the foo.mp4 ?
[01:28:24 CET] <nicolas17> that's the output file name
[01:28:25 CET] <void09> I don't want to remux, just take screns
[01:28:32 CET] <void09> screenshots*
[01:28:45 CET] <nicolas17> maybe you should try that anyway, to see if the concat stuff works
[01:29:26 CET] <nicolas17> and seeking
[01:29:28 CET] <nicolas17> it's just transcoding 5 seconds of video so it should be fast
[01:29:38 CET] <void09> I use -vf scale=w=trunc(if(gte(sar\,1)\,iw*sar\,iw)/ohsub)*ohsub:h=trunc(if(gte(sar\,1)\,ih\,ih/sar)/ovsub)*ovsub,setsar=1
[01:29:57 CET] <void09> somebody here figured that string for taking screenshots obeying Display aspect ratio, and storage aspect ratio
[01:32:21 CET] <nicolas17> anyway, you concat VTS_07_01 VTS_07_02 VTS_07_03 etc to get the entire Video Title Set 7, which VTS has the main film is for you to figure out :)
[02:47:15 CET] <montana> is it possible to convert hardcoded video subtitle to  text subtitle file using OCR ?
[03:55:05 CET] <Henry151> hi folks
[03:55:20 CET] <Henry151> can anyone tell me how I can check a file to see if it has any audio or not, using ffmpeg?
[03:55:37 CET] <gp> montana: That sounds like you're going to extract the frames with ffmpeg. And then use an OCR library for that part
[03:55:38 CET] <Henry151> just because the file is on a remote headless server and so i can't just open it in vlc or whatever
[03:56:31 CET] <gp> Henry151: ffmpeg -i filename gives you some info.  FFProbe gives you lots of information about the encoding and can do json output
[03:57:13 CET] <Henry151> when i play the file (it's a .mov file) through plex or jellyfin i get no audio at all, but i really expect this file to have audio
[03:57:17 CET] <Henry151> thank you gp
[03:57:55 CET] <gp> Henry151: try ffprobe -loglevel quiet -print_format json -show_streams -show_format /path/to/foo
[03:58:15 CET] <gp> the streams part will have a "codec_type" attr that says "video" or "audio"
[04:04:01 CET] <ladders> i have unencrypted DVD VOBs i am encoding to x264 mp4 for playback in a browser.  i need to burn in the DVD subtitles because the browser can't display the subtitle stream if i '-map 0:#21 -c:s copy' (for example)
[04:04:15 CET] <ladders> is there a way to do this without extracting the subs to a srt file?
[04:07:00 CET] <Henry151> https://termbin.com/853q gp does this output mean anything to you?
[04:07:20 CET] <gp> Henry151: Yea
[04:07:25 CET] <gp> Henry151: Whats the question
[04:08:08 CET] <Henry151> gp: does that look like it should have audio?
[04:08:19 CET] <gp> Henry151: Check stream with index 0 - it tells you the codec_type is "audio". The other info tells you about the particulars but you know it is AAC
[04:08:56 CET] <Henry151> ok, so it looks like it *does* have audio, so if i'm not hearing audio, it's possibly some issue with my player and not necessarily an issue with the files, i suppose.
[04:09:03 CET] <Henry151> check stream with index 0?
[04:09:11 CET] <Henry151> ok i see it
[04:09:16 CET] <gp> Henry151: "index": 0,
[04:09:33 CET] <gp> I guess I could have said the first one =)
[04:10:04 CET] <Henry151> thank you for the guidance
[04:10:12 CET] <Henry151> from a glance it looks like the file does have audio
[04:10:37 CET] <Henry151> i will try downloading it to my local machine and playing it in VLC i guess to make 110% sure that it's not a silent audio track or something
[04:11:08 CET] <gp> Henry151: Sure thing
[07:41:35 CET] <onla> can outcome suffer if I encode a 1h video from a video file recorder from hi8 camcorder with lossless ffv1 using low end pc where the speed is 0.6x ... process is like almost 2hours... vs if I do same with good PC where speed is 10x?
[07:42:05 CET] <onla> s/recorder/recorded
[08:40:52 CET] <Reinhilde> i'd use the faster pc if you can. hi8 is an analog format tho
[08:58:25 CET] <onla> yeah I mean I captured video from hi8 using ffv1 lossless. The 1h video file is some 30GB or so. Now I am post-processing it but the speed is 0.6x on my home pc
[08:59:40 CET] <onla> using x264 now and some settings my linux friend provided
[09:19:27 CET] <onla> if I encode file on linux command line with ffmpeg I wonder what's the way to do the equivalent thing on windows PC. I have few friends with good hw on win OS
[09:20:37 CET] <pink_mist> they can open CMD or powershell and get a similar commandline
[09:22:44 CET] <onla> they just need to install some ffmpeg package and the cmd/powershell will find the installation and is able to use it without a hassle?
[09:24:32 CET] <pink_mist> not really, because windows is awful
[09:24:35 CET] <onla> I have a bash script with some checks etc that I am using so I will need to work that out also
[09:25:05 CET] <pink_mist> they'll either need to manually update their %PATH% to include the place they put ffmpeg in or specify the entire path to the ffmpeg binary or cd into the directory they put it in
[09:26:04 CET] <onla> ok. Also considering bringing Live CD, but wonder if the live cd is providing ffmpeg and codecs
[10:48:46 CET] <englosh> is ffmpeg faster at converting audio than avconv? Probably, right?
[10:52:44 CET] <durandal_1707> avconv is not supported here
[10:58:01 CET] <englosh> are there more waveforms than sine, square, triangle, and sawtooth?
[16:17:03 CET] <crockwork> Alright, I want to take an episode of an anime and split it into its constituent frames.
[16:17:32 CET] <crockwork> However, this is the issue: I want its ACTUAL frames. The individual frames of animation. Is that ever going to be possible to recreate from modernly available sources of the full episode?
[16:17:44 CET] <crockwork> (By using ffmpeg or other methods)
[16:19:28 CET] <JEEB> so you want dedup?
[16:19:39 CET] <JEEB> to get rid of duplicates?
[16:21:37 CET] <crockwork> Is that really that simple?
[16:21:51 CET] <crockwork> Also, does ffmpeg make optimized jpegs?
[16:21:58 CET] <JEEB> crockwork: I mean I'm trying to figure out *what* your attempting to do
[16:22:01 CET] <JEEB> *you're
[16:22:25 CET] <JEEB> and of course deduplication will fail if there's actual filters etc applied on top of the animation
[16:22:31 CET] <crockwork> It was for a dumb idea we had elsewhere--someone I knew took every frame and was going to upload it to a server one at a time, just to do a whole "slideshow" situation while spamming pings, et cetera. All good fun.
[16:23:05 CET] <crockwork> However, I wanted to optimize their terrible process, so I wanted to use something like ffmpeg instead of their terrible "open crunchyroll and take a screenshot of the screen and save it as a FOOKING png for every 12-maybe-frames" idea.
[16:23:38 CET] <DHE> well turning a video into 1 png every 12 frames is absolutely doable
[16:23:57 CET] <JEEB> animation is usually in 1:2 or 1:3 if that is what you actually mean, and that might be doable with deduplication
[16:24:05 CET] <JEEB> (given that there are no overlays or anything else moving in the picture)
[16:24:12 CET] <JEEB> (which there often is)
[16:24:27 CET] <JEEB> also it will not count a pan as a single thing even if the panned image itself doesn't move
[16:25:53 CET] <crockwork> DHE: I'd like to turn it more into 1 actually decent jpeg that isn't 2.5 goddamned mb per image, but ensure that ffmpeg automates making a good jpeg and not necessarily "just a jpeg"
[16:27:24 CET] <JEEB> &23
[16:29:20 CET] <crockwork> What's that?
[16:31:53 CET] <JEEB> a typo of /23
[16:32:00 CET] <JEEB> (switching windows in my IRC client)
[16:33:16 CET] <crockwork> lol
[16:33:27 CET] <DHE> it happens more often than you think...
[17:07:51 CET] <gp> Can hls audio be muxed without video and segmented correct? (using -vn to omit video).  I am forcing the video keyframe placement with '-force_key_frames' but I am guessing this is going to leave my audio segmented in an incompatible way?
[17:10:48 CET] <Anderssen> Hey guys, I'm trying to get ffmpeg to work on a hardware encoder on the amd rx580, but when I enter this (just as an example):
[17:10:59 CET] <Anderssen> ffmpeg -i Untraceable.m2t -vcodec hevc_vaapi -t 60 1min.mp4
[17:11:10 CET] <Anderssen> I get this: Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0'
[17:11:48 CET] <Anderssen> On the web I've found several threads with people who have the same problem, but it was always down to some very specific thing in their long ffmpeg command with specific filters.
[17:12:15 CET] <Anderssen> What I don't understand is what I have to do at all (some conversion?) so that this works at all.
[17:12:43 CET] <JEEB> post the full log with -v verbose in there for additional verbosity
[17:12:49 CET] <JEEB> not here but ona a pastebin or so
[17:12:50 CET] <JEEB> and link here
[17:13:28 CET] <Anderssen> kk (I'm running on Suse Leap 15.1)
[17:15:25 CET] <Anderssen> pasted it here: https://pastebin.com/WwmZP1fS
[17:16:43 CET] <JEEB> yes, the vaapi encoder probably outputs hardware buffers but those have a different pixel format
[17:17:05 CET] <JEEB> to minimize RAM to VRAM copies  you might want to see if you can use vaapi for decoding as well
[17:18:13 CET] <Anderssen> how would I decode with vaapi?
[17:18:44 CET] <JEEB> -hwaccel vaapi -hwaccel_output_format vaapi or so
[17:18:47 CET] <JEEB> see https://trac.ffmpeg.org/wiki/Hardware/VAAPI
[17:20:11 CET] <JEEB> basically since there's no specific code paths for the hardware stuff (which can be different between modules) you need to manually map stuff like moving the buffer from RAM to VRAM or other way
[17:22:59 CET] <Anderssen> OK, to be honest I have no experience in moving ram to vram or so. Is there something else I can do, like converting the pixel format to a specific format that is needed by the encoder?
[17:23:52 CET] <furq> that's what -hwaccel_output_format vaapi does
[17:26:31 CET] <Anderssen> ah ok. what I got now is this: [hevc_vaapi @ 0x55e420b7e140] B frames are not supported (0x1).
[17:27:45 CET] <furq> -bf 0
[17:27:47 CET] <Anderssen> or the entire thing: https://pastebin.com/GWMe4eLr
[17:28:51 CET] <Anderssen> thanks, i've added -bf 0, and it's running now. (although I thought no bf would be standard; I always had to add -bf 2 or so to get b frames at all)
[17:29:36 CET] <JEEB> that depends 100% on the encoder
[17:29:57 CET] <furq> it kind of sucks that the rx500 series doesn't even do bframes on h264
[17:29:59 CET] <furq> i thought it did
[17:48:58 CET] <Anderssen> hm, another thing: does hevc_vaapi accept setting bitrates? when I do -vb 1000k I get an output that consists only of colorful artifacts.
[18:58:37 CET] <Xogium> hi folks :) can anyone texplain to me what this is supposed to mean ? [libmp3lame @ 0x7f739c01bd40] The encoder timebase is not set.
[18:58:44 CET] <Xogium> *anyone explain
[18:59:03 CET] <Reinhilde> is it an error or is the encode continuing despite?
[18:59:07 CET] <Xogium> error
[18:59:18 CET] <Xogium> ffmpeg goes like invalid argument
[18:59:28 CET] <JEEB> the encoder didn't get a tiem base set
[18:59:34 CET] <Xogium> hmm
[18:59:39 CET] <Reinhilde> obviously it means what it says
[18:59:41 CET] <JEEB> if (avctx->time_base.num <= 0 || avctx->time_base.den <= 0) {
[18:59:49 CET] <Reinhilde> but more importantly, what's the invocation?
[18:59:55 CET] <JEEB> so either num or denum of time base is less than zero for some reason
[19:00:17 CET] <JEEB> the command line app should generally set it in various cases
[19:00:27 CET] <JEEB> so is this your own API usage app?
[19:00:41 CET] <Xogium> yeah in this case its a third party software, and I guess they are not setting it
[19:00:49 CET] <Xogium> its liquidsoap
[19:00:55 CET] <JEEB> ok, so yea API user
[19:01:02 CET] <Reinhilde> ask the liquidsoap team
[19:01:39 CET] <JEEB> that thing's in avcodec_open2 so that will then fail  for them
[19:01:46 CET] <Xogium> what is a time base anyway ? Sorry for a probably stupid question :D
[19:02:02 CET] <JEEB> it's the measure of things per second
[19:02:14 CET] <JEEB> like for audio 44100kHz would be 1:44100
[19:02:15 CET] <Xogium> oh like samples per second ?
[19:02:18 CET] <JEEB> yea
[19:02:35 CET] <Xogium> ah, right
[19:02:39 CET] <Xogium> that makes sense
[19:02:54 CET] <JEEB> with media it can be something else than the actual "frame rate" because of various reasons
[19:03:00 CET] <JEEB> for example MPEG-TS forces 1:90000
[19:03:05 CET] <JEEB> and FLV forces 1:1000
[19:03:07 CET] <JEEB> (for the container)
[19:03:14 CET] <Xogium> ah
[19:03:25 CET] <Xogium> well makes sense ffmpeg isn't very happy then
[19:03:27 CET] <JEEB> but that's separate from encoding :)
[19:03:36 CET] <JEEB> but yea, avcodec_open2 checks if you have set the time base
[19:03:59 CET] <Xogium> maybe I can fix it& Doubt it, never coded in ocaml
[19:04:23 CET] <Xogium> that broke very recently
[19:04:30 CET] <JEEB> if you can find out where hte thing makes its AVCodecContext it should be relatively simple I'd guess
[19:04:37 CET] <JEEB> since it's not configuring that well enough
[19:04:40 CET] <Xogium> I think ffmpeg got updated, and then liquidsoap broke
[19:05:01 CET] <JEEB> I can see through git blame how old that check is
[19:05:15 CET] <JEEB> e62ff72fc1052273deb708ba715f73e5187281d4
[19:05:17 CET] <JEEB> from 2016
[19:05:24 CET] <Xogium> that's really weird
[19:05:33 CET] <Xogium> it worked not even a week ago
[19:05:42 CET] <Xogium> ah well
[19:05:44 CET] <JEEB> it's not surprising if FFmpeg packaged somewhere is older than that
[19:05:57 CET] <JEEB> but yes, that change itself is from 2016
[19:06:05 CET] <JEEB> and every release since May 2016 has had it :)
[19:06:15 CET] <Xogium> I see
[19:06:36 CET] <Xogium> ffmpeg 4.2.1 here, in any case
[19:06:50 CET] <JEEB> > There is also a divide by the time base lower in this function, which would crash when it is not set.
[19:07:02 CET] <Xogium> I will try to see where it declares avcodec, is that the right way to go ?
[19:07:03 CET] <JEEB> so there was a reason why the sanity check was added :D
[19:07:16 CET] <JEEB> Xogium: avcodec and most importantly avcodeccontext
[19:07:24 CET] <JEEB> since that is the instance of a decoder or encoder
[19:07:31 CET] <Xogium> lets see
[19:08:36 CET] <JEEB> I'm just looking at some code I have locally, and I do set the time base before opening an encoder (and some other basic things for video or audio like width/height/sample foramt)
[19:10:30 CET] <Xogium> a quick grep shows this: ./avcodec_stubs.c:  int ret = avcodec_open2(codec_context, codec, NULL);
[19:10:56 CET] <JEEB> yup
[19:11:20 CET] <Xogium> so this is the ffmpeg function
[19:11:40 CET] <JEEB> so you initialize basic values and then it calls that
[19:12:05 CET] <Xogium> right
[19:17:17 CET] <Anderssen> hey guys, sorry to bother you again: the hevc_vaapi mentioned earlier works fine with certain videos, but at certain others I seem to get a wrong colorspace in the output; or maybe it's rather due to the input. however i can't seem to figure out which other format I can use for input decoding. what I used so far is -hwaccel_output_format vaapi;
[19:17:38 CET] <Anderssen> do I have to select a particular output format at this place if i get the error Incompatible pixel format 'yuv444p10le' for codec 'hevc_vaapi', auto-selecting format 'vaapi_vld' ?
[19:17:39 CET] <JEEB> Anderssen: give a full log with -v verbose or it is hard to figure out
[19:20:43 CET] <furq> does vce even support high bit depth
[19:21:33 CET] <Anderssen> kk: https://pastebin.com/AWYrbjjH
[19:22:00 CET] <JEEB> I don't see any messages regarding yuv444p10le there
[19:22:19 CET] <Anderssen> now, that's funny, wait a sec
[19:22:31 CET] <Anderssen> however, the output still looks somewhat wrong (in terms of colors)
[19:23:12 CET] <JEEB> the input doesn't seem to signal jack, although I'm not sure if it's that or the compression artifacts :P
[19:23:23 CET] <JEEB> so for input I would guess a lot of players would show it in BT.601
[19:23:36 CET] <JEEB> while I have no idea what the AMD vaapi encoder would default to
[19:23:42 CET] <Anderssen> kk, I experimented with a filter earlier which produced that error (incompatible pixel format) in order to get a correct output; but that didn't solve it; the original line is now in the pastebin i just posted
[19:24:24 CET] <JEEB> I recommend you ffprobe -v verbose -I FILE'ing the output of that
[19:24:31 CET] <JEEB> and posting the result
[19:24:49 CET] <Xogium> JEEB: I found this, would that be the right place ? http://ix.io/225d
[19:25:33 CET] <JEEB> Xogium: it seems to set up the codec context yes, but that looks like for video since it seems to skip most things
[19:25:49 CET] <Xogium> mmmh weird
[19:26:19 CET] <JEEB> https://lists.ffmpeg.org/doxygen/trunk/structAVCodecContext.html
[19:26:34 CET] <JEEB> these are all the values that are in a lavc context
[19:26:48 CET] <Xogium> weird cause they claim it only supports audio for now
[19:27:21 CET] <Anderssen> https://pastebin.com/2z9ENyn4
[19:27:21 CET] <JEEB> of course, generally speaking you just need to set stuff like sample_fmt, time_base and such
[19:28:29 CET] <JEEB> Anderssen: that's the *input*
[19:28:34 CET] <JEEB> now what about the *output* ?
[19:28:45 CET] <Anderssen> sorry, misunderstanding
[19:29:15 CET] <Anderssen> https://pastebin.com/sx6SMLuW
[19:29:19 CET] <JEEB> thanks
[19:29:39 CET] <Xogium> JEEB: so I could just add time_base in there ?
[19:30:00 CET] <JEEB> Xogium: setting it before the codec context gets opened, yes
[19:30:11 CET] <JEEB> Anderssen: ok, so that doesn't have the color space info either
[19:30:22 CET] <JEEB> what are you utilizing to compare the color?
[19:30:52 CET] <JEEB> but anyways, as far as FFmpeg is doing things, and as far as you don't have any weird conversions in your filters (which there don't seem to be any), it looks like it's passing those things through
[19:30:54 CET] <Xogium> I've never programmed before
[19:31:09 CET] <Anderssen> you mean a tool? I only realized it when I looked at the video. it's pretty obvious to see though, I can upload a screenshot if it helps
[19:31:10 CET] <Xogium> but figure if its a matter of adding a single line that can work
[19:31:37 CET] <JEEB> Xogium: basically in C it would be lavc_ctx->time_base = (AVRational){ VALUE, ANOTHER_VALUE };
[19:31:49 CET] <JEEB> values being numbers
[19:31:54 CET] <JEEB> numerator and the denumerator
[19:32:27 CET] <JEEB> Anderssen: yes the mechanism you're using
[19:32:50 CET] <JEEB> Anderssen: and rather than screenshots actual short samples might be more useful
[19:33:03 CET] <JEEB> you can limit a sample with -t XX where XX is seconds, for example
[19:33:14 CET] <JEEB> and you can -map 0:v to just do the video stream
[19:33:21 CET] <JEEB> (and -c copy to copy the original stream)
[19:33:42 CET] <JEEB> but it can just be the hardware encoder
[19:33:59 CET] <Anderssen> should i upload it to a particular place?
[19:34:12 CET] <JEEB> anything that doesn't require insane javascript or dozen hoops to grab
[19:34:22 CET] <JEEB> 0x0.st is one place if you know how to upload a file with curl
[19:39:08 CET] <Anderssen> ok, I uploaded one 10 second sample here: http://46.38.239.196/out10s.mp4
[19:40:05 CET] <JEEB> and if you could get the same thing with the input video -c copy'd, that'd make it easier to actually compare ;)
[19:40:17 CET] <Anderssen> ok, but the input video is much larger
[19:40:37 CET] <JEEB> apparently it should only be like 2x that?
[19:40:52 CET] <JEEB> since the source average bit rate over probed area was 3500kbps
[19:40:57 CET] <JEEB> and the output was 1800kbps or so?
[19:41:02 CET] <JEEB> *1800
[19:41:05 CET] <Anderssen> or wait, it's like 3M
[19:41:13 CET] <Xogium> JEEB: I guess I can modify the avcodec_stub.c file, but its the values I'm not sure about
[19:42:38 CET] <Anderssen> http://46.38.239.196/out10s.mp4
[19:42:45 CET] <JEEB> Xogium: the application seems to have a logic most likely
[19:43:01 CET] <Xogium> yeah
[19:43:04 CET] <JEEB> Anderssen: seems to be the same?
[19:43:34 CET] <JEEB> yup that is the same URL and also contains HEVC
[19:43:46 CET] <Anderssen> woops
[19:43:51 CET] <Anderssen> here: http://46.38.239.196/out10s.mp4
[19:43:56 CET] <Anderssen> hey
[19:44:01 CET] <Anderssen> my copy paste thing doesnt work, wiat
[19:44:20 CET] <Anderssen> http://46.38.239.196/input10s.m2t
[19:46:24 CET] <JEEB> Anderssen: colors seem to be the same but either the hardware decoder or encoder has really derped it up
[19:46:34 CET] <JEEB> so you get "nice" chroma artifacts
[19:46:42 CET] <JEEB> welcome to the wonderful world of "where did it all go wrong"
[19:46:48 CET] <Anderssen> ok, so it's visible?
[19:47:01 CET] <Anderssen> i mean it's like horizontal bars or something
[19:47:04 CET] <JEEB> like if I do `mpv --pause FILE` next to each other, I can clearly see it yes
[19:48:05 CET] <JEEB> also I guess the input you have is interlaced so that might be doing something as well
[19:48:22 CET] <JEEB> so you might want to see if the hardware deinterlacer does anything nice to you
[19:48:51 CET] <Anderssen> I'm not sure if the frames are marked as interlaced, but I don't see any interlace artifacts at all
[19:49:20 CET] <JEEB> only reason for me to note that were some interlacing-related flags in there
[19:49:24 CET] <JEEB> but yea, dunno
[19:49:36 CET] <JEEB> I'd probably test with some sw encoder first
[19:49:50 CET] <JEEB> if you really want HEVC, there's probably libx265 built into your FFmpeg binary?
[19:49:58 CET] <Anderssen> software encoders work fine; it looks perfectly ok with libx265
[19:50:03 CET] <JEEB> ok
[19:50:16 CET] <JEEB> have fun figuring out where the vaapi stuff is going wrong
[19:50:22 CET] <Anderssen> hehe
[19:50:34 CET] <JEEB> try the hardware decoding and then bringing it to RAM and using libx265, or vice versa
[19:50:41 CET] <JEEB> software decoding and hardware encoding
[19:50:50 CET] <JEEB> I'm going to put my initial guess on encoder, but it could be either
[19:52:05 CET] <Anderssen> I'm not sure with what to decode though; I think then I'm back at the "old" problem from 2 hours ago
[19:52:40 CET] <JEEB> you just need to add the hwupload filter then
[19:53:01 CET] <JEEB> I just guesstimated that since you want hw encoding you probably wanted the more optimal path which keeps the stuff in the VRAM
[19:53:07 CET] <JEEB> instead of moving it between VRAM and RAM
[19:53:53 CET] <Anderssen> depends on how fast it is
[19:54:21 CET] <Anderssen> main thing is just, when I encode with libx265 (I have an i7-4770), it goes to like 60-65 fps; apparently the hardware encoder is much faster
[19:54:56 CET] <Anderssen> I also have a laptop with a gtx-1050-ti; I've tried the hevc_nvenc there, it goes to like 450fps
[19:55:26 CET] <JEEB> do note that those bring completely different compression ratios since hw encoders are meant for "not using the CPU" or low latency use cases
[19:55:27 CET] <Anderssen> the hevc_vaapi I tried here goes to like 230 fps,
[19:55:36 CET] <JEEB> also you can set the -preset with libx265
[19:55:42 CET] <JEEB> if you just want to make it faster
[19:58:38 CET] <Polochon_street> Hi! Is there a simple way to display a picture on /dev/fb0 (linux framebuffer) using ffplay? I'm trying to fool around with the fbdev, but getting this to work first would be nice
[19:59:17 CET] <JEEB> no idea. the closest thing I have noticed to something like that is mpv's gpu renderer's DRM output
[20:00:38 CET] <Polochon_street> I have `ffmpeg -i pic.jpg -pix_fmt rgb565le -f fbdev /dev/fb0` kinda working, but the picture is completely fubar
[20:19:59 CET] <Anderssen> JEEB, can I ask you another question: I used that line from https://trac.ffmpeg.org/wiki/Hardware/VAAPI
[20:20:10 CET] <Anderssen> for screen capture: ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -video_size 1920x1080 -i :0 -vf 'hwupload,scale_vaapi=format=nv12' -c:v h264_vaapi -qp 24 output.mp4
[20:20:34 CET] <Anderssen> the output is fine. would that mean that the encoder is ok, but the decoder might be set up wrong?
[20:20:44 CET] <JEEB> well that's H.264 :P
[20:20:45 CET] <JEEB> not HEVC
[20:21:05 CET] <Anderssen> my bad
[20:21:37 CET] <JEEB> also /41
[20:21:50 CET] <JEEB> basically you'd have to make sure it's OK with the default sw decoder and hwupload
[20:21:56 CET] <JEEB> I mean, that part is already more or less there
[20:21:58 CET] <JEEB> in the -vf
[20:25:44 CET] <Anderssen> ok, I can't quite see a reference to a hardware decoder in that line that i could replace with something though
[20:26:21 CET] <Anderssen> i mean it doesn't have -hwaccel vaapi and -hwaccel_output_format vaapi
[20:28:02 CET] <JEEB> well yes, those tell ffmpeg.c that you want hw decoding and that you'd like its native output format :P
[20:28:12 CET] <JEEB> the default is software decoding, after all
[20:35:11 CET] <Anderssen> I'm always taking a while; it's a little tricky to experiment with all those options without typos or putting an option at the wrong place. What I now did, is this line:
[20:35:18 CET] <Anderssen> ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -video_size 1920x1080 -i :0 -vf 'hwupload,scale_vaapi=format=nv12' -c:v hevc_vaapi -qp 24 -t 10 -bf 0 output3b.mp4
[20:35:34 CET] <Anderssen> that has, as far as I can tell, produced an output with hevc (h265)
[20:36:23 CET] <JEEB> so you used the VAAPI HEVC encoder, set quantizer to 24, encoded 10 seconds and disabled b-frames
[20:36:30 CET] <Anderssen> and the colors are fine. now, I can't do this with a video input though because i get the "old" error " Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0'"
[20:36:46 CET] <JEEB> yes, because you need the hwupload and vaapi scale there :P
[20:36:59 CET] <JEEB> if you still get errors with that post the full command line and log onto a apstebin or so, and link here
[20:40:15 CET] <Anderssen> I'm not sure what to change now though; I'm trying something like ffmpeg -vaapi_device /dev/dri/renderD128 -i DieHard.m2t -vf 'hwupload,scale_vaapi=format=nv12' -c:v h264_vaapi -qp 24 -bf 0 output4.mp4
[20:40:52 CET] <JEEB> now post the other part of that
[20:41:21 CET] <Anderssen> ffmpeg tells me this then: https://pastebin.com/FHPxuSVK
[20:41:46 CET] <JEEB> alright, then the scale_vaapi might have been unnecessary
[20:42:00 CET] <JEEB> try -vf "scale=format=nv12,hwupload"
[20:42:12 CET] <JEEB> which converts on the RAM side to nv12, and then uploads it
[20:42:33 CET] <JEEB> although in theory the video recording example should be similar
[20:43:02 CET] <JEEB> or maybe scale filter just used a format meta filter
[20:43:03 CET] <Anderssen> i think i have too many terminals open; i got an old version of that line again, with h264_vaapi instead of hevc
[20:43:05 CET] <JEEB> I don't remember :P
[20:43:34 CET] <JEEB> that shouldn't really matter, both VAAPI encoders should be doing similar results. and at least you posted the command and log together
[20:44:49 CET] <JEEB> ok yes, you need the meta one with the standard filters
[20:44:54 CET] <Anderssen> ok, this is what I got now: https://pastebin.com/dagScVd4
[20:45:12 CET] <JEEB> -vf "scale,format=pix_fmts=nv12,hwupload"
[20:45:15 CET] <JEEB> that should be it :P
[20:45:21 CET] <JEEB> since format is not a valid option for the scale filter
[20:45:25 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#scale-1
[20:45:29 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#format-1
[20:45:39 CET] <JEEB> (related documentation, also useful to ctrl+F through)
[20:46:43 CET] <Anderssen> wow, that produces a good output
[20:47:41 CET] <Anderssen> however, what now, was it the hw decoder then?
[20:48:50 CET] <JEEB> not necessarily but if you used exactly the same parameters for the encoder (-qp -bf etc) then maybe
[20:49:00 CET] <JEEB> at least switching to sw decoding seems to have helped :P
[20:50:02 CET] <Anderssen> yes!
[20:50:06 CET] <Anderssen> thanks, you did so much.
[20:50:26 CET] <Xogium> JEEB: thanks a ton :)
[21:08:52 CET] <Anderssen> different topic: I've been looking for a deinterlacing filter that simply discards one of the fields; the only filter in https://ffmpeg.org/ffmpeg-filters.html that I found though is "nnedi" (section 11.134), it requires an an external .bin and is pretty slow. is there maybe an alternative?
[21:09:00 CET] <Anderssen> (i mean for a filter that discards one field)
[21:13:47 CET] <gp> Does VBR audio benefit from 2 pass encoding?
[21:13:55 CET] <gp> or is that video only improvements?
[21:14:22 CET] <JEEB> if audio was encoded in longer fragments possibly
[21:14:37 CET] <JEEB> but right now it's usually each packet being completely separate
[21:14:52 CET] <JEEB> so you have to keep the rate within that buffer and blah blah
[21:15:09 CET] <gp> kk =) ty
[21:15:17 CET] <c_14> Anderssen: use the field filter?
[21:21:12 CET] <Anderssen> c_14: I'm not sure if I'm doing something wrong, but if I use vf=field=top, it seems to not switch to top field but it takes the upper half of the image and crops of the restr
[21:21:51 CET] <JEEB> see the separatefields filter?
[21:22:13 CET] <JEEB> and then you can use the selectwhatever filter to only output the even or uneven ones
[21:22:36 CET] <Anderssen> or wait, that was the effect when I inserted it into that ffmpeg command which I used earlier, with the hardware encoder; if i use the software encoder it seems to work fine
[21:24:11 CET] <Anderssen> ok, i think i just have to move that filter to the front (i.e. before all other filters)
[21:25:28 CET] <Anderssen> thanks c_14, thanks again JEEB !
[22:10:36 CET] <Anderssen> erm, sorry to bother you again, but @JEEB, you stil: have the output file, right? do you recognize something with the image, like it's being somewhat scaled down and moved to the left, so that there is a black bar at the right?
[22:11:03 CET] <durandal_1707> huh?
[22:11:10 CET] <durandal_1707> what command line you use?
[22:11:21 CET] <durandal_1707> post full _uncut_ ffmpeg output
[22:11:35 CET] <furq> Anderssen: afaik every deinterlacing filter discards alternate fields unless you set them to double the framerate
[22:11:54 CET] <Anderssen> furq, that's not it, it occurs in all output files that I encoded, but I haven't realized it until now
[22:11:59 CET] <furq> yadif/bwdif do
[22:12:26 CET] <furq> that was in reference to your earlier question, idk what the black bar is about
[22:14:09 CET] <Anderssen> durandal_1707 the most recent ffmpeg line I used was this: ffmpeg -vaapi_device /dev/dri/renderD128 -i DieHard.m2t -vf "scale,format=pix_fmts=nv12,hwupload" -c:v hevc_vaapi -qp 24 -bf 0 -t 60 -y output5.mp4
[22:17:07 CET] <Anderssen> (for the record, the output was this: https://pastebin.com/W3zGhshH )
[22:18:13 CET] <Anderssen> however, the thing is, regardless which parameters I use: when I play the video with a video player I got a black bar at the right side, and some on top and some on the bottom; the image appears to have been shrunk or zoomed out; however it's not a thing with the video player, it's on all players
[22:33:39 CET] <gp> Just trying to wrap my head around something.  When you write the command and use stdin for an input file, it actually becomes the last stream in a map right?
[22:33:51 CET] <gp> Even if it is specified first?
[22:34:24 CET] <furq> ?
[22:36:02 CET] <Anderssen> As to the issue I just mentioned: I kind of getting an idea of what *might* go wrong: the input was 720x576, the output seems to be 768x576, although that has never been specified; 768x576 however is exactly 4:3 which is the standard DAR; maybe the encoder went rogue and padded the image so that this fits?
[22:36:52 CET] <furq> is it actually 768x576 or is that just how your player displays it
[22:37:20 CET] <Anderssen> when I ask ffmpeg to output a bmp-file from the video, it outputs 768x576
[22:38:00 CET] <Anderssen> yeah, and the input is shown as 768x576, too. idk why though. during encoding it says: Stream #0:0: Video: hevc (hevc_vaapi) (Main) (hev1 / 0x31766568), vaapi_vld, 720x576 [SAR 64:45 DAR 16:9], q=2-31, 25 fps, 12800 tbn, 25 tbc
[22:38:18 CET] <Anderssen> so, the output should be 720x576; but it's actually 768x576
[22:38:45 CET] <furq> yeah and it should be 16:9 anyway
[22:39:01 CET] <furq> sounds like your gpu is doing something crazy
[22:39:01 CET] <Anderssen> yeah, so if the encoder was to pad it, it should pad it to 16:9, not to 4:3
[22:49:12 CET] <Anderssen> it's only the hevc_vaapi though; the h264_vaapi doesn't do that
[23:06:53 CET] <Anderssen> ok, although i haven't figured it out: the encoder apparently doesn't pad beyond 1024 width
[23:07:51 CET] <Anderssen> below that it always pads 32 pixels on the right (though to a max width of 1024)
[00:00:00 CET] --- Mon Nov 18 2019