January 2019 - Ffmpeg-devel-irc

ffmpeg-devel.log.20190130
by burek 31 Jan '19

31 Jan '19

[00:39:25 CET] <JEEB> oh fun, time for a bug report :) [00:42:20 CET] <JEEB> while testing outputting multiple ASS rectangles to an AVSubtitle, both the ASS encoder as well as the muxer didn't seem to handle it right :) [00:43:09 CET] <JEEB> maybe will have to propose a patch for that, but for now hafta put stuff under an AVOption (yes/no position) [03:52:24 CET] <rcombs> JEEB: nevcairiel: any thoughts on that MP3 probing issue? [15:44:14 CET] <nevcairiel> rcombs: the only actionable idea I would have would be to try to include the ID3 tag in the scoring [15:44:19 CET] <nevcairiel> anything else is arcane magic to me [15:44:35 CET] <JEEB> yea [19:42:35 CET] <JEEB> is adding new codec ids etc in AVCodec a minor bump? [19:43:04 CET] <JEEB> because my patch set is currently 1) add codec ids etc 2) add demuxing support 3) add decoding support [19:43:24 CET] <JEEB> so 1) minor lavc 2) micro lavf 3) minor lavc ? [19:43:29 CET] <JEEB> would be my guess [20:03:18 CET] <cone-009> ffmpeg 03Karthick J 07master:789d3b98d1de: avformat/tee : Pass standards compliance value to slave muxers as well [20:30:08 CET] <atomnuker> JEEB: yes, you can bump lavc minor once though I think [20:38:33 CET] <jamrial> JEEB: add codec id and decoder in one patch, bump lavc in it. then add demuxing support, bump minor if it's a new demuxer, micro if it's a change on an existing demuxer [20:38:51 CET] <JEEB> ok [20:39:03 CET] <JEEB> I just thought it made sense to first add the id, then the demuxing support and finally decoder [20:39:06 CET] <JEEB> but sure [20:39:06 CET] <JEEB> that sounds OK [20:39:15 CET] <JEEB> identifiers + decoder and minor bump [20:39:26 CET] <JEEB> then mpeg-ts changes and micro for lavf [21:55:44 CET] <cone-009> ffmpeg 03Dilshod Mukhtarov 07master:d7c9ddd0c4b0: libavdevice/gdigrab: fix HIDPI support for window capture [21:55:46 CET] <cone-009> ffmpeg 03Dilshod Mukhtarov 07master:1100862a94ea: libavdevice/gdigrab: fix HIDPI support for mouse positioning [22:03:47 CET] <philipl> BtbN: Can you do a new release nv-codec-headers release? I'm now unblocked on pushing the mpv that needs cuMipmappedArrayDestroy [22:05:00 CET] <BtbN> Yeah, will do one tomorrow. [22:09:52 CET] <philipl> Thanks [23:16:07 CET] <cone-009> ffmpeg 03Carl Eugen Hoyos 07master:8a23a2b7de38: lavf/asf: Remove an unneeded forward declaration. [00:00:00 CET] --- Thu Jan 31 2019

1 0

ffmpeg.log.20190130
by burek 31 Jan '19

31 Jan '19

