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

[burek]

[00:52:34 CET] <jasom> Is it possible to resize picture (DVD) subtitles?  I'm resizing the video and I'd rather not burn them in or convert to text, but I'll do that if I have to.
[00:55:11 CET] <JEEB> I'm not sure if rescaling or just leaving them as-is and hoping the players do things so that it matches is better
[00:55:37 CET] <JEEB> in theory you can get the output of the DVB/DVD/blu-ray subpictures as a video track and scale it
[00:55:49 CET] <JEEB> and then for DVB and DVD I think we have an encoder?
[00:55:56 CET] <JEEB> so in theory you could re-code it
[00:56:17 CET] <JEEB> but in practice I would probably just remux and see how players reflect the difference in size between canvas and video
[00:56:27 CET] <JEEB> ugh, *canvas and subpicture
[00:59:06 CET] <jasom> JEEB: vlc seems to scale, mpv does not
[03:14:22 CET] <dradakovic> Any clue why my FFMPEG timestamp is faster than it should be? Seconds are going too fast if i check the time played
[03:15:53 CET] <dradakovic> I can see in log file that i get cur_dts is invalid (this is harmless if it occurs once at the start per stream)
[03:15:53 CET] <dradakovic> .
[04:05:26 CET] <DHE> I request op assistance in the channel for the obvious problem
[04:46:00 CET] <CoreX> petecouture fix your shit
[05:55:47 CET] <FishPencil> Does -threads 1 disable filter slice threading
[05:58:33 CET] <furq> FishPencil: -filter_threads
[06:09:31 CET] <Dalboz989> hi - i am seeing something odd when I use stream_loop - anyone around want to take a stab at it?
[06:17:16 CET] <Dalboz989> so video is like 10 seconds long but when i add stream_loop to the same command it is takes over 3 minutes.. https://pastebin.com/PetKKzT1
[06:29:04 CET] <kazuma_> why not just cat the video stream over and over if you are not encoding
[06:30:22 CET] <Dalboz989> hrm.. do you mean like cat out.mp4 out.mp4 out.mp4 | ffmpeg -y -an -i - -c copy junk.mp4 ????
[06:33:21 CET] <furq> presumably not because that's not a thing
[06:33:54 CET] <furq> there are a bunch of different ways to do this though
[06:34:36 CET] <Dalboz989> ultimately i want infinite loop but was just testing with 3
[06:34:53 CET] <furq> oh nvm you want to stream copy
[06:35:05 CET] <furq> if you want an infinite loop then you're pretty much stuck with stream_loop
[06:36:16 CET] <Dalboz989> well if i could loop say 10 times that would probably work - any suggestion how i can do 10 times? or a suggestion on what is up with stream_loop ?
[06:36:37 CET] <furq> https://trac.ffmpeg.org/ticket/6121#comment:5
[06:36:39 CET] <furq> try that i guess
[06:40:20 CET] <Dalboz989> so change output from mp4 to mkv and you think it will work?
[06:40:28 CET] <Dalboz989> or rather the input file
[07:04:25 CET] <Dalboz989> so i converted the mp4 to mkv and tried the same thing but no difference
[09:55:32 CET] <killown> hey there :) I am trying to set watermark with this code https://bpaste.net/show/be8facee8c95 in manjaro updated works but in ubuntu 16.04 it gives error and the out.mp4 is empity
[09:55:38 CET] <killown> can anyone help me?
[09:58:57 CET] <killown> I just updated for newest ffmpeg and worked
[10:01:25 CET] <killown> is there someway to add watermark only in the first 2 minutes of the video?
[10:14:03 CET] <killown> overlay=enable='lte(t,30)' doesnt work [libvorbis @ 0x55e7d725fc00] 39 frames left in the queue on closing
[10:18:58 CET] <durandal_1707> 2 minutes have 120 seconds
[10:42:47 CET] <killown> ok
[10:43:03 CET] <killown> can you help me create a watermark with text transparency?
[12:51:50 CET] <wasperen> hi all
[12:52:07 CET] <wasperen> hopefully someone here can help me...
[12:52:27 CET] <wasperen> I am building ffmpeg with support for zvbi_teletext
[12:52:54 CET] <wasperen> I am building version 3.4.1 with the --enable7libzvbi flag
[12:53:36 CET] <wasperen> it compiles ok but the dvb_teletext decoder / encoder is not included in the list of codecs...
[12:55:12 CET] <wasperen> I have trawled the internet but to no avail...
[12:55:29 CET] <hojuruku> ffmpeg h264_vaapi assumes vaapi can do high profile. AMD Polaris GPU's don't do b-frames so we need to be able to tweak / patch ffmpeg to use base profile etc
[12:56:18 CET] <hojuruku> i think openmax at least works a little better, i'll do some tests now
[12:56:33 CET] <JEEB> wasperen: 1) does it pop up in your configure output? 2) are you sure you are testing with the thing that you actually built?
[12:57:01 CET] <hojuruku> i mean gst-openmax. ffmpeg openmax stable doesn't support libomxil-bellago yet right?
[12:59:38 CET] <JEEB> hojuruku: no need to patch the vaapi h264 encoder to set the profile (although I'm not sure if it does more than just the flag in the headers) - see the AVOptions defined for the encoder
[12:59:44 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vaapi_encode_h264.c;h=a7f9a602533beb746204b748262db39bfc4434f8;hb=HEAD#l989
[13:05:58 CET] <jkqxz> hojuruku:  There is no "yet" wrt OpenMAX.  The specification is too loose to be useful generally, so the ffmpeg wrapper supports only implementations which conform to the Android requirements (those imposed by libstagefright and related stuff, as available on ~all mobile devices).  The Mesa stuff is an ad-hoc implementation without those constraints, so it doesn't work.
[13:08:09 CET] <hojuruku> openmax was merged first into mesa for amd gallium. i wonder if it does a better job than vaapi. i remember being able to play back the gst created hardware encoded videos, but the ffmpeg ones are unplayable.
[13:08:59 CET] <wasperen> JEEB, well this is the thing. It sort of does...
[13:09:14 CET] <wasperen> running config again and will copy the output here
[13:09:18 CET] <wasperen> (relevant parts)
[13:10:37 CET] <wasperen> under "external libraries" it shows libzvbi
[13:10:51 CET] <JEEB> ok, that means the thing is enabled and should be built
[13:11:04 CET] <JEEB> so now the main thing is to check that you actually tested it to be available
[13:11:09 CET] <JEEB> (with the thing you built)
[13:11:34 CET] <JEEB> also one simple way to check is to just ffprobe FILE or ffmpeg -i FILE and see if the teletext track is actually noted as teletext
[13:11:47 CET] <JEEB> but it should also be in the list
[13:11:52 CET] <wasperen> under enables decoders it shows libzvbi_teletext
[13:11:58 CET] <JEEB> yes
[13:12:02 CET] <JEEB> that much I understood
[13:12:13 CET] <wasperen> I have it installed under ~/local/ffmpeg/bin
[13:12:25 CET] <wasperen> I'll run the probe
[13:13:06 CET] <wasperen> output: Stream #0:2[0x1424](eng,eng): Subtitle: dvb_teletext ([6][0][0][0] / 0x0006)
[13:13:17 CET] <wasperen> but also: Unsupported codec with id 94215 for input stream 2
[13:13:24 CET] <wasperen> ok...
[13:13:56 CET] <hojuruku> yeah i need to turn of cbac as well for baseline compatibility - but when i run ffmpeg -h encoder=h264_vaapi it says -coder             <int>        E..V.... Entropy coder type (from 0 to 1) (default cabac)
[13:13:56 CET] <hojuruku>      cavlc                        E..V....
[13:13:56 CET] <hojuruku>      cabac                        E..V....
[13:13:56 CET] <hojuruku>      vlc                          E..V....
[13:13:56 CET] <hojuruku>      ac                           E..V....
[13:13:57 CET] <hojuruku>  Syntax is no good - choice of zero and one. What is zero and one?
[13:14:19 CET] <JEEB> just use the names
[13:14:28 CET] <wasperen> and ffmpeg -codecs (the right one!) shows:  ..S... dvb_teletext         DVB teletext
[13:14:34 CET] <hojuruku> i tried that - it gets angry it want a zero or a one.
[13:14:41 CET] <JEEB> wasperen: ok, then it is there :P
[13:15:09 CET] <wasperen> but... should it now show DES... dvb_teletext?
[13:15:34 CET] <JEEB> I know for sure there is no encoder in libavcodec for teletext
[13:15:47 CET] <wasperen> what do you mean with "use the names"?
[13:15:57 CET] <wasperen> Ok -- but a decoder should be there...
[13:16:26 CET] <wasperen> so should it not read ".DS... dvb_teletext"?
[13:17:00 CET] <JEEB> hojuruku: it definitely has the named options in the code so either there's a bug or you're doing something wrong
[13:17:13 CET] <JEEB> just look at the h264 vaapi encoder code I noted
[13:18:00 CET] <JEEB> wasperen: do you have "libzvbi_teletextdec" noted anywhere?
[13:20:07 CET] <wasperen> JEEB -- I have "installed" it under ~/local/ffmpeg -- but maybe it still uses the system-provided libavcodecs?
[13:20:14 CET] <hojuruku> JEEB: indeed you were right, i needed -coder:v not -coder.
[13:20:32 CET] <JEEB> hojuruku: it probably was trying to apply that option to something else then
[13:20:37 CET] <wasperen> I have only added a --prefix to the configure
[13:20:40 CET] <JEEB> you can have that with the "profile" option as well
[13:21:04 CET] <JEEB> wasperen: then it should be static, and not shared. also make sure you cleared your build directory between builds
[13:21:41 CET] <JEEB> hojuruku: for example both AAC and AVC encoders usually have the "profile" option and of course the values don't match so you have to specify which encoder you'd be setting the value to
[13:23:33 CET] <wasperen> JEEB -- I'll run make clean and build again
[13:24:08 CET] <JEEB> that's why i usually build in separate roots
[13:24:15 CET] <JEEB> I can just nuke them from the orbit
[13:24:21 CET] <JEEB> and recreate the directory and call configure/make from there :P
[13:24:47 CET] <hojuruku> jeeb adding "-profile:v baseline -level 3.0" gave [h264_vaapi @ 0x55f7f37bb4e0] [Eval @ 0x7ffc35116d50] Undefined constant or missing '(' in 'baseline' [h264_vaapi @ 0x55f7f37bb4e0] Unable to parse option value "baseline"
[13:24:58 CET] <wasperen> It has been a while since I did the good-old configure/make cycle :)
[13:25:27 CET] <JEEB> hojuruku: are the quotes on your command line actually like that?
[13:25:46 CET] <JEEB> (I usually use backticks or nothing to denote a command line or a part of it)
[13:25:56 CET] <wasperen> I'll move the system-provided libavcodec out of the way and see if it uses the newly built ine
[13:26:16 CET] <JEEB> unless you used enable-shared the libavcodec should be just fine :P
[13:26:17 CET] <hojuruku> nope just to show you the text i added.
[13:26:20 CET] <JEEB> since it's always statically linked
[13:27:09 CET] <furq> hojuruku: iirc for vaapi you need to use -profile:v 578
[13:27:25 CET] <JEEB> wat
[13:27:58 CET] <JEEB> then what are these good for? http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vaapi_encode_h264.c;h=a7f9a602533beb746204b748262db39bfc4434f8;hb=HEAD#l1025
[13:28:14 CET] <hojuruku> furq: omg you did it... Stream #0:0(eng): Video: h264 (h264_vaapi) (Constrained Baseline) (H264 / 0x34363248) - ppl complaining about it all over the place online ;)
[13:28:25 CET] <furq> oh i guess constrained_baseline will work as well then
[13:28:40 CET] <furq> that's dumb considering x264 just uses -profile baseline
[13:28:57 CET] <JEEB> technically constrained baseline is more correct, but yes - everyone keeps calling it "baseline"
[13:29:01 CET] <furq> yeah
[13:29:17 CET] <hojuruku> i'm going to find the ppl complaining ;)
[13:29:22 CET] <furq> consistency is more important than technical correctness
[13:29:36 CET] <hojuruku> how do you calculate that number furq?
[13:29:43 CET] <JEEB> hojuruku: you don't need the number
[13:29:46 CET] <JEEB> just look at the link I posted
[13:29:51 CET] <furq> https://www.ffmpeg.org/doxygen/trunk/avcodec_8h_source.html#l02866
[13:30:04 CET] <JEEB> there just is no "baseline" defined for vaapi h264 encoder
[13:30:15 CET] <JEEB> the list is "constrained_baseline", "main", "high"
[13:30:19 CET] <furq> right
[13:30:24 CET] <JEEB> which is why "baseline" was not found
[13:30:57 CET] <JEEB> anyways, if someoen cares they could add "baseline" as an additional alternative setting the profile to constrained baseline to match libx264
[13:32:20 CET] <furq> https://github.com/FFmpeg/FFmpeg/commit/c490fc9536dcea7fdf1245a340bf075533610bc2
[13:32:23 CET] <furq> i was only two months out of date then
[13:32:37 CET] <DHE> x264 only offers a single profile with "baseline" in its name though...
[13:32:46 CET] <JEEB> DHE: yeh
[13:32:51 CET] <furq> yeah, which is constrained baseline
[13:32:55 CET] <JEEB> and that's constrained baseline
[13:32:58 CET] <hojuruku> so it would work with -profile:v constrained_baseline
[13:33:01 CET] <JEEB> yes
[13:33:04 CET] <furq> yeah
[13:33:22 CET] <furq> if your ffmpeg is new enough
[13:33:28 CET] <DHE> but then there would be no typical/correct "baseline" profile to go with it.
[13:33:39 CET] <furq> well neither of those encoders have an actual baseline profile
[13:33:48 CET] <furq> and cbp is still technically baseline
[13:34:19 CET] <hojuruku> i can't see how you worked out 578 yet in the source
[13:34:54 CET] <JEEB> DHE: so yes, technically "baseline" was always a misnomer which was left to be because a) nobody actually used the actual baseline as it was not a subset of main (and thus high) b) constrained baseline is a subset of baseline
[13:35:07 CET] <furq> hojuruku: http://codepad.org/Ce65vRBn
[13:35:11 CET] <DHE> (a) was going to be my next question.
[13:35:11 CET] <JEEB> but yea, we would have to have some sort of consistency
[13:35:25 CET] <JEEB> which seems to be hard because different people work on different encoders :P
[13:36:23 CET] <furq> does anything actually use the non-constrained baseline features
[13:36:49 CET] <furq> it's just transmission robustness stuff isn't it
[13:37:10 CET] <JEEB> maybe in the beginning by academic stuff, and possibly some video conferencing stuff?
[13:37:20 CET] <furq> likewise with extended profile which i don't think i've ever seen
[13:37:22 CET] <JEEB> nothing too general since none of the main implementations implement those features
[13:37:37 CET] <JEEB> as in, none of the closed ones either
[13:37:47 CET] <furq> yeah i figured maybe some commercial stuff used it
[13:38:30 CET] <JEEB> yea, what I was hinting at was some really expensive telco system by cisco or something would possibly use it... for a while, until they found it not too useful :)
[13:38:42 CET] <JEEB> after all, I think scalable video coding is also used by some IP telco solutions
[13:38:44 CET] <furq> makes sense
[13:39:12 CET] <furq> it doesn't sound like there's too much risk of ffmpeg adding support for an encoder where there's a meaningful distinction
[13:39:57 CET] <hojuruku> https://en.wikipedia.org/wiki/Context-adaptive_variable-length_coding is that supported in constrained baseline like it is in baseline?
[13:40:06 CET] <furq> yes
[13:40:19 CET] <JEEB> hojuruku: AVC only has CAVLC and CABAC for coding of symbols
[13:40:27 CET] <JEEB> and baseline/constrained baseline don't have CABAC
[13:40:42 CET] <JEEB> so you kind of can't remove CAVLC can you :D
[13:41:12 CET] <JEEB> or more specifically, something else than CAVLC gets added to be available as a tool /after/ baseline profiles
[13:41:26 CET] <hojuruku> so ac and vlc are not supported in constrained baseline only cavlc :P ok
[13:41:58 CET] <JEEB> more like they don't exist in H.264/AVC
[13:42:11 CET] <JEEB> H.264/AVC only has CAVLC and CABAC
[13:42:18 CET] <JEEB> H.265/HEVC only has CABAC
[13:42:46 CET] <hojuruku> what'a ac and vlc's full names / and what codes support them?
[13:43:07 CET] <hojuruku> ah they are different stages in the pipeline
[13:43:53 CET] <JEEB> well all of them are something to compress the final data losslessly
[13:44:06 CET] <JEEB> which is why in theory you can take a H.264 stream coded with CAVLC and re-compress it with CABAC
[13:45:57 CET] <wasperen> JEEB -- so, moving the system-provided libavcodec.so out of the way breaks the newly built ffmpeg
[13:46:16 CET] <wasperen> So it does use the systems one rather than the newly created one
[13:46:39 CET] <wasperen> how do you create a new build-root?
[13:47:12 CET] <wasperen> or make the linking to libavcodec to the new one rather than the system one?
[13:47:33 CET] <hojuruku> what's the maximum bitrate of h264 level in the average 1080p / 720p home television - e.g. a tcl. I'm trying to find out what mine is capable of, what audio codecs it support. It can play mp3 files but not in a matroska for audio. Seems to like DTS audio.
[13:47:35 CET] <wasperen> (I'm sure this is basic stuff, sorry for asking stupid questions :))
[13:47:42 CET] <JEEB> wasperen: this works for me just fine :P http://up-cat.net/p/426d9769
[13:47:57 CET] <JEEB> hojuruku: most recent enough hw decoders take level 4.1
[13:49:10 CET] <hojuruku> yeah it slows down at 60fps 1080p ;)
[13:49:41 CET] <JEEB> well blu-ray for example goes up to 720p60/1.001
[13:49:56 CET] <JEEB> so some things having issues with 1080p60/1.001 isn't exactly surprising
[13:50:28 CET] <JEEB> my default for hwdec support is high/level 4.1. if the decoder doesn't take that, then main/level 4.1 and finally main/level 3.0
[13:50:45 CET] <JEEB> the last one was what the PSP from 2004 supported :P
[13:51:36 CET] <hojuruku> constrained_baseline & -level:v 4.1 is valid?
[13:52:19 CET] <JEEB> why not?
[13:53:30 CET] <hojuruku> great. Now the only other problem is subtitles in the source are not making it through with -scodec copy. The source material plays without sound and subtitles but the destination does not, and it only takes one of the two subtitle channels
[13:54:22 CET] <JEEB> if you want all subtitles to be passed with the ffmpeg.c command line tool, you'd have to start mapping streams manually
[13:54:51 CET] <JEEB> (as soon as you add one mapping the whole app switches to manual stream selection)
[13:55:40 CET] <JEEB> so what you probably want is -map 0:v (maps all video streams from 0th input) -map 0:a:0 (-maps first audio track from 0th input) -map 0:s (maps all subtitle streams from 0th input)
[13:56:28 CET] <hojuruku> furq: so it's not possible to use a numeric code for baseline with the amd polaris 21 vce - i have to use "constrained baseline"
[13:57:38 CET] <JEEB> you will get a message that non-constrained baseline is not supported by the encoder from the encoder itself
[13:57:41 CET] <JEEB> :P
[13:58:15 CET] <JEEB> people have just gotten used to calling constrained baseline "baseline" because so few things actually utilize the baseline profile
[13:59:15 CET] <JEEB> in case of libx264 it was called just "baseline", and the person who added the options to the VAAPI H.264 encoder decided to be technically correct
[13:59:57 CET] <JEEB> of course nobody stops one from adding "baseline" as another value there that maps to the constrained baseline profile
[14:00:34 CET] <JEEB> oh wait
[14:00:36 CET] <JEEB> haha
[14:00:42 CET] <JEEB> the darn code doesn't error there
[14:00:50 CET] <JEEB> it just warns you about baseline not being supported
[14:00:57 CET] <JEEB> and then sets profile to constrained
[14:00:58 CET] <JEEB> :D
[14:03:20 CET] <specing> Any idea how to make -ss work with stuff to encode passed on /dev/stdin?
[14:03:24 CET] <specing> "/dev/stdin: could not seek to position 89393.261"
[14:03:58 CET] <specing> if this is in frames, then it is much different to -ss 00:08:11
[14:04:47 CET] <JEEB> no
[14:05:02 CET] <JEEB> it is just trying to seek in the input and since your input is a non-seekable stream it tells you it can't seek
[14:05:05 CET] <JEEB> which isn't surprising
[14:05:26 CET] <JEEB> -ss isn't "skip this much input", it's "try seeking in this input to this point"
[14:05:54 CET] <specing> How do I tell it to skip instead of seek?
[14:07:04 CET] <JEEB> no idea :)
[14:07:08 CET] <specing> >_>
[14:07:40 CET] <JEEB> I mean, with the API it's simple (you keep reading until you get to where you wanted to be), but with ffmpeg.c NFI :)
[14:08:13 CET] <specing> ah I think I get it
[14:08:19 CET] <specing> "When used as an output option (before an output url), decodes but discards input until the timestamps reach position."
[14:08:25 CET] <specing> lets see
[14:08:40 CET] <JEEB> right, that at least on some level sounds like it :)
[14:09:06 CET] <JEEB> also that seems to decode, too. but I guess you're OK with that?
[14:09:50 CET] <specing> better than nothing ;)
[14:10:05 CET] <specing> actually I'm using -stream copy, so its more or less a noop
[14:10:22 CET] <specing> "-codec copy"
[14:10:55 CET] <JEEB> umm
[14:11:08 CET] <JEEB> yea, that skips decoding altogether. so not sure how that will work with the -ss that is supposed to decode
[14:11:47 CET] <specing> *shrug*
[14:17:24 CET] <sine0> I have a dozen podcasts where the best bit starts 45 minutes in, they are in mp3 format, how can i trim to tha part and save
[14:18:04 CET] <sine0> -ss
[14:18:05 CET] <JEEB> if you have the file around you can just use -ss before the input
[14:22:03 CET] <sine0> yay
[14:22:06 CET] <sine0> :)
[14:23:48 CET] <specing> JEEB: that works, but the seek position is wrong, both at start and at end >_>
[14:23:58 CET] <specing> most annoying
[14:24:13 CET] <JEEB> rip
[14:24:32 CET] <JEEB> which container is it, btw?
[14:24:35 CET] <wasperen> JEEB -- thanks for your support! I made it work
[14:24:43 CET] <JEEB> wasperen: great :)
[14:24:59 CET] <wasperen> (stupid but I flagged the configure --enable-linked)
[14:25:13 CET] <wasperen> thanks again
[14:25:16 CET] <wasperen> you rock
[14:25:28 CET] <JEEB> yea that's why I was trying to stress "are you sure you're testing what you built"
[14:25:49 CET] <JEEB> and testing with a static build is probably the simplest way to do that
[14:25:53 CET] <JEEB> you can always enable shared later
[14:26:27 CET] <wasperen> I'm more a java / scala man -- moving the system-provided lib out of the way and seeing it breaking convinced me
[14:28:02 CET] <specing> huh?
[14:29:40 CET] <BtbN> So you moved system libs around, and stuff broke, and that's why Java is better? oO
[14:30:48 CET] <JEEB> no
[14:31:12 CET] <JEEB> he just didn't think too much of the enable-linked too much
[14:31:15 CET] <JEEB> :P
[14:33:20 CET] <wasperen> exactly --
[14:33:54 CET] <hojuruku> i only get 93fps with rx560's vce (4.14 - i'll try out amdgpu.dc=1 and 4.15 very shortly) doing a h254 transcode from 1080p to 1366x768.
[14:33:56 CET] <wasperen> (you don't know how many hours I have spent fixing java classpath issues!)
[14:34:36 CET] <BtbN> 93 fps for decoding and encoding hevc sounds decent to me
[14:34:52 CET] <BtbN> is this via vaapi?
[14:35:07 CET] <specing> wasperen: you don't have those problems if you aren't using java ;p
[14:35:26 CET] <JEEB> everything has its own kinks :P
[14:35:41 CET] <specing> I have spent a lot of hours getting a working Ada compiler onto Gentoo
[14:35:51 CET] <hojuruku> https://github.com/Xaymar/obs-studio_amf-encoder-plugin/wiki/Hardware-VCE3.4 that's what it get's in windows.  111fps - oh that's right for quality - plus the other 20fps is the vaapi resize filter
[14:40:59 CET] <hojuruku> vdpau/vaapi  supports high quality scaling/resizing on playback in mpv. What's the default in ffmpeg. In mpv it's --vo-vaapi-scaling=<algorithm> fast hq default nla
[14:46:35 CET] <hojuruku> BtbN: it's h264
[15:06:47 CET] <hojuruku> intel uses NV12 for the vaapi hardware surfaces, i wonder what amd uses....
[15:07:24 CET] <BtbN> pretty much every hardware uses NV12
[15:07:33 CET] <BtbN> most even in a tiled variant
[15:09:14 CET] <hojuruku> that's the internal format, but the hardware (not software conversion) can decode to other formats right? (-hwaccel-output_format) like yuv20p for doing a software encode. Now how do I verify x264 is using the opencl?....
[15:10:04 CET] <hojuruku> amd has got a chip for encode (uvd 3.4 external) and encode (vce on die). I doubt it would get faster if I used the onboard graphics to decode.
[15:10:32 CET] <hojuruku> A few years ago intel quick sync video didn't support haswell refresh for h264 encode, but windows did. Have they made it catch up yet?
[15:12:56 CET] <BtbN> at least cuvid can output _only_ NV12 and variants of it.
[15:13:09 CET] <BtbN> nvenc accepts other formats for convenience, but internally converts them to NV12
[15:17:03 CET] <hojuruku> "BEWARE: if you use the installer script the custom libva would override your system one, you might not want that. " Ah if I get quicksync installed I'll have to only enable it via ld_library_path
[15:17:22 CET] <BtbN> you should forget qsv for Linux even exists.
[15:17:42 CET] <JEEB> yea
[15:17:47 CET] <JEEB> qsv on linux is a major PITA
[15:19:31 CET] <hojuruku> https://blogs.gentoo.org/lu_zero/2016/10/31/intel-mediasdk-mini-walkthrough/
[15:19:52 CET] <hojuruku> kernel patches for 4.14 for media sdk.. i wonder
[15:20:48 CET] <BtbN> Just give up on it. There is absolutely no reason to waste time on it.
[15:20:58 CET] <BtbN> QSV should only be used on Windows, and even there it's a pain.
[15:21:17 CET] <hojuruku> yeah i know i used it with handbrake on windows, it was a PITA too.
[15:21:44 CET] <hojuruku> but amd rx560 no b frames is a pain me thinks. Will youtube accept a live stream without b-frames?
[15:22:02 CET] <BtbN> live streams usually do not have b frames
[15:22:08 CET] <BtbN> to avoid reorder-delay
[15:22:23 CET] <hojuruku> i'm a gentoo guy, i can make custom ebuilds and put all the quicksync stuff in a custom path - at least userspace. I just hope amd can still use the dri after they have patched the crap out of it
[15:22:45 CET] <BtbN> Why tho?
[15:22:52 CET] <BtbN> There is zero reason to deal with QSV on Linux.
[15:23:15 CET] <hojuruku> it's that bad?
[15:23:24 CET] <BtbN> It needs Kernel patches...
[15:23:30 CET] <BtbN> And patches to various system libs
[15:23:32 CET] <hojuruku> what's the fps at 1080p with H264 encode on intel qsv?
[15:23:32 CET] <BtbN> so why bother?
[15:23:43 CET] <hojuruku> it only patches the kernel and libva right?
[15:23:48 CET] <BtbN> and libdrm
[15:24:00 CET] <hojuruku> ouch libdrm, well i already have a custom gentoo build....
[15:24:07 CET] <BtbN> libva encoding just works out of the box
[15:24:10 CET] <hojuruku> libdrm git doesn't need to be patched?
[15:24:13 CET] <BtbN> so why the hell deal with qsv?
[15:25:40 CET] <hojuruku> i had trouble using vaapi on haswell with filters before some bug i can try dig it up
[15:27:03 CET] <hojuruku> https://gab.ai/ozzieslovepedos/posts/7802589 ah yes dug it up https://trac.ffmpeg.org/ticket/5532
[15:27:44 CET] <hojuruku> it got fixed i guess.
[15:30:34 CET] <hojuruku> https://software.intel.com/en-us/forums/intel-media-sdk/topic/595283 intel saying qsv is faster
[15:32:35 CET] <BtbN> it uses the exact same hardware
[15:32:41 CET] <hojuruku> yeah i'll stick with just plain vaapi unless i need more performance for my workload for now.
[15:32:43 CET] <BtbN> and qsv is just a wrapper on top of libva
[15:32:55 CET] <BtbN> so claiming it to be faster makes no sense
[15:33:13 CET] <hojuruku> they say the driver patches improve performance
[15:33:46 CET] <BtbN> And why won't they just merge them then?
[15:33:50 CET] <hojuruku> anyway haswell has no h265 encode so there is no point. i think they have 265 hardware decoding on windows but not linux nevermind moving on.
[15:33:59 CET] <hojuruku> yeah i dropped it.... ;)
[15:34:13 CET] <JEEB> they have a sw module that is used through the same API on windows I think
[15:34:20 CET] <JEEB> since haswell is old enough to not have silicon
[15:34:23 CET] <JEEB> as in, a specific chip
[15:34:51 CET] <hojuruku> "intel clear video" core on haswell doesn't have the necessary asic to do h265... i got mixed up, i thought there was the h265 hardware encode light at the end of the tunnel. How is AMD going along moving that functionality to linux.
[15:35:34 CET] <BtbN> it's exposed via vaapi iirc
[15:35:53 CET] <BtbN> But AMDs video encoder is terrible sadly
[15:52:06 CET] <hojuruku> humm the hardware tcl tv rejected the video. I'm going to try again with level 3.1 constrained baseline. Maybe it's looking at the level settings in the video header.  I don't watch my little pony but i'll leave a usb stick in the tv with it for my daughter
[15:52:21 CET] <hojuruku> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i rep-mylittleponythemovie.2017.1080p.bluray.x264.mkv -vf 'scale_vaapi=w=1280:h=720' -map 0:0 -map 0:1 -map 0:2 -map 0:3 -c:v h264_vaapi -b:v 4500k -qp 18 -bf 0 -profile:v 578 -quality:v 0 -level:v 3.1 -coder:v cavlc -c:a ac3 -ab 224k -ar 48000 -ac 2 -codec:s copy -sub_charenc UTF-8 -metadata:s:s:0 language=eng -metadata:s:s:1 language=eng
[15:52:22 CET] <hojuruku> /run/media/lmc/4409-8CCC/mylittlepony.mkv
[15:52:52 CET] <JEEB> do you know it takes in matroska at all btw?
[15:53:21 CET] <hojuruku> yeah it plays 1080 in another sample i got from mkv. the original video doesn't like the audo
[15:53:37 CET] <yusa> Hello all!
[15:53:45 CET] <JEEB> also lol at still using the integer for the profile :P
[15:53:50 CET] <JEEB> way to make it unreadable
[15:53:58 CET] <JEEB> anyways, if you know that the video track works
[15:54:06 CET] <JEEB> just transcode the audio to AAC, that's the most common thing to work
[15:54:11 CET] <hojuruku> the tcl cheap tv with a usb port can't do DTS, but it does AC3. It can't do mp3 in mkv/mp4 streams either.
[15:54:35 CET] <hojuruku> haha it wont fit on the 4 gb usb key i'm throwing away then ;)
[15:54:42 CET] <JEEB> right
[15:54:56 CET] <hojuruku> JEEB: it rejects constrained_baseline
[15:55:05 CET] <JEEB> old version or something?
[15:55:12 CET] <hojuruku> and the interger is in the vaapi howto on your website .. oh sorry the evil libav website
[15:55:31 CET] <JEEB> stop the evil/whatever BS, thank you
[15:55:54 CET] <JEEB> but yea, originally the vaapi encoder didn't have the string-based options
[15:56:03 CET] <JEEB> they were added in late last year I think
[15:56:35 CET] <hojuruku> https://trac.ffmpeg.org/wiki/Hardware/VAAPI sorry i stand corrected you have 578 on your VAAPI page not libav
[15:57:01 CET] <hojuruku> exactly what do i type -profile:v WHAT?? because constrained_baseline is rejected.
[15:57:29 CET] <JEEB> well the wiki pages are community maintained
[15:57:45 CET] <JEEB> hojuruku: as I asked, what is your FFmpeg version?
[15:58:22 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=c490fc9536dcea7fdf1245a340bf075533610bc2
[15:58:27 CET] <JEEB> this is what added the named options
[15:59:03 CET] <JEEB> before then the integer was correct since nobody had added string-wise AVOptions
[15:59:25 CET] <hojuruku> gentoo is pretty recent, i wont try git because it breaks too much. 3.4.1-r1
[15:59:41 CET] <JEEB> yea, that probably is after the cut for the 3.4 series
[16:01:25 CET] <hojuruku> do some hardware players (old one - think 4 year old tcl tv) demand cabac or high profile input?
[16:03:17 CET] <JEEB> their software might be doing weird stuff but usually when people cheap out the hw limit is upwards, not downwards :P
[16:04:14 CET] <JEEB> because to make a main profile decoder you need to support features in constrained baseline, and to make a high profile decoder you need to support features in main profile, as they are subsets of each other
[16:04:15 CET] <hojuruku> i wonder if someone has made a swuite of test videos to probe the capabilities of your tv :)
[16:04:44 CET] <hojuruku> constrained baseline only supports levels up to 3.2 right?
[16:04:58 CET] <JEEB> I'd have to open the specification for that
[16:05:00 CET] <hojuruku> officially that is.  if you want hardware players to accept it
[16:05:20 CET] <JEEB> because different profiles had slightly different limitations on the levels
[16:05:56 CET] <yusa> Hello I am quite new to ffmpeg at all, but maybe you can kickstart me a little bit! I am actually from the area of object recognition, but for my demonstrator i will need to convert raw images. I am handling with 8-bit gray scale raw images that currently live in allocated memory in my C-tool. I could imagine piping these images from there to the ffmpeg tool. (Like in this example i found: #cat png/*png | ffmpeg -f image2pipe -c:v png -
[16:06:21 CET] <hojuruku> maybe you might need a level 3.0 or 3.1 or 3.2 along with the constrianed profile to make the hardware player accept the b-frame content. maybe ffmpeg for some reason is choosing a higher level by default. ffmpeg always tries to choose the lowest compatible right?
[16:06:32 CET] <JEEB> uhh
[16:06:36 CET] <yusa> The format is specified here by "-c:v png". How to specify my raw images? (x and y resolution, 8-bit gray scale)
[16:06:47 CET] <JEEB> hojuruku: a whole buttload of stuff depends exactly on the encoder you're using
[16:06:59 CET] <JEEB> so saying generic statements on FFmpeg isn't going to help
[16:07:10 CET] <hojuruku> yeah i'll have to read the source for h264_enc
[16:07:16 CET] <hojuruku> i mean vaapi_h264enc
[16:07:20 CET] <JEEB> also for b-frames you need main profile or higher
[16:07:28 CET] <JEEB> since CABAC and b-frames are only included there
[16:08:37 CET] <hojuruku> i'm talking the other way, with no b-frames and no cabac - you'll need to limit the max level you will put in the stream header right? i wonder if constrained baseline use in hardware plays only works to a certian level that's lower than the player's max capabilities. (e.g. 3.1 / 3.2)
[16:10:09 CET] <JEEB> hojuruku: for your reference the limits between levels are common between baseline, constrained baseline, main and extended profiles
[16:10:22 CET] <JEEB> A.3.1 in the AVC/H.264 specification
[16:10:24 CET] <JEEB> there's also a nice table
[16:10:40 CET] <JEEB> so it's just the high *** profiles that have a separate sets of limits
[16:10:51 CET] <hojuruku> ah so with constrained baseline you are not allowed to go above level 3.1
[16:10:54 CET] <JEEB> and the table has 4+ just fine for baseline|main|extended
[16:11:03 CET] <JEEB> no, A.3.1. is the part of the goddamn specification
[16:12:09 CET] <yusa> Any ideas? :P
[16:12:45 CET] <JEEB> and baseline/constrained baseline does have specific limits on the MbRectSize for levels 1-3.0, but defines anything higher just fine as "just follow the general requirements for the profile"
[16:13:03 CET] <JEEB> so I don't know where this "constrained baseline only supports up to 3.2" thing comes from :P
[16:13:24 CET] <hojuruku> ah i'm trying to find why this hardware player is rejecting it but the pc is playing it fine
[16:13:42 CET] <JEEB> personally I would just make short clips with minimal stuff first :P
[16:13:47 CET] <hojuruku> divide and conquer, i'll take 10 mins of the raw video without transcoding and change the audio to see if that fixes it.
[16:13:54 CET] <hojuruku> .. then confirm my audio is ok so i can focus on the video.
[16:14:58 CET] <JEEB> first an mp4 file with just AVC video, and AAC audio only, and setting -movflags faststart. first by copying, then re-encode
[16:15:22 CET] <JEEB> because something like -c:a aac -ac 2 -b:a 192k should be good enough for basic AAC
[16:15:45 CET] <JEEB> (you could probably lower the bit rate quite a bit, but it generally takes a small part of it all)
[16:15:50 CET] <JEEB> then you start playing around with other variables
[16:16:01 CET] <JEEB> after you make sure that the basics of video and audio work :P
[16:16:11 CET] <JEEB> after you verify mp4, you can also test mkv
[16:16:12 CET] <JEEB> etc etc
[16:16:30 CET] <hojuruku> yeah i'm using ac3 because i first tried big buck bunny samples on the hardware player. mp4 with mp3 audio at 720p failed, but mp4 with ac3 448k 720p surround sound palyed fine
[16:16:41 CET] <hojuruku> so i know mp3 isn't supported by the hardware player at least in video streams.
[16:16:54 CET] <JEEB> that's usually an issue with people not implementing old mpeg audio parsing from mp4
[16:16:59 CET] <JEEB> rather than a "doesn't support mp3" issue
[16:17:12 CET] <JEEB> which is why I note AAC as the first thing I test with mp4
[16:17:26 CET] <JEEB> since that stuff, esp. with the movflags faststart flag, tends to more or less work
[16:17:36 CET] <hojuruku> oh so i should test again with mkv.
[16:17:52 CET] <JEEB> yea if you have an exact combo that works with mp4
[16:17:57 CET] <JEEB> you should -c copy that into mkv
[16:18:01 CET] <JEEB> and see how that works
[16:18:11 CET] <hojuruku> it's there a equivalent flag for mkv to have the fast start?
[16:18:17 CET] <JEEB> it doesn't need it per se
[16:18:22 CET] <JEEB> so there isn't
[16:18:38 CET] <hojuruku> yeah, mp4 can not define the length of the video etc at the beginning for streaming, but mkv not so.
[16:22:21 CET] <hojuruku> that's an idea, maybe mkv container is assumed to be main or high profile by the hardware player, but mp4 support not.
[16:22:32 CET] <JEEB> lol no
[16:22:43 CET] <JEEB> generally just issues with specific audio/video formats or containers altogether
[16:23:00 CET] <JEEB> although to be completely honest I have no idea what the AMD encoder spouts out at all
[16:23:04 CET] <JEEB> also you added subtitle tracks etc
[16:23:12 CET] <JEEB> there's plenty of stuff that could make the TV go "nope"
[16:23:29 CET] <JEEB> which is why you start with the most plain of plainest for most ekta plastik boxes
[16:23:30 CET] <hojuruku> the subtitle tracks work in the original video so remove them. got it.
[16:23:42 CET] <JEEB> eh
[16:23:50 CET] <JEEB> I'm just saying limit your darn testing surface
[16:23:51 CET] <hojuruku> but the srt subtitles work in the sample from the original source (only the dts audio fails)
[16:24:23 CET] <JEEB> as in make a short sample, encode just video and audio in mp4 with faststart
[16:24:27 CET] <JEEB> test that
[16:24:33 CET] <JEEB> if works, add more stuff step by step
[16:24:34 CET] <JEEB> :P
[16:24:48 CET] <JEEB> I don't think this is a hard thing to grasp
[16:25:28 CET] <hojuruku> but what i started with was mkv 1080p, dts, srt and it worked minus the audio. That's why i'm confused now.
[16:26:22 CET] <JEEB> well it could just be the video encoder being derp, of course. but still. minimize the testing surface. output a short sample with just the video and the audio into mp4, test that
[16:26:36 CET] <JEEB> then test -c:v libx264 -profile main -level 4.1 or something like that
[16:26:43 CET] <JEEB> or even baseline
[16:27:04 CET] <JEEB> (which is constrained baseline)
[16:27:19 CET] <JEEB> I'm pretty sure all of those would work on your device, but at least libx264 should give you relatively known results
[16:27:29 CET] <hojuruku> libx264 high  aac 192 made by handbrake failed on the audio ;)
[16:27:36 CET] <hojuruku> but the video worked fine.
[16:27:47 CET] <JEEB> I don't know what exactly handbrake did there
[16:28:01 CET] <hojuruku> the hardware player generally carries on if the audio is broken but borks if the video is screwed.
[16:28:09 CET] <JEEB> anyways, that sort of thing failing with AAC would be rather funny
[16:28:14 CET] <hojuruku> i can see what handbrake did with mediainfo
[16:28:55 CET] <hojuruku> maybe it only does aac up to 128k
[16:29:02 CET] <JEEB> no, instead just darn test things quickly with ffmpeg.c since that's what you're currently utilizing (´4@)
[16:29:07 CET] <JEEB> rather darn arbitrary limit that
[16:29:16 CET] <JEEB> I mean, you can keep on darn guessing as much as you want
[16:29:22 CET] <furq> yeah i'm not sure there is anything that has that kind of limit
[16:29:46 CET] <JEEB> anyways, have fun - I'm going out to get fresh air and see who I will vote for
[16:29:58 CET] <hojuruku> testing with mp4 now...
[16:31:04 CET] <JEEB> just darn test with `ffmpeg -i INPUT -t 120 -c:v libx264 -profile baseline -level 4.1 -c:a aac -ac 2 -b:a 192k -sn -movflags faststart test1.mp4`
[16:31:09 CET] <JEEB> then give that a fly
[16:31:16 CET] <JEEB> that's the very basic of basics
[16:31:23 CET] <JEEB> if you need to re-encode
[16:31:29 CET] <JEEB> if you don't then it's all simpler
[16:31:35 CET] <furq> JEEB: nils torvalds of course
[16:32:01 CET] <JEEB> then if you need stuff like subtitles you switch to mkv next
[16:32:15 CET] <JEEB> then if that works you switch to your beloved black box VAAPI encoder
[16:32:26 CET] <JEEB> if that breaks you know it's not baseline nor the level which you guessed around
[16:32:33 CET] <JEEB> it's just whatever the VAAPI encoder is doing
[16:32:42 CET] <JEEB> but ye, I'm outta here
[16:42:23 CET] <hojuruku> it rejected the mp4 with whatever vaapi was making completly with aac, but scrambled the screen with the mkv with 128 aac which was interesting.
[16:42:34 CET] <hojuruku> i'll begin testing using software encoders now.
[16:42:42 CET] <hojuruku> i thought if it played on my pc it was good... it's not good.
[16:43:46 CET] <furq> yusa: -s 123x456 -c:v rawvideo
[16:44:08 CET] <furq> you might need to set -pixel_format before -i as well
[16:44:39 CET] <yusa> I was trying: ffmpeg -f image2 -r 30 -s 1280x720 -pix_fmt rgb24 -vcodec rawvideo -i raw/*.raw raw.mp4
[16:44:59 CET] <yusa> for these test images in folder raw/
[16:45:09 CET] <yusa> [NULL @ 0x11010c0] Unable to find a suitable output format for 'raw/image002.raw' raw/image002.raw: Invalid argument
[16:45:58 CET] <klaxa> doesn't this image """raw""" format contain tons of metadata?
[16:46:11 CET] <furq> oh if you mean .raw then that's different
[16:46:16 CET] <furq> i thought you meant piping raw frames into ffmpeg
[16:46:41 CET] <yusa> ah, with raw i mean only the pixel data nothing else
[16:46:58 CET] <yusa> thats what my .raw files contain, sorry if i am messing up with file types
[16:47:24 CET] <furq> yeah that's rawvideo then
[16:48:19 CET] <furq> probably something like cat *.raw | ffmpeg -s 123x456 -pix_fmt rgb24 -f rawvideo -i - out.mp4
[16:49:28 CET] <yusa> awesome almost worked
[16:51:30 CET] <yusa> How can i print all available pixel formats i can apply to -pix_fmt?
[16:53:36 CET] <furq> ffmpeg -pix_fmts
[16:54:32 CET] <yusa> okay for my 8-bit gray scale images, i will need gray i guess
[16:54:39 CET] <yusa> thank you very much
[17:00:21 CET] <yusa> Another question: Is it somehow possible output not in a file but as a RTP/RTSP or RTMP stream ?
[17:02:12 CET] <hojuruku> haha -x264-params opencl makes it go  slower  i think.  well 1.33fps vs 1.2
[17:32:37 CET] <furq> yusa: if you have an rtmp server to send it to, sure
[17:32:51 CET] <furq> -c:v libx264 -f flv rtmp://1.2.3.4/live
[17:36:52 CET] <yusa> furq: That is really cool! I am beginning to enjoy working with ffmpeg, sounds pretty straight forward. Yes i have already tried nginx media streaming server, this should work. But i also came accross ffserver, could be the most efficient solution. I am seeking for efficiency as I am working on an embedded linux platform...
[17:37:12 CET] <furq> don't use ffserver
[17:37:27 CET] <furq> nginx-rtmp is a much better choice
[17:37:41 CET] <furq> not least because ffserver is deprecated now and will be gone in the next release
[17:38:13 CET] <yusa> Aah, thanks for the insides!
[17:39:06 CET] <JEEB> hojuruku: the Proof of Concept opencl stuff only applies to lookahead, and yes - it can very much be slower
[17:39:13 CET] <JEEB> that is why people don't generally use the opencl stuff in x264
[17:39:21 CET] <JEEB> it can be easily built in, but (´4@)
[17:39:45 CET] <JEEB> it's a proof of concept, after all
[17:39:48 CET] <JEEB> http://git.videolan.org/?p=x264.git;a=commit;h=f49a1b2ef6d95d8f0f186df0fc3bfe38414e264f
[17:40:04 CET] <JEEB> so if you want to go faster, you use presets
[17:40:17 CET] <JEEB> -preset veryfast should with any modern CPU be rather quick, for example
[17:41:12 CET] <DHE> I've seen opencl give performance boosts from -20% to +20% and I'm not sure what the difference maker is
[17:41:48 CET] <furq> i've read that it may give slightly worse quality
[17:42:03 CET] <furq> so it doesn't seem worth it at all considering how unpredictable the perf is
[17:42:26 CET] <JEEB> yeh
[17:42:33 CET] <JEEB> it's a proof of concept that "we can do stuff with opencl"
[17:42:37 CET] <JEEB> not to mention this was early opencl
[17:42:53 CET] <JEEB> there's plenty of hacks there because of its age and thus opencl 1.x lacking stuff
[17:43:00 CET] <furq> use your gpu for filtering
[17:43:03 CET] <furq> it's quite good at that
[17:43:06 CET] <JEEB> yup
[17:43:07 CET] <furq> Yagiza: pls stop
[17:43:25 CET] <JEEB> unsurprisingly graphics hardware is actually good at graphics stuff
[17:44:41 CET] <JEEB> granted if you can thread your calculations really heavily
[17:44:45 CET] <JEEB> GPGPU can work
[17:45:07 CET] <JEEB> unfortunately video encoding with any resemblance of compression efficiency will not let you do that
[17:45:31 CET] <JEEB> ATi back in the day made their own video format that enabled really high threading and it was fast - but it was also not something that would compress well
[17:45:37 CET] <furq> semblance
[17:45:47 CET] <JEEB> right
[17:45:57 CET] <furq> resemblance to or semblance of
[17:46:09 CET] <JEEB> anyways, the end result was that everyone and their dog just started making ASICs for the video formats
[17:46:14 CET] <JEEB> (for both decoding and encoding)
[17:47:23 CET] <hojuruku> been testing that hardware player using libx264 ... interesting it plays aac 192 in mp4 but not mkv
[17:47:43 CET] <furq> "interesting" is one way to describe hardware players
[18:05:10 CET] <hojuruku> interesting, mpv loves what the vaapi encoder makes but gstreamer isn't having any constrained baseline.
[18:07:32 CET] <hojuruku>   Stream #0:2(eng): Data: bin_data (text / 0x74786574)    Metadata:      handler_name    : SubtitleHandler Unsupported codec with id 100359 for input stream 2 - funny i thought i disabled subtitles. ffprobe found that
[18:07:48 CET] <hojuruku> yep i encoded with -sn
[18:09:13 CET] <hojuruku> and there we go again it got added
[18:09:55 CET] <ritsuka> it's the chapters track
[18:13:33 CET] <hojuruku> i encoded with -map 0:0 -map 0:1 (audo / video only) as well as -sn and it keeps coming up with ffprobe
[18:13:52 CET] <JEEB> yes, because of how chapters can get put into mp4
[18:14:07 CET] <JEEB> or well, explicitly they're all out of spec because the working group decided they wouldn't specify chapters
[18:14:15 CET] <JEEB> so you've got either the CHAP way or the other way
[18:14:25 CET] <JEEB> and they can pop up in ffprobe like that, although I haven't seen them in general
[18:14:33 CET] <JEEB> (although I very rarely transcode stuff with chapters)
[18:20:09 CET] <hojuruku> so i've done some more testing, that was a misnomer. the hardware player can not handle aac audio in mkv container.
[18:20:51 CET] <hojuruku> i need to make libx264 do constrained baseline now... i think i can't handle that either
[18:22:07 CET] <hojuruku> libx264 doesn't support constrained baseline :P maybe it takes the interger format
[18:23:21 CET] <hojuruku> nope, why can't vaapi_h264 support baseline???
[18:23:30 CET] <furq> -profile baseline with x264 is actually constrained baseline
[18:23:41 CET] <hojuruku> [libx264 @ 0x560125dedca0] Error setting profile 578.
[18:24:54 CET] <hojuruku> this is interesting... fmpeg  -i rep-mylittleponythemovie.2017.1080p.bluray.x264.mkv -t 120 -ss 600 -c:v libx264 -coder 0 -profile:v baseline -level 3.1 -c:a aac -ac 2 -b:a 128k -sn -movflags +faststart /run/media/lmc/4409-8CCC/test10.mp4 works...
[18:25:30 CET] <hojuruku> but... ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -ss 120 -t 120 -i rep-mylittleponythemovie.2017.1080p.bluray.x264.mkv -map 0:0 -map 0:1 -c:v h264_vaapi -b:v 4000k -qp 20 -bf 0 -profile:v 578 -movflags +faststart -quality:v 0 -level:v 3.1 -coder:v cavlc -c:a aac -ab 128k -ar 48000 -ac 2 vaapitest3.mp4 - doesn't. I need to investigate how the mp4 data is corrupt somehow
[18:26:38 CET] <hojuruku> bflags... i wonder.
[18:27:34 CET] <hojuruku> maybe there is a bug here. i've set up vaapi to encode with the same paramaters exactly, and i'm going to investigate with gstreamer rejects it but mpv accepts it.
[18:33:44 CET] <hojuruku> libx264: Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 1920x808 [SAR 1:1 DAR 240:101], 2957 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default) vaapi   Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 1920x808, 3913 kb/s, SAR 1:1 DAR 240:101, 23.98 fps, 23.98 tbr, 24k tbn, 48k tbc (default)
[18:36:45 CET] <hojuruku> yep totem gstreamer isn't playing the vaapi created file with the same presets. something is going on here.
[18:37:56 CET] <hojuruku> mpv with -hwdec no -vo x11 has no problems. therefore gstreamer's playbin hates the mp4 stream created by vaapi with all the same parameters.
[18:39:24 CET] <yusa> Hi again! I've tried now: "ffmpeg -i music.mp4 -c:v libx264 -f flv rtmp://localhost/live". This streams to nginx server. With vlc i am opening "rtmp://localhost/live" and it seems to work. But then video stops, because ffmpeg has finished work as it as converted all data and sent it to the server. So my question is, how to control the output framerate so that the replay rate matches the output rate?
[18:40:06 CET] <furq> yusa: -re before -i
[18:41:01 CET] <yusa> cool, now operating constantly at 24 fps, awesome!
[18:43:09 CET] <yusa> i see, "Mainly used to simulate a grab device.  or live input stream"
[18:43:11 CET] <yusa> thanks a lot again
[18:46:15 CET] <hojuruku> qtdemux qtdemux.c:9713:qtdemux_parse_trak:<qtdemux0> Track shorter than 20% (2881879/24000 vs. 5834998/1000) of the stream found, assuming preview image or something; skipping track
[18:47:02 CET] <hojuruku> that's the problem gstreamer has with the vaapi encoded mp4
[18:48:40 CET] <hojuruku> yet vaapi encoded matroska has no errors at all with the same command line except for the container format. this is getting weird. is it a bug?
[18:49:27 CET] <hojuruku> i think i'll go to git once i've finished my update and leave the preserved libraries alone ;)
[18:58:11 CET] <hojuruku> Note: 4 Generation Intel Core and earlier processors are not supported by Intel Media Server Studio 2017.  I knew qsc was shit
[18:58:20 CET] <hojuruku> https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/quicksync-video-ffmpeg-install-valid.pdf
[18:59:33 CET] <hojuruku> Prerequisites    A machine with QSV hardware, Haswell, Skylake or better. https://blogs.gentoo.org/lu_zero/2016/10/31/intel-mediasdk-mini-walkthrough/
[19:01:34 CET] <kevinn> Does anyone have any experience using libp2p to pack planar buffers?
[19:01:51 CET] <kevinn> I am having a bit of trouble
[19:02:02 CET] <hojuruku> https://software.intel.com/media-sdk haaha they dropped all desktop support - only for embedded linux now
[19:04:06 CET] <hojuruku> https://software.intel.com/en-us/intel-media-server-studio/details  yep haswell support dropped.
[19:10:03 CET] <hojuruku> hehe, vaapi encoded mp4's that bork gstreamer crash the hardware player too, but are rejected there in matroska streams. vaaapi plays fine on gstreamer in matroska containers. i can't make sense of this.
[19:11:25 CET] <hojuruku> sorry i mean the mkv's that play fine on gstreamer crash the hardware player. the mp4's are rejected outright by the hadware player are also rejected on the gstreamer qtmux plugin.
[19:11:57 CET] <hojuruku> mpv can't find anything wrong with the hardware encoded content.
[19:12:39 CET] <JEEB> if you're using software decoding then that goes through FFmpeg's decoding and that gives a whole lot of stuff leeway even if it's not perfect
[19:12:49 CET] <JEEB> have you tried hwdec with mpv?
[19:13:09 CET] <JEEB> (that also goes through FFmpeg usually but the ASICs tend to be more finicky)
[19:13:10 CET] <hojuruku> hwdec with mpv and software dec with mpv handles whatever vaapi throws at it
[19:15:17 CET] <hojuruku> what ffmpeg tool looks at the streams and qa's the files? ffprobe?
[20:02:28 CET] <ddubya> if a filter chain outputs lower framerate than input, what could be the problem. My inputs are 30fps and smooth but output is 25 and choppy
[20:03:19 CET] <JEEB> unless you do some fancy stuff changing the frame rate without making the clip longer/shorter means you're just taking pictures out
[20:03:43 CET] <JEEB> so yes, totally not surprising if a simple 25'ification of 30Hz content gets choppy :P
[20:04:07 CET] <ddubya> well the choppy is no surprise, but the frame rate change is
[20:04:25 CET] <JEEB> it's your filter chain...
[20:04:47 CET] <JEEB> you can look at what exactly it contains and look at why you're getting what you're getting
[20:06:32 CET] <ddubya> hmm all I have is "color" and "overlay"
[20:06:37 CET] <ddubya> maybe "color" has fps setting
[20:06:44 CET] <DHE> what's the framerate of the other overlay signal?
[20:06:55 CET] <DHE> is it 1 input, or 2?
[20:07:14 CET] <ddubya> they're both 30fps
[20:07:21 CET] <ddubya> it says on the opening input log
[20:07:43 CET] <DHE> yeah, color defaults to a 25fps virtual output
[20:46:36 CET] <trewq> folks, wanted to see if you had any thoughts on this question: https://stackoverflow.com/questions/48490516/ffmpeg-concatenated-file-does-not-play-as-expected
[20:54:29 CET] <specing> one does not simply concatenate video files
[20:56:29 CET] <durandal_1707>  meme
[20:59:40 CET] <specing> hi durandal_1707
[20:59:49 CET] <specing> I was not aware the elders were available
[21:00:10 CET] <specing> speaking of glueing video files together, is there an official or a good unofficial howto?
[21:00:59 CET] <specing> i.e. how to continue after ffmpeg got killed.... there was something saying that one has to glue before the last reference frame, but -ss and -to only accept time and not frames...
[21:01:22 CET] <Kuukunen-> ffmpeg used to concat files like you do, but then it took a fork to the knee
[21:01:43 CET] <durandal_1707> howto: avoid it at all cost
[21:02:11 CET] <specing> :(
[21:02:33 CET] <durandal_1707> for concat of frames at any position use concat filter
[21:04:00 CET] <ddubya> how would I figure out the scrolling speed rate of the showspectrum filter in samples/second ?
[21:05:29 CET] <ddubya> I think I mean pixels/second
[21:07:08 CET] <durandal_1707> ddubya: each frame gives new pixel width
[21:09:00 CET] <ddubya> how many samples in the frame? I guess its the width of the FFT ?
[21:09:57 CET] <durandal_1707> width of fft is given by height of video
[21:14:33 CET] <durandal_1707> so for 512 height its approx 44 frames per second for 44100 rate
[21:18:15 CET] <ddubya> got it! thanks!
[21:54:13 CET] <hihi> I know that I can save stream to file without decode and encode the stream ,   ffmpeg-i http://.... -v:c copy test.avi      how can I do that when I stream file with ffserver(I know that not recommended)
[21:54:36 CET] <hihi> when I stream static file I see that ffmpeg decode and encode it ,
[21:56:18 CET] <BtbN> you realize ffserver is dead? It was recently removed from ffmpeg. Don't use it.
[21:57:24 CET] <analogical> does anyone happen to know how do decompress wavpack on linux?
[21:57:45 CET] <hihi> BtbN>: I don't find another server that works with ffmpeg that can stream with lot of protocols
[21:57:49 CET] <sfan5> ffmpeg can do that ;)
[21:57:53 CET] <hihi> BtbN: do you know ?
[21:58:03 CET] <BtbN> most people use nginx-rtmp
[21:58:37 CET] <hihi> BtbN: I not see that nginx-rtmp can stream over rtsp and over mjpeg (http)
[21:59:08 CET] <BtbN> It can send out rtmp, hls and dash
[21:59:14 CET] <BtbN> which is pretty much all that's commonly used nowdays
[21:59:34 CET] <hihi> BtbN: i not get you freind
[21:59:59 CET] <hihi> i looking for server that can easily works with ffmpeg and can stream with lot of protocols that ffserver can
[22:00:36 CET] <BtbN> Why do you want a server for lots of protocols? That's not how this works. You get a server for one specific protocol.
[22:00:36 CET] <hihi> 1) mjpeg 2) rtsp udp 3)rtsp tcp 4) rtsp ovet http 5) rtsp multi cast    , I not see that nginx-rtmp can do that
[22:01:04 CET] <hihi> that why I love ffserver , that can stream with lot of protocols
[22:01:27 CET] <BtbN> It's also a big hack and unmaintaned for the better part of a decade
[22:02:59 CET] <hihi> BtbN:  I know that , but  I not find another server that can stream over lot of protocols
[22:03:18 CET] <BtbN> And why do you need a lot of different protocols? That's not a normal usecase.
[22:04:01 CET] <hihi> I have many client and each 1 want another protocols
[22:04:16 CET] <hihi> do you know ffserver and can you help me wit hthat problem?
[22:04:32 CET] <BtbN> I never used it. And nobody seems to have in a long time.
[22:04:39 CET] <BtbN> You're on your own if you insist on using it.
[22:05:01 CET] <klaxa> i looked at it in 2015 and was supposed to remove all the internal http usage by the pubilc api
[22:05:10 CET] <klaxa> but holy shit
[22:05:48 CET] <analogical> does anyone happen to know how do decompress wavpack on linux??
[22:06:18 CET] <JEEB> did you miss FFmpeg having a decoder?
[22:06:36 CET] <JEEB> not sure if the reference code can be compiled for *nix, probably can :P
[22:06:38 CET] <hihi> JEEB are you talking to me?
[22:07:55 CET] <tdr>  analogical /usr/bin/wvunpack ?
[22:11:20 CET] <analogical> tdr, doesn't exist on my Linux Mint system
[23:34:22 CET] <Jaxx_> hi, I dont like to be the one asking "when" question but is there any aproximate eta for ffmpeg binary for windows with VPX 1.7.0? thanks
[23:35:00 CET] <JEEB> there are no official binaries
[23:35:06 CET] <BtbN> we don't do binaries
[23:35:13 CET] <JEEB> some people do windows binarie, so you'd have to ask them
[23:37:14 CET] <Jaxx_> ah so ask zeranoe directly?
[23:37:29 CET] <JEEB> that would be one guy
[23:38:08 CET] <Jaxx_> kk thank you
[00:00:00 CET] --- Mon Jan 29 2018