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

[burek]

[00:05:50 CEST] <norbert> hi folks, which "-crf" value should I pick to get a result close to what YouTube provides (at HD) ?
[00:06:59 CEST] <norbert> I started off with 28, but decided the quality wasn't good enough, so I went to 25, but this still seems problematic
[00:07:38 CEST] <norbert> and I'm a bit scared that if I go really low the resulting files will be huge and take up way too much disk space
[00:20:40 CEST] <furq> 25 should be plenty if you're just aiming to match youtube
[00:20:54 CEST] <norbert> really?
[00:21:11 CEST] <furq> youtube 1080p30 is always ~3.5mbit
[00:21:15 CEST] <furq> which is not really very good
[00:21:51 CEST] <furq> obviously i wouldn't actually recommend 25 for archival but it'll look about as good as youtube 1080p
[00:22:49 CEST] <furq> i normally use 20 or 21 for hd but it's really just something you need to experiment with and find a value that works for you
[00:22:54 CEST] <furq> encode a short test clip or something
[00:23:46 CEST] <furq> also keep all the other settings the same because those will affect pq even at the same crf value
[00:37:57 CEST] <friendofafriend> I've got a bunch of silent h264 videos, and I want to cut the framerate in half without reencoding to save space.  What's the proper command to use?
[00:38:19 CEST] <DHE> doing so doubles the duration
[00:38:37 CEST] <DHE> and doesn't save space
[00:39:27 CEST] <DHE> "don't reencode" and "save space" is only possible by "cutting"
[00:39:56 CEST] <friendofafriend> Sorry, so I'm after dropping every other frame.
[00:40:15 CEST] <friendofafriend> Say, from 24fps to 12fps.
[00:40:31 CEST] <DHE> that will break playback
[00:40:39 CEST] <DHE> reencoding is required
[00:41:37 CEST] <friendofafriend> That would break playback even in ffplay?
[00:41:52 CEST] <DHE> you can't just skip every other frame and get a video to play correctly
[00:42:11 CEST] <DHE> unless it's an intra codec or in intra mode (aka. every frame is a keyframe)
[00:42:19 CEST] <DHE> in which case I have suggestions to improve size
[00:42:32 CEST] <friendofafriend> Oh, I'd be losing keyframes.  I think I understand.
[00:43:35 CEST] <BtbN> Every frame is used as reference
[00:43:38 CEST] <DHE> that's not what I said
[00:43:45 CEST] <BtbN> You can't just randomly get rid of some
[00:44:01 CEST] <DHE> I said the "drop every other frame" trick only works if every frame in the video is a keyframe. (or I suppose gopsize=2)
[00:44:24 CEST] <cehoyos> Or if every other frame is a non-ref frame...
[00:44:31 CEST] <cehoyos> Like B-frames often are
[00:46:10 CEST] <friendofafriend> Aw heck, oh well.  I've got a board around here that does h265 encoding by OpenMAX, I guess I'll just feed these files into it.
[00:46:22 CEST] <furq> that's definitely not going to save space
[00:46:43 CEST] <furq> not without murdering the quality anyway
[00:46:43 CEST] <friendofafriend> No?  Why not?
[00:46:53 CEST] <friendofafriend> Right, quality murder.
[00:47:01 CEST] <friendofafriend> But I'm going to end up doing that with a reencode anyway.
[00:48:03 CEST] <furq> if it's openmax then i assume it's some kind of sbc
[00:48:09 CEST] <furq> the hardware encoders on those are usually terrile
[00:48:10 CEST] <furq> b
[00:48:20 CEST] <friendofafriend> It's one of these Jetson Nano boards.
[00:48:22 CEST] <furq> at least all the ones i've used are
[00:49:03 CEST] <furq> oh, nvidia
[00:49:09 CEST] <furq> maybe that won't suck quite so badly then
[00:49:37 CEST] <furq> with that said even nvenc hevc is worse than a decent x264 encode
[00:49:53 CEST] <furq> and that's the best consumer-grade hardware encoder afaik
[00:50:02 CEST] <BtbN> Can't you use nvenc on those? Why OMX?
[00:50:27 CEST] <BtbN> nvenc hevc beats libx264 btw.
[00:50:40 CEST] <BtbN> (On Turing)
[00:51:08 CEST] <furq> x264 veryslow?
[00:51:33 CEST] <friendofafriend> Nah, there's no NVENC on those Jetson boards.
[00:51:34 CEST] <furq> i'll be impressed if it does
[00:51:50 CEST] <BtbN> their h264 encoder can compete with x264 veryfast
[00:52:03 CEST] <BtbN> hevc is quite a bit better
[00:52:42 CEST] <friendofafriend> Unfortunately, there's only support for gstreamer with NVIDIA's OpenMAX stuff.
[00:53:01 CEST] <BtbN> Can't install the normal nvidia driver on it?
[00:53:22 CEST] <friendofafriend> Oh not at all.  There's no GPU on the PCI bus.
[00:54:13 CEST] <furq> i would guess it's some nvenc asic if it's an nvidia gpu
[00:54:18 CEST] <furq> just a different api
[00:54:28 CEST] <friendofafriend> It's device entries for CUDA, and a prebuilt static library for OMX GStreamer support.  They don't supply the headers to build it from source.
[00:54:49 CEST] <furq> does it work with ffmpeg's omx stuff
[00:55:16 CEST] <friendofafriend> Unfortunately not.  I did coax ffmpeg into using OMX on the Raspberry Pi, and was pretty happy overall.
[00:55:17 CEST] <BtbN> really makes me wonder why they bothered to implement yet another API just for that board
[00:55:48 CEST] <friendofafriend> I was hot to use it for hardware encoding video by NVENC with xpra, and ended up disappointed.
[00:56:00 CEST] <furq> i guess compat with tools that people use on other sbcs
[00:56:07 CEST] <furq> those great tools that everyone loves
[00:57:50 CEST] <friendofafriend> There's a slot for an M.2 wireless card, so I guess you could put a graphics card onto the bus if x1 was acceptable.
[01:02:24 CEST] <friendofafriend> You guys saved me lots of time.  Thank you.
[02:29:18 CEST] <dastan> michaelni, are you online?
[04:45:15 CEST] <microcolonel> howdy
[04:46:30 CEST] <microcolonel> I have some footage that was deinterlaced poorly (I think just by combining the fields as 30p instead of 60i), is there a filter in ffmpeg for reversing that (restoring the alternating fields to 60i)?
[05:05:10 CEST] <furq> microcolonel: not in ffmpeg, but qtgmc will do it
[05:07:20 CEST] <furq> i guess you could also try separatefields if you want 60i output
[08:46:58 CEST] <lain98> i have a crude understanding of how video works. my application is extracting streams from a video file and then sending them to decode. is there a way i could alter rates in the stream such that when i decode, i decode at a different fps than the the one with which the video was encoded.
[08:47:56 CEST] <lain98> i'm using the libraries
[12:24:56 CEST] <DHE> lain98: not sure I understand the problem. decoding is largely independent of the framerate as long as you're receiving the data fast enough (ie. on disk you can read as fast as the hard drive can offer it). it's on the player to show each frame for the intended duration. you're welcome to mess with it yourself.
[12:34:30 CEST] <lain98> DHE: i imagine there is data in the stream that tells us when the present what frame ?
[12:34:38 CEST] <lain98> *to
[12:36:10 CEST] <lain98> i can see that in AVStream structure, theres time_base and duration and avg_frame_rate
[12:47:19 CEST] <DHE> time_base is the units that the pts values in AVPackets are in. If the value of time_base is {1,30} and the pts values go 1,2,3,4,5 then it's basically 30fps material
[12:47:59 CEST] <DHE> but some file formats might use a fixed time_base. eg: mpegts uses a fixed 90,000 value and at 30fps you would see the pts go 3000, 6000, 9000, etc.
[12:54:05 CEST] <lain98> DHE: is it possible to have a 30 fps video and rewrite the pts values, so that it might get 60 frames instead of 30 frames say if the video was only 1 second long
[12:54:30 CEST] <lain98> sorry if the question is dumb
[12:55:26 CEST] <lain98> so the frames might be duplicated when i decode
[12:56:13 CEST] <DHE> if you want the decoder to actually get duplicate frames, you will need to reencode in order to produce noop frames for the decoder
[12:57:31 CEST] <lain98> so essentially not possible before i transcode beforehand
[12:58:40 CEST] <lain98> you cant interpret a 30 fps video as a 60 fps video and produce more frames than encoded
[12:58:46 CEST] <DHE> it'll be on you to tweak the output time_base and the pts values going into the output file, and to feed the encoder the same AVFrame twice in a row with suitable pts values
[12:59:21 CEST] <DHE> some formats may support variable framerate. maybe you can set a time_base of 1/60 but feed pts values of 2,4,6,... don't know if that will report 30fps or 60fps though
[13:05:16 CEST] <lain98> i guess it cant be done after all
[13:06:36 CEST] <lain98> if i make it seem that the frames have timestamps that would be correct if the frame rate was double, no-op frames would be missing
[13:08:12 CEST] <lain98> and thats not even taking into account vfr
[13:19:19 CEST] <lain98> ~
[13:24:40 CEST] <lain98> thanks DHE
[15:43:38 CEST] <microcolonel> furq: it's a real dog's breakfast; terrible artifacts because of the bad deinterlacing, but also because it's been projected onto 720p... from.... 576 fields maybe
[15:44:01 CEST] <microcolonel> (artifacts from the codec struggling to maintain rate with merged fields)
[15:45:12 CEST] <furq> i've had good luck with qtgmc repairing bad deinterlacing but not that bad
[15:45:52 CEST] <furq> i don't know anything else that would give you a chance though
[15:45:52 CEST] <microcolonel> s/fields/lines/
[15:45:57 CEST] <microcolonel> yeah, it's not great
[15:46:15 CEST] <microcolonel> fun to poke at though, I'll probably document it if I managed to get a good result
[15:46:45 CEST] <microcolonel> maybe could roll it into a "reinterlace" filter.
[15:46:54 CEST] <furq> http://avisynth.nl/index.php/QTGMC#Progressive_Input
[15:47:13 CEST] <furq>  These modes drop half the fields and recreate an interlaced stream from the others, which is then treated in the normal way.
[15:47:16 CEST] <furq> doh
[15:47:50 CEST] <microcolonel> hmm
[15:47:52 CEST] <furq> short of trying to resize it back to 576p and crossing your fingers i wouldn't know where to start
[15:52:13 CEST] <microcolonel> yeah, I'm going to try it like this: a) linear vertical-only  resample at 576 lines b) make two sequences with the alternating lines c) smear that across 576 lines again, and maybe blend a bit vertically d) reassemble it into an interlaced sequence both ways, and see if one looks good.
[15:52:59 CEST] <microcolonel> e) finally do the horizontal resample
[15:54:04 CEST] <microcolonel> vish me luck :- )
[17:17:10 CEST] <N4ppeL> hi
[17:17:22 CEST] <N4ppeL> ah. Now I can send messages :)
[17:19:01 CEST] <N4ppeL> so, I am struggling encoding a video from radiospectrometer data into a single-8-bit-channel. I understand there is no real gain in compression using "pure grayscale" over yuv420p, but since its going to be decoded on mobile devices it would be lovely not to have an additional 50% of zeroes in my decoded framebuffers
[17:19:37 CEST] <N4ppeL> is there any way to achieve this? or is the "solution" to just throw away the last 50% of data i get from the encoder..?
[17:20:50 CEST] <N4ppeL> using H.264
[17:20:56 CEST] <DHE> but the decoder will still want that data. and hardware decoders are often limited in the formats they support.
[17:21:59 CEST] <N4ppeL> ah yeah, sorry, I meant to throw away 50% data i get from the decoder (its all just 0 anyway)
[17:22:36 CEST] <furq> 33%
[17:23:35 CEST] <furq> x264 apparently has 4:0:0 support now but it doesn't look like ffmpeg supports it for libx264 yet
[17:23:52 CEST] <furq> but also i don't think hardware decoders would support that anyway
[17:23:55 CEST] <N4ppeL> furq, no. I get 150% of the data i actually need
[17:24:04 CEST] <furq> well yeah 50% of 150% is 33%
[17:24:09 CEST] <furq> or uh
[17:24:10 CEST] <furq> you know what i mean
[17:24:37 CEST] <furq> 8 bytes instead of 12
[17:24:53 CEST] <furq> ...bits
[17:24:55 CEST] <N4ppeL> ah yeah ok i see where you come frome
[17:25:13 CEST] <N4ppeL> hmm
[17:25:32 CEST] <furq> but yeah if you want to actually use mobile hardware decoders then you're probably stuck with 4:2:0
[17:25:36 CEST] <N4ppeL> so currently i am anyway using a sw decoder since on browsers HW decoding is only available through html5-video element which has its own problems
[17:25:55 CEST] <N4ppeL> but i assume 4:0:0 would probably also not be supported (now) by the js-decoder i am using
[17:26:01 CEST] <N4ppeL> if its not even supported by ffmpeg..
[17:26:12 CEST] <furq> it's just the encoder that doesn't support it
[17:26:15 CEST] <furq> i assume the decoder does
[17:26:41 CEST] <furq> but yeah it's not a commonly used feature
[17:27:00 CEST] <N4ppeL> I see
[17:27:05 CEST] <N4ppeL> well thanks
[17:28:01 CEST] <N4ppeL> would of course be nice to see the support somewhere in the future, but for now I guess I will just throw away the unnecessary part after decoding so framebuffers explode a bit less
[17:29:12 CEST] <furq> you could try piping to the x264 cli
[17:29:17 CEST] <furq> --output-csp=i400
[17:29:26 CEST] <furq> i'd be surprised if it decoded though
[17:31:01 CEST] <N4ppeL> there is a pix_fmt "gray" in ffmpeg
[17:31:13 CEST] <N4ppeL> but it gives me deprecation errors '=D
[17:34:39 CEST] <kepstin> presumably warnings, not errors? Might not be related, afaik the gray pixel format isn't deprecated
[17:35:18 CEST] <kepstin> but yeah, the libx264 wrapper on my ffmpeg lists support for gray and gray10le, I have no idea if it actually encodes 4:0:0 video if passed that, tho.
[17:35:34 CEST] <N4ppeL> warnings resulting in an "error when opening encoder"
[17:36:02 CEST] <kepstin> N4ppeL: you're gonna have to post the complete output of ffmpeg, not bits and pieces
[17:37:42 CEST] Action: kepstin takes a quick look at the ffmpeg libx264 wrapper source - yes, gray and gray10le are wired up to use x264's 4:0:0 support, assuming ffmpeg was compiled against a new enough libx264
[17:38:11 CEST] <N4ppeL> command and output are quite large since I am splitting a 4096x4096 into 85 512x512 videos
[17:38:30 CEST] <N4ppeL> maybe i can first try a simpler case.
[17:41:35 CEST] <N4ppeL> hm, the funniest line is (after 85times "deprecated pixel format used, make sure you did set range correctly") it says "No pixel format specified, yuvj444p for H.264 encoding chosen."
[17:42:01 CEST] <kepstin> that comes from the 'j' in the yuvj444p
[17:42:21 CEST] <kepstin> which is a deprecated way of indicating full-range rather than limited
[17:42:36 CEST] <kepstin> (but the replacement isn't finished, so the message is meaningless to end-users, please ignore it)
[17:43:19 CEST] <kepstin> that's not an error, and would not cause the encoder to fail to initialize
[17:43:21 CEST] <N4ppeL> ok, but I DID specify gray as format? and my ffmpeg does list "gray" as a valid format..
[17:43:35 CEST] <kepstin> N4ppeL: i need to see your complete command line to tell you what's gone wrong there
[17:43:43 CEST] <kepstin> probably you used the wrong option or used it in the wrong place
[17:44:26 CEST] <kepstin> note that if you have multiple outputs, you have to repeat all output options (including -pix_fmt) for all of them.
[17:46:10 CEST] <N4ppeL> i do? original command was "ffmpeg -y -framerate 25 -i %d.jp2 -filter_complex "[0]format=yuv420p, split=85[1_00][4_00][4_01] ......." which worked great although only once specified
[17:48:15 CEST] <N4ppeL> full command and outputs here: https://pastebin.com/CniBt1zz
[17:49:14 CEST] <kepstin> N4ppeL: ok, the issue is that you're setting high profile, but high profile doesn't support 4:0:0 sampling
[17:49:25 CEST] <kepstin> iirc you need to use high444 to get 4:0:0 support
[17:49:39 CEST] <N4ppeL> ohh
[17:50:22 CEST] <kepstin> hmm. but that said, there is something going on weird here, it *is* picking a 4:4:4 pix fmt
[17:50:40 CEST] <kepstin> N4ppeL: please check with "ffmpeg -h encoder=libx264" to make sure your x264 lists "gray" support
[17:51:57 CEST] <kepstin> hmm. i might be wrong about that profile req for 4:0:0 actually
[17:52:02 CEST] <N4ppeL> Encoder libx264 [libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10]:
[17:52:08 CEST] <N4ppeL> so here it does not
[17:52:26 CEST] <N4ppeL> ffmpeg -pix_fmts does list it
[17:52:31 CEST] <kepstin> N4ppeL: if 'gray' is not listed in that output, then you need to recompile your ffmpeg against a newer libx264 to get 4:0:0 support
[17:52:47 CEST] <N4ppeL> I see
[17:53:28 CEST] Action: kepstin checks wikipedia, which notes that monogrpme support *is* in the regular "high" profile
[17:53:33 CEST] <kepstin> monochrome*
[17:54:25 CEST] <kepstin> your ffmpeg version is really old too, you probably need a newer ffmpeg *and* a newer libx264
[17:54:37 CEST] <kepstin> I'd probably suggest downloading the linux static build and using that
[17:54:38 CEST] <N4ppeL> its 3.2
[17:54:57 CEST] <kepstin> current is 4.1...
[17:56:07 CEST] <N4ppeL> yes.. why did I get this old version? installation should not be this old
[17:56:34 CEST] <kepstin> because debian stable.
[17:56:45 CEST] <kepstin> iirc they do have backports available of newer versions
[17:57:03 CEST] <N4ppeL> anyway. I try to update and retry.. if its still not listed re-compile
[17:57:06 CEST] <JEEB> so many things depend on FFmpeg that they generally don't back-port newer versions unless they're ABI compatible
[17:57:25 CEST] <N4ppeL> i am not a linux user usually. but windows CMD has a command limit of 8192 chars :')
[17:57:49 CEST] <kepstin> the ffmpeg libs are usually parallel installable, so it shouldn't be an issue to backport the cli tool i think?
[17:58:49 CEST] <kepstin> and backports aren't installed unless you manually enable them
[18:25:05 CEST] <N4ppeL> hm, on deb-multimedia current version is 3.9 which doesnt list gray either. I will continue on Monday - thanks all for your support and suggestions
[18:25:20 CEST] <furq> N4ppeL: https://www.johnvansickle.com/ffmpeg/
[18:25:20 CEST] <N4ppeL> have a nice WE
[18:25:40 CEST] <N4ppeL> oh, thx :)
[18:25:49 CEST] <furq> it's much easier to just install that in ~/bin or /usr/local than risk ruining everything with backports or deb-multimedia
[18:26:09 CEST] <N4ppeL> still have to leave for an errand :P  but yeah, thx
[18:47:24 CEST] <dastan> does someone here know about VLC? i know they have their own channel but it look nobody answer there
[18:53:48 CEST] <dastan> does someone know about ffmpeg HLS problems?
[18:53:56 CEST] <dastan> i get lot of buffer errors
[21:32:41 CEST] <r0x> Hello
[21:35:17 CEST] <dastan> hello r0x
[21:35:41 CEST] <r0x> I'm struggling to find an example of how to flip a video stream
[21:35:42 CEST] <r0x> .
[21:38:13 CEST] <durandal_1707> vertical or horizontal flip?
[21:38:20 CEST] <r0x> both
[21:39:04 CEST] <durandal_1707> use video filters, vflip and hflip
[21:39:27 CEST] <r0x> mmm, I'm using the libraries not the tool
[21:39:36 CEST] <r0x> so I'm looking for a snippet
[21:45:22 CEST] <r0x> https://ffmpeg.org/doxygen/4.0/group__lavu__video__display.html
[21:45:29 CEST] <r0x> This seems to be a good starting point
[21:45:41 CEST] <r0x> But I can't find an example :(
[21:59:31 CEST] <furq> https://www.ffmpeg.org/doxygen/trunk/filtering_video_8c-example.html
[23:21:30 CEST] <BtbN> oh god, -f concat on Windows is stupidly slow
[00:00:00 CEST] --- Sat Jul  6 2019