[00:07:25 CET] <Bray90820> Ehh it cant hurt [00:25:51 CET] <johnjay> i've never understood what dual channel or whatever is [00:26:00 CET] <johnjay> why is having 2 2GB in dual better than a single 4GB ? [00:31:19 CET] <BtbN> Because it'll be twice as fast [00:31:29 CET] <BtbN> If your memory controler does dual channel [00:38:18 CET] <furq> it has twice as much bandwidth [00:38:32 CET] <furq> that doesn't really matter most of the time but some benchmarks will benefit a lot from it (20-30%) [00:38:59 CET] <furq> idk how video encoding fares but i assume it benefits more than most [01:51:09 CET] <analogical> I just realized that FFmpeg can't be taught because it's a black art... [02:24:31 CET] <mfolivas> @BtbN you mentioned that I should also want to use scale=-2:1080 instead of scale=1920:1080. Would that make a difference in performance? [03:00:03 CET] <DHE> no, but it would keep the aspect ratio in case you're not dealing with 16:9 ratios [03:00:27 CET] <DHE> it would give you 1080 pixels high, and the closest appropriate horizontal resolution that is a multiple of 2 (H264 requirement) [05:01:53 CET] <kurufu> Oh yea I confirmed the issue with my adaptive sync stuff was nothing to do with mpv and the mpv video filters were working perfectly for doubling/tripling fps. But the screen just has hella pixel artifacts due to overdrive. Thanks TheAMM . [05:05:36 CET] <kurufu> Also `fps=fps=120, hue=s=mod(n\,2)` in a low contrast high motion scene really makes the artifacts blatant. [05:07:27 CET] <kurufu> oh this was ffmpeg meant to say this in mpv. [05:50:09 CET] <Spice_Boy> Hi. I have dashcam video which is h264 and colourspace bt709, and when I convert it with ffmpeg it still looks good as video. If I do a windows vlc snapshot, only the original maintains the colour, but the converted has the lower range/slightly greyer colour. But, on Linux vlc snapshot, both original and converted are greyish [05:50:16 CET] <Spice_Boy> since the video plays fine, I'm not too worried, just curious [05:50:41 CET] <Spice_Boy> the only difference I can find is the original has "profile=High" whereas the converted one has "profile=High 4:4:4 Intra" [05:51:23 CET] <Spice_Boy> I believe there's something to do with nvidia card in windows, but curious to know why the original version from the dashcam does have its snapshot accurate. [05:53:00 CET] <Spice_Boy> here is the original https://pastebin.com/TgXjynMv and here is the converted https://pastebin.com/zf35RxXH [10:12:50 CET] <Zexaron> Hello [10:12:53 CET] <Zexaron> I get [NULL @ 0000027423fa38c0] Unable to find a suitable output format for '20' [10:12:53 CET] <Zexaron> 20: Invalid argument [10:12:56 CET] <Zexaron> FRAPS video [10:13:16 CET] <Zexaron> but the application is the same as usual, it gets updated regularly so maybe they messed something up [10:13:50 CET] <Zexaron> I was using same fraps as I ever was and no a problem before, some files won't encode, some encodeings stuck and never finish and some encodings go slower [10:14:02 CET] <Zexaron> I tried the latest and 4.1 stable [10:14:11 CET] <Zexaron> same thing [10:15:05 CET] <furq> Zexaron: pastebin the full command line [10:15:08 CET] <Zexaron> well it's 50 fps and I never used that before, that's the only thing I think it's different [10:18:11 CET] <Zexaron> furq: https://pastebin.com/qnR9tFtj [10:18:45 CET] <Zexaron> it's possible the game can't keep up 50FPS, but I don't remember that causing problems in the past [10:19:11 CET] <furq> this is literally everything except the command line [10:19:33 CET] <furq> that error message is almost always a broken command line [10:19:45 CET] <furq> probably a missing - somewhere [10:21:59 CET] <Zexaron> for %%F in (*.avi) do ffmpeg -i "%%~F" -vcodec libx264 -x264-params crf 20 -movflags faststart -preset slow -acodec libmp3lame -b:a 256k -ac 2 -threads 8 -f mp4 "%%~nF.mp4" [10:22:01 CET] <Zexaron> oh sorry [10:22:12 CET] <furq> -x264-params crf=20 [10:22:19 CET] <furq> i was close [10:22:20 CET] <Zexaron> i guess i was experimenting with crf value, but I was doing that to try to fix something else [10:22:41 CET] <Zexaron> I gues newwer ffmpeg has diff syntax [10:22:58 CET] <furq> well it's either -crf 20 or -x264-params crf=20 [10:23:45 CET] <Zexaron> oh [10:24:13 CET] <Zexaron> well there is some kind of a bug with encoding, it's stuck, it started 85 frames and idling now, CPU utilization idling [10:24:37 CET] <Zexaron> Codec AVOption b (set bitrate (in bits/s)) specified for output file #0 (DCS_2019-01-25_01-11-39-63.mp4) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream. [10:24:49 CET] <Zexaron> there's one warning in yellow ^^ [10:25:19 CET] <Zexaron> started encoding now [11:55:24 CET] <egrouse> i occasionally get an error from ffmpeg when streaming via rtmp: [flv @ 0x5566dc29d180] Failed to update header with correct duration. [flv @ 0x5566dc29d180] Failed to update header with correct filesize. [11:55:51 CET] <egrouse> why does this occur/how can i stop it? it seems very inconsistent and other videos (and even the same file) with same commands work correctly other times [19:13:40 CET] <mfolivas> I would like to increase the performance of my encoding time for all my videos. One thing that people recommended was to take a look at QuickSync [19:13:47 CET] <mfolivas> Right now this is what I am running [19:14:37 CET] <mfolivas> time ffmpeg -i two-minute-video.mp4 -vf scale=1920:1080 -profile:v baseline -level 4.1 -crf 17 -preset fast -bf 0 scaled-some-random-video.mp4 [19:15:36 CET] <mfolivas> 1) how can I figure out the encoding and decoding (I think it's by default libx264) [19:16:15 CET] <mfolivas> 2) how I can use the encoding/decoding for QuickSync? -c:v h264_qsv?? [19:17:39 CET] <DHE> libx264 doesn't do decoding. ffmpeg has its own software decoder [19:18:15 CET] <DHE> ffmpeg -encoders (or -decoders) will list the available codecs. decoders can be specified with -c:v in front of the input file, encoders can be specified with -c:v in front of the output file. the :v means video obviously [19:22:53 CET] <mfolivas> @DHE thanks again! so libx264 is only for encoding! [19:23:56 CET] <mfolivas> again, my main concern is performance/speed and quality for the videos. [19:24:13 CET] <mfolivas> I'm trying to understand how is QuickSync going to help me with it? [19:25:07 CET] <pink_mist> quality is unlikely to be helped by something that's faster [19:36:18 CET] <DHE> in general hardware encoders are worse in quality compared to software encoding, even on "fast" presets [19:37:15 CET] <roxlu> hi, does someone knows a way to generate a test video that includes some audio blips/blops that I can use to test synchronisation during playback? [19:37:33 CET] <pink_mist> aren't there faster presets than 'fast'? like 'veryfast' or something? you could try that instead, mfolivas [19:47:22 CET] <mfolivas> @ pink_mist yes, I have tried different presents. I also understand that there is a balance between "fast" and "quality". I'm trying to find that balance. [19:49:28 CET] <DHE> when you're dealing with high resolutions (1080p) it gets harder [19:55:18 CET] <pink_mist> mfolivas: x264 is really a lot better, quality-wise, than practically all hardware-encoding solutions ... the only time hardware-encoding is better is when quality is far down the line of priorities [20:02:13 CET] <mfolivas> @pink_mist thanks [20:03:57 CET] <DHE> I'm told that the RTX GPUs have a substantially improved hardware encoder over the previous generations (nvenc) but can't quantify it myself. plus they're expensive as all hell. [20:09:32 CET] <mfwitten> Any idea why 'ffmpeg -i input.mp4 -an -c:v libx264 output.mp4' takes a 29.97 FPS input and tries to create a 120 FPS output (by duping frames)? Is the input (from an Android video recording) wrong? The output, when played, still looks fine. [20:18:29 CET] <mfwitten> Perhaps time stamps are incorrect in the input? Putting '-vsync 0' still tries to create an output with 120 FPS; adding '-r 29.97' for the output causes ffmpeg to complain about timestamps being non-monotonics, etc. [20:27:59 CET] <mfwitten> So, I did 'ffmpeg -i input.mp4 -an -c:v libx264 -vsync 0 output.mp4', and ffmpeg was telling me that the output would be 120 FPS, but when I run 'ffmpeg -i output.mp4', it tells me that the movie is 29.95 FPS (not 29.97, mind you!). All very strange. [20:30:28 CET] <mfwitten> Now, I'm trying with '-r 29.97' (and without -vsync 0): ffmpeg -i input.mp4 -an -c:v libx264 -r 29.97 output.mp4 [20:30:57 CET] <mfwitten> So far, it seems to be working as expected. No dups (except for the usual 2 that ffmpeg makes for some reason, at the beginning) [20:31:57 CET] <mfwitten> This makes 2 questions then: Is Android producing bad time stamps? Why is ffmpeg choosing 120 FPS for the output by default? [20:32:29 CET] <JEEB> most likely just variable frame rate [20:32:54 CET] <JEEB> the phone cameras have variable recording rate due to how long it takes to get the image [20:33:28 CET] <JEEB> if you want to wonder what's going on, check out the pts values ffprobe -show_packets -show_streams shows :P [20:33:41 CET] <JEEB> (you can -of json if you want to script it with python/ruby/js or something) [20:34:15 CET] <mfwitten> JEEB: OK. I'll investigate further in that way. Thanks for the idea. Also, any idea why ffmpeg might choose 120 FPS? [20:34:51 CET] <JEEB> fuzzy logic? also make sure it's actually 120fps and not also variable frame rate? (although I think the default "vsync" mode is cfr for stuff like mp4) [20:35:24 CET] <mfwitten> JEEB: If the frame rate is variable on the input, then how come '-r 29.97' did result in any drops or dups (besides the initial 2 that it seems to make every time)? [20:35:47 CET] <mfwitten> did NOT result, that is. [20:37:06 CET] <JEEB> mfwitten: can't say anything. also if possible use exact values like 30000/1001 for those /1001 rates [20:37:44 CET] <JEEB> mfwitten: you'll have to look at the AVPacket dts values if you want to look into what's going on :P [20:37:56 CET] <JEEB> that's why I noted the ffprobe command [20:38:10 CET] <JEEB> alternatively look into L-SMASH's boxdumper, which has an option to dump the timestamps [20:38:30 CET] <mfwitten> Ok. I'll do so. Thanks again [20:47:37 CET] <analogical> how do I trim the first 10 seconds from a video without reencoding it? [20:50:06 CET] <brimestone> Hello. How would someone use FFmpeg/FFplay into their project? Is there a guide on how to embed? [20:51:45 CET] <JEEB> brimestone: see the examples directory under docs [20:52:05 CET] <JEEB> and then for specific things there's "site:ffmpeg.org doxygen trunk KEYWORD" [20:52:23 CET] <JEEB> which then can get you to things like https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [20:55:00 CET] <mfwitten> analogical: Maybe: ffmpeg -i input.mp4 -ss 10 -codec copy output.mp4 [20:55:12 CET] <mfwitten> analogical: (Sorry if that doesn't do it) [21:11:56 CET] <TheAMM> What does NUT stand for? [21:12:34 CET] <DHE> it's a custom file format/extension for ffmpeg [21:12:52 CET] <TheAMM> I know what NUT is [21:13:08 CET] <TheAMM> But is there any meaning behind the name? [21:13:52 CET] <friendofafriend> Probably something saucy in Hungarian. [22:41:14 CET] <mfwitten> JEEB: Running 'ffprobe -show_packets -show_streams input.mp4 2>/dev/null | grep 409088' shows one entry for 'pts=409088' (and it's for an audio packet), while running the same command on 'output.mp4' (after just '-vsync 0') shows 2 entries for 'pts=409088', both of which are video packets. To me, that makes no sense, and it looks like it must be a bug in ffmpeg. Regardless of the input, surely it's a bug [22:41:20 CET] <mfwitten> for ffmpeg to produce 2 video packets with the same PTS. [22:48:19 CET] <utack> is there a way to "concat" three image files with different fps? like take three jpg files, tell it "0.1fps first, 1.5fps second, 0.5fps third"? [22:53:32 CET] <mfwitten> utack: fps? Are you just trying to get different durations of display? [22:53:45 CET] <utack> yep [22:54:01 CET] <utack> i can also input duration in ms or whatever, i just thought that "fps" was the fastest way to do it [23:06:52 CET] <Someone_Else> i'm trying to process an interlaced video file to both save it deinterlaced and apply motion interpolation, like some media players and tv's do [23:07:19 CET] <Someone_Else> however, i'm not sure if a tv actually doubles the framerate or smooth out the motions, or both [23:08:04 CET] <Someone_Else> anyhow, it's tricky to find the right command line options for it [23:08:21 CET] <Someone_Else> it should be fast, as some media players are able to do this real time [23:09:46 CET] <Someone_Else> it's a m2ts file, 1080i [23:12:07 CET] <mfwitten> utack: https://trac.ffmpeg.org/wiki/Slideshow#Framerates [23:13:01 CET] <mfolivas> what does "-profile:v" does in this case: ffmpeg -i two-minute-video.mp4 -vf scale=1920:1080 -profile:v baseline -level 4.1 -crf 17 -preset fast [23:14:27 CET] <JEEB> sets teh video profile to (constrained) baseline [23:14:32 CET] <JEEB> profiles are feature sets [23:14:34 CET] <mfwitten> Someone_Else: Some players just cut the resolution in half, I've read [23:14:43 CET] <JEEB> you go (constrained) baseline -> main -> high [23:14:49 CET] <mfwitten> Someone_Else: Meaning, they throw out the interlacing naively [23:15:15 CET] <JEEB> (constrained) baseline drops most of the features out of the window [23:15:27 CET] <JEEB> (CABAC and b-frames being the major things) [23:16:58 CET] <mfwitten> Someone_Else: Take a look through the filters here: https://ffmpeg.org/ffmpeg-filters.html [23:17:02 CET] <mfolivas> JEEB: if I would like to tune performance, quality, or file size, I would say that "profile" will not affect any of these criteria, right? [23:17:08 CET] <mfwitten> Someone_Else: There's a number of topics having to do with de-interlacing [23:17:34 CET] <JEEB> mfolivas: uhh, by setting profile you are limiting the encoder to that (sub-)set of features [23:17:41 CET] <JEEB> how is that not affecting compression? [23:17:47 CET] <JEEB> esp. with (constrained) baseline [23:17:58 CET] <JEEB> which disables most of the useful features in H.264/AVC [23:18:00 CET] <mfolivas> oh, now I see [23:18:44 CET] <mfwitten> mfolivas: In case you haven't, take a look at this: https://trac.ffmpeg.org/wiki/Encode/H.264 [23:19:02 CET] <JEEB> if you're using something like CRF that will just lead to the stream utilizing more bit rate for a similar result (same CRF value does not hold between different encoding parameters so I can't just say the same CRF value is the same result) [23:19:04 CET] <mfolivas> mfwitten: yeah, looking at that page now [23:19:18 CET] <mfolivas> >Profile: Another optional setting is -profile:v which will limit the output to a specific H.264 profile [23:19:32 CET] <JEEB> on the other hand, if you're forcing the encoder for a specific bit rate, then you're just losing quality [23:19:34 CET] <mfolivas> >Omit this unless your target device only supports a certain profile (see Compatibility). [23:19:42 CET] <mfolivas> hmm, I wonder why we're using this [23:19:58 CET] <JEEB> by default libx264 will limit you to the profile required by your parameters (preset etc) [23:20:01 CET] <mfwitten> mfolivas: Well, you can't forget that you have to have a player that can actually play your video [23:20:04 CET] <Someone_Else> mfwitten: I'm quite sure my player does not. It uses around 40% cpu usage and +/- 25% gpu usage while playing the video. Based on the quality it's definitely not cut in half otherwise I would have noticed [23:20:05 CET] <JEEB> so most of the time it would be main [23:20:11 CET] <mfwitten> mfolivas: There's a lot of junk hardware out there. [23:20:23 CET] <JEEB> Someone_Else: mplayer probably utilizes yadif at half rate by default? [23:20:28 CET] <JEEB> unless they switched that to full rate [23:20:42 CET] <Someone_Else> JEEB: I'm not using mplayer [23:20:45 CET] <mfwitten> mfolivas: If you know exactly who is going to be playing your video, then you don't have to worry about contraining the features you want to use. [23:20:56 CET] <JEEB> Someone_Else: argh, sorry. misread :P [23:21:19 CET] <Someone_Else> JEEB: but the question remains, what is it doing to get this result? [23:21:26 CET] <JEEB> eff if I know [23:21:52 CET] <mfolivas> yeah, the use case for this is the following: we have our own cameras (proprietary), we film short videos (zipline and skydiving), and then we create the videos using some ML language [23:21:59 CET] <mfolivas> but ultimately we leverage ffmpeg [23:22:07 CET] <mfolivas> the problem is that the render is taking too long [23:22:25 CET] <JEEB> then you instead of making the preset even faster just disabled all the features in another way? [23:22:27 CET] <mfolivas> "the players" in this case are mobile phones and my linux app [23:22:58 CET] <mfolivas> we're actually using preset [23:23:22 CET] <JEEB> yes, but I mean - you end up with baseline if you keep moving preset towards the most fast presets in libx264 :P [23:23:23 CET] <mfolivas> the only thing that we disable is the -bf 0 since our cameras doesn't support that [23:23:26 CET] <utack> thanks mfwitten [23:23:40 CET] <JEEB> no, you've effectively disabled b-frames with the profile :P [23:23:48 CET] <JEEB> since constrained baseline disables a lot of stuff [23:23:56 CET] <mfwitten> mfolivas: https://trac.ffmpeg.org/wiki/Encode/H.264#FAQ [23:24:00 CET] <mfolivas> no way! [23:24:02 CET] <mfwitten> mfolivas: See encoding times [23:24:10 CET] <mfolivas> looking into it! [23:24:23 CET] <JEEB> anyways, for any encoding speed I'd recommend actually benchmarking which part of your chain is the bottleneck :P [23:24:25 CET] <mfolivas> i see it now, brb [23:24:30 CET] <JEEB> since you have decoding, filtering, encoding [23:24:44 CET] <JEEB> decoding you can benchmark with just `ffmpeg -i INPUT -f null -` [23:24:59 CET] <JEEB> with filtering you add your vf/af/filter_complex to that [23:25:11 CET] <JEEB> that should give you a hunch on how much each step takes [23:25:29 CET] <JEEB> also your camera is not decoding, right? so it not supporting b-frames shouldn't really matter? [23:29:35 CET] <mfwitten> mfolivas: Perhaps also look into whether you're using hardware acceleration: https://trac.ffmpeg.org/wiki/HWAccelIntro [23:29:57 CET] <mfwitten> mfolivas: If you don't care too much about make a very small file, then you can probably make the the encoding process fairly quick. [23:30:47 CET] <mfolivas> JEEB: our camera is NOT decoding [23:31:13 CET] <mfolivas> so, yeah, I guess it really doesn't matter [23:32:09 CET] <mfolivas> JEEB: that's what I've been trying to figure out - what's our bottleneck [23:32:16 CET] <mfolivas> this is what we're using at the moment [23:32:17 CET] <mfolivas> ffmpeg -i two-minute-video.mp4 -vf scale=1920:1080 -profile:v baseline -level 4.1 -crf 17 -preset fast -bf 0 scaled-some-random-video.mp4 [23:32:30 CET] <mfolivas> although, we're using a C++ lib, this is similar of what we're doing [23:32:54 CET] <mfwitten> mfolivas: What is the input dimensions? Why are you scaling? [23:33:27 CET] <mfolivas> the input dimensions depends on the client: 4K, 1080p, and 720p [23:33:41 CET] <mfolivas> however, the output will differ [23:34:36 CET] <mfolivas> as I mentioned before, our customers are getting rendered videos but they don't have to match the input. In other words, we're getting a 4K file, but we CAN make it 1080p or 720p [23:35:08 CET] <mfolivas> specially because now, we're having a performance issue: rendering the movies is taking too long based on the amount of users that we have [23:36:48 CET] <mfwitten> mfolivas: Why not just provide the 4K ready to go, and charge for transcoding? [23:37:13 CET] <mfwitten> mfolivas: Then clients get better material for their records, and you get paid for scaling down [23:38:16 CET] <mfwitten> mfolivas: In any case, 17 is getting pretty low for crf, if time is an issue [23:38:25 CET] <mfolivas> mfwitten: we need to upload the file to the cloud and these sites are in a VERY remote area with low internet bandwidth (10mb upload) [23:38:49 CET] <mfwitten> mfolivas: I see [23:44:20 CET] <mfwitten> mfolivas: Is it a time issue for your business or for your clients? Maybe you could do a much smaller, lower-quality video to upload more quickly for the impatient, and then provide the higher-quality file when it finishes later? 640x480 would probably encode a lot faster than 1080p or even 720p [23:44:29 CET] <mfwitten> mfolivas: I don't know. I'm just thinking out loud [23:45:06 CET] <mfwitten> 480p, I mean [23:45:07 CET] <mfolivas> mfwitten: yes, I just don't want to play the guessing game (I've done that before) [23:45:44 CET] <mfolivas> I rather just do an analysis and see what features to tune based on the output (file size, quality, and time) [23:46:15 CET] <mfwitten> mfolivas: Yeah. Well, good luck. I wish I could help you more. [23:46:29 CET] <mfwitten> mfolivas: (not that I've helped :-)) [23:49:26 CET] <mfolivas> mfwitten: you're helping a lot [23:52:51 CET] <mfolivas> JEEB: seems that it's because of Android that we're using the Baseline profile [23:52:53 CET] <mfolivas> >Android 9 states that all devices must be able to decode Baseline/Main Profile Level 3.1. [23:53:38 CET] <JEEB> yea, that's the bare bare minimum [23:54:09 CET] <JEEB> I bet there are some very cheap devices that go at the very minimum of that, but the last time I was able to actually buy one that only did *baseline* was in 2009, a samsung device [23:54:28 CET] <JEEB> google just doesn't *require* more for device certification [23:54:41 CET] <JEEB> or whatever that specifically means :P [23:55:15 CET] <JEEB> I mean, I'm not saying there aren't baseline-only devices [23:55:26 CET] <mfolivas> The fact that I'm restricted by using the profile makes me wonder what limitations/constraints I can/cannot use [23:55:45 CET] <JEEB> I'm just noting that it might not be the device base you are aiming for [23:56:01 CET] <mfolivas> understood [23:56:06 CET] <JEEB> also you were IIRC encoding 1080p [23:56:22 CET] <JEEB> pretty sure those devices that limit themselves to baseline, level 3.1 can't do that [23:56:29 CET] <JEEB> just sayin' [23:56:47 CET] <mfolivas> in some sites we're getting 4K and 1080p and then we can provide our clients 4K, 1080p, or 720p [23:56:53 CET] <mfolivas> my research will define this better [23:57:09 CET] <mfolivas> again, we're trying to figure out what's the most optimal settings [23:57:24 CET] <mfwitten> mfolivas: I recall iPhones being a pain in the ass. [23:57:41 CET] <JEEB> I think 3GS or so onwards the hwdec in iPhones got better? [23:57:48 CET] <JEEB> can't remember, was so long ago [23:57:54 CET] <JEEB> (Seriously, not facetiously) [23:58:00 CET] <mfolivas> say for a client that needs to generate 15 minute and there are 200 videos [23:58:37 CET] <mfwitten> mfolivas: I would never upscale (1080p to 4k); it's a total waste of your time [00:00:00 CET] --- Thu Jan 31 2019

