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

[burek]

[01:42:51 CET] <FishPencil> What's the correct format to pipe raw YUV data?
[01:48:58 CET] <kepstin> FishPencil: use the 'rawvideo' format, but you also have to specify the pixel format, frame size, and framerate of course.
[01:49:10 CET] <JEEB> nut lets you have timestamps and audio if you want
[01:49:38 CET] <JEEB> of course you need to be able to read nut on the other side, too
[01:50:32 CET] <FishPencil> kepstin: If it's just going out I would think I don't specify that stuff?
[01:50:44 CET] <FishPencil> s/would/wouldn't
[01:50:51 CET] <kepstin> yeah, you just need to tell the reasing side that
[03:53:20 CET] <hiihiii> hello
[03:54:19 CET] <Diag> hiihiii:
[04:02:57 CET] <hiihiii> I'm sorry I lost my cnx
[04:03:27 CET] <hiihiii> did I post my question?
[04:06:50 CET] <Lunchbox> hey guys i'm trying to stream my desktop over lan to a media player on another computer but i'm getting a few errors
[04:06:51 CET] <Lunchbox> '[ffmpeg/video] h264: non-existing PPS 0 referenced'
[04:06:51 CET] <hiihiii> can motion detection duplicate regions of frames? i.e. can it lead to an object, which should have moved from point A to point B, still be present at point A for an additional frame due to cpu/memory factors
[04:06:51 CET] <Lunchbox> '[ffmpeg/video] h264: decode_slice_header error'
[04:06:54 CET] <Lunchbox> ' [ffmpeg/video] h264: no frame!'
[04:09:28 CET] <hiihiii> try flv, header errors are probably mp4
[04:09:39 CET] <geuis> Wondering if someone might have some insight. I have two sets of images, layer-%d.png and layer-%d.svg. The intention is to overlay the svg files over the pngs for the same duration
[04:09:59 CET] <geuis> This is a simplified version of what I thought might work "ffmpeg -y -framerate 1 -i layer-%d.png -i layer-%d.svg -filter_complex "[0:v]fps=30[base];[1:v]fps=30[date];[date][base]overlay=(0):(0)" -preset ultrafast -movflags +faststart -vcodec libx264 -crf 23 -pix_fmt yuv420p out.mp4"
[04:10:56 CET] <hiihiii> [base][date]overlay
[04:11:10 CET] <geuis> thought they had to be reversed
[04:12:07 CET] <geuis> hah awesome it works. thanks man
[04:31:17 CET] <Lunchbox> hiihiii it says unable to recognize file format using flv
[04:32:00 CET] <geuis> hmm, so I have multiple overlays throughout the video but the old ones stick around and stack up. any way to clear them?
[08:35:28 CET] <ovi_> hello
[08:37:01 CET] <ovi_> I used the following command https://pastebin.com/vvCKv83t
[08:37:33 CET] <ovi_> but now I get "cat: Argument list too long"
[08:38:01 CET] <ovi_> because I have over 20 000 file in that pattern
[08:38:25 CET] <ovi_> it is possible to specify the input without using the image2pipe?
[09:45:27 CET] <FishPencil> What data type is the YUV information when dumped with -c:v rawvideo? I'm just trying to read the YUV info in something else, but buff[0] (which should be Y), doesn't look right. I'm using uint8_t right now.
[09:48:54 CET] <JEEB> if you need it API-wise I would jus utilize the API, which gives you AVFrames straight off the bat which says which pix_fmt it is, too :P
[09:49:09 CET] <JEEB> see examples under docs
[09:49:44 CET] <FishPencil> I'm trying to read the yuv file outside of FFmpeg
[09:50:45 CET] <JEEB> well yes
[09:50:55 CET] <JEEB> if you have buffers and stuff I definitely recommend you start using the API
[09:51:20 CET] <JEEB> since it lacks a lot of the complications you have with "just trying to get the decoded samples out"
[09:51:42 CET] <JEEB> otherwise I recommend you add support for either NUT or Y4M to your application
[09:51:58 CET] <JEEB> which contain the pixel format information in addition to other stuff, so you can pipe that to your thing :P
[09:52:40 CET] <FishPencil> Getting the YUV to decode is an important step even in that..
[09:53:28 CET] <JEEB> if you know from the stuff you're pushing in WHAT it is, that helps :P
[09:53:42 CET] <JEEB> because "rawvideo" in ffmpeg.c is your common weasel word for whatever came out of your filter chain or decoder
[09:53:45 CET] <JEEB> capisci?
[11:21:35 CET] <hojuruku>  Strange problem with ffmpeg git mesa git and libva (latest sable in gentoo)....
[11:21:50 CET] <hojuruku> how to replicate: ffmpeg-git -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -ss 120 -t 120 -i  xyz.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 vaapitest4.mp4
[11:22:02 CET] <hojuruku> the mp4 is not playable by gstreamer but mpv can handle it fine. I use a mkv container it works in gstreamer, but hardware players still can't handle the h264 data in mkv. Amd's can't use bframes so I have to use the baseline constrained profile
[11:22:17 CET] <hojuruku> this is what gstreamer complains with: qtdemux qtdemux.c:9719:qtdemux_parse_trak:<qtdemux0> Track shorter than 20% (5761024/48000 vs. 5834998/1000) of the stream found, assuming preview image or something; skipping track
[11:22:50 CET] <hojuruku> both libx264 and vaapi encoded streams report the same in ffprobe except for the bitrate 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)
[11:23:10 CET] <JEEB> you can look at the timestamps of the mp4 file with, say, L-SMASH's tools
[11:23:18 CET] <JEEB> it could be that VAAPI is just pushing out borked timestamps
[11:23:28 CET] <JEEB> although without bframes the timestamps should be monotonically rising
[11:57:17 CET] <hojuruku> that looks like the plan, i'll do that, but the question is where does the bug go? libva? mesa who do the vaapi driver for our hardware of ffmpeg?
[11:57:49 CET] <hojuruku> JEEB: it seems that the framerate stays at zero as it revs up and the bitrate starts out low and it goalseeks to the desired bitrate.
[11:58:12 CET] <hojuruku> the libomxil-bellago driver doesn't take bitrate only crf settings which explains why it works in gstreamer.
[12:00:24 CET] <jkqxz> Does it work if you overwrite the timestamps with something fixed?  (Something like "-r 30" as an input option.)
[12:02:21 CET] <jkqxz> VAAPI does not work sensibly with VFR at all (the API has no concept of timestamps), and your 48k tbc there suggests a VFR stream.
[12:20:21 CET] <JEEB> hojuruku: where the bug goes depends on what is actually giving out timestamps IF AND ONLY IF (IFF) the timestamps from the vaapi encoder are weird
[12:21:54 CET] <bigeast> hi, I want to compile ffmpeg with all other tools disabled, i.e. ./configure --disable-all --enable-xxx. But the command line file is disabled too, is there any configure option like --enable-programs ?
[12:44:28 CET] <sfan5> bigeast: not sure if --enable-programs exists, but --enable-ffmpeg should work
[12:45:11 CET] <sfan5> but if you just want an "ffmpeg" binary as result i'd configure with --disable-shared --disable-{ffplay,ffprobe}
[13:13:55 CET] <rk__> Hi, I am using libavformat to mux a VP8 encoded rtp stream into a webm file. I need a small help regarding how to set pts and dts values in the AVPacket, using rtpTimeStamp. Do I need to get NTP timestamp from RTCP and set that as pts or is there any other way ?
[13:15:56 CET] <mux> im using libavformat to rk__ a vp8 encoded rtp stream
[13:35:36 CET] <dradakovic> Guys, i compiled the ffmpeg according to the guide and it works ok. I would now like to install the additional library "libswresample". Any idea on how to do that?
[13:37:05 CET] <sfan5> ffmpeg comes with libswresample
[13:38:08 CET] <JEEB> dradakovic: unless you disabled building/installation of the library in your configuration parameters, it should have been installed
[13:38:27 CET] <JEEB> PKG_CONFIG_PATH=/your/ffmpeg/prefix/lib/pkgconfig pkg-config --libs --cflags libswresample
[13:38:32 CET] <JEEB> is a good way to test
[13:38:50 CET] <JEEB> the prefix being what you passed to the configure script as --prefix (/usr/local by default)
[13:52:20 CET] <dradakovic> Thank you. I will try it right away
[13:55:02 CET] <dradakovic> No package 'libswresample' found
[13:55:31 CET] <dradakovic> I followed the guide exactly as it is on the compiling guide web page
[14:00:51 CET] <Nacht> Question. I'm not super sure I'm understanding the memory in work here. Why is this wrong ? https://play.golang.org/p/oiWDlGwsob_s
[14:02:19 CET] <Nacht> Isn't P an alias for b[i:i+188], and when I say p[0] = nil it would just change b ?
[14:07:00 CET] Last message repeated 1 time(s).
[14:17:15 CET] <dradakovic> So it seems like i dont have libswresamble installed as i get:
[14:17:17 CET] <dradakovic> Package libswresample was not found in the pkg-config search path.
[14:17:17 CET] <dradakovic> Perhaps you should add the directory containing `libswresample.pc'
[14:17:17 CET] <dradakovic> to the PKG_CONFIG_PATH environment variable
[14:17:17 CET] <dradakovic> No package 'libswresample' found
[14:17:36 CET] <furq> Nacht: you don't need the & and also this is the wrong channel
[14:18:41 CET] <Nacht> Oh snap, wc idd :D
[14:18:51 CET] <Nacht> cheers furq :)
[14:19:38 CET] <furq> https://play.golang.org/p/XfKj_Lnw3kH
[14:22:31 CET] <c_14> dradakovic: which guide?
[14:22:57 CET] <dradakovic> exactly this one: https://trac.ffmpeg.org/wiki/CompilationGuide/Centos
[14:24:55 CET] <c_14> PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" pkg-config --libs --cflags libavformat <- what does that return?
[14:35:17 CET] <dradakovic> -I/root/ffmpeg_build/include  -pthread -L/root/ffmpeg_build/lib -lavformat -lavcodec -lvpx -lz -lfdk-aac -lmp3lame -lopus -lvorbisenc -lvorbis -logg -lx264 -lpthread -lx265 -lstdc++ -lrt -lswresample -lavutil -lm -ldl
[14:35:20 CET] <dradakovic> This
[14:35:31 CET] <c_14> and if you replace libavformat with libswresample it fails?
[14:35:35 CET] <c_14> do you still have your config.log?
[14:36:43 CET] <dradakovic> it didnt fail
[14:36:44 CET] <dradakovic> -I/root/ffmpeg_build/include  -pthread -L/root/ffmpeg_build/lib -lswresample -lavutil -lm -ldl
[14:37:23 CET] <dradakovic> Any clue where i would find config.log
[14:40:19 CET] <dradakovic> Seems like there is a libswresample.pc in the pkgconfig folder
[14:40:41 CET] <dradakovic> did your command already enable it? Or do i have to do something else
[14:44:03 CET] <c_14> nah, now you just have to pass PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" to whatever you have that needs libswresample
[14:44:25 CET] <c_14> (if it uses pkg-config)
[14:44:33 CET] <c_14> otherwise you'll have to pass the CFLAGS/LDFLAGS manually
[14:45:41 CET] <dradakovic> Ok c_14. I will figure it out how to do it. Thank you for your time
[15:02:45 CET] <glumanda> How do I prevent package loss? When I try to watch an rtsp stream with vlc it runs a lot smoother than with ffmpeg.
[15:05:25 CET] <pmjdebruijn> presumably that's just buffersize related?
[15:05:49 CET] <glumanda> pmjdebruijn: i tried with -bufsize 6000k according to the streaming guide, but it won't help
[15:05:58 CET] <glumanda> i dont know what vlc does different
[15:06:09 CET] <glumanda> it has set a network-cache to 1000ms
[15:06:20 CET] <pmjdebruijn> i'm not sure how much focus ffmpeg has had as a client
[15:06:44 CET] <glumanda> i'm trying to stream an rtsp stream to an rtmp server
[15:07:20 CET] <bigeast> sfan5: thanks for your advice! What I want is a ffmpeg executable with only H.264 decoder enabled, without encoder, other decoder or parser or muxers(which I don't know what they are).
[15:07:56 CET] <sfan5> what container formats are you expecting to handle?
[15:08:23 CET] <bigeast> I tried --disable-all --enable-ffmpeg, the configure can generate a Makefile, but still no ffmpeg executable files after make
[15:09:11 CET] <DHE> ffmpeg has additional dependencies. --disable-all really does disable everything.
[15:09:22 CET] <bigeast> It's strange to me that I find no "enable-ffmpeg" string in the configure file, but it doesn't report it as an error.
[15:09:41 CET] <bigeast> sfan5: raw H.264 stream
[15:10:05 CET] <DHE> that still requires a parser or demuxer to parse the elementary stream into the individual frames, doesn't it?
[15:10:08 CET] <furq> bigeast: --disable-programs --enable-ffmpeg
[15:10:18 CET] <furq> maybe, idk if that actually works
[15:10:26 CET] <furq> it's more likely than --disable-all though
[15:10:46 CET] <c_14> bigeast: you have to enable all the libs and other things
[15:10:56 CET] <c_14> at least libavformat, libavcodec, libavutil
[15:11:02 CET] <c_14> and the h264 decoder/parser
[15:11:07 CET] <saml> i should learn about bitrates
[15:11:18 CET] <c_14> and a demuxer of some sort
[15:11:18 CET] <DHE> you probably want --disable-everything instead which targets individual codecs etc rather than the libraries as a whole
[15:11:20 CET] <saml> everyday learnin
[15:11:54 CET] <sfan5> something like --disable-shared --disable-ff{play,probe} --disable-{encoders,decoders,hwaccels,demuxers,parsers,bsfs} --enable-decoder=h264 --enable-parser=h264 --enable-demuxer=h264
[15:12:10 CET] <furq> you'll need --enable-protocol=file
[15:12:15 CET] <DHE> yeah but.. then what? ffmpeg is a converter and it can't output anything. literally.
[15:12:19 CET] <furq> or whatever protocol you want to handle the stream on
[15:12:28 CET] <furq> and yeah you'll need a muxer and an encoder
[15:12:29 CET] <sfan5> yeah you probably want at least --enable-encoder=rawvideo
[15:12:36 CET] <DHE> you gotta provide some kind of output format, muxer and codec even if it's the dumb ones
[15:13:07 CET] <furq> and ofc you'll need the protocol for the output as well as for the input
[15:13:09 CET] <DHE> I'm also going to recommend --enable-protocol=file  or else ffmpeg isn't going to be able to do basic IO
[15:13:14 CET] <DHE> yeah
[15:13:37 CET] <bigeast> YUV out is fine.
[15:13:41 CET] <furq> bigeast: basically be prepared to build this a bunch of times when ffmpeg tells you it can't do something
[15:14:45 CET] <furq> you will at the bare minimum need a decoder, parser, demuxer, muxer, encoder, and protocol (or more than one of each)
[15:16:46 CET] <saml> why do you want to build ffmpeg like that bigeast ? just curious
[15:17:07 CET] <bigeast> furq: so if I --disable-all, and then enable one option for these items, then --enable--fmpeg will generate ffmpeg executable?
[15:17:15 CET] <saml> does that make it faster and more web scale in dockerized serverless?
[15:17:18 CET] <sfan5> --disable-everything, not --disable-all
[15:17:18 CET] <furq> bigeast: probably not
[15:17:24 CET] <furq> yeah, that
[15:18:27 CET] <furq> --disable-components might be a better name than --disable-everything
[15:19:00 CET] <sfan5> having two options with synonymous names but different effect is indeed confusing
[15:20:14 CET] <saml> --start-from-scratch
[15:20:19 CET] <bigeast> saml: At first, I want a minmal libavcodec.a. Then I decide to make some change to the H.264 decoder, and compare the performance difference.
[15:20:41 CET] <saml> oh you're building your own statically linked program?
[15:20:51 CET] <saml> would it be open source?
[15:21:03 CET] <sfan5> you don't need a minimal libavcodec.a to measure performance
[15:21:22 CET] <furq> i assume this is to make it build as quickly as possible
[15:21:31 CET] <bigeast> furq: yes
[15:21:32 CET] <saml> ah that makes sense
[15:21:44 CET] <sfan5> well make will only rebuild what's necessary
[15:21:47 CET] <furq> yeah
[15:21:50 CET] <sfan5> unless you do a clean build every time
[15:22:17 CET] <DHE> I do something similar, but more like "--disable-encoders --enable-encoder=libx26?,mpeg*,aac,..." rather than throwing around --disable-everything.
[15:22:44 CET] <DHE> it's better to err on the safe side. hopefully ffmpeg isn't getting built that often compared to your own app
[15:23:11 CET] <saml> does netflix have the best video encoding program?
[15:23:22 CET] <furq> they're probably just using ffmpeg
[15:23:25 CET] <furq> youtube definitely are
[15:23:45 CET] <saml> they don't make custom modification? like what bigeast is doing
[15:24:03 CET] <saml> i mean, modifying codec source code and stuff
[15:24:32 CET] <DHE> we don't know the details. the only obvious signs are the encoder signatures in the metadata
[15:24:51 CET] <furq> yeah we wouldn't know that unless they contributed source back
[15:24:55 CET] <saml> ffprobe shows me that metadata?
[15:24:56 CET] <sfan5> given how good x264, netflix are probably using it with modifications
[15:25:00 CET] <furq> which they're under no obligation to if it's internal use only
[15:25:09 CET] <sfan5> ffprobe won't show that metadata, e.g. mediainfo can
[15:25:18 CET] <furq> youtube strips that metadata so netflix probably does as well
[15:26:29 CET] <saml> Writing application                      : google
[15:29:11 CET] <saml> what's good documentation about bitrate?  https://trac.ffmpeg.org/wiki/Encode/H.264  ?
[15:29:25 CET] <furq> that's a vague topic
[15:29:44 CET] <furq> if you mean "what bitrate is good" then that depends on too many factors to have an answer you could write down
[15:29:47 CET] <saml> like, i have no idea what bit rate means.
[15:30:06 CET] <furq> it's the size of the video stream in bits divided by the number of seconds
[15:30:13 CET] <saml> ISP's bitrate
[15:30:45 CET] <saml> ah i see. do you calculate bitrate based on encoded bits per second? or some raw pixel data bits per sec?
[15:31:19 CET] <furq> encoded
[15:31:21 CET] <saml> 1Mbps could mean a lot of frames if it was 1Mbits of very well compressed data
[15:31:30 CET] <furq> it's literally just the size of the output stream
[15:32:02 CET] <saml> so filesize/file_duration
[15:32:10 CET] <furq> right
[15:32:14 CET] <bigeast> I'm curious about how --enable-small will affect the speed, and in the configure file I see what it does is replace the default -O3 flag with -Os. I want to test the performance between the executable build with or without -Os when decoding H.264 stream. What's more, I'm not sure whether other options will affect on this so I want disable all of them.
[15:32:28 CET] <saml> i guess container and codec has little impact on bitrate
[15:33:28 CET] <saml> i wonder if ffmpeg or x264 source code has test suite to measure such performance
[15:33:46 CET] <saml> then you can create a quick feed back loop: modify code, build, run the test
[15:33:57 CET] <bigeast> saml: me too
[15:34:13 CET] <saml> or if you build your own, open source it so i can get it for free :P
[15:34:50 CET] <DHE> bigeast: --enable-small also strips out a lot of the ffmpeg library text message. for example "ffmpeg -h" will be a lot less useful
[15:35:29 CET] <bigeast> what I do is very simple... I guess it's not worth to open soruce it :O
[15:35:32 CET] <furq> bigeast: probably --disable-optimizations
[15:35:45 CET] <furq> that will obviously make the code itself run slower though
[15:35:55 CET] <saml> performace here is encoding speed? how would you measure encoding quality? psnr?
[15:36:00 CET] <furq> and also if you're trying to do speed comparisons of your code then it's not much good to run it with -O0
[15:36:16 CET] <DHE> would that also disable assembly routines?
[15:36:17 CET] <bigeast> saml: I want to test decoding speed.
[15:36:25 CET] <furq> it just says "disable compiler optimizations"
[15:37:18 CET] <bigeast> saml: encoding quality is measure by BD-bitrate, in MPEG.
[15:37:55 CET] <saml> shouldn't you measure decoding quality as you modify decoder?  if your decoder just decodes everything to 0, it'll be fast
[15:38:08 CET] <saml> i guess you can use psnr here indeed :P
[15:38:30 CET] <bigeast> DHE: probably not, -Os just disable some align optmization, you can see the gcc man
[15:38:45 CET] <saml> like, get a standard decoder decode.  and that decoded gop is your reference
[15:39:09 CET] <furq> DHE: looks like it just builds with -O1
[15:39:19 CET] <sfan5> how is psnr useful for performance measuring?
[15:39:46 CET] <bigeast> saml: the decode result is for sure, with no post-processing. so it's only speed that maters.
[15:39:51 CET] <DHE> sfan5: well, it's not. but if changes in optimizations produce different image quality results then it should be measurable by PSNR
[15:40:33 CET] <sfan5> true
[15:40:33 CET] <bigeast> compiler flag only affect the speed I guess?
[15:41:36 CET] <furq> actually on gcc it just builds it without -O at all
[15:41:48 CET] <saml> ah if you're not changing source code but only fiddling with compilers and their flags
[15:42:20 CET] <saml> you can also try different compilers to see if they produces more performant decoder
[15:42:56 CET] <bigeast> gcc under macOS is just an alias of clang...
[15:43:16 CET] <saml> https://trac.ffmpeg.org/wiki/CompilationGuide#PerformanceTips  i'm not sure if this is relevant
[15:43:32 CET] <bigeast> and it's may be trick to install the GNU gcc on mac I assume
[15:43:41 CET] <sfan5> you can also try icc
[15:43:56 CET] <saml> is your producing running ffmpeg on mac?
[15:44:01 CET] <saml> production*
[15:44:20 CET] <DHE> new versions of gcc support "-Og" for optimizations that don't affect ability to debug... that worth using maybe?
[15:44:23 CET] <bigeast> or tcc which is writen by the same author with ffmpeg :D
[15:45:39 CET] <saml> just curious, why do you need to optimize decoder?  so far i haven't had to optimize ffmpeg binary. i just use whatever OS provides
[15:46:28 CET] <saml> it'd be nice if by changing ffmpeg binary, i get to save N% of processing time
[15:48:12 CET] <pmjdebruijn> bigeast: I don't think tcc is viable for non-trivial projects
[15:48:41 CET] <saml> if I use -r 30 as output option on a 60fps video input,  is there equivalent filter? I tried -filter_complex "fps=fps=30"  but it doesn't seem to be the same.  and framerate=fps=30  is not the same either.
[15:49:19 CET] <bigeast> I want the libavcodc to be small, then I found --enable-small can do that, but I want to make sure that the performance is not too much slower.
[15:49:39 CET] <pmjdebruijn> why do you want it to be small?
[15:49:56 CET] <Guest94689> hi! is it possible to use ffmpeg to stream from a dvr to youtube via raspberry pi 3 (dvr-->rp3-->yt)?
[15:50:29 CET] <Guest94689> dvr and rpi3 connected in the same network
[15:50:42 CET] <sfan5> if you don't need to transcode, probably
[15:50:45 CET] <sfan5> if you need to, definitely not
[15:50:48 CET] <sfan5> the rpi is way too slow for that
[15:50:52 CET] <pmjdebruijn> Guest94689: this is literally the first google result https://gist.github.com/olasd/9841772
[15:51:06 CET] <pmjdebruijn> aside from the transcoding issue
[15:51:06 CET] <bigeast> pmjdebruijn: ehh, becauce it's too big?
[15:51:12 CET] <pmjdebruijn> bigeast: too big for what?
[15:51:26 CET] <pmjdebruijn> bigeast: are you on embedded hardware?
[15:51:35 CET] <Guest94689> i see
[15:53:21 CET] <Guest94689> pmjdebruijn:i was looking to that link prior to enter. thank you anyway
[15:53:48 CET] <pmjdebruijn> but the transcoding point is rather valid :)
[15:54:33 CET] <pmjdebruijn> bigeast: ?
[15:54:37 CET] <furq> ffmpeg supports the pi's hardware encoder now
[15:54:43 CET] <furq> admittedly that thing sucks
[15:54:57 CET] <furq> so transcoding is possible, it'll just be bad
[15:54:59 CET] <pmjdebruijn> sucks as in it only supports a subset of the h264 spec?
[15:55:10 CET] <pmjdebruijn> or sucks as in the result are poor even consider the previous point?
[15:55:12 CET] <furq> sucks as in it's terrible quality
[15:55:21 CET] <bigeast> pmjdebruijn: yes, say I'm on android.
[15:55:50 CET] <pmjdebruijn> bigeast: most android devices aren't remotely resource constrained enough for you to worry about ffmpeg's size, unless it's a bottom of the barrel device :)
[15:56:55 CET] <pmjdebruijn> the point i'm trying to make is, fiddling with options few people use in real life, might get you more grief than you bargained for :)
[15:57:05 CET] <pmjdebruijn> that's just general advice, i'm not an ffmpeg expert :)
[15:57:52 CET] <bigeast> it make sense for me, thanks~
[15:58:48 CET] <pmjdebruijn> bigeast: enable-small practical result may also depend a bit on the particular CPU
[15:59:17 CET] <pmjdebruijn> bigeast: the best way to reduce ffmpeg's size is to not build it with support for codecs you won't use
[15:59:22 CET] <pmjdebruijn> at least that's my first thought
[15:59:55 CET] Action: pmjdebruijn isn't sure what autoenabled these days
[16:01:33 CET] <pmjdebruijn> ldd will tell you where the resulting binary links too (unless you're building a static binary of course)
[16:02:43 CET] <Guest94689> since I'm not familiar with streaming or ffmpeg I'm assumig that sending a rstp with ffmpeg will probably kill rp3
[16:03:37 CET] <sfan5> not necessarily
[16:03:58 CET] <sfan5> you're just receiving some data, doing some maths and sending it somewhere else
[16:04:18 CET] <sfan5> well that's a little vague
[16:04:29 CET] <sfan5> my point is (de-)muxing a video stream is not resource intensiver
[16:04:33 CET] <sfan5> s/r$//
[16:05:34 CET] <bigeast> pmjdebruijn: yes, that's why I disable-all at the very first. Even disable-all, enable-small can still make the library smaller, I want to know how it'll affect the speed.
[16:06:08 CET] <pmjdebruijn> bigeast: just encode some video samples
[16:06:51 CET] <pmjdebruijn> bigeast: ffmpeg -benchmark -i input -c:v libx264 -f null -
[16:06:52 CET] <pmjdebruijn> or whatever
[16:07:29 CET] <pmjdebruijn> but does enable-small make such a big difference?
[16:09:01 CET] <bigeast> Since there isn't a simple configure option to enable-ffmpeg after disable-all, I guess I'll disable some, and leave others there, and hope they are irrelevant.
[16:09:05 CET] <pmjdebruijn> oh darn, avcodec is 12M
[16:09:18 CET] <bigeast> pmjdebruijn: that's what I want to find out.
[16:09:25 CET] <sfan5> you shouldn't use --disable-all
[16:09:31 CET] <sfan5> the result will be a non-functional ffmpeg
[16:09:35 CET] <sfan5> use --disable-everything instead
[16:10:08 CET] <bigeast> on macOS, libavcodec.a s 15M
[16:10:24 CET] <JEEB> the size of the libraries heavily depends on how much one has enabled
[16:10:30 CET] <Guest94689> sfan5: what I want is just sending rstp://user:pass@ipaddress/cam/<params> to youtube server. other parameters that i want to send is cbr=3000, x264 if needed and audio if needed  ,
[16:10:38 CET] <JEEB> and if the dependencies are static or shared for it (like libx264 if you link against it)
[16:12:06 CET] <sfan5> you want to transcode then?
[16:12:40 CET] <sfan5> on the pi your only option is the h264 hardware encoder, no chance for x264
[16:12:50 CET] <saml> wow libvmaf is so slow
[16:13:12 CET] <JEEB> saml: I don't think anyone optimized it and the whole library was still heavily Work In Progress last I checked
[16:13:17 CET] <bigeast> sfan5: disable-everything is very close to what I need!
[16:15:05 CET] <Guest94689> sfan5: ok.
[16:16:37 CET] <Guest94689> sfan5: i followed this tutorial https://www.jeffreythompson.org/blog/2014/11/13/installing-ffmpeg-for-raspberry-pi/
[16:17:52 CET] <sfan5> that uses x264 which is way too slow on the pi
[16:20:03 CET] <bigeast> ./configure with default option generate a 142M libavcodec.a, while disable-everything then enable only h264 decoder reduce it to 16M, and with an executable.
[16:20:23 CET] <bigeast> on Ubuntu x64 machine
[16:20:39 CET] <sfan5> that's due to debug info
[16:20:43 CET] <sfan5> --disable-debug
[16:20:47 CET] <Guest94689> sfan5: ooo, i see....
[16:22:09 CET] <Guest94689> sfan5: can you please, if possible, with an command example ?
[16:23:56 CET] <sfan5> https://www.raspberrypi.org/forums/viewtopic.php?t=199775 try this guide
[16:23:59 CET] <sfan5> you can skip the steps for mpv
[16:25:26 CET] <Guest94689> sfan5: thank you
[16:26:38 CET] <bigeast> sfan5: you'r right. --disable-debug make it to 16M too! Then there's no meaning in disable-everything? I'm a little fuzzy
[16:27:05 CET] <sfan5> uh well
[16:27:15 CET] <sfan5> disable-everything should make libavcodec much, much smaller
[16:27:25 CET] <sfan5> since it doesn't actually have any functionality anymore
[16:27:49 CET] <bigeast> how come it enable all the codec and result the same with disable-everything!
[16:28:22 CET] <sfan5> ¯\_(Ä)_/¯
[16:37:39 CET] <DHE> bigeast: you can also run: "strip --strip-debug" on your binaries to remove debug symbols.
[16:37:53 CET] <DHE> or "strip --strip-unneeded" if you're not doing any testing at all
[17:20:42 CET] <saml> is 60 psnr max?
[17:21:04 CET] <alexpigment> i want to say "inf" is max
[17:22:21 CET] <saml> ffmpeg -i a.mp4 -i a.mp4 -filter_complex 'libvmaf=psnr=1:log_path=vmaf.log' -f null - # gives psnr of 60
[17:22:24 CET] <saml> same file
[17:22:35 CET] <saml> i guess libvmaf is yolo
[17:23:08 CET] <alexpigment> i've never used libvmaf tbh
[17:23:31 CET] <alexpigment> anyway, i remember numbers in the high 40s, so it would make sense if 60 is the effective max
[17:41:32 CET] <FishPencil> Given argv[1] is i.yuv and was created with 'ffmpeg -i i.png -pix_fmt yuv420p i.yuv', shouldn't this correctly display the first Y value: uint8_t y; std::ifstream i(argv[1], std::ios::binary); i >> y; std::cout << +y << std::endl;
[17:44:47 CET] <kepstin> FishPencil: assuming that the "i >> y" actually reads a single byte, then I'd assume so yeah.
[17:45:53 CET] Action: kepstin doesn't know enough about the C++ type system to say whether or not that is correct.
[17:47:17 CET] <FishPencil> kepstin: So the first pixel is R: 226, G: 137, B: 125, which I believe should be 162 Y, but it's showing as 155
[17:48:16 CET] <sfan5> since you are dealing with 4:2:0 YUV, I wouldn't just expect this to be equal
[17:48:17 CET] <kepstin> are you accounting for the conversion to tv range (Y=16 is black, y=239 is white)
[17:48:33 CET] <sfan5> oh nevermind ignore me
[17:52:19 CET] <kepstin> If I convert 162 in pc range to tv range, i get ~157, which seems pretty close (particularly when you account for chroma subsampling, etc.)
[17:56:54 CET] <FishPencil> kepstin: I think that's it
[17:58:18 CET] <FishPencil> kepstin: How is that conversion done?
[17:59:36 CET] <kepstin> simple scaling. I gave you the values above ^^
[18:05:43 CET] <furq> 155 should be correct
[18:06:12 CET] <furq> 162 * 220/256 + 16 = 155.2
[18:06:57 CET] <kepstin> hmm, I was off by a bit. Did I get the wrong value for the white point?
[18:07:16 CET] <furq> limited is 16-235
[18:07:27 CET] <kepstin> ah, yeah, I did. my fault :)
[18:07:50 CET] <furq> i used 224 instead of 220 at first so we probably made the same mistake
[18:57:10 CET] <ChocolateArmpits> Has anyone encoded any av1 content yet? How well does cpu-used=0 compare to cpu-used=8 ? The processing speed drops by at least 40 times so I'm still a day away from any results lol.
[19:20:48 CET] <SortaCore> is there any point in passing dxva2 to libx264
[19:21:09 CET] <SortaCore> via hw_device_ctx
[19:21:27 CET] <SortaCore> or does libx264 just ignore that
[19:22:24 CET] <sfan5> you could look at libavcodec/libx264.c and check yourself
[19:23:33 CET] <SortaCore> yea, it's like instead of trying to find the book in the library, asking the librarians >.>
[19:25:02 CET] <SortaCore> ok, no sign of hw_device_ctx or dxva2 in that file
[19:25:11 CET] <SortaCore> so does that mean nothing, or does it mean I have the wrong file?
[19:26:59 CET] <sfan5> former
[19:27:55 CET] <kepstin> SortaCore: x264 is a completely software/cpu encoding library in normal usage
[19:33:07 CET] <saml> are there different interlacing method?
[19:35:26 CET] <kepstin> saml: there lots of different *de*interlacing methods
[19:36:00 CET] <ChocolateArmpits> saml, can you be more specific ? Generally you either have a odd lines or even lines as the first field. You can store them as a whole frame or each field as a separate frame.
[19:36:23 CET] <kepstin> interlaced content is can be either produced natively from a camera that does interlaced capture, or via a telecine process to convert from progressive footage
[19:36:28 CET] <tyng> does libavcodec supports the dts:x extension?
[19:36:59 CET] <tyng> https://comfy.moe/limnty.dts
[19:37:25 CET] <saml> hrm let me read up on those. i was wondering if two videos of same size, frame rate.. but one is interlaced , it would generate different psnr.  so I wanted to use ffmpeg to generate a video with interlacing on
[19:38:08 CET] <kepstin> saml: interlacing vs. deinterlaced changes the image data so obviously the psnr will be different, yes.
[19:38:48 CET] <kepstin> you can't recover the original interlaced video from deinterlaced version (except in the telecine case), and deinterlacing the other video means you're just comparing deinterlacers, so...
[19:38:49 CET] <ChocolateArmpits> saml, depends on the codec used. Some may store both fields as a single frame with a flag checked but with no temporal distinction
[19:39:05 CET] <kepstin> psnr between interlaced and deinterlaced video is basically even more meaningless than usual.
[19:39:19 CET] <sfan5> tyng: that file doesn't play here so I'd say no
[19:39:56 CET] <saml> i see
[19:40:01 CET] <saml> on man psnr just die
[19:40:09 CET] <saml> https://gist.github.com/saml/1e512d7b9a74a62e9c5e20d661dfc6a0
[19:40:20 CET] <ChocolateArmpits> Generally storing both fields as a frame will require higher bitrate to preserve comb edges
[19:40:53 CET] <kepstin> saml: and again, you shouldn't be using the 'framerate' filter to convert - the blending it does generally looks bad *and* lowers psnr
[19:41:45 CET] <saml> hrm i see.  i guess -filter fps  is same as -r then?
[19:41:47 CET] Action: saml tries
[19:42:26 CET] <kepstin> saml: of course, neither the framerate nor fps filter guarantees that the frames will line up with the other video you have
[19:42:37 CET] <kepstin> which means of course that the psnr is still useless
[19:43:00 CET] <saml> i wish psnr just errors out if two input videos are different in anything other than bit rate
[19:43:29 CET] <saml> then i can just report. nope, you can't use psnr for that
[19:44:28 CET] <tyng> sfan5 ffprobe detects it as dts-hd ma profile but is also contains a dts:x extensions as detected by libmediainfo
[19:44:39 CET] <tyng> compare "ffprobe -of json -show_streams -f dts https://comfy.moe/limnty.dts" and "mediainfo --Language=raw https://comfy.moe/limnty.dts"
[19:44:40 CET] <saml> how do you change frame rate of 120fps slow mo  (gopro)  to 30fps but still maintain playback speed? when I use -r 30,  video seems to play faster
[19:45:29 CET] <kepstin> saml: the problem is probably that your player can't play 120fps correctly
[19:46:02 CET] <saml> ah that's true. mplayer did complain my system is too slow
[19:47:06 CET] <saml> PSNR calculation is only meaningful when main and ref have same spec other than bit rate.  (is this true?)
[19:47:28 CET] <furq> i feel like we've said that a bunch of times
[19:47:49 CET] <sfan5> tyng: ah i was missing the -f dts, if ffmpeg doesn't detect the DTS:X content it likely doesn't support it
[19:48:27 CET] <kepstin> saml: psnr calculation doesn't correspond to visual quality as perceived by humans. In some circumstances it can be used to make relative comparsions between the *same* video encoded with slightly different settings.
[19:49:17 CET] <saml> do you have example of those settings that are allowed?  obviously i can't use -r fps
[19:49:17 CET] <SortaCore> is it correct that nvenc is slower with d3d11 hw context than dxva2?
[19:49:19 CET] <kepstin> saml: this is why netflix is working on stuff like vmaf, which *does* correspond to visual quality as perceived by humans - at least better than anything else we have so far.
[19:49:33 CET] <kepstin> saml: changing fps means it's not the same video being encoded.
[19:49:42 CET] <furq> maybe it wasn't you who was asking this before, but it's difficult to get meaningful psnr results from videos that are different sizes or framerates
[19:49:52 CET] <furq> especially framerates
[19:50:09 CET] <saml> it was all me. psnr stuff
[19:51:24 CET] <kepstin> psnr does not account for the perceptual quality loss from a lower framerate having lower temporal resolution - indeed, I don't know of any metrics which do account for that.
[19:51:26 CET] <saml> so, only allowed parameters for psnr testing is  -maxrate -bufsize -b:v  -crf ?
[19:51:33 CET] <saml> if any other parameter is used, psnr is useless
[19:51:44 CET] <furq> change whatever you want other than the rate and size
[19:52:06 CET] <furq> remember these metrics are only useful at all to compare a source and reference
[19:52:18 CET] <furq> comparing two different encodes doesn't tell you anything
[19:52:23 CET] <furq> and er
[19:52:25 CET] <kepstin> saml: but even if you keep rate and size the same, psnr still isn't very useful unless only computers are watching your video.
[19:52:30 CET] <furq> a source and encode, i mean
[19:52:44 CET] <furq> and also yeah psnr/ssim aren't that useful with modern codecs because of psy
[19:52:52 CET] <furq> vmaf supposedly takes that into consideration
[19:53:05 CET] <furq> i couldn't tell you how good it is though
[19:53:22 CET] <saml> yeah i'm calculating psnr of source and encode.  but encode does use -r  and -s  (changes both framerate and size)
[19:53:39 CET] <furq> well yeah you're not comparing the same frames
[19:54:15 CET] <kepstin> saml: run a first pass encoding to a temp file (lossless?) with -r and -s, then encode from that temp file. Run a psnr compare between the temp file and final encode.
[19:54:42 CET] <saml> kepstin, that works pretty well.  except when encode is generated with -filter framework, not -r
[19:54:50 CET] <sfan5> x264 is not deterministic is it?
[19:54:56 CET] <furq> not by default
[19:55:03 CET] <saml> this is theoretical situation. i don't do -filter framerate
[19:55:08 CET] <furq> there's some settings you can disable to make it bitexact but i forget which ones right now
[19:55:31 CET] <furq> i'm pretty sure you have to disable frame threading and something else
[19:55:43 CET] <furq> so it's not something most people are going to do
[19:55:46 CET] <saml> so, to test an encoding pipeline,   i need to figure out what it's exactly doing. if it's using -r or -s... etc.   i create a lossless encoding with same -r and -s ... etc.  and do psnr
[19:56:00 CET] <kepstin> saml: -r ? is the same as -vf fps=?
[19:56:06 CET] <furq> -r is the fps filter and -s is the scale filter
[19:56:39 CET] <kepstin> saml: basically, you need to compare psnr between the lossless output of the filters and the final encoded file.
[19:56:53 CET] <furq> yeah the filters aren't encoding anything
[19:57:02 CET] <furq> just use the same filterchain to generate a lossless output and an encoded output
[19:57:09 CET] <furq> although at this point it's unclear what you're actually testing
[19:57:17 CET] <kepstin> yeah :/
[19:57:42 CET] <furq> scaling and decimating has already reduced the quality relative to the source
[19:57:42 CET] <kepstin> saml: why do you think you want psnr values in the first place, anyways? What do you plan to do with them?
[19:58:03 CET] <saml> -r 30 r30.mp4   vs.   -vf fps=30  fps30.mp4        would you expect r30.mp4  and fps30.mp4 to have psnr inf?
[19:58:26 CET] <kepstin> saml: those are both the same command, so the result should be identical (except for x264 nondeterminism)
[19:58:29 CET] <furq> no but only because x264 isn't bitexact by default
[19:58:33 CET] <furq> funny how that came up again so quickly
[19:58:41 CET] <furq> the psnr should be very high though
[19:59:31 CET] <furq> oh, actually
[19:59:45 CET] <furq> it's non-deterministic with frame threading and the vbv enabled
[19:59:53 CET] <furq> so i guess it will be bitexact by default
[19:59:59 CET] <kepstin> no, threading is enabled by default
[20:00:15 CET] <furq> both frame threading and the vbv
[20:00:16 CET] <kepstin> oh, or did they make threading deterministic at some point?
[20:00:23 CET] <furq> https://mailman.videolan.org/pipermail/x264-devel/2015-April/011035.html
[20:00:26 CET] <kepstin> it might depend on x264 version then
[20:00:44 CET] <saml> i want metric to test encoding pipeline v1 and v2.  I have source code of both v1 and v2. I know exactly what ffmpeg they are executing.  before rolling v2 out to production, i want to make sure it does not have abnormali against v1
[20:01:30 CET] <saml> so I wanted to encode sample originals through v1 and v2 and somehow measure something numerically
[20:01:31 CET] <kepstin> furq: this other post: https://mailman.videolan.org/pipermail/x264-devel/2015-April/011037.html measures that simply changing threads affects psnr
[20:02:11 CET] <furq> oh fun
[20:02:55 CET] <kepstin> furq: I'm fairly sure that frame threading in x264 is non-deterministic. I believe libvpx 1.7's new threading mode is deterministic, tho.
[20:03:13 CET] <furq> is that row-mt or did they finally add frame threading
[20:03:30 CET] <kepstin> i think it's row-mt.
[20:03:52 CET] <kepstin> libvpx 1.7.0 is just the first release to include row-mt
[20:03:56 CET] <furq> yeah
[20:04:43 CET] Action: kepstin has been using git snapshots for ages tho.
[20:05:45 CET] <kepstin> saml: if you have the original source of both videos, and both were encoded at the same fps/size as the original source, then you can do vmaf of source’encode1 and source’encode2 and compare the values.
[20:09:53 CET] <saml> if encode1 and encode2 are different, the best bet for me is to generate two lossless from source  that matches encode1 and encode2  and do psnr or vmaf  of  lossless1->encode1   and lossless2->encode2
[20:10:05 CET] Action: saml tests this
[20:15:35 CET] <killown> how can ffmpeg auto set font size depending on video aspect ratio size etc, I mean, some videos the text gets too big and some too small, ffmpeg -i "$originalfile"  -vf "drawtext=text='MYTEXT':x=w-tw-10:y=h-th-20:fontsize=35:fontcolor=white at 0.6:shadowcolor=black at 0.2:shadowx=2:shadowy=2:box=1: boxcolor=DarkMagenta at 0.2:boxborderw=5" "$newfile"
[20:16:51 CET] <ddubya> killown, multiply the font size by some function of the frame size
[20:17:55 CET] <ddubya> if you want the font to be 10% of height then fontSize=0.1*h
[20:18:08 CET] <killown> ddubya, thank you I will try
[20:18:22 CET] <kepstin> saml: but that won't account for perceptual differences due to the resolution or framerate changes, so it's kinda incomplete.
[20:22:16 CET] <saml> yeah. i think it's better to start measuring encoding time and other exact numbers  and compare how long it takes to encode the same video in pipeline1 and pipeline2... etc
[20:23:50 CET] <geuis> hmm. How can I clear an overlay after some amount of time? I'm importing a stack of pngs at 1fps and a stack of svgs at 1fps, then overlaying the svgs.
[20:24:03 CET] <geuis> Current command: ffmpeg -y -framerate 1 -i layer-%d.png -framerate 1 -i layer-%d.svg -filter_complex "[0:v]fps=30[base];[1:v]fps=30[date];[base][date]overlay=(0):(0)" -preset ultrafast -movflags +faststart -vcodec libx264 -crf 23 -pix_fmt yuv420p out.mp4
[20:30:06 CET] <ddubya> geuis, maybe it would clear if you ran out of svgs?
[20:31:14 CET] <kepstin> geuis: the overlay filter takes framesync options, see https://www.ffmpeg.org/ffmpeg-filters.html#framesync - The default is to keep showing the last frame forever
[20:31:27 CET] <geuis> its a 1-1 correlation. Each svg is created to last as long as the base png
[20:32:47 CET] <killown> ddubya, thanks a lot, this worked
[20:35:08 CET] <saml> wait.. just noticed if i have to create lossless encoding to use as reference to psnr,  i could just pass -psnr -tune psnr.   and be done with it
[20:35:18 CET] <saml> re-encode with -psnr param :P
[20:35:30 CET] <saml> i don't need to create lossless reference and use psnr filter
[20:36:28 CET] <kepstin> saml: but you don't want -tune psnr if humans are watching your video
[20:36:41 CET] <kepstin> saml: -tune psnr makes the video look worse, but the psnr number higher
[20:36:46 CET] <geuis> kepstin, would it look like this? "[base][date]overlay=(0):(0),framesync=repeatlast=0"
[20:37:28 CET] <kepstin> geuis: no, "[base][date]overlay=(0):(0),repeatlast=0" (or "[base][date]overlay=(0):(0),eof_action=pass" might be better actually)
[20:40:53 CET] <saml> since psnr is logarithmic scale,  difference of 1.0 is huge?
[20:41:05 CET] <saml> i feel like i'm writing a paper
[20:42:29 CET] <geuis> @kepstin: says its an invalid argument -filter_complex "[0:v]fps=30[base];[1:v]fps=30[date];[base][date]overlay=(0):(0),repeatlast=0"
[20:43:06 CET] <kepstin> geuis: sorry, my fault. syntax issue. It should be a : not a ,
[20:45:01 CET] <geuis> ah right
[20:54:26 CET] <geuis> hmm. @kepstin tried all of the framesync options but the overlays persist
[20:55:43 CET] <kepstin> geuis: do you have an svg corresponding to each png file?
[20:55:49 CET] <kepstin> or fewer svgs than pngs?
[20:56:17 CET] <geuis> yeah, 1-1
[20:57:14 CET] <kepstin> geuis: expected behaviour then. If you want the svg overlay to stop earlier, just delete some of the files? Or you can add a trim filter after one of the fps filters, to set an end point on that stream.
[21:00:32 CET] <kepstin> geuis: so something like "[0:v]fps=30[base];[1:v]fps=30,trim=end=10[date];[base][date]overlay=(0):(0):repeatlast=0" will stop the overlayed frames after 10 seconds.
[21:04:37 CET] <geuis> semicolon or comma between fps=30,trim=end=10?
[21:04:52 CET] <geuis> I get them mixed up
[21:05:07 CET] <sfan5> comma
[21:05:45 CET] <geuis> why a comma there, but a semi in "[base][date]overlay=(0):(0):repeatlast=0"
[21:06:40 CET] <saml> overlay(base, date, 0, 0, repeatlast=0)
[21:06:48 CET] <sfan5> "Filters in the same linear chain are separated by commas, and distinct linear chains of filters are separated by semicolons. "
[21:06:49 CET] <saml> I think that's rough C-like syntax
[21:06:50 CET] <sfan5> from the docs
[21:07:15 CET] <geuis> ah that makes sense saml
[21:07:46 CET] <saml> foo,bar  means bar(foo(a)), i think
[21:07:47 CET] <geuis> commas are like passing the results from one function to the next, semis are arguments for a function
[21:08:12 CET] <saml> foo;bar   is  foo();  bar()  (not necessarily sequentially)
[21:08:26 CET] <geuis> yah
[21:10:20 CET] <furq> it's bar(foo(a)) in languages that don't have multiple returns
[21:10:41 CET] <furq> if a filter takes or emits more than one stream you always need ;
[21:10:47 CET] <furq> even if the outputs go to the next input
[21:11:39 CET] <furq> actually nvm maybe i'm wrong
[21:13:27 CET] <geuis> hmm not working
[21:14:02 CET] <geuis> tried end and duration with different values for trim
[21:14:34 CET] <geuis> all it seems to be doing is cutting off the overlay at a certain point, then no new ones are shown afterwords
[21:15:01 CET] <geuis> like its treating all of the svgs as a single video source rather than individually
[21:16:45 CET] <saml> you want layer-1.svg to be overlayed to layer-1.png  and become frame 1?
[21:16:58 CET] <saml> and layer-2.svg is overlayed to layer-2.png and become frame 2
[21:19:21 CET] <geuis> what's the definition of frame in this context?
[21:19:27 CET] <kepstin> geuis: yes, that's exactly what it's doing. it's making a video out of the svgs by putting one frame after the next
[21:20:10 CET] <geuis> I have pairs of png and svg. Trying to have each svg overlay its png for an equal duration
[21:20:27 CET] <geuis> so 10 input pngs at 1fps create a ten second animation
[21:21:20 CET] <geuis> and each matching svg should overlay at the start of its png and be cleared when the next png input is shown
[21:22:29 CET] <geuis> currently they all start correctly, but the tricky bit is getting the associated svg to be cleared after its 1 second duration
[21:23:17 CET] <geuis> is there a way to set a keyframe at each second and have ffmpeg clear everything?
[21:23:51 CET] <Jared> Hey guys, my new download install failed but I can't find the console log in ffbuild, should I just re-run to see if it makes one next time or is it in a different location on Mac?
[21:24:48 CET] <kepstin> ok, so you want each png to be shown for 10 seconds, but the svg to be shown for 1 second, and then 9 seconds of blank?
[21:25:07 CET] <kepstin> geuis: that's gonna be really hard to do, I don't know any easy way to do it via ffmpeg filters.
[21:25:24 CET] <saml> i wonder if it's easier to overlay png and svg  using different program in a loop, generating  overlayed-%d.png ...
[21:25:45 CET] <geuis> each png is shown for 1 second. each svg is overlayed for 1 second over its png
[21:25:56 CET] <kepstin> geuis: that should be what it's doing...
[21:25:59 CET] <saml> it's like as if you're watermarking each slide with different watermark and create a slideshow
[21:26:16 CET] <geuis> yes, that's a close analogy
[21:26:35 CET] <kepstin> geuis: you've created a 1fps video of pngs, and a 1fps video of svgs, and you've overlayed one video over the other. Everything should be matching up.
[21:26:42 CET] <geuis> they do
[21:26:55 CET] <geuis> but I need each svg to stop displaying after 1fps
[21:27:08 CET] <saml> oh that's clever way to do it
[21:27:22 CET] <saml> ah do you see buffering effect(?) on svg video stream?
[21:27:30 CET] <kepstin> geuis: I'm not sure what you mean. After 1s, the first svg should be replaced with the next.
[21:27:34 CET] <geuis> I can't show a sample unfortunately (internal company thing)
[21:27:45 CET] <saml> i mean like buffer isn't cleared before drawing next svg
[21:27:50 CET] <geuis> lemme screen shot
[21:27:54 CET] <geuis> one min
[21:28:11 CET] <thebombzen_> in the configure script, what does --enable-gray actually do?
[21:28:29 CET] <thebombzen_> it says 'full grayscale support (slower color)' but what does that even mean?
[21:30:20 CET] <kepstin> thebombzen_: it looks like it adds a fastpath for grayscale in a few codecs, at the expense of adding a bunch of extra conditionals (if statements) which make the regular colour path slower
[21:30:51 CET] <kepstin> thebombzen_: you'd probably have to benchmark individual use cases to see if it helps/hurts.
[21:31:10 CET] <saml> it seems to enable gray9be  and gray9le   pix_fmt
[21:31:40 CET] <thebombzen_> cause I find it strange that adding full grayscale support would slow down color, since most of the computation would be done knowing the pixel format, right?
[21:31:46 CET] <thebombzen_> I mean how much slower does it really make color?
[21:31:57 CET] <saml> i have ffmpeg with --enable-gray  and -pix_fmts include gray9be  and gray9le   ffmpeg without --enable-gray don't have those
[21:32:00 CET] <kepstin> thebombzen_: "kepstin> thebombzen_: you'd probably have to benchmark individual use cases to see if it helps/hurts."
[21:32:11 CET] <thebombzen_> oh lol, okay then.
[21:32:15 CET] <geuis> ok hopefully this is clearer https://imgur.com/a/IsEni
[21:32:17 CET] <saml> ah i'm wrong
[21:32:26 CET] <kepstin> thebombzen_: but in general, adding more conditionals/if statements makes code slower
[21:32:41 CET] <kepstin> so if you add an if statement "if grey, don't do colour stuff" then the colour stuff is slower
[21:33:03 CET] <geuis> I have 5 pngs of background imagery I'm overlaying with an svg that contains some date text and other graphical elements.
[21:33:07 CET] <thebombzen_> yea but I was under the impression the if statements weren't done repeatedly
[21:33:33 CET] <thebombzen_> I also wonder if that logic can be fixed with -fpredictive-commoning
[21:34:25 CET] <sfan5> isn't that just a fancy way of adding __builtin_except(/* is color? */, 1) aka __likely() ?
[21:34:32 CET] <sfan5> s/except/expect/
[21:35:07 CET] <thebombzen_> predictive commoning affects a compiler's branch prediction yea. and since you're always encoding the same pixel format it should be pretty good at the branch prediction
[21:35:39 CET] <sfan5> well that can only do so much, there will still be nonzero overhead
[21:36:06 CET] <thebombzen_> true, but it might be worth it. Depending on how frequently you execute teh if statements it might be negligible
[21:38:40 CET] <Loeb> Is there an encoder that uses cuda for h264, independent of nvenc/nvidia's on chip hardware encoder?
[21:39:41 CET] <furq> not in ffmpeg
[21:39:46 CET] <furq> there's some commercial one iirc
[21:41:24 CET] <thebombzen_> Loeb: in general GPU-accelerated encoding is a very difficult thing to do
[21:41:31 CET] <furq> x264 can use opencl for lookahead but the results are very patchy
[21:41:48 CET] <furq> it's generally not something you can do well on an gpu
[21:42:03 CET] <furq> you're better off just using the gpu for filtering
[21:42:12 CET] <furq> it was designed for image processing after all
[21:42:15 CET] <thebombzen_> teh design of these codecs is such that good encoders make lots of decisions on how to allocate bitrate
[21:42:25 CET] <thebombzen_> and GPUs are specifically very bad at "lots of decisions"
[21:42:27 CET] <Loeb> Yeah, right now we are running ffmpeg with cuda decode and nvenc encode but we are maxing out the gpu's encoder chip
[21:42:41 CET] <Loeb> Wasn't sure if we could pile on something that used the other GPU bits on top
[21:43:06 CET] <thebombzen_> if all you're doing is decoding with cuvid and encoding with nvenc, you're just suffering from generation loss for no reason it seems
[21:43:21 CET] <thebombzen_> if you have any filtering in between, that's a good thing to do on the GPU as furq said
[21:43:34 CET] <Loeb> All we are doing is going form mpeg2 to h264 right now
[21:43:37 CET] <furq> is this a quadro
[21:43:40 CET] <Loeb> from*
[21:43:42 CET] <Loeb> Yeah, P4000
[21:43:46 CET] <furq> oh ok
[21:43:54 CET] <thebombzen_> You might want to consider using x264
[21:43:57 CET] <furq> i guess you are actually maxing it out and not just running into the concurrent stream limit then
[21:44:09 CET] <Loeb> x264 runs on the CPU though, right?
[21:44:19 CET] <Loeb> Yeah we are at around 24 encoding threads
[21:44:24 CET] <kepstin> Loeb: sure, but you have all those cpus free because you're encoding on the gpu right? :)
[21:44:46 CET] <thebombzen_> yes. but x264 is so much better than nvenc. nvenc's coding inefficiency is really bad
[21:44:47 CET] <Loeb> Unfortunately I think we could only shove another 3-4 encoders on the CPU before it maxes out
[21:44:56 CET] <furq> what cpu
[21:45:04 CET] <Loeb> E5-2603 v4
[21:45:08 CET] <Loeb> No core speed
[21:45:21 CET] <specing> you need tha power
[21:45:23 CET] <furq> 1.7ghz apparently
[21:45:24 CET] <thebombzen_> also Loeb you should decode mpeg2 on the cpu. FFmpeg's mpeg2video decoder is faster than Cuvid's mpeg2video hardware decoder.
[21:45:26 CET] <specing> tha IBM openpower
[21:45:28 CET] <furq> so yeah that's not going to do too great
[21:45:35 CET] <thebombzen_> or rather
[21:45:39 CET] <thebombzen_> maybe not with that core speed
[21:45:39 CET] <kepstin> ah, so you got a slow chip with a lot of pci-e just to run the gpus, then.
[21:45:44 CET] <Loeb> Also this is for streaming use, so we are running higher bitrates than normal x264 use
[21:45:52 CET] <furq> it doesn't really matter if it's faster if cuvid isn't the bit that's maxed out
[21:45:55 CET] <thebombzen_> x264 can do any bitrate?
[21:46:22 CET] <Loeb> thebombzen_, the decoder isn't the limiting factor I believe, nvidia-smi is reporting different utilization counters for decode and encode
[21:46:23 CET] <Loeb> I could be wrong
[21:46:31 CET] <thebombzen_> ah okay
[21:46:34 CET] <Loeb> Yes but we don't have any quality issues with nvenc
[21:46:37 CET] <thebombzen_> might be worth it anyway though for power reasons
[21:46:44 CET] <Loeb> We just wanna push more data through it. If anything we should drop the quality settings...
[21:46:45 CET] <furq> 24 streams with nvenc is a fair old amount
[21:46:50 CET] <furq> i wouldn't be surprised if that was the limiting factor
[21:47:04 CET] <furq> i take it this is sd
[21:47:07 CET] <Loeb> It might be, I just wanted to make sure there wasn't any better way to utilize the rest of the GPU
[21:47:12 CET] <thebombzen_> you might be hitting max TDP too on the GPUs
[21:47:14 CET] <Loeb> Some SD some 1080i
[21:47:19 CET] <BtbN> I'm surprised it even managed 24 without dieing horrible
[21:47:20 CET] <thebombzen_> so perhaps you should consider software decoding the mpeg2
[21:47:23 CET] <Loeb> Nowhere near TDP limit actually
[21:47:28 CET] <thebombzen_> oh then, nvm
[21:47:28 CET] <kepstin> thebombzen_: nah, if the 3d engine isn't being used it should be nowhere near tdp
[21:47:34 CET] <furq> maybe offload the sd streams to the cpu then
[21:47:51 CET] <furq> i'm not sure how many you could get on that cpu but x264 is very quick if you use fast settings
[21:47:53 CET] <thebombzen_> yea SD on a CPU is actually quite fast
[21:48:09 CET] <thebombzen_> probably fast enough
[21:48:14 CET] <furq> yeah and you'd probably want to use nvenc's deinterlacer for 1080i
[21:48:15 CET] <thebombzen_> which is all that matters if streaming. "fast enough"
[21:48:21 CET] <Loeb> We aren't even deinterlacing
[21:48:23 CET] <furq> oh
[21:48:24 CET] <furq> well that helps
[21:48:25 CET] <thebombzen_> rip
[21:48:27 CET] <Loeb> Literally just mpeg2 > h264
[21:48:41 CET] <thebombzen_> Although you can save bitrate with IVTC
[21:48:53 CET] <thebombzen_> not sure how well you can IVTC in realtime though
[21:49:04 CET] <thebombzen_> (since 30 -> 24 fps is lower bitrate I mean)
[21:49:05 CET] <furq> i doubt this is telecined
[21:49:11 CET] <kepstin> ivtc doesn't help unless it's telecined :)
[21:49:13 CET] <thebombzen_> well it's 30 fps interlaced mepg2
[21:49:19 CET] <thebombzen_> so I'm guessing it's telecined
[21:49:28 CET] <furq> that's a weird guess to make
[21:49:30 CET] <kepstin> nah, it could be any ntsc interlaced video.
[21:49:51 CET] <thebombzen_> okay, so *if* it's telecined, IVTC could save you some bitrate
[21:50:16 CET] <thebombzen_> (I just see interlaced 1080i mpeg2 and figured it was a digital TV broadcast)
[21:50:30 CET] <thebombzen_> I've been hanging out with anime encoders too much
[21:50:30 CET] <furq> it probably is a digital tv broadcast but a lot of that is 30i anyway
[21:50:47 CET] <thebombzen_> but most content is filmed in 24
[21:50:53 CET] <furq> i don't think it is
[21:51:09 CET] <furq> maybe if you work for HBO it is
[21:51:12 CET] <thebombzen_> film and animation industry use 24 as standard, afaik. lemme find a soruce on that.
[21:51:19 CET] <furq> yeah the film industry does
[21:51:26 CET] <furq> that's distinct from the tv industry though
[21:56:22 CET] <kepstin> tv industry is still mostly 60i/50i for broadcast stuff and general tv productions (which is why high framerate is sometimes called "soap opera effect")
[21:56:32 CET] <geuis> @kepstin I isolated this to just the svgs http://i.imgur.com/Mo39Ld8.gifv
[21:57:11 CET] <kepstin> geuis: alright, so my guess is that it's a bug in the svg rendering in ffmpeg
[21:57:27 CET] <kepstin> where it's drawing over a previously rendered frame rather than drawing each separately on a clear frame
[21:57:34 CET] <geuis> ffmpeg -y -i layer-%d.svg -preset ultrafast -movflags +faststart -vcodec libx264 -crf 23 -pix_fmt yuv420p out.mp4
[21:57:37 CET] <geuis> yeah
[21:58:16 CET] <geuis> I wonder if I convert them to pngs first..
[21:58:38 CET] <kepstin> using an external svg renderer would work around the bug, yes.
[21:58:51 CET] <kepstin> unless your svgs themselves are bad (have stuff stacked in the svg)
[21:59:42 CET] <geuis> actually, yes I do
[21:59:43 CET] <furq> maybe try -i layer-%d.svg -filter_complex "color=black:s=640x480[bg];[bg][0:v]overlay=shortest=1"
[21:59:52 CET] <geuis> there are a few different elements going on
[22:00:14 CET] <furq> assuming these images have a transparent background
[22:00:26 CET] <kepstin> geuis: if your svg rendered by itself looks like that, then... ffmpeg can't really do anything about it?
[22:00:39 CET] <geuis> no, each svg is fine on its own
[22:01:12 CET] <geuis> there's <text> for the date and an external svg for the company logo being written into the svg
[22:04:02 CET] <geuis> @furq the background isn't actually black. We've been trying to diagnose a problem I'm running into using svgs as overlays
[22:04:24 CET] <geuis> previous frames are bleeding through
[22:10:34 CET] <kepstin> furq: the suspicion I have is that the libsrvgdec code isn't correctly clearing the buffer (which might be re-used?) before drawing the next svg.
[22:11:05 CET] <furq> yeah i subsequently realised that they're obviously being overlaid on something anyway
[22:11:16 CET] <furq> i had to call my isp earlier so forgive my brain being broken
[22:12:54 CET] <kepstin> hmm, looking at the librsvgdec code, the functions it's using to clear the buffer do in fact look wrong.
[22:13:12 CET] <kepstin> it's clearing the buffer - by painting *over* it with transparent black
[22:13:17 CET] <kepstin> which obviously does nothing
[22:13:28 CET] <geuis> heh. I feel like a snow plow for bugs
[22:13:53 CET] <kepstin> it's gonna be a 2-3 line patch to fix, refereincing the faq at https://www.cairographics.org/FAQ/#clear_a_surface
[22:15:21 CET] <kepstin> geuis: apply this patch and rebuild your ffmpeg, should fix it: https://gist.github.com/kepstin/0e71839057301334ae65fdf4c26b372c
[22:15:42 CET] <kepstin> er, wait, no that's wrong
[22:15:47 CET] <kepstin> that'll do opaque black
[22:16:00 CET] <geuis> I've also noticed something else, the fonts embedded in the svg aren't being rendered in the svg
[22:16:06 CET] <geuis> was going to tackle that later
[22:16:40 CET] <kepstin> ^^ I've updated that link to fix it to clear to transparent black
[22:16:46 CET] <geuis> er, fonts referenced by file path in the svg document aren't being used when the svg is rendered into the graphic
[22:17:15 CET] <kepstin> geuis: hmm, the renderer probably has disabled referencing external files.
[22:17:19 CET] <geuis> @kepstin ok will need to tackle that in a big
[22:17:27 CET] <geuis> bit
[22:17:41 CET] <kepstin> geuis: either rendering the text as paths in the svg or using system fonts via fontconfig should work
[22:19:25 CET] <geuis> haven't tried this yet, but since we have the font file I was going to try referencing it with fontconfig to see if that might work.
[22:20:19 CET] <karen__> Is there somewhere to find help with opening video surveillence footage? My system encoded some footage @~4K in H.265, but mplayer and vlc won't play it. The terminal output says to upload it to the ftp, but I figured I'd see if this is an issue that might arise with some frequency and ask here first...
[22:22:01 CET] <kepstin> karen__: can you pastebin the output from "ffplay <file>" so we can take a quick look at what's going wrong?
[22:22:58 CET] <kepstin> geuis: let me know if that patch works, and I'll send it over to ffmpeg-devel
[22:23:10 CET] <JEEB> karen__: you most likely just have old software (or the file format is something proprietary in which the HEVC is)
[22:23:21 CET] <karen__> https://pastebin.com/4wbhVcbu
[22:23:47 CET] <karen__> im running manjaro (current - updated yesterday) and ...
[22:23:48 CET] <JEEB> also that seems like it's getting read as H.264, not HEVC
[22:23:54 CET] <kepstin> karen__: huh, it's been misdetected as h264. You're missing the top of that output, can you go back and get the earlier bits?
[22:24:09 CET] <karen__> yeah, i saw that - but the output checkmark says 265
[22:24:17 CET] <JEEB> karen__: I recommend using ffprobe and posting the log with the version numbers of `ffprobe FILE`
[22:24:17 CET] <karen__> sure, i can - just a sec
[22:24:39 CET] <JEEB> the version markers should tell us how old your FFmpeg etc is
[22:25:00 CET] <karen__> oh, well i just installed that from manjaro repo
[22:25:02 CET] <kepstin> the full ffplay output includes the version info too
[22:25:21 CET] <karen__> 3.4.1-3 for ffmpeg
[22:25:39 CET] <JEEB> kepstin: yes but we don't need playback
[22:25:48 CET] <JEEB> ffprobe is more useful to just get the probed format info etc
[22:25:56 CET] <karen__> okay
[22:26:01 CET] <kepstin> JEEB: sure, but ffplay prints that too ... at the top
[22:26:03 CET] <JEEB> karen__: ok, so you have a new enough thing for HEVC
[22:27:23 CET] <karen__> https://pastebin.com/h3k3Z4tE
[22:27:55 CET] <JEEB> ok, so it seems like AVI with H.264
[22:28:07 CET] <JEEB> yet it cannot parse it as H.264
[22:28:45 CET] <kepstin> so this is an avi file containing hevc, but with the h264 fourcc? ugg.
[22:28:53 CET] <JEEB> could be something like that :P
[22:28:54 CET] <furq> this all sounds very chinese
[22:28:55 CET] <karen__> right, but the manual and the screen on the surveillence equipment both say h.265 default and h.264 is not on
[22:29:09 CET] <JEEB> karen__: yea but the file could just be shoddily written by the device
[22:29:17 CET] <JEEB> it seems to be saying "hey this is H.264"
[22:29:22 CET] <JEEB> in the file for the video track
[22:29:26 CET] <furq> is there such thing as hevc in avi
[22:29:36 CET] <JEEB> well there is no real official mappings for AVC or HEVC
[22:29:37 CET] <furq> outside of whatever device wrote this
[22:29:42 CET] <JEEB> or heck, even MPEG-4 Part 2
[22:29:48 CET] <kepstin> karen__: can you possibly use a different container instead of avi?
[22:29:56 CET] <karen__> I cannot anylonger
[22:29:59 CET] <karen__> and when i exported it
[22:30:03 CET] <karen__> it chose mp4
[22:30:11 CET] <karen__> but it came out like this
[22:30:15 CET] <JEEB> lol
[22:30:20 CET] <JEEB> great software/hardware
[22:30:34 CET] <JEEB> anyways, I would just try rewriting the FourCC of that AVI file
[22:30:42 CET] <karen__> seriously - f)(k binary/propiatary blobs right?
[22:30:44 CET] <furq> to what, though
[22:30:44 CET] <JEEB> to whatever FFmpeg reads as HEVC
[22:31:14 CET] <karen__> I don't know what rewriting the fourcc means
[22:31:59 CET] <JEEB> possible 'HEVC' would work
[22:32:02 CET] <kepstin> hmm. would forcing the codec on an ffmpeg command (using -c:v as an input option) work to override this case?
[22:32:15 CET] <JEEB> I don't think it would :/
[22:32:27 CET] <furq> yeah i don't think that works but it's worth a try
[22:32:50 CET] <karen__> Yesterday i tried to force VLC to use different codecs to play the video back, and didn't have any luck  - I mean, i'm kinda just feel like im guessing and fumbling around at this point, and the trouble is, this creep that was stalking me is in the clip... photographing my house.. *le sigh
[22:33:24 CET] Action: kepstin honestly wouldn't trust this security camera to be ... secure.
[22:33:43 CET] <karen__> oh hell, it's not on the network.. lulz
[22:33:56 CET] <kepstin> but if you're only using it to record outdoor stuff (not private), probably good enough.
[22:34:11 CET] <furq> it's not good enough if you can't play back the footage
[22:34:26 CET] <JEEB> karen__: basically there's currently a thing in the AVI file that says literally 'H264 ', you could try rewriting that identifier (called FourCC) to 'HEVC' or so
[22:34:31 CET] <furq> call me old-fashioned but i would say that is one of the main features of a security camera
[22:34:32 CET] <JEEB> and hope that FFmpeg knows that
[22:34:34 CET] <karen__> nor the internet - but the picutres look good on the machine, but the export function, the only time ive needed it seems to have failed me
[22:34:46 CET] <JEEB> but yes, that thing has generated you broken-beyond-commision files :P
[22:35:03 CET] <karen__> right furq? lol
[22:35:12 CET] <furq> karen__: you can try ffmpeg -c:v hevc -i foo.avi -f null -
[22:35:31 CET] <furq> emphasis on try because i don't think that works
[22:35:47 CET] <karen__> foo.avi with my file name?
[22:35:50 CET] <furq> right
[22:36:00 CET] <karen__> oh, yhea - this looks like what i was trying yesterday
[22:36:08 CET] <karen__> when i tried h26x and such too
[22:36:22 CET] <JEEB> most likely it won't work because that's actually within a container and all
[22:36:25 CET] <furq> yeah
[22:36:31 CET] <JEEB> so ffmpeg.c already has the Trusted Information
[22:37:05 CET] <kepstin> geuis: any news back on whether my patch fixes your svg problem?
[22:37:13 CET] <karen__> Too many packets buffered for output stream 0:0.32:22.77 bitrate=N/A speed=N/A
[22:37:36 CET] <JEEB> karen__: in the output of ffmpeg.c do you see if the input track is noted as HEVC or H.264?
[22:37:42 CET] <JEEB> it's in the relative beginning of the log
[22:37:52 CET] <JEEB> if you succeeded in overriding it to HEVC, congratulations
[22:38:25 CET] <karen__> um, wheres the ffmpeg.c?
[22:38:41 CET] <JEEB> it's the command line ffmpeg tool
[22:38:50 CET] <kepstin> karen__: please just pastebin the output of that ffmpeg command *from the top*
[22:38:56 CET] <karen__> oh
[22:39:50 CET] <furq> if you don't get a million h264 decoder errors (like in the ffprobe paste) then we might be onto something
[22:39:52 CET] <karen__> https://pastebin.com/MmafrFFw
[22:40:02 CET] <karen__> oh no, it was way smaller error
[22:40:03 CET] <furq> oh wow nice
[22:40:03 CET] <JEEB> con-fucking-gratulations
[22:40:11 CET] <furq> i genuinely didn't think that would work
[22:40:17 CET] <JEEB>  Stream #0:0: Video: hevc (Main) (H264 / 0x34363248), yuvj420p(pc, bt709), 2560x1440, 2087 kb/s, 9 fps, 9 tbr, 9 tbn, 36 tbc
[22:40:32 CET] <JEEB> so you actually managed to override the darn thing
[22:40:35 CET] <furq> i wonder if this is because whoever wrote the avi muxer is familiar with china
[22:40:37 CET] <JEEB> and suddenly it has way more info
[22:40:56 CET] <kepstin> karen__: you should be mostly good to go then, try running "ffmpeg -c:v hevc -i 1_01_R_171112194500.avi -c copy fixed.mkv" and see if the result is playable.
[22:40:56 CET] <geuis> kepstin: haven't had a chance to try it yet
[22:41:02 CET] <furq> yeah i was just typing that
[22:41:07 CET] <JEEB> ok, kepstin wrote it down :)
[22:41:09 CET] <geuis> juggling the task masters atm
[22:41:15 CET] <JEEB> that should hopefully generate a valid matroska file
[22:41:17 CET] <JEEB> with HEVC
[22:41:23 CET] <furq> i have to suspect the audio codec is wrong as well but who knows
[22:41:25 CET] <JEEB> which should play in mpv for example
[22:41:28 CET] <furq> i'm guessing that bit is less important anyway
[22:41:32 CET] <JEEB> furq: yea probably it is :D
[22:41:47 CET] <JEEB> might as well -an that I guess?
[22:41:50 CET] <kepstin> geuis: cool. I'll probably just send the patch off anyways, I'm pretty sure it's correct.
[22:42:21 CET] <geuis> trying to think how I'm going to do this. got ffmpeg built from source via homebrew
[22:43:32 CET] <geuis> my other env is in a local docker image but its not setup as part of the rendering pipeline yet
[22:44:14 CET] <geuis> will your patch go into 3.4.1 or wait until another release?
[22:44:33 CET] <kepstin> geuis: probably won't be into 3.4.x, but who knows.
[22:44:42 CET] <kepstin> depends on if it can be considered a security issue
[22:44:56 CET] <JEEB> it doesn't have to be security
[22:45:05 CET] <JEEB> if it is applicable to that release branch and you care
[22:45:19 CET] <JEEB> that's pretty much how backports work right now I think :P
[22:51:25 CET] <karen__> https://pastebin.com/0Xhuzs4q
[22:52:09 CET] <alexpigment> karen__: what are you trying to do here?
[22:52:25 CET] <karen__> karen__: you should be mostly good to go then, try running "ffmpeg -c:v hevc -i 1_01_R_171112194500.avi -c copy fixed.mkv" and see if the result is playable.
[22:52:26 CET] <JEEB> right
[22:52:30 CET] <JEEB> the tag is incorrect
[22:52:48 CET] <JEEB> not sure why it requires it but let's see if there's an ffmpeg.c parameter to force it
[22:53:25 CET] <karen__> Thanks. Am feeling rather defeated :p
[22:53:38 CET] <JEEB> karen__: -tag:v "HEVC" after input
[22:53:41 CET] <JEEB> try that :)
[22:53:57 CET] <JEEB> or maybe input?
[22:54:01 CET] <JEEB> *before input
[22:54:23 CET] <alexpigment> is -c:v hevc even a thing?
[22:54:31 CET] <JEEB> yes
[22:54:31 CET] <kepstin> alexpigment: for the decoder, yes
[22:54:34 CET] <alexpigment> i guess i'm not used to specifying a decoder
[22:54:42 CET] <kepstin> (and it's an alias for whatever the default hevc encoder is)
[22:54:53 CET] <JEEB> the format didn't have another name yet when the decoder was made in libavcodec
[22:55:03 CET] <JEEB> it was still being called H.HEVC in ITU-T as well
[22:55:04 CET] <alexpigment> ah
[22:55:34 CET] <JEEB> as the specification was finally finished, then ITU-T announced they'd take it in and call it H.265
[22:55:38 CET] <JEEB> and absolutely no-one was surprised
[22:55:43 CET] <alexpigment> :)
[22:56:01 CET] <alexpigment> well, it's ideal to name something close to something people are already familiar with
[22:56:31 CET] <alexpigment> and maybe if HD-DVD would have succeeded, there would be a lot less confused old people about blu-ray
[22:57:04 CET] <kepstin> i still find it interesting that some companies have started putting out SD content on blu-ray (not upscaled)
[22:57:14 CET] <JEEB> that's been in the spec for ages
[22:57:19 CET] <alexpigment> sorry, just a side rant here. i really hate that blu-ray didn't catch on in time, and that most stores still stock more dvd than blu-ray :(
[22:57:22 CET] <JEEB> to be able to put DVD content there
[22:57:36 CET] <alexpigment> kepstin: yeah, it's usually for supplemental content though
[22:57:45 CET] <alexpigment> just reusing existing assets
[22:58:02 CET] <therage3> wait
[22:58:02 CET] <alexpigment> i'm fine with it. i don't need them to upscale something that my player can already upscale
[22:58:04 CET] <JEEB> physical stuff is going the way of the dodo outside of use cases where you just want the best thing you can get :P
[22:58:10 CET] <therage3> what? SD as in Standard Definition? like 480p stuff??
[22:58:12 CET] <JEEB> as in, a normal person cannot get a master
[22:58:13 CET] <kepstin> doing a new encode in h264 should be possible tho too
[22:58:15 CET] <therage3> on BR?
[22:58:18 CET] <alexpigment> i always want the best thing i can get. not sure why i would not want that
[22:58:19 CET] <JEEB> therage3: yes
[22:58:19 CET] <kepstin> therage3: yeah.
[22:58:26 CET] <therage3> fr
[22:58:27 CET] <therage3> lr
[22:58:28 CET] <alexpigment> 480i to be exact
[22:58:37 CET] <JEEB> both 480i and 576i
[22:58:37 CET] <therage3> like, for what purpose? to have 10 hours of it=
[22:58:39 CET] <therage3> ?
[22:58:49 CET] <alexpigment> because you have a movie with some sd-mastered extras
[22:58:51 CET] <JEEB> usually to put already created SD content there
[22:58:53 CET] <kepstin> I think the samurai pizza cats release on BD is 480p, and *probably* a new encode
[22:58:57 CET] <alexpigment> and they put the sd extras on in SD
[22:58:57 CET] <kepstin> entire season on one disk
[22:59:03 CET] <JEEB> kepstin: wow
[22:59:15 CET] <therage3> oh. so it isn't the whole thing
[22:59:17 CET] <therage3> just some extras
[22:59:18 CET] <JEEB> also I've seen literally two discs utilize 720p60/1.001
[22:59:31 CET] <kepstin> therage3: you can do the whole thing in sd, there's been a few cases
[22:59:45 CET] <alexpigment> JEEB, i've done that on a lot of discs i've mastered too. the source was 720p60, so... :)
[22:59:51 CET] <kepstin> some concert releases iirc, and it looks like a few companies doing anime releases for stuff that was originally sd.
[22:59:56 CET] <JEEB> alexpigment: :)
[23:00:03 CET] <JEEB> it's good when you have stuff like that
[23:00:22 CET] <JEEB> the one disc I know was a demoscene BD which had all the demos rendered at that rate
[23:00:25 CET] <alexpigment> well, i do a lot of broadcast backups to blu-ray. abc and maybe fox is still native 720p60
[23:00:34 CET] <JEEB> and the other just used it for 60/1.001Hz refresh rate
[23:00:40 CET] <JEEB> because they made a java-based adventure game
[23:00:42 CET] <therage3> that'd be a massive waste of capabilities, especially if you end up with a lot of unused space. I wonder if those same releases also have a DVD release which is the same, but costs less
[23:01:00 CET] <JEEB> therage3: well granted you can use H.264 and actual nice GOPs and bit rates
[23:01:00 CET] <kepstin> therage3: DVD is terrible if you can do a new encode from a good source
[23:01:13 CET] <JEEB> so in that sense you can get the best version of that SD content you have
[23:01:21 CET] <alexpigment> yeah, sd to blu-ray can look much better
[23:01:30 CET] <kepstin> and the BD is probably *cheaper* because you have to manufacture fewer disks
[23:01:33 CET] <alexpigment> so i get it. i've just never personally seen a case where the whole disc was SD
[23:01:48 CET] <JEEB> yea, DVD was goddamn awful. 1.5mbps and 8mbps maxrate?
[23:01:57 CET] <kepstin> it's rare, yeah. Upscales have generally been more common.
[23:01:59 CET] <JEEB> look at your buffer running away while you eat!
[23:02:15 CET] <kepstin> JEEB: hey, you could use up to 10.something mbit maxrate... if you had no audio ;)
[23:02:21 CET] <kepstin> iirc.
[23:02:24 CET] <kepstin> or 9.8 or something
[23:02:26 CET] <alexpigment> kepstin: yeah, 9.2
[23:02:27 CET] <JEEB> well yea, but that doesn't save the 1.5 megabit bufsize
[23:02:28 CET] <JEEB> lol
[23:02:28 CET] <kepstin> i forget
[23:02:32 CET] <therage3> JEEB, kepstin, I see
[23:02:34 CET] <alexpigment> well, the "safe" bitrate was usually 9.2
[23:02:40 CET] <therage3> kepstin: hm, it could be
[23:02:40 CET] <alexpigment> but yeah, you coudln't use PCM then :(
[23:02:45 CET] <therage3> tell me about it. that cartoon I was trying to rip for so long gave me nightmares
[23:02:47 CET] <therage3> fucking variable telecine with hardcoded blended frames
[23:02:48 CET] <therage3> yeesh, what a nightmare
[23:02:59 CET] <JEEB> well that part wouldn't change if the source is shit
[23:03:09 CET] <JEEB> but you'd get a better thing out of that shitty master
[23:03:39 CET] <alexpigment> you know, i had a few archiving projects where i authored an SD Blu-ray, which i had forgotten about until just now
[23:03:47 CET] <JEEB> basically the amount of damage making the disc itself to the turd will be minimized
[23:03:55 CET] <JEEB> *from making the disc...
[23:04:01 CET] <alexpigment> VHS captures that were like 4 hours long with no obvious place to split. so i kept the 16mbps h.264 bitrate and burned the whole thing to blu-ray
[23:04:13 CET] <kepstin> but if you had a good source for the SD, like i dunno digibeta broadcast tapes or something, then a new encode SD Blu-Ray could look a lot better than a DVD.
[23:04:39 CET] <alexpigment> kepstin: actually, i find the opposite case to be much truer
[23:04:41 CET] <JEEB> well yea, and even with the turds you can get a better image quality. just that if it's FUBAR, it will still be FUBAR
[23:04:51 CET] <alexpigment> if you have a bad source for SD, you need more bitrate
[23:05:12 CET] <JEEB> karen__: so did it go through with the forced tag?
[23:05:15 CET] <JEEB> (fourcc)
[23:05:18 CET] <kepstin> hey, even with a clean source, DVD still looks awful due to bitrate limits.
[23:05:23 CET] <alexpigment> yeah i agree
[23:05:36 CET] <JEEB> kepstin: suddenly got movement? WELCOME YOUR BLOCKY MASTERS!
[23:05:51 CET] <JEEB> s/MASTERS/OVERLORDS/
[23:05:53 CET] Action: kepstin thinks it's literally impossible to encode the Haruhi anime opening to DVD without looking like a blocky mess.
[23:06:02 CET] <alexpigment> just saying though, the absolute worst analog signal (static) needs to most digital bitrate. it's kinda comical how that worked out..
[23:06:05 CET] <JEEB> and for americans the HBO logo
[23:06:06 CET] <JEEB> lol
[23:06:15 CET] <alexpigment> yeah HBO logo for sure
[23:06:30 CET] <alexpigment> i haven't seen the hbo logo look decent in years
[23:07:45 CET] <JEEB> kepstin: I think the initial airings of haruhi and esp. the second season are the most fabulous though, since someone clearly passed the air masters through some analogue equipment
[23:07:47 CET] <alexpigment> i'm actually very surprised they didn't change it
[23:08:00 CET] <JEEB> so you got stuff like dot crawl and rainbows
[23:08:38 CET] <JEEB> it seemed to be popular up until 2009-2010 or so to push out certain things with crappy masters on terrestial
[23:08:53 CET] <alexpigment> i hate seeing dot crawl on dvd releases :(
[23:08:53 CET] <JEEB> cropping things to 4:3 and passing through analogue equipment
[23:09:14 CET] <kepstin> i dunno if it was unintentional badness or on purpose to make the dvds sell better.
[23:09:26 CET] <JEEB> it looked pretty purposeful
[23:09:50 CET] <JEEB> same for other shows on less popular networks, although there might have been a necessity due to lack of tapes or whatever
[23:09:57 CET] <JEEB> for example chiba tv would get shafted
[23:10:04 CET] <JEEB> while tokyo mx would get gut quality
[23:10:32 CET] <JEEB> and it definitely wasn't their encoder as it could handle other stuff that came from similar sources a'OK
[23:11:29 CET] <JEEB> I guess people just stopped using some sort of tapes or whatever around 2011, because that stuff just stopped around that time (the TBS stuff with kyoani being crap on terrestial got fixed before that)
[23:11:33 CET] <SortaCore> kepstin: try encoding the Maid Dragon opening
[23:11:57 CET] <SortaCore> one part it goes fast motion and technicolor
[23:12:04 CET] <kepstin> SortaCore: heh, yeah. I know crunchyroll couldn't encode that (but then again, i'm not convinced they can encode anything)
[23:12:16 CET] <JEEB> kepstin: http://www.mod16.org/randompics/screencaps/shit/tayutama-chiba2.png -> http://www.mod16.org/randompics/screencaps/shit/tayutama-tokyomxgasm.png
[23:12:19 CET] <JEEB> was a fun difference
[23:12:30 CET] <JEEB> (there were plenty of such cases)
[23:12:48 CET] <kepstin> crunchyroll can't even match up the gops for quality switching on the hls streams they use for most of their apps (ps3/4/chromecast/phone/etc)
[23:12:54 CET] <saml> how are you doing?
[23:13:46 CET] <kepstin> so you're watching a show on crunchyroll, and halfway through the opening it'll bump to higher quality and randomly move you forward/backward up to 10 seconds
[23:14:09 CET] <saml> is that a feature?
[23:14:12 CET] <kepstin> presumably because they forgot to set their x264 to use fixed gop size
[23:14:33 CET] <JEEB> most players can do the switch just fine with HLS
[23:14:37 CET] <saml> is it same as -r 30?
[23:14:38 CET] <JEEB> even without matching GOPs
[23:14:48 CET] <saml> i think you need constant frame rate for HLS
[23:14:52 CET] <JEEB> no
[23:14:59 CET] <JEEB> HLS has no requirements for frame rates
[23:15:05 CET] <kepstin> JEEB: my favourite fun difference was the episode of hidamari sketch where the 4:3 version has some of the faces squished compared to the 16:9.
[23:15:09 CET] <saml> otherwise, you can't switch to different conversion based on bandwidth
[23:15:20 CET] <saml> you can switch.. but it'll not be at the same time
[23:15:20 CET] <JEEB> kepstin: yup, TBS stuff there too
[23:15:27 CET] <JEEB> saml: wrong again
[23:15:30 CET] <JEEB> please read the specification
[23:15:37 CET] <JEEB> https://tools.ietf.org/html/rfc8216
[23:15:52 CET] <kepstin> JEEB: hmm, maybe this jumping thing is just a problem with their ps3 player then
[23:16:07 CET] <JEEB> kepstin: I mean all of their players *could* be shit, I just don't know
[23:16:22 CET] <JEEB> heck, it could just also be switching to the next segment's start point
[23:16:23 CET] <saml> i mean keyframes should line up
[23:16:24 CET] <JEEB> or previous
[23:16:44 CET] <JEEB> saml: no such requirement for the segments to have to be of the same length in time or to have matching GOPs
[23:16:50 CET] <saml> unless i'm using HLS wrong
[23:16:54 CET] <saml> hrm i see
[23:16:58 CET] <JEEB> you can do it, but it's not required
[23:17:06 CET] <JEEB> it also depends on what sort of retarded ass clients you have to support
[23:17:12 CET] <JEEB> if you go down there to the very low point
[23:17:15 CET] <JEEB> there's shit there
[23:17:18 CET] <kepstin> well, guess I'll send this librsvgdec patch. It doesn't break anything, at least.
[23:17:19 CET] <JEEB> which breaks the spec etc
[23:17:26 CET] <saml> yup
[23:17:32 CET] <saml> hsl.js or something
[23:17:35 CET] <geuis> kepstin: how do I apply your patch?
[23:17:41 CET] <JEEB> no, hls.js actually handles mismatching GOPs as far as I know
[23:17:43 CET] <geuis> beyond manually editing the file
[23:17:49 CET] <JEEB> real shitty stuff is random plastic boxes
[23:17:49 CET] <saml> that thing will jump time
[23:17:51 CET] <JEEB> including TVs
[23:17:57 CET] <kepstin> geuis: if you have git, "git apply <patch-filename" will do it.
[23:18:04 CET] <kepstin> (even if it's not a git checkout)
[23:18:06 CET] <JEEB> jumping time is still OK. the best I've seen wasn't even HLS though :P
[23:18:29 CET] <JEEB> it was one vendor's player just not thinking that segments aren't aligned and thus leading to a/v desync
[23:18:32 CET] <JEEB> for the rest of the video
[23:18:36 CET] <geuis> ok building now
[23:18:38 CET] <JEEB> I think this was a DASH player even
[23:18:41 CET] <saml> Matching content in Variant Streams MUST have matching timestamps.     This allows clients to synchronize the media.
[23:19:06 CET] <JEEB> saml: yes, as in the timestamps have to be matching overall for the content
[23:19:15 CET] <JEEB> as in, 3min in profile A is 3min in profile B
[23:19:17 CET] <JEEB> that makes sense
[23:19:37 CET] <JEEB> as in, they have to share the overall time line
[23:19:42 CET] <saml> Matching content in Variant Streams MUST have matching  Discontinuity Sequence Numbers
[23:19:49 CET] <saml> along with that, you need to have same gop
[23:20:17 CET] <saml> x.1.ts -> variant.2.ts   to continue this smoothly
[23:20:27 CET] <saml> x.ts-1   -> variant.ts-2
[23:20:46 CET] <JEEB> uhh, no. I'm pretty sure that doesn't read like that because then every mux would have to be equal in MPEG-TS packet count
[23:20:58 CET] <saml> otherwise, if you do have to go from x.ts-1 to variant.ts-2, you'll land at weird timestamp
[23:21:24 CET] <saml> hrm i see. probably i'm wrong. i'm noob
[23:21:29 CET] <JEEB> oh, wait no. that's the discontinuity flags in the playlist
[23:21:41 CET] <JEEB> so it just means that if you have discontinuity in one profile, you have to have it in all
[23:21:51 CET] <JEEB> which maeks sense, since you are using the same input for all
[23:22:24 CET] <JEEB> saml: I think it basically tells you that you cannot use the location of a segment in the array of available segments as a synchronizer there somewhere
[23:22:35 CET] <JEEB> it specifically says that you cannot use that as the way to switch
[23:22:45 CET] <JEEB> instead you have to go by the timestamps in the playlist, which makes sense
[23:22:51 CET] <JEEB> I just don't remember the exact wording
[23:24:05 CET] <saml> how do I convert container format only so that I can stream mp4 to ffmpeg command?
[23:24:46 CET] <saml> hrm i see. player just has to be smarter
[23:24:59 CET] <saml> instead of incrementing index
[23:26:26 CET] <JEEB> saml: right, 6.3.2 , the thing that starts with A client MUST NOT assume"
[23:31:36 CET] <alexpigment> saml: to convert container format, you just use ffmpeg -i [input] -c copy [output.ext]
[23:31:41 CET] <alexpigment> the extension usually implies the format
[23:31:50 CET] <alexpigment> but if not, you can put -f [format] after the input
[23:32:11 CET] <alexpigment> usually for streaming, it's just ffmpeg -i [input.mp4] -c copy [output.ts]
[23:44:53 CET] <geuis> kepstin: patch confirmed
[23:47:46 CET] <kepstin> Good to know, thanks for testing.
[23:48:49 CET] <saml> thanks all
[23:59:26 CET] <linux50> hello everyone.
[00:00:00 CET] --- Thu Feb  1 2018