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

[burek]

[00:28:23 CEST] <SolarAquarion> for some reason video isn't playing for the videos
[00:28:24 CEST] <SolarAquarion> only the audio
[00:28:29 CEST] <SolarAquarion> only gstreamer based players work, not ffmpeg based players
[00:28:49 CEST] <SolarAquarion> Only ffmpeg2.8 is working fine
[00:28:53 CEST] <SolarAquarion> weird
[02:38:04 CEST] <stapler> hi, is it possible to have a muxer write to a buffer in memory instead of a file?
[03:14:22 CEST] <klaxa> stapler: see the custom io example maybe? https://www.ffmpeg.org/doxygen/trunk/avio_reading_8c-example.html
[03:14:26 CEST] <klaxa> that does exactly that
[03:14:33 CEST] <klaxa> except for reading
[03:14:45 CEST] <stapler> oh, thank you
[03:14:49 CEST] <klaxa> you'll have to write it for writing instead, it works basically the same though
[09:09:57 CEST] <manjaro-kde5_> Good morning, anyone here?
[09:11:21 CEST] <manjaro-kde5_> I'm using a blackmagic decklink card as an video input and want to place that output with ffplay on my screen on a certain spot.
[09:12:53 CEST] <manjaro-kde5_> I found that you can make a borderless window with "-noborders" and being able to set the resolution with the "-x" and "-y" switches, but how can I place the video somewhere like 50 pixels from top right on the screen without moving it by hand?
[09:13:24 CEST] <manjaro-kde5_> Do I have to use any special filters to achive that?
[11:55:52 CEST] <thebombzen> I have /usr/local/lib added to my ld.so.conf so /usr/local/bin/ffmpeg can find it
[11:56:26 CEST] <thebombzen> unfortunately this makes it so /usr/bin/ffmpeg (installed from the package manager) also see these and the library mismatch makes it useless without LD_PRELOAD
[11:56:53 CEST] <thebombzen> is there an easy way to make /usr/bin/ffmpeg point to /usr/lib/libav* other than adding a custom post-install hook to do that?
[12:55:51 CEST] <the_k> would it be possible to scan for a specific colour range in an incoming video stream?
[12:56:32 CEST] <the_k> i.e. a security camera overwatching a front door - when a guy with a specific colour jacket (postman/deliveryman) comes into the scene, it could trigger something
[13:01:02 CEST] <Bear10> Hello, does anyone know how to have an overlay of an image that you can change dynamically? Or if maybe someone knows of a way to achieve this via another means maybe something like writing to a mjpeg from another process or something?
[13:04:10 CEST] <Nacht> Bear10, define 'Dynamically'. Using FFMPEG to add an overlay will just recode the entire clip, thus the 'overlay' pixels become part of the movie itself.
[13:04:12 CEST] <sine0> I have converted some cctv video to libx264 for my boss but he cant play it on his default computer, what is the best, low filesize compression type to give to people ?
[13:04:29 CEST] <sine0> will play in windows media player etc
[13:04:37 CEST] <Bear10> Nacht: well I'm working on live streams and so I want to be able to add an image in, then take it out etc as I'm streaming live
[13:05:08 CEST] <Nacht> Bar10, you mean like OBS does ?
[13:05:12 CEST] <Bear10> Nacht: exactly
[13:06:14 CEST] <Nacht> Bear10, then the obvious question comes, why not use OBS ?
[13:06:52 CEST] <Bear10> Nacht: because we're developing a platform that's very specific to our users, can't have them installing software on their pcs or anything as advanced as OBS
[13:09:23 CEST] <Nacht> afaik, FFMPEG will take the image used for overlay and store it in memory the first time, so changing the image during the stream won't do much, as ffmpeg already has the intial one and will ignore it.
[13:10:20 CEST] <Bear10> yeah that's what I imagined
[13:10:40 CEST] <Nacht> It will prolly require custom coding, which uses the same processes as FFMPEG does when using overlay, only with constant refreshing before encoding the frames
[13:11:17 CEST] <Nacht> So bascily, a sort of 'OBS lite'
[13:12:12 CEST] <Bear10> Exactly, I thought maybe there'd be a way for me to use let's say 2 video streams and have one be an mjpeg, write to it and see if it would keep streaming
[13:12:22 CEST] <Bear10> but it didn't seem very efficient (haven't tested the hypothesis either)
[13:13:11 CEST] <Nacht> There are ways with clients as well, so you put the overlay on the client side. But that would really depend on your use-case
[13:15:54 CEST] <Bear10> yeah hmm
[13:15:59 CEST] <Bear10> do you have any suggestions regarding the custom coding
[13:16:22 CEST] <Bear10> if i should be looking at ffmpeg github and modifying the CLI tool or seeing if i can somehow incorporate it into a new C app/tool or something?
[13:20:08 CEST] <Nacht> Not much I can say about that. However, I've seen quite a few people mentioning using the AV library's of FFMPEG to use in their codes. There's something about it in the FAQ:
[13:20:08 CEST] <Nacht> http://ffmpeg.org/faq.html#Are-there-examples-illustrating-how-to-use-the-FFmpeg-libraries_002c-particularly-libavcodec-and-libavformat_003f
[13:22:32 CEST] <Bear10> awesome thank you Nacht
[13:49:13 CEST] <manjaro-kde5_> Hi there
[13:49:36 CEST] <manjaro-kde5_> I'm using a blackmagic decklink card as a video input and want to place that output with ffplay on my screen on a certain spot. I found that you can make a borderless window with "-noborders" and being able to set the size of that window with the "-x" and "-y" switches, but how can I place the video somewhere like 50 pixels from top right on the screen without moving it by hand? Do I have to use any special filters to achive that?
[13:50:51 CEST] <SolarAquarion> I have a weird issue with the playing of videos that isn't in ffmpeg2.8 version.  Like Videos have a framerate of 0, IE they don't play at all but the videos do
[13:51:07 CEST] <SolarAquarion> i mean the audio
[13:57:20 CEST] <elmarikon> does it help to set the framerate manually?
[13:57:28 CEST] <elmarikon> ex. -r 25
[13:58:10 CEST] <Nacht> manjaro-kde5_>: So you want to position the window ? Windows or Linux ?
[13:59:15 CEST] <manjaro-kde5_> Win
[13:59:30 CEST] <Nacht> You'll need something like this for that:
[13:59:31 CEST] <Nacht> https://ritchielawrence.github.io/cmdow/
[13:59:31 CEST] <elmarikon> manjaro-kde5_ maybe u can use -vf pad=640:480:0:40
[13:59:36 CEST] <elmarikon> sth. like that...
[14:00:06 CEST] <manjaro-kde5_> Thanks a lot
[14:00:44 CEST] <manjaro-kde5_> Thought there is an option to place it bei doing something linke -resolution 1024x786+50+50
[14:01:13 CEST] <Nacht> It's not really the video itself you want to manipulate, but the ffplay window itself
[14:03:18 CEST] <Nacht> if you would do something like  '1024x786+50+50' you would only end up with a bigger video, but the position of the window wouldnt really change much. You'd just end up with a weirdly sized video
[14:32:22 CEST] <manjaro-kde5_> Yes, thats what I found out already...
[14:32:37 CEST] <manjaro-kde5_> Thanks anyway, Nacht...
[14:39:30 CEST] <momomo> i am testing to feed youtube live a livestream
[14:40:29 CEST] <momomo> what is the best way to minimize cpu usage on the ffmpeg running server ? raw serving .. is that possible ... i'd like to do really through tvheadend .. but I don't think youtube can make the request, but I have to connect to youtube
[14:49:01 CEST] <Nacht> momomo: Youtube's required live encoder settings: https://support.google.com/youtube/answer/2853702?hl=en&ref_topic=6136989
[14:52:22 CEST] <momomo> Nacht: i want to try to feed it raw from tvheadend
[14:52:32 CEST] <momomo> that page suggest formatting it
[14:52:46 CEST] <Nacht> as well as feeding them RTMP
[14:52:51 CEST] <oerg866> hello again
[14:53:25 CEST] <oerg866> i'm archiving a couple of very old VHS tapes and a few of them were recorded with really bad reception... what's the best method for denoising these with ffmpeg
[14:53:34 CEST] <oerg866> the files are lossless avi files (lagarith)
[14:54:29 CEST] <oerg866> http://img.ctrlv.in/img/17/08/02/5981cb6333976.png <-- this is the kind of noise level we're talking about here
[14:55:12 CEST] <momomo> Nacht: so the command would be? I have these variabnts as of now:
[14:55:13 CEST] <momomo> https://hastebin.com/ikiyuxozig.m
[15:01:13 CEST] <Nacht> momomo: The 2nd one looks valid enough. I'm not sure what kind of stream tvheadend gives off ? Is it already in H.264/AAC/MP3 ? Cause if so, you could just copy and have hardly any CPU usage
[15:01:35 CEST] <Nacht> momomo: input would be something like 'http://ip.of.tvheadend.streamer:9981/stream/channelid/number_of_channel' ?
[15:01:48 CEST] <Nacht> I'm not really familiar with tvheadend
[15:13:34 CEST] <momomo> yes
[15:54:33 CEST] <elmarikon> oerg866: looks like removegrain could help, sice thios is more gran then noise...
[15:55:01 CEST] <elmarikon> -o
[15:55:50 CEST] <guikos> Hi, i'm trying to transcode an h264 HD1080p 29,97fps video into DVCPRO25 without too much stutter and without loosing audio sync. Any ideas?
[16:32:01 CEST] <elmarikon> you could use the filter "fps"...
[16:32:03 CEST] <elmarikon> http://ffmpeg.org/ffmpeg-filters.html#fps-1
[16:32:16 CEST] <elmarikon> But I do not know how good it looks...
[16:32:59 CEST] <elmarikon> or drop to 23.976 and the speed up to 25 again... that's how it is done very often...
[16:33:45 CEST] <guikos> @elmarikon Thanks, I'll try that
[16:48:25 CEST] <djgl> Dropping to 23.976 fps only works for videos that were sped up from 23.976 to 29.97 before
[16:57:58 CEST] <sikilikis> so I need help. I'm streaming 24/7 to youtube on my raspberry pi using ffmpeg. No matter what I do, I always seem to get disconnected from youtube with a generic "connection reset by peer" type of error
[16:58:25 CEST] <sikilikis> here's a pastebin with how I have ffmpeg configured, the ffmpeg command, and the errors I'm seeing with timestamps: https://pastebin.com/xGmBnwxM
[16:59:13 CEST] <sikilikis> I'm running ffmpeg in a loop so that when it gets disconnected it can hopefully reconnect and resume the stream, but sometimes it doesn't reconnect for like ten minutes. I've tried both using librtmp-dev and whatever the native ffmpeg rtmp lib is
[16:59:27 CEST] <sikilikis> both are giving me generic disconnect errors and I can't figure out what is causing it
[17:00:42 CEST] <JodaZ> JASTON, you got any further with individual live segmenting?
[17:02:09 CEST] <sikilikis> sometimes it will stream for days without errors and sometimes it errors after an hour. Or minutes
[17:02:46 CEST] <JodaZ> sikilikis, can you send anything besides flv?
[17:03:01 CEST] <sikilikis> to youtube? don't think so
[17:03:24 CEST] <JodaZ> sikilikis, connection reset by peer could either be youtube shutting the connection or basically anything in between you and them (firewall, router, your isp etc etc)
[17:03:24 CEST] <sikilikis> and just for the record, it DOES work. It just randomly disconnects
[17:04:10 CEST] <sikilikis> What can I do to get more info? Because this has been an issue for me for months and I can't find anything about it
[17:05:21 CEST] <elmarikon> djgl: that's not true.
[17:17:04 CEST] <sikilikis> no ideas anyone?
[17:29:32 CEST] <djgl> elmarikon: yeah, you can try to run IVTC algorithms on material that never underwent TC, but it will look worse than picking 25 approximately equidistant frames per second from the 29.97 frames that are available.
[17:41:18 CEST] <cq1> Does anyone here know where I could find some lossless 2160p source for testing compression?
[17:41:37 CEST] <cq1> I only need enough to plausibly form a GOP or two at reasonable parameters (10 seconds is fine).
[18:05:37 CEST] <Aerroon> so i gather that ffmpeg is not allowed to be distributed in a fashion where it includes nvenc support?
[18:06:06 CEST] <Diag> Did somebody say GOP
[18:06:36 CEST] <Diag> also Aerroon graphics card encoding sucks
[18:06:46 CEST] <Aerroon> ehh
[18:06:49 CEST] <Aerroon> isn't it good enough?
[18:06:49 CEST] <Diag> you need like 10x the bitrate for a similar quality video
[18:06:50 CEST] <thebombzen> cq1: jellyfish.us
[18:06:59 CEST] <Diag> Its fast, yes
[18:07:02 CEST] <Aerroon> no i mean
[18:07:20 CEST] <thebombzen> cq1: err, http://jell.yfish.us/
[18:07:22 CEST] <Aerroon> ssim and psnr gave me similar results from nvenc on obs to x264 cbr
[18:07:25 CEST] <Aerroon> at same filesize
[18:07:33 CEST] <Diag> yes, CBR
[18:07:49 CEST] <Diag> hardly anyone uses cbr
[18:07:53 CEST] <Aerroon> but i'm not 100% certain that it was similar, because i can't guarantee that the frames are in sync unless i fully reencode
[18:07:57 CEST] <Diag> unless its for a standard
[18:07:57 CEST] <Aerroon> uh
[18:08:00 CEST] <Aerroon> well, i do
[18:08:04 CEST] <Aerroon> for streaming i do use cbr
[18:08:06 CEST] <DHE> Aerroon: GPU encoding is worse than software encoding in terms of quality, but it's very fast and low CPU impact
[18:08:07 CEST] <thebombzen> cq1: they're not lossless, but if you pick the ones with enormous bitrates it might be close enough
[18:08:13 CEST] <Aerroon> again
[18:08:21 CEST] <Aerroon> it gave a higher ssim and psnr result
[18:08:30 CEST] <Diag> Why not use the obs that supports nvenc?
[18:08:36 CEST] <Aerroon> i want to compare again, but this time i want to encode all the sources with ffmpeg so it's better to compare
[18:08:42 CEST] <Aerroon> i am going to use obs with it
[18:08:44 CEST] <Aerroon> i want to compare quality
[18:08:51 CEST] <Diag> Its like a completely different codec almost though
[18:08:52 CEST] <Aerroon> to make sure there are no wrong frame problems in comparisons
[18:09:06 CEST] <thebombzen> Aerroon: x264 vastly outperforms NVENC in quality per bitrate
[18:09:11 CEST] <Aerroon> oh boy
[18:09:16 CEST] <thebombzen> this is well-known
[18:09:16 CEST] <Aerroon> do i have to say this a third time again?
[18:09:29 CEST] <Aerroon> which part of "ssim and psnr gave me similar numbers" is so difficult to understand
[18:09:35 CEST] <Diag> Show us
[18:09:36 CEST] <thebombzen> did you use preset ultrafast?
[18:09:36 CEST] <Aerroon> so i want to test further
[18:09:48 CEST] <thebombzen> we're all very skeptical, because it's well-known that x264 is better than nvenc
[18:10:00 CEST] <Diag> Aerroon: set that shit to placebo and be amazed
[18:10:01 CEST] <Aerroon> https://docs.google.com/spreadsheets/d/1lkmYF2lphAxkdVWVy2qxgLR--88fDBTjbu4JsMF9UsI/edit#gid=0
[18:10:05 CEST] <thebombzen> the only way I can see this happening is if you used the ultrafast preset
[18:10:12 CEST] <Aerroon> these are the results
[18:10:14 CEST] <Aerroon> of ssim
[18:10:23 CEST] <Aerroon> but my question is not about this
[18:10:34 CEST] <Aerroon> it's about whether i need to compile ffmpeg myself if i want nvenc support
[18:10:34 CEST] <thebombzen> out of curiosity, did you use --tune ssim?
[18:10:41 CEST] <Aerroon> no
[18:10:45 CEST] <thebombzen> well there you go
[18:10:58 CEST] <thebombzen> x264 optimizes for humans, not SSIM. Unless you disable that and use --tune ssim
[18:11:55 CEST] <thebombzen> Also, your spreadsheet disagrees with you. x264 beats NVENC
[18:12:10 CEST] <Aerroon> https://pastebin.com/Y2PxtXCy
[18:12:15 CEST] <Aerroon> this is what i got
[18:12:19 CEST] <Aerroon> yeah
[18:12:23 CEST] <Aerroon> x264 beats nvenc
[18:12:32 CEST] <Aerroon> at settings my cpu can't actually encode at
[18:12:34 CEST] <Diag> As far as AMDs first gen gpu encoding goes, i have to encode at 35mbps at 60fps to get the same quality as a tiny ass x264 encoded file
[18:12:50 CEST] <Aerroon> and i'm not here to argue about this
[18:12:52 CEST] <thebombzen> Aerroon: well what did you expect would happen if you turned x264's settings down so you can encode it in realtime
[18:12:52 CEST] <Aerroon> i want to test this
[18:13:00 CEST] <Diag> lol
[18:13:03 CEST] <Aerroon> let's see
[18:13:12 CEST] <Aerroon> i mentioned it was going to be for streaming
[18:13:24 CEST] <Diag> I think he/shes just looking for high performance adequate quality video encoding
[18:13:26 CEST] <Aerroon> and now you're telling me "oh of course it doesn't work if you turn settings down"
[18:13:30 CEST] <Aerroon> no, i'm not
[18:13:34 CEST] <Diag> no?
[18:13:37 CEST] <Diag> then youre crazy lol
[18:13:38 CEST] <Aerroon> i'm asking if i need to compile ffmpeg myself to try nvenc
[18:13:42 CEST] <Aerroon> or if i can find a redistributed build
[18:13:54 CEST] <Aerroon> i will run the tests myself and see what results i get and then decide
[18:14:09 CEST] <thebombzen> ffmpeg's Zeranoe builds have nvenc support built in. On Linux, it depends on the downstream build flags
[18:14:24 CEST] <Aerroon> visually looking at it i can't actually tell much of a difference between the x264 settings i can run at this limited bandwidth and nvenc or even quicksync
[18:14:36 CEST] <Aerroon> i can tell that the quality isn't very good, but i can't tell which one is better
[18:14:44 CEST] <Aerroon> thebombzen, thank you!
[18:15:16 CEST] <Aerroon> the problem with my tests so far is that they are basically recordings with obs and simply hoping that they compare the exact same frames
[18:15:29 CEST] <Aerroon> but i'd like to make sure, and ffmpeg is amazing
[18:15:45 CEST] <thebombzen> What you should do is make a short recording in OBS with lossless x264 ultrafast
[18:15:53 CEST] <thebombzen> and then use the CLI tool to process that
[18:16:05 CEST] <thebombzen> warning, it'll be absolutely enormous. hence, short.
[18:16:07 CEST] <Aerroon> well that's the plan
[18:16:17 CEST] <Aerroon> well i'm not gonna record it
[18:16:22 CEST] <Aerroon> i'm gonna go look for some lossless source
[18:16:28 CEST] <Aerroon> a few come to mind already
[18:17:15 CEST] <Aerroon> thank you for your help guys
[18:17:59 CEST] <Diag> make sure to show us the results
[18:18:09 CEST] <Diag> im interested
[18:20:37 CEST] <Aerroon> sure
[18:20:40 CEST] <thebombzen> Aerroon: try http://jell.yfish.us/
[18:20:50 CEST] <thebombzen> it's not lossless but the bitrates are so enormous that it might be good enough for your purposes
[18:21:50 CEST] <Aerroon> okay now i need to figure out why my ffmpeg version is still showing the old one
[18:22:09 CEST] <thebombzen> what do you mean "my ffmpeg version is still showing the old one"
[18:22:15 CEST] <thebombzen> on Windows, it's probably a PATH thing
[18:22:18 CEST] <Aerroon> yep
[18:22:20 CEST] <Aerroon> and i updated path
[18:22:28 CEST] <thebombzen> restart your command prompt
[18:22:32 CEST] <thebombzen> it caches that
[18:23:12 CEST] <Diag> why not use fraps to record
[18:23:21 CEST] <Diag> its already lossless and not even h264 iirc
[18:24:02 CEST] <Aerroon> imagemagick
[18:24:07 CEST] <Diag> ?
[18:24:15 CEST] <Aerroon> imagemagick dropped another ffmpeg version into my path
[18:24:16 CEST] <Diag> what of it
[18:24:18 CEST] <Aerroon> that's why it didn't update
[18:24:19 CEST] <Diag> lol
[18:24:32 CEST] <Diag> does imagemagick have an interface?
[18:24:38 CEST] <Diag> I thought it was just a library
[18:24:59 CEST] <thebombzen> Diag: yes
[18:25:04 CEST] <thebombzen> convert, identify, etc.
[18:25:07 CEST] <thebombzen> those are ImageMagick
[18:25:09 CEST] <Diag> weird
[18:25:23 CEST] <thebombzen> as for "Why not use FRAPS"
[18:25:26 CEST] <thebombzen> well OBS is much better
[18:25:38 CEST] <Diag> well yes and no
[18:25:54 CEST] <thebombzen> how is OBS not better than FRAPS
[18:26:03 CEST] <Diag> In this situation, I think fraps is a good substitute if youre looking for a 30 second video thats not compressed
[18:26:10 CEST] <thebombzen> Why?
[18:26:18 CEST] <Diag> because fraps is simple
[18:26:21 CEST] <Aerroon> how good is nvenc's lossless version?
[18:26:28 CEST] <Diag> probably worse XD
[18:26:43 CEST] <Aerroon> fraps you can literally have it write separate images if you so desire
[18:26:55 CEST] <thebombzen> You can also do that with OBS. But you shouldn't.
[18:27:00 CEST] <Aerroon> i do think i have to find something other than jellyfish though
[18:27:07 CEST] <thebombzen> Aerroon: NVENC's lossless is not good, but it's fairly comparable to anything that encodes losslessly in realtime.
[18:27:08 CEST] <Aerroon> 3 hours to download
[18:27:35 CEST] <thebombzen> Realtime lossless encoding is not something that's going to be efficient
[18:27:45 CEST] <dsc_> why record things if you can 'live the moment'. Priceless parts of life can't be recorded. With or without fraps/obs, it doesnt matter. Some moments are too precious to capture.
[18:27:51 CEST] <dsc_> for anything else you can use mastercard
[18:27:58 CEST] <Diag> lol
[18:28:02 CEST] <Diag> I love my radeon relive
[18:28:08 CEST] <Diag> its the greatest shit
[18:28:31 CEST] <dsc_> is it geforce experience but then for radeon?
[18:28:32 CEST] <thebombzen> Some things require a known exact configuration.
[18:28:36 CEST] <Diag> nope
[18:28:37 CEST] <thebombzen> For everything else, there's git master
[18:28:57 CEST] <Diag> dsc_: its literally built right into the radeon software shit, no extra bullshit, no accounts
[18:28:58 CEST] <Diag> more options
[18:29:01 CEST] <Diag> more streaming options
[18:29:10 CEST] <Diag> less gpu impact
[18:29:10 CEST] <thebombzen> Aerroon: anything that can do it (utvideo, ffvhuff, x264 lossless ultrafast, nvenc lossless) is going to be inefficient in realtime
[18:29:11 CEST] <dsc_> yeah and worse drivers because its ATI ?
[18:29:14 CEST] <dsc_> ;')
[18:29:19 CEST] <thebombzen> so NVENC is not great, but nothing is.
[18:29:23 CEST] <Aerroon> oh yeah i know
[18:29:24 CEST] <Aerroon> i meant
[18:29:25 CEST] <Diag> nvidia has horrible ass drivers
[18:29:28 CEST] <Aerroon> is nvenc lossless actually lossless
[18:29:36 CEST] <Diag> probably
[18:29:48 CEST] <thebombzen> Aerroon: I'm not sure if it's bit-exact
[18:29:53 CEST] <thebombzen> but there's no quantization
[18:30:01 CEST] <thebombzen> it's lossless in that sense
[18:31:05 CEST] <thebombzen> Aerroon: note that NVENC doesn't support RGB H.264
[18:31:19 CEST] <thebombzen> you'll need to convert it to yuv444p (also called I444) first. This might be lossy
[18:31:23 CEST] <thebombzen> or at least, not bit-exact.
[18:31:46 CEST] <Diag> why would they do that
[18:32:25 CEST] <thebombzen> why would they do what
[18:32:34 CEST] <Diag> https://www.youtube.com/watch?v=k2ByHspr9sQ
[18:32:38 CEST] <Diag> why would they do that ^
[18:34:23 CEST] <Aerroon> so i have a video in images
[18:34:30 CEST] <Aerroon> what should i encode it as to be the main thing to compare to
[18:35:01 CEST] <thebombzen> Diag: same reason people do this: https://www.youtube.com/watch?v=GDU-fW36qaA
[18:35:07 CEST] <BtbN> thebombzen, nvenc can take RGB input just fine. But it will convert it to yuv internally
[18:35:18 CEST] <thebombzen> BtbN: that's the same issue though
[18:35:25 CEST] <thebombzen> "not big-exact"
[18:35:27 CEST] <thebombzen> bit*
[18:42:53 CEST] <Diag> thebombzen: i died a littler
[18:42:58 CEST] <Diag> little*
[18:44:58 CEST] <Diag> holy fuck
[18:44:58 CEST] <cq1> Does anyone know how good GoPro's hardware H.264 encoders are? I always approach anything other than x264 with extreme skepticism, and assume that their encoders are absolute rubbish.
[18:45:08 CEST] <cq1> thebombzen: Thanks for the resource.
[18:45:27 CEST] <Diag> thebombzen: so this guy brings me his computer telling me its running slow
[18:45:32 CEST] <Diag> 107 days of uptime
[18:45:36 CEST] <Diag> hes just been putting it to sleep
[18:45:53 CEST] <BtbN> That's what Windows does by default when you tell it to Shutdown
[18:46:03 CEST] <Diag> yes
[18:46:08 CEST] <BtbN> Only an explicit reboot actually reboots it...
[18:46:10 CEST] <Diag> I just cannot believe that it has 107 days
[18:46:19 CEST] <Diag> its a laptop, it should shut down from other crpa
[18:46:28 CEST] <BtbN> it'll just suspend to disk
[18:46:29 CEST] <Diag> hibernation is disabled
[18:46:47 CEST] <Diag> no disk suspension
[18:46:50 CEST] <Diag> its been asleep
[18:47:57 CEST] <cq1> thebombzen: Yeah, this looks okay enough. I guess HEVC 10-bit at 400 Mbps (assuming it was encoded by a non-trash encoder) will probably be high enough quality for my purposes. Thanks.
[18:59:43 CEST] <Aerroon> thebombzen, https://pastebin.com/XdUr27Pk this is what i got
[18:59:47 CEST] <Aerroon> i'm on a gtx 1080
[19:00:08 CEST] <Aerroon> but unfortunately i don't think these results are very useful for me and i'll have to revisit it
[19:00:54 CEST] <Aerroon> the source isn't high enough resolution and when i looked through the results in vlc i noticed that the bitrates were throwing way too high
[19:01:20 CEST] <thebombzen> Aerroon: again, if you're trying to use ssim, you should use -tune:v ssim
[19:01:48 CEST] <thebombzen> x264's psychovisual optimizations give visually better results with worse ssim
[19:02:01 CEST] <thebombzen> if you want ssim to be useful, you should tell x264 to optimize for SSIM, rather than subjective quality
[19:02:53 CEST] <thebombzen> Aerroon: other things about x264 - don't set the profile if you're just testing. x264 picks the most restrictive profile that can encompass the other encoding settings. Setting the profile explicitly is not recommended unless you're targeting a device that has that restriction
[19:02:57 CEST] <Aerroon> well even then the problem witht he source video would still be there
[19:03:12 CEST] <Aerroon> thebombzen, as i will use this for streaming eventually
[19:03:14 CEST] <thebombzen> Don't set the pixel format to nv12
[19:03:17 CEST] <Aerroon> i think it's useful
[19:03:21 CEST] <thebombzen> It's completely useless
[19:03:22 CEST] <Aerroon> and of course i will set pixel format to nv12
[19:03:27 CEST] <Aerroon> that's what i'm going to use when i'll stream
[19:03:28 CEST] <thebombzen> Don't set it to nv12
[19:03:31 CEST] <Aerroon> so why would i not mimic those settings
[19:03:41 CEST] <thebombzen> because nv12 is non-planar
[19:03:52 CEST] <thebombzen> x264 internally converts it to to planar (i.e. yuv420p, or I420)
[19:04:02 CEST] <thebombzen> you should use -pix_fmt yuv420p
[19:04:12 CEST] <thebombzen> also, it's -pix_fmt, not -pixel_format. long story.
[19:04:40 CEST] <thebombzen> nv12 is interleaved, and yuv420p is planar. x264 works in planar so you're going to want to use that
[19:05:30 CEST] <Aerroon> thanks
[19:05:34 CEST] <JEEB> detail: x264 actually natively works in nv12
[19:05:37 CEST] <JEEB> ;)
[19:05:38 CEST] <Aerroon> but
[19:05:58 CEST] <thebombzen> JEEB: lol, haha
[19:05:58 CEST] <JEEB> http://git.videolan.org/?p=x264.git;a=commit;h=387828eda87988ad821ce30f818837bd4280bded
[19:06:02 CEST] <Aerroon> "this is what i'm going to end up using so i should run tests with it too"
[19:06:11 CEST] <JEEB> it was changed in 2010 to improve SIMD'ification
[19:06:14 CEST] <thebombzen> Aerroon: you should not use -pix_fmt nv12 for the final result either
[19:06:28 CEST] <thebombzen> x264 receives yuv420p
[19:06:30 CEST] <JEEB> most likely the libavcodec wrapper still feeds it planar stuff
[19:07:00 CEST] <thebombzen> yea. if you use -pix_fmt nv12, avcodec's libx264 will reject that and request planar input
[19:07:19 CEST] <JEEB> shouldn't be too hard to patch it to take in nv12 as well I guess?
[19:07:27 CEST] <JEEB> "This change also extends the API to allow direct NV12 input"
[19:07:49 CEST] <thebombzen> probably. I'm not sure if it ignores the -pix_fmt nv12, or if it autoinserts scale,format=nv12,scale,format=yuv420p
[19:08:08 CEST] <Aerroon> thebombzen, but doesn't it end up nv12 on youtube anyway?
[19:08:12 CEST] <thebombzen> No
[19:08:23 CEST] <thebombzen> Youtube H.264 is in yuv420p
[19:08:40 CEST] <thebombzen> given that the video you're capturing will be in planar when FFmpeg sees it, it's best to let libx264 handle any sort of nv12 conversion
[19:08:54 CEST] <Aerroon> ???????
[19:08:56 CEST] <Aerroon> okay
[19:08:58 CEST] <JEEB> well, technically I bet it's coded in separate planes but what the decoder output is depends on the decoder
[19:09:01 CEST] <Aerroon> so i'm doing this entire thing
[19:09:15 CEST] <Aerroon> to compare encoders in quality to know which one to use with obs for *streaming*
[19:09:18 CEST] <thebombzen> Aerroon: what I'm telling you is that most software tools abstract away any sort of nv12 from the user so you can pretend most of the time that it's always yuv420p
[19:09:32 CEST] <thebombzen> nvenc is the exception, which whines about that.
[19:09:48 CEST] <JEEB> the difference between the two is only in how the data is kept, basically
[19:10:03 CEST] <JEEB> nv12 = luma and a single plane for chroma, interleaved (aka "half-packed")
[19:10:05 CEST] <thebombzen> Aerroon: yuv420p means planar. Y plane, followed by U, followed by V
[19:10:20 CEST] <thebombzen> nv12 is partially interleaved
[19:10:25 CEST] <thebombzen> as jeeb-said, half-packed.
[19:10:38 CEST] <JEEB> yuv420p = each plane is separate
[19:10:41 CEST] <JEEB> (planar)
[19:10:54 CEST] <thebombzen> it's like how rgb24 is a sequence of 24-bit integers, each of which is red,green, then blue
[19:10:57 CEST] <Aerroon> i don't understand
[19:10:59 CEST] <JEEB> so conversion between the two is a simple pack/unpack
[19:11:06 CEST] <Aerroon> what i don't understand is why you want me to switch it
[19:11:29 CEST] <thebombzen> Aerroon: I'm not asking you to switch to it, I'm recommending you remove explicitly setting options that the tools will choose for you correctly
[19:11:29 CEST] <JEEB> (although swscale is lulz so you've been warned)
[19:11:43 CEST] <thebombzen> for this, swscale is fine
[19:11:48 CEST] <Aerroon> thebombzen, but you seem to be missing the entire point of what i'm doing here
[19:11:53 CEST] <JEEB> yea, as long as you hit the "fast path"
[19:11:56 CEST] <Aerroon> i'm trying to compare the results i will get
[19:12:11 CEST] <JEEB> Aerroon: then you will be getting a bit stream of some sort and you decode it, no?
[19:12:12 CEST] <thebombzen> Aerroon: and I'm telling you that you shouldn't put those options here *or* in your final recording
[19:12:12 CEST] <Aerroon> obs defaults to nv12 and i do not see a reason to switch away from it
[19:12:25 CEST] <Aerroon> so why would i NOT use nv12 when i'm going to be testing for it
[19:12:38 CEST] <JEEB> if the encoder cannot take it in (or at least the lavc wrapper cannot?)
[19:12:47 CEST] <thebombzen> Aerroon: becuase nv12 and yuv420p are different ways of arranging mathematically identical data
[19:12:47 CEST] <JEEB> it only takes the separate-planes thing in
[19:12:50 CEST] <thebombzen> you don't need to make that choice.
[19:13:00 CEST] <Aerroon> again please listen
[19:13:03 CEST] <thebombzen> nv12 and yuv420p are mathematically the same data, just arranged differently
[19:13:16 CEST] <Aerroon> i'm trying to compare the quality of the recordings of the encoders
[19:13:24 CEST] <thebombzen> I know that
[19:13:25 CEST] <Aerroon> to see which one would be a better fit for using with streaming
[19:13:25 CEST] <JEEB> yes, so you just want to encode some sort of 4:2:0
[19:13:30 CEST] <Aerroon> the streaming will use nv12
[19:13:40 CEST] <Aerroon> so why would i want it to be something different during testing
[19:13:42 CEST] <thebombzen> Aerroon: again, it doesn't *really* matter from a mathematical perspective which one you use, because it's the same data arranged differently
[19:13:45 CEST] <thebombzen> it won't affect the quality at all
[19:13:54 CEST] <JEEB> Aerroon: so YCbCr has three planes, right?
[19:14:05 CEST] <Aerroon> so what difference does it make if i set or don't set it?
[19:14:15 CEST] <thebombzen> Aerroon: I'm telling you not to set it because the tools will pick whichever one you want in this case correctly.
[19:14:23 CEST] <JEEB> depends on the encoder and your input
[19:14:25 CEST] <thebombzen> and also not setting it avoids swscale
[19:14:45 CEST] <Aerroon> so let me get this straight
[19:14:45 CEST] <thebombzen> Aerroon: libx264 wants yuv420p input, and nvenc wants nv12. It's the same data, but arranged differently.
[19:15:03 CEST] <JEEB> but between NV12 and planar 4:2:0 (what yuv420p is) the difference is how it's arranged in memory
[19:15:04 CEST] <Aerroon> during testing i should use different settings than for the actual streaming later on
[19:15:09 CEST] <JEEB> uhh
[19:15:14 CEST] <JEEB> if your thing can use libx264
[19:15:25 CEST] <JEEB> then effectively you are either pushing planar 4:2:0 or NV12 to it
[19:15:28 CEST] <JEEB> which are the same data
[19:15:35 CEST] <thebombzen> Aerroon: well you should listen to us
[19:15:35 CEST] <JEEB> just arranged differently in memory
[19:15:44 CEST] <thebombzen> and when we tell you that yuv420p and nv12 are mathematically the same data
[19:15:47 CEST] <thebombzen> but arranged differently
[19:15:53 CEST] <thebombzen> then you should understand this means there's no quality difference
[19:15:54 CEST] <Aerroon> then why does it matter if they're the same
[19:16:08 CEST] <JEEB> because the encoders are specific about what they take in
[19:16:10 CEST] <JEEB> in libavcodec
[19:16:15 CEST] <JEEB> and if you say "I want you to take in X"
[19:16:24 CEST] <JEEB> and the encoder hasn't been set to take it in
[19:16:28 CEST] <JEEB> it will say "nope"
[19:16:32 CEST] <JEEB> or the wrapper
[19:16:44 CEST] <JEEB> in this case lavc's libx264 wrapper could be patched to also take in nv12
[19:16:50 CEST] <JEEB> because libx264 actually supports it
[19:16:58 CEST] <thebombzen> libx264's avcodec wrapper wants yuv420p. If you tell it that you're feeding it nv12, it will automatically insert a converstion from nv12 to yuv420p
[19:17:08 CEST] <thebombzen> you don't want to do this
[19:17:24 CEST] <BtbN> uhm, I'm pretty sure x264 takes in nv12 natively
[19:17:27 CEST] <JEEB> yes
[19:17:29 CEST] <BtbN> and it's even the prefered format
[19:17:29 CEST] <JEEB> I've said that N times
[19:17:33 CEST] <JEEB> and linked the commit
[19:17:40 CEST] <thebombzen> Aerroon: they're mathematically identical data, so it's generally a good idea to not force an explicit conversion (which is just a rearrangement) unless the tools are necessary
[19:17:49 CEST] <JEEB> and thus I said "the wrapper could be patched"
[19:17:49 CEST] <thebombzen> BtbN: >[13:16:58] <thebombzen> libx264's avcodec wrapper
[19:17:50 CEST] <JEEB> :P
[19:18:16 CEST] <thebombzen> Given that the data is the same, you should not force it to be rearranged unless it's necessary
[19:18:20 CEST] <BtbN> libx264.c supports NV12, and _a lot_ of other formats, just fine
[19:18:21 CEST] <JEEB> Aerroon: basically you're hitting details which most higher-abstraction tools would hide from you :P
[19:18:22 CEST] <Aerroon> so i fixed pix_fmt
[19:18:26 CEST] <Aerroon> it outputs it just fine
[19:18:49 CEST] <JEEB> Aerroon: in theory you shouldn't be setting either nv12 or yuv420p but saying something like "I want 4:2:0 YCbCr"
[19:18:54 CEST] <JEEB> and the thing should internally do whatever
[19:18:57 CEST] <Aerroon> Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), nv12, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 6000 kb/s, 24 fps, 1k tbn, 24 tbc
[19:19:12 CEST] <thebombzen> Aerroon: we're telling you not to force options that you do not need to force
[19:19:39 CEST] <thebombzen> BtbN: that being said, there's still merit in letting x264 do the I420 -> NV12 conversion, because it's probably faster than swscale
[19:19:40 CEST] <Aerroon> but then the option is going to be different in the testing vs actual use
[19:19:59 CEST] <thebombzen> WE ARE ALSO TELLING YOU NOT TO SET IT FOR THE ACTUAL USE
[19:20:00 CEST] <JEEB> if you are going to want to use libx264 then it would be exactly that unless the thing you're using is a different piece of software
[19:20:01 CEST] <thebombzen> please listen
[19:20:02 CEST] <Aerroon> i get that it doesn't change anything here now
[19:20:17 CEST] <Aerroon> thebombzen, it defaults to nv12 in obs
[19:20:22 CEST] <Aerroon> there is no "do not touch this option" button
[19:20:27 CEST] <Aerroon> you explicitly have to select one
[19:20:29 CEST] <thebombzen> -_-
[19:20:33 CEST] <JEEB> then it's a different piece of software
[19:20:37 CEST] <JEEB> and it is hiding/setting things accordingly
[19:20:38 CEST] <Aerroon> yeah, it is
[19:20:45 CEST] <JEEB> it is hiding details from you
[19:20:55 CEST] <JEEB> although to be honest already showing NV12 to you is "too much" :P
[19:21:05 CEST] <JEEB> for you it is 4:2:0 YCbCr
[19:21:10 CEST] <JEEB> that's all you really care about
[19:21:13 CEST] <thebombzen> yea tbh OBS shouldn't actually differentiate between I420 and NV12
[19:21:15 CEST] <JEEB> since that's the data
[19:21:30 CEST] <thebombzen> I420 and NV12 are the same pixel data but arranged differently
[19:21:38 CEST] <thebombzen> OBS shouldn't allow you to choose between the two
[19:21:45 CEST] <thebombzen> and it should pick the correct one depending on context
[19:21:46 CEST] <Aerroon> since we're on that topic
[19:21:50 CEST] <JEEB> (I420 is the windows fourcc name for what is called yuv420p in FFmpeg)
[19:21:55 CEST] <Aerroon> would I444 look any better?
[19:22:08 CEST] <JEEB> if your filter chain doesn't fuck up, yes
[19:22:11 CEST] <JEEB> esp. reds etc
[19:22:13 CEST] <thebombzen> Aerroon: probably not. don't stream in I444
[19:22:17 CEST] <JEEB> ahahaha
[19:22:26 CEST] <JEEB> thebombzen: you're giving the right recommendation but for the wrong reason
[19:22:34 CEST] <JEEB> 4:4:4 isn't hardware decode'able
[19:22:43 CEST] <JEEB> thus most clients will not be able to play it
[19:22:43 CEST] <BtbN> it's not browser decodable as well
[19:22:48 CEST] <JEEB> effectively yes
[19:22:55 CEST] <thebombzen> JEEB: I know that I444 does look better for CRF, but finite bitrate means I444 might actually look worse
[19:23:08 CEST] <JEEB> he said colorspace vs colorspace
[19:23:10 CEST] <BtbN> I think nvidia can decode it? But I'm not 100% and would need to check
[19:23:18 CEST] <JEEB> BtbN: I think it was encode only?
[19:23:25 CEST] <JEEB> at least DXVA2 doesn't have it
[19:23:51 CEST] <thebombzen> JEEB: Yea, I444 is better than I420, but also remember that if you're encoding at a finite CBR, it might allocate too many bits for the extra data
[19:23:52 CEST] <Aerroon> anyways thanks guys
[19:24:06 CEST] <BtbN> hm, cuvid in theory supports it. But anything else than 420 is not implemented by the driver
[19:24:08 CEST] <JEEB> thebombzen: yes but that is different from 4:2:0 vs 4:4:4
[19:24:23 CEST] <thebombzen> JEEB: I know, but I was answering Aerroon's question
[19:24:27 CEST] <JEEB> I would then add separately that if you're constrained it might or might lead to worse compression
[19:24:30 CEST] <JEEB> no
[19:24:30 CEST] <JEEB> his question was
[19:24:31 CEST] <thebombzen> or rather in the context of their question
[19:24:37 CEST] <JEEB> "< Aerroon> would I444 look any better?"
[19:24:47 CEST] <JEEB> (against 4:2:0)
[19:24:51 CEST] <JEEB> thebombzen: yes you add details then
[19:24:53 CEST] <JEEB> goddamnit
[19:25:01 CEST] <Aerroon> also i have to say
[19:25:05 CEST] <thebombzen> well yea but I assume the question was specifically about streaming in CBR in OBS
[19:25:08 CEST] <Aerroon> i haven't seen this channel be this alive before
[19:25:12 CEST] <thebombzen> I444 does look better but in this particular case probably not
[19:25:18 CEST] <JEEB> it really depends
[19:25:26 CEST] <JEEB> I've had lower bit rate streams look better in 4:4:4
[19:25:42 CEST] <thebombzen> but Aerroon: whether or not it looks better here is mostly irrelevant because I444 will break compatibility
[19:25:51 CEST] <JEEB> yes, as I noted
[19:25:53 CEST] <Aerroon> yup, already got that part
[19:25:56 CEST] <thebombzen> most mobile devices won't be able to view it and many browsers as well
[19:26:23 CEST] <thebombzen> JEEB: either way, the 4:4:4 vs 4:2:0 seems to be a bit of a hot topic here
[19:26:34 CEST] <thebombzen> whehter it's worth the extra bitrate
[19:26:43 CEST] <JEEB> it depends is the real answer
[19:26:50 CEST] <thebombzen> probably on the source
[19:26:55 CEST] <thebombzen> my guess is for film it's probably not
[19:26:58 CEST] <JEEB> source, parameters etc
[19:26:59 CEST] <thebombzen> but for anime maybe
[19:27:13 CEST] <Aerroon> actually one more question
[19:27:16 CEST] <JEEB> also screen capture is most likely gonna like 4:4:4
[19:27:31 CEST] <JEEB> although to be honest it also depends on how fucked up your filtering chain is
[19:27:36 CEST] <Aerroon> if i limit bitrate to 6000k, i should also limit buffer size, right? but o what?
[19:27:39 CEST] <Aerroon> or should i set a -maxrate?
[19:27:40 CEST] <JEEB> going through 4:2:0 and back is welp
[19:27:51 CEST] <JEEB> Aerroon: uhh since you're using OBS I don't think we can help you
[19:27:57 CEST] <JEEB> since you need help wrt OBS options
[19:27:58 CEST] <JEEB> not FFmpeg options
[19:27:59 CEST] <Aerroon> well i meant for ffmpeg
[19:28:02 CEST] <Aerroon> for the test part
[19:28:12 CEST] <JEEB> maxrate+bufsize are always to be used together
[19:28:24 CEST] <JEEB> since you calculate maxrate over bufsize
[19:28:58 CEST] <JEEB> (that's how VBV/HRD works)
[19:29:27 CEST] <Aerroon> bufsize + maxrate will be the highest the bitrate will go to, right?
[19:31:24 CEST] <JEEB> no
[19:31:27 CEST] <JEEB> maxrate is the highest
[19:31:47 CEST] <JEEB> thus if maxrate is the minimum average bandwidth a client has to be able to keep
[19:31:52 CEST] <Aerroon> okay, i'm sorry i was an idiot
[19:32:08 CEST] <JEEB> and bufsize is on how much buffer both encoder and client work with
[19:32:27 CEST] <JEEB> the bigger the bufsize the more leeway the encoder has, of course
[20:04:04 CEST] <pgorley> hi, is there a way to get ffmpeg logs in android studio? "adb shell setprop log.redirect-stdio true" doesn't work
[20:05:54 CEST] <BtbN> I doubt anyone in here has any clue about android IDEs
[20:08:38 CEST] <JEEB> pgorley: you will have to tell libavutil to log into your logging thing
[20:08:49 CEST] <JEEB> if you're not using the APIs then you're fucked
[20:09:20 CEST] <pgorley> so av_log_set_callback?
[20:09:26 CEST] <JEEB> yes
[20:09:33 CEST] <JEEB> then map that to the android logging framework
[20:10:48 CEST] <pgorley> ok, thanks
[20:30:02 CEST] <Dark-knight> will anything negative happen to my file if I use "-i input.mkv -c copy output.mp4"?
[20:30:54 CEST] <Dark-knight> the audio is 2 ch stereo AAC
[20:55:54 CEST] <Dark-knight> simply what I'm asking is, will it actually work to change a .mkv to a .mp4
[20:56:06 CEST] <Dark-knight> I'm trying to get it to play on my xbox
[20:56:24 CEST] <Dark-knight> and it won't work if the file isn't actually an mp4
[20:57:32 CEST] <kepstin> assuming the audio+video codecs in your file are compatible with mp4 container and are supported on your xbox, I'd expect that to be fine
[20:58:03 CEST] <kepstin> also, running that command to test it would have probably gone faster than waiting for someone to respond :/
[21:08:01 CEST] <strepto> Top of the morning! This must be the most crowded IRC channel I've seen since the wall fell.
[21:09:31 CEST] <dahlquist> Hello all
[21:09:47 CEST] <thebombzen> sounds like you haven't been on Rizon then
[21:10:00 CEST] <DHE> or just #gentoo
[21:10:17 CEST] <thebombzen> I haven't been there but I absolutely believe that
[21:10:26 CEST] <DHE> currently 1098 users
[21:10:34 CEST] <thebombzen> I wonder about #archlinux or whatever it's called
[21:10:36 CEST] <dahlquist> new to ffmpeg..  struggling to merge 3 video of short length. (works on longer lengths)  Using -f concat -safe 0 -i "${TMP_MERGER_FILE_INPUT1}" -c copy "${TMP_MERGED_VIDEO_FILE}"
[21:11:45 CEST] <thebombzen> DHE: #archlinux has 1788
[21:11:52 CEST] <dahlquist> problem is the playback stops at the start of the 3rd  video after merge when the lengths of the elements are 2/6/1 seconds in length respectively...
[21:12:27 CEST] <dahlquist> no problem when the length of the 3rd piece is more then 5 seconds
[21:12:33 CEST] <thebombzen> we can't help you if we don't actually know anything about the videos or their lengths or what you tried
[21:12:34 CEST] <strepto> I am looking into setting up an audio stream, streaming only lossless files, most of it being .aiff and .wav, with a bitrate from 1411 to 2304 kbps. Would "ffserver" be able to provide that kind of streaming capability? The other tools I've looked at, like icecast2, offers only lossy streams..
[21:12:55 CEST] <thebombzen> dahlquist: you haven't really told us anything that allows us to help you
[21:13:24 CEST] <thebombzen> strepto: ffserver is deprecated
[21:13:45 CEST] <thebombzen> you could possibly set up an nginx instance as a multicast stream. but you also shouldn't stream uncompressed audio
[21:14:01 CEST] <thebombzen> if you're going to do that, you should encode it to FLAC on the fly
[21:14:24 CEST] <strepto> thebombzen: I didn't know lossless compression could be added to a stream of the fly.
[21:15:03 CEST] <thebombzen> strepto: it definitely can. The issue with compressing stuff on the fly is it takes CPU. but audio is not cpu-intensive enough for that to be an issue.
[21:15:16 CEST] <thebombzen> you can encode flac at like 100x realtime speed with even mediocre hardware.
[21:16:17 CEST] <thebombzen> strepto: what you probably want to do for streaming is compress the audio in advance. You honestly could even stream in high-bitrate Opus. It's lossy but for streaming on the fly if you set the bitrate to 320 kbps or something absurd it should easily be transparent enough.
[21:16:19 CEST] <strepto> In any case, I'd need to find a way to stream it first. Ironically, VLC supports this out of the box, but .. doesn't really scale from a service perspective.
[21:17:06 CEST] <thebombzen> One advantage of Opus is that it's specifically designed for that purpose and it works incredibly well with chunking and starting and stopping
[21:17:13 CEST] <strepto> I have no problems setting up a lossy stream using icecast2 or similar. Still, the very point of my project is to offer lossless audio. In my case, bw and cpu/hw resources isn't a problem.
[21:17:28 CEST] <JodaZ> icecast claims to support flac
[21:17:29 CEST] <strepto> I will look into Opus.
[21:17:34 CEST] <thebombzen> Opus *is* lossy fyi
[21:18:13 CEST] <thebombzen> it's higher quality than every other lossy codec in existence (including aac, vorbis, mp3, etc) and it maintains nice qualities for streams like low-delay and that stuff
[21:18:45 CEST] <thebombzen> Icecast says it supports FLAC, so if you got a lossy icecast stream to work before, you might want to consider encoding your wav to flac in advance and then just trying that.
[21:18:56 CEST] <thebombzen> "ffmpeg -i input.wav output.flac" should do it
[21:19:10 CEST] <thebombzen> and then use the FLAC files the same way you used the lossy files
[21:19:27 CEST] <strepto> That could work.
[21:19:28 CEST] <JodaZ> thebombzen, barbaric, just pipe it in directly
[21:20:54 CEST] <strepto> Hm, there's nothing in the official icecast documentation to suggest flac support. But I'll keep on digging.
[21:21:08 CEST] <furq> http://icecast.org/faq/
[21:21:17 CEST] <furq> Icecast is a streaming server, which can stream audio (and video) to listeners/viewers. It supports Ogg (Vorbis, Theora), Opus, FLAC and WebM (VP8/VP9),
[21:21:46 CEST] <furq> flac support is landing in browsers as well now
[21:21:50 CEST] <thebombzen> JodaZ: yea, but I have no idea what setup they used to get icecast to work. if it was VLC then that won't work
[21:21:51 CEST] <furq> i know firefox supports it
[21:22:01 CEST] <furq> also you can use ffmpeg as an icecast source client
[21:22:54 CEST] <DHE> thebombzen: you win then
[21:23:05 CEST] <thebombzen> lol
[21:23:23 CEST] <thebombzen> I have all of the wins
[21:24:03 CEST] <strepto> Thank you furq :)
[21:24:43 CEST] <thebombzen> your_solution = (Ice) stream;
[21:35:30 CEST] <RandomCouch> So I need help with a problem that is probably too complicated, I'm working on mobile app for android, I have ffmpeg compiled and running on android, the app records a video from the mobile's camera, and then concats that video with another video on the device
[21:35:50 CEST] <RandomCouch> the problem is the output video, and this problem does not exist on all android devices, recent ones play it just fine
[21:36:06 CEST] <RandomCouch> but some devices like the Samsung S4 freeze at the end of the video playback
[21:36:14 CEST] <RandomCouch> the video player freezes and becomes unresponsive
[21:36:32 CEST] <RandomCouch> The way I concat these 2 videos is, I first create intermediates
[21:36:44 CEST] <RandomCouch> the command for transforming the recorded video into itnermediate vid is this
[21:36:51 CEST] <RandomCouch>  -acodec copy -vcodec copy -bsf:v h264_mp4toannexb -b:v 1M -preset fast -r 30
[21:37:06 CEST] <BtbN> that's not a transcode. And just use -c copy. The bsf should not be needed anymore.
[21:37:22 CEST] <RandomCouch> I've tried that too
[21:37:33 CEST] <RandomCouch> it still made the video player unresponsive at the end, what did fix it though
[21:37:38 CEST] <RandomCouch> is when I used -vcodec libx264
[21:37:51 CEST] <BtbN> that's an actual transcode
[21:37:54 CEST] <BtbN> but still, -c:v
[21:37:56 CEST] <RandomCouch> the problem with that is that it took way too long to transcode it
[21:38:04 CEST] <RandomCouch> it's a 15 second long video
[21:38:16 CEST] <RandomCouch> and it took about 200 seconds to transcode it
[21:38:27 CEST] <BtbN> that's about expected on a phone
[21:38:41 CEST] <RandomCouch> well, when I skip the transcoding, it's much faster but bugs out on some devices
[21:38:48 CEST] <RandomCouch> do you know why that happens?
[21:38:56 CEST] <BtbN> Because phones have bad players
[21:39:06 CEST] <RandomCouch> the second video that gets mixed with it is transcoded with libx264
[21:39:23 CEST] <RandomCouch> like it's already transcoded when I put it on the device
[21:39:30 CEST] <RandomCouch> so I don't need to do it again when concatenating
[21:39:49 CEST] <RandomCouch> so if I can figure out a way to transcode it the right way, a way where I won't have to transcode the first video which is recorded by the phone
[21:39:55 CEST] <RandomCouch> then I can just concat them
[21:39:59 CEST] <RandomCouch> and it would be quick
[21:40:16 CEST] <BtbN> the phone probably uses a hardware encoder for it
[21:40:34 CEST] <BtbN> You can't really produce an input video that is compatible with everything any hw decoder could ever throw out
[21:40:37 CEST] <RandomCouch> the video that is recorded by the phone has a variable frame rate
[21:40:44 CEST] <RandomCouch> uses h264 and aac encoders
[21:41:16 CEST] <RandomCouch> I mean codecs
[21:53:47 CEST] <Shootfast> Hi, I'm trying to convert from yuv420p to yuv444p, adjusting only the srcRange and dstRange via sws_setColorspaceDetails, but the set call fails due to a check in libswscale/utils.c:884 that hopes to find differences in the yuv coefficient tables (which I am not changing). Could anyone confirm that changing only the YUV subsampling and range is an acceptable operation for swscale?
[21:59:47 CEST] <BtbN> it should work fine. But is 100% pointless
[22:05:03 CEST] <Shootfast> @BtbN What makes it pointless?
[22:05:18 CEST] <BtbN> It makes it bigger, for no gain in quality.
[22:05:30 CEST] <BtbN> The information is already lost, it's not going to come back.
[22:22:35 CEST] <Shootfast> Yes, the data is lost, but I'm manipulating the data elsewhere with other full range sources and wanted everything in one range.
[22:25:20 CEST] <Dark-knight> whats the difference between 10bit and 8bit? I'm trying to chose which file I want to convert.
[22:27:33 CEST] <Cracki_> Dark-knight, more context please
[22:27:45 CEST] <Cracki_> in any case: the difference is 2bit
[22:29:30 CEST] <Dark-knight> well one says, 10bit 1080p and the other says 8bit 1080p
[22:30:14 CEST] <klaxa> is it anime?
[22:30:14 CEST] <Dark-knight> idk what 10bit means
[22:30:21 CEST] <Dark-knight> maybe
[22:30:27 CEST] <alexp> 8-bit equals 256 stops per color channel
[22:30:35 CEST] <alexp> 10-bit is 1024 stops I believe
[22:30:40 CEST] <Dark-knight> ah
[22:30:48 CEST] <Dark-knight> so 10bit is always better
[22:30:50 CEST] <alexp> so you have the benefit of getting more accurate colors and more smooth gradation
[22:31:06 CEST] <alexp> not to compatibility. 8-bit is always a safer bet if you want compatibility
[22:31:27 CEST] <alexp> but 10-bit is a fairly big improvement for very little (if any) difference in file size for H.264
[22:31:50 CEST] <Dark-knight> cool
[22:32:10 CEST] <alexp> i don't think Windows Media Player will play 10-bit H.264 videos on my Win7 machine, fwiw
[22:32:11 CEST] <Dark-knight> so you're saying 8bit so more likely to work on media players and consoles?
[22:32:16 CEST] <alexp> yeah, certainly
[22:32:29 CEST] <alexp> 10-bit support is going to be somewhat rare
[22:32:34 CEST] <Dark-knight> but its wouldn't hurt to try 10bit right?
[22:32:40 CEST] <Dark-knight> it*
[22:32:57 CEST] <alexp> are you trying to distribute it, or is there only one hardware or software player that you're going to use and can test for compatibility?
[22:33:06 CEST] <alexp> that should determine your answer
[22:33:09 CEST] <Dark-knight> why is it rare, if you mind me asking?
[22:33:31 CEST] <alexp> all distribution formats up until UHD Blu-ray have been 8-bit
[22:33:41 CEST] <alexp> including all digital TV, all DVD, all Blu-ray
[22:33:48 CEST] <alexp> all internet video
[22:33:49 CEST] <alexp> etc
[22:33:57 CEST] <alexp> so the hardware has never needed to support it
[22:34:00 CEST] <alexp> nor has the software
[22:34:26 CEST] <alexp> it's historically just been used for high end filming, high end video editing, etc
[22:34:37 CEST] <Dark-knight> so blueray players and computers are the only things that can play 10bit so far?
[22:34:39 CEST] <Cracki_> (ffmpeg and vlc of course can work with it)
[22:34:41 CEST] <alexp> but now it happens to be part of the "HDR" spec
[22:35:17 CEST] <Dark-knight> well that helps me chose which file I use.
[22:35:22 CEST] <alexp> Dark-knight - not regularly Blu-ray. UHD (4K) Blu-ray players
[22:35:28 CEST] <Dark-knight> oh
[22:35:45 CEST] <Dark-knight> well then, I'll choose this file https://pastebin.com/QYM65mUt
[22:35:59 CEST] <Dark-knight> can it be converted into .mp4 with no problem?
[22:36:16 CEST] <alexp> yes, you don't need to re-encode
[22:36:24 CEST] <alexp> just stream copy
[22:36:35 CEST] <alexp> both the video and audio streams in that file are MPEG-4 container compliant
[22:37:00 CEST] <alexp> ffmpeg -i [inputfile.mkv] -c copy [outputfile.mp4]
[23:24:55 CEST] <feistyFrank> Anyone familiar with compiling ffmpeg for android?
[23:27:24 CEST] <JEEB> lol
[00:00:00 CEST] --- Thu Aug  3 2017