1 0

ffmpeg-devel.log.20190129
by burek 30 Jan '19

30 Jan '19

[05:36:03 CET] <cone-274> ffmpeg 03Gyan Doshi 07master:2e2b44baba57: avformat/http: clarify that ffmpeg will attempt to add missing CRLF [09:40:22 CET] Action: JEEB grmbl grmbls about figuring out which parts of a string in ARIB captions are ruby text [09:40:34 CET] <JEEB> should read the spec and figure out if libaribb24 already exports that [09:40:40 CET] <JEEB> (it didn't seem to) [09:40:59 CET] <JEEB> and then implement it if it doesn't [09:41:32 CET] <JEEB> because all ruby text seems to be exported in the beginning of the line, which leads to funky results [10:49:20 CET] <rcombs> so here's an MP3 file that misidentifies as MPEG-PS, but only because of the size of the ID3v2 tag (if I remove it it identifies as MP3) https://puu.sh/CE1qZ/5e09c24034.zip [10:49:50 CET] <JEEB> so the extension points are not high enough? [10:49:54 CET] <rcombs> yeah, I guess so [10:50:11 CET] <rcombs> MP3 gives 51, MPEG gives 52 [10:51:30 CET] <rcombs> well, MP3 gives 12 until the probe buffer expands past the end of the ID3 tag, and then it gives 51 [10:51:36 CET] <rcombs> but at the same time MPEG gives 52 [10:51:47 CET] <rcombs> which are both above the threshold so it picks MPEG [10:53:33 CET] <nevcairiel> we try to not rely on extension matches much at all [10:53:48 CET] <nevcairiel> the mpeg-ps probe f unction probably should be more strict somehow [10:53:50 CET] <JEEB> yes, if possible it shouldn't be used [11:00:04 CET] <nevcairiel> if the id3 tag fully exhausts the probe buffer, there really isnt anything to be done other then increasing the buffer however [11:00:17 CET] <JEEB> yea [11:02:20 CET] <nevcairiel> one could imagine a mechanism that allows a probe function to say something like "this might be a file of mine, but there is a tag block here of X bytes, can you skip that and send me more after?" [11:23:46 CET] <thardin> isn't there already a way for probe functions to say "more data pls"? [11:24:46 CET] <thardin> but maybe that doesn't help if the mpeg-ps prober is being too lax [11:26:48 CET] <rcombs> "more data pls" is just returning a low score, isn't it? [11:27:23 CET] <rcombs> nevcairiel: the problem isn't really that the tag fully exhausts the buffer [11:28:04 CET] <rcombs> on the iterations when that's the case, MP3 returns a low score below the threshold, MPEG returns 0, and it tries again [11:28:55 CET] <rcombs> but then on the final iteration, when the buffer is large enough to get past the ID3 tag, the remaining data past the tag happens to probe 1 higher on MPEG than MP3 [11:30:36 CET] <rcombs> the final probe iteration is on 65536 bytes, of which 54310 are the ID3 tag and the remaining 11226 are actual MP3 frame data [11:30:59 CET] <rcombs> which ends up probing at 52 in the mpeg routine [11:31:39 CET] <rcombs> if you strip off the ID3 tag, then the MP3 probe gets to 51 at only 8192 bytes, and at that size the MPEG probe only gives 25 [11:34:39 CET] <thardin> strange [11:35:36 CET] <nevcairiel> / 1 more than mp3 [11:35:41 CET] <nevcairiel> comment from mpeg.c =p [11:36:03 CET] <thardin> AVPROBE_SCORE_EXTENSION / 2 + 1; // 1 more than mp3 [11:36:06 CET] <thardin> ye [11:36:25 CET] <rcombs> it's not actually that case [11:36:33 CET] <rcombs> it's the "/* PES stream */" one [11:36:35 CET] <nevcairiel> mpeg-ps is just an annoying format [11:36:44 CET] <rcombs> that it is [11:36:51 CET] <nevcairiel> it has basically no sync markers [11:36:59 CET] <nevcairiel> or reliable magic numbers [11:37:17 CET] <thardin> this "invalid" business looks suspicious [11:37:49 CET] <rcombs> vid=9, audio=0, sys=0, invalid=0 [11:38:05 CET] <rcombs> don't ask me why it thinks there are 9 video somethingorothers [11:38:43 CET] <rcombs> the definition of "invalid" here is pretty narrow [11:39:25 CET] <nevcairiel> all it looks for is a very narrow bit pattern [11:39:37 CET] <rcombs> which is also perfectly valid MP3 [11:40:14 CET] <rcombs> maybe MP3 should give a higher score than 51 when it sees lots of perfectly valid MP3 packets (and nothing else)? [11:40:31 CET] <nevcairiel> it could also give the id3 tag some value [11:40:36 CET] <nevcairiel> since thats pretty common in mp3 files [11:41:02 CET] <rcombs> and pretty uncommon in mpeg [11:42:36 CET] <thardin> the mpegps prober could give a score of zero if it finds an ID3 tag maybe? [11:42:57 CET] <nevcairiel> i'm sure some crazy person put those together [11:48:53 CET] <rcombs> this all seems fragile enough that I'm a bit afraid to touch it [11:49:19 CET] <nevcairiel> the probing of those identifier-free formats is a ll over the place [11:49:29 CET] <nevcairiel> mpeg-ps and mp3 keep fighting about who is the most inaccurate [12:15:11 CET] <atomnuker> be glad there isn't an opus raw bitstream container, as any collection of random bits would be a valid opus packet [12:53:49 CET] <thardin> atomnuker: wouldn't/shouldn't any efficient codec do that? [12:54:17 CET] <rcombs> not sure anybody's accused MP3 of efficiency [12:54:48 CET] <rcombs> at least not this decade [12:56:21 CET] <atomnuker> thardin: usually if a decoder receives a corrupt bitstream it'll error out as it could cause out of bounds/reading past the packet/a definitely irrecoverably corrupt frame [12:56:42 CET] <atomnuker> if opus gets a weird packet it doesn't care, each choice is always checked against the amount of bits left [12:57:41 CET] <atomnuker> if there aren't enough bits it falls back to some encoding that would take less bits, and even then if the packet ends, it'll just think the encoder didn't have anything to signal afterwards so its zero [12:58:10 CET] <thardin> yeah, that's pretty much how I would make it [12:58:25 CET] <thardin> else you're wasting bits [12:59:04 CET] <atomnuker> well, maybe not, suppose you're sending e.g. golomb values to specify a codebook (which you usually look up in an array of such) [12:59:48 CET] <atomnuker> golomb would be efficient and not waste any bits, but at the same time a corrupt packet could easily specify a huge nonexistant codebook [13:00:04 CET] <thardin> you have to handle that anyway, no? [13:00:05 CET] <atomnuker> so rather than continue you'd be better off erroring out [13:00:58 CET] <atomnuker> its just that the opus bitstream doesn't have any places where a packet would be obviously corrupt [13:01:43 CET] <atomnuker> okay, there is one, if the packet size is larger than 1275 bytes, but that would be a demuxer/user problem [18:00:51 CET] <atomnuker> erm [18:01:01 CET] <atomnuker> why is there a copy of fft_template in libavutil? [18:01:17 CET] <atomnuker> as well as fft_init_table.c? [18:01:24 CET] <atomnuker> they're not hooked up to anything [18:01:29 CET] <atomnuker> they're not even compiled [18:03:49 CET] <atomnuker> nevermind, my dir's extremely dirty and I can't bring myself to delete anything [18:43:16 CET] <Compn> lol atomnuker. the problem with being a dev :D [00:00:00 CET] --- Wed Jan 30 2019

1 0

ffmpeg.log.20190129
by burek 30 Jan '19

30 Jan '19

[01:20:31 CET] <retrojeff> hello I am trying to join (concat) 2 mkv files with ffmpeg [01:20:56 CET] <retrojeff> tried ffmpeg -i "concat:input1.mkv|input2.mkv" -c copy output.mkv [01:21:04 CET] <retrojeff> no errors but it did not join [01:22:15 CET] <retrojeff> full output here https://pastebin.com/WSvVrjdu [01:27:45 CET] <relaxed> retrojeff: "ffmpeg version 0.10.16" is ancient [01:28:09 CET] <retrojeff> its the version thats on the website for RHEL/CentOS [01:28:32 CET] <retrojeff> from RPMFusion [01:28:54 CET] <relaxed> that's from 2015 [01:29:00 CET] <retrojeff> yikes [01:29:29 CET] <relaxed> I have static recent builds here: https://www.johnvansickle.com/ffmpeg/ [01:29:39 CET] <retrojeff> ya I saw that [01:29:39 CET] <relaxed> recent static* [01:29:44 CET] <retrojeff> trying them now [01:32:00 CET] <retrojeff> cool got yours to work [01:32:01 CET] <retrojeff> https://pastebin.com/cggd3LGT [01:32:30 CET] <retrojeff> maybe not [01:32:32 CET] <retrojeff> [concat @ 0x4fcdc40] Line 1: unknown keyword '?Eã?' [01:32:32 CET] <retrojeff> input1.mkv: Invalid data found when processing input [01:33:06 CET] <relaxed> pastebin the command and output [01:33:32 CET] <furq> retrojeff: you need to use the concat demuxer for mkv [01:33:40 CET] <furq> https://trac.ffmpeg.org/wiki/Concatenate#demuxer [01:34:15 CET] <retrojeff> https://pastebin.com/A10K8EZQ [01:34:34 CET] <retrojeff> thats with ffmpeg -f concat -i input1.mkv -i input2.mkv -c copy output.mkv [01:34:50 CET] <furq> yeah that's not how the demuxer works [01:40:25 CET] <friendofafriend> Howdy all. I'd like to change the "service_name" in the MPEG transport stream muxer. How do I actually pass that option on the command line? [01:40:28 CET] <retrojeff> my files play in VLC just fine [01:40:46 CET] <retrojeff> just wanna join them together [01:44:53 CET] <retrojeff> if I convert these to other formats I might lose quality [01:50:48 CET] <friendofafriend> Ah, figured out the service name is the '-metadata service_name="foo"' flag. Can I change the publisher data? [01:59:45 CET] <friendofafriend> Ah, found it. Thank you, all. [04:09:00 CET] <retrojeff> still no solution to my issue? [04:52:47 CET] <fella> retrojeff: < furq> yeah that's not how the demuxer works [04:57:27 CET] <retrojeff> ????? [04:58:11 CET] <retrojeff> followed https://stackoverflow.com/questions/7333232/how-to-concatenate-two-mp4-file… [06:17:45 CET] <kurufu> Is there a filter I can apply to a video to double/triple up frames? A la, I want video to play back at the same rate but take say 24fps to 48fps. [06:18:58 CET] <kurufu> ideally the duplicated frame would be an exact duplicate. The idea behind this is driving an adaptive sync display at a low fps results in serious overdrive artifacts. [06:22:43 CET] <kurufu> oh this appears to be how the -r flag works. [07:31:45 CET] <fella> retrojeff: furq told you to use the concat demuxer and gave you a link that shows how to use it! [07:34:10 CET] <fella> ... and even your link shows how it's done properly ;) [09:20:20 CET] <retrojeff> your funny men [09:25:53 CET] <pink_mist> retrojeff: not sure what you think the joke is, but you have the correct answers already; if you refuse to use those answers that's your own fault [12:21:45 CET] <oliv3> hi there, i'm using ffmpeg to encode a mp4. input is video frames dumped using a pipe (-i pipe:). looking for a way to dump audio samples from another pipe, is it possible ? using named pipes maybe ? [12:30:32 CET] <yrios> Is there any way to get the number of bytes consumed from the new 'avcodec_receive_frame' API? Like with the old 'avcodec_decode_audio4'? [12:31:58 CET] <BtbN> It consumes packets and outputs frames. Not raw bytes. [12:34:26 CET] <yrios> BtbN: I understand this is supposed to be transparent to the library user, but I really need to know how many bytes were consumed! Do you know a workaround? [12:34:33 CET] <BtbN> no [12:34:52 CET] <BtbN> You can get the size of the packet before you send it if you want to know the size [12:37:19 CET] <yrios> The returned frame has AVFrame::pkt_size, but it is not updated correctly, there is no delta (before - after) on first decode :( [12:38:21 CET] <BtbN> delta of what? [12:39:54 CET] <JEEB> AVFrame is AVFrame [12:39:57 CET] <JEEB> AVPacket is AVPacket [12:40:25 CET] <JEEB> and if you have packets with multiple things then generally parsers separate them for you? [12:40:39 CET] <JEEB> you might want to explain more about what exactly you're trying to do [12:43:02 CET] <yrios> delta is d in: a = frame->pkt_size; avcodec_receive_frame(ctx, frame); d = a - frame->pkt_size [12:44:07 CET] <JEEB> can you actually explain the use case? [12:44:18 CET] <JEEB> like, going from the beginning [12:44:39 CET] <JEEB> (unfortunately I'm busy at $dayjob so I will not be able to help) [12:44:47 CET] <BtbN> frames don't really have a packet size [12:44:48 CET] <yrios> I don't have the moov atom, so I try to reconstruct it. For this I need to know how long each packet is [12:45:19 CET] <BtbN> You get that infrom from the demuxer [12:45:27 CET] <BtbN> *info [12:45:47 CET] <JEEB> the AVPacket you're feeding to the decoder should have that info, unless you're just randomly spewing data into the decoder? [12:45:56 CET] <JEEB> in which case you maybe should try utilizing a parser? [12:46:06 CET] <JEEB> (lavf/lavc should have different parsers) [12:47:16 CET] <yrios> You dont know the size of the packet, so you set it to a constant. 'avcodec_decode_audio4' worked fine for getting the actual size. BtbN: How would I use the demuxer to get this information? [12:47:48 CET] <BtbN> It gives you packets, and they have size. [12:49:47 CET] <yrios> function names? [12:50:59 CET] <BtbN> You already must be getting packets somehow? [12:51:31 CET] <JEEB> he has broken files as input, and is just feeding data in chunks to a decoder [12:51:37 CET] <JEEB> in order to recreate the index [12:52:41 CET] <JEEB> I don't know/remember the parser API, but it sounds like that might be a better option if the data of a single stream is already there. although still, I would not be 100% sure what lavf gives out matches his needs (although if the older stuff worked then it should, maybe) [12:52:46 CET] <JEEB> anyways, $dayjob [12:53:17 CET] <JEEB> yrios: if you cannot figure it out within some time, explain your use case as well as possible and seek help on the trac issue tracker. [12:53:41 CET] <JEEB> because not for everyone your explanation hits 100%, like you could see with BtbN. thus explaining it out will help with the context :P [12:55:42 CET] <BtbN> I don't think decoders even generally support that, and will just randomly throw away excess data at the end of "packets". [12:56:02 CET] <yrios> JEBB: ok, thank you [15:35:11 CET] <mfolivas> Need to leverage the use of multithreads on my renders [15:35:22 CET] <mfolivas> Right now I am using something like this on a Debian box [15:35:26 CET] <mfolivas> `time ffmpeg -i some-random-video.mp4 -vf scale=1920:1080 -crf 16 -bf 0 scaled-some-random-video.mp4` [15:35:40 CET] <mfolivas> it takes about 6 minutes per render [15:36:03 CET] <mfolivas> this is for a small size video (seconds) [15:36:24 CET] <mfolivas> for videos with more than 10 minutes, it takes a very long time [15:36:44 CET] <mfolivas> I want to see if I can increase the speed by multithreading it [15:36:51 CET] <BtbN> It already is. [15:36:51 CET] <mfolivas> how can I do that? [15:37:02 CET] <BtbN> You need to turn it explicitly off. [15:37:12 CET] <BtbN> To not have it use all the CPUs it can get [15:38:30 CET] <mfolivas> @BtdN thanks!! [15:38:40 CET] <mfolivas> noticed that there is a `thread` command [15:38:47 CET] <mfolivas> that is how you can tweak the threads? [15:39:22 CET] <BtbN> yes [15:39:28 CET] <BtbN> The default is 0, which means auto-detect [15:39:51 CET] <mfolivas> yeah, I got confused because in StackExchange someone said [15:39:56 CET] <mfolivas> >it depends on codec used, ffmpeg version and your CPU core count. Sometimes it's simply one thread per core. Sometimes it's more complex like: [15:40:13 CET] <BtbN> Some codecs and filters indeed are single threaded [15:40:30 CET] <furq> mfolivas: that command will use x264 which is multithreaded [15:40:48 CET] <furq> and with no additional effort [15:40:54 CET] <BtbN> You also most likely want to use scale=-2:1080 [15:40:55 CET] <egrouse> sorry to randomly jump in - is there a chance that a single threaded filter could cause a bottleneck if others are multi/ [15:41:00 CET] <BtbN> Also, why are you turning off B-Frames? [15:41:04 CET] <mfolivas> @furq thank you! [15:41:10 CET] <BtbN> egrouse, yes [15:41:14 CET] <furq> egrouse: yes but it has nothing to do with threading [15:41:20 CET] <furq> a slow filter will bottleneck faster filters [15:41:30 CET] <egrouse> yeah, makes sense [15:41:38 CET] <furq> libavfilter only supports slice threading iirc so it's not like one filter will need to buffer more frames [15:41:54 CET] <mfolivas> @ BtbN I just started on this startup and they have this bottleneck - developer is no longer with company [15:42:22 CET] <BtbN> Throw more/faster CPUs at it [15:42:22 CET] <mfolivas> so, I do not know why we are using b-frames? [15:42:31 CET] <BtbN> you are turning them off [15:42:51 CET] <mfolivas> @BtdN by using b-frames I am turning them off? [15:42:56 CET] <BtbN> what? [15:43:03 CET] <BtbN> "-bf 0" 0 B-Frames. So you turn them off. [15:43:25 CET] <furq> if you just want it to run faster then use a faster preset [15:43:26 CET] <mfolivas> oh, I see...thanks [15:43:32 CET] <furq> -preset fast/faster/veryfast/superfast/ultrafast [15:43:38 CET] <mfolivas> gotcha [15:43:44 CET] <mfolivas> @furq thanks again! [15:43:48 CET] <furq> all of those should look fine at crf 16 [15:44:03 CET] <furq> ultrafast turns a lot of stuff off though so i wouldn't use that unless absolutely necessary [15:44:16 CET] <DHE> what resolution is the source? if you can skip the rescaling that will help significantly [15:44:29 CET] <DHE> and personally I would try to keep it no worse than "veryfast" [15:45:01 CET] <mfolivas> @DHE using a 4k video and scaling to 1080p [15:45:16 CET] <mfolivas> @DHE thanks for the tip!! [15:45:48 CET] <DHE> ah... okay yeah the... [15:45:49 CET] <DHE> *then [15:46:07 CET] <BtbN> That will be slow no matter what really [15:46:14 CET] <BtbN> scaling alone will take a bit [15:47:00 CET] <mfolivas> ok, so, by default ffmpeg uses ALL the cores in the system (unless you explicit it define them). To increase the throughput, the quickest way is to scale vertically (add more cpus)...or play with the `preset` option [15:47:21 CET] <BtbN> If it's an nvidia system you could use the special features of the cuvid decoders, which can scale in hardware. [15:47:35 CET] <furq> mfolivas: libx264 defaults to using all cores, not ffmpeg [15:47:48 CET] <furq> most other codecs won't do that [15:48:08 CET] <DHE> CPU scaling works to a point. diminishing returns sets in somewhere in the 10-16 core range I think.. [15:48:38 CET] <JEEB> mfolivas: if it's HEVC you could try spawning dozens of threads as a hack :P [15:48:43 CET] <JEEB> (the input that is) [15:48:48 CET] <JEEB> (or just use hwdec if available) [15:49:01 CET] <furq> yeah decoding 4k hevc in software is no fun [15:49:07 CET] <mfolivas> @furq thanks, the code we're using is in C++ so not sure if that is using libx264 [15:49:15 CET] <furq> ffmpeg is using libx264 [15:49:40 CET] <furq> if you used e.g. -c:v libvpx-vp9 then it would not multithread as easily as that [15:49:46 CET] <furq> or easily at all [15:50:07 CET] <furq> also yes listen to what JEEB just said [15:56:31 CET] <mfolivas> @JEEB thanks!! I do not know if we're using HEVC [15:57:28 CET] <mfolivas> but at this time, I just need to get this SIGNIFICANTLY fast (like twice as fast) [15:59:34 CET] <DHE> the ffmpeg cli tool could use a multithreading makeover, but that's quite the project by itself... [15:59:51 CET] <mfolivas> right now for a 2 minute 4K video to 1980p, the render takes more than 3 minutes [15:59:58 CET] <mfolivas> *1080p [16:00:43 CET] <egrouse> i take it that investing in a 2x more powerful machine is out of the question [16:01:17 CET] <mfolivas> @egrouse not really, we will get a more powerful machine [16:01:35 CET] <mfolivas> but also I would like to make the video rendering as optimal as possible [16:01:44 CET] <egrouse> i am doing some streaming stuff right now and the cpu cant even hack downscale 1080>720 fast enough [16:01:50 CET] <egrouse> so i had to preprocess everythgin to 720 [16:01:52 CET] <egrouse> zzz [16:01:56 CET] <DHE> mfolivas: benchmark the video decoder with: ffmpeg -i $INPUTFILE -map 0:v -c:v rawvideo -f raw -y /dev/null [16:02:19 CET] <mfolivas> standby @DHE [16:02:53 CET] <DHE> eg: for h264 input at 1080p I'm getting 189fps (6.3x realtime) [16:03:28 CET] <mfolivas> @DHE > Requested output format 'raw' is not a suitable output format [16:03:36 CET] <DHE> whoops, -f null [16:03:37 CET] <DHE> my bad [16:03:39 CET] <mfolivas> `time ffmpeg -i some-random-video.mp4 -map 0:v -c:v rawvideo -f raw -y /dev/null` [16:03:44 CET] <furq> just ffmpeg -i foo -f null - [16:03:49 CET] <mfolivas> thanks guys! [16:04:18 CET] <mfolivas> @DHE you're good! [16:04:24 CET] <mfolivas> stand by [16:04:32 CET] <mfolivas> real 0m22.858s user 1m6.764s sys 0m0.216s [16:04:53 CET] <mfolivas> doing this: time ffmpeg -i some-random-video.mp4 -map 0:v -c:v rawvideo -f null -y /dev/null [16:04:53 CET] <furq> what fps did ffmpeg report [16:05:16 CET] <mfolivas> @furq checking [16:05:46 CET] <DHE> you said this is a 2 minute video... so that's 5.2x realtime... [16:06:06 CET] <DHE> which isn't too bad I think, but it's consuming ~3 cores doing that... [16:06:09 CET] <mfolivas> give me a minute, this is NOT a 2 minute video [16:06:13 CET] <furq> yeah that's not ideal [16:06:15 CET] <mfolivas> this is just some random video that I am using [16:06:30 CET] <mfolivas> but the majority of the videos that we render (on prod) are about 2 minute [16:06:32 CET] <mfolivas> sorry for the confusion [16:06:35 CET] <mfolivas> let me check the video [16:06:40 CET] <mfolivas> length [16:07:19 CET] <furq> also this is academic if you don't have a device that can hwdec hevc [16:08:21 CET] <furq> so a recent intel cpu, recent nvidia gtx card, or amd rx400 or better [16:08:33 CET] <mfolivas> so the video is 34 seconds and its demesions are 3840x2160, codecs: AAC, H.264 [16:09:11 CET] <furq> oh man 4k h264 [16:09:16 CET] <furq> that's always annoying [16:09:51 CET] <furq> i think nvdev/uvd will deal with that though [16:09:52 CET] <mfolivas> I'm using an Intel NUC on Debian with processor:3, vendor_id : GenuineIntel, model name : Intel(R) Core(TM) i5-7260U CPU @ 2.20GHz [16:09:53 CET] <furq> nvdec [16:10:18 CET] <furq> that should have qsv [16:12:33 CET] <furq> is scale_qsv still a thing [16:12:50 CET] <furq> it's not in the docs and i don't have an intel cpu newer than 2009 to hand [16:13:05 CET] <mfolivas> @furq regarding your question of the fps: [16:13:07 CET] <mfolivas> frame= 1020 fps= 45 q=-0.0 Lsize=N/A time=00:00:34.03 bitrate=N/A speed=1.51x [16:13:25 CET] <furq> yeah that's more useful than the output of time [16:13:53 CET] <furq> anyway i don't know how to use qsv but here is a wiki page [16:13:55 CET] <furq> https://trac.ffmpeg.org/wiki/Hardware/QuickSync [16:14:06 CET] <furq> that should at least speed up the decoding and scaling quite a bit [16:14:17 CET] <furq> you could also consider using qsv for encoding but it's not as efficient as x264 [16:16:05 CET] <mfolivas> will look into that [16:16:26 CET] <furq> using qsv for the whole pipeline will be massively quicker on such a low-power cpu [16:16:34 CET] <mfolivas> @furq so don't bother with the multithreads at the time and focus on the QuckSync [16:16:38 CET] <furq> and there's no reason not to use it for decoding and scaling [16:17:51 CET] <mfolivas> sorry, that was a question @furq [16:17:52 CET] <mfolivas> :) [16:18:08 CET] <furq> if you do use x264 then just stick with the default threads setting [16:18:22 CET] <furq> it rarely helps you to change it, and it especially won't help if you're offloading the decoding and filtering [16:18:52 CET] <furq> and if you use qsv for everything then there's no threads setting to change, everything is running in hardware [16:36:42 CET] <mfolivas> @furq seems like this is the code that we're using based on my research [16:36:43 CET] <mfolivas> ffmpeg -i $input -vf scale=w=$width:h=$height -profile:v baseline -level 4.1 -crf 17 -preset fast -bf 0 $output [16:37:28 CET] <mfolivas> also, the reason why we turn off b-frames is because our cameras (we have a proprietary camera) does not produce b-frames [16:38:54 CET] <pixelou> Hi, I would like to dump the data from a video frame as a binary array of RGB values with the C API. How do I make sure that all pixels are contiguous in on big array of size w*h*3? [16:56:27 CET] <mfolivas> @furq so we are using x264 so I guess that we're using *all* cores. One of my developers said that it may not actually correspond to the number of cores on the machine. He said: I'd try explicitly setting the core count to the number of hyperthreads [17:00:18 CET] <Mavrik> pixelou: video frames will probably be in YUV420 format [17:00:20 CET] <mfolivas> Also, the bottleneck we have is with the video *encoding* time, so I don't think QuckSync can help me [17:00:23 CET] <Mavrik> so you'll need to do a pixel format conversion to RGB [17:00:31 CET] <Mavrik> non-planar I guess [17:01:50 CET] <pixelou> Mavrik: I was planing to use sws_scale for the pixel format conversion. [17:02:00 CET] <Mavrik> Yp. [17:10:27 CET] <pixelou> For the data packing, I have found this: https://stackoverflow.com/a/35837289 I'm not sure whether this is an idiomatic way of doing things. [17:28:21 CET] <mfolivas> @DHE seems that we are using x264 and the issue is with the encoding [17:29:11 CET] <Mavrik> pixelou: you shouldn't really have to do that if you set input and output pixel formats correctly [17:29:27 CET] <Mavrik> I'm not sure if RGB24 output is planar or not [17:30:00 CET] <mfolivas> we're also turning the b-frames because our cameras doesn't support them [17:30:08 CET] <mfolivas> we [17:30:19 CET] <mfolivas> we're also using a "fast" preset [17:30:53 CET] <mfolivas> since we're using the x264 lib, does that means that we're using all the cores of the machine? No need to do any type of multithreating? [17:34:39 CET] <egrouse> it defaults to use all cores [18:21:03 CET] <pixelou> Mavrik: you are right, the sws_scale takse the line sizes of the destination [18:22:06 CET] <pixelou> So I can choose the minimal value instead of rounding to the closest multiple of 32. [18:22:54 CET] <pixelou> Actually, the line sizes are set by av_image_alloc which has an align parameter. [19:47:03 CET] <rememberYou> hello friends, I have an acquaintance who filmed in portrait mode, which takes place at black stripes on the side. Is it possible to convert this video to landscape mode to remove these black bands on either side of the video? [19:48:06 CET] <rememberYou> NOTE: I tried to use `ffmpeg -i foo.mp4 -filter:v "crop=w:h:x:y" output.mp4` but the black strip are still there, I'm not sure if this is the right thing to do [19:49:36 CET] <friendofafriend> rememberYou: What is the actual command you are using for crop? [19:51:46 CET] <rememberYou> well, I took a single frame of the video and opened it with gimp to know the "x, y" from the rectangle and the "width" and "height" of this rectangle and this is what it gave me: `ffmpeg -i test.mp4 -filter:v "crop=875:1275:882:0"`, but... ffmpeg doesn't like 1275, telling that the height it's too big, so I tried 1000 instead of 1275 (as the bar should be delete anyway, just the height of the rectangle wouldn't be enough), but the black [19:51:46 CET] <rememberYou> strip are still there [19:52:50 CET] <rememberYou> if you want to take a look at the video, this is the file that I've got: https://wetransfer.com/downloads/9605afe5f8a2f43044ca46b3404813782019012917… [19:53:27 CET] <friendofafriend> Sure! [19:54:47 CET] <rememberYou> note, the idea it's to crop these black strips to be able to upload this video on YouTube (from a friend) :p [19:56:05 CET] <friendofafriend> So, you want the black bars cropped, but not the video rotated? [19:56:50 CET] <rememberYou> yeah, if possible, I don't want that the video is rotated as the video is already straight, but I would like to put this video in a landscape mode without these black strips, to be able to upload on YouTube. [19:57:13 CET] <rememberYou> could you share also how do you do that? It's a good way to learn also for my case, as this is the first time that I'm doing this kind of thing [19:59:54 CET] <friendofafriend> rememberYou: Sure. You will lose a lot of resolution turning it to landscape. [20:01:27 CET] <rememberYou> friendofafriend: hmm, it's probably a bad idea then. Well, maybe it's just possible to delete these black strips? [20:04:53 CET] <friendofafriend> rememberYou: Sure. Is she talking about cleaning a cat box? [20:05:13 CET] <rememberYou> friendofafriend: ahaha yeah, it's a french video :p [20:05:50 CET] <friendofafriend> The language of cleaning up after your cat is universal. [20:06:27 CET] <rememberYou> hahaha, you're right [20:06:29 CET] <friendofafriend> rememberYou: ffmpeg.new -i ./pelle\ huile.mp4 -vf "crop=607:1080:416:0" -c:v libx264 -crf 0 -c:a copy ./pelle_noblackbars.mp4 [20:06:36 CET] <friendofafriend> rememberYou: ffmpeg -i ./pelle\ huile.mp4 -vf "crop=607:1080:416:0" -c:v libx264 -crf 0 -c:a copy ./pelle_noblackbars.mp4 [20:06:57 CET] <friendofafriend> Sorry, you ffmpeg would be called just "ffmpeg". :) [20:07:19 CET] <rememberYou> alright, that fine. Can you explain a little bit, how you find the right "crop" and why these extra options? [20:07:50 CET] <friendofafriend> Sure, I used the crop tool in GIMP, and opened tool options. [20:08:43 CET] <friendofafriend> The first part, crop=607:1080, is the size of what you want the output. [20:09:10 CET] <friendofafriend> But then the second part, 416:0 is how far that output is from pixel 0,0. [20:09:53 CET] <friendofafriend> In this case, we cut off 416 pixels of black bar on the left, and did not cut anything from the top. [20:10:51 CET] <rememberYou> ah yeah, so you took a screenshot of a single frame of the video and you opened with GIMP to know these properties [20:11:11 CET] <rememberYou> damn, a big thank you for her, that exactly what she needed [20:11:36 CET] <friendofafriend> You are welcome. If I were you, I would just use 640x480. [20:12:10 CET] <friendofafriend> rememberYou: ffmpeg -i ./pelle\ huile.mp4 -vf "crop=640:480:399:241" -c:v libx264 -crf 0 -c:a copy ./pelle_sd.mp4 [20:12:38 CET] <friendofafriend> But I don't know if her catbox tools will show as well. [20:12:49 CET] <rememberYou> I will send to her the both version of video :p I'm glad to sleep more smart today [20:13:21 CET] <friendofafriend> Regards to you and your friend. My cat box is cleaner already. ;) [20:14:04 CET] <rememberYou> hahaha, if you need some cat advises, you can find her on YouTube "Cosmo Chats", she's a cat pro and talk more better than I in English *laughter* [20:15:01 CET] <friendofafriend> I will certainly visit there, thank you! [21:01:19 CET] <ring0> does ffmpeg support h265 encoding using OMX IL? looking at https://github.com/FFmpeg/FFmpeg/blob/2e2b44baba575a33aa66796bc0a0f93070ab6… it is not present. am I missing something? [21:01:41 CET] <BtbN> Is there even a hwencoder that does that? [21:03:04 CET] <ring0> yes, Xilinx provides a OMX IL integration, which features OMX IL w/ h265 [21:07:41 CET] <ring0> there already is a GStreamer implementation available, but I'm somehow not a fan [21:08:52 CET] <ring0> they do GStreamer OMX IL Control SW FPGA [21:28:44 CET] <ring0> BtbN, btw I looked at the achieved bitrate using their FPGA, as you told me. f.e. on a 4k20 sample w/ h265, main, lvl 5, it produced ~45000 kbit/s [22:17:21 CET] <johnjay> I don't suppose linux has any programs that can do text to speech on a wav file? [22:17:37 CET] <johnjay> it's probably asking too much but meh. ffmpeg does so much [22:18:58 CET] <Hello71> wait what [22:19:16 CET] <Hello71> do you mean speech to text [22:19:32 CET] <johnjay> yes [22:19:40 CET] <johnjay> sorry i'm exhausted at the moment [22:20:00 CET] <johnjay> i get the impression it's so difficult no such programs exist except Dragon [22:21:42 CET] <Hello71> there are lots of speech recognition programs [22:21:55 CET] <Hello71> iirc there are no good foss ones [22:22:07 CET] <Hello71> possibly you can get some free trial [22:27:44 CET] <johnjay> yeah maybe. thanks [22:29:18 CET] <Hello71> there are also paid cloud services [22:29:23 CET] <Hello71> I think all three have one [22:29:27 CET] <Hello71> or possibly only google and amazon [22:59:39 CET] <Bray90820> How much performance boost would i get while encoding video if i upgraded to 8GB ram from 6 [23:00:07 CET] <Bray90820> Encoding mkv to mp4 to be exact [23:01:44 CET] <Hello71> about .5 performances [23:07:31 CET] <Bray90820> But still a boost alright [23:13:24 CET] <DHE> maybe... unless you had 3 sticks of 2GB on a quad-channel controller. upgrading from triple channel to quad channel memory may give 10-20% performance improvement. maybe more. 1->2 channel gave me +30% [23:36:41 CET] <Bray90820> I have a 4 gb and a 2 gb stick and i was gonna replac the 2 gb with a 4gb [23:37:14 CET] <Bray90820> 4+2 becomes 4+4 [23:41:45 CET] <DHE> it might make a difference for dual channel memory controllers. make sure both sticks go into blue RAM slots [23:42:02 CET] <furq> if you get matching sticks then that could potentially make a noticeable difference [23:42:09 CET] <furq> or matching enough that you can run dual channel at 1T [23:48:49 CET] <Bray90820> I dont have matching sticks [23:49:11 CET] <Bray90820> I found a 4gb stick in my house and thought i would put it in [23:52:24 CET] <furq> just having more ram won't speed anything up unless you're actually running out of it [00:00:00 CET] --- Wed Jan 30 2019

1 0

ffmpeg-devel.log.20190128
by burek 29 Jan '19

29 Jan '19

[01:24:28 CET] <cone-653> ffmpeg 03hwren 07master:3016e1f8c53d: MAINTAINERS: add AVS2 section [01:24:29 CET] <cone-653> ffmpeg 03Michael Niedermayer 07master:c95d0fb23917: avcodec/ilbcdec: Fix integer overflow in construct_vector() [01:24:30 CET] <cone-653> ffmpeg 03Michael Niedermayer 07master:4523cc5e75c8: avcodec/ilbcdec: Fix undefined integer overflow lsf2poly() [01:24:31 CET] <cone-653> ffmpeg 03Michael Niedermayer 07master:fcbda8af175a: avcodec/huffyuvdec: Check slice_offset/size [01:24:32 CET] <cone-653> ffmpeg 03Michael Niedermayer 07master:b860f2218a74: tools/target_dec_fate.list: add entries upto 1214 [01:24:33 CET] <cone-653> ffmpeg 03Michael Niedermayer 07master:5bcefceec8b6: avcodec: Add discard_sample_percentage [01:24:34 CET] <cone-653> ffmpeg 03Michael Niedermayer 07master:eb1f95eb355f: avcodec/rscc: Avoid returning frames that have nearly no undamaged pixels in them [03:48:56 CET] <Compn> agrecascino : do you want me to approve patch in mod queue (if its there?) [03:49:05 CET] <Compn> or did you want me to discard it ? [03:49:14 CET] Action: Compn has not checked hehe [21:52:43 CET] <JEEB> hmm [21:53:00 CET] <JEEB> ff_ass_subtitle_header doesn't let you set PlayResX/Y :< [22:05:38 CET] <cone-639> ffmpeg 03Marton Balint 07master:483d02918872: avcodec/motion_est: remove duplicate function [22:14:26 CET] <cone-639> ffmpeg 03James Almer 07master:286e58bb1f2d: avcodec/arbc: clear decoder state when seeking [22:21:33 CET] <JEEB> not exactly happy with this, but will have to deal with it for now :< [22:21:41 CET] <JEEB> https://github.com/jeeb/ffmpeg/commit/dd5966da33ab55674a14f91e789e9c40fc2b9… [00:00:00 CET] --- Tue Jan 29 2019

1 0

ffmpeg.log.20190128
by burek 29 Jan '19

29 Jan '19

[01:19:53 CET] <SpeakerToMeat> Hello all. [01:20:18 CET] <SpeakerToMeat> Question, if I have an interlaced video that came from a progressive (it was interlaced), what's the best deinterlacing algorithm to use for it? [01:24:56 CET] <klaxa> the exact inverse algorithm used for interlacing it [01:27:01 CET] <klaxa> if you don't know which one that is, maybe yadif "just works"? [01:28:38 CET] <klaxa> if it doesn't maybe one of the other deinterlacing filters does: https://ffmpeg.org/ffmpeg-filters.html (search for deinterlace maybe?) [01:30:28 CET] <SpeakerToMeat> I'll need to check what (default) algo premiere uses (where it was interlaced), thanks [12:28:32 CET] <zyme> nadermx 's mention reminds me of the headake I got last time I times to decoe some order between what [12:32:18 CET] <zyme> is sometimes just newline \n, what sometimes needs to be called clear and newline or return and newline, not to mention what's the difference between text formats of it like in windows verses unix or linux which usually shows up on the same line in windows notepad and other readers - not to mention it doesn't seem to (always?) change in ASCII vs Unicode - also just pressing Enter/Retum often differs in an app depending on the lang [14:36:26 CET] <ddevault> hiya [14:36:48 CET] <ddevault> I have a little C program which feeds frames into libav for streaming with rtp [14:37:10 CET] <ddevault> ffplay can play back my stream no problem, but mpv only shows one frame and freezes, and vlc never shows anything at all [14:37:48 CET] <ddevault> here's the code: https://gist.github.com/ddevault/d05d502b5b1e65505b24e2150c7d2536 [14:38:31 CET] <ddevault> mpv prints a lot of "h264: non-existing PPS 0 referenced", "h264: decode_slice_header error", "sdp: max delay reached. need to consume packet" [14:38:42 CET] <ddevault> the sdp file ends up looking like this https://sr.ht/GTzr.txt [14:39:29 CET] <Mavrik> IIRC you need to set something like global header [14:41:07 CET] <ddevault> setting this flag changes the behavior (different sdp file, different logs from mpv), but not the outcome [14:51:57 CET] <ddevault> is there a way to list all codecs which support a given pixel format? [19:42:38 CET] <SagarChapara> Greetings, I am a newbie in open source development and would like to know how to get started. Would love to here from anyone who can help me get started [19:47:48 CET] <durandal_1707> SagarChapara: find something interesting to code or just inspect code and post patch if you find something wrong/missing [19:48:27 CET] <durandal_1707> you need to know how to fetch & compile code too [21:24:25 CET] <realies> can i fix aac file timestamps with ffmpeg? [21:24:48 CET] <realies> trying to make it a wav but getting [aac @ 0x7f8855807000] Input buffer exhausted before END element found; Error while decoding stream #0:0: Invalid data found when processing input; [wav @ 0x7f8855807600] Filesize 4919443534 invalid for wav, output file will be broken [22:39:10 CET] <ecrist> Hello folks. I have an RTP stream from an HDHomeRun device that I'd like to grab a screenshot of. I'm having a hard time coming up with the right command line options. I get a bunch of decode slice errors and when I Ctl-C out, I get a "Decoding for stream 0 failed". Full output here: https://pastebin.com/Z53KQyh0 [23:39:02 CET] <funyun> hi. i'm trying to build ffmpeg on windows to use hwaccel with my nvidia gpu. i'm following this guide i have installed directx sdk, cuda toolkit, and nvidia geforce drivers. but i don't understand how to build ffmpeg to utilize this. anyone familiar with this? [23:42:25 CET] <funyun> i have also installed visual studio [00:00:00 CET] --- Tue Jan 29 2019

1 0

ffmpeg-devel.log.20190127
by burek 28 Jan '19

28 Jan '19

[04:34:08 CET] <agrecascino> hi i'm trying to fix a mess in mov_read_sidx and i'm not sure really what it's entirely _doing_ [04:35:40 CET] <agrecascino> like my brain is like, ok offset should be bounded within the limits of the start of the littlethingywhateveryoucallit and the that plus the size [04:35:47 CET] <agrecascino> but no it's just kinda going everywhere [04:36:24 CET] <agrecascino> and then mov_read_sidx declares it's done its day's work before even reading the last sidx thingywhatever and suddenly we're in an infinite loop [04:37:10 CET] <agrecascino> like on line 5010 we have offset == avio_size(pb) and at this point i'm just really not sure what makes up offset [04:37:59 CET] <agrecascino> like it's read from sidx right? [04:44:21 CET] <agrecascino> like offset + first_offset + itemsizes = the file size is the exit condition but [04:44:41 CET] <agrecascino> that apparently not correct? [04:44:47 CET] <agrecascino> or at least some part of this isn't [04:45:05 CET] <agrecascino> even if this is a malformed mp4 i feel like that shouldn't infloop ffmpeg [04:45:21 CET] <agrecascino> which is even stranger since it was made by ffmpeg [04:47:00 CET] <agrecascino> what even makes it stranger is that if you just comment out setting the frag index as complete [04:47:01 CET] <agrecascino> it works [04:47:12 CET] <agrecascino> so something is busted i really just don't know what [04:51:54 CET] <agrecascino> ah no wait i got it [04:52:05 CET] <agrecascino> i think you guys are adding the size of the block twice [04:52:49 CET] <agrecascino> if this version of ffmpeg still works then [04:52:53 CET] <agrecascino> i'm sorry this is so stupid [04:58:41 CET] <agrecascino> nvm figured it out [04:58:46 CET] <agrecascino> this is beyond stupid [04:59:06 CET] <agrecascino> actually what am i saying nevermind for [04:59:09 CET] <agrecascino> that's the dang issue [13:55:32 CET] <cone-235> ffmpeg 03Paul B Mahol 07master:795af110f70b: avcodec: add ARBC decoder [14:17:33 CET] <cone-235> ffmpeg 03Carl Eugen Hoyos 07master:8a788ff5d635: lavf/cafdec: Do not fail for unknown atoms with negative size. [14:18:50 CET] <cone-235> ffmpeg 03Gyan Doshi 07master:b5b6f6ad59ef: avfilter/buffersrc: print relevant info when skipping filter reinit [14:26:40 CET] <cone-235> ffmpeg 03Carl Eugen Hoyos 07master:d3a69438049b: lavf/subviewerdec: Skip leading BOM. [17:01:22 CET] <agrecascino> how do i like [17:01:27 CET] <agrecascino> submit a patch correctly [17:01:49 CET] <agrecascino> i tried to send one and it hasn't showed up on the mailing list and i'm worried i did something wrong [17:02:21 CET] <kierank> agrecascino: if you're not subscribed it needs manual approval [17:02:30 CET] <agrecascino> ah [17:02:47 CET] <agrecascino> also i messed up the title format, should i resend it with a fixed title? [19:23:23 CET] <cand> how does one apply for commit access to ffmpeg? I searched, but found no docs [19:24:05 CET] <durandal_1707> you need to be maintainer and have already commits in tree [19:24:08 CET] <cand> bg: I've been sending power patches for a few months, but the interest is not high. Only cehoyos and michaelni have ever reviewed, and applying has all fallen on michael [19:24:16 CET] <cand> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/239357.html [19:24:31 CET] <cand> I asked whether I should apply, and cehoyos told here I should [19:25:01 CET] <JEEB> there's a maintainer file that contains a list of people [19:25:14 CET] <JEEB> post a patch that adds yourself to the PPC side of things I guess? [19:25:32 CET] <cand> atm I have 7 commits in the tree [19:25:43 CET] <cand> oops, 5, 7 in my local tree [19:25:51 CET] <JEEB> then poke michaelni if he trusts you and your key might get added somewhere [19:26:16 CET] <JEEB> but yes, ppc in general is a very limited field :P [19:26:28 CET] <JEEB> which is why f.ex. I haven't reviewed that stuff [19:26:40 CET] <JEEB> I don't have things to test patches on, and I lack thematic knowledge [19:26:59 CET] <cand> for my first such patch, michael said altivec is not his area either, and he'd be ok if someone else checked it out [19:27:04 CET] <cand> naturally, no such someone else appeared [19:27:21 CET] <JEEB> yup, unfortunately very few people have PPC (esp. power8+) [19:28:40 CET] <cand> are there responsibilities for a maintainer? It's a heavy word, in that I can't guarantee I have time to review ppc things always, etc [19:29:14 CET] <iive> cand, you might be asked to review ppc patches other people are sending. [19:30:15 CET] <cand> that's totally fine, I was wondering about any guidelines or expectations [19:31:28 CET] <cand> some old irc logs talked about commit frequency requirements, but they were many years ago [19:31:31 CET] <JEEB> this is IMHO a general thing (not specific to maintainership) that if you break something, you should either fix it or revert it. and you are going to be the one probably CC'd onto relevant patches. the amount of activity required depends. [19:32:46 CET] <cand> yep, so ffmpeg maintainership sounds a lot lighter than kernel, etc [19:32:59 CET] <durandal_1707> you need to donate 5k bitcoins [19:33:12 CET] <cand> aww crap, I only have 4k [19:34:34 CET] <kierank> i have a power9 at work but it's being used for other things [19:34:57 CET] <JEEB> and yes, being on IRC lets you get access to people who might not otherwise respond as easily on the ML for one reason or another [19:35:20 CET] <JEEB> (busy and thus feel a bigger commitment when an e-mail has to be written f.ex.) [19:36:04 CET] <JEEB> the patches get posted on the ML of course, that's (currently) the official way [19:53:21 CET] <JEEB> ubitux: OK, I think I fixed the subtitle time bases - time to see if I can get anything out of this :) [19:53:51 CET] <JEEB> AVSubtitle's pts to AV_TIME_BASE_Q, duration is 1, 1000 [19:54:20 CET] <JEEB> (talking of results of av_rescale_q of course [20:16:14 CET] <JEEB> well, ffprobe looks all correct http://up-cat.net/p/588125e5 [20:23:00 CET] <agrecascino> hey [20:23:06 CET] <agrecascino> i use power9 [20:23:11 CET] <agrecascino> power9 solidarity! [20:23:51 CET] <JEEB> and webvtt with -copyts looks OK [20:24:35 CET] <JEEB> (ASS just lacks timestamps over 10 hours) [21:26:42 CET] <JEEB> ubitux: ok, now I know why mpv wasn't working - the ASS subtitle specific code wasn't considering duration == 0 as unknown duration from the AVPacket [21:26:57 CET] <JEEB> jesus christ I wasted time on this [23:49:07 CET] <cone-653> ffmpeg 03Mark Thompson 07master:44bcccb7f0c4: vaapi_encode_h265: Ensure that ref pics are always in the RPS [00:00:00 CET] --- Mon Jan 28 2019

