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

[burek]

[00:07:30 CEST] <idlus> Hello, I have a basic question, I am applying a filter chain '[vid1] split [a][b]; [a] crop=... [a]; [b] crop=..., scale=-1:.6*ih, [a] overlay=0:main_h-overlay_h, scale=4/3*ih:ih'
[00:09:44 CEST] <idlus> the resulting jpg file has dimensions 925x694 and a "density" parameter of 954x925
[00:10:39 CEST] <idlus> some viewers display at 925x694 while another (mpv) resizes at 954x694
[00:10:58 CEST] <idlus> What am I missing?
[00:12:21 CEST] <damata> I'am Using ffmpeg + ffserver to stream audio from a input mic in my raspberry, on my pc i have almost 0 delay but when e play the stream in my phone (android) i have almost 2 seconds delay. Can i fix this and have better delay on my phone ?
[00:14:50 CEST] <damata> iam using vlc in both pc and smartphone
[00:45:59 CEST] <rhizome> hi all. i have a video where the video freeze-frames for some seconds. time continues, so it's not like the decode is hung or anything, just multiple duplicate frames. is there anything in ffmpeg that can detect (and hopefully remove) these frames? re-encoding is not a problem.
[00:56:01 CEST] <rhizome> the alternate strategy i can think of is to manually step through frames, comparing each to its previous, using some language
[01:05:33 CEST] <klaxa> rhizome: maybe you can use the decimate filter https://ffmpeg.org/ffmpeg-filters.html#decimate-1
[01:07:41 CEST] <klaxa> this drops at regular intervals though
[01:19:25 CEST] <furq> !filter mpdecimate @rhizome
[01:19:34 CEST] <furq> uh
[01:24:01 CEST] <furq> !filter mpdecimate @rhizome
[01:24:01 CEST] <nfobot> rhizome: http://ffmpeg.org/ffmpeg-filters.html#mpdecimate
[02:04:32 CEST] <thebombzen> does anyone know anything about the AV1 bitstream freeze?
[03:16:53 CEST] <damata> I'am Using ffmpeg + ffserver to stream audio from a input mic in my raspberry, on my pc i have almost 0 delay but when e play the stream in my phone (android) i have almost 2 seconds delay. Can i fix this and have better delay on my phone ? i'am using vlc in both pc and smartphone
[03:49:57 CEST] <rhizome> furq: klaxa perfect, thanks
[09:51:27 CEST] <dystopia_> is there anyway to toggle flags on the fly?
[09:51:34 CEST] <dystopia_> like -re
[09:52:28 CEST] <Nacht> Define: on the fly
[09:52:39 CEST] <dystopia_> while an encode is running
[09:52:46 CEST] <Nacht> Why ?
[09:52:48 CEST] <dystopia_> i hit a key to enable / disable -re
[09:53:08 CEST] <dystopia_> because if im encoding from a live source, and im a far behind live i could disable it to catch up
[09:53:27 CEST] <dystopia_> and when i get to a few seconds behind live, i would enable it, to prevent hitting the end of the file
[09:53:36 CEST] <c_14> You shouldn't use -re with a live source anyway
[09:53:53 CEST] <dystopia_> what would be the preferred method c_14?
[09:54:02 CEST] <c_14> just without -re
[09:54:10 CEST] <c_14> You can't read faster than realtime from a live source anyway
[09:54:11 CEST] <Nacht> Yeah, -re is for when, for example, you have a VOD which you transmux to a stream
[09:54:19 CEST] <dystopia_> no because then i encode faster than the source, hit the end of the file
[09:54:24 CEST] <dystopia_> before the show has finnished
[09:54:29 CEST] <c_14> Is your live source an actual file?
[09:54:34 CEST] <dystopia_> and ffmpeg things it's over
[09:54:39 CEST] <dystopia_> a tv show for example
[09:54:43 CEST] <dystopia_> being written to a .ts file
[09:55:10 CEST] <c_14> You want to feed ffmpeg the bytes as they're being written, not the file itself
[09:55:37 CEST] <dystopia_> so if the show is 50fps, i use -re to encode at 50fps, which works well but it would be nice to toggle
[09:55:59 CEST] <dystopia_> hmm im not sure i have the skills to code somthing to do that c_14
[09:56:11 CEST] <c_14> How is the show being saved to the .ts file?
[09:56:38 CEST] <dystopia_> via dvb application called dvbviewer, it writes it to disk as .ts
[09:56:54 CEST] <dystopia_> hadware is a bda capture device
[09:56:59 CEST] <dystopia_> hardware*
[09:58:16 CEST] <c_14> I'd probably get dvbviewer to write to a fifo then and let ffmpeg read from that
[09:58:55 CEST] <c_14> Is this Windows or Linux?
[09:59:28 CEST] <dystopia_> windows
[09:59:30 CEST] <c_14> On windows you could probably use ffmpeg's dshow input to directly grab from the device and use that
[10:00:03 CEST] <c_14> try `ffmpeg -f dshow -list_devices`
[10:00:05 CEST] <dystopia_> i don't think that would be possible because i use plugins in dvbviewer to access my ca card to decrypt channels
[10:00:20 CEST] <c_14> mhm
[10:00:35 CEST] <dystopia_> it might with the fta stuff
[10:00:52 CEST] <dystopia_> but im not sure who i would be able to tell ffmpeg which transponder to lock to
[10:01:02 CEST] <dystopia_> and then which channel in the transponder to encode from
[10:02:33 CEST] <dystopia_> Unrecognized option 'list_devices'.
[10:02:33 CEST] <dystopia_> Error splitting the argument list: Option not found
[10:07:48 CEST] <c_14> You might want to see if dvbviewer can output as a network stream which ffmpeg can listen on or try outputting to a Named Pipe somehow. Toggling -re is technically possible with the realtime filter, but would most likely require coding your own ffmpeg replacement
[10:11:48 CEST] <dystopia_> ok, thank you for the info c_14
[10:11:53 CEST] <dystopia_> will do some research
[11:32:57 CEST] <flux> so the packet.dts of first packet can be negative, but can the packet.pts be positive?
[11:34:22 CEST] <BtbN> of course it can?
[11:34:56 CEST] <flux> right, I was thinking if it might be somehow normalized to always be zero
[11:34:59 CEST] <flux> thank you :)
[11:35:16 CEST] <BtbN> I'm not sure I understand your question
[11:35:35 CEST] <BtbN> them being positive is the normal. Being negative in the beginning is the exception
[11:35:47 CEST] <flux> yes, normal, but I'm talking only about the first frame
[11:35:51 CEST] <flux> can pts>0 in first frame?
[11:36:08 CEST] <BtbN> I don't think pts need to start at 0
[11:36:20 CEST] <BtbN> neither do dts
[11:36:35 CEST] <BtbN> depends on the container though
[11:37:46 CEST] <flux> so I'm looking at an ISO MPEG4 file and the CompositionOffset of its first sample is 512 (in time scale units)
[11:37:57 CEST] <flux> how av_read_frame doesn't say dts=0, pts=512?
[11:38:24 CEST] <flux> (no edit list)
[12:26:04 CEST] <borsh> Has anybody tried to stream to chaturbate.com?
[12:26:42 CEST] <borsh> ffmpeg -i ... -f flv "$url token=$token"
[12:27:01 CEST] <borsh> It works, the stream is getting accepted, no errors.
[12:27:26 CEST] <borsh> But the video is not getting published. And the stream is offline on the site.
[12:27:32 CEST] <borsh> Am I missing any extra rtmp flags?
[12:36:38 CEST] <borsh> Nothing special in obs about this https://github.com/jp9000/obs-studio/blob/4c58dcf65c426eaa83541c8e752a01b18319edf1/plugins/rtmp-services/data/services.json
[12:36:45 CEST] <borsh> But obs is intended to just work
[12:51:06 CEST] <stevenliu> do you want publish stream to the rtmpserver?
[12:51:15 CEST] <stevenliu> borsh: ?
[13:14:47 CEST] <borsh> stevenliu: yes.
[13:18:48 CEST] <hendry> hmm, i noticed the 1080p video i uploded to youtube is 3.8GB 1920x1080 [SAR 1:1 DAR 16:9], 15549 kb/s... but when i download from yt it's a 517mb  1920x1080 [SAR 1:1 DAR 16:9], 2381 kb/s
[13:19:30 CEST] <hendry> so since i've trusted YT to keep a keep "an original" copy, I'm screwed right?
[13:20:34 CEST] <klaxa> youtube never keeps originals
[13:20:47 CEST] <klaxa> hasn't ever iirc
[13:20:51 CEST] <borsh> hendry: `youtube-dl -F $url`
[13:20:59 CEST] <borsh> hendry: it will show you the available formats
[13:21:32 CEST] <borsh> hendry: vp9 could be pretty close to the original
[13:21:57 CEST] <hendry> borsh: https://s.natalian.org/2017-09-01/1504264899_2548x1398.png
[13:22:43 CEST] <hendry> borsh: can't see vp9... so I assume: "137          mp4        1920x1080  DASH video 4934k , avc1.640028, 30fps, video only" is better?
[13:22:53 CEST] <hendry> borsh: video in question: youtube-dl -F https://www.youtube.com/watch?v=X0wTCckdUNI
[13:22:57 CEST] <borsh> hendry: looks like you want 137 and 140
[13:23:32 CEST] <borsh> vp9 could appear later
[13:24:15 CEST] <hendry> borsh: oh, wonder if youtube-dl can combine them to save the trouble
[13:24:23 CEST] <hendry> borsh: very very useful info thank you
[13:24:38 CEST] <borsh> hendry: ffmpeg could combine easily
[13:24:41 CEST] <hendry> borsh: so i still have a good chance of recovering a new original i take it
[13:25:35 CEST] <hendry> borsh: so i still have a good chance of recovering "a near" original i take it
[13:26:08 CEST] <borsh> hendry: ffmpeg -i video07642530.mp4 -i audio76053249.m4a -c copy a-new-near-original.mkv
[13:26:45 CEST] <borsh> hendry: notice you could probably use mp4 or nut or whatever instead of mkv for the output file
[13:26:52 CEST] <borsh> depends on your needs or preferences&
[13:33:46 CEST] <hendry> borsh: something that i can play back in the browser via a video element 😅
[13:37:47 CEST] <borsh> hendry: then you could use them as-is or try merging into mp4 or flv or mpegts
[13:43:21 CEST] <borsh> stevenliu: looks like obs is not an option as it requires some unavailable on this hardware opengl features http://dpaste.com/2BF486J
[13:43:31 CEST] <hendry> borsh: thanks again for taking the time
[13:44:32 CEST] <hendry> ive stopped using obs. prefer to multicam edit bu taking ffmpeg capture + mp4 from canon in fcpx 10.3
[13:44:58 CEST] <borsh> hendry: ffmpeg works but I'm missing some extra rtmp flags
[13:44:59 CEST] <borsh> ffmpeg -i ... -f flv "$url token=$token"
[13:45:11 CEST] <borsh> hendry: the stream is getting accepted by the server but just not getting published
[13:45:16 CEST] <borsh> I've tried setting live=1
[13:46:02 CEST] <borsh> hendry: what is the proper rtmp vo for chaturbate?
[13:50:53 CEST] <borsh> hendry: I wanted to run obs for dicovering rtmp options using rtmpdump
[13:50:54 CEST] <hendry> borsh: wat? haha, no idea. tested with twitch?
[13:51:02 CEST] <borsh> hendry: twitch works.
[13:51:22 CEST] <borsh> But twitch will ban me for the content I provide :D
[13:51:22 CEST] <hendry> sorry, i have zero exp with live
[13:51:43 CEST] <borsh> obs wants opengl 3.2 but the card only provides 2.0
[13:51:44 CEST] <hendry> borsh: going to assume the worst 😂
[13:51:47 CEST] <borsh> So it is failing to start.
[13:53:31 CEST] <borsh> this is what I mean by live -> ffmpeg -i ... -f flv "$url token=$token live=1"
[13:53:58 CEST] <borsh> I will return in half an hour
[13:54:03 CEST] <borsh> hendry: good luck!
[13:57:11 CEST] <damata> I'am Using ffmpeg + ffserver to stream audio from a input mic in my raspberry, on my pc i have almost 0 delay but when e play the stream in my phone (android) i have almost 2 seconds delay. Can i fix this and have better delay on my phone? Using vlc in both pc and smartphone
[14:08:33 CEST] <stevenliu> borsh: ffmpeg -re -i input.mp4 -c copy -f flv rtmp://blablabla.com/live/stream    can you give me a rtmpserver , let me try it :)
[14:29:18 CEST] <borsh> stevenliu: rtmp://live.stream.highwebmedia.com/live-origin
[14:29:51 CEST] <BtbN> stevenliu, can always use Twitch or YouTube
[14:31:32 CEST] <stevenliu> I usually use my own rtmpserver ....
[14:32:41 CEST] <borsh> hendry: what is multicam edit?
[14:32:51 CEST] <stevenliu> borsh: what's your stream name?
[14:33:00 CEST] <borsh> stevenliu: not sure what it is
[14:33:11 CEST] <stevenliu> for example: rtmp://live.stream.highwebmedia.com/live-origin/streamname
[14:33:16 CEST] <borsh> stevenliu: I only have the link and the stream token
[14:33:20 CEST] <borsh> No stream name afaik
[14:34:28 CEST] <BtbN> that token is most likely the name.
[14:34:32 CEST] <BtbN> But it's private
[14:35:24 CEST] <borsh> BtbN: token is used like this: ffmpeg -i ... -f flv "$url token=$token live=1"
[14:35:36 CEST] <borsh> it is an rtmp option
[14:35:59 CEST] <borsh> pass a wrong option to get the list of valid rtmp options
[14:36:02 CEST] <stevenliu> I think the $url and $token is a var
[14:36:46 CEST] <borsh> I provide both $url and $token vars but 'live=1' does not help to get the stream published
[14:40:06 CEST] <borsh> hendry: stevenliu: more info: https://support.chaturbate.com/customer/portal/articles/2831439-external-encoders-and-obs
[14:40:49 CEST] <borsh> I will try passing more random options heh
[14:41:49 CEST] <stevenliu> Let me try to login in it :D
[14:42:01 CEST] <stevenliu> maybe sex video, haha
[14:42:09 CEST] <stevenliu> many sex video
[14:44:18 CEST] <borsh> pubUser pubPasswd are interesting fields
[14:52:53 CEST] <stevenliu> Ohho, it need my more information...
[14:59:17 CEST] <borsh> stevenliu: these fields are accepted by ffmpeg via librtmp: http://dpaste.com/2CNT423
[15:00:20 CEST] <stevenliu> i know
[15:00:31 CEST] <stevenliu> ffmpeg support these yet
[15:00:48 CEST] <stevenliu> but i don't know how should i do
[15:01:01 CEST] <stevenliu> i don't want share my more information to the site
[15:02:01 CEST] <borsh> ok fixed obs with LIBGL_ALWAYS_SOFTWARE=1
[15:02:06 CEST] <borsh> now it thinks I have opengl 3
[15:02:14 CEST] <borsh> how do I rtmpdump what I'm streaming?
[15:02:29 CEST] <borsh> I really want to get these rtmp options asap
[15:03:56 CEST] <borsh> stevenliu: obs only need the token for streaming, no username or password
[15:33:17 CEST] <borsh> stevenliu: obs now works
[15:33:31 CEST] <borsh> I can stream and see the video is getting published
[15:34:27 CEST] <borsh> How do I rtmpdump what I'm streaming now? :D
[15:34:41 CEST] <borsh> I want to derermine these rtmp options!!
[17:27:49 CEST] <borsh> I can't figure out how to use rtmpdump on my stream
[17:36:27 CEST] <bigx> hello, Im trying to leverage hw encoding with some filter_complex
[17:36:42 CEST] <bigx> but I when I do it, I see a 400% cpu usage
[17:36:55 CEST] <bigx> so clearly noy HW accelerated
[17:37:25 CEST] <bigx> how is filter_complex supported with nvenc?
[17:44:00 CEST] <durandal_1707> bigx: only with hw filters you will get less cpu usage
[17:44:46 CEST] <bigx> thanks durandal_1707 , do you know any hw overlay filter ?
[17:44:53 CEST] <BtbN> There is none
[17:48:18 CEST] <Fenrirthviti> Hmm. Does this actually test the hardware support, or is it just checking what the driver says? https://gist.github.com/Brainiarc7/c6164520f082c27ae7bbea9556d4a3ba
[17:48:40 CEST] <Fenrirthviti> Context: Trying to find a simple way to actually test NVENC support on a given system.
[17:49:11 CEST] <Fenrirthviti> Since many laptop GPUs are scale-downs that don't have NVENC support, even though the driver reports it does. When you try to encode anything, it just fails.
[17:49:44 CEST] <BtbN> Fenrirthviti, it does not check anything. It only lists which npp|cuvid|nvenc|cuda encoders/decoders/filters ffmpeg was compiled with.
[17:49:53 CEST] <Fenrirthviti> Drat, that's what I feared.
[17:50:16 CEST] <Fenrirthviti> That's what we do now, and it's giving false positives for actual support and making for annoyed end users (and me, cause I have to hear about it)
[17:50:28 CEST] <Fenrirthviti> Rather, we do something similar now I should say.
[17:50:45 CEST] <borsh> Is it possible to use radeon gpu for speeding up x264 encoding or hqdn3d?
[17:51:05 CEST] <BtbN> The x264 opencl support is rather minimal. Don't use it. In worse cases it can even make stuff slower.
[17:51:09 CEST] <borsh> What is the filter name for chroma key?
[17:51:11 CEST] <BtbN> And I have no idea what hqdn3d is.
[17:51:16 CEST] <BtbN> chromakey.
[17:51:28 CEST] <BtbN> Fenrirthviti, you'll need to actually try and decode/encode/filter something to be sure your set of parameters is supported.
[17:51:36 CEST] <borsh> hqdn3d is a fine denoise thing
[17:52:17 CEST] <Fenrirthviti> BtbN: I was afraid of that too, dangit. Thanks for clarifying.
[17:52:38 CEST] <Fenrirthviti> nvidia's documentation is infuriatingly sparse.
[17:52:38 CEST] <BtbN> The filters pretty much always work though, when there is a CUDA capable GPU
[17:53:04 CEST] <borsh> is not it possible to run chromakey on gpu?
[17:53:15 CEST] <BtbN> If someone were to write a CUDA version of it.
[17:54:09 CEST] <borsh> Don't you also know how to rtmpdump the stream generated by obs?
[17:54:16 CEST] <borsh> I'm trying to get the rtmp flags
[17:55:29 CEST] <borsh> Because the stream generated by ffmpeg is not getting published and I'm trying to determine how it is different from obs one
[17:57:41 CEST] <BtbN> you connect to the server with rtmpdump, and dump the stream?
[17:59:13 CEST] <borsh> Probably not the option as the server is modifying the stream.
[17:59:34 CEST] <bigx> if there is no hw overlay filter, I then wont be able to use gpu encoding, right?
[17:59:47 CEST] <Fenrirthviti> borsh: You can't intercept the stream from OBS -> Server if that's what you're asking
[18:00:11 CEST] <borsh> Should I use strace or something instead?
[18:00:38 CEST] <borsh> I'm not sure how to derermine the rtmp options obs enables for the stream.
[18:00:59 CEST] <Fenrirthviti> What are you actually trying to do here?
[18:01:27 CEST] <borsh> I'm streaming to charutbate.com, the steam is getting accepted by the server but is not getting published.
[18:01:38 CEST] <BtbN> obs sets the rtmp options you tell it to?
[18:01:53 CEST] <borsh> BtbN: it only asks for the stream token
[18:01:59 CEST] <Fenrirthviti> You should probably contact chaturbate support. They're pretty solid, very knowledgeable.
[18:02:00 CEST] <borsh> It is the same option I set with ffmpeg.
[18:02:11 CEST] <borsh> I think it is setting something else in addition
[18:02:16 CEST] <BtbN> rtmp://server/endpoint_name/token
[18:02:19 CEST] <BtbN> that's all OBS sets
[18:02:35 CEST] <Fenrirthviti> well, not strictly true.
[18:02:39 CEST] <BtbN> It has a seperate, read-protected box for the token though
[18:03:08 CEST] <borsh> I thought it should be something like this: ffmpeg -i ... -f flv "$url token=$token"
[18:03:18 CEST] <Fenrirthviti> OBS doesn't use ffmpeg for rtmp
[18:03:22 CEST] <BtbN> seems like it's not
[18:03:23 CEST] <Fenrirthviti> it uses librtmp
[18:03:45 CEST] <borsh> librtmp allows ffmpeg to use 'token' rtmp option (and others)
[18:03:53 CEST] <borsh> I'm trying to use ffmpeg and not obs
[18:04:53 CEST] <Fenrirthviti> I know for an absolute fact that OBS works with chaturbate, I spent time working with them on it.
[18:05:11 CEST] <borsh> obs works for me!
[18:05:27 CEST] <borsh> I started trying obs when wanted to determine the rtmp options it uses
[18:05:32 CEST] <Fenrirthviti> Ahhh, wait I understand here, sorry.
[18:06:48 CEST] <borsh> BtbN: So should I try appending token to the url instead of using the rtmp option from librtmp?
[18:07:20 CEST] <Fenrirthviti> you should be able to just do -f flv rtmp://host/app/token
[18:07:52 CEST] <borsh> Fenrirthviti: already checked and it works!
[18:07:55 CEST] <borsh> Thanks.
[18:08:11 CEST] <borsh> -f flv "$url/$token"
[18:08:30 CEST] <borsh> Looks like I don't even need librtmp.
[18:08:43 CEST] <borsh> obs uninstall time!
[18:08:55 CEST] <BtbN> an rtmp url is always rtmp://server/ingest_name/stream_name
[18:09:03 CEST] <BtbN> if it's longer or shorter than that, it's wrong
[18:09:39 CEST] <borsh> right, the $url is rtmp://live.stream.highwebmedia.com/live-origin
[18:10:24 CEST] <azarus> Hey, I can't seem to be getting the vp8_vaapi or vp9_vaapi encoder to work. Here's what I tried: "ffmpeg -i in.mp4 -c:v vp8_vaapi out.webm" And here's the output: http://ix.io/zwZ
[18:11:50 CEST] <BtbN> There is no vp9_vaapi encoder.
[18:12:42 CEST] <jkqxz> azarus:  It can only encode things which are already in GPU surfaces.  See <https://trac.ffmpeg.org/wiki/Hardware/VAAPI> (the encoding section).
[18:12:44 CEST] <BtbN> And for vp8, you need to set the hwaccel options, and/or insert an upload filter
[18:13:00 CEST] <jkqxz> BtbN:  Yes there is.
[18:13:05 CEST] <BtbN> where?
[18:13:16 CEST] <BtbN> I only see encode_vp8.c
[18:13:35 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vaapi_encode_vp9.c>
[18:13:50 CEST] <jkqxz> Old version?
[18:14:12 CEST] <azarus> Thanks, jkqxz, I'll try that.
[18:16:46 CEST] <BtbN> What hardware even supports vp9 encoding? And how terrible is it?
[18:17:21 CEST] <borsh> Which hardware to buy if I want to reencode a lot of videos fast with fine encoding quality?
[18:17:37 CEST] <BtbN> Bunch of Threadripper-Servers
[18:17:44 CEST] <BtbN> Or wait for Epyc, and then a bunch of those
[18:18:05 CEST] <borsh> And which encoder will I use?
[18:18:19 CEST] <jkqxz> BtbN:  Kaby Lake (and then probably all future Intel).  As hardware encode goes it's surprisingly not-completely-terrible, and obviously it wins epically on speed.
[18:18:21 CEST] <BtbN> Depends on what codec you need
[18:18:30 CEST] <borsh> Not sure on this one.
[18:18:38 CEST] <jkqxz> Though obviously all normal caveats about hardware encoding apply.
[18:19:47 CEST] <azarus> What's better for encode, an overclocked i5-6600K or a stock i7-2600? (Note the generational difference)
[18:20:16 CEST] <BtbN> most likely the SKL I'd say, but hard to tell for sure without testing
[18:20:26 CEST] <alexpigment> azarus: hardware or software?
[18:20:32 CEST] <borsh> is H.264 good or should I try vp8/vp9?
[18:21:04 CEST] <jkqxz> The 6600K will win by a long way.  SMT is only a marginal benefit and everything else is in its favour (clock, memory speed, IPC, etc.).
[18:21:56 CEST] <alexpigment> borsh: personally, H.264 is still a great codec, and its hardware support is way better than anything else at this point. I don't see any reason to switch to vp8/vp9
[18:22:11 CEST] <BtbN> license fees.
[18:22:21 CEST] <alexpigment> that's a fair point
[18:22:42 CEST] <borsh> The video is not getting sold
[18:22:53 CEST] <alexpigment> still, i'd imagine someone trying to watch vp8 on a 4-year-old phone or tablet is not going to be a great experience
[18:23:38 CEST] <BtbN> Not sure what the exact license terms are, but when you offer it publicly, you might have to pay.
[18:23:52 CEST] <jkqxz> VP8 is not really useful for anything.  VP9 is gaining quite a bit of traction now and does offer significant benefits, but it is still a pretty big pain on old devices.
[18:24:13 CEST] <BtbN> YouTube technically also does not sell the videos.
[18:24:15 CEST] <alexpigment> H.264 licensing is actually not bad. You have to go up to a certain amount of units before you have to pay. AAC on the other hand...
[18:24:36 CEST] <jkqxz> BtbN:  You need to sell a lot of units (100k?).  And just streaming doesn't count, that has an exemption nowadays.
[18:24:42 CEST] <azarus> I'm suprised how well cheap smartphones can handle FHD stream with no problem.
[18:24:52 CEST] <BtbN> They all have hardware decoders.
[18:24:53 CEST] <azarus> Also, in VP8.
[18:25:04 CEST] <BtbN> And VP8 is rather cheap to decode on CPU as well
[18:25:55 CEST] <jkqxz> There is still pretty much no reason to use VP8 over H.264 unless you are Google.
[18:26:53 CEST] <alexpigment> still, vp9 hardware decoder just happened in the past few years
[18:27:13 CEST] <alexpigment> like for nvidia, you have to have a 900 series card or above (which I do, but not everyone will)
[18:27:19 CEST] <BtbN> Browsers are only very slowly starting to adopt it
[18:27:31 CEST] <BtbN> And on Linux there is a lack of APIs
[18:27:50 CEST] <alexpigment> I just feel like until the hardware support is ubiquitous, it's best to stick with H.264
[18:28:39 CEST] <alexpigment> Also, one thing I learned when trying to avoid licensing issues with AAC audio is that Apple products will not play sound from an MP4 with MP3 audio
[18:28:50 CEST] <alexpigment> Even though MP4 technically supports it
[18:29:03 CEST] <alexpigment> But if you rename it to F4V, Apple products will play the audio
[18:29:19 CEST] <alexpigment> Greedy tactics, but whatever..
[18:35:02 CEST] <azarus> Yay, vp8_vaapi works for me!
[18:35:12 CEST] <azarus> And with very fast speed :D
[18:35:50 CEST] <BtbN> But probably very ugly quality
[18:36:10 CEST] <azarus> I'll see, and probably i'll bump up the bitrate,
[18:36:31 CEST] <BtbN> vp8 will need quite a lot of bitrate, specially when hw encoded
[18:37:31 CEST] <jkqxz> Also make sure you have the recent driver (> 1.8.1ish?).  The one before that was basically a placeholder and laughably terrible.
[18:38:06 CEST] <azarus> jkqxz: The vaapi driver?
[18:38:28 CEST] <jkqxz> Yeah.
[18:39:02 CEST] <azarus> I have 1.8.3
[18:39:37 CEST] <jkqxz> Then you're good.
[18:51:05 CEST] <azarus> Okay, vp8_vaapi is 12.5x faster, but produces 'okay' quality.
[18:51:22 CEST] <azarus> Difference not perceptible to me as of now.
[18:58:23 CEST] <alexpigment> BtbN: I figured out what's up with NVENC's interlaced handling btw. I was in the process of logging up a new issue and it seems that the fields are just reversed. if you bob deinterlace it, the motion jumps back and forth each frame (i.e. each field prior to bob deinterlace))
[18:59:37 CEST] <BtbN> If that's the case, just put a https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L1857 in here.
[18:59:45 CEST] <BtbN> a !
[19:00:13 CEST] <BtbN> Would seem weird though. The if looks correct
[19:00:43 CEST] <alexpigment> a ! is some sort of reverse command?
[19:01:13 CEST] <alexpigment> at any rate, now that I see where to make the change, I can test this on my own
[19:01:16 CEST] <alexpigment> Thanks for the heads up
[19:01:23 CEST] <BtbN> Just negates the condition
[19:01:25 CEST] <alexpigment> I'll finish logging up the issue here in a bit
[19:01:41 CEST] <alexpigment> Cool, thanks for confirming that
[19:01:45 CEST] <BtbN> I'd call this a bug on nvidias end though, if this is the wrong way around.
[19:02:15 CEST] <BtbN> Cause NV_ENC_PIC_STRUCT_FIELD_TOP_BOTTOM is definitely documented as top field first
[19:02:23 CEST] <alexpigment> Well, I tested it in another application that does NVENC and it was correct. Maybe they're doing it backwards too
[19:02:42 CEST] <alexpigment> Yeah, I'll make this change and confirm. There could be another problem in the pipeline
[19:10:57 CEST] <nelder> hi guys, does anybody can help me to understand what does it mean when i play .m4a file wich was compressed from .flac by means of 'ffmpeg -i <file> -codec:a libfdk_aac  -b:a 225K <result.m4a>'?
[19:11:17 CEST] <nelder> i have this warning -> [lavf] Edit lists are not correctly supported (FFmpeg issue)
[19:12:05 CEST] <nelder> when I listen original .flac-files I don't see this warning
[19:49:57 CEST] <acos> Hi
[19:50:16 CEST] <nelder> hi
[19:50:54 CEST] <BtbN> alexpigment, are you using mkv by any chance, for your interlaced testing?
[20:02:02 CEST] <alexpigment> BtbN: no, MP4 input and output
[20:02:37 CEST] <BtbN> anyway, field ordering is broken globally in ffmpeg. nvenc is not at fault, it does its part correctly. And at least when muxing to mpeg-ts it works fine.
[20:03:00 CEST] <alexpigment> then why does libx264 not suffer from the same problem?
[20:03:10 CEST] <BtbN> It does
[20:03:16 CEST] <alexpigment> Not in my tests
[20:03:24 CEST] <alexpigment> But I just rebuilt, so I'll check again
[20:03:39 CEST] <BtbN> I just tested it 5 minutes ago. No matter what encoder I use, it's equally broken everyhwere.
[20:03:50 CEST] <alexpigment> I'll confirm your findings in 2-3 minutes
[20:03:51 CEST] <BtbN> It's quite obvious with ffprobe
[20:04:10 CEST] <BtbN> The input is Stream #0:0(eng): Video: h264 (High), yuv420p(top first), 1920x1080
[20:04:17 CEST] <BtbN> Output is Stream #0:0(eng): Video: h264 (Main), yuv420p(top coded first (swapped))
[20:04:51 CEST] <BtbN> That information that breaks it is purely in the muxer. h264 itself does not even carry that information.
[20:06:09 CEST] <alexpigment> ok, so where's what I'm doing:
[20:06:35 CEST] <alexpigment> (btw, I just retried in my newest rebuild, but I specified "prefer stable"
[20:06:38 CEST] <alexpigment> no I'm not on a nightly
[20:06:53 CEST] <BtbN> I'm only ever testing and comparing git master.
[20:07:23 CEST] <alexpigment> ffmpeg.exe -i interlacedsample.mp4 -c:v libx264 -b:v 8000000 -pix_fmt yuv420p -flags +ilme+ildct -profile:v high -level 41 interlacedoutput.mp4
[20:07:42 CEST] <alexpigment> https://trac.ffmpeg.org/attachment/ticket/6260/interlacedsample.mp4
[20:07:55 CEST] <alexpigment> output is interlaced and as smooth as the original
[20:08:57 CEST] <alexpigment> I also tried the change you suggested, and it still looks busted for nvenc
[20:11:59 CEST] <BtbN> It looks completely fine to me, on both of them
[20:12:06 CEST] <BtbN> No artifacts, no jumping, nothing
[20:13:25 CEST] <alexpigment> is it possible you could post your interlaced sample somewhere so I can see it and do some investigating?
[20:13:36 CEST] <BtbN> I'm using the same one.
[20:13:42 CEST] <alexpigment> sorry
[20:13:51 CEST] <alexpigment> sample of your interlaced output from nvenc
[20:16:04 CEST] <BtbN> alexpigment, https://btbn.de/public/out.ts
[20:16:44 CEST] <alexpigment> wow, that looks busted :)
[20:17:18 CEST] <BtbN> It looks 100% correct to me. No idea what could possibly be busted there.
[20:17:36 CEST] <alexpigment> You did see view the original, right?
[20:17:46 CEST] <alexpigment> The motion should be as smooth as 1080p60
[20:17:51 CEST] <BtbN> It is
[20:18:16 CEST] <alexpigment> Not over here at all
[20:18:35 CEST] <alexpigment> This might as well be 1080p30
[20:19:08 CEST] <BtbN> No idea what you are seeing there
[20:19:16 CEST] <BtbN> If I play them in parallel, it looks 100% identical
[20:19:30 CEST] <alexpigment> Is your player properly deinterlacing to 1080p60?
[20:19:39 CEST] <BtbN> Yes, using yadif2x
[20:19:44 CEST] <Fenrirthviti> Plays perfectly smooth for me as well, in both vlc and mpc-hc
[20:20:06 CEST] <alexpigment> I'm going to try Kodi just to triple check this
[20:21:14 CEST] <alexpigment> Weird. Kodi plays it smooth too. I'm confused why VLC and WMP don't on my end (and do for the x264 version)
[20:21:52 CEST] <BtbN> VLC plays it just fine for me as well
[20:22:01 CEST] <BtbN> In Auto-Deinterlace-Mode, with Yadif2x as deinterlacer
[20:22:08 CEST] <alexpigment> Yeah I did that
[20:22:12 CEST] <alexpigment> And then tried Bob as well
[20:22:24 CEST] <BtbN> And WMP is just trash
[20:23:04 CEST] <alexpigment> WMP is better than VLC for interlaced content
[20:23:07 CEST] <alexpigment> Which is why I use it often
[20:23:19 CEST] <BtbN> My general advice for interlaced content is to not use it.
[20:23:52 CEST] <BtbN> But my overall conclusion about this is that the nvenc side of interlaced encoding is just fine. And ffmpeg is doing something weird the field ordering.
[20:23:55 CEST] <alexpigment> BtbN: I deal with interlaced content daily. It's the primary format for broadcast and the closest you'll get to 1080p60 on Blu-ray
[20:24:06 CEST] <alexpigment> I'm doing some tests on hardware players now
[20:24:26 CEST] <BtbN> The primary format is bad then
[20:25:04 CEST] <alexpigment> Not sure what you mean by that
[20:27:26 CEST] <alexpigment> oh duh
[20:27:28 CEST] <alexpigment> I see the problem ehre
[20:27:30 CEST] <alexpigment> *here
[20:27:40 CEST] <alexpigment> You didn't make a proper 1080i30 file
[20:27:47 CEST] <alexpigment> You made a 60fps video that's interlaced
[20:27:55 CEST] <alexpigment> That's why it looks all janky
[20:28:24 CEST] <BtbN> Stream #0:0[0x100]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
[20:28:26 CEST] <BtbN> no I didn't.
[20:29:03 CEST] <alexpigment> I know you hate when people talk about MediaInfo, but why does MediaInfo say this?
[20:29:30 CEST] <BtbN> no I didn't.
[20:29:32 CEST] <BtbN> It's probably showing you the field rate. Which is indeed 59.94
[20:29:46 CEST] <alexpigment> It never shows the field rate in place of the frame rate
[20:30:26 CEST] <alexpigment> Somewhere in the stream is a flag that's saying it's 59.94
[20:30:39 CEST] <alexpigment> let me hexedit it
[20:30:54 CEST] <BtbN> 59.94 tbc
[20:31:18 CEST] <alexpigment> what does the x264 variant say for the tbc?
[20:32:09 CEST] <BtbN> the same
[20:32:18 CEST] <BtbN> tbc is the timebase
[20:32:30 CEST] <alexpigment> And it plays just fine over here and is reported correctly in MediaInfo
[20:32:39 CEST] <alexpigment> so it's not the tbc and it's not the field rate
[20:32:57 CEST] <alexpigment> there's something else here that is causing some plays to play/read the file incorrectly
[20:33:06 CEST] <BtbN> analyze wise, the files look 100% identical to me
[20:33:44 CEST] <alexpigment> I don't doubt it. But I'm going to keep looking for the problem
[20:33:47 CEST] <BtbN> https://btbn.de/public/out_x264.ts
[20:33:51 CEST] <alexpigment> Because this is not compliant
[20:34:16 CEST] <BtbN> There is also this: https://github.com/FFmpeg/FFmpeg/commit/dcbf72836c90d077067248a0ddc4e4c7556e2461
[20:34:29 CEST] <BtbN> I'm pretty sure this is the main culprit for when using mp4/mkv/anything that's not ts
[20:34:34 CEST] <alexpigment> Your x264 sample doesn't show frame rate values because it's VFR, but that's not a problem
[20:34:49 CEST] <BtbN> It's mpegts
[20:34:56 CEST] <BtbN> it only has timestamps
[20:35:19 CEST] <BtbN> No idea where you are getting those readings from. They seem dubious to me
[20:35:23 CEST] <alexpigment> BtbN: I understand what you're saying. I'm just looking at it in the tools at my disposal
[20:35:33 CEST] <alexpigment> So MediaInfo is reporting it wrong, but also WMP and VLC are playing it wrong
[20:35:47 CEST] <alexpigment> So whatever MediaInfo is reading is spilling over into real-world playback issues
[20:35:52 CEST] <alexpigment> And that is my primary concern here
[20:36:00 CEST] <BtbN> Are you re-muxing it to mp4, or how are you reading it?
[20:36:07 CEST] <alexpigment> You can be a developer and say it's right, but I'm telling you that it's not right based on results
[20:36:16 CEST] <alexpigment> I'm playing the ts in VLC
[20:36:35 CEST] <alexpigment> I remuxed to TS with Tsmuxer and also remuxed to MP4 with ffmpeg, just to check
[20:36:54 CEST] <alexpigment> all files show the frame rate as 59.94 in MediaInfo, and fail in the two players mentioned
[20:37:06 CEST] <alexpigment> the x264 version plays just fine in all players and mediainfo reports it correctly as 29.97
[20:37:31 CEST] <alexpigment> (well, mine reports it as 29.97 at least, but I'm going straight to mp4 on my end via ffmpeg)
[20:37:46 CEST] <alexpigment> your x264 just says the rate is variable
[20:37:53 CEST] <alexpigment> but it plays fine, I presume it is actually 29.97
[20:38:39 CEST] <BtbN> it's mpegts. It's always "variable" framerate
[20:38:43 CEST] <BtbN> as with a lot of other containers
[20:39:17 CEST] <alexpigment> you're focusing on this aspect and it's unimportant
[20:39:20 CEST] <alexpigment> the x264 file is fine
[20:40:58 CEST] <BtbN> The biggest difference I see is that x264 stores it as a single interlaved frames, with mbaff coding
[20:41:04 CEST] <BtbN> While nvenc uses seperate fields
[20:41:04 CEST] <alexpigment> Right
[20:41:17 CEST] <alexpigment> But I've got other separate fields files from cameras that are fine, fwiw
[20:41:28 CEST] <alexpigment> Any AVCHD camera stores it that way these days
[20:49:41 CEST] <BtbN> Whatever it is, it's not something the nvenc API gives any control over.
[20:50:10 CEST] <BtbN> The things that can be set are all set correctly
[20:50:30 CEST] <BtbN> The one questionable thing is the framerate. But it doesn't seem to matter, as container framerate overrides it anyway.
[20:50:44 CEST] <BtbN> At least just plain commenting it out or setting bullshit does not have any visible effect
[20:50:56 CEST] <alexpigment> Yeah, I'm still doing some investigating over here
[20:51:14 CEST] <alexpigment> There's a nuanced bug here, regardless of what ffprobe is showing you
[20:59:58 CEST] <alexpigment> ok, so I demuxed the two streams, put them back into mp4 with silent aac audio (just so my players can all deal with it). I ffprobed them both
[21:00:08 CEST] <alexpigment> the x264 says r_frame_rate=30000/1001
[21:00:18 CEST] <alexpigment> the nvenc says r_frame_rate=60000/1001
[21:00:37 CEST] <alexpigment> the streams are untouched
[21:01:39 CEST] <alexpigment> also the nvenc says the avg_frame_rate is 72000000/1202503
[21:01:47 CEST] <alexpigment> ~59.875
[21:04:31 CEST] <BtbN> https://btbn.de/public/out_test.ts this is with nvenc and the framerate artificially halved.
[21:04:49 CEST] <BtbN> It's still stuttering in WMP for me, so I doubt that's the issue
[21:04:57 CEST] <alexpigment> looks very bad over here
[21:05:23 CEST] <BtbN> I suspect it's something weird in the h264 bitstream
[21:05:35 CEST] <BtbN> Which is completely out of anyones but nvidias control
[21:05:45 CEST] <alexpigment> does r_frame_rate get defined in the stream or in the container?
[21:05:56 CEST] <BtbN> I have no idea what r_frame_rate is
[21:06:18 CEST] <alexpigment> I'm going to do a comparison with staxrip again, just to make sure their nvenc implementation is still working correctly
[21:06:32 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/nvenc.c;h=1220ae4b8c40d832863fa509bd193416ac4dd5c0;hb=HEAD#l1072 I stuck a *2 in there to get the halved framerate
[21:06:57 CEST] <alexpigment> Yeah, that doesn't seem like it addresses the issue here
[21:07:10 CEST] <BtbN> yep, so it's not the framerate that's the issue
[21:07:19 CEST] <BtbN> I even made a sample where I set it to 65k FPS
[21:07:37 CEST] <BtbN> still plays fine in VLC, and stutters the same in WMP. So the in-bitstream framerate is just entirely ignored, like it should
[21:07:43 CEST] <alexpigment> sorry, work is calling. be back in a second
[21:07:49 CEST] <BtbN> The container timestamps are what matters
[21:11:02 CEST] <doux> Question about terminology: Does a single packet from a stream contain one encoded frame? Or in the case of stereo audio two encoded frames?
[21:11:49 CEST] <DHE> an AVPacket should contain a single encoded video frame or a all audio channels from single period of time. again encoded
[21:12:05 CEST] <doux> DHE: thank you
[21:12:14 CEST] <DHE> but I suppose there's no guarantees. the content really should go to a decoder and it will provide the data properly to you
[21:12:35 CEST] <doux> DHE: right, just want to understand how data is stored.
[21:13:48 CEST] <DHE> an AVPacket gets decoded into an AVFrame which will contain exactly 1 video frame or exactly N samples from all channels of the audio. it's just that as I understand it all codecs do basically 1:1 mappings here
[21:14:29 CEST] <doux> DHE: each channel is in its own frame right?
[21:14:35 CEST] <doux> DHE: audio channel
[21:14:59 CEST] <DHE> no. an AVFrame contains an array of pointers and each channel maps to one array slot
[21:15:15 CEST] <DHE> unless the stored format is planar
[21:15:21 CEST] <DHE> or do I have that backwards
[21:16:23 CEST] <doux> DHE: all the channels for that time period as stored in a single frame then?
[21:17:43 CEST] <doux> i think that's what you said already. nevermind.
[21:19:37 CEST] <doux> DHE: thanks for the help
[21:19:40 CEST] <DHE> keep in mind said time period is usually fractions of a second
[21:19:53 CEST] <doux> DHE: ok
[21:46:06 CEST] <kinkinkijkin> blugh, I'm on arch, trying to do a full system update, and this comes along
[21:46:07 CEST] <kinkinkijkin> ffmpeg-git: installing x265 (2.5-1) breaks dependency 'libx265.so=116-64'
[21:46:52 CEST] <kinkinkijkin> completely stops me from being able to update my system and I don't know what package is pulling x265 2.5-1 nor why ffmpeg-git requires a very specific (and seemingly old) version of x265
[21:47:32 CEST] <kinkinkijkin> issue on the arch package maintainers' side?
[22:19:51 CEST] <acos> Sup
[23:03:45 CEST] <Martchus> kinkinkijkin: ffmpeg-git is an AUR package which you likely built and installed using some AUR helper. You need to rebuild the package against the latest x265.
[23:05:08 CEST] <Martchus> kinkinkijkin: So this is not an Arch package issue. It is just your old custom package.
[23:09:30 CEST] <kinkinkijkin> oh nice I have to force install stuff
[23:26:41 CEST] <kinkinkijkin> Martchus, built it with latest x265, it didn't install
[23:28:22 CEST] <Martchus> kinkinkijkin: You should not force the installation. The correct way of building packages is in a current, clean chroot using makechrootpkg.
[23:29:31 CEST] <kinkinkijkin> this is the only time I've seen this recommended to anyone, ever, in all of my 5 years running unixlikes fulltime
[23:29:55 CEST] <Martchus> kinkinkijkin: Do you get the same error with the new ffmpeg-git package or a different error? If you get the same error, I doubt at the current x265 was present at build time.
[23:30:49 CEST] <kinkinkijkin> no, I didn't get an error last time at build time, this time I got an error after installing saying that the dependency of x265:116-64 was not present
[23:33:02 CEST] <Martchus> kinkinkijkin: Ok, so still the same error at install/upgrade time.
[23:33:32 CEST] <Martchus> kinkinkijkin: And building in a clean chroot is really the way, checkout the Wiki https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot
[23:34:02 CEST] <Martchus> kinkinkijkin: Other distros do the same, eg. osc build under suse also uses a chroot.
[23:36:03 CEST] <kinkinkijkin> the build succeeded so, I'm thinking it's just a bad package like I expected before
[23:36:44 CEST] <kinkinkijkin> so I'll fix the package before build and build it again
[23:38:12 CEST] <kinkinkijkin> package isn't broken
[00:00:00 CEST] --- Sat Sep  2 2017