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

[burek]

[00:00:02 CEST] <vader-> The original Source is VHS btw
[00:21:19 CEST] <alexpigment> vader: is it possible that it's actually dark, but your video card on the capture system is set to a different color range? (e.g. Full vs Limited)
[00:22:09 CEST] <alexpigment> generally speaking, Windows Media Player uses its own color range settings in my experience, but VLC is definitely affected by that setting
[00:22:43 CEST] <alexpigment> Changing Limited to Full usually darkens playback to the correct levels
[01:14:20 CEST] <vader-> where is this setting at?
[01:43:36 CEST] <thebombzen> what is the purpose of using a partial color range?
[01:43:44 CEST] <thebombzen> compared to full?
[01:43:59 CEST] <thebombzen> what does one gain from this?
[01:47:28 CEST] <TD-Linux> room for overshoot and undershoot for your ADC
[01:47:49 CEST] <iive> idct stuff
[01:47:56 CEST] <TD-Linux> when capturing ye olde NTSC signal you'd preserve any out of range signals
[01:48:18 CEST] <TD-Linux> idct expands range anyway and JPEG gets away with full range
[01:51:22 CEST] <thebombzen> but if jpeg can do it
[01:51:26 CEST] <thebombzen> why can't NTSC
[02:08:42 CEST] <TD-Linux> ye olde convention
[02:09:07 CEST] <iive> it has nothing to do with ntsc
[02:10:02 CEST] <vader-> ya i don't really have the option to change many settings on the Blackmagic H.264 recorder
[02:11:50 CEST] <iive> it is more of a stuff of keeping the black back and the white white, after encoding and decoding.
[02:12:11 CEST] <dystopia_> heh
[02:12:37 CEST] <TD-Linux> yes I believe it came from SDI
[02:12:40 CEST] <dystopia_> i bought one of those black magic intensity pro 4k cards
[02:12:40 CEST] <iive> it involves stuff like color format changes, transformation and quantization.
[02:12:50 CEST] <dystopia_> had nothing but trouble with it and it's software
[02:15:10 CEST] <vader-> ya im working on a VHS archiving project
[02:15:41 CEST] <vader-> trying to capture about 400-500 tapes
[02:15:48 CEST] <vader-> that range from like 10-30 years old
[02:16:06 CEST] <vader-> all editing, recorded, mastered, etc by amateurs
[02:16:53 CEST] <vader-> so right now im just ripping them in with H.264 compression since this is what this box does... hardware H.264 compression
[02:17:06 CEST] <vader-> running at 5Mbps bitrate which seems to be decent
[02:17:12 CEST] <vader-> anything more has really diminishing returns
[02:17:25 CEST] <vader-> and anything less isn't really worth the savings
[03:36:55 CEST] <Justin_> Hi all, I have some questions about combining zoompan (and other filters) with a crossfade effect.
[03:37:19 CEST] <Justin_> i pasted my code to the pastebin, here is the question:
[03:38:30 CEST] <Justin_> if you input two images 640*480 px to this code, it will make kind of a slideshow, the first image will have the zoompan and then it will fade into the second image.
[03:39:14 CEST] <Justin_> basically, the fadein this code is done speerate to the zoompan, and you will notice that it seems like it zooms back out befor ethe fade
[03:39:40 CEST] <Justin_> I'm not sure how to sync the [crossfade] with the final frame of the zoompan
[03:40:06 CEST] <jaredp> Hey everyone - can someone point me towards the documentation on the dash format? I don't see it on the official list of formats but it comes up when you run ffmpeg -formats
[03:40:51 CEST] <Justin_> does anyone know how I can better integrate the zoompan with the crossfade effect
[03:41:32 CEST] <Justin_> @jaredp, not me, sorry
[03:42:17 CEST] <Justin_> in the pastebin the title of the paste is "crossfade with zoompan"
[08:41:15 CEST] <turlando> Hello everyone
[08:42:31 CEST] <turlando> I'm trying to write a tiny python script that will just get some audio files from a queue, make a continous stream with defined codec and bitrate and stream it over RTP
[08:43:09 CEST] <turlando> Since I didn't actually find any actively supported python library I'm just scripting around ffmpeg
[08:43:41 CEST] <turlando> I succesfully accomplished the stream part with ffmpeg -re -i in.ogg -map 0:0 -c:a:0 libvorbis -b:a:0 192k -f rtp rtp://127.0.0.1:1234
[08:45:18 CEST] <turlando> Since the client listening to che stream will exit as soon as the stream end on the server I'm trying to concatenate multiple files to send over rtp
[08:45:51 CEST] <turlando> I have these two problems: I need a way to enqueue tracks, I need a way to play silence when the playlist reached its end
[08:46:21 CEST] <turlando> Is this even possible with ffmpeg? Is it possible to script that?
[08:51:06 CEST] <das_> hello
[08:51:36 CEST] <turlando> hi
[08:58:20 CEST] <jleclanche> I'm trying to record a video; audio is fine but the video itself is coming out running at 10x speed. Any idea why? Arch linux, this is the command line I'm using: ffmpeg -f video4linux2 -s 1024x576 -r 30 -i /dev/video0 -f alsa -i pulse -acodec libmp3lame -ab 48k
[09:22:47 CEST] <thebombzen> turlando: there isn't a way to do that with ffmpeg
[09:23:14 CEST] <thebombzen> but if you have your audio muxed into .ts for example, you can just concatenate .ts files
[09:23:28 CEST] <thebombzen> and have ffmpeg read from standard input
[09:23:39 CEST] <thebombzen> and use a concatenation-friendly container to feed files to it, like .ts
[09:23:57 CEST] <thebombzen> although I recommend using libopus instead of libvorbis because it's better for streaming
[09:24:03 CEST] <thebombzen> (and better quality audio)
[09:24:22 CEST] <turlando> thebombzen I will stream mostly ogg and maybe some mp3. Isn't ts just a container format? I need to encode my audio to maybe aac inside the ts or not?
[09:24:33 CEST] <thebombzen> yes mpegts is a container
[09:24:47 CEST] <thebombzen> but mpegts is a container that supports concatenation
[09:24:58 CEST] <thebombzen> also you should be using opus audio
[09:25:10 CEST] <turlando> I got all my library in ogg, too late :P
[09:25:14 CEST] <turlando> vorbis*
[09:25:23 CEST] <thebombzen> well you're transcoding it anyway
[09:25:58 CEST] <thebombzen> either way
[09:26:18 CEST] <thebombzen> using a concatenation-friendly container like mpegts is probably the easiest
[09:26:31 CEST] <thebombzen> cause then ffmpeg reading from standard input will effectively be reading a continuous stream of audio
[09:26:46 CEST] <turlando> thebombzen I see, but I still need to handle silence and such corner cases, it still feels like an hack
[09:27:06 CEST] <thebombzen> well have an audio file of pure silence
[09:27:31 CEST] <turlando> The ffmpeg that will stream using rtp still needs the source file hasn't got an end
[09:27:34 CEST] <thebombzen> given that your stream has to be broadcasting 24/7, the only way to send silence is to just send audio that is silent
[09:27:53 CEST] <thebombzen> and yea that's why you have ffmpeg read from standard input
[09:27:56 CEST] <thebombzen> rather than from a file
[09:28:09 CEST] <thebombzen> and you feed the audio to ffmpeg's standard input
[09:28:55 CEST] <jleclanche> @@@++
[09:28:56 CEST] <turlando> That is a great hint, thank yoy. I was just saying that I must be faster to transcode than to stream, which can seem obvious but still can give birth to race conditions
[09:29:12 CEST] <thebombzen> what race conditions
[09:29:35 CEST] <thebombzen> jleclanche: yes @@@ should have 1 added to it
[09:30:00 CEST] <jleclanche> keyboard fell :(
[09:30:12 CEST] <turlando> If not race conditions it will definitely make the streamer ffmpeg kill itself
[09:30:21 CEST] <thebombzen> that makes no sense
[09:30:32 CEST] <thebombzen> ffmpeg exits if it reaches end-of-file on input
[09:30:43 CEST] <thebombzen> but if it's reading from standard input it won't reach end-of-file, unless you send it
[09:30:47 CEST] <thebombzen> so just don't do that
[09:31:02 CEST] <turlando> I was referring to files as input
[09:31:09 CEST] <turlando> Which was by bad design
[09:31:29 CEST] <thebombzen> yea that won't make ffmpeg kill itself
[09:31:37 CEST] <thebombzen> it'll make ffmpeg gracefully exit
[09:31:41 CEST] <thebombzen> if it reaches end-of-file
[09:31:49 CEST] <thebombzen> so maybe you should use the thing I suggested
[09:31:53 CEST] <thebombzen> which is to read from standard input
[09:32:20 CEST] <thebombzen> instead of complaining that what you're already doing won't work
[09:33:05 CEST] <thebombzen> and I have to go to bed
[09:33:50 CEST] <turlando> Maybe I am bad at exmplaining myself but I was just saying thank you and that your way is a solution to my problem
[10:01:16 CEST] <Snowie> Hi all, hope all is well. Trying to convert some files for use on PS4, feel like I'm getting closer, but I'm obviously missing something. This is what I have so far but i'm getting an error: ffmpeg -i input.mkv -sn -vcodec mpeg4 -profile:v high -level 4.2 -acodec mp3 output.mkv
[10:02:02 CEST] <Snowie> target file types available are http://manuals.playstation.net/document/en/ps4/music/mp_format_m.html
[10:02:37 CEST] <Snowie> Error message is Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[10:08:22 CEST] <Snowie> actually, going for h.265 instead seems to be building. hopefully it works, doing it for someone else. Anyone able to confirm if this will satisfy the PS4's unusually tight requirements? Error while opening encoder for output stream
[10:08:26 CEST] <Snowie>                 #0:0 - maybe incorrect parameters such as bit_rate, rate, width
[10:08:35 CEST] <Snowie> sorry, wrong paste
[10:09:11 CEST] <Snowie> ffmpeg -i AdventureTimeTest.mkv -sn -vcodec h264 -acodec mp3 AdventureTimeTestConverted.mkv
[10:10:39 CEST] <BtbN> The PS4 can play hevc?
[10:10:44 CEST] <JEEB> not as far as I know
[10:15:17 CEST] <Snowie> hevc? is there something i need to do differently for the audio or video encoding?
[10:15:53 CEST] <JEEB> HEVC is the original name for H.265
[10:15:53 CEST] <Snowie> supported formats are super strict, listed here http://manuals.playstation.net/document/en/ps4/music/mp_format_m.html
[10:15:59 CEST] <JEEB> or well, name of another standards body :P
[10:16:09 CEST] <Snowie> JEEB: ahh, i see
[10:16:10 CEST] <JEEB> (which was given to it before ITU-T blessed it)
[10:16:20 CEST] <JEEB> just like AVC is the ISO/IEC name for H.264
[10:16:26 CEST] <JEEB> H.xxx is ITU-T
[10:17:47 CEST] <Snowie> Friend of mine got these files, and they are mkv, which is a supported container, but within that they are strict. Audio was originally in what looked like the right format too though, same with video. I think i'm clutching at straws now
[10:21:23 CEST] <Snowie> I think i want to try and crack this nut and script it so it can just work. Frustrating i don't have the ps4 here to test it though.
[10:37:27 CEST] <termos> when getting the time_base from the deprecated AVCodecContext in AVStream i'm getting 1/6000, but when I'm getting it from the one I create myself with avcodec_alloc_context3 + avcodec_parameters_to_context I'm getting 0/2 as timebase from that AVCodecContext
[10:37:47 CEST] <termos> is this a bug? if not how will I be able to obtain the correct codec time_base?
[10:38:57 CEST] <termos> for audio they are the same, both time_bases are 1/44100
[10:51:06 CEST] <termos> I see the codecpar are not containing any time_base information either, not framerate either (but they have sample_rate)
[11:05:06 CEST] <DemoniacMilk> hey everony
[11:05:18 CEST] <DemoniacMilk> *everyone
[11:06:47 CEST] <DemoniacMilk> are there any ressources that might help me to cross compile ffmpeg for an ARM based system?
[11:35:46 CEST] <Snowie> So im settling with this to convert to ps4 compatible video. ffmpeg -i Test.mkv -codec:v h264 -profile:v high -level 4.2 -codec:a ac3 TestConverted.mkv
[11:36:13 CEST] <Snowie> can anyone tell me if ac3 (Dolby) as listed on ps4 manual is just fine to encode as ac3 though
[11:37:04 CEST] <Snowie> like, is ac3 just a Dolby proprietary format or is dolby ac3 a subset of ac3
[11:37:13 CEST] <Snowie> googling just got confusing
[11:39:02 CEST] <BtbN> you probably don't want to encode ac3.
[11:39:06 CEST] <BtbN> Just use aac and libx264
[11:40:10 CEST] <Snowie> BtbN: ok. ps4 only supports aac cl though. Do I need to add a parameter to get that output in the encoding?
[11:40:18 CEST] <BtbN> cl?
[11:40:33 CEST] <Snowie> BtbN: sorry LC http://manuals.playstation.net/document/en/ps4/music/mp_format_m.html
[11:40:39 CEST] <BtbN> That's normal AAC.
[11:40:46 CEST] <Snowie> ok, perfect
[11:42:06 CEST] <Snowie> I think the issue is just that most videos found on the web are encoded for best fit, so older mpeg standards, where ps4 ONLY plays the latest (high 4.2). Does that make sense though? or am i misunderstanding the whole thing
[11:42:06 CEST] <DemoniacMilk> guys, has anyone of you cross compiled ffmpeg before?
[11:43:08 CEST] <DemoniacMilk> im trying to compile for an arm based system using    arm-linux-gnueabi-gcc -I ./ ffmpeg.c -o ffmpeg_ARM
[11:44:10 CEST] <DemoniacMilk> compilation is started, but stops saying something like      /tmp/ccrUvte3.s: Assembler messages:     /tmp/ccrUvte3.s:255: Error: Invalid Instruction »cmovg r3,r2«
[11:45:28 CEST] <DemoniacMilk> i guess the instruction set and names might differ for the target platform, but i dont know how to work around that
[11:56:21 CEST] <DemoniacMilk> oh i think i figured it out
[11:56:51 CEST] <DemoniacMilk> i have to run configure, providing info on the cross compilation (target os, target arch, cross compiler) then make?
[12:53:52 CEST] <BtbN> Snowie, a h264 decoder that supports high can always decode main and constrained baseline as well.
[12:54:04 CEST] <BtbN> Normal baseline is a bit different, but most of them support it as well
[13:05:24 CEST] <Tom_B> I'm using ffmpeg to convert video to HLS, is there any way to reduce the amount of time ffmpeg needs before it starts processing the input and creating the output? By default there's quite a few seconds delay
[13:05:48 CEST] <__jack__> obviously, not
[13:07:16 CEST] <vlt> Tom_B: Are you using the "-ss" option? If yes, there's a difference between putting it before and after the "-i" arg.
[13:09:55 CEST] <Tom_B> I'm not seeking, I'm connecting to a live stream and re-encoding it, it's acceptable but there's a 5-10 second delay before it starts processing any output. ffmpeg shows me stream information and a bit of debug output. I wondered if somehow disabling this would improve startup time
[13:16:39 CEST] <BtbN> you can't avoid the startup delay of joining a livestream
[13:16:53 CEST] <BtbN> It has to wait at least for the next IDR Frame to come by
[13:17:05 CEST] <BtbN> which can be anything between 1 and 10 seconds
[13:17:15 CEST] <BtbN> or even more for weird stream setups
[13:21:44 CEST] <Tom_B> ah thanks, makes sense
[13:23:05 CEST] <libertas> hi, -autoexit for ffplay doesn't seem to work in the following command
[13:23:10 CEST] <libertas> ffplay -autoexit -loglevel quiet -t 3 -x 800 -y 600 ./VID_20170131_194035.3gp
[13:23:48 CEST] <libertas> I'm even unable to close the video window when clicking the close button
[13:24:20 CEST] <libertas> have to Ctrl+c the bash command to close the window
[13:24:31 CEST] <libertas> any tips for this problem?
[13:25:39 CEST] <libertas> q, Esc don't work, too
[13:28:55 CEST] <dwarfh> whose responsibilty of syncing dispay video stream? is it programmers? or avcodec_decode_video2 take of? Actually I have small program which plays video but it plays very fast when sound is disabled
[13:30:55 CEST] <kepstin> dwarfh: it's up to the player to sync a/v; the decoder only gives you the info needed to do it
[13:31:49 CEST] <kepstin> if you have sound it's "easy", because the sound card consumes it in realtime, so you just have to sync video frames to the audio. But with video only, you have to time it yourself with os clock.
[13:39:22 CEST] <dwarfh> kepstin: ok great, thanks, I was confuse with pts and dts values, once again thanks for clearing my doubt
[13:54:35 CEST] <Tyras> Could someone help me with YUV (UYVY/YUY2) macropixels? How do I store in a macropixel a black pixel alongside a "colored" pixel?
[15:37:14 CEST] <bf_> I have a list of x264 frames and I want to convert them to mp4 with ffmpeg. What is the best way to do it?
[15:37:38 CEST] <bf_> The x264 frames are extracted from an RTMP connection
[15:54:55 CEST] <BtbN> You mean you have a raw .h264 file?
[15:56:03 CEST] <bf_> BtbN: No I am extracting frames out of an rtmp stream
[15:56:30 CEST] <BtbN> So, just use nignx-rtmp?
[15:56:49 CEST] <bf_> BtbN: I spent yesterday with nginx-rtmp, it is very buggy, both in HLS and DASH
[15:57:01 CEST] <bf_> As I need only a subset of its features I want to roll my own solution
[15:57:12 CEST] <bf_> Because they all keep on using ffmpeg anyways
[15:57:21 CEST] <BtbN> It works great for me, for HLS and rtmp re-streaming.
[15:57:42 CEST] <BtbN> nginx-rtmp is by far the best rtmp server you'll find.
[15:57:46 CEST] <bf_> HLS works but it does not respect the segment size / playlist length. I always end up with 30sec deplay
[15:57:47 CEST] <BtbN> ffmpeg is not one, btw.
[15:57:58 CEST] <BtbN> so you will have to write one yourself, which is not a simple task at all
[15:57:58 CEST] <bf_> I mean ffmpeg is doing heavy listing in nginx-rtmp, right?
[15:58:05 CEST] <BtbN> no?
[15:58:27 CEST] <BtbN> you can call ffmpeg via exec or so, but nginx-rtmp does not depend on ffmpeg.
[15:58:36 CEST] <bf_> hm?
[15:58:54 CEST] <bf_> I read parts of its source and took away that it is indeed using ffmpeg
[15:59:26 CEST] <bf_> the maintainer Roman Arutyunyan is a brilliant man but unfortunately he isn't maintaining the project any more
[15:59:41 CEST] <bf_> I have already hit two bugs which are listed as 2+ year old issues..
[15:59:55 CEST] <bf_> And when I start compiling my own nginx I can also write my own rtmp server
[16:00:09 CEST] <BtbN> No idea what you are doing with it, but it works great for me on the latest version of nginx.
[16:00:20 CEST] <BtbN> Yeah, sure, write your own rtmp server...
[16:00:32 CEST] <bf_> I mean there is already a node.js / cpp rtmp server out there
[16:00:42 CEST] <bf_> which gives me a stream of x264 video frames and aac audio frames
[16:01:12 CEST] <BtbN> So you misconfigured nginx-rtmp, and instead of figuring out the issue, you start to re-write it?
[16:01:31 CEST] <bf_> why misconfigured?
[16:01:42 CEST] <bf_> I read 20+ different configs and tried all day
[16:01:49 CEST] <termos> with avcodec_send_frame/avcodec_receive_packet for encoding, will either of these functions do any encoding or will everything be done in a background thread? Asking because I'm thinking of doing a bunch of avcodec_receive_packet's in one single thread and I don't want there to be any performance issues
[16:02:00 CEST] <bf_> HLS is working but with 30+ sec delay, but dash is not working (with listed bugs)
[16:02:21 CEST] <bf_> So I want to build a node.js-based OBS -> RTMP -> DASH thing
[16:02:57 CEST] <BtbN> HLS has inherent delay by design, same for DASH. No magic can change that.
[16:03:12 CEST] <bf_> But it shouldn't be 30s on a local stream
[16:03:14 CEST] <kepstin> having a delay is an inherent part of segmented streaming formats... 30s is consistent with a normal 3 segment delay 10s segment hls stream
[16:03:27 CEST] <BtbN> With 10 seconds segment length, 30s delay is exactly what one would expect
[16:03:45 CEST] <kepstin> you can use smaller segments to reduce the delay, but it reduces video coding efficiency, so :/
[16:03:52 CEST] <bf_> I was using hls_fragment 2s; hl_playlist_length 4s;
[16:03:56 CEST] <bf_> it was not working
[16:04:05 CEST] <kepstin> bf_: and you re-encoded the video to have 2s between keyframes?
[16:04:07 CEST] <BtbN> it will only cut to the smallest possible gop length
[16:04:15 CEST] <bf_> it is an obs live stream
[16:04:17 CEST] <BtbN> so if you have 10 second GOPs, it will product 10 second segments
[16:04:55 CEST] <bf_> I can't seem to configure that in OBS
[16:05:22 CEST] <kepstin> bf_: https://i.imgur.com/ahJ6s4W.png
[16:05:22 CEST] <bf_> Is GOP length defined through bitrate?
[16:07:40 CEST] <alexpigment> GOP = -g ##
[16:07:51 CEST] <alexpigment> or -x264-params keyint=##
[16:08:04 CEST] <bf_> I'm trying to use imgur, my upload fials
[16:08:20 CEST] <bf_> https://ibb.co/hiOaMF
[16:08:33 CEST] <bf_> Linux f*cking with me again -.-
[16:08:48 CEST] <bf_> kepstin: I dont have that option
[16:09:00 CEST] <Tom_B> is it possible to select an audio streamm using a tag? E.g. select by language rather than ID? As each source can have streams in different indexes, using 0:1 or whatever requires knowing the stream order before launching ffmpeg
[16:09:39 CEST] <bf_> alexpigment: for what does abbreviation gop stand? I cannot find it https://www.google.de/search?hl=de&q=gop#hl=de&q=gop+ffmpeg&*
[16:10:02 CEST] <alexpigment> Group Of Pictures
[16:10:11 CEST] <alexpigment> it's the arrangement of I, P, and B frames
[16:10:23 CEST] <alexpigment> a value of -g 1 is only I frames
[16:12:18 CEST] <bf_> thank you alexpigment
[16:13:03 CEST] <alexpigment> np
[16:13:11 CEST] <bf_> so if I get my users to configure obs to the right framerate then HLS would actually work with 2sec delay?
[16:13:59 CEST] <kepstin> not framerate, but gop length (often called "keyframe interval")
[16:14:07 CEST] <kepstin> and you probably won't get down below around 6s
[16:14:49 CEST] <bf_> Ok that'd be so much better than 30s
[16:15:05 CEST] <bf_> So just to make it clear, if I would've switched to dash this obs setting still would've given me 30sec delay?
[16:15:23 CEST] <kepstin> depends on the player, but probably around 20-30s, yes
[16:15:33 CEST] <bf_> Why is the default then 30?
[16:15:52 CEST] <bf_> It looks like a premature optimization for recording storage space?
[16:16:11 CEST] <kepstin> the default gop size of 10 seconds provides decent coding efficiency, and works ok for non-segmented streaming formats like rtmp
[16:17:05 CEST] <bf_> thank you. just to make sure: GOP = keyframe interval?
[16:17:05 CEST] <kepstin> (actually, i'm not sure that 10s is the default, but most encoders for hls end up doing something close to that)
[16:17:25 CEST] <bf_> Or is GOP a higher concept?
[16:18:52 CEST] <kepstin> GOP is a bit more accurate, since keyframe is sometimes used to refer to any I frames, but a GOP specifically is one that starts with an IDR frame
[16:19:07 CEST] <kepstin> which is basically "a point where a decoder can start from"
[16:21:47 CEST] <kepstin> but most gui encoder applications will probably have a field named 'keyframe interval' which actually sets the gop size
[16:22:01 CEST] <kepstin> so in casual usage they're almost interchangable
[16:22:08 CEST] <bf_> Thanks so much
[16:22:38 CEST] <bf_> I've been diving into this topic for two days and I didn't know these small things before
[16:23:13 CEST] <bf_> I use segment_size 2s and playlist_length 4s for HLS, but it still has ~8sec delay
[16:24:01 CEST] <Tom_B> bf_ I'm doing something similar, the delay, for me, is actually due to ffmpeg opening the input (in my case a live stream)
[16:24:51 CEST] <bf_> Tom_B: I was using "hls_fragment_slicing aligned;", removed it and now I am at ~6sec
[16:26:11 CEST] <Tom_B> part of the problem is that the .m3u8 file doesn't get written until after the first segment has been created, it's a shame there's no way to create a 0.5s setgment0 then change it to a more sane number
[16:27:17 CEST] <iive> x264 has some options for low latency
[16:29:09 CEST] <DemoniacMilk> hello! im trying to compile ffmpeg for an ARM based system (since quite some time) and still have not been able to
[16:29:45 CEST] <DemoniacMilk> i got a cross compiler set up and can compile ffmpeg on my host (using either the standard gcc or the cross compiler)
[16:31:16 CEST] <DemoniacMilk> if i use the cross compiler, i need to manually start stripping the created files, because i havent figured out how to automate the strip selection
[16:31:48 CEST] <DemoniacMilk> however, when i cross compile on my host, the target does not accept the created files (says its neither a file nor a directory)
[16:32:04 CEST] <DemoniacMilk> while reading the elf header states its an executable for architecture ARM
[16:32:24 CEST] <kepstin> DemoniacMilk: that error usually means that the path to the "interpreter" (dynamic loader) is wrong
[16:33:04 CEST] <DemoniacMilk> you mean the stripping?
[16:33:45 CEST] <kepstin> no, this probably is a misconfigured cross compile toolchain that doesn't match the fs layout of your target box
[16:35:13 CEST] <bf_> Thank you very much again kepstin alexpigment and BtbN
[16:35:28 CEST] <DemoniacMilk> hm how may i find out if there is a fs mismatch?
[16:35:50 CEST] <alexpigment> does anyone know how to enable CBR mode for x265 within FFMPEG? i tried adding "-x265-params strict-cbr" (this gets ignored) and "-x265-params strict-cbr=1" (this causes a fatal error)
[16:36:01 CEST] <alexpigment> the x265-params stuff is just a mess at this point :(
[16:37:04 CEST] <kepstin> DemoniacMilk: run 'readelf -l ffmpeg' on your binary, it should print a line like "[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]" (except different, for the arm loader)
[16:37:18 CEST] <kepstin> DemoniacMilk: that has to match where the linux distro on your arm board puts the loader
[16:38:24 CEST] <DemoniacMilk> "[Requesting program interpreter: /lib/ld-linux.so.3]"
[16:39:04 CEST] <DemoniacMilk> while  there is only a ld-linux-armhf.so.3 in /lib
[16:39:46 CEST] <DemoniacMilk> any hint where i can find out how to change the requested interpreter?
[16:40:06 CEST] <kepstin> DemoniacMilk: sounds like you have the wrong cross compile env
[16:40:29 CEST] <DemoniacMilk> please noooo :D
[16:40:40 CEST] <DemoniacMilk> alright ill try to set that up again
[16:41:07 CEST] <kepstin> make sure you build one for armhf this time :)
[16:42:53 CEST] <DemoniacMilk> i hope ill figure out how to
[16:43:11 CEST] <DemoniacMilk> got my hands on all this stuff (inlcuding linux) a few days ago so im really lost sometimes
[16:44:15 CEST] <DemoniacMilk> oh one more question!
[16:44:33 CEST] <DemoniacMilk> i tried to build ffmpeg on the target instead of cross compiling it on the host
[16:44:52 CEST] <DemoniacMilk> but i got a ton of errors when running the configuration script
[16:45:03 CEST] <DemoniacMilk> ./configure: line 466: pr: command not found
[16:45:20 CEST] <DemoniacMilk> i guess i need to install some missing packet?
[16:45:56 CEST] <kepstin> DemoniacMilk: yeah, you must have a really minimal linux distro on there. is this a raspberry pi or something? what linux distro?
[16:46:07 CEST] <DemoniacMilk> arago i think
[16:46:25 CEST] <DemoniacMilk> its the same chip that is used in beablebone blacks i think
[16:47:00 CEST] <DemoniacMilk> the linux distro was provided as part of a linux SDK by texas instruments, so im not entirely sure whats in there
[16:47:31 CEST] <kepstin> well, arago has decent docs for setting up a cross dev env, including a prebuilt compiler: http://arago-project.org/wiki/index.php/Setting_Up_Build_Environment
[16:48:06 CEST] <kepstin> i have no idea how the packaging on that works, or how to get additional tools :/
[16:48:08 CEST] <DemoniacMilk> arm-linux-gnueabihf/ is the one i used actually (just randomly saw that in the doc)
[16:48:17 CEST] <DemoniacMilk> its got opkg installed
[16:48:24 CEST] <DemoniacMilk> but im not getting familiar with that
[16:50:25 CEST] <DemoniacMilk> alright ill try to get things set up correctly here, thanks a lot for your help!
[16:52:05 CEST] <alexpigment> FFMPEG doesn't seem to honor "strict-cbr" as an x265 param, and it fails when specifying "strict-cbr=1" (this trick is necessary for some x265-params)
[16:52:46 CEST] <alexpigment> additionally ratetol=1 and -bt=1 both give errors stating that the value 0.000000 is out of range (i'm not specifying 0.000000 obviously)
[16:53:22 CEST] <JEEB> x265-params should be passing options to the libx265 API as-is
[16:53:36 CEST] <JEEB> so if it doesn't work then the API usage could be derp'd
[16:53:37 CEST] <alexpigment> i agree that they should :)
[16:53:45 CEST] <JEEB> no, I mean it most likely is
[16:53:51 CEST] <JEEB> so most issues are then on the libx265 side
[16:54:29 CEST] <alexpigment> well, does anyone have any ideas on how to make a CBR H.265 stream given the problems noted above?
[16:54:45 CEST] <kepstin> the libx265 api requires being passed pre-split parameters key, value, iirc, so the string has to be pre-parsed in ffmpeg a bit :/
[16:55:18 CEST] <kepstin> the trick is to figure out what value some of these flag parameters actually need to work :/
[16:56:05 CEST] <alexpigment> well, i'm all open for any hints or suggestions. bt and ratetol obviously ignore whatever value you enter
[16:56:14 CEST] <alexpigment> strict-cbr isn't honored
[16:57:01 CEST] <alexpigment> oh wait
[16:57:05 CEST] <alexpigment> i'm an idiot
[16:57:09 CEST] <kepstin> strict-cbr should work if you can figure out the correct value to give it
[16:57:19 CEST] <alexpigment> ok, so try something other than 1?
[16:57:44 CEST] <kepstin> you could try the string "true" and the empty string, i guess :/
[16:57:49 CEST] <alexpigment> anyway, ratetol wasn't working because i had a bt from earlier elsewhere in the chain with an actual zero
[16:57:59 CEST] <alexpigment> my bad ;)
[16:58:08 CEST] <Tom_B> is there any way to automatically set one of many possible decoders? I have various streams, some are h264, others are mpegts. For the h264 streams I want to use h264_cuvid decoding, but only when it's applicable, is it possible to specify different decoders depending on the input type?
[16:58:15 CEST] <kepstin> "ratetol" isn't even an x265 option as far as I can see
[16:58:15 CEST] <alexpigment> either way, ratetol says it's an unknown parameter
[16:58:30 CEST] <thebombzen> hmmm... I'm having issues with framerates in matroska containers
[16:58:33 CEST] <alexpigment> -bt is accepted if 1 or more, but doesn't have any effect
[16:58:57 CEST] <alexpigment> keptin: i'll try 'true'. thanks for the suggestion
[16:58:59 CEST] <thebombzen> for some reason the matroska muxer/demuxer reports 120 fps erroneously: http://sprunge.us/XHcD
[16:59:12 CEST] <kepstin> alexpigment: the options you can use should be the same as the cli options here: https://x265.readthedocs.io/en/default/cli.html
[16:59:26 CEST] <kepstin> (in the x265-params string)
[16:59:29 CEST] <thebombzen> I'm not entirely sure why
[16:59:40 CEST] <alexpigment> yeah, i was only using ratetol because at some point this worked and it was deprecated
[16:59:58 CEST] <alexpigment> i was hoping it still worked because strict-cbr wasn't working for me
[17:01:19 CEST] <kepstin> thebombzen: what makes you think that's an error? it depends on the video souce, but sometimes if you have mixed 24 and 30fps content, it'll be encoded into a container with a 120fps nominal rate
[17:01:42 CEST] <thebombzen> kepstin: because that should be listed as "tbr" not "fps"
[17:01:57 CEST] <thebombzen> "fps" is the container's reported cfr
[17:02:10 CEST] <thebombzen> whereas "tbr" is the timebase rate required to display alll frames accurately
[17:02:35 CEST] <kepstin> right, but that original input file is reporting a framerate of 120, so that's just being preserved all the way through.
[17:02:48 CEST] <thebombzen> no it's not
[17:02:57 CEST] <thebombzen> the original input file is not 120 fps
[17:03:09 CEST] <thebombzen> and if you look again it's not being preserved by the mp4 container
[17:03:18 CEST] <thebombzen> which correctly reports 25.93
[17:03:47 CEST] <kepstin> that's... a really strange framerate
[17:04:43 CEST] <thebombzen> I agree
[17:04:49 CEST] <thebombzen> but it's also what the original content had
[17:05:04 CEST] <kepstin> I have never heard of that being used anywhere. and to be honest, '120' tbr is strange too, the 120 rate is normally only used on ntsc stuff where it's actually 120/1.001
[17:05:24 CEST] <kepstin> so, you have a strange input file, and it's behaving strangely? :/
[17:05:45 CEST] <thebombzen> no what I find strange is the difference in behavior between matroska and mp4
[17:06:07 CEST] <kepstin> it's probably just a quirk of how metadata is stored vs calculated in the different formats
[17:06:23 CEST] <thebombzen> actually to be honest
[17:06:29 CEST] <thebombzen> the true original was muxed by libmatroska
[17:06:35 CEST] <Tom_B> can you specify multiple values for -c:v before -i and have ffmpeg try each in order? At the moment it works out "conversion failed" can I specify that "if conversion fails, try this decoder instead"
[17:06:36 CEST] <thebombzen> and the video was this: Video: h264 (High), yuv420p(tv, bt709/unknown/unknown, progressive), 1280x720, SAR 1:1 DAR 16:9, 500 fps, 120 tbr, 1k tbn, 719.28 tbc (default)
[17:06:41 CEST] <kepstin> if there's no problem playing the video, then I wouldn't worry about it...
[17:06:58 CEST] <thebombzen> is it because matroska uses a 1k tbn?
[17:07:07 CEST] <thebombzen> speaking of which, is there any way to make it NOT use a 1k tbn?
[17:07:15 CEST] <thebombzen> because I've had problems with matroska's 1k timebase
[17:07:34 CEST] <kepstin> thebombzen: you can theoretically use a different power of 10, but it's limited to only powers of 10 and i've never seen a muxer supporting anything other than 1k
[17:07:49 CEST] <thebombzen> that sounds like a limitation of matroska
[17:07:53 CEST] <kepstin> yep
[17:08:01 CEST] <thebombzen> but what else should you use
[17:08:18 CEST] <thebombzen> I haven't found anything else that supports everything
[17:08:30 CEST] <kepstin> if you need to actually preserve timebase in intermediate stuff, you could use nut, I think that does it.
[17:08:39 CEST] <thebombzen> nut doesn't support hevc or opus
[17:08:51 CEST] <thebombzen> which it should, but it doesn't
[17:08:53 CEST] <kepstin> hmm, that's annoying
[17:09:27 CEST] <kepstin> but yeah, I think the fps code in ffmpeg for matroska really just tries to "guess" the timebase and framerate that fits the video
[17:09:56 CEST] <thebombzen> http://sprunge.us/haGF
[17:10:12 CEST] <thebombzen> wait not that
[17:10:34 CEST] <thebombzen> http://sprunge.us/BEgb
[17:10:34 CEST] <thebombzen> this
[17:10:37 CEST] <kepstin> (if you get messages like 'past duration too large' when transcoding a matroska file, it means the guess was wrong (framerate too low)
[17:10:39 CEST] <kepstin> )
[17:10:59 CEST] <thebombzen> if you get that, how do you fix it?
[17:11:15 CEST] <thebombzen> should I use -vsync cfr?
[17:13:26 CEST] <kepstin> i usually end up rewriting the video timestamps with filters :/
[17:14:34 CEST] <kepstin> some reports are that -vsync 0 -copytb 0 might work :/
[17:15:26 CEST] <kepstin> or using the -r input option, if you know the input is supposed to be cfr and you know the exact framerate
[17:18:13 CEST] <kepstin> (i only found out what that 'past duration too large' message even meant when I was doing some work on the 'concat' video filter to handle concatenating sources with different framerates)
[17:18:52 CEST] <thebombzen> -copytb 0? what does that do
[17:18:55 CEST] <alexpigment> ok, here's a more basic question. has anyone here ever been able to get x265 to honor a bitrate at all?
[17:20:57 CEST] <kepstin> alexpigment: using the regular ffmpeg -b:v option should work for bitrate in x265
[17:21:56 CEST] <alexpigment> right
[17:22:00 CEST] <kepstin> (based on the order that parameters are applied in, `-x265-params bitrate=N` should work too)
[17:22:01 CEST] <alexpigment> i'm just not seeing that being the case
[17:22:05 CEST] <alexpigment> i also tried that
[17:23:40 CEST] <kepstin> does it work in multi-pass mode?
[17:23:51 CEST] <kepstin> might just be that the 1-pass abr doesn't work very well :/
[17:23:58 CEST] <alexpigment> i haven't tried - ultimately i won't be able to use 2-pass
[17:24:27 CEST] <kepstin> using vbv might help too if you have a specific target
[17:24:45 CEST] <alexpigment> to be clear, i'm getting a *change* in bitrate when i set one vs the other, but the average bitrate just doesn't end up being close to what i set
[17:24:57 CEST] <alexpigment> yeah i tried that earlier along with a bunch of other things
[17:24:59 CEST] <alexpigment> trying again nowq
[17:25:01 CEST] <alexpigment> *now
[17:25:12 CEST] <kepstin> you're using fairly long samples to test this, right? short samples the bitrate will just not have time to converge :)
[17:25:32 CEST] <alexpigment> i'm doing 10 second tests at the moment so my tests don't take all day
[17:25:43 CEST] <kepstin> yeah, that's not nearly long enough.
[17:25:45 CEST] <alexpigment> :(
[17:26:10 CEST] <alexpigment> this is going to turn my hour of work into a day of work...
[17:26:30 CEST] <kepstin> it would probably be getting close to the average bitrate you want by the end of the 10s, but the overal file average will be off quite a bit.
[17:26:39 CEST] <alexpigment> (sorry for whining. was really just hoping to get some early positive results before i did longer tests)
[17:27:00 CEST] <bf_> kepstin: Is there data on the 90% bitrate band for users by country?
[17:27:25 CEST] <kepstin> bf_: I have no idea :/
[17:27:35 CEST] <bf_> Ok
[17:29:44 CEST] <kepstin> alexpigment: i'm kind of curious why you can't use 2-pass. Either it needs to be realtime, in which case a few 5minute tests shouldn't take too long to encode, or it's not realtime, in which case 2-pass is just as not realtime :/
[17:30:09 CEST] <kepstin> alexpigment: and unless you actually need min bitrate for some reason, crf + vbv is probably preferable
[17:30:17 CEST] <thebombzen> probably reading from a pipe
[17:30:22 CEST] <thebombzen> that would be my only explananation
[17:31:04 CEST] <alexpigment> kepstin: CRF+vbv will be the default option. i need to provide an option to fairly accurate hit a bitrate (and therefore file size) target due to burning onto disc
[17:31:14 CEST] <alexpigment> and 2-pass unfortunately isn't an option in my case
[17:31:23 CEST] <alexpigment> *accurately
[17:32:07 CEST] <kepstin> so, 2-pass is designed to do what you want, target a file size accurately. any other option is going to compromise quality.
[17:32:14 CEST] <alexpigment> right
[17:32:25 CEST] <alexpigment> quality will be compromised for predictability
[17:32:35 CEST] <alexpigment> but at high enough bitrate settings, that compromise won't be as great
[17:32:38 CEST] <kepstin> and probably not hit the file size, because without future knowledge, you have less predictability
[17:32:50 CEST] <alexpigment> and given blu-ray disc sizes, the bitrate allowance is pretty flexible in this case
[17:33:01 CEST] <alexpigment> yeah
[17:33:08 CEST] <alexpigment> that's why i'm hoping for an *actual* CBR mode
[17:33:17 CEST] <alexpigment> which the FFMPEG wiki seems to imply is the default mode, and it's clearly not ;)
[17:33:27 CEST] <kepstin> no, default is abr
[17:33:40 CEST] <kepstin> which is design to approximately hit an average bitrate over long term
[17:33:40 CEST] <alexpigment> https://trac.ffmpeg.org/wiki/Encode/H.265
[17:34:26 CEST] <kepstin> really, why can't you use 2-pass? if you're encoding from a pipe, just tee it to disk or encode to an intermediate format before doing the hevc final encode :/
[17:34:28 CEST] <alexpigment> "1-pass constant bitrate (by setting -b:v)
[17:35:04 CEST] <kepstin> alexpigment: any time you see "constant bitrate" in simple encoding guides, it's probably actually abr :)
[17:35:09 CEST] <alexpigment> it's going to be prohibitive for either a) time, or b) space considerations
[17:35:11 CEST] <kepstin> unless you're talking about mp3
[17:35:24 CEST] <BtbN> if you are targeting a specific filesize, twopass encoding it is.
[17:35:33 CEST] <alexpigment> yeah, i was really just making a joke about how ironically they only mention CBR on the wiki, as if CBR even works at all
[17:35:49 CEST] <kepstin> i hope I'm not buying any of the BDs you're encoding if you're not gonna spend the time to do a proper 2-pass encode ;)
[17:35:54 CEST] <BtbN> cbr can work. But at some point it starts inserting padding
[17:36:07 CEST] <alexpigment> no, not at all
[17:36:10 CEST] <alexpigment> i don't work for a studio
[17:36:13 CEST] <kepstin> well, i suppose at BD bitrates even a bad hevc encode is probably tolerable
[17:36:23 CEST] <alexpigment> nor am i producing any discs for distribution :)
[17:36:58 CEST] <alexpigment> yeah, i mean if you're at 30mbps or so with H.264 using CBR, it's perfectly fine
[17:37:12 CEST] <kepstin> honestly, if speed is important for you, just use x264 instead. it'll provide comparable quality at better speed, and is a more mature encoder
[17:37:43 CEST] <kepstin> the only reason to use x265 is if speed isn't a problem, so you can spend the extra time the encoder needs to beat h264
[17:37:59 CEST] <alexpigment> kepstin, i appreciate your advice and i know you're right from the standpoint of "this is a better option". however, i'm telling you the constraints i'm working within to a achieve a goal
[17:39:30 CEST] <kepstin> well, your constraints are "I need to do a 1-pass encode and hit a target filesize", and there's really no good solution to that :/
[17:39:36 CEST] <alexpigment> more than anything, i'm looking into customizability of HEVC streams to allow for the *possibility* of certain workflows. if it turns out that CBR is not functional at all, then that'll be scratched from the list. however, i can think of a handful of situations where it would be handy to have available, so i'm researching at the moment
[17:40:16 CEST] <alexpigment> well, the solutions are in the documentation - they just don't work
[17:40:42 CEST] <alexpigment> i mean i'm looking at a webpage that tells me it's possible within some small margin of error that i find to be acceptable
[17:41:18 CEST] <alexpigment> but x265 through FFMPEG at the moment, is unfortunately like the Wild Wild West
[17:41:23 CEST] <alexpigment> ;)
[17:41:32 CEST] <kepstin> well, x265 in general is like that
[17:42:05 CEST] <BtbN> x265 is real time capable for me now.
[17:42:05 CEST] <alexpigment> do you think turning the rc-lookahead way down might have any effect?
[17:42:22 CEST] <alexpigment> BtbN: at 1080p or UHD?
[17:42:27 CEST] <kepstin> but yeah, it should be possible to get"strict-cbr" working via ffmpeg, with the caveat that it's marked as experimental in the docs, so make sure you're using a recent x265 library, and it would be difficult to tell what it's actually doing :)
[17:42:48 CEST] <BtbN> 1080p at one of the fast presets
[17:42:52 CEST] <alexpigment> oh gotcha
[17:43:09 CEST] <BtbN> Well, given that a year ago it couldn't even hit 10fps...
[17:43:33 CEST] <kepstin> alexpigment: if anything, having rc-lookahead higher should help it hit the bitrate more accurately.
[17:44:02 CEST] <alexpigment> i hit ~21fps for 1080p over here on a 3770k. i'd probably do pretty close to realtime on my 5930k at home, but i haven't testesd
[17:44:33 CEST] <alexpigment> kepstin: right, but if the encoder knows it can't lookahead further, wouldn't it stop deviating from the ABR as much?
[17:46:59 CEST] <kepstin> hmm, looks like using the values "1", "true", or "yes" on boolean parameters in -x265-params should work
[17:47:08 CEST] <kepstin> at least in the current x265 source code
[17:50:27 CEST] <kepstin> the x265 encoder should be printing the params it's actually using in the log output, so you can check if they got passed through correctly
[17:50:46 CEST] <BtbN> alexpigment, what preset?
[17:50:54 CEST] <kepstin> if they're getting passed from ffmpeg, then it's really just up to the x265 encoder and whatever limitations it has in rate control :/
[17:52:09 CEST] <alexpigment> BtbN: oh sorry, that's a useful bit of knowledge, right? ;) i'm using veryfast for my current tests
[17:53:08 CEST] <alexpigment> kepstin: 1, true, and yes all fail
[17:53:28 CEST] <alexpigment> 0 gives no failure, but obviously doesn't do anything ;) same with not specifying a parameter at all
[17:54:17 CEST] <alexpigment> kepstin: i'm a bit green on logging. is there something i need to specify to get a log file?
[17:54:23 CEST] <thebombzen> how does x265 compare to x264? x264 is pretty mature and x265 is not
[17:54:43 CEST] <bencc1> how can I count hls viewers?
[17:54:45 CEST] <thebombzen> also is x265 still unusably slow for anything?
[17:54:58 CEST] <alexpigment> x265 is only 'better' in theory - i don't think it's there yet. unfortunately, it's a standard that is enforced for certain mediums
[17:55:01 CEST] <thebombzen> bencc1: that's a question for the webserver
[17:55:12 CEST] <bencc1> thebombzen: ok
[17:55:28 CEST] <thebombzen> whoever's actually serving the content over http can know that
[17:55:30 CEST] <kepstin> alexpigment: ffmpeg just prints to stderr, should be on your terminal
[17:55:39 CEST] <kepstin> interesting, strict-cbr mode only works if you're using vbv
[17:56:38 CEST] <kepstin> i think? either that or the bitrate really isn't getting passed correctly :/
[17:56:48 CEST] <thebombzen> that's not a big surprise?
[17:56:58 CEST] <thebombzen> because cbr is impossible without a vbv
[17:57:03 CEST] <thebombzen> it just has to be very small to be "strict"
[17:57:17 CEST] <kepstin> i suppose it's not. and yep, bitrate's being passed correctly, so I guess you just also need vbv params
[17:58:30 CEST] <alexpigment> just looked in the 'log' in the place i think you're referring to. it says "ABR-5000 kbps"
[17:58:49 CEST] <alexpigment> the problem is that i don't think it's being passed at all because all the "true" booleans cause a failure
[17:59:13 CEST] <alexpigment> i'll try again with vbv settings to make sure that =1/=true/=yes all still result in failures
[18:00:23 CEST] <kepstin> looks like in my quick test that the option is being accepted correctly.
[18:00:30 CEST] <kepstin> https://gist.github.com/kepstin/b05650259a6b09d689477ed4751600ce
[18:00:34 CEST] <alexpigment> ok, yeah i didn't get an error that time
[18:00:42 CEST] <BtbN> https://bpaste.net/show/daab8309b731
[18:00:44 CEST] <kepstin> (it's obviously not hitting 1M there because i'm using a 320x240 testsrc, but still)
[18:00:46 CEST] <alexpigment> i guess i was trying vbv stuff when strict-cbr wasn't being accepted
[18:00:52 CEST] <BtbN> hitting exactly 60 fps for 1080p with veryfast
[18:00:56 CEST] <alexpigment> so i wasn't using them together
[18:01:06 CEST] <thebombzen> kepstin: ffmpeg 3.1.7?
[18:01:20 CEST] <alexpigment> kepstin: thank you very much for your help. i would have been lost looking in the source code to find that info
[18:01:32 CEST] <kepstin> thebombzen: hmm, i really should put a newer ffmpeg here. this is my work box, running a packaged ffmpeg :/
[18:01:51 CEST] <thebombzen> also I noticed it says "x265 8bit"
[18:02:02 CEST] <thebombzen> can x265 do more than one bit depth per library
[18:02:10 CEST] <thebombzen> which is probably the biggest limitation of x264
[18:02:10 CEST] <kepstin> thebombzen: yes, if compiled correctly
[18:02:11 CEST] <furq> yeah but you need to enable it
[18:02:14 CEST] <alexpigment> BtbN: what CPU?
[18:02:21 CEST] <BtbN> R7 1800X
[18:02:29 CEST] <kepstin> nice :)
[18:02:43 CEST] <alexpigment> ah yeah, that thing has the advantage sheer numbers of cores
[18:02:50 CEST] <alexpigment> *advantage of
[18:03:23 CEST] <alexpigment> it's interesting to think that the new AMD chips might actually have the most use for video encoding :)
[18:03:35 CEST] <alexpigment> their weakest area up until this point
[18:03:53 CEST] <furq> BtbN: is it any good
[18:03:58 CEST] <BtbN> I'd imagine a 16 core FX chip to be also quite decent for it
[18:03:59 CEST] <thebombzen> furq: lol it says "enable main12 instead of main10"
[18:04:07 CEST] <thebombzen> doesn't sound like it supports multiple bit depths
[18:04:13 CEST] <furq> er
[18:04:21 CEST] <furq> you should just need to build it with -DHIGH_BIT_DEPTH=YES
[18:04:57 CEST] <kepstin> i think you actually have to build it multiple times, then do some extra step to link them all together? not sure
[18:05:25 CEST] <BtbN> furq, it's not the "gaming monster" some people expected. Apparently that's enough for people to shit on it.
[18:05:44 CEST] <BtbN> But an 8 core that can easily hit 3.8-4GHz, for that price, is more than decent.
[18:06:29 CEST] <furq> yeah it's like half the price of the equivalent i7 isn't it
[18:06:38 CEST] <furq> i'm not sure why people were expecting them to beat it all ends up
[18:07:05 CEST] <BtbN> The platform itself has some nasty stability issues, which I hope AGESA and BIOS updates will address.
[18:07:19 CEST] <furq> is that just the FMA3 erratum or is there more
[18:07:26 CEST] <kepstin> it's rather tempting over a xeon chip for a workstation, other than the trickiness of finding a motherboard with working ecc ram
[18:07:41 CEST] <kepstin> there's already a microcode update (bios upgrade) for the fma3 thing, iirc?
[18:07:41 CEST] <thebombzen> so if you enable HIGH_BIT_DEPTH will it support 8bit AND 10bit?
[18:07:46 CEST] <furq> yeah there is
[18:08:01 CEST] <BtbN> It's quite hard to figure out what is going on with the Microcode
[18:08:31 CEST] <BtbN> Like, I know which version I'm on, but no idea if that already has the fix
[18:08:37 CEST] <kepstin> thebombzen: no, it's more complicated than that. each build of x265 gives a library that supports only one bit depth
[18:08:54 CEST] <thebombzen> okay you're contradicting furq then
[18:09:10 CEST] <thebombzen> actually you're contradicting yourself
[18:09:13 CEST] <furq> i mean that's not my understanding but i've never actually used high bit depth
[18:09:21 CEST] <thebombzen> [12:01:50] <thebombzen> also I noticed it says "x265 8bit"
[18:09:21 CEST] <thebombzen> [12:02:02] <thebombzen> can x265 do more than one bit depth per library
[18:09:21 CEST] <thebombzen> [12:02:09] <thebombzen> which is probably the biggest limitation of x264
[18:09:21 CEST] <thebombzen> [12:02:10] <kepstin> thebombzen: yes, if compiled correctly
[18:09:22 CEST] <furq> trust someone who has over me
[18:09:27 CEST] <kepstin> it looks like you can parallel install multiple x265 builds, and it'll dynamically reload one with the correct bit depth, or you can build x265 multiple times and link them into a single library
[18:09:30 CEST] <BtbN> you have to to kind of a 4-pass-build to get all 3 bit depths
[18:09:42 CEST] <thebombzen> kepstin: what
[18:09:44 CEST] <thebombzen> how does that even work
[18:09:51 CEST] <furq> i did always wonder why high bit depth wasn't the default if it supported multiple
[18:09:54 CEST] <furq> i guess that answers my question
[18:09:57 CEST] <kepstin> https://x265.readthedocs.io/en/default/api.html#build-implications
[18:10:02 CEST] <BtbN> with a wrapper-library that redirects to the correct bit-depths version depending on the parameters.
[18:11:23 CEST] <thebombzen> kepstin: I just read that and it doesn't actually say how to do this
[18:11:26 CEST] <thebombzen> it only says that it's possible
[18:12:00 CEST] <thebombzen> "In this way you can build one or more libx265 libraries without any exported C interface and link them into a libx265 build that does export a C interface. The build which exported the C functions becomes the default bit depth for the combined library, and the other bit depths are available via the bit-depth introspection methods."
[18:12:06 CEST] <thebombzen> which it proceeds to NOT tell you how to do
[18:12:08 CEST] <BtbN> by doing quite exactly that
[18:12:22 CEST] <BtbN> you build the 2 other static libraries with the C interface disabled
[18:12:32 CEST] <thebombzen> and do you make install them?
[18:12:33 CEST] <BtbN> and then build the default one normally, but link in those two other static libraries.
[18:12:47 CEST] <thebombzen> and how do you link in those other two? with the EXTRA_LIBS options?
[18:12:57 CEST] <BtbN> With whatever way to link in stuff their build system offers
[18:13:06 CEST] <BtbN> If all else fails, by invoking the linker manually
[18:13:09 CEST] <kepstin> thebombzen: the exherbo package does it by doing the final link manually: http://git.exherbo.org/media.git/tree/packages/media-libs/x265/x265-2.3.exheres-0
[18:13:28 CEST] <kepstin> looks like they have a shell script 'multilib.sh' which does the work for you when building manually?
[18:14:35 CEST] <kepstin> https://bitbucket.org/multicoreware/x265/src/6e1edafd6dc767ae84c93bca2ff9711f38056e08/build/linux/multilib.sh?at=default&fileviewer=file-view-default there it is
[18:15:49 CEST] <alexpigment> sorry, just skimming above. does this wrapper library redirection work on Windows, or is this just a *nix thing?
[18:16:48 CEST] <kepstin> windows: https://bitbucket.org/multicoreware/x265/src/6e1edafd6dc767ae84c93bca2ff9711f38056e08/build/vc12-x86_64/multilib.bat?at=default&fileviewer=file-view-default
[18:17:21 CEST] <alexpigment> ah, this is going to be incompatible with my cross compiling setup
[18:17:53 CEST] <alexpigment> i guess if i'm cross compiling for windows on linux, i need to do some more research and possibly (read: definitely) get in over my head ;)
[18:18:06 CEST] <kepstin> it looks like they have an msys version too, which is probably more like what a cross compile would look like
[18:18:33 CEST] <alexpigment> but this is exactly what i've been needing, because i'm working with two separate copies of FFMPEG on Windows at the moment, and it's less than ideal
[18:18:35 CEST] <BtbN> I don't see how cross compiling or building on/for windows would change anything.
[18:18:37 CEST] <kepstin> I think it's actually very similar to the linux build
[18:19:11 CEST] <alexpigment> i just looked at the Visual Studio 12 references, so i assumed it's specific to Visual Studio
[18:19:39 CEST] <kepstin> alexpigment: yes, because that's the file in the vc12 directory. feel free to poke around in the source tree yourself :)
[18:19:46 CEST] <BtbN> well, obviously the compiler and linker invocations change
[18:19:50 CEST] <BtbN> but the general concept is identical
[18:20:15 CEST] <alexpigment> k, i'll have to look into the build script i'm using a bit
[18:20:34 CEST] <alexpigment> great to hear this though. i was thinking it wasn't possible to have multi-bit-depth in x265 up until now
[18:20:55 CEST] <alexpigment> or rather, in ffmpeg
[18:25:43 CEST] <thebombzen> yea I tried that
[18:25:48 CEST] <thebombzen> it didn't work, it still always forces 8bit
[18:26:42 CEST] <alexpigment> thebombzen: are you passing on the correct pix_fmt and/or profile?
[18:26:50 CEST] <Tom_B> Why doesn't this respect hls_time 2, I'm getting the default 10s segments: ffmpeg -hwaccel cuvid -deint adaptive -i INPUT -hls_time 2 -hls_list_size 30 -hls_flags delete_segments -map 0:v:0 -map m:language:eng -c:v h264_nvenc -profile:v high -pixel_format yuv444p -level 5 -qp 20 -preset slow -sn playlist.m3u8
[18:26:51 CEST] <thebombzen> explicitly setting -pix_fmt yes
[18:27:22 CEST] <thebombzen> Incompatible pixel format 'yuv420p10le' for codec 'libx265', auto-selecting format 'yuv420p'
[18:27:25 CEST] <alexpigment> does it give you any warnings when you try to pass on yuv420p10le?
[18:27:28 CEST] <alexpigment> yeah
[18:27:28 CEST] <thebombzen> ^
[18:27:32 CEST] <alexpigment> have seen that error many times
[18:28:05 CEST] <thebombzen> I'll have to investigate it later
[18:28:09 CEST] <thebombzen> when I don't have class at 1pm
[18:28:30 CEST] <alexpigment> thebombzen, it might also be worth trying x264 at some point
[18:28:43 CEST] <alexpigment> just make sure it's not a problem specific to x265 rather than x264
[18:28:58 CEST] <thebombzen> it's very clearly not a problem specific to x265
[18:28:59 CEST] <alexpigment> (both of which don't allow multi-bit-depth on my end)
[18:29:09 CEST] <thebombzen> the whole point of what I was trying was to get multiple bit depths to work in x265
[18:29:20 CEST] <alexpigment> k, i figured i'd just check since it sounds like you built with the workaround above
[18:29:20 CEST] <thebombzen> like it's literally the purpose of this conversation
[18:29:28 CEST] <thebombzen> so
[18:29:55 CEST] <alexpigment> er, maybe i'm wrong. did you just now report this after following the instructions that kepstin listed above?
[18:30:05 CEST] <thebombzen> yes
[18:30:08 CEST] <alexpigment> k
[18:30:22 CEST] <thebombzen> but you're trying to ask if the problem is specific to x265 and suggested I try x264
[18:30:27 CEST] <alexpigment> well, i'm going to look into trying this today, and i'll let you know if my results are different
[18:30:30 CEST] <thebombzen> which is a bit of stupid suggestion
[18:30:40 CEST] <thebombzen> because the problem WILL occur with x264
[18:30:49 CEST] <thebombzen> it's one of its major limitations
[18:30:58 CEST] <kepstin> x264 does have some outstanding patches for multi bit depth support
[18:31:00 CEST] <alexpigment> sorry, when i do my builds, i always make x264 and x265 the same bit depth
[18:31:06 CEST] <kepstin> i should check the status of that again :)
[18:31:10 CEST] <thebombzen> kepstin: do you mean they're phenomenal
[18:31:22 CEST] <thebombzen> or do you mean they're not committed to master
[18:31:29 CEST] <thebombzen> by "outstanding"
[18:33:20 CEST] <kepstin> they've commited at least some of the work which adds prefixes to symbols
[18:33:36 CEST] <kepstin> i think
[18:35:38 CEST] <kepstin> still ongoing discussion about the big multi bit depth patch set
[19:16:59 CEST] <Tom_B> none of the -hls_ options seem to be being applied, do I need to include them at a particular point in ffmpeg launch command?
[19:17:11 CEST] <c_14> before the output they apply to
[19:17:24 CEST] <c_14> and after any input/output they shouldn't apply to
[19:19:24 CEST] <ronak> hy
[19:19:40 CEST] <ronak> i am nwe for this
[19:19:45 CEST] <ronak> new
[19:22:01 CEST] <Tom_B> here's my full command: ffmpeg -threads 2 -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i INPUT -vf hqdn3d=4.0:3.0:6.0:4.5,yadif,format=nv12,hwupload -map 0:v:0 -map m:language:eng -y -vcodec h264_vaapi -qp 15 -sn -hls_init_time 0.5 -hls_time 2 -hls_list_size 50 -hls_flags delete_segments out.m3u8
[19:22:22 CEST] <Tom_B> I'm getting 5 second segments and the number of segments seems to grown identinely
[19:24:08 CEST] <ronak> hy
[19:24:35 CEST] <c_14> (your command output)
[19:24:43 CEST] <ronak> i am new for this
[19:25:13 CEST] <c_14> ronak: do you have a question?
[19:29:06 CEST] <Tom_B> c_14: here: https://pastebin.com/AXL0uGbg  it works but it seems all -hls options are ignored.
[19:30:49 CEST] <c_14> hmm
[19:30:52 CEST] <c_14> again with -v debug ?
[19:35:37 CEST] <Tom_B> it's very long but here's the debug output: https://gist.github.com/TomBZombie/29d900c5ef4b7fd247188bc9ffef103c
[19:37:24 CEST] <Tom_B> actually hls_lis_size is having an effect, but not what I expected. I set it to 5 for testing... I get 13 .ts files
[19:37:56 CEST] <c_14> yeah
[19:38:00 CEST] <c_14> sounds about right
[19:38:10 CEST] <c_14> though I think it should be 10/11
[19:38:53 CEST] <Tom_B> hmm, is hls_size limited by the input or output codec? I'm sure it was correctly giving 2 seconds before I started trying to use vaapi
[19:39:07 CEST] <c_14> it only cuts on gops
[19:39:11 CEST] <c_14> so that could be an issue
[19:42:11 CEST] <Tom_B> ah, alright. The only annoying thing about that is that I can't start watching the video until the first file has been written, hence the lower hls_init_time, is it possible to change gop rate for h264_vaapi?
[19:42:35 CEST] <c_14> probably
[19:42:37 CEST] <c_14> try setting -g
[19:45:28 CEST] <Tom_B> ah, yes -g 30 has done it thanks :)
[19:46:57 CEST] <BtbN> c_14, it will do 2*list_length+3 iirc
[19:47:02 CEST] <BtbN> so 13 is exactly right
[19:47:29 CEST] <c_14> I thought it was just 2*length +- 1
[19:48:10 CEST] <BtbN> if a player downloads the playlist, and start downloading the last 3 files in real time, the +3 might be needed in edge cases
[19:48:39 CEST] <BtbN> or rather, the entire list in real time, in reverse order, or something stupid like that
[19:49:47 CEST] <pbos> Are there good x264 CBR one-pass command-lines?
[19:49:55 CEST] <pbos> (for realtime)
[19:50:10 CEST] <BtbN> x264 only supports abr
[19:51:12 CEST] <pbos> abr with a low buffer size ~= cbr?
[19:51:19 CEST] <alexpigment> kepstin: thanks again for helping me figure out CBR earlier. I also just now discovered why it wasn't working for me. out of habit, i often use -maxrate and -bufsize rather than vbv-maxrate and vbv-bufsize, because for x264, those parameters were passed on. that doesn't appear to be true in this case, so it was failing until i tried again with vbv-maxrate and vbv-bufsize in the x265-params.
[19:51:19 CEST] <alexpigment> things like this are going to take a while to remember, but I suppose I'll just have to remember to always use x265-params from nowon
[19:51:32 CEST] <alexpigment> pbos, i have a trick for it somewhere
[19:51:34 CEST] <alexpigment> lemme see
[19:52:01 CEST] <kepstin> alexpigment: yeah, very few of the x265 params are mapped to ffmpeg options - in fact, there's bitrate, crf, and... that's about it
[19:52:03 CEST] <pbos> thanks, I'm looking for a fair comparison between x264 "realtime" and openh264 settings
[19:52:18 CEST] <pbos> if the answer is just "pfft, don't use x264 for realtime", let me know :p
[19:52:21 CEST] <alexpigment> pbos: i was using -nal-hrd-cbr according to my notes
[19:52:24 CEST] <BtbN> openh264 can only do baseline, so x264 will crush it.
[19:52:42 CEST] <kepstin> pbos: i'd expect x264 to do rather better at realtime than openh264 in most circumstances
[19:53:10 CEST] <BtbN> the only reason openh264 exist is the licensing-workaround cisco pulled
[19:54:04 CEST] <TD-Linux> would be interesting to see. I don't think many people use x264 for realtime
[19:54:14 CEST] <kepstin> i kinda wish cisco had just done their license blessing workaround on an x264 build rather than their own library, but i guess they didn't want to have GPL stuff.
[19:54:23 CEST] <alexpigment> pbos: more in my notes: to get CBR, i used -b:v XXXX, vbv-maxrate=XXXX, vbv-maxrate=XXXX then the -nal-hrd-cbr flag. this was a while back, so i don't recall how CBR-y it was
[19:54:32 CEST] <atomnuker> TD-Linux: everyone and their dog uses x264 for realtime
[19:55:05 CEST] <BtbN> TD-Linux, everyone using OBS or XSplit does...
[19:55:09 CEST] <TD-Linux> atomnuker, for 1-frame latency? I know it has a single frame delta q rate control but I had never seen it usd in practice
[19:55:22 CEST] <BtbN> Nobody cares about 1 frame latency
[19:55:33 CEST] <TD-Linux> oh that's what I interpreted 1 frame latency as
[19:55:36 CEST] <TD-Linux> *realtime
[19:55:36 CEST] <alexpigment> BtbN: actually a lot of people are using NVENC these days due to hardware limitations on their laptops ;)
[19:55:38 CEST] <kepstin> TD-Linux: if you need 1-frame latency, just use tune=zerolatency, tada.
[19:55:39 CEST] <pbos> kepstin: I need rate control to behave though, hence the CBR issue :)
[19:55:50 CEST] <TD-Linux> this ^
[19:55:53 CEST] <pbos> alexpigment: Thanks
[19:55:55 CEST] <atomnuker> x264 won't overshoot
[19:55:56 CEST] <alexpigment> np
[19:56:02 CEST] <kepstin> pbos: you actually need padded cbr?
[19:56:03 CEST] <BtbN> alexpigment, well, that's what happens when you want to stream on shitty hardware. Results in a stream with questionable visual quality.
[19:56:13 CEST] <TD-Linux> atomnuker, with the buffer size being one frame long?
[19:56:18 CEST] <pbos> kepstin: Nah
[19:56:31 CEST] <alexpigment> BtbN - you're preaching to the choir. having said that, i don't personally stream, so it doesn't affect me personally
[19:56:43 CEST] <BtbN> Well, it doesn't affect the streamer.
[19:56:46 CEST] <BtbN> Just the viewers.
[19:56:51 CEST] <kepstin> pbos: then you don't need cbr at all, you want limited vbr (i.e. either crf more or abr mode with vbv limits)
[19:56:53 CEST] <alexpigment> yeah that's true ;)
[19:57:08 CEST] <alexpigment> +1 kepstin
[19:57:11 CEST] <pbos> kepstin: Thanks, I'm learning as I go
[19:57:23 CEST] <atomnuker> TD-Linux: pretty much, even with slice threading
[19:57:36 CEST] <BtbN> x264 can and will drop way below the desired bitrate if there is nothing to fill it with
[19:57:37 CEST] <alexpigment> i personally use CRF + maxrate + bufsize when doing streaming encodes
[19:57:42 CEST] <BtbN> Which is undesireable for live streaming.
[19:58:03 CEST] <atomnuker> (it denoises based on quantizers)
[19:58:08 CEST] <kepstin> some online streaming stuff (twitch specifically) does want padded cbr so the bitrate remains constant, to avoid issues with tcp
[19:58:20 CEST] <BtbN> You can turn on padding with some x264-param or something
[19:58:24 CEST] <kepstin> yeah
[19:58:33 CEST] <alexpigment> -nal-cbr-hrd is the padding, right?
[19:58:46 CEST] <alexpigment> er
[19:58:47 CEST] <alexpigment> haha
[19:58:50 CEST] <pbos> kepstin: For WebRTC we can do padding outside the codec.
[19:58:52 CEST] <alexpigment> -nal-hrd-cbr
[19:59:09 CEST] <BtbN> well, it's basically one line to enable it, so might as well
[19:59:15 CEST] <pbos> I'm mostly interested in avoiding significant frame spikes
[19:59:35 CEST] <BtbN> the vbv buffer size defines the maximum spike you can possibly see
[19:59:37 CEST] <kepstin> pbos: yeah, iirc rtp has that builtin? or at least the dtls stuff allows it
[19:59:54 CEST] <kepstin> if you want to completely avoid frame spikes, then intra-refresh mode is where it's at
[19:59:55 CEST] <pbos> kepstin: IIRC RTP pads up to 255 bytes per packet
[20:00:00 CEST] <pbos> or something like that
[20:00:19 CEST] <pbos> Normally I turn off periodic intra frames
[20:00:33 CEST] <TD-Linux> webrtc uses udp so you don't want padding
[20:00:38 CEST] <pbos> we send nack/pli/fir
[20:00:50 CEST] <BtbN> turning off I frames with UDP seems like a bad idea
[20:00:54 CEST] <pbos> We pad for BWE purposes sometimes
[20:00:59 CEST] <TD-Linux> BtbN, no, it's actually standard
[20:01:06 CEST] <pbos> or add stream resilience by sending redundant data
[20:01:11 CEST] <TD-Linux> if you want an I frame you request one with RTCP
[20:01:12 CEST] <BtbN> So if a package is lost, you just start over...?
[20:01:17 CEST] <TD-Linux> BtbN, no you request one
[20:01:19 CEST] <kepstin> TD-Linux: for encrypted stuff, it's sometimes desireable to pad, because compressed frame size leaks info
[20:01:37 CEST] <kepstin> but that's not done for most webrtc media
[20:01:40 CEST] <BtbN> But doesn't the quality degrade over time if you never throw in an occasional I frame?
[20:01:42 CEST] <TD-Linux> yeah, and more common for audio
[20:01:46 CEST] <TD-Linux> BtbN, nope.
[20:01:59 CEST] <pbos> BtbN: rtcp will nack missing packets or request a new frame
[20:02:07 CEST] <BtbN> Applying Delta to Delta has to result in degration over time oO
[20:02:08 CEST] <pbos> i-frame degrades quality generally
[20:02:09 CEST] <kepstin> the video encoder sends enough info in each predicted frame to maintain the desired level of quality...
[20:02:20 CEST] <TD-Linux> BtbN, nope, because decoders have exact reconstruction
[20:02:25 CEST] <TD-Linux> there is no drift
[20:02:26 CEST] <pbos> because it removes prediction capabilities
[20:02:40 CEST] <pbos> so you can't maintain the same quality without huge bitrate spikes
[20:02:43 CEST] <kepstin> sending I frames is problematic because it eats a v. large chunk of your vbv buffer, so you often have to send it at lower quality than the predicted frames
[20:02:48 CEST] <pbos> generally delta frames just improve quality over time
[20:03:15 CEST] <kepstin> if you see a live stream where the quality drops every x frames, that's an issue with keyframes not getting enough bitrate, then predicted frames recovering the quality
[20:05:23 CEST] <pbos> BtbN: http://i.imgur.com/hQVymJo.png
[20:05:53 CEST] <pbos> vp8 keyframes are significantly worse quality and then improve over time
[20:06:02 CEST] <pbos> openh264 likely overshoots significantly in the beginning there
[20:06:16 CEST] <pbos> (but I don't have per-frame size metrics for h264 decoding yet)
[20:06:18 CEST] <TD-Linux> I see a flat line for openh264 rate?
[20:06:19 CEST] <TD-Linux> ok
[20:06:44 CEST] <TD-Linux> yes the only way to avoid that overshoot is to either reencode the first frame or use sub frame rate contorl
[20:06:50 CEST] <TD-Linux> vp8 does the former, openh264 does the latter
[20:07:32 CEST] <BtbN> shouldn't starting with a not completely filled vbv-buffer prevent it?
[20:07:49 CEST] <TD-Linux> if your buffer is sufficiently large
[20:08:36 CEST] <pbos> And if you do, it'll blow out any realtime end-to-end latency.
[20:08:44 CEST] <pbos> Given a limited throughput, ofc.
[20:09:44 CEST] <pbos> Or packet loss up the wazoo.
[20:16:05 CEST] <pbos> alexpigment: you specified vbx-maxrate twice, was there any other flag you wanted in there?
[20:29:13 CEST] <Justin_> If someone gets a chance, please take a look at this question I posted: https://superuser.com/questions/1192999/ffmpeg-how-can-i-use-the-last-frame-of-zoompan-for-a-crossfade
[20:31:44 CEST] <durandal_1707> Justin_: crossfade with zoompan? just transformation after last frame?
[20:32:35 CEST] <Justin_> Yes, or continue zoompan through the crossfade. either option is fine.
[20:32:57 CEST] <Justin_> ther ewill be up to 25 images i nteh slideshow
[21:16:41 CEST] <alexpigment> pbos: sorry i just saw your question. try -b:v [your bitrate] -nal-hrd cbr -x264opts vbv-maxrate=[your bitrate]:vbv-bufsize=[your bitrate]
[21:17:15 CEST] <thebombzen> does anyone know an easy way to get zoompan math working? i.e. suppose I have a video and I have an w:h:x:y that I could feed to -vf crop
[21:17:37 CEST] <thebombzen> I couldn't find an easy way to zoom in on that particular rectangle
[21:17:42 CEST] <thebombzen> at a linear rate with zoompan
[21:19:06 CEST] <alexpigment> pbos: also note that -b:v can be in bytes (e.g. 20000000 for 20mbps), but vbv-maxrate and vbv-bufsize must be written in kilobytes (e.g. 20000 for 20mbps)
[21:19:45 CEST] <furq> no those are both in kbit
[21:19:54 CEST] <alexpigment> furq?
[21:20:02 CEST] <furq> and bitrate is also in bits, obviously
[21:20:47 CEST] <alexpigment> sorry, i meant *bits* up there obviously, but -b:v is definitely in bits unless you specify K or M
[21:20:58 CEST] <furq> yeah i meant the vbv options are both in kbit
[21:21:01 CEST] <furq> bitrate is in bits
[21:21:32 CEST] <alexpigment> oh, nm. i thought you were saying -b:v and vbv-maxrate and vbv-bufsize were all in kbit
[21:21:41 CEST] <alexpigment> you're just saying kbit vs kilobytes
[21:21:53 CEST] <alexpigment> in which yeah, yeah, my bad
[21:22:24 CEST] <alexpigment> point was really just to point out that you can't use the same numbers for all of them unless you define the bitrate in the x264opts
[21:22:54 CEST] <kepstin> alexpigment: all ffmpeg options take bits, but if you're using -x264opts/-x264-params or -x256-params it's up to what the x264/x265 library takes
[21:23:10 CEST] <alexpigment> yes, in which case x264opts take kbit
[21:23:16 CEST] <alexpigment> which is all i was trying to point out
[21:23:57 CEST] <alexpigment> i think i'm missing something that both of you guys are saying though :)
[21:24:03 CEST] <kepstin> yep, but with x264, the -bufsize and -maxrate options are mapped, so you don't have to use -x264opts
[21:24:13 CEST] <thebombzen> kepstin: I tried it manually but apparently I was missing -DLINKED_10BIT and -DLINKED_12BIT that it uses in ./mulitlib.sh
[21:24:19 CEST] <alexpigment> right - i historically used bufsize and maxrate
[21:24:24 CEST] <thebombzen> so I'm just running ./multilib.sh and seeing what happens
[21:24:33 CEST] <alexpigment> but as i alluded to earlier today, that bit me in the ass with x265. today is the day i stop doing that ;)
[21:25:25 CEST] <thebombzen> alexpigment: yes be careful with that
[21:25:52 CEST] <thebombzen> if you use -bufsize you provide bps but if you use -x264-opts vbv-bufsize you provde kbps
[21:26:00 CEST] <alexpigment> yes
[21:26:05 CEST] <thebombzen> this has dinged me on a number of occasions
[21:26:06 CEST] <alexpigment> that's exactly what i said up above
[21:26:20 CEST] <thebombzen> yes it is, I'm seconding it
[21:26:27 CEST] <thebombzen> saying that I have too suffered from this
[21:26:35 CEST] <alexpigment> oh yeah
[21:26:58 CEST] <kepstin> i wonder if the x265 api is stable enough nowadays that it might make sense to start mapping more ffmpeg options
[21:27:01 CEST] <alexpigment> but as a person who switches between x264 and x265 a lot, i need to make sure and forget that bufsize and maxrate exist ;)
[21:27:27 CEST] <alexpigment> kepstin: well, it will sure help a lot of people moving from x264 to x265
[21:27:45 CEST] <kepstin> then again, using x264 with ffmpeg is kind of confusing, because it's hard to tell which ffmpeg options it uses and which it ignores
[21:27:48 CEST] <alexpigment> i almost didn't notice initially that -g doesn't map to keyint
[21:28:50 CEST] <alexpigment> i just don't understand why x265 parameters can't just map back to same-named ffmpeg parameters
[21:28:53 CEST] <kepstin> (and ffmpeg -h encoder=libx264 only lists encoder-specific avoptions, doesn't include the global stuff)
[21:29:09 CEST] <alexpigment> i realize that's kinda weird, but i'd love to just type out things without having to use -x265-params all the time
[21:29:23 CEST] <kepstin> alexpigment: they could, but someone would have to go and add avoptions for all the things.
[21:30:07 CEST] <alexpigment> i don't know anything about modifying and submitting source code, but that seems like it would only take a day of work
[21:30:52 CEST] <kepstin> well, adding them it's the hard part, it's keeping the list up to date and matching that's tricky - then you have to worry about different  x265 versions maybe having different supported options
[21:31:00 CEST] <kepstin> adding them isn't the hard part*
[21:32:05 CEST] <kepstin> i assume that when the libx265 wrapper was added, it was fairly early in the x265 dev, and they weren't sure how stable the options were gonna be, so a minimal wrapper was done with the ability to use arbitrary extra options with -x265-params
[21:32:22 CEST] <kepstin> but yeah, at least adding support for stuff like -g would be a good start :)
[21:32:42 CEST] <alexpigment> well taking that one step further, why not add -keyint?
[21:32:55 CEST] <alexpigment> (either in addition or in place of -g)
[21:33:37 CEST] <alexpigment> the problem historically with x264 is that you find documentation online for either ffmpeg options or x264 options, and for novices, it's difficult to know how to handle those
[21:33:51 CEST] <kepstin> but then there's a duplicate option that only works on one codec... unless you mean add it as a global alias to the ffmpeg cli tool?
[21:33:53 CEST] <alexpigment> fortunately someone made a really nice translation wiki online that i reference a lot
[21:34:29 CEST] <alexpigment> kepstin, i don't think i mind it working only on one codec. a lot of options don't translate from codec to codec anyway
[21:35:22 CEST] <alexpigment> my main problem is that it's visually hard to parse a command line where -x265-params is packed and only separated with colons
[21:35:37 CEST] <alexpigment> and that is currently very much the case with x265
[21:35:45 CEST] <kepstin> i suspect this discussion about using global parameters vs codec avoptions is the other reason why nobody has mapped the x265 options :)
[21:35:52 CEST] <alexpigment> haha
[21:36:14 CEST] <kepstin> the global parameters are nice for libavcodec api users, because it's a consistent api for different codecs
[21:36:31 CEST] <alexpigment> seriously though, don't you think it'd be cleaner if you looked at the x265 documentation and were able to just drop a hyphen to map it on your ffmpeg command line?
[21:37:22 CEST] <alexpigment> -crf 18 -vbv-maxrate 20000 -vbv-bufsize 20000 -keyint 60
[21:37:22 CEST] <alexpigment> etc
[21:37:41 CEST] <kepstin> no, i think it would be cleaner if I can swap out x264 with x265 with the same options and get similar behaviour :)
[21:38:37 CEST] <alexpigment> well i guess that makes me in favor of doing the same for x264, although i care less about that cause because most things can be done through ffmpeg commands rather than x264opts
[21:38:38 CEST] <kepstin> that said, only if they actually do the same thing. I'm still kind of annoyed with how libvpx's cq mode got mapped to the crf option on ffmpeg.
[21:39:26 CEST] <alexpigment> kepstin: yeah, except that it's completely useless unless you specify a maxrate, right?
[21:39:37 CEST] <alexpigment> rather
[21:39:53 CEST] <kepstin> well, they fixed that in vp9 at least
[21:39:57 CEST] <alexpigment> more comically, *if you don't specify a -b:v which functions as a maxrate*
[21:40:24 CEST] <kepstin> but unlike x264/x265, you actually get the best result with libvpx if you do a 2-pass encode with cq mode
[21:40:33 CEST] <kepstin> which is... kinda strange
[21:40:38 CEST] <alexpigment> weird
[21:41:27 CEST] <alexpigment> i don't know what that even implies about vp8
[21:42:07 CEST] <alexpigment> still, vp9 is all good and all, but vp8 is just a fallback for HTML5 to me. i have no other reason to use vpx codecs
[21:42:09 CEST] <kepstin> cq mode in vp8 was designed as an enhancement for abr rate control to cause it lower the bitrate below the abr setting if the content wasn't complex enough to warrant using all the rate
[21:42:30 CEST] <kepstin> mostly to save bandwidth and storage on youtube
[21:42:55 CEST] <alexpigment> kepstin: so how much of a difference is there in 1-pass vs 2-pass?
[21:43:03 CEST] <alexpigment> i mean is it very significant?
[21:43:38 CEST] <kepstin> alexpigment: the vp8 single-pass rate control isn't very good, and cq mode still uses the abr rate control for the most part :/
[21:44:07 CEST] <kepstin> by "isn't very good", i mean.. it hits the bitrate targets more or less, but it's used for realtime stuff (webrtc), not quality batch encoding
[21:44:23 CEST] <alexpigment> gotcha
[21:44:34 CEST] <alexpigment> again, i still use it strictly as a fallback. i could care less about it ;)
[21:44:59 CEST] <alexpigment> basically if you're using Firefox on Windows XP, you get the quality you get
[21:45:04 CEST] <kepstin> hmm. at this point, i don't think there's much reason to use vp8 as a fallback for anything
[21:45:15 CEST] <kepstin> unless you care about those ff on xp users, i guess :/
[21:45:32 CEST] <alexpigment> well, they do exist
[21:45:34 CEST] <alexpigment> somehow
[21:45:39 CEST] <kepstin> vp9 gives better results for just about everything, and isn't really any slower than vp8 to encode.
[21:45:55 CEST] <alexpigment> i assumed it was slower to decode
[21:46:07 CEST] <alexpigment> if it's on par with h.264
[21:47:09 CEST] <alexpigment> after all, as a fallback for *xp users* in my usage, those slight differences are going to be amplified
[21:47:34 CEST] <alexpigment> potentially pentium 3 era hardware
[21:48:08 CEST] <thebombzen> kepstin: what?
[21:48:14 CEST] <thebombzen> vp9 is much much slower than vp8
[21:48:37 CEST] <kepstin> hmm, isn't firefox 45 new enough that it should be able to do h264 decoding on xp?
[21:48:43 CEST] <kepstin> or is there some weird limitations with that?
[21:48:55 CEST] <furq> firefox has had h264 since 30something
[21:49:06 CEST] <alexpigment> kepstin, pretty sure firefox avoided paying MPEG-LA by decoding with the system codecs
[21:49:10 CEST] <kepstin> thebombzen: with some testing I've done, you can easily get vp9 to encode as fast as vp8 with better quality
[21:49:23 CEST] <kerio> can ffmpeg mux fragmented isobmff?
[21:49:28 CEST] <kepstin> (although I haven't done any faster-than-realtime stuff)
[21:50:07 CEST] <alexpigment> furq: source? i'd love to get rid of the fallback tbh
[21:50:15 CEST] <furq> i don't know for sure about xp
[21:50:40 CEST] <alexpigment> yeah, it's the one exception because it doesn't ship with an H264 decoder on the system
[21:51:36 CEST] <alexpigment> https://www.wired.com/2013/01/mozilla-brings-native-h-264-to-firefox-nightly/ "Eventually all platforms except Windows XP will get OS-native codec support for H.264 video. Windows XP, which lacks OS-level tools for H.264, will continue to use the Flash plugin to play H.264 movies."
[21:51:42 CEST] <kepstin> i don't even want to install xp on something to test it.
[21:52:01 CEST] <thebombzen> kepstin: is that just because vp8 is slow as fuck or something?
[21:52:14 CEST] <kepstin> thebombzen: libvpx encoder is, yes
[21:52:16 CEST] <alexpigment> kepstin, i have a machine around here, but i'd rather not drag it out and fire it up unless someone has some information that is contrary to what was true a year ago
[21:52:26 CEST] <thebombzen> kepstin: so if libvpx-vp8 is slow as fuck
[21:52:31 CEST] <thebombzen> why not just use x264
[21:52:33 CEST] <furq> i was going to say maybe baseline would work with openh264
[21:52:40 CEST] <thebombzen> which in that case is far faster than vp8 and vp8
[21:52:41 CEST] <furq> but there's still no aac support
[21:52:50 CEST] <thebombzen> also what is openh264
[21:52:57 CEST] <thebombzen> is there any reason to not just use avcodec's h.264 decoder
[21:52:57 CEST] <furq> cisco's h264 implementation
[21:53:15 CEST] <furq> firefox uses it for webrtc
[21:53:15 CEST] <furq> the reason to use it is because it's free to use
[21:53:15 CEST] <alexpigment> thebombzen: openH264 is cisco's version that only supports baseline
[21:53:33 CEST] <furq> which is good if you want to ship an h264 encoder
[21:54:03 CEST] <alexpigment> "come on, Cisco, at least give us Main profile" ;)
[21:54:47 CEST] <furq> well that's probably important to know about xp anyway
[21:54:50 CEST] <TD-Linux> most of the legacy equipment that it needs to interoperate with only supports baseline
[21:54:51 CEST] <furq> i assumed h264 would just work everywhere now
[21:55:15 CEST] <furq> i'm in a position that i can just ignore xp users, but i've definitely wrongly told people in here that h264 works everywhere
[21:55:22 CEST] <kepstin> the correct thing to do with xp users, if you're allowed to, is just say "well, that's just too bad. go away"
[21:55:22 CEST] <furq> hopefully they can do the same ;_;
[21:55:24 CEST] <TD-Linux> firefox and chrome default to vp8 if there is no h264 only endpoint
[21:55:44 CEST] <alexpigment> yeah, but licensing is still a problem for browsers. most people just pay the max fee to MPEG-LA. Firefox can't really afford to do that since they don't have a good revenue stream like Google, Microsoft, Safari, etc
[21:56:22 CEST] <alexpigment> rather, Apple, not Safari
[21:56:57 CEST] <furq> i did always wonder who youtube's vp8 fallback was for
[21:57:24 CEST] <alexpigment> it was Google/YouTube's way to push a standard out there that would potentially save them millions of dollars if it caught on
[21:57:39 CEST] <furq> i meant the fact that youtube still has a vp8 fallback format for new videos
[21:57:57 CEST] <alexpigment> oh gotcha
[21:58:02 CEST] <alexpigment> it's still in there probably just for xp
[21:58:06 CEST] <furq> yeah
[21:58:27 CEST] <alexpigment> although i think when they initially had the fallback, it wasn't necessarily for xp
[21:58:40 CEST] <alexpigment> it was what they were actively pushing on their H.265 player
[21:58:56 CEST] <furq> you meant html there, right
[21:58:57 CEST] <alexpigment> trying to break free from Adobe and MPEG-LA at the same time, i'd guess
[21:59:05 CEST] <kepstin> have they improved the speed of their vp9 encodes yet? iirc they only popped up after a while, or after a video hit a certain number of views or something
[21:59:07 CEST] <alexpigment> yeah, sorry. HTML5
[21:59:14 CEST] <furq> kepstin: it's still after 150 views in my experience
[21:59:20 CEST] <furq> purely anecdotal though
[21:59:45 CEST] <alexpigment> out of curiosity, what do people use VP9 for these days?
[21:59:50 CEST] <kepstin> I wonder why they do that. I'm sure they could afford the compute to do the vp9 encodes immediately :/
[22:00:01 CEST] <TD-Linux> I think they are doing it more aggresively
[22:00:07 CEST] <TD-Linux> I have private videos with <10 views that are vp9
[22:00:08 CEST] <furq> i expect >90% of videos end up with <150 views
[22:00:21 CEST] <TD-Linux> maybe they just do extra videos when they have spare compute
[22:00:23 CEST] <kepstin> alexpigment: google uses it for HD and especially 4K videos since hevc isn't an option
[22:00:43 CEST] <furq> TD-Linux: maybe, i've not uploaded anything in a while
[22:00:55 CEST] <furq> i have a ton of videos close to that mark and it was consistently at 150
[22:00:55 CEST] <TD-Linux> for HDR videos I think they only offer VP9 encodes, so uploading a HDR clip is probably a sure way to get VP9
[22:01:00 CEST] <furq> but these were uploaded about two years ago
[22:01:12 CEST] <alexpigment> kepstin: they use it *additionally* for HD - are you saying it's exclusive for 4k?
[22:01:29 CEST] <furq> there's still an h264 format at 4k
[22:01:32 CEST] <TD-Linux> VP9's advantage over H.264 is larger at higher resolutions
[22:02:00 CEST] <BtbN> VP9 for 4K sounds like fun, with the lack of broad hwaccel for it
[22:02:08 CEST] <kepstin> my impression was that on desktops, they were planning to only serve 4K content to systems with vp9 support
[22:02:16 CEST] <alexpigment> BtbN: exactly what I was thinking
[22:02:18 CEST] <kepstin> (mostly to annoy apple into adding it?)
[22:02:21 CEST] <TD-Linux> BtbN, it decodes in realtime in software on most machines with a 4k monitor
[22:02:28 CEST] <furq> yeah vp9 decode is pretty quick
[22:02:43 CEST] <furq> and it's not like you're going to be watching it on a phone
[22:02:55 CEST] <TD-Linux> even if you did, most phones have hwaccel now
[22:02:56 CEST] <BtbN> Oh, there are phones with a 4K screen
[22:03:03 CEST] <alexpigment> furq: you never know. the "resolution" wars on phones is dumb but very much a real thing
[22:03:09 CEST] <furq> i'm sure people have tried
[22:03:13 CEST] <kepstin> looks like since about december 2016, google stopped encoding 4k videos in h264
[22:03:30 CEST] <furq> oh really
[22:03:38 CEST] <furq> i'm not surprised tbh
[22:03:43 CEST] <furq> the bitrate of the h264 4k was like 12mbit or something
[22:04:00 CEST] <alexpigment> is vp9 that much better than h.264?
[22:04:06 CEST] <furq> yeah
[22:04:11 CEST] <alexpigment> or is it just better than youtube's H.264 encoder?
[22:04:15 CEST] <furq> i've seen noticeable quality bumps on videos after the vp9 went live
[22:04:21 CEST] <furq> i'd imagine youtube are using x264
[22:04:32 CEST] <kepstin> i don't see why they'd use anything else
[22:04:33 CEST] <BtbN> I'd guess YouTube just uses libx264? But probably an ancient version, same as their ffmpeg
[22:04:37 CEST] <alexpigment> furq: well, they sure as hell strip out the metadata on the videos, if i recall
[22:04:42 CEST] <furq> they do
[22:04:55 CEST] <kepstin> that said, as we've seen with crunchyroll, using x264 doesn't mean you're using it correctly ;)
[22:04:59 CEST] <TD-Linux> their h.264 encodes are limited because they have to be compatible with a lot of buggy hw decoders
[22:05:00 CEST] <furq> people in here seem pretty sure they're basically using ffmpeg from 2013-ish
[22:05:15 CEST] <furq> but obviously patched to remove any identifying metadata
[22:05:18 CEST] <alexpigment> youtube are definitely not using x264 with the best settings, that's for sure
[22:05:22 CEST] <BtbN> iirc it was a heavily modified ffmpeg 0.10?
[22:05:38 CEST] <furq> well my source for that is this channel, so shrug
[22:05:44 CEST] <kepstin> iirc, you can narrow down which ffmpeg they're using by checking for supported decoder features when uploading videos
[22:05:45 CEST] <furq> i didn't find it surprising though
[22:06:10 CEST] <BtbN> I find it surprising they never bothered with updating, given all the new stuff that's supported
[22:06:31 CEST] <furq> well it gives them a good technical excuse to not support h265
[22:06:41 CEST] <BtbN> I can see them not touching their encoders, but it shouldn't be too hard to convert to a common lossless intermediate, to profit from the new input formats
[22:06:53 CEST] <kepstin> well, they've added vp9 support to their encoder pipeline...
[22:07:11 CEST] <BtbN> I'd assume that to run on a more recent ffmpeg, alongside the old one
[22:07:27 CEST] <kepstin> I assume they're doing encoding by segmenting the videos, farming out segments to compute workers, and reassembling after
[22:07:59 CEST] <kepstin> that said, they have to at least be patching their decoding ffmpeg, I'm sure they've had a few code execution from uploaded video vulnerabilities to fix.
[22:08:01 CEST] <BtbN> From my experience the encodes never seemed faster than what one machine could do
[22:08:16 CEST] <TD-Linux> yes they segment encodes
[22:08:26 CEST] <TD-Linux> and oh yes they are
[22:08:35 CEST] <alexpigment> admittedly, it is very fast
[22:08:38 CEST] <TD-Linux> at least for long videos
[22:08:56 CEST] <BtbN> I very frequently had to wait 6-12 hours for my series of 6h uploads
[22:09:06 CEST] <BtbN> for the first low-qualality to come up
[22:09:10 CEST] <alexpigment> Vimeo, by comparison doesn't hide the fact that they use x264. i think they're using highly-multi-cored systems though. i seem to recall the thread count was 32 or something
[22:09:12 CEST] <BtbN> the better qualities easily took days
[22:09:27 CEST] <furq> how long ago was that
[22:09:36 CEST] <BtbN> a good year
[22:09:39 CEST] <furq> the one thing i can say for sure about youtube internals is that they're changing all the time
[22:10:14 CEST] <kepstin> they definitely have a small number of encodes they do really quickly, and a a remaining set that's added later, if at all.
[22:10:23 CEST] <furq> i've not uploaded anything other than 720p1 for like five years though
[22:11:06 CEST] <kepstin> I should take a look at my videos, I've got a channel with short (mostly) 1080p videos uploaded once a week for a year now.
[22:11:07 CEST] <alexpigment> the 1080p encodes definitely take a bit longer
[22:11:21 CEST] <alexpigment> but usually within a few minutes in my experience
[22:11:27 CEST] <furq> yeah i should probably upload a new batch
[22:11:33 CEST] <alexpigment> it's not like it was 5 years ago where your 1080p video might not show up for a day or so
[22:11:45 CEST] <furq> after all youtube is constantly telling me that my subscribers are eagerly waiting for regular content updates
[22:12:00 CEST] <furq> i'm all about that content baby
[22:12:00 CEST] <alexpigment> :)
[22:12:08 CEST] <alexpigment> monetize
[22:12:15 CEST] <furq> content is my middle name
[22:12:28 CEST] <alexpigment> furq content furqson
[22:13:57 CEST] <alexpigment> i guess i'm going to have to start doing some quality comparisons between vp9 and HEVC. i kinda just presumed vp9 wasn't worth using for any reason, but if it's better than H.264 at high resolutions...
[22:14:41 CEST] <alexpigment> hell, if it's faster to encode than x265 and even 2/3 of the quality per bitrate, that's probably a win overall
[22:14:55 CEST] <furq> it's not faster than x265
[22:15:03 CEST] <alexpigment> :(
[22:15:10 CEST] <sikilikis> yo furq, remember me?
[22:15:11 CEST] <alexpigment> well, you gave me some bad news, but you also saved me from some work
[22:15:13 CEST] <furq> it's faster to decode, but there's less hwaccel support
[22:15:32 CEST] <kepstin> alexpigment: main improvement for high-res stuff over h264 is that vp9 adds 64px superblocks, i think
[22:15:50 CEST] <furq> sikilikis: hi
[22:16:09 CEST] <alexpigment> kepstin: ah that does sound familiar
[22:16:12 CEST] <sikilikis> dont worry, everything is still working, but i'm wondering if you guys can help me push out a few extra frames from the pi
[22:16:14 CEST] <TD-Linux> and larger transforoms
[22:16:38 CEST] <sikilikis> right now its looping a gif over and over with text overlay and the text is constantly updating
[22:16:52 CEST] <sikilikis> only thing I've played around with is changing the source gif. The bigger the gif, the less fps
[22:17:03 CEST] <sikilikis> so i'm limited by that.
[22:17:43 CEST] <sikilikis> I'm wondering if rather than doing like "-ignore_loop 0 -i some_gif.gif" if it'd be faster to do "-loop 0 -i image%03.png"
[22:17:56 CEST] <furq> are you using the pi's hardware encoder
[22:18:10 CEST] <sikilikis> I am, though when I tested stuff using the hardware encoder didn't improve performance
[22:18:19 CEST] <sikilikis> h264_omx
[22:18:19 CEST] <furq> it should definitely be faster than x264 on a pi
[22:18:23 CEST] <sikilikis> compared to libx264
[22:18:45 CEST] <alexpigment> decoding bottleneck?
[22:18:48 CEST] <furq> maybe
[22:18:51 CEST] <sikilikis> they both run about as fast as each other. I'm assuming it's because I'm creating video from a gif rather than just encoding an already existing mp4 video or something
[22:18:54 CEST] <kepstin> if it's being limited by the decoder, it might make sense to use the loop filter rather than loop the decoding
[22:18:59 CEST] <sikilikis> but that leads me to my next question
[22:19:17 CEST] <furq> you could maybe try -i image%d.bmp if you want to avoid decoding
[22:19:17 CEST] <sikilikis> if I turn the gif into an mp4 and then loop that, would it be better?
[22:19:25 CEST] <furq> er
[22:19:30 CEST] <furq> did you build with --enable-mmal
[22:19:36 CEST] <furq> if you can hardware decode then that should help
[22:19:40 CEST] <sikilikis> I believe I did but I don't remember
[22:19:59 CEST] <kerio> do keep in mind that decoding and encoding with ffmpeg will not be as efficient as it could be
[22:20:10 CEST] <sikilikis> and I didn't actually bother using it but I can try that. What do I need to add to my command?
[22:20:30 CEST] <sikilikis> actually I should show you guys what my command is shouldnt I
[22:20:43 CEST] <kerio> sikilikis: -c:v h264_mmal before -i
[22:20:51 CEST] <kepstin> if you're doing extra video processing (like adding overlays), the decoded video has to be in cpu-accessible ram and stuff anyways - might even need some colorspace conversions
[22:20:51 CEST] <thebombzen> everyone always boasts about the improvements of HEVC over H.264 (and likewise vp9 over vp8) for 4k and other huge resolutions
[22:20:57 CEST] <thebombzen> but what about at 1080p
[22:21:01 CEST] <alexpigment> you could also try ffmpeg -hwaccels to see what's available (if anything)
[22:21:10 CEST] <thebombzen> which is still what a large amount of content will be at for a long time
[22:21:35 CEST] <alexpigment> thebombzen: i personally see no point in using HEVC for 1080p
[22:21:37 CEST] <kepstin> thebombzen: 1080p is small enough that the benefits from larger transforms is marginal. It can be better, but at the expense of more power needed to encode.
[22:22:02 CEST] <thebombzen> what about extra intra directions?
[22:22:07 CEST] <thebombzen> or are those only useful for large blocks
[22:22:21 CEST] <sikilikis> lets say I dont use hardware decoding. Do you think using separate images would be faster than a gif?
[22:22:26 CEST] <thebombzen> also I feel like 64x64 can be useful if there's like, a large sky
[22:22:26 CEST] <sikilikis> its got to loop forever
[22:22:38 CEST] <furq> i have no idea
[22:22:38 CEST] <thebombzen> sikilikis: gif can be decoded very fast but it's also terrible
[22:22:43 CEST] <thebombzen> and you should not use it if you can avoid it
[22:22:52 CEST] <alexpigment> agree with bombzen re: terribility ;)
[22:22:52 CEST] <sikilikis> terrible in what way?
[22:22:59 CEST] <sikilikis> slow? bad quality?
[22:23:02 CEST] <furq> are you scaling the image
[22:23:03 CEST] <thebombzen> the visual quality of gifs is atrocious
[22:23:05 CEST] <kepstin> sikilikis: show us your command? it might make sense to use the "loop" filter to loop the frames if there's not too many, that way they only get decoded once, then just stored in ram
[22:23:10 CEST] <furq> if you are then prescaling to the right size will help a lot
[22:23:17 CEST] <kepstin> and yeah, with gif source there's some colorspace conversion...
[22:23:21 CEST] <sikilikis> yeah i'm on it. gotta get on my other computer
[22:23:21 CEST] <thebombzen> first of all, gifs are posterized and panels are forced
[22:23:23 CEST] <furq> and yeah that
[22:23:36 CEST] <thebombzen> second of all gifs have no inter prediction (alpha is a thing I know, it's fake inter prediction)
[22:23:38 CEST] <sikilikis> um, I have the -s flag but its not scaling to a different size
[22:23:47 CEST] <sikilikis> I just found that if I left it out, I'd get a lot of alsa errors
[22:23:56 CEST] <kepstin> sikilikis: show us your command :)
[22:24:07 CEST] <alexpigment> is the source true GIFs, or is that an intermediate format that you're creating?
[22:24:07 CEST] <sikilikis> working on it lol. on my work laptop which is on vpn
[22:24:09 CEST] <thebombzen> and the GIF palette thing counteracts the use of transparency
[22:24:13 CEST] <sikilikis> which means i cant ssh into my pi
[22:24:17 CEST] <thebombzen> because forcing a palette requires you to dither
[22:24:31 CEST] <furq> i guess you'd want yuv420p tiff for minimum time spent decoding and colourspace converting
[22:24:40 CEST] <furq> if you do split to images
[22:24:45 CEST] <thebombzen> I'd even recommend mjpeg over TIFF
[22:24:50 CEST] <thebombzen> over GIF*
[22:24:54 CEST] <thebombzen> mjpeg is actually pretty fast
[22:25:08 CEST] <furq> iirc mmal doesn't support mjpeg in ffmpeg
[22:25:18 CEST] <thebombzen> mmal?
[22:25:19 CEST] <alexpigment> WebM/VP8 is what a lot of modern GIFs are switching to under the hood, right?
[22:25:24 CEST] <furq> the rpi hardware decoder
[22:25:29 CEST] <thebombzen> alexpigment: sort of
[22:25:40 CEST] <alexpigment> i'm out of the gif loop (no pun intended)
[22:25:40 CEST] <thebombzen> it's definitely true video
[22:25:48 CEST] <thebombzen> there's definitely a push to use video
[22:25:53 CEST] <kepstin> alexpigment: the ".gifv" on imgur is just a video file in an html page, yeah, but I expect they do h264 encodes (in addition to vp8/9?)
[22:25:54 CEST] <alexpigment> right, to get around the interent shittiness of gif
[22:25:55 CEST] <thebombzen> but many websites are ignoring vp8 and just using H.264
[22:25:56 CEST] <furq> there's animated webp now but nobody uses it
[22:26:07 CEST] <furq> gifv is mp4 iirc
[22:26:09 CEST] <furq> twitter does the same thing
[22:26:14 CEST] <thebombzen> yea gifv is just mp4
[22:26:15 CEST] <alexpigment> did animated PNG ever catch on?
[22:26:23 CEST] <thebombzen> alexpigment: yes and no
[22:26:25 CEST] <furq> funnily enough they finally added apng to chrome last month
[22:26:28 CEST] <thebombzen> it did but then it un-caught on
[22:26:36 CEST] <furq> it's been in firefox for years but nobody's been able to use it
[22:26:42 CEST] <sikilikis> https://pastebin.com/XHP5LxCx
[22:26:45 CEST] <furq> and now that there are viable alternatives, chrome go and add it
[22:26:45 CEST] <thebombzen> chrome used to support apng but when they went from Webkit to Blink they lost the support
[22:26:52 CEST] <furq> i bet it's part of the hostage exchange for webp in firefox
[22:26:57 CEST] <furq> i can't see any other reason they'd do it
[22:27:05 CEST] <thebombzen> Chromium doesn't support apng tho
[22:27:09 CEST] <alexpigment> furq: i like this conspiracy theory
[22:27:13 CEST] <thebombzen> Safari does as of like a year ago
[22:27:16 CEST] <thebombzen> either way
[22:27:22 CEST] <furq> didn't we have this conversation
[22:27:23 CEST] <thebombzen> webp has pretty terrible support globally
[22:27:25 CEST] <furq> chrome has never supported apng
[22:27:30 CEST] <sikilikis> theres my command and I know it can be better
[22:27:31 CEST] <thebombzen> it did actually
[22:27:33 CEST] <thebombzen> it used to
[22:27:37 CEST] <thebombzen> it doesn't anymore
[22:27:40 CEST] <furq> i'm pretty sure it never did
[22:27:48 CEST] <furq> you just said webkit only added support in 2015
[22:28:00 CEST] <furq> chrome switched to blink in 2013
[22:28:16 CEST] <sikilikis> remind me how to add hardware decoding? I think I may have compiled it with it already
[22:28:18 CEST] <thebombzen> huh?
[22:28:19 CEST] <thebombzen> hm
[22:28:19 CEST] <kepstin> hmm, does drawtext only work on rgb frame?
[22:28:26 CEST] <furq> sikilikis: -c:v h264_mmal before -i
[22:28:29 CEST] <thebombzen> ohhey apparently Chromium supports apng as of March 2017
[22:28:33 CEST] <furq> but obviously that only works if you're inputting a video
[22:28:35 CEST] <furq> thebombzen: i just said that ;_;
[22:28:44 CEST] <thebombzen> lol okay
[22:28:49 CEST] <thebombzen> l2read @me
[22:28:50 CEST] <sikilikis> the hardware decoding does? or something else?
[22:28:57 CEST] <furq> mmal
[22:29:03 CEST] <furq> it's an h264 decoder
[22:29:06 CEST] <sikilikis> okay so lets say
[22:29:10 CEST] <furq> it does other stuff but i don't think it's wired up in ffmpeg
[22:29:11 CEST] <sikilikis> I encode the gif to a video
[22:29:21 CEST] <alexpigment> thebombzen: i have to laugh when someone *else* says "i just said that" to you ;) seems like there's a pattern :)
[22:29:24 CEST] <sikilikis> is there any way I can loop that instead of a gif or set of images?
[22:29:28 CEST] <furq> also
[22:29:37 CEST] <furq> that's slow because you're scaling and doing a colourspace conversion
[22:29:45 CEST] <sikilikis> I'm trying to get at the optimal of doing this
[22:29:47 CEST] <alexpigment> (i'm only busting your balls a little bit of course, not serious at all)
[22:29:48 CEST] <furq> also -x264opts and -preset do nothing with h264_omx, so remove those
[22:29:56 CEST] <sikilikis> gotcha
[22:30:05 CEST] <kahunamoore> anyone have experience with libavformat and mxf audio issues?
[22:30:07 CEST] <furq> if you want to not scale or do a conversion, encode each frame of the gif to a pre-scaled yuv420p tiff
[22:30:14 CEST] <furq> then use image2 to loop over those
[22:30:23 CEST] <kahunamoore> muxing specifically
[22:30:33 CEST] <thebombzen> alexpigment: haha when I did it to you I was repeating what you said to agree with you xD
[22:30:42 CEST] <sikilikis> wait real quick
[22:30:50 CEST] <alexpigment> oh right. that was *another* time. i want to say it happened yesterday too
[22:30:52 CEST] <sikilikis> I use the x264 opts to set the keyframe interval
[22:30:56 CEST] <thebombzen> anyway it's funny that the wikipedia page that states that chromium supports apng has an apng that doesn't work when I view the page in chromium
[22:31:00 CEST] <sikilikis> how do I do that with the hardware encoder?
[22:31:03 CEST] <thebombzen> maybe because Arch hasn't pulled from upstream yet
[22:31:22 CEST] <furq> -g should work
[22:32:10 CEST] <sikilikis> I'm assuming I can encode the gif using ffmpeg?
[22:32:21 CEST] <furq> http://vpaste.net/AC1Y5
[22:32:23 CEST] <furq> something like that
[22:32:25 CEST] <sikilikis> into separate frames that are already the correct format?
[22:32:35 CEST] <furq> i think image2 works with tiff
[22:32:45 CEST] <furq> if not then jpg shouldn't be too bad
[22:33:04 CEST] <kepstin> jpg might still need some conversion tho, since it's full range?
[22:33:06 CEST] <sikilikis> do I need to configure ffmpeg with image2 and jpg?
[22:33:12 CEST] <furq> ?
[22:33:23 CEST] <furq> kepstin: good point
[22:33:26 CEST] <sikilikis> er, how do I know if I can use those with my current ffmpeg?
[22:33:33 CEST] <furq> all of that except h264_omx is builtin by default
[22:33:37 CEST] <sikilikis> or if I need to recompile
[22:33:39 CEST] <sikilikis> oh okay
[22:33:40 CEST] <sikilikis> sweet
[22:34:06 CEST] <furq> actually you should be able to get rid of -c:v tiff in the first command
[22:34:33 CEST] <kepstin> can you use the image2 demuxer with raw video frames?
[22:35:00 CEST] <furq> yeah that works fine
[22:35:04 CEST] <thebombzen> kepstin: afaik ffmpeg uses "yuvj" for fullrange and "yuv" for nonfullrange
[22:35:04 CEST] <furq> i have no idea
[22:35:29 CEST] <sikilikis> where would the -g option go for the keyframe interval? after the -c:v h264_omx part?
[22:35:33 CEST] <thebombzen> so if you convert yuvj444p to yuv444p that'll fix the fullrange issue
[22:35:45 CEST] <furq> anywhere after the input filename and before the output filename
[22:35:50 CEST] <sikilikis> thanks
[22:36:11 CEST] <kepstin> thebombzen: yes, but the problem is that we don't want to do any conversions ;)
[22:38:57 CEST] <kepstin> hmm, looks like you can do raw frame files with image2 demuxer, just have the file extension ".raw" and give it pixel_format and video_size options
[22:39:08 CEST] <furq> neat
[22:39:11 CEST] <furq> that might be better then
[22:41:01 CEST] <kepstin> (it has some weird stuff for having separate files per video plane if you give it a file with extension ".y", too)
[22:43:28 CEST] <sikilikis> cant seem to look at the generated tiff images. At least not under windows. It just complains that it cant read the file
[22:44:06 CEST] <furq> works here
[22:44:19 CEST] <sikilikis> windows CAN read tiff images right?
[22:44:35 CEST] <furq> i've got no idea what windows supports by default
[22:44:50 CEST] <alexpigment> 1 sec
[22:44:52 CEST] <alexpigment> i can test this
[22:45:16 CEST] <alexpigment> yes, on a basic level
[22:45:33 CEST] <alexpigment> having said that, it might just support embedded thumbnails in TFF files
[22:45:42 CEST] <alexpigment> *TIFF, rather
[22:46:15 CEST] <kahunamoore> ping #2: anyone have experience with libavformat and mxf muxing?
[22:46:51 CEST] <alexpigment> kahunamoore: i think i have, but maybe that was FFMBC. let's assume i can't answer the question, but go ahead anyway
[22:47:55 CEST] <kahunamoore> I'm having "last frame" audio issues, either the audio essence is incomplete (smaller than all the other CBR audio essences) or missing one of the channels/essences altogether
[22:48:23 CEST] <kahunamoore> I'm properly writing out the footer, closing the file, etc
[22:48:50 CEST] <sikilikis> yeah i used your command to get tiff images from my gif. it seems to work okay but I cant open them
[22:49:02 CEST] Action: alexpigment moves out of the way for smarter people to make sense of kahunamoore's problem
[22:49:17 CEST] <kahunamoore> BTW - I'm not using libavcodec (using hw codec)
[22:49:18 CEST] <furq> well as long as ffmpeg can open them, it's fine
[22:49:25 CEST] <kepstin> sikilikis: i'd expect there to be limited application support for opening yuv tiff files. that's ok, they're just a temporary file for ffmpeg
[22:49:34 CEST] <sikilikis> I guess so. I'll have to try that
[22:51:08 CEST] <kahunamoore> i've emailed the libav-user ml so maybe someone there can help. thanks!
[22:53:16 CEST] <sikilikis> loop option doesnt work
[22:53:18 CEST] <thebombzen> but what improvements does HEVC have over H.264 other than larger blocks and more intra directions (which afaik is just to make the larger blocks more effective)
[22:53:42 CEST] <thebombzen> because it seems to me that a codec that's 10 years newer should be able to do 1080p significantly better
[22:53:43 CEST] <sikilikis>  [image2 demuxer @ 0x30a840] Unable to parse option value "-1" as boolean
[22:53:57 CEST] <thebombzen> sikilikis: use -stream_loop
[22:54:02 CEST] <thebombzen> not -loop or -loop_input
[22:54:13 CEST] <thebombzen> although the image2 demuxer has always had trouble looping input
[22:54:57 CEST] <thebombzen> sikilikis: wait nvm. -loop is a private option for the image2 demuxer
[22:55:06 CEST] <thebombzen> from the docs it says: If set to 1, loop over the input. Default value is 0.
[22:55:14 CEST] <thebombzen> this means you don't have an option for the # of loops
[22:55:24 CEST] <thebombzen> just -loop 1 to loop it and -loop 0 to, not
[22:55:34 CEST] <sikilikis> that seems to have done it
[22:57:10 CEST] <sikilikis> hmm. Looks like there actually is something wrong with the tiff images
[22:57:27 CEST] <sikilikis> stream is just buffering but ffmpeg seems to be chugging along nicely
[22:58:57 CEST] <sikilikis> Is there any other formatting stuff I need to do? For youtube I need to have -f flv
[22:59:25 CEST] <furq> pastebin the command and output
[23:01:06 CEST] <sikilikis> https://pastebin.com/97YE0cVw
[23:01:07 CEST] <thebombzen> furq why not use furqbot
[23:01:25 CEST] <furq> my bot doesn't do that
[23:01:30 CEST] <furq> sikilikis: paste the output as well
[23:02:13 CEST] <sikilikis> gimme a sec
[23:03:12 CEST] <sikilikis> https://pastebin.com/C0m5GQT6
[23:03:22 CEST] <sikilikis> I killed the command myself. ffmpeg doesnt complain or anything
[23:04:29 CEST] <sikilikis> oh wait shit did you want the output of the tiff conversion?
[23:05:54 CEST] <furq> no
[23:06:03 CEST] <sikilikis> okay well thats basically it
[23:06:36 CEST] <sikilikis> oh wait
[23:06:38 CEST] <sikilikis> its working
[23:06:41 CEST] <furq> oh fun
[23:06:45 CEST] <furq> i was going to say you might need to set -g
[23:06:48 CEST] <sikilikis> i just had to refresh the browser...
[23:06:51 CEST] <furq> nice
[23:07:03 CEST] <furq> youtube is pretty picky about gop size but idk what h264_omx spits out by default
[23:07:05 CEST] <alexpigment> does anyone else here get a little gunshy when they see 854x480?
[23:07:21 CEST] <furq> also yeah you might as well scale to 720p
[23:07:24 CEST] <sikilikis> yeah dont trip I can fix that now that I have the super secret technique of streaming
[23:08:09 CEST] <alexpigment> no, it's fine. i'm just saying that when i see 854x480, i think of all the problems that can arise (and I have personally dealt with). not that there's a problem here with your usage
[23:08:12 CEST] <furq> not sure if google reencodes live streams but that'll improve audio quality for regular videos
[23:09:27 CEST] <furq> oh, one other thing
[23:09:34 CEST] <furq> make sure the textfile you're using for drawtext is on a tmpfs
[23:09:40 CEST] <furq> otherwise it'll be hitting the sd card
[23:09:46 CEST] <sikilikis> oh yeah
[23:09:52 CEST] <sikilikis> I did that already dont trip
[23:10:05 CEST] <sikilikis> that was one of the first things I read when googling for this
[23:10:06 CEST] Action: alexpigment is tripping
[23:10:09 CEST] <alexpigment> ;)
[23:10:11 CEST] <furq> i wish i was tripping
[23:10:19 CEST] <alexpigment> can we all just agree to trip?
[23:10:31 CEST] <furq> depends on what my dealer's got in
[23:10:42 CEST] <sikilikis> lol yeah no worries everything I ever read says "the pi can corrupt the sd card. dont write too much"
[23:10:57 CEST] <furq> it's more "the sd card is slow as fuck"
[23:11:15 CEST] <furq> but having it die is also concerning
[23:11:21 CEST] <sikilikis> well that too but reading a text file wont be too difficult
[23:11:39 CEST] <furq> i can imagine it having enough latency to cause a frame drop
[23:11:48 CEST] <sikilikis> although if theres a way to have ffmpeg not read it every frame thatd be cool
[23:11:58 CEST] <furq> you could maybe do something with sendcmd
[23:12:03 CEST] <sikilikis> like have it read every 30 frames or something
[23:12:03 CEST] <furq> i've never fully figured out how that works though
[23:12:10 CEST] <sikilikis> naw thats too complicated
[23:12:18 CEST] <sikilikis> I'll just let it read off of /tmp
[23:12:20 CEST] <thebombzen> sikilikis: you want ffmpeg to read every 30 frames?
[23:12:22 CEST] <furq> it shouldn't be a big deal if it's in memory
[23:12:26 CEST] <thebombzen> and drop 29 of every 30?
[23:12:31 CEST] <thebombzen> cause that's what the framestep filter does
[23:12:32 CEST] <furq> he wants it to read the textfile in drawtext every 30 frames
[23:12:35 CEST] <thebombzen> -vf framestep =30
[23:12:36 CEST] <sikilikis> the drawtext filter has a "reload" option
[23:12:43 CEST] <furq> you're really bad at reading today
[23:12:44 CEST] <thebombzen> oh hm
[23:12:53 CEST] <thebombzen> yea I guess I am
[23:12:55 CEST] <sikilikis> but all I found is that "reload=1" makes it reread the text file every frame
[23:12:59 CEST] <sikilikis> which is fine but not necessary
[23:13:08 CEST] <thebombzen> perhaps I'd suggest using some complex filtergraph
[23:13:11 CEST] <sikilikis> if it could do like "reload=30" or something
[23:13:21 CEST] <sikilikis> just to make things a little easier on ffmpeg
[23:13:25 CEST] <sikilikis> but again, its not necessary
[23:14:34 CEST] <thebombzen> whatever the framerate is, say it's R
[23:14:43 CEST] <sikilikis> yeah
[23:14:58 CEST] <sikilikis> basically "re read the text file every R frames"
[23:15:06 CEST] <sikilikis> but again its not necessary
[23:15:22 CEST] <sikilikis> i dont know if that would even give a performance boost
[23:15:38 CEST] <furq> the Right Way to do this is probably sendcmd, but i've never figured out how to do that dynamically through an fd or something similarly simple
[23:15:46 CEST] <thebombzen> you could do -lavfi 'color=black at 0.0,drawtext=<options>:reload=1,fps=R[draw] ; [0:v] [draw] overlay [v]' -map '[v]'
[23:16:03 CEST] <furq> i know you can do it through zmq but that's massively overcomplicated for this
[23:16:08 CEST] <thebombzen> haha
[23:16:30 CEST] <thebombzen> I mean actually this: -lavfi 'color=black at 0.0:rate=R/30,drawtext=<options>:reload=1,fps=R[draw] ; [0:v] [draw] overlay [v]' -map '[v]'
[23:16:37 CEST] <thebombzen> where R/30 is the actual number
[23:17:21 CEST] <furq> that would incur a colourspace conversion wouldn't it
[23:17:41 CEST] <sikilikis> now I need to increase the font
[23:17:44 CEST] <thebombzen> it would, but not on the original video
[23:17:48 CEST] <sikilikis> font size I mean
[23:17:50 CEST] <furq> oh maybe not
[23:17:55 CEST] <furq> apparently color is yuv420p by default
[23:17:58 CEST] <thebombzen> so if your input is 60 fps, this will just run drawtext on 2fps transparent input with reload=1, and duplicate frames to make it 60 fps
[23:18:15 CEST] <thebombzen> and then overlay the drawn image on the original
[23:19:30 CEST] <sikilikis> also I can add -r at the end to set a constant fps right?
[23:20:43 CEST] <furq> set -framerate before -i
[23:20:58 CEST] <furq> -r will take the existing framerate and drop/dup frames
[23:21:07 CEST] <furq> -framerate with image2 will just set the input framerate
[23:21:21 CEST] <sikilikis> ah okay
[23:45:03 CEST] <alexpigment> furq: related to our earlier convo about HEVC vs VP9, i just ran across this: http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Netflix-Finds-x265-20-More-Efficient-than-VP9-113346.aspx
[23:45:21 CEST] <alexpigment> it doesn't really cover 4k comparisons in the charts, but it's an interesting breakdown
[23:45:52 CEST] <chovy> how do i convert an m3u8 feed to live audio stream?
[23:46:02 CEST] <furq> well that's x265 vs libvpx, which isn't quite the same thing, although it is in practice
[23:46:24 CEST] <furq> afaik google have pretty much abandoned libvpx vp9 at this point in favour of av1
[23:46:32 CEST] <thebombzen> has av1 been frozen yet?
[23:46:36 CEST] <furq> no
[23:46:39 CEST] <thebombzen> ah okay
[23:46:43 CEST] <furq> some time this year iirc
[23:46:43 CEST] <alexpigment> another codec i have to research... :)
[23:46:55 CEST] <furq> av1 is the alliance for open media codec
[23:46:56 CEST] <thebombzen> will av1 even be better than H.264 at hd1080
[23:47:04 CEST] <furq> ask TD-Linux, he's working on it
[23:47:24 CEST] <thebombzen> cause from what you guys were saying, HEVC/VP9 don't have much improvement over H.264 at 1080p
[23:47:35 CEST] <furq> define "much"
[23:47:40 CEST] <thebombzen> what you just said
[23:47:42 CEST] <TD-Linux> VP9 is quite an improvement
[23:47:46 CEST] <TD-Linux> @ 1080p
[23:47:53 CEST] <thebombzen> what about HEVC over H.264?
[23:48:01 CEST] <alexpigment> thebombzen: i was just saying it wasn't *worth using*, not that it doesn't have much improvement, per se
[23:48:02 CEST] <furq> the improvement is relatively bigger at 1440p/4k
[23:48:08 CEST] <thebombzen> lol I know that
[23:48:20 CEST] <TD-Linux> AV1 is hopefully better at lower resolutions too
[23:48:21 CEST] <thebombzen> I am fully aware that HEVC and vp9 really shine at uhd
[23:48:42 CEST] <thebombzen> but does HEVC really have a drastic improvement over H.264 at hd1080?
[23:48:50 CEST] <nightlingo> Hello
[23:48:54 CEST] <thebombzen> Hello
[23:48:54 CEST] <TD-Linux> <furq> afaik google have pretty much abandoned libvpx vp9 at this point in favour of av1 <- there is a lot of activity in the libvpx tree still, they depend on it a lot for YT
[23:49:05 CEST] <TD-Linux> certainly less dead than x264 :^)
[23:49:19 CEST] <furq> fair enough
[23:49:33 CEST] <thebombzen> TD-Linux: what do you mean by "AV1 is hopefully better at lower resolutions too"
[23:49:35 CEST] <furq> i take it no major new features are planned though
[23:49:48 CEST] <thebombzen> is it currently not better than H.264 with the given testing?
[23:49:50 CEST] <furq> like, you know, frame multithreading
[23:50:10 CEST] <furq> thebombzen: it was better than vp9 last time i asked him about this
[23:50:17 CEST] <furq> which was about a week ago
[23:50:38 CEST] <nightlingo> I want to slice a small part from an .mp4 file. How can I use the exact same format and settings on the output file as the input file? I dont want to use -c copy though, because it doesnt work well when the split happens in a non-keyframe moment
[23:50:40 CEST] <thebombzen> yea cause remember that UHD is the new hip thing but most people still have 1080 monitors
[23:50:48 CEST] <thebombzen> so many many people still consume 1080p video
[23:51:10 CEST] <thebombzen> I think neglecting 1080p as "that's so 2010" or something like that is a mistake
[23:51:10 CEST] <furq> well if you're targeting the mass market then vp9/hevc are out anyway
[23:51:17 CEST] <furq> and av1
[23:51:32 CEST] <furq> and it's not like it'll perform worse than h264 at 1080p
[23:51:45 CEST] <thebombzen> well "performing slightly better" isnt' good enough
[23:51:53 CEST] <thebombzen> bitrate ratio-wise
[23:51:55 CEST] <TD-Linux> thebombzen, no it's way better than h.264
[23:51:59 CEST] <furq> i don't think it's a case of "tuning for 4k" as it is that that's where the obvious gains are to be made
[23:52:00 CEST] <thebombzen> at 1080?
[23:52:03 CEST] <thebombzen> excellent
[23:52:05 CEST] <furq> as much as it is
[23:52:22 CEST] <thebombzen> because to be honest I don't really care about uhd
[23:52:27 CEST] <thebombzen> and I suspect a very large number of people don't either
[23:52:39 CEST] <thebombzen> so having it be significantly better at 1080p is a really nice
[23:52:42 CEST] <furq> that number can only get smaller over time though
[23:52:58 CEST] <TD-Linux> there's some stuff that will help with very low resolutions, like 360p over vp9
[23:53:14 CEST] <thebombzen> perhaps we'll finally be able to abandon codecs that are patent-encumbered
[23:53:19 CEST] <TD-Linux> or even 144p
[23:53:21 CEST] <thebombzen> wow that's low
[23:53:25 CEST] <alexpigment> thebombzen: UHD is cool in the sense that it's throwing away less information, but the real selling point for UHD is actually HDR imho.
[23:53:30 CEST] <furq> africa video 1
[23:53:31 CEST] <thebombzen> that seems mostly useful for "new gif" technology
[23:53:49 CEST] <thebombzen> like websites that use actual video instead of GIFs
[23:53:59 CEST] <thebombzen> alexpigment: not really
[23:54:04 CEST] <furq> granted most of africa will have a higher gdp/capita than the usa by the time av1 is released
[23:54:15 CEST] <thebombzen> alexpigment: it's pretty useless if you don't have a large or HDR monitor
[23:54:21 CEST] <alexpigment> thebombzen? how do you figure? HDR is the only element of UHD that you can see from your couch?
[23:54:28 CEST] <thebombzen> no I can't see it from my couch
[23:54:36 CEST] <furq> uh
[23:54:38 CEST] <thebombzen> because my monitor displays 8bit anyway so it'll be downsampled
[23:54:41 CEST] <alexpigment> right
[23:54:43 CEST] <furq> oh
[23:54:49 CEST] <alexpigment> normal people watch TV from a TV ;)
[23:55:01 CEST] <thebombzen> normal people don't have HDR tvs
[23:55:10 CEST] <alexpigment> i realize monitor tech lags, but if 4k is really going to "take off", it's going to be because of HDR, not UHD
[23:55:27 CEST] <thebombzen> again, you're neglecting the incredible number of people who *still* use 1080p
[23:55:34 CEST] <alexpigment> thebombzen: more people have HDR TVs than have 10-bit monitors, by a very very wide margin
[23:55:43 CEST] <thebombzen> in particular remember that people of my generation frequently don't have TVs
[23:55:48 CEST] <thebombzen> and consume all multimedia on a computer
[23:55:54 CEST] <thebombzen> (I'm 21 fyi)
[23:56:10 CEST] <alexpigment> <-- *i* still use 1080p TVs. i'm just saying, the resolution is not a good selling point. HDR is the only hope of pushing along the new standard
[23:56:15 CEST] <thebombzen> sure
[23:56:22 CEST] <thebombzen> but remember that TVs themselves are declining
[23:56:27 CEST] <thebombzen> but yes HDR is great
[23:56:33 CEST] <thebombzen> also bt.2020 color primaries are good
[23:56:40 CEST] <thebombzen> much better than 709
[23:56:48 CEST] <alexpigment> it was kinda like when they tried to sell 120hz tvs and found that most people couldn't tell the difference, so they had to come up with motion interpolation... (that was a horrible idea, btw)
[23:57:17 CEST] <thebombzen> 120 Hz over 60 Hz is not useful if people are viewing 30 fps video
[23:57:22 CEST] <alexpigment> right
[23:57:24 CEST] <thebombzen> it's nice if you play video games tho
[23:57:27 CEST] <alexpigment> the point is 24fps x 5
[23:57:28 CEST] <thebombzen> and you have a powerful card
[23:57:35 CEST] <bf_> Could it be that ffmpeg tages up a lot of resources?
[23:57:40 CEST] <bf_> *takes
[23:57:42 CEST] <thebombzen> what?
[23:57:44 CEST] <thebombzen> https://upload.wikimedia.org/wikipedia/commons/b/b6/CIExy1931_Rec_2020.svg
[23:57:45 CEST] <furq> it could be
[23:57:50 CEST] <thebombzen> but look at these primaries
[23:57:51 CEST] <alexpigment> the only selling point as far as I know is just that 120hz TVs eliminate motion judder on 24fps sources
[23:57:57 CEST] <alexpigment> not motion interpolation
[23:57:59 CEST] <thebombzen> this is true they do
[23:58:13 CEST] <thebombzen> but there are pretty good algorithms to remove judder
[23:58:15 CEST] <alexpigment> yeah, you don't have to sell me on bt2020
[23:58:19 CEST] <thebombzen> mpv does it quite well
[23:58:24 CEST] <thebombzen> but damn those color primaries
[23:58:35 CEST] <bf_> this command uses 50%-100% on 8 cpus (in htop) /usr/local/bin/ffmpeg -i rtmp://localhost:1935/src/live -c:a aac -b:a 32k -c:v libx264 -b:v 128K -f flv rtmp://localhost:1935/hls/live_low -c:a aac -b:a 64k -c:v libx264 -b:v 256k -f flv rtmp://localhost:1935/hls/live_mid -c:a aac -b:a 128k -c:v libx264 -b:v 512K -f flv rtmp://localhost:1935/hls/live_hi
[23:58:46 CEST] <furq> well yeah you're encoding video and audio
[23:58:49 CEST] <alexpigment> i mean you *need* a 120hz display to eliminate 24fps judder fully. algorithms or not
[23:58:49 CEST] <furq> twice
[23:58:52 CEST] <furq> what do you expect
[23:58:54 CEST] <thebombzen> compare to this gcrap
[23:58:55 CEST] <thebombzen> https://en.wikipedia.org/wiki/Rec._709#/media/File:CIExy1931_Rec_709.svg
[23:59:06 CEST] <bf_> furq: I expect to run 10 or 20 of those processes per server
[23:59:18 CEST] <furq> well then use a faster x264 preset
[23:59:18 CEST] <thebombzen> um
[23:59:29 CEST] <thebombzen> well software encoding video is very computationally expensive
[23:59:30 CEST] <bf_> hm
[23:59:36 CEST] <thebombzen> so this should not surprise you
[23:59:48 CEST] <thebombzen> try using -preset:v fast instead of the default (which is -preset:v medium)
[23:59:49 CEST] <bf_> speedup options except buying dedicated encoding hardware?
[23:59:57 CEST] <bf_> thank you
[00:00:00 CEST] --- Wed Mar 29 2017