1 0

ffmpeg.log.20190127
by burek 28 Jan '19

28 Jan '19

[03:03:00 CET] <Kadigan> So um, yuv422p10le is deprecated? Can the error say in favor of -what- it's deprecated? [03:11:36 CET] <furq> i don't think it is deprecated [03:11:51 CET] <furq> afaik you should only get that warning if you're using yuvj pixel formats [03:21:01 CET] <Kadigan> Unless I'm not understanding the warning I'm getting, I'm getting it for yuv420p10le, yuv422p10le and yuv444p10le. [03:21:37 CET] <furq> is the source pixel format yuvj [03:21:49 CET] <Kadigan> Yes, it is yuvj444p (JPEG files). [03:22:27 CET] <furq> that's probably it then [03:22:38 CET] <furq> it throws the same warning either way [03:22:46 CET] <Kadigan> So what... it's having a problem with the -input- format? (which I have no control over at this stage?) [03:23:00 CET] <furq> it's not having a problem with it, it's just a generic error to let you know that yuvj is deprecated and might be removed [03:23:14 CET] <Kadigan> So ffmpeg will no longer support reading JPEG input? [03:23:25 CET] <furq> i doubt it [03:23:55 CET] <Kadigan> Your answer is a bit ambiguous. [03:24:03 CET] <furq> well i'm not a dev so idk what the plans are [03:24:31 CET] <Kadigan> But was that a "doubt it will be removed" or "doubt it will continue to" [03:24:33 CET] <furq> i'm just looking at the source for that error message [03:24:49 CET] <furq> it's unlikely that they'll remove support for reading jpegs [03:25:04 CET] <furq> because that would be a crazy thing to do [03:25:05 CET] <Kadigan> Then I'm not sure who that message (in these circumstances) is for. [03:25:21 CET] <furq> yeah it's news to me that it throws that warning for inputs [03:25:48 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/libswscale/utils.c#L1192-L1196 [03:25:51 CET] <furq> there it is though [03:26:24 CET] <Kadigan> Also, "ffmpeg.pastebin.com" doesn't seem to work. [03:26:41 CET] <furq> any pastebin is fine [03:28:16 CET] <Kadigan> https://pastebin.com/KuKr5Xff is the command (and current output). You can see the error at line 37. -- Maybe I did set something incorrectly? [03:28:50 CET] <Kadigan> (I should probably fix the newlines) [03:30:52 CET] <furq> my understanding is that ffmpeg no longer uses the yuvj* formats internally, so if it encounters it then it just changes it to the equivalent yuv* format and then sets the range flag to full range [03:31:00 CET] <furq> the warning is pretty much just to let you know that this has happened [03:31:16 CET] <Kadigan> What implications does this conversion have? [03:31:22 CET] <furq> nothing [03:31:34 CET] <Kadigan> I see. [03:31:46 CET] <furq> it's not even a conversion, they're both the same format but one is limited range (16-235) and one is full range (0-255) [03:32:01 CET] <furq> i think the yuvj* stuff is the old ffmpeg way of indicating that [03:32:20 CET] <furq> but someone didn't like it so now it's all the same format with the range flag set separately [03:32:20 CET] <Kadigan> The message is confusing. Perhaps adding a "Detected a yuvj* pixel format - internally converting to a corresponding yuv* format." in front of it would help... [03:32:25 CET] <furq> yeah maybe [03:32:40 CET] <furq> the warning makes sense for outputs because that might stop working at some point [03:33:00 CET] <furq> but it's not like mjpeg support is ever going to be dropped [03:33:27 CET] <furq> it also makes sense for outputs because generally you've actually done something in that case [03:33:44 CET] <Kadigan> Also, weird... why would JPEG be using a Rec. 601 format... [03:35:38 CET] <Kadigan> ... wow. JPEG -does- use Rec. 601 [03:36:00 CET] <furq> it's a digital display format that uses yuv so i suppose it might as well [03:36:17 CET] <Kadigan> Okay, so nvm on the "weird", it's right there in the JPEG spec. 1.02 from 1992 [07:10:12 CET] <brimestone> Hey guys, is there a guide on how to use FFmpeg/FFplay on Swift4.2/xCode macOS projects? [17:44:42 CET] <Mavrik> Hmm, so apparently Dolby Atmos has been retrofitted into DD+ / DD TrueHD. Anyone has a good description on how the encoding works? [17:45:47 CET] <JEEB> not that I know. also dolby atmos is another of dolby's sales words [17:45:57 CET] <JEEB> so it probably means completely different things between different places [17:46:17 CET] <JEEB> just like dolby vision is everything from the dynamic metadata to ICtCp-like colorspaces [17:46:32 CET] <Mavrik> Yeah, I mean here the part where audio is encoded with spatial data [17:46:52 CET] <Mavrik> Instead of having a prebuilt surround mix. [17:47:31 CET] <JEEB> generally I've only seen hardware and people wanting to have their LEDs be enabled when bit streaming [17:47:53 CET] <JEEB> not sure if there are swdecs like there are for AC-4 (lol) [17:48:33 CET] <JEEB> but yea, if you find the spec it might be possible to poke at :P (or reverse engineer if a swdec is found) [17:49:03 CET] <Mavrik> Mhm, looking for it but it seems like there's bunch of marketing materials and nothing else. I guess you have to pay Dolby to get the spec :P [17:49:26 CET] <JEEB> yea, generally they only release specs when they want it into broadcast [17:49:33 CET] <JEEB> like AC-3, AC-4 and relative things [17:49:48 CET] <JEEB> ATSC/DVB/EBU etc [17:49:57 CET] <JEEB> ETSI I think one of the places was [17:52:08 CET] <JEEB> you could check if the "atmos" packets just happen to match https://www.etsi.org/deliver/etsi_ts/103100_103199/103190/01.01.01_60/ts_10… or so [17:52:46 CET] <JEEB> so far nobody's thankfully asked or implemented AC-4 because literally no-one is using it [20:38:13 CET] <deltasquared> hmm, having performance issues doing some encoding... but I've noticed ffmpeg giving me an swscaler warning about data alignment. why would there be an auto-injected swscaler in there and can I tell ffmpeg not to do that? [20:38:37 CET] <deltasquared> I'm trying to encode to mp4 using x11grab. logs can be provided if needed [20:38:52 CET] <JEEB> yes, swscale is getting inserted somewhere if that's happening [20:39:11 CET] <deltasquared> invocation is... hold on [20:39:24 CET] <JEEB> lavfi filter chain API has an option to disable implicit additions of format/swscale [20:39:30 CET] <JEEB> not sure if you can set it through ffmpeg.c [20:39:48 CET] <JEEB> (just like lavfi does have a function to graph your generated filter chain but I don't think it's in ffmpeg.c) [20:40:00 CET] <deltasquared> ffmpeg -f x11grab -framerate 30 -video_size 1366x768 -i :1.0 -vcodec libx264 -preset ultrafast -tune zerolatency -threads 4 test.mp4 [20:40:16 CET] <deltasquared> I'm not entirely sure the tune is helping, but it's description seemed like it would [20:42:08 CET] <deltasquared> it keeps up fine while doing things like scrolling in a terminal, but even running a fairly lightweight game, e.g. minetest, causes the output to become chopfest [20:42:23 CET] <Mavrik> swscaler ends up in there probably because you need RGB -> YUV conversion on the way [20:42:46 CET] <deltasquared> Mavrik: I tried libx264_rgb though, that was actually sligtly worse in performance [20:42:53 CET] <deltasquared> erm, minus the underscore [20:43:02 CET] <Mavrik> Yeah, RGB isn't optimized at all since pretty much nothing uses it. [20:43:19 CET] <deltasquared> I wouldn't have thought getting a lossless intermediate rgb format would have been so hard... [20:43:20 CET] <Mavrik> I'd suggest dumping the file to disk with some kind of fast lossless encoding and then reencoding offline. [20:43:22 CET] <JEEB> well, not like it's *not* optimized, but there's more data to begin with (4:4:4 as opposed to 4:2:0) [20:44:00 CET] <deltasquared> Mavrik: and libx264 with ultrafast *isn't* a fast encoding? I have no other ideas... [20:44:15 CET] <JEEB> zerolatency actually slows encoding down FYI [20:44:23 CET] <JEEB> since it prefers latency to speed [20:44:25 CET] <JEEB> :P [20:44:26 CET] <deltasquared> hell I was frame dumping to individual pngs at one point just to see if that would be faster... [20:44:34 CET] <deltasquared> JEEB: I'll try taking it out [20:44:53 CET] <JEEB> although I have a hunch your actual bottleneck is before x264? [20:45:05 CET] <JEEB> and/or your machine is quite slow or already loaded due to the game or so :P [20:45:28 CET] <Mavrik> I usually took huffyuv for those cases [20:45:44 CET] <Mavrik> Not sure if there's anything better for "let's dump this to disk asap" use-case :) [20:45:47 CET] <JEEB> something that video editors like is Ut Video [20:45:49 CET] <deltasquared> why isn't there a huffrgb or something, surely less colour conversion would be better [20:45:59 CET] <JEEB> ffvhuff is the FFmpeg huffyuv [20:46:03 CET] <JEEB> (with more pix_fmts) [20:46:39 CET] <deltasquared> interesting... also daft question, is huffyuv a codec or is it also a container format, just wondering what container I should shove it into [20:46:49 CET] <JEEB> it's a codec [20:46:58 CET] <deltasquared> so... shove it in mkv? :P [20:47:03 CET] <deltasquared> always a safe bet it seems [20:47:12 CET] <JEEB> Ut Video or huffyuv or ffvhuff is generally stuck into AVI since vfw codecs were usually utilized to edit those [20:47:16 CET] <deltasquared> hell I'm not audio grabbing at the moment... [20:47:32 CET] <Mavrik> Yeah, ffvhuff in AVI seems something that would work. :) [20:47:40 CET] <deltasquared> JEEB: I'm not seeing ffvhuff listed in ffmpeg-codecs [20:47:56 CET] <deltasquared> distro is arch linux. I'll dump the build flags if need be [20:48:23 CET] <JEEB> http://up-cat.net/p/fcee509a [20:48:33 CET] <JEEB> my branch I just built [20:48:33 CET] <deltasquared> configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg [20:48:33 CET] <deltasquared> --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-nvdec --enable-nvenc --enable-omx --enable-shared --enable-version3 [20:48:37 CET] <JEEB> it]s internal, too [20:48:46 CET] <deltasquared> ... oops, watch the flood limit, my derp [20:49:04 CET] <JEEB> I think the only dependency is zlib -- if even that? [20:49:26 CET] <deltasquared> ah yes, it's here [20:49:43 CET] <deltasquared> so, -vcodec ffvhuff -pix_fmt rgb24? [20:50:09 CET] <deltasquared> assuming x11 is operating in 24-bit colour mode... [20:50:17 CET] <Mavrik> You probably won't need the pix_fmt since the default is to avoid conversion. [20:50:21 CET] <deltasquared> right. [20:51:48 CET] <deltasquared> ... yow that file size though... I'm going to need a bigger disk [20:52:37 CET] <JEEB> yea it's lossless and intra only and simple [20:52:55 CET] <deltasquared> does it at least try to do something with the frames themselves? [20:53:04 CET] <deltasquared> i.e. is it at least better than raw [20:53:08 CET] <Mavrik> Well, it's way better than RAW [20:53:17 CET] <JEEB> yes, it's zlib-like and has some simple left/median prediction [20:53:22 CET] <JEEB> nothng like modern encoders of course [20:53:41 CET] <deltasquared> 714MB in 30 seconds though... ouch [20:54:28 CET] <deltasquared> 25MB/s or thereabouts... but that is better than 90MB/s or thereabouts for raw though [20:54:41 CET] <deltasquared> it's also faster than one PNG per frame thus far :P [20:55:26 CET] <Mavrik> The other option is to of course use a HW encoder if you have one [20:55:46 CET] <deltasquared> Mavrik: I tried that. my quicksync encoder (ivy bridge mobile chip) produces trash colouring... [20:56:06 CET] <Mavrik> I'm guessing broken reds? [20:56:44 CET] <deltasquared> Mavrik: broken everything... including this weird seizure inducing flicker in 3D games, like the scenery was missing every other frame but the skybox was there... only in the recording though [20:56:54 CET] <deltasquared> I have no clue what was causing that [20:56:59 CET] <deltasquared> that was kmsgrab to boot [20:58:11 CET] <deltasquared> I could try using quicksync in x11 I guess, though there would be a hwupload penalty. [20:58:27 CET] <deltasquared> input via kmsgrab causes system lockups occasionally. [20:58:40 CET] <deltasquared> needless to say it has felt like rock and a hard place at times... [20:59:10 CET] Action: deltasquared does some disk space calculations [20:59:48 CET] <deltasquared> assuming a conservative 30MB/s, 10 minutes would rack up 18GB. it's a bit oof but not completely unworkable I guess [21:00:34 CET] <Mavrik> 4TB drives are not that expensive these days :) [21:00:41 CET] <deltasquared> I should try using simplescreenrecorder again if I'm going with ffvhuff. I tried that with libx264 before but it was pushing the encoding to make the deadline, so the output was utter trash [21:01:03 CET] <deltasquared> Mavrik: oh great, just when I thought I wouldn't need spinning rust in my laptop again :/ [21:01:25 CET] <deltasquared> then again I do have this optical bay spare :) [21:05:26 CET] <deltasquared> gah, sss has still managed to end up doing yuv conversion... [21:06:14 CET] <deltasquared> I wish ffmpeg had an opengl hook library shipped with it. I'd prefer to be able to take more direct control... SimpleScreenRecorder seems to assume too many things [21:06:31 CET] <JEEB> check out libplacebo [21:06:38 CET] <deltasquared> hmm? [21:06:39 CET] <JEEB> if you need GPU colorspace conversions or resizing [21:06:52 CET] <JEEB> you could just utilize that + the FFmpeg APIs [21:07:50 CET] <deltasquared> how would this lib do the opengl hooking though? doesn't seem to be for that based on the description... unless I'm looking at the wrong thing [21:08:58 CET] <JEEB> I was mostly pointing you towards the colorspace conversion and resizing stuff, not hooking [21:09:20 CET] <deltasquared> right. [21:10:46 CET] <deltasquared> JEEB: at the very least, of all the options I've tried thus far ffvhuff has managed to remain realtime. [21:11:54 CET] <deltasquared> I wonder if kmsgrab would knock it down further... but alas that never seems to play ball without a CPU-side format filter present [21:12:33 CET] <deltasquared> somewhat defeating the object of performance [21:12:57 CET] <JEEB> if you were getting unalignment messages then you'd have to look into if you can improve the alignment of your input pictures [21:13:03 CET] <JEEB> otherwise all the SIMD couldn't be utilized [21:13:20 CET] <deltasquared> JEEB: I guess the weird resolution didn't help [21:13:29 CET] <deltasquared> let me see what that looks like in binary powers, one sec [21:14:06 CET] <JEEB> well even with weird resolutions as long as the buffer is properly allocated you should be able to get alignment [21:14:27 CET] <JEEB> esp. since your line-to-line length doesn't have to be width [21:14:31 CET] <deltasquared> 1366x768x3 looks like it should be align-able to 512 bytes... [21:14:43 CET] <deltasquared> [user@hydrocarbon scratch]$ dc -e '1366 768 * 3 * 2 o p' [21:14:44 CET] <deltasquared> 1100000000011000000000 [21:14:55 CET] <JEEB> I'd check the module if it's allocating the images itself [21:15:01 CET] <JEEB> if it is, then it's simple [21:15:04 CET] <deltasquared> what, x11grab? [21:15:11 CET] <JEEB> or kmsgrab or something like that [21:15:19 CET] <deltasquared> x11grab is where I saw those messages [21:15:25 CET] <deltasquared> is there a function I'd look out for [21:15:38 CET] <deltasquared> also where's said sauce code in a hurry [21:15:53 CET] <Hello71> >dc [21:15:55 CET] <Hello71> pls [21:16:00 CET] <JEEB> libavdevice/xcbgrab.c: .name = "x11grab", [21:16:21 CET] <deltasquared> Hello71: haunting me on #archlinux-offtopic wasn't bad enough? :P [21:16:34 CET] <deltasquared> I *like* my RPN [21:16:35 CET] <JEEB> yea, seems like it just gets a buffer [21:16:47 CET] <deltasquared> oh, so from xcb or whatever? [21:16:49 CET] <JEEB> xcb_shm_attach [21:16:51 CET] <deltasquared> ah. [21:16:58 CET] <JEEB> and shmget before that [21:17:21 CET] <deltasquared> well surely that'd be 4k aligned...? [21:17:25 CET] <JEEB> and then data = shmat(id, NULL, 0); [21:17:39 CET] <JEEB> deltasquared: well buffer vs the actual image within that buffer and all other things [21:17:45 CET] Action: deltasquared hurriedly reads man pages [21:17:46 CET] <JEEB> you could add more logging there [21:18:05 CET] <deltasquared> you'll forgive me I'm not set up to rebuild all the things at this time :P [21:18:14 CET] <deltasquared> (also wouldn't that get fairly verbose at 30fps...) [21:18:21 CET] <JEEB> not really, I've done worse :P [21:18:33 CET] <deltasquared> something tells me I don't want to know [21:18:37 CET] <JEEB> (parsers logging multiple times before a single packet gets through) [21:19:17 CET] <deltasquared> JEEB: so if x11 was for some reason daft with alignment I'd run into that issue I guess [21:20:02 CET] <JEEB> yes [21:20:15 CET] Action: deltasquared decides to try seeing what ffvhuff does with just "hwdownload" from kmsgrab [21:22:27 CET] <deltasquared> invalid output format gray for hwframe download... hmm [21:22:42 CET] <deltasquared> I assume it's just saying gray because nothing else told it [21:23:38 CET] <deltasquared> man page > "may be necessary to insert an additional format filter" reeee [21:24:18 CET] <deltasquared> I've tried to use scale_vaapi to help me out here before as well but the same message seemingly appears if you have hwdownload as the last thing in the chain [21:25:51 CET] <deltasquared> using hwmap instead gives "failed to map frame: -38". I assume that's the warning I've seen in places about failure if the buffer isn't linearly mappable [21:27:14 CET] <deltasquared> JEEB: actually, a thought occurs, does the format filter actually necessarily do any work? or is it just there to idk hint that the previous stages should output in a certain format [21:27:27 CET] <deltasquared> because I certainly didn't order gray as a pixel format for instance [21:27:36 CET] <JEEB> it's a hint and doesn't necessarily make any conversions if not necessary [21:27:44 CET] <JEEB> a meta-filter in a way [21:28:57 CET] <deltasquared> right. trying hwdownload again, I've tried setting pix_fmt specifically to rgb24 after -vcodec and the error message changes to "invalid output format rgb24", so it at least gets the hint, but still doesn't seem to like it [21:41:20 CET] <deltasquared> sigh, I guess I'll just have to resign myself to sticking with x11grab for the time being. it is certainly more flexible at least. doesn't require root, for one. [21:42:56 CET] <deltasquared> not wise to be tinkering with video encodes when you've got a headache as it is heh [00:00:00 CET] --- Mon Jan 28 2019

1 0

ffmpeg-devel.log.20190126
by burek 27 Jan '19

27 Jan '19

[01:25:08 CET] <meredydd> Hi all; I just submitted my first ffmpeg patch (adding a 'delay' filter). Am happy to take feedback here or on the mailing list. [01:43:20 CET] <Compn> meredydd : just remember to idle a while, we all have different hours on irc :) [13:52:13 CET] <cone-458> ffmpeg 03Peter Ross 07master:1dfd7aecf26e: avcodec/vp3dsp: move vp3 init loop filter function to vp3dsp [13:52:13 CET] <cone-458> ffmpeg 03Peter Ross 07master:19565c602601: avcodec/vp3dsp: add 12 pixel loop filter functions [13:52:13 CET] <cone-458> ffmpeg 03Peter Ross 07master:f4756ee9f7cc: avcodec/vp3dsp: add 10 coefficient version of the VP3 IDCT [13:52:13 CET] <cone-458> ffmpeg 03Peter Ross 07master:10a57f55e609: avcodec/vp6: use rounded shift for chroma motion vector calculation [13:52:13 CET] <cone-458> ffmpeg 03Peter Ross 07master:160ebe0a8d78: avcodec/vp6: use ff_vp3dsp_[hv]_loop_filter_12 [13:52:13 CET] <cone-458> ffmpeg 03Peter Ross 07master:d8ebfd1bdf7e: avcodec/vp6: select idct based (loosely) on number of coefficients decoded [14:02:52 CET] <pross> thx cehoyos [00:00:00 CET] --- Sun Jan 27 2019

