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

[burek]

[00:00:14 CET] <sfan5> >supporting webm but not mkv
[00:00:15 CET] <sfan5> smh
[00:00:33 CET] <furq> browsers
[00:00:36 CET] <furq> what do you expect
[00:00:45 CET] <sfan5> more like Google
[00:00:53 CET] <furq> firefox is the same
[00:00:54 CET] <illegal> by support you mean the browser can't play .mkvs?
[00:00:57 CET] <sfan5> damn
[00:00:58 CET] <furq> illegal: yes
[00:01:04 CET] <illegal> well yeah, even in firefox...
[00:01:20 CET] <furq> chrome, firefox and edge don't support mkv, and apple doesn't support vp9 or opus or webm
[00:01:21 CET] <alexpigment> i have a feeling MKV support is usually just because you can't make a blanket statement about supporting them, so don't even try
[00:01:30 CET] <alexpigment> it's like saying "my program supports AVIs"
[00:01:36 CET] <furq> i mean the same is true of mp4
[00:01:43 CET] <furq> browsers won't play my mpeg-4 part 2 and ac3 mp4s
[00:01:46 CET] <furq> if i chose to make any
[00:01:49 CET] <alexpigment> the official spec of MP4 is much more limited in terms of codecs
[00:02:36 CET] <alexpigment> MKV is like "here's Cineform + Opus"
[00:02:46 CET] <alexpigment> good luck finding enough players that support that combo
[00:03:06 CET] <alexpigment> anyway, my two cents on the problem of MKV support
[00:03:07 CET] <alexpigment> ;)
[00:11:36 CET] <therage3> isn't mkv like
[00:11:49 CET] <therage3> "ok, take whatever stream formats you want and shove them in here. you're welcome"
[00:12:44 CET] <SortaCore> so uh
[00:12:51 CET] <SortaCore> does rtsp h264 have a set pixel format or not
[00:13:25 CET] <JEEB> in theory H.264 can dynamically change it dynamically but it always some /some/
[00:13:32 CET] <JEEB> you get that information as soon as you get the parameter sets
[00:15:40 CET] <SortaCore> some some wat
[00:18:45 CET] <SortaCore> so it can change in the middle of a h264 stream, but it's always set to something?
[00:19:26 CET] <JEEB> yes
[00:20:01 CET] <JEEB> H.264 and HEVC decoding works like this: 1) wait for parameter sets (the stuff that tells you WTF is in those coded pictures etc.) 2) decode pictures
[00:20:16 CET] <DHE> that's the SPS in the headers?
[00:20:45 CET] <JEEB> people call parameter sets the "headers" yes, and they're generally put into a separate thing in mp4/matroska
[00:25:05 CET] <SortaCore> so I can't say "decode from whatever to NV12" without keeping whatever pix fmt it was, and then converting
[00:27:37 CET] <SortaCore> atm I'm doing it src -> AVFrame, AVFrame sws_scale -> NV12 AVFrame, then passing to hwa encoder
[00:28:32 CET] <sfan5> the decoder is going to give you whatever pixfmt it wants, there's nothing wrong with having to use sws_scale inbetween
[00:30:25 CET] <DHE> the encoded picture does explicitly specify the colourspace used. it's why yuv420p is so strongly encouraged. many decoders just don't support anything else
[00:30:32 CET] <DHE> so yes, conversion is often required between steps
[00:34:48 CET] <JEEB> SortaCore: basically you can set up your filter chain when you get your first AVFrame from the decoder. if it's NV12 (for example since you mentioned it), great. Otherwise start building a filter chain and convert to whatever your requirements are
[00:43:23 CET] <SortaCore> so is a filter chain just passing it to sws_scale
[00:45:04 CET] <SortaCore> it just seems a bit dumb you get HWA decoders and you can't use most of them because they want NV12
[00:50:11 CET] <JEEB> hardware likes NV12/P010 while software has historically done planar
[00:50:47 CET] <JEEB> NV12 is half-planar 4:2:0 (luma is separate, chroma packed), and what's called YUV420P in FFmpeg is fully planar 4:2:0
[00:51:24 CET] <JEEB> I think libx264 is one of the few SW encoders that takes in NV12 as well (no idea about the libavcodec wrapper, of course)
[00:51:29 CET] <SortaCore> if I wanted to convert that "by hand" would that be a couple memcpy or lots of complex stuff
[00:52:34 CET] <JEEB> so you have the planes separate in fully planar AAAA , BBBB , CCCC. NV12 is the same data but AAAA , BCBCBCBC
[00:53:24 CET] <JEEB> so not exactly rocket science, but it's not just memcpys or switching pointers' values
[00:53:39 CET] <JEEB> memcpys as in a single memcpy I mean
[00:53:52 CET] <JEEB> you can of course do a crapload of memcpys if you really want but I don't recommend it
[00:55:29 CET] <SortaCore> and there's no way to get the hardware encoder to do that?
[00:56:19 CET] <SortaCore> really trying to reduce any cpu footprint
[00:57:46 CET] <SortaCore> eventually, I'll need to put in rotate/flip to the image as well
[00:57:52 CET] <SortaCore> for some reason the feeds are coming in upside-down
[00:57:58 CET] <SortaCore> although VLC displays them right way up
[01:01:48 CET] <SortaCore> ...oh I see
[01:02:03 CET] <SortaCore> it's because BGR is right way up, but BMP24 expects pixels in reverse
[01:02:31 CET] <SortaCore> "The pixel data is organized in rows from bottom to top and, within each row, from left to right. Each row is called a "scan line". If the image height is given as a negative number, then the rows are ordered from top to bottom."
[01:02:40 CET] <SortaCore> oh, then easy fix by flipping image height
[01:02:42 CET] <SortaCore> ima try that
[01:05:45 CET] <JEEB> SortaCore: I don't think BGR or such define limitations on stride or height or width or so. use cases do. and yes, windows bitmaps go upside down
[01:05:53 CET] <JEEB> so that's separate from pixel formats
[01:07:38 CET] <SortaCore> I'm using a slightly dodgy way of copying files which uses an in-memory image file
[01:07:53 CET] <SortaCore> copying files to rendering part, that is
[01:08:52 CET] <SortaCore> it's an in-memory bitmap, since I thought that'd be the fastest and easiest file format to use
[01:11:59 CET] <xylc> I tried to remux a video and audio file, but for some reason, the source gave them a starting offset of 1000 (Duration: 00:16:40.09, start: 1000.158000), which cuts off most of the video. Is it possible to make ffmpeg use a starting offset of 0?
[01:12:46 CET] <xylc> Using mkvmerge results in a video that works fine (presumably because it ignores the starting offset), but I'm curious if it's possible to do this in ffmpeg as well
[01:35:29 CET] <xylc> I managed to do it in a slightly hacky way, "-ss 0 -seek_timestamp -2147483648.000000 -i ..."
[01:35:38 CET] <xylc> Not sure if there's any better way
[03:49:20 CET] <TAFB> how do I get minutes in hls_segment_filename?
[04:21:45 CET] <Rajko> is there any tutorial on how to use the h264 PARSER in ffmpeg ?
[04:22:39 CET] <Rajko> how would i get all the pps/sps parameters out, as well as enumerating pictures and slices inside them ?
[09:48:15 CET] <ayum> Hi, anyone know how to compile 32 bit ffmpeg executable on 64 bit linux?
[09:57:45 CET] <DHE> --extra-cflags=-m32 --extra-ldflags=-m32
[09:58:17 CET] <DHE> note that you may have issues due to library availability. if your system doesn't have parity between 64 bit and 32 bit libraries some features may be missing or building may fail
[10:09:02 CET] <illegal> Why did ffmpeg devs remove the auto detection of broken x264 files?
[10:18:10 CET] <ayum> @DHE, yes, add above flags is necessary, also I added --cc="gcc -m32" option
[10:18:32 CET] <ayum> otherwise, some object files still is 64 bit
[10:18:50 CET] <DHE> yeah I'm looking at my own system. looks like I missed --arch=i686
[10:19:05 CET] <DHE> otherwise nasm is building 64 bit assembly objects
[10:19:34 CET] <ayum> yes, I have to disable many libraries. I even disable h264 and h265 codec
[10:20:04 CET] <ayum> but it's okay, I only need a i386 version ffmpeg for test purpose. I can use rawvideo codec
[10:24:26 CET] <xylc> I would recommend checking arch linux PKGBUILDs https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=lib32-ffmpeg
[10:25:26 CET] <xylc> I found a lot of build troubles I had with various source packages were solved in some way in PKGBUILDs
[10:25:47 CET] <xylc> Including how to build 32 bit, or enable a certain option :)
[10:46:48 CET] <fx159159> Is my assumption correct that when I have a YUV picture where U and V are interleaved and U starts at 0xcc8e0001 and V at 0xcc8e0000 that the format is actually NV21?
[11:32:33 CET] <dradakovic_> i have another question regarding streaming into mpegts. I try to output the .avi file on udp but it ends almost instantly as it outputs at very high speed. It says speed x178
[11:32:40 CET] <dradakovic_> How can i normalize that
[11:33:16 CET] <DHE> add -re on the input
[11:33:31 CET] <DHE> also I'm guessing you got bitrate issues again
[11:34:03 CET] <dradakovic_> i dont even know how to solve my bitrate issues or what kind of issues i have anyway
[11:38:37 CET] <dradakovic_> I am trying to send audio stream from file now as i cannot solve the http radio stream.
[11:40:33 CET] <dradakovic_> @DHE would you mind telling me where i should put the -re option in my command
[11:40:35 CET] <dradakovic_> https://pastebin.com/zxMeMPpv
[11:40:43 CET] <dradakovic_> dont mind the comments in the command
[11:40:55 CET] <DHE> that looks fine...
[11:41:47 CET] <dradakovic_> But i get the: Option re (read input at native frame rate) cannot be applied to output url udp://232.50.50.2:5200?localaddr=172.20.188.170&pkt_size=188&fifo_size=1000000
[11:43:01 CET] <dradakovic_> you are trying to apply an input option to an output file or vice versa. Move this option before the file it belongs to.
[11:43:18 CET] <dradakovic_> So i don't have a clue where to put it
[11:44:10 CET] <DHE> so I have a problem with your command. you've \"escaped\" the quotes around your output URL which means that is literally the output filename, and "udp isn't a protocol
[11:44:16 CET] <DHE> so this command wouldn't work in the first place
[11:44:34 CET] <dradakovic_> ahhh yes
[11:44:36 CET] <dradakovic_> got it
[11:44:46 CET] <dradakovic_> thank you DHE
[11:45:11 CET] <DHE> ./ffmpeg -re -i test.ts -c copy -f mpegts -pkt_size 1316 -bitrate 9000k -muxrate 9000k udp://239.30.20.10:12345   # this is the command I am using. works great.
[11:46:16 CET] <dradakovic_> Got it, it works great. So now i know the problem. If i send the stream from the online http radio i get lost packets. If i send the stream from a file, everything is fine
[11:46:39 CET] <dradakovic_> Will build on that and maybe ask here again for advice. Thank you again
[11:50:15 CET] <dradakovic_> Hell yeah i sorted the issues up. Even with http streaming you need -re option. Oh man DHE i owe you a dinner
[11:50:24 CET] <dradakovic_> You solved an issue i had for days
[11:50:40 CET] <DHE> ... is the http file a live stream, or some pre-created mp4? that seems odd
[11:51:03 CET] <BtbN> If you want to output a live stream, you pretty much always need -re, if you are streaming from a static input
[11:51:10 CET] <BtbN> Otherwise it will go as fast as the CPU allows
[11:51:47 CET] <dradakovic_> Exactly
[11:52:01 CET] <DHE> yeah that's why I asked... the UDP -bitrate will throttle but the buffer size will easily overflow and ffmpeg fails
[11:56:07 CET] <DHE> but even with -re, I very strongly recommend using -muxrate and -bitrate
[14:23:29 CET] <ootje> anyone know if it is possible to tell by the ffproble --show_frames output if an mp4 has b-pyramid frames? (a method is described here, but it refers to nal_ref_idc which is not in the -show_frames output, http://www.ramugedia.com/hierarchical-b-frames-or-b-pyramid)
[15:03:28 CET] <DHE> ootje: you can dump the timestamps of individual video frames and observe the pattern of the PTS values
[15:04:07 CET] <ootje> DHE: i tried doing that, but it seems as if --show_frames show dts=pts and a steady increase.. --show_packets however shows dts!=pts
[15:26:55 CET] <ootje> (seems -show_frames sorts the frames by order, ordering by pkt_pos brings back the original I guess)
[15:42:52 CET] <DHE> yeah, show packets will be what you want...
[15:43:49 CET] <DHE> or is it... because this might be easier with frames so you can see pict_type=B
[15:45:47 CET] <DHE> nope..
[15:47:54 CET] <ootje> i did -show_packets and -show_frames and matched them with  pkt_pos and pos ;)
[15:48:10 CET] <DHE> so basically what you need to do is classify frames as either B or not-B. next for each group of B frames see if the PTS values are ascending/sequential or jumbled
[15:48:31 CET] <DHE> this is where it would have been nice if show_frames gave you that information or if you would have to either infer it or cross-reference it
[15:48:35 CET] <ootje> yes, will try that now..
[15:49:51 CET] <DHE> eg: with 8 b-frames in a row, the I,P,Bx8 pattern should have relative timestamps like 1, 10, 2,3,4,5,6,7,8. With b-pyramid it might be 1,10,4,2,6,7,5,3,9,8
[15:50:16 CET] <DHE> ... forgot '9' in the first pattern. bu you get the idea
[15:52:22 CET] <ootje> the funny thing is there are no consequtive B frames in this file, IPPBPPBPPBPBPBPBPPB etc, so I guess that rules it out?
[15:52:54 CET] <DHE> if bframes=1 then the setting is irrelevant
[16:01:28 CET] <ootje> am i supposed to use the order output by -show_packets or -show_frames to evaluate this?
[16:03:22 CET] <ootje> i was expecting to use the packet position in the file, as that probably reflects the stream order
[16:06:17 CET] <DHE> I guess step 1 is to run show_frames to find consecutive frames with pict_type=B. note the pts timestamps. step 2: find the dts values from the packets. the pts values are your cross-reference fields
[16:06:32 CET] <ootje> this is the output of my test script anyway, https://imgur.com/a/0pXwE
[16:07:00 CET] <DHE> there is another possibility. if the encoder was x264, there's a good chance you can just run "strings" on the input file and search for x264 and see if it just tells you what the encoder settings were.
[16:07:09 CET] <ootje> don't really see any consequtive B's any way, so i guess there's something else that's the issue here ( AE has an issue importing mp4s with B-pyramids, apparently )
[16:07:43 CET] <ootje> ..and it is resolved by disabling it when encoding the mp4s - otherwise suddenly there's a frame or two missing
[16:08:28 CET] <ootje> (was just trying to write a preprocessor to check if i could tell if the file would be troublesome, or if i have to transcode to eg huffyuv, which i'd like to skip if i don't need to)
[18:07:52 CET] <oerg866> Quick question, say i have two files that have the top and bottom fields of an interlaced video, how would i turn that back into a single interlaced video file?
[18:13:16 CET] <durandal_1707> oerg866: ffmpeg -i top -i bottom -filter-complex interleave,weave output
[18:13:24 CET] <oerg866> sick, thanks man
[18:15:44 CET] <kepstin> in the case that doesn't work, you might have timestamp issues, which could be worked around by using the -r input option or settb+setpts filters.
[18:16:30 CET] <oerg866> it's all gucci, working perfectly
[18:20:26 CET] <oerg866> https://i.snag.gy/2WaJUH.jpg
[18:20:36 CET] <oerg866> dunno if that's an ideal result but i'm pretty happy with that for now
[18:20:56 CET] <furq> what filters did you use for that
[18:21:35 CET] <oerg866> well first i split up the original interlaced video into two files for top and bottom fields and denoised those with hqdn3d
[18:22:46 CET] <oerg866> simply because deinterlacing first would make the speccles bigger than they would be and denoising the interlaced video would mess up the interlacing because the hqdn3d isn't line based
[18:23:36 CET] <oerg866> i still don't know if there's a line based blur filter / video low pass filter that i could apply here since the noise is so much higher bandwidth than the actual picture behind it :P
[19:04:38 CET] <delsol_> Is there a way to do an x11grab using less CPU? currently using:    ffmpeg -framerate 25 -video_size 1024x768 -f x11grab -i :0 -vcodec libx264 -crf 20 -preset ultrafast /video/12345.mkv
[19:06:11 CET] <delsol_> but where I've got like 5-7 going at once, (:0, :1, :2, :3, :4, :5, :6) I end up with both CPU cores being 85%+ loaded and performance starts becoming unacceptable.
[19:06:53 CET] <pzich> I don't think 7 x11grabs is ever going to be performant
[19:07:09 CET] <delsol_> changing -crf 20 to -crf 40 with 6 recording at once, changed overall load basically none.
[19:09:31 CET] <DHE> is that really where all the CPU time is going though? 7 instances of 25ps 1024x768 is going to use a lot of CPU power and RAM even at ultrafast presets
[19:09:38 CET] <delsol_> but if each one could use 20% less CPU than it does now, then that would help push performance issues further into the future, or reduce the effect of more clients.
[19:09:58 CET] <DHE> sounds like a job for perf (linux-specific tool)
[19:11:00 CET] <delsol_> DHE: seems to be where it all goes according to HTOP. although the ffmpeg sub-threads are niced at 10, and seem to calm down a bit and give up their slice of time to allow the machine to not total drag-ass...
[19:11:55 CET] <DHE> I suggested perf because it can help actually measure the amount of time going into the x11 code and the x264 code independently
[19:12:38 CET] <delsol_> ahhhh..... gotcha, so then I could possibly see how much is x11grab load, and how much is x264 load
[19:13:41 CET] <kepstin> delsol_: honestly, you probably have a pretty good use case for getting a quadro card so you can do hardware encoding.
[19:13:58 CET] <kepstin> a single modern card should be able to encode all those streams at once.
[19:14:37 CET] <JEEB> but does that help with the x11grab :P
[19:14:48 CET] <kepstin> it wouldn't help if x11grab is the issue, yeah
[19:15:16 CET] <kepstin> wait, "both CPU cores"... you're trying to do that many video streams on a dual-core box? what kind of cpu?
[19:15:20 CET] <DHE> even without a quadro, you can do 2 instances on any (?) GeForce GTX 680 or higher. can confirm a 770 and 1060 both support it
[19:15:43 CET] <DHE> oh... I didn't even notice he said that... oh god. yeah ultrafast is no miracle worker
[19:16:14 CET] <JEEB> not to mention x11grab being a semi-unknown as well.
[19:16:44 CET] <delsol_> kepstin: G3258 @3.2
[19:17:09 CET] <kepstin> delsol_: well, there's your problem
[19:17:19 CET] <mampf> Hello =) I need some help. I try to compile ffmpeg 3.2 with only decoder h264_vdpau. But when I play with the options I only get no h264 decoder or h264 and h264_vdpau     https://pastebin.com/nQ7S13b5
[19:17:53 CET] <kepstin> you simply don't have enough processing power to do the thing you seem to want to do. Can fix that by adding a hardware encoder or more cpu, which would help more is hard to determine.
[19:17:53 CET] <JEEB> seven screen recordings on a haswell pentium (celeron) <3
[19:18:02 CET] <delsol_> kepstin: I've got more than 50 locations. moving to 50 i7's isn't exactly cheap. :)
[19:18:40 CET] <delsol_> and most locations won't be doing more than 2 on the main machine... with the other encodings done on client machines and dumped into NFS share
[19:18:41 CET] <DHE> mampf: sorry, the pure software h264 decoder is still a dependency of the vdpau decoder
[19:18:41 CET] <kepstin> hmm. that haswell chip has quick sync, so that should help a bit
[19:19:10 CET] <JEEB> kepstin: that kind of recommendation is always fun because then you end up with something else being the bottleneck and what do you say then? please recommend that stuff after it's been checked which parts are actually the bottlenecks in the end (f.ex. can he even handle 7 x11grabs :P)
[19:19:10 CET] <kepstin> use it via the vaapi interface on linux, and it'll help a little :/
[19:19:40 CET] <delsol_> kepstin: Tried getting vaapi working, doesn't seem to work.
[19:19:48 CET] <JEEB> after it's been checked that 7 x11grabs work, then you can start recommending things
[19:20:13 CET] <mampf> Thanks! Is it possible to change the default decoder? I try to run Ultrastar a Singstar game on an orange pi. And Ultrastar choose the default decoder
[19:20:19 CET] <mampf> from ffmpeg
[19:20:35 CET] <delsol_> JEEB: I was doing 7 yesterday. Worked fine other than performance of the app being grabbed started turning to crap anytime something CPU intensive happened.
[19:20:56 CET] <kepstin> delsol_: if you don't want to bother with the perf tool, you can check the x11grab performance separate from video encoding by just doing something like "ffmpeg -f x11grab -i :0 -f null -" a bunch of times and see your fps.
[19:21:14 CET] <kepstin> using whatever x11grab options you'd be using otherwise
[19:21:29 CET] <JEEB> yea, that way you'd check if whatever encoder you'd be using would be having the problems
[19:21:45 CET] <delsol_> aha! grab framebuffer, dump to /dev/null without encoding
[19:21:50 CET] <delsol_> good idea.
[19:22:08 CET] <kepstin> that would check if the fb grab vs. video encoding is where perf problems are coming in, yeah.
[19:22:33 CET] <JEEB> mampf: no, but if the API client has requirements you can always request another encoder, although hwaccels are somewhat special. also if that board has a mmal decoder it's shit but might work :P
[19:22:52 CET] <JEEB> of course the mmal crap generally tends to want the whole screen with a measly overlay to itself
[19:23:32 CET] <JEEB> (also I have no idea if the "orange pi" has anything to do with the raspberry pi boards but these comments assumed they have)
[19:23:41 CET] <mampf> No it doesn't have mmal. OK I try to find a person which can develop this :D
[19:24:15 CET] <mampf> It's a cheaper version than the raspberry pi or a faster :D
[19:24:15 CET] <JEEB> ok, then you're fscked unless the hw decoding drivers offer some common and usable-from-FFmpeg interface
[19:24:23 CET] <JEEB> welcome to ARM world
[19:24:31 CET] <JEEB> everything sucks and sticks things that hurt into you
[19:25:02 CET] <JEEB> android's mediacodec kind of got better after google started doing integration testing as requirements for passing their tests
[19:25:22 CET] <mampf> it has h264_vdpau and runs 1080p in mpv player without any problems, but I need the same with ffmpeg :D
[19:25:25 CET] <JEEB> before then HW accelerated decoding was the wild west, I think until 5 or so
[19:25:34 CET] <mampf> Thank you very much for you help!
[19:25:36 CET] <JEEB> mampf: huh, it has vdpau?
[19:25:36 CET] <JEEB> wtf
[19:25:46 CET] <JEEB> that's surprisingly sane if the drivers work
[19:26:18 CET] <JEEB> mampf: but yes, someone will have to develop the app to make use of hwaccel decoding, which has some specialities that differ from sw decoding as you have to initialize the device contexts etc
[19:26:20 CET] <mampf> It should decode 4k but I think there isn't an working driver idk. But it's advertised that it can run 4k :D
[19:26:24 CET] <JEEB> but there are examples for that
[19:26:35 CET] <JEEB> well yes of course they advertise everything the ASIC can do
[19:26:40 CET] <JEEB> uhh
[19:26:49 CET] <JEEB> how can it run h264_vdpau with mpv if it doesn't have a driver?!
[19:26:51 CET] <mampf> yes that would be nice. It's made in pascal and I can't cde that :D
[19:27:11 CET] <mampf> It has a 1080p driver I think but not a 4k
[19:27:14 CET] <kepstin> mampf: see the caveats about vdpau at https://trac.ffmpeg.org/wiki/HWAccelIntro#VDPAU
[19:27:35 CET] <kepstin> it's a presentation api for rendering to screen, if that's what you want great, but it's not a general decoding api.
[19:27:48 CET] <JEEB> I think you could get the YCbCr from it?
[19:27:56 CET] <JEEB> since mpv separates the decoding and the rendering
[19:28:07 CET] <JEEB> also mpv utilizes FFmpeg's hwaccels for the decoding so then you just need your API client to utilize the hwaccel mampf
[19:28:43 CET] <mampf> Yes I think the App just need to select hwaccel.
[19:28:53 CET] <kepstin> hmm, i guess some gpus allow frame copy back from vdpau.
[19:28:54 CET] <mampf> Thank you very much ;)
[19:28:55 CET] <JEEB> yes, your app is an API client as far as FFmpeg is concerned
[19:29:17 CET] <JEEB> kepstin: it seems like you can generally get YCbCr out of the VDPAU *decoder* as long as you don't enable deint or vdpau post-processing
[19:29:40 CET] <JEEB> scroll down @ https://mpv.io/manual/master/#options-hwdec
[19:29:50 CET] <JEEB> it has the possible downsides of various hwaccels there
[19:30:40 CET] <mampf> Yes I think the only problem is that Ultrastar must select hwaccel
[19:31:07 CET] <mampf> So if you nothing to do and you can write pascal fix this please :DD
[19:31:08 CET] <mampf> https://github.com/UltraStar-Deluxe/USDX/tree/master/src/lib/ffmpeg-3.2
[19:57:42 CET] <jfmcarreira> heyyy guys
[19:57:55 CET] <jfmcarreira> how can i get the number of frame in stream like .264 and .265
[19:58:40 CET] <JEEB> lavf doesn't handle that for you, you have to index it
[19:58:47 CET] <JEEB> or lavc for that matter
[19:59:02 CET] <JEEB> you can use something like ffms2 to get frame-exact access
[19:59:11 CET] <JEEB> because it uses lavf to index the whole input
[20:52:02 CET] <Timmey> Does anyone know what pgk I need for .srt encoder? My mac has it standard, but my raspberry2 (raspbian) is missing it.
[21:01:12 CET] <BtbN> ffmpeg/libavcodec
[21:25:13 CET] <SortaCore> Timmey: did you see btb's reply
[21:31:18 CET] <Timmey> Yeah, so libavcodec should always be in standard right.. no need for extra flags?
[21:31:55 CET] <Timmey> I just finished a new build instead of the apt-get pkg, so i'm gonna try it now.
[21:35:05 CET] <BtbN> Possible that Debian removed it, because reasons
[21:44:32 CET] <Timmey> @BtbN a manual install of added the srt encoder :) so it's working now!
[21:45:23 CET] <Timmey> of ffmpeg*
[22:23:34 CET] <therage3> for the native Native FFmpeg AAC Encoder, is there any recommended quality setting for audible transparency?
[22:24:43 CET] <another> i think the wiki says >=128k
[22:25:33 CET] <another> https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio
[22:26:39 CET] <therage3> another: thing is, that 128 figure is for Fraunhofer FDK AAC
[22:26:58 CET] <therage3> that is specifically why I asked about the native encoder
[22:27:27 CET] <klaxa> >aac  usable range e 32Kbps (depending on profile and audio). Recommended range e 128Kbps
[22:28:13 CET] <therage3> but is that true for the native encoder as well? because the 128 figure is there in https://trac.ffmpeg.org/wiki/Encode/AAC for the Fraunhofer encoder
[22:28:43 CET] <klaxa> the line i pasted is specifically for the native encoder
[22:29:02 CET] <klaxa> that page as well has a section about the native aac encoder
[22:29:21 CET] <therage3> so they have the same recommended range?
[22:29:27 CET] <therage3> huh, i was told the Fraunhofer one was better. weird
[22:29:37 CET] <klaxa> it is
[22:29:40 CET] <therage3> ...
[22:29:47 CET] <klaxa> >Which encoder provides the best quality?
[22:29:47 CET] <klaxa> >For AAC-LC: libfdk_aac > Native FFmpeg AAC encoder (aac).
[22:29:51 CET] <klaxa> also on that page
[22:30:37 CET] <therage3> indeed
[22:30:48 CET] <therage3> so the same recommended range seems a bit odd to me, i dunno
[22:30:59 CET] <klaxa> recommended does not mean it has the same quality at the same bitrate
[22:31:15 CET] <therage3> i see, i guess it'll have a similar audible transparency then?
[22:31:48 CET] <klaxa> tbh, i don't know you'd have to test that, maybe there are test series around where someone tested it
[22:31:52 CET] <furq> there's not really any consensus because no proper listening tests have been done
[22:31:59 CET] <therage3> furq: i figured
[22:32:16 CET] <therage3> you know, i'm going to test this out myself in a bit
[22:32:17 CET] <furq> i would probably go above 128k for cbr
[22:32:29 CET] <furq> and i don't know if the builtin encoder has a usable vbr mode yet
[22:32:41 CET] <therage3> the Wiki says it's experimental
[22:32:48 CET] <therage3> and likely to get worse results than CBR
[22:32:58 CET] <klaxa> >Note: -strict experimental (or -strict -2) was previously required for this encoder, but it is no longer experimental and these options are unnecessary since 5 December 2015.
[22:33:02 CET] <furq> the wiki isn't always very up to date though
[22:33:06 CET] <klaxa> >no longer experimental
[22:33:08 CET] <BtbN> it's not experimental anymore for a while now
[22:33:10 CET] <furq> he means vbr mode
[22:33:10 CET] <ChocolateArmpits> native encoder performs quite bad at low bitrates and produces nasty artifacts, libfdk is far better if you intend to encode 64kbitps or lower audio
[22:33:17 CET] <klaxa> oh
[22:33:29 CET] <BtbN> You don't want to use AAC-LC for those low bitrates anyay
[22:33:31 CET] <therage3> "Effective range for -q:a is around 0.1-2. This VBR is experimental and likely to get even worse results than the CBR."
[22:33:33 CET] <BtbN> That's what HE-AAC exists for
[22:33:34 CET] <klaxa> nvm then
[22:33:37 CET] <therage3> I was talking about this :P
[22:33:41 CET] <furq> yeah that was the last i heard
[22:33:51 CET] <therage3> i see
[22:33:52 CET] <JEEB> you should poke atomnuker regarding the "VBR" mode
[22:33:52 CET] <furq> also some nice incomprehensible -q mapping there
[22:34:04 CET] <ChocolateArmpits> BtbN, 32kbps-48kbps is acceptable for speech really
[22:34:08 CET] <furq> for the first time ever
[22:34:11 CET] <therage3> well, I understand it as 0.1 all the to 2, with 0.1 increments
[22:34:16 CET] <therage3> I don't know if that's the intended meaning
[22:34:19 CET] <BtbN> With AAC-LC? I'd rather use HE
[22:34:41 CET] <furq> i just use fdk -vbr 5 anyway
[22:34:49 CET] <klaxa> nowadays i just encode evertyhing in opus anyway
[22:35:09 CET] <iranen> yes opus is best
[22:35:20 CET] <ChocolateArmpits> well LC has higher compatibility
[22:35:24 CET] <furq> yeah if you can do that then that's much simpler
[22:36:11 CET] <furq> that page should probably be updated to include the audiotoolbox encoders on osx
[22:38:45 CET] <alexpigment> furq: does ffmpeg take advantage of audiotoolbox?
[22:38:54 CET] <alexpigment> (and videotoolbox for that matter)
[22:39:00 CET] <alexpigment> ?
[22:39:40 CET] <JEEB> it has some hwaccels for that IIRC
[22:39:45 CET] <JEEB> &45
[22:40:16 CET] <alexpigment> interesting. i'll have to look into that at some point
[22:40:27 CET] <BtbN> hwaccel for audio is hardly worth it
[22:40:43 CET] <JEEB> VT was mostly what I was talking about
[22:41:08 CET] <alexpigment> yeah, i was hoping audiotoolbox support meant that there was also videotoolbox support
[22:41:13 CET] <alexpigment> which is obviously much more important
[22:41:25 CET] <alexpigment> although an OS-level aac encoder is not a bad thing to have around
[22:41:43 CET] <kepstin> even if it's not accelerated, using the system/quicktime aac encoder on a mac is probably a good idea, it's def. one of the better aac encoders around.
[22:41:48 CET] <furq> yeah it's itunes aac on osx afaik
[22:41:52 CET] <furq> which is the best aac encoder
[22:42:06 CET] <furq> and it doesn't require a nonfree build
[22:42:16 CET] <alexpigment> yep
[22:50:34 CET] <alexpigment> speaking of hwaccel stuff
[22:51:03 CET] <alexpigment> i get the feeling from the mailing list that the AMD VCE/AMF integration is at a standstill because of the header integration
[22:51:36 CET] <alexpigment> does anyone know if there's more movement behind the scenes, or is it just the same status as the last message from friday?
[22:52:47 CET] <jkqxz> Is was merged a week ago.
[22:58:33 CET] <alexpigment> jkqxz: but that requires external headers still?
[22:59:10 CET] <delsol> how do I make null output again to determine performance of x11grab vs performance of encoding?
[22:59:15 CET] <alexpigment> i tried figuring out how to integrate that into the build script i was using but ultimately my lack of knowledge and/or lack of flexibility with the build script prevented me from geting anywhere
[22:59:19 CET] <jkqxz> alexpigment:  Just like every other package every.
[23:00:27 CET] <jkqxz> s/every\./ever./
[23:00:32 CET] <alexpigment> jkqxz: just checked the new version of the build script and it looks like it's already in there
[23:00:38 CET] <alexpigment> so nm then ;)
[23:00:39 CET] <alexpigment> thanks
[23:10:49 CET] <SortaCore> ah, x264 guys got back to me
[23:11:22 CET] <SortaCore> "give more details about how you will sell this, and here's an NDA so you can never say about our little arrangement"
[23:12:11 CET] Action: JEEB wonders if it's still corecodec or is it videolan handling it now
[23:12:20 CET] <SortaCore> corecodec
[23:13:18 CET] <SortaCore> I see in the forms they sent me, they didn't bother to fill in the parts that my email said already
[23:13:30 CET] <JEEB> oh well
[23:14:06 CET] <JEEB> and I wonder what the NDA is for, other than "we want to price each customer 100% separately"
[23:14:21 CET] <SortaCore> possibly that
[23:14:30 CET] <SortaCore> but it seems to be "every detail is NDA don't breathe a word"
[23:14:47 CET] <JEEB> that's how NDAs are esp. in the US it seems
[23:15:44 CET] <JEEB> where I work there's general law that if you hurt a company by speaking about internal stuff that doesn't need additional stuff. generally a "gentleman's agreement" or so
[23:15:53 CET] <SortaCore> https://pastebin.com/raw/t3BT83rT
[23:16:03 CET] <SortaCore> mm, I prefer that idea
[23:16:14 CET] <JEEB> but then you get foreign corps buying companies they tend to try and stick NDAs
[23:16:24 CET] <SortaCore> they could just have pricing and how the codecs work internally be NDA
[23:16:36 CET] <SortaCore> seems a lot less suspicious than everything
[23:16:37 CET] <JEEB> well the code workings are OSS anyways
[23:16:51 CET] <JEEB> since what you get as far as I can tell is the same thing, just under a diff license
[23:17:04 CET] <JEEB> + IIRC if you make changes to the core you have to give them back to the LLC
[23:17:14 CET] <JEEB> and then the LLC will decide whether to incorporate them or not
[23:17:36 CET] <JEEB> there were some people making MVC etc patches, but those were decided that to hone them up would require E_TOO_MUCH_EFFORT
[23:17:51 CET] <JEEB> but the pastebins are still out there
[23:18:41 CET] <JEEB> SortaCore: looks like standardo US lawyerisms
[23:18:52 CET] <SortaCore> yea, that's my take too
[23:19:01 CET] <SortaCore> not that I have much experience with licensing
[23:19:21 CET] <JEEB> this is just the "business people got into the loop" kind of stuff
[23:19:26 CET] <JEEB> IANAL though
[23:19:50 CET] <SortaCore> whenever I'm presented with legal absolutely-no-two-ways-to-read-this-no-common-sense-required text, my brain just gives up and sums it to maximum possible
[23:47:29 CET] <SortaCore> Intel Corp: "We would appreciate your response by: 12/15/2017"
[23:47:41 CET] <SortaCore> that's not a real date
[23:47:53 CET] <alexpigment> in the US it is
[23:47:57 CET] <SortaCore> sounds like Trump mischief
[23:48:02 CET] <alexpigment> MM/DD/YYYY
[23:48:11 CET] <SortaCore> why would you order dates like that?
[23:48:22 CET] <alexpigment> all standards are wrong tbh
[23:48:30 CET] <alexpigment> it should be YYYY/MM/DD
[23:48:37 CET] <alexpigment> and yet no one does that
[23:49:10 CET] <SortaCore> yyyy:mm:dd:hh:mm:ss:ms:ns
[23:49:19 CET] <alexpigment> sure
[23:49:32 CET] <alexpigment> basically a format that can be sorted in a file system alphanumerically
[23:49:47 CET] <SortaCore> don't file systems have date fields
[23:49:56 CET] <SortaCore> which are internally binary
[23:50:02 CET] <SortaCore> instead of textuals
[23:50:48 CET] <alexpigment> here's what i'm saying: if you name a file MM-DD-YYYY.file or DD-MM-YYYY.file, neither will be in order over time
[23:51:08 CET] <alexpigment> at least the current US standard works within a given year (but fails the next year)
[23:51:18 CET] <alexpigment> the european standard fails every single month
[23:51:27 CET] <alexpigment> YYYY-MM-DD is the only format that doesn't fail
[23:52:06 CET] <SortaCore> sort(f => reverse(f.filename));
[23:52:15 CET] <SortaCore> 100% no problems
[23:52:40 CET] <alexpigment> SortaCore: are you actually defending DD/MM/YYYY ?
[23:52:49 CET] <alexpigment> i'm not sure if that's what you're doing
[23:52:52 CET] <SortaCore> I'm vaguely obligated as I'm British
[23:53:10 CET] <alexpigment> well i'm american and humble enough to know we're both wrong
[23:53:10 CET] <SortaCore> we'll defend our ways to the death, but complain the whole time we use them
[23:53:33 CET] <SortaCore> don't bring humility magic into this
[23:53:45 CET] <alexpigment> fair enough ;)
[23:54:01 CET] <SortaCore> it's something as soon as you say you have it, you don't have it
[23:54:13 CET] <SortaCore> I mean, my humility is totally outmatched
[23:54:26 CET] <furq> most of east asia uses YMD
[23:54:28 CET] <SortaCore> no one can stand up to the sheer amount of humility I weild
[23:54:43 CET] <SortaCore> (server dies and interrupt speech)
[23:54:59 CET] <SortaCore> why do I have the one-character-must-be-typoed bug now?
[23:55:04 CET] <furq> you're not as humble as me
[23:55:12 CET] <furq> i am the most humble person who has ever lived
[23:55:17 CET] <SortaCore> I could talk about my humility all day
[23:55:26 CET] <SortaCore> and still not describe even a sliver of it
[23:55:42 CET] <SortaCore> also, did today seem slow to you guys?
[23:55:50 CET] <SortaCore> (bit off topic)
[23:56:11 CET] <alexpigment> furq: good to know that east asia took the logical approach
[23:57:02 CET] <alexpigment> SortaCore: actually yes. although I went through 210+ windows updates on a VM, so that kinda added to the slowness
[23:58:40 CET] <SortaCore> I think we're in a temporal distortion, I'm getting reports from around the world about today feeling slow
[00:00:00 CET] --- Thu Dec  7 2017