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

[burek]

[00:35:26 CET] <arhat> cehoyos: Sorry, had to leave for a bit. Thanks! Actually, it's a DCP (.mxf) file that i believe is made up for JPEG 2000's (not sure what the technical way to describe that is?). By compare, do you mean just check visually, or is there some more robust method that doesn't depend on my eyes :P?
[00:40:58 CET] <arhat> made up of*
[01:59:42 CET] <cehoyos> If the input is lossless j2k (I don't know since you didn't show us command line including console output), you can export the single j2k frames with jpeg, decode them with another software and compare the results (not visually) with FFmpeg's output. This is only to check if there is something wrong
[02:28:53 CET] <nickname123> hi
[09:26:15 CET] <gusandrianos> Hello!
[09:26:30 CET] <gusandrianos> I have set up an rtsp server to stream something and I am using ffmpeg to open the stream to the server. I am streaming h.263 with a low resolution for a specific use case but the stream plays in a very poor way and drops many frames
[09:26:57 CET] <gusandrianos> I get this
[09:26:59 CET] <repo> hi again. i'm still trying to debug my issue with concatenating two videos in sequences
[09:27:02 CET] <gusandrianos> [h263 @ 0x55fe20d5f5a0] warning, clipping 1 dct coefficients to -127..12743 drop=0 speed= 191x        Last message repeated 979 times
[09:27:15 CET] <repo> here's my log output:
[09:27:32 CET] <repo> it's 3 lines, is it ok if i paste them directly?
[09:28:12 CET] <repo> i take that as a yes! :)
[09:28:14 CET] <repo> eb 04 09:24:14 Stitching video for uuid jokke... Running ffmpeg with params: ["-y", "-loglevel", "error", "-f", "v4l2", "-framerate", "30", "-video_size", "1920x1080", "-t", "10", "-i", "/dev/video0", "-f", "alsa", "-t", "10", "-i", "hw:2", "-map", "0:v", "-map", "1:a", "-codec:v", "h264", "-codec:a", "aac", "/tmp/jokke.mp4"]
[09:28:16 CET] <repo> Feb 04 09:24:25 Running ffmpeg with params: ["-y", "-loglevel", "error", "-filter_complex", "[0:v:0][1:v:0][2:v:0]concat=n=3:v=1[outv]", "-map", "[outv]", "-map", "0:a", "-codec:v", "h264", "-codec:a", "aac", "-r", "30", "-max_muxing_queue_size", "8192", "/data/jokke.mp4"]
[09:28:18 CET] <repo> Feb 04 09:25:14 Too many packets buffered for output stream 0:0.
[09:29:22 CET] <repo> so the second command fails with the error in the last line
[09:29:52 CET] <repo> the weird thing is, that most of the time this works.
[09:31:02 CET] <repo> the command is exactly the same
[09:31:23 CET] <repo> the only variance being the captured video
[09:46:39 CET] <repo> hm ok i took a closer look at the captured video files when it works and when it doesn't. https://p.jokke.space/m-maS/
[09:48:40 CET] <repo> the one that is broken shows a duration of 10s but when played, the player shows weird time codes (it starts playing at 0:29:00 and stops at 0:29:03)
[09:48:59 CET] <repo> also the broken one is half the size of the working one
[09:49:14 CET] <repo> any idea what might be going on?
[17:22:03 CET] <kikuchi> Hello, I have a .png image folder
[17:22:03 CET] <kikuchi> I'm trying to convert png to gif with Ffmpeg -i D:\adiirc\buffer\mario%d.png D:\Adiirc\buffer\test.gif
[17:22:07 CET] <kikuchi> But I still have this error [png @ 000001e5cfe7dac0] Invalid PNG signature 0xFFD8FFE000104A46.
[17:22:08 CET] <kikuchi> How I can override and create my gif please ?
[17:29:58 CET] <BtbN> looks like your png is either not a png, or broken. As ffmpeg does not overly care about the file extension, I'd guess the later
[17:31:43 CET] <furq> those are jpeg magic bytes
[17:32:16 CET] <kikuchi> But i can view my png
[17:32:39 CET] <furq> i would expect that your image viewer can view jpegs, yes
[17:32:57 CET] <furq> but presumably image2 expects every image to be the same format
[17:34:31 CET] <kikuchi> Actually it works if i change to jpg
[17:34:36 CET] <kikuchi> Thx !
[20:37:47 CET] <ralphcor> I will be obtaining a hardware MJPEG encoder that does differential MJPEG.  Before then, I'd like to get some idea of the size of video that results so my first thought was to use ffmpeg.  It has a encoder mjpeg, but ffmpeg-all(1) doesn't suggest it does differential, i.e. key frame and updates.  Am I correct?  Does anyone here know a Linux encoder that does?
[20:39:46 CET] <slimschwifty> Hey all, I'm planning to add a Radeon RX580 to my headless server to use to encode my DVR captures. Will I need to install X or Wayland to utilize VAAPI? If so, is there a bare minimum consider it wouldn't be used for anything else?
[20:40:45 CET] <slimschwifty> considering*
[20:56:32 CET] <BtbN> differential mjpeg sounds like h264 but bad
[20:57:16 CET] <ralphcor> BtbN: Yes, I accept that, but it's a tiny embedded device, low power, 640x480, and hardware differential MJPEG is what I have.  :)
[20:57:37 CET] <BtbN> I never before heard of that term, are you sure it isnt something that device made up?
[20:59:30 CET] <ralphcor> BtbN: I find Google hits, e.g. https://www.researchgate.net/publication/4128956_Low-bit_rate_motion_JPEG_using_differential_encoding
[21:02:11 CET] <ralphcor> Conexant CX93510 is one example hardware device.
[21:04:48 CET] <furq> i've never seen mjpeg-dpcm mentioned outside of academic papers
[21:08:27 CET] <ralphcor> Well, the CX93510 datasheet says JPEG & MJPEG-DPCM Image Compression (ISO/IEC 10918-1/2).  Those two ISO references are just JPEG though IIRC.
[21:14:19 CET] <BtbN> sounds like they cooked something together themselves
[21:14:52 CET] <furq> well it's described by/referenced in a bunch of papers as far back as 2004
[21:14:55 CET] <furq> so it's "a thing"
[21:15:03 CET] <furq> but i don't think it's a thing that caught on
[21:15:09 CET] <BtbN> yes, but papers aren't a standard to implement a decoder/encoder by
[21:15:10 CET] <furq> idk if ffmpeg would even decode it
[21:15:25 CET] <furq> or anything that would
[21:17:22 CET] <ralphcor> Then this will be fun.  :)
[22:09:41 CET] <kingsley> Can any royalty-free encoders render faster with ffmpeg's "-threads <n>' option, besdies libxpx? If so, which one(s)?
[22:10:59 CET] <BtbN> av1 probably
[22:12:04 CET] <furq> kingsley: https://clbin.com/tKE15
[22:12:12 CET] <furq> not a complete list since it's missing anything with threading: auto
[22:13:43 CET] <kepstin> slimschwifty: don't need X, it should work fine in a headless config as long as the user can access the appropriate /dev/dri/render* device
[22:15:12 CET] <kepstin> slimschwifty: that said, the hardware encoder on polaris is kinda 'meh', and you could certainly get equivalent results with a lower-power card.
[22:16:27 CET] <kingsley> furq: That's a nice list of encoders. May I please have the benefit of your thoughts on 3 questions? Question #1.) Why don't I see libvpx in it? Question #2.) How do you know they support ffmpeg's "-threads <n>" option? Question #3.) Asking if I could ask! ;-)
[22:17:16 CET] <BtbN> The only actually useful encoder is libx264 and libvpx anyway
[22:17:23 CET] <BtbN> and libx265 in some limited cases
[22:17:56 CET] <BtbN> The other ones are mostly for special case uses
[22:25:40 CET] <furq> kingsley: afaik external libs that support threading are all listed as "auto" which doesn't get reported in the -encoders output
[22:25:52 CET] <furq> auto meaning just pass a threads param to the encoder and let it deal with it
[22:26:41 CET] <furq> and everything listed there supports -threads
[22:26:52 CET] <furq> to some varying degree
[22:31:31 CET] <furq> https://clbin.com/nvJXR
[22:32:17 CET] <furq> no big surprises there really
[22:34:01 CET] <kingsley> furq: I said it before. I'll say it again. Thanks!
[22:34:40 CET] <furq> you should probably run that locally if you're on *nix since it's dependent on what libs your ffmpeg links to
[22:34:41 CET] <kingsley> BtbN: Do you happen to know if libx265 is royalty-free?
[22:34:56 CET] <furq> x265 is the least royalty-free codec
[22:36:07 CET] <BtbN> No codec is truly royalty free. Even VPx has patents behind it.
[22:36:08 CET] <furq> it's got more royalty than the battle of hastings
[22:36:09 CET] <slimschwifty> kepstin: I just happen to have a spare RX580, I have a GTX 260 as well but I figured I'd get more out of the AMD
[22:36:22 CET] <BtbN> gtx260 doesn't have an encoder.
[22:38:00 CET] <furq> also yeah vpx is most likely safe but the license doesn't grant proper patent indemnification
[22:39:01 CET] <slimschwifty> BtbN: good to know, I wasn't even considering it since it's so old anyway
[22:39:27 CET] <BtbN> Kinda sad that VPx is such a mess
[22:39:31 CET] <BtbN> libvpx in particular
[22:39:49 CET] <furq> i know at least nokia claim that they hold vpx patents that aren't part of the mpeg-la/google agreement
[22:40:03 CET] <furq> and i'm sure others will crawl out of the woodwork if they sniff a dollar or two
[22:40:14 CET] <furq> but really that's true of all codecs
[22:59:27 CET] <kingsley> Is my understanding correct that encoders can be ranked by how encumbered they are by royalties as: libvpx (least), libx264 and libx265 (most)?
[23:00:07 CET] <BtbN> hardly
[23:00:15 CET] <BtbN> Cause for private use, it's a non-issue
[23:01:02 CET] <pink_mist> wait, libx264 is encumbered by royalties? 0_o
[23:01:10 CET] <furq> h264 is
[23:01:30 CET] <furq> kingsley: libvpx is royalty free, that just doesn't imply patent indemnity
[23:01:42 CET] <furq> you don't have to pay any royalties but you may still be sued
[23:02:03 CET] <furq> av1 is in the same boat which is a bit of a shame
[23:02:13 CET] <furq> you'd think aom would have enough cash between them to cover that
[23:02:25 CET] <BtbN> it's just impossible to make a decent video encoder without hitting any patents...
[23:02:50 CET] <furq> sure but the richest companies in the world ought to be able to stump up for a patent indemnity clause
[23:03:40 CET] <furq> anyway x265 is definitely worse than x264 in this regard
[23:03:54 CET] <BtbN> it has not one, but TWO independend patent pools asking for money
[23:03:58 CET] <furq> four
[23:04:04 CET] <BtbN> When did they multiplay?
[23:04:24 CET] <furq> mpeg-la, hevc advance, technicolour and velos media iirc
[23:04:38 CET] <furq> some of them might have merged or split since i last checked
[23:07:04 CET] <furq> apparently technicolor rejoined hevc advance so i guess it's three now
[23:16:41 CET] <kingsley> What do you think of libvpx-vp9? Is it also royalty free? Can it render as fast as libvpx -threads <n>?
[23:20:06 CET] <Kaedenn> I have a video file that's like ~80MB. How much of it do I need to read to extract the first frame as an image?
[23:31:27 CET] <Kaedenn> ...well, how about this. I want to extract 16 images from a video, equally spaced across the video's timeline. So if the video is 16 minutes long, then I'd extract an image every 60*fps seconds.
[23:31:32 CET] <Kaedenn> s/seconds/frames/
[23:33:12 CET] <Mavrik> Kaedenn, you also need to tell which format you have
[23:33:34 CET] <Kaedenn> It's almost always going to be h264
[23:33:55 CET] <Kaedenn> The following example command seems to be a good starting point, as it takes an image every 400 frames $ ffmpeg -ss 00:00:05 -i YosemiteHDII.webm -frames 1 -vf "select=not(mod(n\,400)),scale=160:120,tile=4x3" tile.png
[23:33:58 CET] <Mavrik> in what conatiner?
[23:34:02 CET] <Kaedenn> mp4
[23:34:04 CET] <Mavrik> *container
[23:34:21 CET] <Mavrik> Well, for first frame you need the header + frame data
[23:34:32 CET] <Mavrik> The header can be either at the start or at the end of the file.
[23:34:44 CET] <Kaedenn> ...oh.
[23:34:46 CET] <Mavrik> For extracting frames every N steps you probably need more or less the whole file.
[23:35:28 CET] <Kaedenn> Would it be possible to "sniff" a frame of video based on byte patterns?
[23:36:02 CET] <Kaedenn> In theory I'd have the resolution of the video. In practice I don't always do.
[23:36:42 CET] <Kaedenn> (the extract-first-frame and make-a-collage questions are two separate projects)
[23:37:20 CET] <Kaedenn> What's the variable for the length of the movie in -vf?
[23:38:51 CET] <Mavrik> You need the header in any case to get SPS/PPS
[23:39:00 CET] <Mavrik> And the header also has the index
[23:39:14 CET] <Mavrik> So after that you can access keyframes without getting the whole file (assuming it's not segmented)
[23:52:35 CET] <kingsley> Do you happen to know of nice, clean, reliable documentation for how to speed up a royalty free encoder, like libvpx, libvpx-vp9 or av1 across many cores, threads and or slices?
[23:55:32 CET] <Mavrik> What's your goal? Meaning, what are you encoding?
[23:56:01 CET] <kingsley> Mavrik: Thanks for asking.
[23:56:36 CET] <kingsley> Short answer? testsrc2.
[23:57:31 CET] <Mavrik> ??
[23:57:43 CET] <Mavrik> I mean, are you doing realtime transcode?
[23:57:52 CET] <Mavrik> Archival?
[23:58:05 CET] <Mavrik> What's your quality goal?
[23:58:11 CET] <kingsley> Long answer? Bench mark how well render can be sped up by running it in parallel across multiple CPUs, cores and threads.
[23:58:15 CET] <BtbN> libvpx is a pretty terrible encoder
[23:58:23 CET] <Mavrik> All of these are :P
[23:58:24 CET] <BtbN> it does not scale too great, and has horrible rate control
[23:58:56 CET] <Mavrik> BtbN, then again, VP9 got better multithreading in 1.7 it seems
[23:59:06 CET] <kingsley> Mavrik: I suppose the default quality would be a reasonable standard.
[23:59:07 CET] <Mavrik> And it does have a realtime transcode mode used by Hangouts IIRC
[23:59:30 CET] <BtbN> still has laughably bad rate control compared to x264
[23:59:51 CET] <Mavrik> BtbN, sure.
[00:00:00 CET] --- Wed Feb  5 2020