1 0

ffmpeg.log.20190126
by burek 27 Jan '19

27 Jan '19

[00:06:55 CET] <SpeakerToMeat> Is there any way I can crop a piece of a video in ffmpeg, shift it down and overlay it on the same video? [07:46:43 CET] <rnmhdn> how can I make the iframes of a video file regular? [07:47:08 CET] <rnmhdn> so that I have an iframe every say 3 seconds [07:48:34 CET] <furq> depends on the codec [07:49:36 CET] <furq> -g will either set a fixed keyframe interval or the maximum keyframe interval, but then you might also need to disable scenecut or something like that, which is encoder-specific [09:00:43 CET] <rnmhdn> I want to create a dash stream with fixed intervals [09:00:54 CET] <rnmhdn> the problems is my video has fixed intervals but not my audio [20:06:46 CET] <illuminated> if you're going to pass the -y option for overwrite.. do you pass it in before -i? [20:06:59 CET] <illuminated> or does it matter where it is? [20:20:46 CET] <johnjay> ffmpeg source is scary. is there some simpler source i could look at first to understand image processing? [20:24:10 CET] <JEEB> you probably want to know some specifics, FFmpeg just does a whole crapload of things :P [21:00:35 CET] <deltasquared> why do I always get into fights with kmsgrab... I've previously had kmsgrab working with a filter chain that looks like this: "hwmap,scale_vaapi=format=nv12,hwdownload" which was then encoded to MP4. Now when trying instead to save output to one png per frame as an experiment, I get "invalid output format monob ...". [21:01:43 CET] <deltasquared> Out of curiosity I tried seeing if the scale_vaapi filter could take other formats; I tried "rgb8" (I just made it up, not read it anywhere) and evidently that didn't work... so my first question, can I get ffmpeg to tell me what the vaapi device's supported pixel formats are? [21:03:14 CET] <cluelessperson> do you know where I can find a list of the file extensions that ffmpeg supports? [21:05:16 CET] <Mavrik> ffmpeg -formats ? :) [21:05:29 CET] <deltasquared> cluelessperson: I don't know about file extensions per se, but my understanding is that "man ffmpeg-formats" describes which containers are supported (for instance, "mp4" which is what it sounds like - but one must also consider codecs as well, e.g. the mp4 container doesn't support every codec under the sun like say mkv does) [21:06:05 CET] <deltasquared> that said, I'd be surprised to come across a container format that ffmpeg doesn't understand [21:06:08 CET] <cluelessperson> Mavrik: that's not a list of file extensions [21:06:24 CET] <cluelessperson> the goal is to programmatically control what files are displayed in a media thing [21:07:15 CET] <deltasquared> cluelessperson: extensions used by container formats are sometimes just convention; they aren't a hard and fast indication of encodings etc. [21:07:48 CET] <cluelessperson> then what's the point [21:07:50 CET] <deltasquared> hence I don't see how asking ffmpeg's supported "file extensions" (which I don't think it really cares about mostly) would help [21:08:25 CET] <deltasquared> the only time ffmpeg really cares about file extensions is when you just give it an output file and it tries to guess what you want [21:08:32 CET] <deltasquared> err output filename rather [21:10:16 CET] <deltasquared> cluelessperson: in any case when you say programmatically control files that are shown... how so [21:10:50 CET] <deltasquared> brb... there's a rodent loose in the house [21:11:25 CET] <cluelessperson> deltasquared: for example, I'm obviously not going to playback pdf files [21:21:22 CET] <deltasquared> cluelessperson: the thing is though, some media formats have rather generic extensions - some edge cases would be .bin, .dat and so on. that said, seeing as ffmpeg is fairly versatile, you could just get a list somewhere of known extensions that are unique to media files - if it's in such a list there's a good chance ffmpeg would handle it (and anything using it's libraries... mpv comes to mind) [21:21:30 CET] <deltasquared> as to where you'd find such a list, search me. [21:22:14 CET] <Mavrik> I'm guessing you could parse them out of libavformat source :) [21:22:32 CET] <Mavrik> But TBH I see no reason why you wouldn't just attempt to play a PDF file and fail if it's not readable :) [21:24:00 CET] <deltasquared> does ffmpeg have different exit codes for that situation? e.g. "I don't recognise this" vs "this was corrupt" or "your sound card caught fire" [21:24:36 CET] <Mavrik> I'm not sure a meaningful difference can be made [21:24:52 CET] <Mavrik> There are some error codes but for a lot of cases there's no difference between corrupt and wrong file [21:25:25 CET] <deltasquared> Mavrik: I would have thought a malformed header somewhere in the middle would be easy to tell apart from simply being unable to find any matching magic numbers, for instance [21:25:39 CET] <deltasquared> sure, it's not 100% black and white, but it'd be a good enough guess most of the time [21:25:48 CET] <tdr> it should know if theres bad magic bits [21:27:21 CET] <Mavrik> deltasquared, mhm, no idea if the ffmpeg binary does that, if you use the API then of course you know what failed [21:27:23 CET] <Mavrik> https://github.com/FFmpeg/FFmpeg/search?q=.extensions&unscoped_q=.extensions [21:27:33 CET] <Mavrik> This seems like a reasonable list of extensions ffmpeg knows tho :) [21:28:14 CET] <tdr> or can [21:31:22 CET] <deltasquared> Mavrik: you mean libavformat/rawenc.c? [21:32:29 CET] <deltasquared> or rather everything in that list defining an AVInputFormat... that'd be painful to comb through though >_> [21:33:31 CET] <Mavrik> deltasquared, a simple grep over ".extensions" in all "*dec.c" should give you the most. [21:33:41 CET] <Mavrik> Over everything in avformat if you want it to be complete [21:34:52 CET] <deltasquared> Mavrik: it occurs that it may still need some filtering... I would hope nothing would be daft enough to try and claim something as generic as .bin say, but I'd personally want to watch out for those sort of overloaded file extensions anyway [21:37:30 CET] <deltasquared> anyway, re: my kmsgrab thing earlier, the script invoking ffmpeg is https://ptpb.pw/sQRv.txt and the output I got back is https://ptpb.pw/IhOw (warning, terminal colour escape sequences in the latter) [21:38:26 CET] <deltasquared> I guess just curl the latter one in a terminal. then you can see the colours too ;) [22:18:01 CET] <deltasquared> aha, format=bgr0 seems to do the trick... but I only discovered that from a random internet search finding a bug ticket, which is less than ideal [00:00:00 CET] --- Sun Jan 27 2019

1 0