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

[burek]

[00:10:32 CET] <cc___> debianuser: hi, here is the info : http://www.alsa-project.org/db/?f=507bc288afcf74ccdcde5910fa4fc27f51de327d
[00:11:29 CET] <cc___> do not mind the current asoundrc config because I reverted it back to proper mixing and there's a lot of unused slaves now
[01:29:24 CET] <SortaCore> soo
[01:29:31 CET] <SortaCore> how do I invoke D3D11VA on Windows?
[01:37:34 CET] <SortaCore> it's saying h264_vaapi encoder is missing when I just make'd it
[01:41:58 CET] <lagzilla> In my ffserver config I have AudioCodec mp3 which returns error ffserveraudio.cfg:14: Invalid codec name: 'mp3'. ffserver -codecs returns DEA.L. mp3                  MP3 (MPEG audio layer 3) (decoders: mp3 mp3float ) (encoders: libmp3lame ). So I'm not sure why it's not working.
[01:44:12 CET] <dreamy> Good evening everyone, is it possible to set a explicitly start_pts value using ffmpeg? (I tried setpts and
[01:44:19 CET] <dreamy> I couldn't make it)
[01:45:53 CET] <debianuser> cc___: (if you ever return) To duplicate the output to both internal "SB" card and virtual "Loopback" card you need a config like this: https://pastebin.com/rjyRPBEk  -- it uses a typical route+multi chain to duplicate the sound to dmix:SB and dmix:Loopback. Then you can capture it from "nowplaying" pcm (an alias to "plug:\"dsnoop:Loopback,1\"")
[01:54:01 CET] <debianuser> atomnuker, furq: Thank you for your hints! r=5 made nlmeans 7 times faster. But... I can't make it as good as hqdn3d. Nlmeans blurs the image, but keeps the noise. :( Even with `nlmeans=s=30:r=15` the image is much more blurry but still noisy compared to `hqdn3d=15`: https://drive.google.com/open?id=1FXt1i5He77EMYtd7e8kXcmzdTcoBK84C
[01:54:04 CET] <debianuser> Are my nlmeans params wrong? Or is hqdn3d actually better? Or is ffmpeg's nlmeans filter broken?
[02:07:00 CET] <dreamy> JEEB: did you see my attempt to write a newbie tutorial for libav https://github.com/leandromoreira/ffmpeg-libav-tutorial#learn-ffmpeg-libav-the-hard-way ? Any feedback is welcome! :)
[03:33:23 CET] <drathir> and the report of subtitles is Stream #0:4(eng): Subtitle: dvd_subtitle (mp4s / 0x7334706D), 720x576, 2 kb/s (default) converting to srt give error Error while opening encoder for output stream #0:4 - maybe incorrect parameters such as bit_rate, rate, width or height mappinhg Stream #0:4 -> #0:4 (dvd_subtitle (dvdsub) -> subrip (srt))
[05:00:31 CET] <SortaCore> how do I invoke D3D11VA on Windows? it's saying h264_vaapi encoder is missing when I just make'd it
[05:00:45 CET] <SortaCore> static linking, C++, if that helps
[08:00:23 CET] <fella> hi, i tried to capture from a rather unstable connection using this commandline; 'i=1; while true; do ffmpeg -i http://INPUT.URI -c:v libx264 -crf 24 -preset fast -t 02:00:00.00 /PATH/TO/OUTFILE_${i}.mp4; $((i++)); done' <- to my understanding this should record my INPUT forever and put it into chunks not longer than 2hrs, but after half a day i ended up with 2 chunks ( OUTFILE_1.mp4 and OUTFILE_2.mp4 )
[08:00:29 CET] <fella> each around 40min. When i try it now, stream is available. What could have stoped ffmpeg there, and even more important - is there a way to ensure ffmpeg isn't halted?
[08:02:22 CET] <fella> btw, echo $i said '2', when i forced ffmpeg to exit with ^-C
[08:31:01 CET] <kwand> Hello.
[08:31:01 CET] <kwand> I try to transcode the stream using ffmpeg with vaapi (intel qsv).
[08:31:01 CET] <kwand> My version https://pastebin.com/raw/8AvBig6Y
[08:31:01 CET] <kwand> When I try to set profile "main" or "baseline" for h264_vaapi encoder, I get 'Unable to parse option value "main"' - https://pastebin.com/raw/igeJmvSN
[08:31:01 CET] <kwand> I found on https://trac.ffmpeg.org/wiki/Hardware/VAAPI , that "-profile 578" is "constrained baseline profile". I can't find documentation with number values for other profiles (main, high, etc.).
[08:31:01 CET] <kwand> Values from https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles (66, 88) aren't recognizes by h264_vaapi encoder too, but the value "100" (High) is working.
[08:31:02 CET] <kwand> Where are numeric values for h264_vaapi profiles can be found?
[08:40:52 CET] <furq> kwand: https://www.ffmpeg.org/doxygen/2.4/libavcodec_2avcodec_8h_source.html#l02852
[08:41:17 CET] <furq> also constrained baseline is baseline for all intents and purposes
[09:19:06 CET] <kwand> furq: Thank you, but the value "66", which is "FF_PROFILE_H264_BASELINE" give me the error "Encoding profile not found (5)."
[09:19:06 CET] <kwand> https://pastebin.com/raw/dbnbHrZ3
[09:19:06 CET] <kwand> And I don't find the value "578" which is used in https://trac.ffmpeg.org/wiki/Hardware/VAAPI
[09:19:46 CET] <furq> 578 is constrained baseline
[09:20:05 CET] <furq> normally when you see baseline, it means constrained baseline
[09:21:54 CET] <kwand> furq: Can you show me, where are you see, that "578 is constrained baseline" ?
[09:24:18 CET] <furq> kwand: http://codepad.org/Ce65vRBn
[09:28:21 CET] <kwand> furq: I don't know C, but I have understood, that 578 is "some calculated value". Thank you.
[09:28:44 CET] <furq> 66 | (1 << 9) is 578
[09:29:01 CET] <furq> but yeah most things don't actually support baseline
[09:29:21 CET] <furq> constrained baseline is a subset of baseline with some error correction features removed
[09:30:27 CET] <furq> a CBP stream is still a valid BP stream, so the term gets used interchangeably
[09:37:39 CET] <kwand> furq: When you said "but yeah most things don't actually support baseline", do you mean that most things don't actually support baseline, but support CBP ?
[09:38:52 CET] <DHE> they actually support constrained, but don't support the "enhanced" (relatively speaking) baseline
[09:50:33 CET] <kwand> As I understarnd, ffmpeg profile "baseline" for h264 encoder is really "constrained baseline", isn't it ?
[09:50:34 CET] <kwand> If I'm right, does exist any ffmpeg profile for h264 encoder, which is real "baseline" (without "constrained") ?
[09:52:50 CET] <furq> i'm not aware of any h264 encoder in ffmpeg that will encode non-constrained baseline
[09:53:16 CET] <furq> i don't think x264 does, and that's obviously the big one
[09:53:59 CET] <furq> decoders i'm less sure about, but anything that supports baseline automatically supports CBP
[13:44:41 CET] <sam73> Hello, I am trying to convert m2ts file to anything usable more widely such as mkv. But it seems the original file lacks some settings and I could not do it.
[13:44:47 CET] <sam73> ffmpeg-3.4-64bit-static/ffmpeg -i pad.m2ts -codec copy -map 0:0 -map 0:1  pad.mkv
[13:45:07 CET] <sam73> ffmpeg version 3.4-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2017 the FFmpeg developers   built with gcc 6.4.0 (Debian 6.4.0-7) 20170920   configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc-6 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gray --enable-libfribidi --enable-libass --enable-libvmaf --enable-li
[13:45:18 CET] <sam73> arg, too big to post.
[13:46:04 CET] <sam73> yup : https://pastebin.com/HFNc2hzF
[13:49:27 CET] <Nacht> And if you try MP4 ?
[13:50:55 CET] <sfan5> >Consider increasing the value for the 'analyzeduration' and 'probesize' options
[13:50:57 CET] <sfan5> try doing exactly that
[13:52:37 CET] <sam73> I tried, no result : https://pastebin.com/ZVMWPhqa
[13:53:45 CET] <sfan5> hm
[13:53:57 CET] <sfan5> is your m2ts even playable at all? have you tried using mkvmerge?
[13:54:20 CET] <Nacht> Im suprised the audio and video have no channels
[13:54:41 CET] <sam73> mkvmerge does not get correct result, I can play the m2ts on tvset using the recording box (freebox), but not on the computer
[13:55:00 CET] <sfan5> but can you play the m2ts on ANY desktop application?
[13:55:08 CET] <sam73> nope
[13:55:12 CET] <sam73> avidemux no
[13:55:14 CET] <sam73> openshot no
[13:55:20 CET] <sam73> vlc no
[13:55:22 CET] <sfan5> is it encrypted by any chance? i know that sony TVs do this
[13:55:40 CET] <sam73> probably not, it recorder from freebox
[13:55:51 CET] <sam73> which is quite open on many sides
[13:57:35 CET] <Nacht> How big is it, exactly  ?
[13:57:40 CET] <Nacht> in bytes
[13:58:28 CET] <sam73> 1830425664
[13:59:35 CET] <Nacht> Hmm, seems devidable by 192
[14:00:05 CET] <sam73> is it good doctor ?
[14:00:54 CET] <sfan5> it might be that just this m2ts file is damages, I suggest doing a fresh recording and checking if that works
[14:01:04 CET] <sfan5> damaged*
[14:01:31 CET] <sam73> I will plug back the usb key to the box and check it can play. It was a tv recording so...
[14:01:35 CET] <sam73> I get back in few minutes
[14:01:37 CET] <sam73> after test
[14:04:34 CET] <Nacht> I'm reading things here that the TS files get encrypted. Common Scramble Algo
[14:04:48 CET] <Nacht> But it's all in french, so I'm reading half of it
[14:06:55 CET] <sam73> the box could not read the file anymore
[14:07:05 CET] <sam73> i made a new record of a few seconds
[14:07:10 CET] <sam73> checking again
[14:08:35 CET] <sam73> same issue with the fresh record
[14:09:31 CET] <sfan5> your device is doing something unusal to the recordings
[14:10:37 CET] <sam73> it is an internet box, which is also doing tv by @
[14:10:49 CET] <sam73> it allows to behave as recorder
[14:11:02 CET] <sam73> seems to record flux
[14:11:23 CET] <sam73> without specs on the flux itself
[14:11:33 CET] <sfan5> it wouldn't surprise me if this was intended to prevent customers from accessing the recording in other ways
[14:11:56 CET] <sam73> it is not their style, but possible
[14:12:16 CET] <Nacht> http://www.lacelluledusat.tv/showthread.php?4855-Etude-du-proc%E9d%E9-cryptage-DRM-sur-Freebox-Revolution-Bouquet-CANALSAT
[14:12:46 CET] <Nacht> I can read only half of it using Google Translate, but perhaps it explains a few things ?
[14:12:59 CET] <sam73> reading
[14:14:41 CET] <sam73> seems they encrypt...
[14:31:29 CET] <__jack__> yes, however, cannot you download that file via the web interface ?
[14:32:22 CET] <__jack__> it may depends on the channel, some won't be fetched any way
[14:34:48 CET] <sam73> I made a new record using the web interface, it does not show from the web and is not downloadble
[14:35:00 CET] <sam73> they encrypt this channel (public tv...)
[14:38:40 CET] <__jack__> which channel is this ?
[14:38:41 CET] <__jack__> tf1 ?
[14:44:12 CET] <sam73> yes tf1
[14:44:22 CET] <sam73> it is definitly encrypted and so unusable
[14:44:45 CET] <sam73> I do not have a tnt decoder here, probably will have next year. It seems they do not encrypt from tnt
[14:45:16 CET] <sam73> I will look after a screen recorder as you can use the webapp to see tv, I should be able to record from pc...
[14:46:32 CET] <sfan5> if there's a webapp you can use for watching there should be an easier way to capture the stream instead
[14:48:10 CET] <sam73> lol
[14:48:24 CET] <sam73> they refuse to cast the same channel they encrypt in the webapp
[14:48:37 CET] <sam73> at least I know wich channel will be recordable now :)
[14:59:22 CET] <sam73> thanks for the help, I would have searched hours without noticing is was encrypted. I still not see how to guess it from the ffmpeg output.
[15:27:02 CET] <nich-aus> Hello all
[15:28:14 CET] <nich-aus> I'm not sure if this is the best place, but I am trying to hard burn subs, and crop video at the same time. However cropping changes the position of the subtitles, which is expected I guess. Is there a command that allows cropping without changing location of hard burned subs?
[15:28:43 CET] <sfan5> how does your command look currently?
[15:29:10 CET] <kepstin> hmm. you want to do something like move normal subtitles into the cropped video area, but make sure positioned subtitles line up with the video?
[15:29:28 CET] <kepstin> i don't see any way to do that without splitting the subtitles into two tracks
[15:29:57 CET] <nich-aus> I will check, one moment. Thanks all
[15:29:58 CET] <kepstin> so you'd have one track with the positioned subs, burn it in, crop, then burn in the second track with the unpositioned subs.
[15:32:48 CET] <nich-aus> I'm using iFFmpeg, so sorry if this is too verbose
[15:33:00 CET] <nich-aus> https://pastebin.com/3bjaSpsH
[15:34:02 CET] <nich-aus> The video has black bars at top and bottom, so the subtitles have a vertical position to be over the video, instead of the black bars which should be cropped.
[15:34:42 CET] <sfan5> yeah you'll want the subtitle filter first and then crop
[15:34:43 CET] <kepstin> oh, if the subtitles are already in the right spot, just change the order of the filters - put the 'subtitles' filter before the crop.
[15:35:18 CET] <nich-aus> That's a great and now obvious top kepstin, thank you!
[15:35:28 CET] <nich-aus> *tip Thank you again.
[15:35:52 CET] <kepstin> and sfan5 who typed it a little faster than me ;)
[15:36:21 CET] <nich-aus> Thanks sfan5 :)
[15:37:11 CET] <sfan5> another tip: if you're using a gui frontend to do something chances are it will do anything beyond simple things wrong
[15:37:53 CET] <nich-aus> Very wise sfan5. I'll be careful moving the command from the guy front end to terminal.
[15:38:04 CET] <nich-aus> *giu. I can't type tonight.
[15:50:21 CET] <corrideat> Hello. I have a video and Im trying to create different DASH variants. This seems to work for WebM, but it fails for the MP4 container, which I need for H.264 and AAC.
[15:51:23 CET] <corrideat> Could it be that Im issuing the wrong command for generating the DASH file? The error I get is: «EBML header parsing failed»
[15:51:38 CET] <corrideat> And this is the full log, including the commands issued: https://pastebin.com/y2qN6gP5
[15:55:32 CET] <ritsuka>  I guess the webm_dash_manifest option is only for webm, maybe there is another one for mp4
[16:01:49 CET] <corrideat> ritsuka: thatd a good point, thanks. I couldnt find a non-WebM manifest option
[16:02:02 CET] <sfan5> corrideat: remove the first "-f webm_dash_manifest"
[16:02:13 CET] <sfan5> it tells ffmpeg to read your input (a mp4) as a webm manifest which is nonsense
[16:06:44 CET] <corrideat> If I remove both of them, I get «Unable to find a suitable output format for 'test_a.mpd» and if I remove only the first one (for the input), I get «Could not write header for output file #0 (incorrect codec parameters ?): Invalid data found when processing input»
[16:07:52 CET] <sfan5> the latter error is what you should look to solve
[16:19:49 CET] <corrideat> Well, it seems like if I use -f dash instead of webm_dash_manifest it works, but then the file is split into chunks
[16:33:20 CET] <corrideat> Not the ideal solution, but at least I have some manifest.
[16:34:06 CET] <corrideat> Thanks
[17:33:12 CET] <SortaCore> I asked that d3d question here twice yesterday :p
[17:33:18 CET] <JEEB> too bad :P
[17:33:26 CET] <SortaCore> what's the usual count
[17:33:29 CET] <JEEB> not everyone can be fucking at the keyboard 24/7
[17:33:44 CET] <SortaCore> I hope not, that's a lot of sweat to clean up
[17:33:45 CET] <JEEB> or watching this channel
[17:33:49 CET] <JEEB> perkele
[17:35:07 CET] <SortaCore> yea, but isn't that the point of a chat, being able to quickly read up on history
[17:35:37 CET] <SortaCore> but I digress
[17:36:16 CET] <SortaCore> so, I need to process X times, the receive frame and so on, then resume main thread, how do I know the X
[20:35:38 CET] <Protected> Hi there. I'm using ffmpeg 3.4 through node.js and fluent-ffmpeg. I'm trying to convert some audio to mp3 and using a seek parameter which, as far as I can tell, converts directly to -ss. For certain files, when this -ss is present, ffmpeg will error out with the following message(s): "Error reinitializing filters! Failed to inject frame into filter network: Invalid argument ; Error while
[20:35:38 CET] <Protected> processing the decoded data for stream #0:0"
[20:35:46 CET] <Protected> If I convert without seeking, everything works fine
[20:36:18 CET] <Protected> Could anyone give me any pointers to help me figure out why exactly this happens, or just to help me work towards fixing it?
[20:36:49 CET] <JEEB> move -ss to after -i if you want to be exact and not get issues, esp. with things without an index like raw mpeg-1 layer 3 audio
[20:37:30 CET] <Protected> Thank you. Let me look at fluent's source code again
[20:38:25 CET] <alexpigment> my understanding is -ss before input allows you to copy without re-encoding, but -ss after input requires re-encoding
[20:38:28 CET] <alexpigment> right?
[20:39:43 CET] <JEEB> the difference is that before -ss seeks with avformat
[20:39:45 CET] <JEEB> and then tries to decode
[20:40:04 CET] <JEEB> after-ss just decodes until that point and then passes it into the framework
[20:40:21 CET] <JEEB> so before-ss can fsck things up with things that you cannot effectively seek in without an index
[20:40:23 CET] <alexpigment> ok, so that's why -ss before input would fail if timestamps aren't included in the container
[20:40:26 CET] <alexpigment> right
[20:40:50 CET] <JEEB> I made a test app once and tried to seek in an MPEG-TS. hilarious stuff ensued
[20:42:23 CET] <alexpigment> out of curiosity, was it MPEG-TS that was muxed with ffmpeg?
[20:42:35 CET] <alexpigment> because that's a half-assed implementation if there ever was one ;)
[20:43:06 CET] <alexpigment> i have to use Tsmuxer every time, otherwise I get a file that is either non-compliant for standards or just doesn't play right in various players
[20:43:23 CET] <JEEB> no, it was some broadcast stuff. and believe me I don't think lavf's is worst. but yes, it's not abiding to specs
[20:43:28 CET] <JEEB> as in, broadcast ones
[20:43:30 CET] <alexpigment> ah
[20:43:41 CET] <JEEB> it's good enough for stuff like HLS
[20:43:59 CET] <alexpigment> yeah, HLS is certainly not as demanding
[20:55:05 CET] <raytiley_> JEEB: are you aware of any examples of using NUT with a named pipe that I could use as a staring point?
[21:00:53 CET] <debianuser> Hello. I'm trying "nlmeans" filter instead of hqdn3d, and can't make it as smooth as hqdn3d is. It blurs the image, but keeps the noise. :( Even `nlmeans=s=30:r=15` is blurry and noisy compared to `hqdn3d=15`. 27sec test video: https://drive.google.com/open?id=1FXt1i5He77EMYtd7e8kXcmzdTcoBK84C Are my nlmeans params wrong? Or is hqdn3d actually better? Or is ffmpeg's nlmeans filter broken?
[21:06:41 CET] <johnjay> why on debian buster is ffmpeg development files called libavcodec-dev and not libffmpeg-dev?
[21:06:51 CET] <johnjay> oh hello there fellow debian user
[21:10:16 CET] <debianuser> johnjay: Yeah, according to http://http.debian.net/debian/pool/main/f/ffmpeg/ffmpeg_3.4-2.dsc the -dev packages built are: libavcodec-dev, libavdevice-dev, libavfilter-dev, libavformat-dev, libavresample-dev, libavutil-dev, libpostproc-dev, libswresample-dev, libswscale-dev
[21:11:03 CET] <johnjay> oh ok. normaally the pattern is <program> and lib<program>-dev
[21:11:18 CET] <johnjay> i thought for a second it was the defunct libav project
[21:13:46 CET] <JEEB> johnjay: there is no libffmpeg
[21:13:49 CET] <JEEB> that's why
[21:14:00 CET] <JEEB> FFmpeg consists of multiple libraries
[21:14:09 CET] <JEEB> avformat for reading/writing and demuxing/muxing
[21:14:15 CET] <JEEB> avcodec for decoding/encoding
[21:14:20 CET] <JEEB> avfilter for filtering a/v
[21:14:34 CET] <JEEB> (sw|av)resample for audio resampling
[21:14:42 CET] <JEEB> (which is used by avfilter filters)
[21:28:32 CET] <debianuser> raytiley_: A long time ago someone (Cloudef) asked here for a simple container to pass video/audio from his opengl+alsa capturing tool to ffmpeg. He ended up writing his own raw format and "rawmuxdec" patch for ffmpeg: https://github.com/Cloudef/glcapture/blob/master/glcapture.c Maybe you can use that too? ;)
[21:41:59 CET] <johnjay> what is sw vs av?
[21:42:12 CET] <Protected> JEEB: Unfortunately, after modifying the library to put -ss after -i, I'm still getting the same error :(
[21:42:16 CET] <johnjay> as in software vs hardware?
[22:02:42 CET] <ferz> Hi
[22:04:22 CET] <ferz> What does it mean "an output option" in https://trac.ffmpeg.org/wiki/Encode/H.264#faststart ?
[22:05:51 CET] <Nacht> ffmpeg has input and output options, bepending on how you format your command
[22:06:07 CET] <Nacht> ffmpeg <input options> -i input <output options> output
[22:06:39 CET] <ferz> Nacht: thank you
[22:07:10 CET] <Nacht> np
[22:27:12 CET] <raytiley_> debianuser: thanks
[22:55:27 CET] <DocHopper> Hey ffmpeg folks, I was just wondering if there was a way to suggest adding some information on -muxrate to the ffmpeg documentation.
[22:58:27 CET] <c_14> Write a patch and send it to the mailing list.
[22:58:40 CET] <kepstin> The documentation is all in git along with the source code, so it's basically the same process as development
[22:59:08 CET] <DocHopper> c_14 & kepstin:  Okay, I just have to figure out how to do that now!
[22:59:23 CET] <DocHopper> -muxrate is required for my application and it was tricky to find any info on it.
[23:00:24 CET] <c_14> https://ffmpeg.org/developer.html#Submitting-patches
[23:00:42 CET] <c_14> don't worry about the regression tests bits though
[23:00:52 CET] <kepstin> hmm, it's mentioned in https://www.ffmpeg.org/ffmpeg-formats.html#mpegts-1 but without any details
[23:01:01 CET] <c_14> (though do test a `make doc' or something)
[23:04:12 CET] <DocHopper> kepstin: I'm embarrassed, somehow I missed that documentation.  While it could be far more helpful, I wouldn't know hot to improve what's there.
[23:49:13 CET] <ppw> hello good folk of ffmpeg.
[23:49:35 CET] <ppw> just transcoding my oversized iPhone videos to something more manageable ...
[23:49:52 CET] <ppw> is HEVC + HE-AACv2 a good combo for the resulting file?
[23:50:13 CET] <BtbN> HE-AAC is for very low bitrate content
[23:50:25 CET] <BtbN> And you are probably better of with h264 still
[23:50:25 CET] <ppw> true, but then again, there's only speech and noise
[23:50:41 CET] <ppw> why h264 over h265? the size difference is noticeable
[23:50:44 CET] <BtbN> Just use normal 128kbps aac and you're good
[23:51:05 CET] <ppw> again, a noticeable size difference. would you care to elaborate?
[23:51:15 CET] <BtbN> noticable size difference?
[23:51:20 CET] <ppw> indeed.
[23:51:36 CET] <BtbN> 128kbps is entirely insignifficant compared to whatever video you intend to store next to it
[23:52:06 CET] <ppw> ok.
[23:52:08 CET] <ppw> true
[23:52:12 CET] <BtbN> h264 has higher compatiblity, lower resource usage, and libx264 is still just so good that it's barely worth it
[23:52:37 CET] <furq> if these are 1080p videos then prepare for encoding at 3fps if you want libx265 to actually do better than libx264
[23:52:46 CET] <ppw> 3fps? or 30?
[23:52:48 CET] <furq> 3
[23:52:51 CET] <CoReX> pointless to use x265 right now i find unless you like the long encode times depending on how long the file is
[23:53:13 CET] <BtbN> Unless you are aiming for 4K stuff, I wouldn't even think about using HEVC
[23:53:16 CET] <ppw> oh, the transcoding's already been done, it was pretty fast.
[23:53:29 CET] <ppw> I've used hevc for 720p, 1080p and 4K, at 30 and 60fps
[23:53:56 CET] <furq> yeah if you used a fast x265 preset then it probably won't have been more efficient than x264 would have been at the same speed
[23:54:07 CET] <ppw> it was --preset medum
[23:54:08 CET] <ppw> medium
[23:54:27 CET] <furq> last time i saw benchmarks that was roughly as good as x264 veryslow
[23:54:42 CET] <furq> maybe x265 got better since then though
[23:54:48 CET] <ppw> in terms of encoding speed or resulting file size and quality?
[23:54:51 CET] <furq> both
[23:55:18 CET] <furq> the main difference being that hevc is harder to decode
[23:55:36 CET] <ppw> that's .. not very informative
[23:55:49 CET] <ppw> I mean, what kind of device do you plan on playing the video anyway?
[23:55:53 CET] <CoReX> i encoded something the other week with x264 and x265 and the file size was only about 10mb ended up keeping the x264
[23:56:07 CET] <ppw> really? well I'll give h.264 + aac-lc at 128kbps a shot and note the difference.
[23:57:46 CET] <alexpigment> x265 isn't worth it unless you need it to maintain a standard (e.g. Ultra HD Blu-ray). otherwise, you're trading a small amount of file size savings for device incompatibility and slower encode speeds
[23:58:30 CET] <alexpigment> i guess it's also possible that if you're on a very tight bit budget for 4K content (e.g. video delivery service), then it might be worth using
[23:59:46 CET] <JEEB> I should do new tests for x265 :/ not that I expect them to have gotten much better but to see if it's worth it anywhere else than in the low bit rate scenario (where all alternatives will have artifacts)
[00:00:00 CET] --- Thu Nov 16 2017