June 2019 - Ffmpeg-devel-irc - lists.ffmpeg.org

ffmpeg-devel.log.20190616
by burek 17 Jun '19

17 Jun '19

[01:42:01 CEST] <kierank> michaelni: thx [04:53:18 CEST] <pross> these fuzzing services provided to open source projects seem like a cheap way to collect large amounts of training data [10:09:02 CEST] <cone-241> ffmpeg 03Michael Niedermayer 07master:2603f25d3264: avcodec/bink: Reorder operations in init to avoid memleak on error [10:09:02 CEST] <cone-241> ffmpeg 03Amir Pauker 07master:edfced8c045c: avutil: add FF_DECODE_ERROR_CONCEALMENT_ACTIVE flag for AVFrame.decode_error_flags [10:09:02 CEST] <cone-241> ffmpeg 03Limin Wang 07master:1c3ed1189313: doc/filters.texi: Fix the confusing description for find_rect and cover_rect command [13:00:58 CEST] <JEEB> should I make a patch to disable the connection re-usage from TLS with schannel? [13:01:08 CEST] <JEEB> since it seems like schannel performance just goes way down when that's enabled [13:11:27 CEST] <nevcairiel> schannel overall has an issue where it breaks down on some connections, and the API is so convoluted that I couldn't figure out why, hence I'm using gnutls now :D [13:12:33 CEST] <JEEB> :D [13:12:38 CEST] <JEEB> yea, I've seen various people do that [13:13:47 CEST] <nevcairiel> i implemented it roughly base on the implementation in curl i think, but not sure if I made a snafu or whatever, but I couldn#t figure it out [16:53:27 CEST] <stuartm> Out from -progress includes the following issue: [16:53:31 CEST] <stuartm> out_time_us=51440078 [16:53:32 CEST] <stuartm> out_time_ms=51440078 [16:54:19 CEST] <stuartm> Is there some legacy, intentional reason that it's outputting the millisecond value in microseconds? [16:55:01 CEST] <stuartm> Or should I just open a ticket with patch? [17:17:11 CEST] <nevcairiel> It was a bug, and cannot be changed without breaking scripts that rely on the current behavior, hence the correct second one was added, so the old one can be removed or fixed at a later date [00:00:00 CEST] --- Mon Jun 17 2019

1 0

ffmpeg.log.20190616
by burek 17 Jun '19

17 Jun '19

[01:39:28 CEST] <linext> hi [04:43:08 CEST] <grosso> hi [04:46:15 CEST] <grosso> in muxing.c example, the new version that uses "codecpar" instead of "codec", there is an issue when output format is "flv" through librtmp library [04:47:32 CEST] <grosso> with the old version using "codec" everythig works, but you receive lot of deprecation warnings [04:47:48 CEST] <grosso> I'm working with 3.3.9 release [04:50:07 CEST] <grosso> then, with the new code, those deprecation warnings are gone, but muxing don't work anymore... turns out that flvenc.c is looking for settings in the old "codec" AVCodecContext, instead of using codecpar struct [04:51:41 CEST] <grosso> when you run the new code, an error message appears in the log, saying that "flv output don't support a codec type NULL in stream[0]" or something like this [04:55:46 CEST] <grosso> ...inmediately after opening the output file via avio_open [04:56:37 CEST] <grosso> line 620 [08:06:46 CEST] <Sur3> Hi, when i try to use vaapi with ffmpeg it says "libva info: va_getDriverName() returns -1" but when i call vainfo directly it returns 0, what could be the problem? [08:08:13 CEST] <Sur3> https://pastebin.com/raw/2hQNCRrA [10:35:48 CEST] <dstaring> I currently use these commands to convert any audio file to .flac and any image file to .png or any video file to .avi. They work, but it bothers me that they are different with the -q:a and -q:v stuff. Is it not possible to make a more generic, minimalistic ffmpeg command that simply converts *any* kind of file losslessly to the output format, whether it's an audio, still picture or video file? [10:36:01 CEST] <dstaring> ffmpeg -i "INPUT PATH" -q:a 0 "OUTPUT PATH.flac" [10:36:03 CEST] <dstaring> ffmpeg -i "INPUT PATH" -q:v 0 "OUTPUT PATH.png" [10:36:05 CEST] <dstaring> ffmpeg -i "INPUT PATH" -q:v 0 "OUTPUT PATH.avi" [10:36:32 CEST] <dstaring> I feel like I'm doing something wrong by specifically mentioning "-q:a 0" and whatnot. [10:37:10 CEST] <dstaring> A "-lossless" generic flag would be so much nicer. [10:37:18 CEST] <dstaring> (And it should be implied by default anyway) [10:38:14 CEST] <dstaring> Actually, I made a typo. The .avi one actually has both: -q:a 0 -q:v 0 [10:47:24 CEST] <dstaring> Can I just always add both "-q:a 0 -q:v 0"? Will that cause problems? [10:47:31 CEST] <dstaring> Why do they have to be explicitly mentioned in the first place? [10:47:42 CEST] <dstaring> Is this chat room monitored at all? [10:49:32 CEST] <furq> -q doesn't do anything for flac [10:50:02 CEST] <furq> or for png for that matter [10:54:47 CEST] <dstaring> So what would be the correct, generic command? [10:56:15 CEST] <furq> just omit -q for those, they're always lossless [12:42:10 CEST] <dstaring> furq: Please read what I asked... [12:42:38 CEST] <dstaring> Is it not possible to make a more generic, minimalistic ffmpeg command that simply converts *any* kind of file losslessly to the output format, whether it's an audio, still picture or video file? [12:42:54 CEST] <dstaring> Why have all this format-specific BS that has to be added? [12:45:22 CEST] <JEEB> well if you just want to copy streams over, then map all streams and stream copy them into a container that supports all of your use cases? [12:45:25 CEST] <JEEB> if that's what you mean [12:47:00 CEST] <englosh> can ffmpeg convert Opus audio data to wav, ogg or mp3? [12:47:22 CEST] <BtbN> sure, but not losslessly, except for wav [12:47:55 CEST] <JEEB> well you can put opus in ogg in theory, I think? [12:48:01 CEST] <JEEB> although I guess he meant vorbis in ogg [12:48:17 CEST] <JEEB> wav ends up being decoded and raw samples [12:49:25 CEST] <englosh> and how could I convert from Opus to wav? [12:50:23 CEST] <JEEB> ffmpeg -i blah.opus -c pcm_s16le out.wav or something [13:27:22 CEST] <englosh> a PCM file could look like this, right? https://pastebin.com/raw/3rQNzNtX or is that not what a PCM file looks like? [13:29:13 CEST] <JEEB> raw pcm depends 100% on the actual type of raw PCM you're reading [13:29:42 CEST] <JEEB> and it literally can be anything between 0x00~0xFF, which depends then on the type and actual content [13:33:07 CEST] <englosh> it's the stuff I got when decoding Opus data [13:49:34 CEST] <dstaring> JEEB: I don't know how it's possible to misunderstand what I asked. [13:49:51 CEST] <JEEB> I didn't look far enough in back-log what you originally asked :P [13:50:08 CEST] <JEEB> I just noted based on your most recent thing [13:50:37 CEST] <dstaring> I want to convert input file X into output file Y, losslessly, and the format to be determined by the Y file's extension (as FFmpeg already does). [13:50:51 CEST] <dstaring> And not have to use different commands for each format. [13:51:05 CEST] <dstaring> Specifically regarding the -q:a 0 -q:v 0 stuff. [13:51:23 CEST] <dstaring> Right now, I guessed my way into always including "-q:a 0 -q:v 0" and just letting it ignore them whenever it doesn't make sense. [13:51:46 CEST] <dstaring> But it's a command that's difficult to remember and awkward to type, so it seems strange that you have to explicitly state those flags. [13:52:54 CEST] <JEEB> you only need to set those if you're using a format that by default does something else than lossless. f.ex. if your audio format is FLAC and video Ut Video or FFV1 then they're just always lossless [13:53:15 CEST] <JEEB> because f.ex. with libx264 or something like that the most often utilized and the encoder's default mode is indeed to not do lossless [14:09:28 CEST] <cehoyos> dstaring: This is not possible because "q" has a very specific meaning (not "quality") and it was decided that codecs that do not fit this specific meaning should not listen to "q". [14:10:19 CEST] <cehoyos> But if you are using a lossless codec you - as JEEB explained - don't need any quality option. [14:10:41 CEST] <cehoyos> (no lossless codec can be auto-detected by file suffix iirc) [15:03:29 CEST] <dstaring> cehoyos: Huh? If 'codecs that do not fit this specific meaning should not listen to "q"', isn't that exactly what I wanted? [15:03:38 CEST] <dstaring> So it only applies where it matters and is ignored everywhere else? [15:04:28 CEST] <cehoyos> Then you will not get lossless encoding for codecs that do not default to lossless encoding and do not listen to "q" [15:15:20 CEST] <humbolt> Hi there! [15:16:25 CEST] <humbolt> I want to send video data with an alpha channel to another application (all codecs, muxers, formats allowed). [15:17:01 CEST] <humbolt> I want to do it as CPU extensive as possible so I guess I should go with some sort of raw codec. [15:18:26 CEST] <humbolt> However, I am more concerned about the mode of delivery. I presume using mpegts would add to much stream handling CPU load, so I tend to use pipe or a fifo or something like that. [15:18:30 CEST] <humbolt> Any suggestions? [16:28:32 CEST] <kepstin> if humbolt hadn't left, I would have suggested either actual raw video or ffvhuff in nut container [16:32:29 CEST] <dstaring> cehoyos: That sounds idiotic. Why would something not default to lossless and ignore the -q flag? [16:32:53 CEST] <dstaring> It's amazing how many hours of my life I've spent solely on trying to interpret the FFmpeg manual, even while being able to ask people. [16:33:05 CEST] <dstaring> Especially as I have extremely basic FFmpeg needs. [16:35:23 CEST] <BtbN> Because lossless is usually not what you want, so defaulting to it would be bad. [16:35:45 CEST] <BtbN> A lot of codecs don't even support it. [17:02:38 CEST] <linext> are there any good programs for using ffmpeg as a DVR? [17:02:59 CEST] <linext> there are some shows i would like to record at a time for about 30 hour [17:03:12 CEST] <linext> the shows are being streamed from an hdhomerun [17:03:28 CEST] <linext> ffplay and ffmpeg both do well when playing / recording [17:03:41 CEST] <linext> i just want to tell it when to record and for how long [17:06:51 CEST] <JEEB> &41 [17:13:33 CEST] <linext> i've been using this script to record security camera footage: https://ideone.com/YjR2Ub [17:14:28 CEST] <linext> maybe it could be turned into a command line utility and scheduled using windows task scheduler [17:14:34 CEST] <linext> there probably is something better [17:24:38 CEST] <kepstin> dstaring: when using ffmpeg you usually want to be explicit as possible - in particular, do not rely on the default selected codec to be something useful (many of them are historic, and the default sometimes changes between versions of ffmpeg) [17:31:44 CEST] <linext> is it possible to use ffmpeg to put a timestamp in the filename (windows) [17:32:18 CEST] <JEEB> some specific meta-muxers might have that, but I recommend you just make your batch script or whatever add that [17:32:25 CEST] <linext> all right [17:32:28 CEST] <linext> i can do it in php [18:05:19 CEST] <dstaring> BtbN: The mentality that "lossless is not wanted" is what has caused all these countless crappy JPEGs that have been crushed in 632 generations of idiots saving them, adding crap to them and then saving them again as JPEG, eventually uploading it to some shitty "gallery" on a malware-infested porn hub for me to find. The few times I actually get my hands on *actual* digital photos, as in, not a stamp-sized, multi-generation-lossy pile of pixels, it's [18:05:19 CEST] <dstaring> like night and day. Either that, or I'm served a completely different Internet to everyone else. [18:05:38 CEST] <dstaring> Even when I search DuckDuckGo images and select "large size only", there's virtually no photos. [18:06:18 CEST] <BtbN> You realize lossless video is insanely huge, right? [18:06:35 CEST] <BtbN> So huge most home connections couldn't even handle 720p [18:06:36 CEST] <dstaring> Yes, but I was talking about images. [18:07:02 CEST] <dstaring> Home connections? 1080p is default for YouTube videos these days... [18:07:13 CEST] <BtbN> Guess what, YouTube uses lossy codecs... [18:07:41 CEST] <dstaring> No shit. [18:08:00 CEST] <dstaring> A JPEG straight from a camera and a JPEG that was saved 632 times and is 10x smaller is what I'm talking about. [18:08:32 CEST] <BtbN> I have no idea what you are going on about. Of course if you compress lossy over and over again, quality drops. Every re-encode loses a bit. [18:08:32 CEST] <dstaring> The first JPEG, from the camera, is to be considered the original. So if you turn that JPEG into a PNG, it's lossless from the perspective of the original to a new copy. [18:08:43 CEST] <BtbN> JPEG is even special, in that there is no generation loss under certain circumstances. [18:08:59 CEST] <dstaring> "lossless is usually not what you want, so defaulting to it would be bad." [18:09:13 CEST] <dstaring> BtbN: You mean cropping, for example? [18:09:18 CEST] <dstaring> I didn't know that about JPEG, BTW. [18:09:34 CEST] <BtbN> If you crop in multiples of 8, and use the same encoder settings that were used for the original, yes, cropping is lossless with jpeg [18:09:50 CEST] <dstaring> "Multiples of 8" and "same encoder settings" seems awfully specific. [18:10:06 CEST] <BtbN> It's just how jpeg works [18:11:18 CEST] <dstaring> A couple of years ago, I was digitizing a ton of old family photos from physical negatives. They came as JPEGs from the device I used. While doing the work, I didn't think about what I was doing, and in many cases, I would crop them in XnView, change the gamma/contrast/brightness and just save it again as JPEG. In retrospect, this was idiotic, but they were *lots* and *lots*, and maybe they didn't loose data assuming XnView used the same settings as it [18:11:19 CEST] <dstaring> found in the metadata. [18:12:00 CEST] <dstaring> My eyes didn't notice a major quality loss, probably because they looked so much better with the correct lighting. [18:13:04 CEST] <dstaring> (In some cases, it was only cropping or only gamma/contrast/brightness changes.) [18:13:56 CEST] <BtbN> One extra encode won't overly matter at high quality levels [18:15:17 CEST] <dstaring> Maybe not, but now I will forever think: "Maybe that blurry background object could be seen better in the original photo..." [18:17:04 CEST] <dstaring> Of course, it's infinitely better than the result would've been if I had done the same thing 15 years earlier, in 2000 or so. The digital consumer equipment around that time was always highly limited. [18:17:50 CEST] <dstaring> Would've sucked to have spent a lot of efforts back then only to find that it was completely immature. [19:58:03 CEST] <Sur3> Ok i found out i had to set "LIBVA_DRIVER_NAME=radeonsi" for vaapi to find the driver. ^^ [19:58:33 CEST] <Sur3> but i get an other error now: Impossible to convert between the formats supported by the filter 'Parsed_format_0' and the filter 'auto_scaler_1' [20:15:48 CEST] <Sur3> ok it says it has some header problems now, how to solve that? https://pastebin.com/raw/cUxutdRU [20:22:01 CEST] <Sur3> Ok seems it didnt like .mkv, with .avi as output format it seems to work to some extend. ^^ [21:39:00 CEST] <causa-sui> I'm on macos, need to record mic audio -and- desktop audio in a single stream, but I'm too dumb apparently and also not very good with ffmpeg. help? [22:00:10 CEST] <causa-sui> on https://trac.ffmpeg.org/wiki/Capture/Desktop it suggests `ffmpeg -f avfoundation -list_devices true -i ""` but -list_devices isn't an option in the version I have (4.1.3) [22:01:33 CEST] <kepstin> causa-sui: what's the output when you try running that command? [22:05:57 CEST] <causa-sui> kepstin: looking again I think there is a list of input devices here, but I was thrown off by ': Input/output error' at the end (dunno if that's an issue) http://ix.io/1LYs [22:06:34 CEST] <kepstin> causa-sui: yeah, that's what the option does. it prints the list of devices as log messages, then raises a fake io error so the ffmpeg cli exits. [22:06:46 CEST] <causa-sui> kepstin: I see [22:07:22 CEST] <causa-sui> kepstin: so if I want to record input and output into one stream, do I just pass '-i' twice? [22:09:22 CEST] <kepstin> looks like it only supports capture from one video + one audio device in a single input, so you'd have to use a second input if you have multiple audio devices. [22:10:34 CEST] <causa-sui> kepstin: right, but can I record two inputs in a single command or do I have to record in separate threads and somehow merge them after the fact? [22:11:54 CEST] <kepstin> you can use multiple inputs in a single ffmpeg command. note that it'll give you multiple separate audio streams - if you want them mixed you'll have to use filters [22:12:22 CEST] <kepstin> there's some quirks about ffmpeg's input handling - it opens inputs one at a time - which means the second input might not be synced perfectly with the first. [22:12:33 CEST] <causa-sui> that's ok [22:13:18 CEST] <causa-sui> I guess the "audio device index" is 1 in this case since I want the "Macbook Pro Microphone", but what is the "screen device index" here? [22:14:57 CEST] <kepstin> see the docs at https://ffmpeg.org/ffmpeg-devices.html#avfoundation [22:15:38 CEST] <kepstin> and you have to reference the output of -list_devices on your system, I have no idea what it would be [22:16:12 CEST] <causa-sui> kepstin: that's the ix.io link I pasted above [22:16:14 CEST] <causa-sui> I think [22:16:37 CEST] <kepstin> oh, i see. [22:16:40 CEST] <urdne> hello duders, i have been trying to convert some VP8 webms into mp4s. i noticed that in some of the videos, (perhaps ones with a yellow tint in the general chromatic landscape?) the whole video gets color shifted. you can see the effect by flipping between the pics here https://imgur.com/a/1uKeRdD - the webms used are identical in terms of encoding parameters [22:16:42 CEST] <causa-sui> this avfoundation doc is helpful, thank you [22:16:51 CEST] <kepstin> well, you have some "capture screen" devices listed... pick one? [22:17:13 CEST] <causa-sui> kepstin: just to confirm, I'm trying to record desktop _audio_ output and also the microphone together [22:17:41 CEST] <kepstin> causa-sui: ah, i don't know how to record desktop audio output on a mac. [22:17:46 CEST] <urdne> also, post-conversion, ffmpeg emits this error in all cases (but still spits out a working-fine mp4:) [matroska,webm @ 000001d6eea69200] Element at 0x2e8378 ending at 0x2e83c2 exceeds containing master element ending at 0x2e836c [22:18:13 CEST] <causa-sui> argh. [22:18:15 CEST] <kepstin> urdne: that error message indicates a corruption in the input webm file [22:18:43 CEST] <kepstin> urdne: probably not a big issue, maybe the file was truncated or something? [22:18:58 CEST] <urdne> it could be that it has no metadata? [22:19:50 CEST] <urdne> in any case if the error is unrelated to the random spray-tan ffmpeg gives my videos, i don't mind it [22:20:30 CEST] <kepstin> urdne: it would be helpful to see the ffmpeg command line you're running and the complete output, please pastebin it. [22:21:32 CEST] <urdne> https://pastebin.com/znKBB588 [22:24:01 CEST] <kepstin> hmm, so 420 sampling, no conversions being done. what video player are you using? [22:24:21 CEST] <urdne> whatever release of mpc-hc is in the latest k-lite [22:24:39 CEST] <kepstin> mind trying, hmm, mpv to compare? [22:25:01 CEST] <kepstin> i'm wondering if the difference might be due to the player/decoder setup rather than the video itself [22:25:59 CEST] <kepstin> one possibility is that the video doesn't have the color space tagged properly, and that one of the formats is being interpreted as rec.601, the other as rec.709. I don't know if that would cause this particular noticable change tho. [22:26:07 CEST] <urdne> same thing on mpv [22:26:45 CEST] <urdne> i can send you the webm and mp4 if you wanna look [22:27:21 CEST] <kepstin> what's the source of the webm? (what software recorded it?) [22:27:47 CEST] <urdne> shadowplay [22:28:35 CEST] <kepstin> ... shadowplay records webm files? with vp8? that's kinda unexpected. [22:29:31 CEST] <urdne> originally they were mp4s ofc, but i converted them into vp8s - it so happens that today i no longer have the original mp4s, and adobe premier won't play well with webms [22:30:06 CEST] <kepstin> I assume you used ffmpeg to make the webms then? [22:30:16 CEST] <urdne> yeah [22:30:23 CEST] <kepstin> did you check that the colours matched the original when you did that? [22:30:41 CEST] <urdne> nay, i didn't [22:30:49 CEST] <urdne> none of them really looked orangeish like this though [22:30:57 CEST] <urdne> it's a pretty noticeable change [22:32:52 CEST] <urdne> https://mega.nz/#F!vNBzgIiR!DBXcJVElB_IgUbdEsEP8zA here is the webm and the cheeto dusted mp4 [22:36:28 CEST] <kepstin> so i can't see any difference between the two when playing with mpv, and it notes that it's using rec709 primaries and rec601 transfer for both, hmm. [22:36:45 CEST] <kepstin> mind hitting 'i' in mpv when you're playing them to check what it says? [22:37:47 CEST] <urdne> i'm getting the same here, but she's still orange [22:38:50 CEST] <urdne> adobe premier seems to also process it with full orangeness [22:38:51 CEST] <kepstin> hmm. well, this issue looks consistent with a rec601/rec709 confusion - interpreting 601 content as 709 causes saturated colors to become more saturated. should be fixable. [22:39:13 CEST] <kepstin> (apparently this is a weirdness about shadowplay in particular) [22:39:45 CEST] <urdne> is there some flag i can add to lecture ffmpeg that the output should be 601? [22:43:35 CEST] <kepstin> you'll probably want to convert to 709 for best compatibility. try using `-vf colormatrix=src=bt601:dst=bt709` when encoding the mp4 [22:45:09 CEST] <durandal_1707> do not use colormatrix, its obsolete and wrong [22:47:08 CEST] <kepstin> durandal_1707: could probably use a documentation update then... what's your suggested replacement? [22:49:06 CEST] <durandal_1707> colorspace or zscale [22:51:39 CEST] <kepstin> hmm. so for this particular case, probably colorspace=itrc=smpte170m:trc=bt709 would do the desired conversion, i think. [22:52:29 CEST] <kepstin> (assuming shadowplay recorded using srgb/bt709 primaries+colorspace, and only got the transfer wrong) [22:55:31 CEST] <urdne> >[NULL @ 000001450551d600] Unable to find a suitable output format for 'colorspace=itrc=smpte170m:trc=bt709' [22:55:33 CEST] <urdne> hlep [22:56:09 CEST] <furq> there's a vp9 bitstream filter that sets the colorspace [22:56:12 CEST] <furq> idk if it works for vp8 [22:56:30 CEST] <kepstin> urdne: i think you clipped out the important part of the ffmpeg output that ways what the error is [22:56:45 CEST] <urdne> [NULL @ 000001450551d600] [22:56:56 CEST] <urdne> oh wait uhh [22:57:13 CEST] <urdne> fug i don't know man. i don't use ffmpeg much as you can tell [22:57:24 CEST] <urdne> i wish it was not this much wizardry to turn a webm into a mp4 [22:57:25 CEST] <kepstin> urdne: but using my mind reading powers and some documentation, i think you probably need to use 'colorspace=itrc=smpte170m:all=bt709' instead of what i originally told you [22:57:39 CEST] <furq> [AVBSFContext @ 00000168474dea00] Codec 'vp8' (139) is not supported by the bitstream filter 'vp9_metadata'. Supported codecs are: vp9 (167) [22:57:42 CEST] <furq> shame [22:57:55 CEST] <kepstin> it normally works, this is apparently related to an old shadowplay weirdness [22:58:12 CEST] <kepstin> https://forums.geforce.com/default/topic/795006/shadowplay-bugs-wrong-color… is someone else running into an issue that looks very similar [22:58:36 CEST] <furq> urdne: -vf 'colorspace=itrc=smpte170m:all=bt709' [22:59:36 CEST] <urdne> [AVFilterGraph @ 0000015896f5b400] No such filter: 'colorspace=itrc=smpte170m:all=bt709' Error reinitializing filters! Failed to inject frame into filter network: Invalid argument Error while processing the decoded data for stream #0:0 [23:00:14 CEST] <kepstin> urdne: paste the *complete* output please [23:00:20 CEST] <kepstin> and the full command line as you ran it [23:01:11 CEST] <urdne> oh i did but IRC truncated lines, here https://pastebin.com/fMCAQqQj [23:01:24 CEST] <kepstin> this might be a quoting issue actually? if you're running on windows i think single-quotes don't work properly? [23:01:37 CEST] <kepstin> just drop the quotes they're not needed for that filter description [23:02:00 CEST] <urdne> tried doublequotes and no quotes, both no dice [23:02:32 CEST] <kepstin> uhh. what does "ffmpeg -h filter=colorspace" print? [23:03:12 CEST] <furq> it's weird that it's not parsing the = [23:03:32 CEST] <furq> the error message should just show the filter name even if it's not recognised [23:03:48 CEST] <kepstin> yeah, that's why i was thinking the quotes might be an issue [23:03:51 CEST] <urdne> with the quotes it prints nothing, without quotes it prints https://pastebin.com/AA3SJWa4 @kepstin [23:04:09 CEST] <kepstin> right, so it works. remove the single quotes [23:04:33 CEST] <urdne> https://pastebin.com/m5rRx0fS [23:04:59 CEST] <kepstin> alright, *now* we have a message that's useful :) [23:05:40 CEST] <kepstin> I guess you'll also have to set the input primaries. since you seemed ok with the mpv playback of the webm, add :iprimaries=bt709 to the end of the filter string [23:08:54 CEST] <urdne> seems to have worked [23:09:22 CEST] <urdne> danke for all the help, you have dusted the cheeto film off my webms [00:00:00 CEST] --- Mon Jun 17 2019

1 0

ffmpeg-devel.log.20190615
by burek 16 Jun '19

16 Jun '19

[15:29:11 CEST] <durandal_1707> michaelni: what was wrong with trac? [18:52:18 CEST] <durandal_1707> michaelni: why are you not responding? [20:46:21 CEST] <kierank> durandal_1707: do not disturb michaelni important fuzzing work [20:48:06 CEST] <durandal_1707> google have army of bots doing fuzzing work, michealni is doing something else entirely [20:50:05 CEST] <durandal_1707> FFmpeg is certainly in dictatorship, bunch of powers are in one guy [21:31:31 CEST] <jamrial> wtf is wrong with you two? [00:00:00 CEST] --- Sun Jun 16 2019

1 0

ffmpeg.log.20190615
by burek 16 Jun '19

16 Jun '19

[00:16:04 CEST] <friendofafriend> With the deprecation of ffserver, is there something I should be using instead? [00:16:36 CEST] <DHE> a couple of options depending on what you want. HLS or DASH are high latency but require only an HTTP server. nginx-rtmp is a more traditional replacement [00:57:10 CEST] <friendofafriend> DHE: Is that live555 thing worth it to try? [00:57:36 CEST] <friendofafriend> I can't use anything high latency, that's why I'm dumping icecast anyway. [10:05:25 CEST] <TekuConcept> Trying to resolve a curious error when calling avformat_open_input() - sometimes it returns "Invalid data found when processing input" - I'm calling open an a local live RTSP stream [19:04:10 CEST] <ncouloute> Is there no way maintain exact timestamp of the input when converting fps. It looks like the fps filter has a few rounding methods so maybe the rounding is what is causing it to be off by ~4-8 frames. Also it seems the nature of cfr is that it needs to drop/duplicate frames in order to maintain the cfr. Like I could take the existing frames and just retime them as cfr. [19:18:59 CEST] <DHE> the timestamps are relative to the time-base. some formats have fixed time bases, others are flexible and allow you to set the timebase to the framerate (inverse of), then the pts just becomes a frame counter for video. [19:53:37 CEST] <linext> what's the best media player for a windows computer to play a hdhomerun stream? [19:54:57 CEST] <ncouloute> Yeah so I'm using ffms2 which apparently writes out the PTS of each frame with a time base of 1000. Similar to the mkvtimestamp_v2 of ffmpeg. In which case I would just take that number as the number of miliseconds? [19:58:07 CEST] <DHE> ncouloute: basically yes [20:03:18 CEST] <ncouloute> So I think that logic is correct. Issue must be with how I'm calculating the frame number of the resulting file. So I take that PTS number. lets call it x. X * (FPS/1000) = frame number.. (FPS is 60000/1001 in this case) Although that assumes ffmpeg is making a file with a timebase of 1000. Which doesnt appear to be the default. I have a tbn of 60k and a tbc of 59.94. [00:00:00 CEST] --- Sun Jun 16 2019

1 0

ffmpeg-devel.log.20190614
by burek 15 Jun '19

15 Jun '19

[04:31:28 CEST] <cone-025> ffmpeg 03Zhong Li 07master:4208b428c473: lavf/qsv_vpp: add frame format option [04:56:59 CEST] <cone-025> ffmpeg 03Steven Liu 07master:fa7a6dbd7607: avformat/hlsenc: add EXT-X-I-FRAMES-ONLY tag support [04:57:01 CEST] <cone-025> ffmpeg 03Steven Liu 07master:aea524e6e325: avformat/dashdec: add http_proxy, referer and rw_timeout http method support for segments [04:57:02 CEST] <cone-025> ffmpeg 03Steven Liu 07master:5d0652916f2f: avformat/hls: avformat_find_stream_info when the audio list in the variant [04:57:02 CEST] <cone-025> ffmpeg 03Steven Liu 07master:bee0fba7e69f: avformat/hls: add http 2.0 version number compare for the http_multiple [07:26:59 CEST] <cone-025> ffmpeg 03Jun Zhao 07master:c351873e06be: lavf/webvtt: fix ffmpeg -h demuxer=webvtt can't dump options [07:27:00 CEST] <cone-025> ffmpeg 03Jun Zhao 07master:6f34fca8a8ad: doc/formats: document f_strict/strict for AVFormatContext [07:27:01 CEST] <cone-025> ffmpeg 03Jun Zhao 07master:c432a91d252f: doc/fftools-common-opts: document ffmpeg -h bsf=bitstream_filter_name [07:27:02 CEST] <cone-025> ffmpeg 03Jun Zhao 07master:6f82bf9dd30d: lavf/hls: More log message [11:07:11 CEST] <cone-025> ffmpeg 03Steven Liu 07master:665759c3c803: avformat/dashdec: check copy_init_section memory alloc result [12:41:35 CEST] <jidckii> Hello to all. Tell me, are there any problems at work https://trac.ffmpeg.org/wiki ? For several weeks, it opens very slowly. [12:56:36 CEST] <jidckii> example https://i.imgur.com/mEBqwHD.png [13:21:08 CEST] <durandal_1707> michaelni: there are huge issues with trac server, please fix it [13:46:07 CEST] <cone-025> ffmpeg 03Limin Wang 07master:24321b8751b7: libavfilter/vf_blend.c: remove duplicate code with same function [13:46:08 CEST] <cone-025> ffmpeg 03Limin Wang 07master:c9c1711f4961: libavfilter/vf_blend.c: remove duplicate code with macro-defined function [18:10:20 CEST] <kierank> durandal_1707: good live resampler is hard [19:33:08 CEST] <durandal_1707> kierank: fake! [19:33:48 CEST] <kierank> durandal_1707: fix my lipsync problem, kthx [19:34:22 CEST] <durandal_1707> kierank: use pcm [19:34:45 CEST] <kierank> That's what I am doing [19:34:49 CEST] <kierank> That is lipsync with pcm [19:35:01 CEST] <kierank> Good resampling is hard [19:35:07 CEST] <durandal_1707> than you are bad engineer [19:35:21 CEST] <durandal_1707> resampling is trivial [19:37:38 CEST] <kierank> Not if resample ratio is dynamic [19:37:42 CEST] <kierank> And fractional [19:49:50 CEST] <durandal_1707> kierank: you wrong, me correct [19:53:24 CEST] <durandal_1707> Lynne: how is tx asm going? [19:57:46 CEST] <durandal_1707> michaelni: why is release still not made? [20:06:29 CEST] <michaelni> because the day has only 24h and theres always more work. For example trac today ... [20:13:01 CEST] <JEEB> michaelni: btw since you were the only one who commented on https://patchwork.ffmpeg.org/patch/12492/ , it seems like the only thing wget/curl do is they have a "how much time until I/O timeout we have" in the loop. f.ex. https://github.com/curl/curl/blob/master/lib/vtls/gtls.c#L332 [20:13:13 CEST] <JEEB> I'm not 100% sure how we handle timeouts on this level, or if we do at all :P [20:13:39 CEST] <JEEB> but it clearly seems like in normal usage (not thinking of I/O timeouts) we should just keep on looping on non-fatal errors [20:14:23 CEST] <nevcairiel> thats definitely the documented API usage pattern, and timing out in the middle of a SSL handshake seems rather overkill [20:14:25 CEST] <nevcairiel> so just go with i t [20:15:02 CEST] <JEEB> yes, I looked at the API usage and docs and that's what the thing seems to be [20:15:27 CEST] <JEEB> I think TLS handshakes have a limited amount of downgrades you can do etc so I would /guess/ in any sane case it will stop at some point or end up with a fatal error [20:15:35 CEST] <JEEB> or well, that the list of ciphers is limited [20:15:36 CEST] <JEEB> :P [20:15:45 CEST] <JEEB> from client's and server's POV [20:16:00 CEST] <JEEB> since that's what effectively you're looping over [20:16:46 CEST] <nevcairiel> ship it [20:19:35 CEST] Action: JEEB rebases locally [20:21:24 CEST] <durandal_1707> michaelni: if you can't spend so much time with FFmpeg please say so! [20:21:43 CEST] <kierank> durandal_1707: you should become leader [20:21:49 CEST] <JEEB> durandal_1707: what's with your attitude recently? [20:24:03 CEST] <durandal_1707> kierank: how? [20:24:11 CEST] <kurosu> maybe some news he has been waiting for so long but isn't coming - growing restless [20:24:36 CEST] <kierank> durandal_1707: just announce it [20:24:42 CEST] <durandal_1707> lol [20:29:23 CEST] <roxlu> hi, is this where libav dev. people hang out nowadays? [20:29:43 CEST] <JEEB> yes, the libraries' developers [20:30:20 CEST] <roxlu> Ah cool ... maybe this question is a bit offtopic then (not sure) [20:30:27 CEST] <roxlu> but I've experimented with using libav to decode video in the past and wanted to have a look at video + audio decoding. [20:30:54 CEST] <JEEB> there's some examples under doc/examples, but officially #ffmpeg is the "users' channel" [20:30:58 CEST] <JEEB> ffmpeg.c or the APIs [20:31:07 CEST] <roxlu> I'm curious how the API/design of libav fit's into the OS level audio callback. I mean what's the general approach? [20:31:38 CEST] <roxlu> ok thanks JEEB. Should I ask this in #ffmpeg? [20:31:44 CEST] <JEEB> API usage, yup [20:31:58 CEST] <roxlu> ok, thanks [20:34:18 CEST] <cone-025> ffmpeg 03Remita Amine 07master:bc1749c6e460: lavf/tls_gnutls: retry gnutls_handshake on non fatal errors [20:34:22 CEST] <JEEB> nevcairiel: there we go [21:05:05 CEST] <nevcairiel> :) [21:40:20 CEST] <cone-025> ffmpeg 03Michael Niedermayer 07master:6f2625aafc3d: tools/target_dec_fuzzer: Also fuzz extradata [21:40:21 CEST] <cone-025> ffmpeg 03Michael Niedermayer 07master:8c6c4129b4cc: avformat/vpk: Fix integer overflow in samples_per_block computation [21:40:22 CEST] <cone-025> ffmpeg 03Michael Niedermayer 07master:aa003019ab9e: avformat/vpk: Check offset for validity [21:40:23 CEST] <cone-025> ffmpeg 03Michael Niedermayer 07master:2a0f23b9d647: avformat/sbgdec: Fixes integer overflow in str_to_time() with hours [21:40:24 CEST] <cone-025> ffmpeg 03Michael Niedermayer 07master:e78b0f83748f: avcodec/bitstream: Check for integer code truncation in build_table() [21:40:25 CEST] <cone-025> ffmpeg 03Michael Niedermayer 07master:a7e3b271fc9a: avcodec/bitstream: Check for more conflicting codes in build_table() [21:40:26 CEST] <cone-025> ffmpeg 03Michael Niedermayer 07master:dd357d76e5fa: avformat/wtvdec: Avoid (32bit signed) sectors [22:15:20 CEST] <mkver> jkqxz: I am currently working on the patches for vp9_raw_reorder and noticed a bug: Think about a frame that will never be displayed and also not referenced at all (so refresh_frame_flags is 0). The current code doesn't handle this scenario very well. It is insanse (the frame is essentially just filler material), but I haven't found anything that says that it is against spec, so I hesitate to simply error out on encountering [22:15:20 CEST] <mkver> such frames (although that's my preferred solution). [00:00:00 CEST] --- Sat Jun 15 2019

1 0

ffmpeg.log.20190614
by burek 15 Jun '19

15 Jun '19

[00:00:54 CEST] <MoziM> kepstin: are there any shows that aren't interlaced? [00:00:58 CEST] <furq> yes [00:01:04 CEST] <furq> quite a lot of shows [00:01:26 CEST] <MoziM> i thought all movies/shows blurred video to some degree [00:01:30 CEST] <kepstin> MoziM: basically all movies, most non-live hidef tv shows [00:01:36 CEST] <furq> anything shot on film [00:01:41 CEST] <MoziM> unless it's cctv footage then interlacing is the norm i thought? [00:01:52 CEST] <furq> which will be telecined for ntsc broadcast but not on bluray or pal broadcast [00:01:53 CEST] <MoziM> o kk [00:02:10 CEST] <kepstin> MoziM: not sure what you mean by "blurred", interlacing and blurring are different things [00:02:16 CEST] <furq> also more stuff nowadays is just shot at 25/30p on digital [00:02:29 CEST] <MoziM> you're right, not "blurred" [00:02:54 CEST] <kepstin> web browsers can't play interlaced video (or at least can't deinterlace it), so basically all web streamed video is progressive rather than interlaced. [00:03:16 CEST] <kepstin> except when they get it wrong, like the screenshot i pasted earlier ;) [00:03:19 CEST] <furq> someone should tell everyone who uploads sports videos to youtube that [00:03:26 CEST] <BtbN> Twitch sometimes gets fed interlaced video from their "professional" events. Looks like shit every time. [00:03:47 CEST] <furq> i normally have my browser resized vertically so interlaced stuff gets this really unpleasant moiré-ish effect [00:03:51 CEST] <BtbN> That ONLY affects productions with super high profile, lot of money put into it, production value. [00:03:52 CEST] <furq> 1080i stuff, that is [00:04:08 CEST] <furq> pretty much every clip the bbc uploads is like that [00:04:31 CEST] <kepstin> yeah, live sports are the one weird thing where everybody uses 1080i60 because they decided it was better than 1080p30 or 720p60, and atsc doesn't support 1080p60 iirc [00:04:40 CEST] <kepstin> for north america anyways ^ [00:06:17 CEST] <kepstin> so the entire reason tvs have fancy hardware motion prediction stuff for those stupid modes that convert film to 60hz or 120hz is because they had to include hardware motion prediction anyways for the deinterlacer so 1080i sports don't look terrible. [00:07:48 CEST] <JEEB> kepstin: so in the slice header you have field_pic_flag value, and then bottom_field_flag if that is true [00:14:09 CEST] <ringo_> Hello ... out of luck with format conversion ....using -hwaccel nvdec -hwaccel_output_format uyvy422 will fool the chain but the output on sdi output looks all wrong ... colors, etc [00:14:12 CEST] <ringo_> smooth but wrong [00:14:34 CEST] <ringo_> so, we are pretending nvidia returns 422 but it does not [00:16:17 CEST] <MoziM> the layers of stuff that can make it all look wrong [00:16:19 CEST] <MoziM> ugh [00:19:48 CEST] <ringo_> is it possible to make a 420 to 422 converter that is multithreaded? or is the memcpy the bottleneck? [00:19:53 CEST] <BtbN> cuvid/nvdec simply does not support 422 [00:20:01 CEST] <BtbN> I'm surprised it doesn't just throw an error at you [00:22:02 CEST] <BtbN> What codec is that? [00:22:14 CEST] <ringo_> yuv [00:22:18 CEST] <BtbN> that's not the codec... [00:22:25 CEST] <ringo_> source files are hevc [00:23:03 CEST] <ringo_> for example [00:23:04 CEST] <ringo_> Video: hevc (Main 10) ([36][0][0][0] / 0x0024), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 59.94 fps, 59.94 tbr, 90k tbn, 59.94 tbc [00:23:15 CEST] <BtbN> That's 420 though, not 422 [00:23:34 CEST] <ringo_> that file needs to be decoded and output on decklink SDI output [00:23:41 CEST] <ringo_> decklink only supports 422 [00:23:57 CEST] <ringo_> uyvy422 [00:24:31 CEST] <BtbN> You'll have to send it through the format filter then [00:25:19 CEST] <ringo_> I can decode using nvidia gpu [00:25:38 CEST] <ringo_> and then when I pass it through the format filter, one cpu is maxed out [00:25:45 CEST] <ringo_> and output drop frames, etc [00:25:54 CEST] <BtbN> You'll need a more powerful CPU then [00:26:08 CEST] <BtbN> The GPU can't help you with that. Not unless someone write a filter that does specifically that conversion. [00:26:18 CEST] <ringo_> I am already using a Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz [00:26:30 CEST] <ringo_> I am already using an Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz [00:26:58 CEST] <BtbN> converting 4K, 60fps in real time is probably not happening then [00:27:10 CEST] <ringo_> GPU will of course help in the conversion from hevc to uncompressed [00:27:59 CEST] <BtbN> This will be this horrible because the conversion you are doing is not really a very common one, so there won't be too much SIMD for it [00:28:06 CEST] <ringo_> but then, the conversion of pixel format seems to be single threaded .. once cpu at 100% and all others under 5% [00:28:10 CEST] <BtbN> It will probably do a 3 way conversion [00:28:59 CEST] <ringo_> 4k 60 in real time happens over HDMI ... because inside the card there is no bottleneck on pixel format conversion [00:29:27 CEST] <BtbN> Can't that thing take a more common pixel format? [00:29:54 CEST] <BtbN> 4K60 is also some serious bandwidth just to copy it around in RAM [00:30:26 CEST] <ringo_> no, for some reason the blackmagic card can only take uyvy422 ... maybe I need to explore other vendors ... aja, dektek, bluefish [00:31:09 CEST] <BtbN> Interleaving several gigabytes of data per second IS horribly expensive [00:32:27 CEST] <BtbN> If you just want 4K60 out via HDMI... why not use any somewhat modern graphics card? [00:33:35 CEST] <ringo_> I already have a quadro rtx 4000 ... and I do not want 4k60 over hdmi ... I want 4k60 over HD-SDI [00:34:02 CEST] <BtbN> The path of least resistance might still be an HDMI to SDI converter then [00:34:41 CEST] <ringo_> someone else is doing it with the exact same combination of hardware under windows [00:35:09 CEST] <ringo_> so, they must have coded an effective multithreaded pixel format converter [00:35:38 CEST] <ringo_> the CPU can do it under linux for 4k30 ... but it maxes out for 4k60 [00:36:14 CEST] <BtbN> Doesn't even need to be multi-threaded [00:36:34 CEST] <ringo_> true ... it just needs to be fast enough [00:36:44 CEST] <BtbN> but what libswscale will be doing is convert to a common abstract base pixel format from whatever input format, and then convert that to the target format [00:37:00 CEST] <BtbN> Because there is no direct conversion for those unusual formats [00:37:06 CEST] <BtbN> specially with one of them being 10 bit and one 8 bit [00:37:24 CEST] <ringo_> I think decklink also supports 10 bit output [00:37:39 CEST] <BtbN> uyvy422 is an 8 bit format though [00:39:58 CEST] <ringo_> let me look at the code again ... [00:40:01 CEST] <ringo_> 175 if (c->codec_id == AV_CODEC_ID_WRAPPED_AVFRAME) { [00:40:01 CEST] <ringo_> 176 if (c->format != AV_PIX_FMT_UYVY422) { [00:40:01 CEST] <ringo_> 177 av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format!" [00:40:01 CEST] <ringo_> 178 " Only AV_PIX_FMT_UYVY422 is supported.\n"); [00:40:01 CEST] <ringo_> 179 return -1; [00:40:02 CEST] <ringo_> 180 } [00:40:04 CEST] <ringo_> 181 ctx->raw_format = bmdFormat8BitYUV; [00:40:06 CEST] <ringo_> 182 } else if (c->codec_id != AV_CODEC_ID_V210) { [00:40:08 CEST] <ringo_> 183 av_log(avctx, AV_LOG_ERROR, "Unsupported codec type!" [00:40:12 CEST] <ringo_> 184 " Only V210 and wrapped frame with AV_PIX_FMT_UYVY422 are supported.\n"); [00:40:14 CEST] <ringo_> 185 return -1; [00:40:15 CEST] <BtbN> ... [00:40:16 CEST] <pzich> please do not paste code here! [00:40:16 CEST] <ringo_> 186 } else { [00:40:18 CEST] <ringo_> 187 ctx->raw_format = bmdFormat10BitYUV; [00:40:20 CEST] <ringo_> 188 } [00:40:40 CEST] <ringo_> sorry ... I did not know it was not allowed [00:40:58 CEST] <ringo_> to me code is almost like english language as I look at it all day :) [00:41:05 CEST] <BtbN> spamming a channel for a minute is just a bad idea and annoying [00:41:34 CEST] <ringo_> understood [00:41:48 CEST] <BtbN> It's only instant for you, the rest gets it in ~1 line per second [00:42:08 CEST] <ringo_> indeed [00:43:27 CEST] <ringo_> how do I force the output to be a non wrapped frame with pixel format bmdFormat10BitYUV? [00:43:49 CEST] <BtbN> That's the V210 case [00:43:56 CEST] <ringo_> no, it is not [00:44:03 CEST] <BtbN> Yes it is, the check is != V210 [00:44:11 CEST] <BtbN> so that else case is for when it actually is V210 [00:44:12 CEST] <ringo_> ahhh ... yes [00:45:40 CEST] <BtbN> I'd really just get a Mini-HDMI-To-SDI box. Probably even cheaper than whatever you're using right now. [00:46:26 CEST] <ringo_> 12G converters are about $500 [00:46:47 CEST] <BtbN> Those Decklink output cards aren't much cheaper, are they? [00:47:05 CEST] <ringo_> about $600 [00:47:38 CEST] <ringo_> but they are bidirectional, so you can use them to encode as well [00:47:56 CEST] <BtbN> Why on earth do they only take 422 though? [00:48:07 CEST] <BtbN> In that weird format even [00:48:15 CEST] <ringo_> 422 and V210 aparently [00:50:03 CEST] <ringo_> so, writing one or more filters that convert direclty to these formats might be enough? ... it would save half the processing cpu cycles [00:51:38 CEST] <ringo_> sources will be hevc or h264 .... 420 8 or 10 bit 99% of the time [00:54:34 CEST] <BtbN> Pretty much [00:54:51 CEST] <BtbN> could also write them using CUDA, if you're using nvidia GPUs anyway [00:55:13 CEST] <BtbN> Should be an easy task for a GPU [00:56:38 CEST] <BtbN> CUDA can also do the conversion straight to system RAM, saving a copy in the process [00:56:45 CEST] <BtbN> But that would be a very specialized filter [00:56:57 CEST] <ringo_> scale_npp supports several ...but not this 422 [00:57:12 CEST] <BtbN> Nothing from nvidia supports 422, so that's not overly surprising [00:57:39 CEST] <ringo_> but you can still write the filter using the cuda SDK and stay in the GPU memory space? [00:57:52 CEST] <BtbN> You'd need to write the CUDA Kernel yourself though [00:59:02 CEST] <ringo_> That goes beyond my skills .... I think I might barely be able to write a normal filter [00:59:27 CEST] <BtbN> It's primarily an insane amount of boilerplate for maybe a handful of lines that do the actual conversion [01:00:34 CEST] <ringo_> I am willing to sponsor the work if you or someone wants to do it ... to be put into ffmpeg of course for others to use [01:02:01 CEST] <BtbN> You could put it on trac as feature request and mark it as bounty [01:02:16 CEST] <BtbN> not sure how actively trac is used for that purpose though [01:03:25 CEST] <ringo_> what is the link to trac? I can take a look for other bounties to see how effective it i [01:03:38 CEST] <BtbN> see topic [01:04:20 CEST] <ringo_> ok, saw it! [11:37:08 CEST] <zerodefect> With most subtitle files, I can do something like 'ffmpeg -i subtitle.ass subtitle.srt' to convert the input subtitle file it into a different format. Now, I'm trying to do the same thing for a .PAC subtitle file, but I get an error 'Invalid data found when processing input'. [11:37:18 CEST] <zerodefect> I notice in 'libavcodec/ccaption_dec.c' there is a method called 'handle_PAC' [12:44:30 CEST] <realies> can you use ffprobe to figure out what should be the file extension of the file? [13:24:13 CEST] <void09> how to get size of video file up to frame number N or timestamp ? [13:24:42 CEST] <zerodefect> @realies, no luck. Receive "/media/sf_SharedFolder/IIF17012320.pac: Invalid data found when processing input" with ffprobe too. [14:26:18 CEST] <realies> zerodefect :o [15:54:44 CEST] <void09> how to get size of video file up to frame number N or timestamp ? [15:58:16 CEST] <zerodefect> @void09 - AVPacket has a member called 'pos'. Try that. [16:11:30 CEST] <void09> zerodefect: sorry but I have no idea what you are talking about [16:11:58 CEST] <zerodefect> Are you using C-API or FFmpeg cmd line? [16:12:04 CEST] <void09> ffmpeg command line [16:12:33 CEST] <zerodefect> Ok. Ignore me then. [16:22:15 CEST] <kepstin> void09: copy the video to a new file up to that frame or timestamp, and then see how big it is, i guess? [16:22:31 CEST] <kepstin> (you might even be able to copy to nowhere, and use the ffmpeg stats output) [16:29:33 CEST] <void09> kepstin: cool, how do I do that? :P [16:30:02 CEST] <kepstin> void09: use "-c copy -f null -" as the output part of your ffmpeg command [16:30:55 CEST] <kepstin> although note that that will only show the stream sizes, it won't include container overhead [16:31:38 CEST] <void09> i already know the container overhead [16:32:06 CEST] <void09> but where do i enter the frame nmber or timestamp? [16:32:35 CEST] <kepstin> using the -t or -vframes option, same as any normal transcode [16:36:03 CEST] <void09> Element at 0x377b234 ending at 0x377b4c9 exceeds containing master element ending at 0x377b22e [16:36:17 CEST] <void09> i entere this command: ffmpeg -i output.mkv -c copy -f null - -vframes 2967 [16:40:26 CEST] <kepstin> void09: output options go *before* the output filename [16:40:30 CEST] <kepstin> which is "-" here [16:40:44 CEST] <kepstin> (and that warning message is unrelated, that's a problem with your input file) [17:07:43 CEST] <FishPencil> Is Android officially supported as a target? [17:08:22 CEST] <durandal_1707> no [17:11:43 CEST] <JEEB> FishPencil: yes sibce we have mediacodwc etc. for the libraries at least [17:12:13 CEST] <JEEB> otherwise quite a few android apps wouldn't be able to play video or audio :p [17:13:11 CEST] <JEEB> also i think fate has ndk boxes [17:14:24 CEST] <FishPencil> Was durandal_1707 kidding then? [17:18:00 CEST] <durandal_1707> i'm not aware that android is supported as build target [17:19:20 CEST] <durandal_1707> there is certainly some android stuff supported for sure, but i dunno is that enough [18:11:04 CEST] <JEEB> durandal_1707: there's really nothing special required for android [18:11:15 CEST] <JEEB> NDK is nowadays relatively modern clang with the android libc [18:11:27 CEST] <JEEB> the only thing we don't support is the custom makefile crap that GOOG is trying to pollute things with [18:11:38 CEST] <JEEB> (like, android specific makefiles) [18:11:47 CEST] <JEEB> but this is the same with MSVC etc [18:11:51 CEST] <JEEB> you use *our* build system [18:12:19 CEST] <JEEB> durandal_1707: you can see an example of how to build for android with https://kuroko.fushizen.eu/docs/buildan_mpv_android.txt [18:12:31 CEST] <JEEB> ctrl+F FFmpeg [18:13:11 CEST] <JEEB> target-os is android, and then you set your cross-prefix to the right one [18:13:36 CEST] <JEEB> (and because the CC/CXX are clang/clang++ you set clang/clang++ as --cc and -cxx [18:13:48 CEST] <JEEB> and as I noted, I'm pretty sure we have NDK in FATE [18:14:13 CEST] <JEEB> or at least we used to have [18:14:54 CEST] <JEEB> ok, seems like current FATE has no NDK :/ [19:05:40 CEST] <shockeroo> Hi all! Total newbie here. My encoding settings seem to be forcing 16:9 video to create 4:3 videos with a black strip at the top. I'm pretty sure I need to change/remove my use of scale and/or trunc. Can anybody point me in the right direction here please? My arguments are: -vcodec libx264 -vf "scale=min(640\,iw):trunc(ow/a/2)*2" -vb 800k -acodec aac -ab 96k -ar 44100 -f mp4 [19:08:47 CEST] <DHE> I think you just want scale=min(640\,iw):-2 [19:09:36 CEST] <DHE> still, that doesn't explain black bars and an aspect ratio change. unless of course the source already had that [19:10:57 CEST] <shockeroo> No, it's doing it to all my 16:9 videos and none of them had black bars in the source. I'll try your recommended setting, thanks. [19:14:56 CEST] <Hello71> also you need single quotes in shell [19:16:39 CEST] <shockeroo> Thank you. I'm using a front-end/script called "cumulusclips" and these are the default encoding options. Are you saying I should replace uses of " with ' ? [19:27:13 CEST] <kepstin> the quotes shouldn't change anything. you would have probably gotten a syntax error if that was wrong (the usual issue is that the \, doesn't get passed through properly) [19:28:20 CEST] <kepstin> I assume the reason for the calculation on the frame height is to turn anamorphic videos into 1:1 sar [19:28:44 CEST] <kepstin> it all looks correct, nothing in that command would be changing display aspect ratio or adding black bars to video. [19:31:09 CEST] <Atlenohen> Hello [19:31:28 CEST] <Atlenohen> So is it good to use preset ultrafast with x264 lossless mode ? [19:31:42 CEST] <Atlenohen> as in to do as less compression artifacts as possible? [19:32:31 CEST] <Atlenohen> Or is there some things that would increase quality, ... this whole compression stuff is quite complicated, I think I researche and looked videos about it in the past but forgot [19:33:12 CEST] <DHE> lossless is lossless no matter the preset. but higher presets will still produce smaller files [19:33:46 CEST] <Atlenohen> oh, allright [19:34:19 CEST] <another> see also https://trac.ffmpeg.org/wiki/Encode/H.264 [19:35:50 CEST] <shockeroo> Hm it looks like I might be having a problem with how cumulusclips embeds videos rather than with the actual encoding. Thanks for your help all; I think I need to know what I should be working on now. [19:54:19 CEST] <Atlenohen> I tried both ... yeah for a 2 minute excerpt, very slow took like 15 mins while ultrafast was almost instant, 100 Megabyte difference, 300 vs 400 MB [19:55:03 CEST] <Atlenohen> would definitely made a difference at larger sizes indeed [19:56:05 CEST] <furq> Atlenohen: normally there isn't a linear relationship between preset and size because the quality will change depending on the preset [19:56:11 CEST] <furq> but obviously for lossless you can't really change the quality [19:56:42 CEST] <aan3k> German Wikipedia says ogg is directly streamable. mkv only with specific settings and mp4 isn't streamable at all ... Have I missed something? I thought mp4 is streamable [19:57:18 CEST] <furq> also fwiw i normally use -preset ultrafast -coder cabac [19:57:49 CEST] <furq> cabac makes a much bigger difference than any other setting in my experience [19:58:29 CEST] <furq> aan3k: you can't stream (non-fragmented) mp4 on the fly because the header isn't written until the end [19:59:01 CEST] <furq> obviously for vod and stuff that doesn't matter [20:00:31 CEST] <aan3k> Oh, didn't knew. Thanks. Isn't a VOD streamed too? [20:00:37 CEST] <Atlenohen> takes the sense out of a header doesn't it :) [20:01:11 CEST] <furq> tbf they call it an atom, not a header [20:01:16 CEST] <DHE> yes, but "vod" is pre-rendered so the header was written a long time ago [20:01:30 CEST] <furq> aan3k: in one sense of the word, yes [20:01:32 CEST] <furq> but not the same sense [20:01:53 CEST] <aan3k> ah ok, got you. Thanks :) [20:02:19 CEST] <Atlenohen> still the player can't play until it parses the whole file so it reads the header/atom at the back rihgt [20:02:32 CEST] <furq> technically yes but practically no [20:02:38 CEST] <aan3k> so "livestreaming" and "demandstreaming" would differ it more nicely?! [20:02:49 CEST] <furq> if you mean for vod then any decent player will just range request the last 1MB or so and find the moov atom in there [20:03:13 CEST] <furq> aan3k: something like that, yeah [20:03:29 CEST] <furq> if the file already exists then mp4 will do whatever you want [20:03:37 CEST] <furq> in fact it's the only thing supported by every browser for that [20:04:19 CEST] <furq> if it's being generated on the fly then it's unplayable unless you write some kind of dummy moov atom or you use fragmented mp4 [20:04:34 CEST] <kepstin> Atlenohen: for making mp4 files intended for vod streaming, you'll usually post-process the mp4 to move the moov to the start of the file (ffmpeg has builtin support for that, "-movflags faststart") [20:04:39 CEST] <furq> yeah that too [20:04:48 CEST] <furq> but even if it's at the end it doesn't really matter any more [20:05:49 CEST] <kepstin> should reduce a server round trip, but yeah pretty minimal gains esp. with http2 or request pipelining. [20:08:20 CEST] <furq> yeah it's nice to have but it's not like you still need to download the entire file before you can play it [20:08:23 CEST] <furq> like in the good old days [20:30:56 CEST] <Atlenohen> Well wait [20:31:14 CEST] <Atlenohen> it's not seeking good in Adobe Premiere Pro ... shouldn't I do I frames only too ? [20:31:50 CEST] <Atlenohen> I think the veryslow actually performs a bit faster in Premiere, seek and stabilization (wich takes a shitload of RAM continually) [20:32:12 CEST] <JEEB> if you want fast seeking the tune fastdecode and short (3-5 frame) GOPs are probably pretty good [20:32:21 CEST] <JEEB> *then [20:32:23 CEST] <roxlu> hi, I asked this in #ffmpeg-devel, but I just learned that's the wrong channel .. (sorry for crossposting) [20:32:38 CEST] <JEEB> roxlu: anyways https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [20:32:48 CEST] <roxlu> thanks [20:32:48 CEST] <JEEB> this is the docs related to the push/pull APIs for decoding and encoding :) [20:32:54 CEST] <JEEB> wm4 wrote nicely [20:32:58 CEST] <JEEB> <3 [20:33:24 CEST] <JEEB> it's not async, but at least it separates pushing stuff to the decoder/encoder and receiving data from it [20:34:19 CEST] <roxlu> ok I see the high-level usage. pretty clear [20:36:12 CEST] <roxlu> I'm not sure how that fits in with an OS audio callback exactly. Would I send (encoded) audio frames from the user thread (e.g. a game/event loop) and in my audio callback call `avcodec_receive_frame()` ? [20:37:13 CEST] <Atlenohen> Wait, -g is deprecated ? [20:38:00 CEST] <kepstin> i don't think it's safe to call the send/receive functions from different threads. [20:38:24 CEST] <kepstin> but you can transfer an avpacket or avframe from one thread to another without issue [20:38:55 CEST] <kepstin> Atlenohen: the -g option to get gop size isn't deprecated, what gives you that idea? [20:38:58 CEST] <kepstin> to set* [20:39:09 CEST] <roxlu> kepstin: ok thanks, does this imply that one basically has to do the decoding in one thread; buffer the decoded packets and put them in a queue; then read from that queue in the audio callback? [20:39:11 CEST] <Atlenohen> some random stackoverflow post [20:39:33 CEST] <kepstin> roxlu: that's probably how i'd do it, yeah. [20:40:24 CEST] <JEEB> Atlenohen: there can be wrappers for encoders that just don't read the AVCodecContext value but most definitely the actual value is not deprecated [20:40:31 CEST] <JEEB> (that's what the -g option sets in FFmpeg) [20:40:35 CEST] <JEEB> *ffmpeg.c [20:40:45 CEST] <Atlenohen> Source is youtube 1080p - Stream #0:0(eng): Video: vp9 (Profile 0), 1 reference frame, yuv420p(tv, bt709), 1920x1080, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn, 1k tbc (default) [20:41:15 CEST] <saml> VP9 [20:41:18 CEST] <roxlu> Ok thanks, that would probably work. And you said I can queue AVFrame objects and share them between threads? [20:42:12 CEST] <friendofafriend> I'm streaming scanner audio to an Icecast server, so the audio is periodic. Is there a way to mix silence and a named pipe so my feed is continuous? [20:42:15 CEST] <davis> hello [20:42:41 CEST] <Atlenohen> apparently VP9 has better quality at lower bitrate than than H264, but I could get the H264 source at 1080p too if you guys think that's a better choice [20:43:06 CEST] <davis> im trying to write three ffmpeg commands. The commands are sequenced to get my desired output. The first one converts pcm file to wav. This appears to work [20:43:33 CEST] <davis> the second script would mix wav files into one wav file. this does not work. [20:43:46 CEST] <davis> i get an error about invalid data. [20:43:59 CEST] <JEEB> friendofafriend: I would probably write a daemon that would run 24/7 with the API, and then you could pass it inputs that it would stream until they end [20:44:01 CEST] <Atlenohen> saml, does it really matter, Adobe Premeiere gets fed H264, unless you think it matters for ffmpeg VP9 decoder ? [20:44:03 CEST] <JEEB> with a playlist, possibly [20:44:26 CEST] <JEEB> actually, I'd be surprised if there wasn't such a thing already using the FFmpeg APIs [20:45:11 CEST] <JEEB> since all you need are pre-generated samples of nothing, and then you start feeding decoded samples as you get onto the playlist [20:45:27 CEST] <JEEB> and then fall back into nothingness when playlist is finished [20:45:34 CEST] <davis> im doing this to convert the pcm to wav [20:45:35 CEST] <davis> ffmpeg -f s32le -ar 16k -y -i /tmp/one.pcm -ac 1 -f s32le -ar 16k /tmp/two.wav [20:46:04 CEST] <davis> i'm reading a audio pcm file which is stereo but one channel is padded as zeros. [20:46:26 CEST] <davis> i believe i'm writing a wav file which is mono in same format. [20:46:54 CEST] <saml> Atlenohen, I was just repeating after vp9 in ffmpeg/ffprobe output. ignore me [20:47:24 CEST] <Atlenohen> Wikipedia states CABAC requires much more processing power to decode, so I guess I shouldn't use that then if I want fastseek in Premiere pro right furq? [20:47:26 CEST] <furq> davis: -ac 1 downmixes [20:47:37 CEST] <furq> if you want to just ignore one channel then use -map_channel or -af pan [20:47:43 CEST] <JEEB> Atlenohen: that's what tune fastdecode does in libx264 [20:47:46 CEST] <JEEB> it switches to CAVLC [20:47:55 CEST] <JEEB> also it only helps with software decoding, not hardware decoding [20:47:59 CEST] <kepstin> davis: the issue is that you haven't specified the number of channels on the input, so it's using the default '1' [20:48:48 CEST] <davis> so, that command seems to work [20:49:08 CEST] <kepstin> davis: right now that command's reading the raw pcm stream as if it was 1 channel, downconverting to 1 channel (a no-op), then saving the result as a single-channel wav [20:49:10 CEST] <davis> it does not generate an error, but is the wav file output valid? it appears so [20:49:23 CEST] <davis> kepstin: so that is good [20:49:30 CEST] <kepstin> assuming it's interleaved samples, the result will be a single-channel wav which plays at 1/2 speed [20:49:40 CEST] <davis> let me show the second command which fails. [20:49:56 CEST] <davis> kepstin: ahh, perhaps I should remove the -ac 1 in output? [20:50:03 CEST] <kepstin> davis: is the input stereo? [20:50:27 CEST] <davis> the iput is stereo with only one channel having data. the other channel is all 0 [20:50:44 CEST] <kepstin> davis: if so, you need to add the "-channels 2" input option, so ffmpeg reads it as a stereo stream. Then use the options furq mentioned to drop the extra channel. [20:51:12 CEST] <kepstin> davis: don't use -ac 1 - that'll mix the two input channels together, instead of dropping one. [20:51:19 CEST] <davis> ahh [20:52:41 CEST] <davis> ok, i made adjustments. i'm trying a few things. bbiab [20:53:28 CEST] <davis> im dong this now [20:53:29 CEST] <davis> ffmpeg -f s32le -ar 16k -y -i /tmp/oneb.pcm -f s32le -ar 16k /tmp/oneb.wav [20:54:51 CEST] <kepstin> right, that's copying all of the contents of all channels of the pcm input file into a single channel in the output wav file. [20:54:58 CEST] <furq> -f s32le is just writing raw pcm data to a file with a .wav extension [20:55:02 CEST] <furq> it's not an actual wav file [20:55:06 CEST] <kepstin> oh, yeah [20:55:18 CEST] <furq> you want -c:a pcm_s32le (if wav even supports that) [20:55:28 CEST] <another> it does [20:55:28 CEST] <kepstin> so that's just a weird way to write "cp oneb.pcm oneb.wav" ;) [20:55:52 CEST] <davis> hmm. perhaps I should state my goal [20:56:14 CEST] <davis> i want to take multiple pcm files, convert to wav as first step [20:56:46 CEST] <davis> take a mix of the wav files and then mix them together to create a new wav file. mix.wav [20:57:03 CEST] <davis> last step would be to convert the mix.wav to mix.pcm. [20:57:20 CEST] <furq> if you're planning on doing all this with ffmpeg then you don't need the intermediate wavs at all [20:57:20 CEST] <davis> and have mix.pcm as the same format as the original pcm files. [20:57:31 CEST] <kepstin> dunno why you want multiple steps there, that's doable in a single command [20:58:01 CEST] <furq> unless you want the wavs to do some editing with a different tool [20:58:03 CEST] <davis> i was using the wav files to get audio so i could play them. it appears that my python code can not read pcm. [20:58:25 CEST] <davis> in python when i read as wav I could make graphs/plots [20:58:35 CEST] <kepstin> davis: the important pieces of information you need to provide to ffmpeg about the pcm audio is the * number of channels * sample format * sample rate [20:58:46 CEST] <davis> gotcha [20:58:57 CEST] <davis> btw, if I make a gist, can you guys read it? [20:59:17 CEST] <furq> raw s32le is just a bunch of 32-bit ints [20:59:24 CEST] <furq> so a plotting library should be able to handle that just fine [21:02:54 CEST] <davis> this is gist of the three ffmpeg scripts [21:02:55 CEST] <davis> https://gist.github.com/netskink/e9c079dcce69be045cbd39f0c6d89d4f [21:03:38 CEST] <furq> yeah the second script can both input and output raw pcm [21:03:46 CEST] <davis> so looking back at scrollback, the step1.sh was just a fancy cp? [21:04:01 CEST] <furq> yeah but it's redundant even if you fix it [21:04:24 CEST] <kepstin> davis: yes, since you used -f s32le, it wrote raw s32le instead of wav [21:05:58 CEST] <davis> so would that be a correct step1.sh after the update? [21:06:01 CEST] <kepstin> davis: with those commands i'd expect step 2 to give an error since the input files weren't wav files. [21:06:31 CEST] <davis> i believe it does [21:06:33 CEST] <kepstin> davis: correction is to delete step 1, and add "-f s32le -ar 16k -channels (something)" before each input in step 2 [21:06:54 CEST] <davis> ahh [21:06:58 CEST] <kepstin> and change it to use the .pcm filenames, of course [21:08:52 CEST] <kepstin> and optionally you can delete step 3 and make step 2 output the raw pcm directly, if you like. [21:08:54 CEST] <davis> hmm. if I makde -c:a pcm_s32le step1.sh mod, it runs, then it fixes error with step2.sh and finally step3.sh runs [21:10:33 CEST] <kepstin> davis: you still need to fix the issue where you're not specifying -channels on any of the raw pcm inputs [21:10:56 CEST] <kepstin> (reminder that the default is 1, so if your inputs are stereo you need to explicitly specify 2) [21:12:03 CEST] <davis> ok [21:12:13 CEST] <davis> since this script combination is running [21:12:29 CEST] <davis> i'm trying to see if I can play the intermediate files in a player [21:12:31 CEST] <davis> one moment [21:13:32 CEST] <kepstin> if the input is stereo, i'd expect the intermediate wavs to play at 1/2 speed with high-frequency noise. [21:14:10 CEST] <kepstin> well, at 16khz, it'll be kinda midrange noise tbh [21:16:33 CEST] <davis> cool, the wav files and the final wav file sound correct [21:16:51 CEST] <kepstin> then your raw pcm files were 1 channel to start with. [21:17:18 CEST] <davis> ahh [21:17:28 CEST] <davis> i did not create the original pcm files [21:17:58 CEST] <davis> i asked the guy and he said they were stereo with one channel zero [21:18:04 CEST] <kepstin> the other option is that the original pcm files were actually s16le stereo [21:18:30 CEST] <davis> its odd, though, my originals are 64K and my final is not [21:18:49 CEST] <davis> let me read your scrollback [21:18:50 CEST] <davis> one sec [21:18:55 CEST] <kepstin> if you read s16le stereo with one channel as all 0s as if it was s32le mono, the result will be a perfectly fine mono signal with weird levels [21:19:03 CEST] <kepstin> i think [21:19:14 CEST] <kepstin> might depend on channel order and other weirdness, but w/e [21:19:21 CEST] <kepstin> s32le is an unusual format to start with [21:20:16 CEST] <davis> "the important pieces of information you need to provide to ffmpeg about the pcm audio is the * number [21:20:19 CEST] <davis> of channels * sample format * sample rate" [21:20:40 CEST] <davis> is there anyway to determine that from the file itself? [21:20:44 CEST] <davis> the original pcm file? [21:22:57 CEST] <davis> that is an octal dump in hex mode of the file [21:23:08 CEST] <davis> or at least first line [21:25:38 CEST] <davis> so it looks like my mix.wav is 32k [21:26:05 CEST] <kepstin> huh, that alternating 8000 and 0000 is kinda weird [21:26:47 CEST] <davis> so the original are 64k, the wav versions are 64k, the mix is 32k, so when the file is created as a pcm, it is 64k [21:27:13 CEST] <davis> is there a good tool for displaying audio waveforms you recommend? [21:27:55 CEST] <kepstin> davis: i'd guess your input data is 2-channel s16le [21:28:47 CEST] <kepstin> simply because s16 is by *far* the most common sample format, and your file has an alternating pattern going on every 16 bits. [21:30:28 CEST] <davis> yah, don't know [21:30:38 CEST] <davis> i'm trying to open with audacity to examine there [21:30:41 CEST] <davis> one moment [21:30:56 CEST] <kepstin> that's the thing about raw data, you can't do anything with it unless you know the details about how it was encoded [21:31:49 CEST] <ASAMIR___> Hi [21:32:41 CEST] <ASAMIR___> I'm looking for the reference frames for motion vectors [21:33:28 CEST] <davis> wow, this is making my head hurt [21:33:34 CEST] <davis> kepstin: i really appreciate it [21:33:48 CEST] <davis> i'm going to get some lunch, take a break and return [21:34:06 CEST] <davis> fwiw, in audacity all the files are one second in audio [21:34:20 CEST] <ASAMIR___> As the only a parameter which is related to motion vectors is a variable which specifies if the reference frame is either one of the previous frames or the following ones [21:34:23 CEST] <davis> but for some reason the mix.wav file is not the same size as the original. [21:34:30 CEST] <kepstin> davis: well, you've used -t 1 on some of those commands, so ffmpeg would have cut them off after 1 second [21:34:36 CEST] <ASAMIR___> I have been hacking at this for almost two weeks now [21:34:45 CEST] <ASAMIR___> So I appreciate any help [21:34:48 CEST] <kepstin> different since probably means different sample format, maybe your mixed wav was saved as 16bit? [21:35:03 CEST] <davis> yes, the -t 1 was to keep all audio as one second [21:35:17 CEST] <davis> i think its before that [21:35:35 CEST] <kepstin> ASAMIR___: references always refer to previous frames (in dts order), you can't reference frames that haven't been decoded yet [21:36:04 CEST] <davis> the mix.wav was created form the input wav files. the inputs were 64k, the output was 32k. [21:36:25 CEST] <kepstin> davis: does your gist show the commands you just ran? [21:36:40 CEST] <davis> the mix does not specify the output format [21:36:55 CEST] <davis> let me check to see if .sh files match the gist [21:36:58 CEST] <davis> one moment [21:37:03 CEST] <kepstin> davis: the default codec for wav if unspecified is pcm_s16le [21:37:13 CEST] <davis> hmm [21:37:20 CEST] <davis> so perhaps i need to adjust that [21:37:22 CEST] <davis> one moment [21:37:31 CEST] <ASAMIR___> kepstin: Yeah I know that reference frames are decoded first. But I want to get their index with respect to the order of display (POC) and it's not available in the AVMotionVector struct [21:38:52 CEST] <kepstin> ASAMIR___: looks like that information is simply not available. [21:38:57 CEST] <ASAMIR___> kepstin: There is a field for the direction but it has +/-1 values only. [21:39:47 CEST] <ASAMIR___> kepstin: Yes I want to implement. I think it has a todo comment in the AVMotionVector struct. [21:40:27 CEST] <ASAMIR___> kepstin: I think it has to be available because it must be used to calculate the actual frame. It's just not exposed. [21:41:31 CEST] <davis> hmm. [21:41:57 CEST] <davis> now it does mix.wav as 64102 bytes instead of 32k [21:42:21 CEST] <kepstin> davis: wav has a header in addition to the actual data contents [21:42:46 CEST] <davis> ill put my .sh files in the gist [21:42:48 CEST] <davis> one moment [21:43:03 CEST] <kepstin> ASAMIR___: fixing that will require diving into the code for individual decoders to find and expose the information. maybe a better discussion topic for #ffmpeg-devel [21:45:02 CEST] <ASAMIR___> I'm already knee deep in the code and gone through the whole code but I've been stuck for a long time and I cannot advance more without asking someone so can you suggest me anyone to help? I've already got two arrays which seems to contain the reference frames lists but their numbers doesn't make much sense. [21:45:03 CEST] <davis> ok they are updated [21:45:16 CEST] <davis> now, when i pasted them, i see a few problems which i learned from you [21:45:21 CEST] <davis> one moment, i'll correct [21:46:46 CEST] <friendofafriend> What's the new option to loop an input file forever? -stream_loop and -loop aren't working. [21:46:48 CEST] <ASAMIR___> If you could even point me to where are the frames actually calculated from motion vectors + residuals to produce the final cur_pic which contains the final frame [21:47:31 CEST] <kepstin> ASAMIR___: i wouldn't know, i've never worked on decoders. but you should probably start by saying which decoder you're looking at. [21:48:04 CEST] <ASAMIR___> kepstin: H264 decoder [21:48:11 CEST] <kepstin> friendofafriend: -stream_loop should be working, what problem are you having with it? [21:49:28 CEST] <friendofafriend> kepstin: Oh drat, I was running some old ffmpeg from repo. My mistake. [21:50:22 CEST] <davis> i updated the gist [21:50:38 CEST] <davis> it shows the fixes and the resulting output file sizes [21:51:34 CEST] <davis> since it random how it picks the files in python to create these scripts, the step1 will not match on file names, but the command options are the ones last used [21:55:29 CEST] <Atlenohen> I think -tune fastdecode did it, feels quite faster even if really seeking like crazy it's a bit, but big difference, and it doesn't take up that ram when stabilizing [21:55:39 CEST] <Atlenohen> RAM* [23:35:05 CEST] <gbee> I'm trying to get realtime audio stats using the astats and ametadata filters, using the print to pipe option. However this isn't working as it's not flushing the output to the pipe immediately, it appears to be buffering at least 256kb or more so the output is written in large chunks. Is there any way to force ametadata to flush immediately? [23:36:24 CEST] <gbee> If I remove the :file argument for ametadata the output is realtime but then I lose the ability to send the data to a specific numbered pipe [23:53:10 CEST] <gbee> for now I've modified the metadata filter to call avio_flush() after every write, this is a bit brute force and I may refine it but it works. However it doesn't seem like it should be necessary - many of the filters with output are intended to be used in realtime so either I'm overlooking an official solution or this use of buffering isn't intentional? [00:00:00 CEST] --- Sat Jun 15 2019

1 0

ffmpeg-devel.log.20190613
by burek 14 Jun '19

14 Jun '19

[00:07:51 CEST] <cone-189> ffmpeg 03U. Artie Eoff 07master:f70c397456c7: vaapi_encode_mjpeg: fix bad component id bug [00:07:52 CEST] <cone-189> ffmpeg 03Alejandro Solozabal 07master:caabe1b4956d: avcodec/omx: Correct av_log() log message [00:18:12 CEST] <mkver> jkqxz: Why doesn't cbs use unchecked bitstream readers? After all, cbs does its own checks for overreads. [00:24:37 CEST] <jkqxz> Mostly a preference on my part for safety over performance in that API, so I never investigated it. I wouldn't object if you want to change it (and it makes a nontrivial difference for something you care about). [00:25:49 CEST] <mkver> Ok, I'll benchmark it. [00:30:55 CEST] <mkver> Btw: I think that the display orientation stuff in h264_metadata (and in h264_slice and hevcdec) is completely buggy. [00:32:13 CEST] <mkver> The reason is that in all these instances when reading a SEI and creating the corresponding matrix, the rotation is applied first and then the flip. But according to the H.2645 standard, the flips should be performed first, then the rotation. [00:38:00 CEST] <mkver> (The new matrix M' that corresponds to applying a flip after having applied the transformation corresponding to the matrix M is the matrix M with some of its columns multiplied by (-1). If the flip is applied first, then the new matrix is created by multiplying certain rows with (-1).) [00:46:02 CEST] <jkqxz> I'm confused by the standard. The first example in the note doesn't seem to make sense? [00:46:38 CEST] <jkqxz> (In H.265 D.3.17.) [00:50:25 CEST] <jkqxz> Unhelpfully with the second example it doesn't matter which way around the flip/rotate happens. [00:51:16 CEST] <mkver> Yes, that note is wrong: One can't have anticlockwise_rotation equal to 0x8000000. [00:53:06 CEST] <jkqxz> 0x8000 is just a half turn. [00:53:48 CEST] <mkver> Yes, and that is what they meant. [00:55:29 CEST] <jkqxz> What do you mean? The 0x8000 is correct for the second example. [00:56:05 CEST] <mkver> They meant this: "It is possible for equivalent transformations to be expressed in multiple ways using these syntax elements. For example, the combination of having both hor_flip and ver_flip equal to 1 with anticlockwise_rotation equal to 0 can alternatively be expressed by having both hor_flip and ver_flip equal to 0 with anticlockwise_rotation equal to 0x8000, and the combination of hor_flip [00:56:05 CEST] <mkver> equal to 1 with ver_flip equal to 0 and anticlockwise_rotation equal to 0 can alternatively be expressed by having hor_flip equal to 0 with ver_flip equal to 1 and anticlockwise_rotation equal to 0x8000." [00:56:50 CEST] <mkver> I mean that they made three mistakes: They twice wrote 0x8000000 where they should have written 0x8000. [00:57:30 CEST] <jkqxz> Are we looking at the same thing? I see 0x8000. [00:58:15 CEST] <mkver> And they wrote "can alternatively be expressed by having both hor_flip and ver_flip equal to 1" (that 1 should be 0). [00:58:34 CEST] <jkqxz> Ah, that looks like it was corrected between 2015 and 2018. [00:58:56 CEST] <jkqxz> The flip part is still wrong in 2018, though. [00:58:59 CEST] <mkver> I se 0x8000000. I use the H.264 standard 04/2017 and H.265 12/2016. [00:59:10 CEST] <mkver> I'll get the newer standards. [00:59:58 CEST] <jkqxz> I'm looking at 2018/02. [01:01:09 CEST] <mkver> Yes. That has been corrected. [01:05:33 CEST] <mkver> The same thing (i.e. GCC 9 being more strict about the scope of compound literals) is btw behind a data corruption bug in the linux kernel (that affects users having a SSD cache + HDD combination). [01:06:59 CEST] <mkver> And the codepath for inserting a display orientation SEI from a side-data matrix is btw. also not bug-free. [01:08:24 CEST] <mkver> The check whether to flip is wrong: One should check at the determinant of the upper left 2x2 submatrix. If it is negative, one needs to use a flip (doesn't matter which one); if not, no flip. [01:13:01 CEST] <jkqxz> Hmm, I don't really remember that code at all. I was only interested in rotations, so I'm not surprised if flips are wrong somehow. [01:16:17 CEST] <mkver> Ok. Did you manage to reproduce the infinite loop I mentioned in https://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245054.html or was I too cryptic? [01:24:07 CEST] <jkqxz> I think the hevcdec code is doing the right thing? It would be helpful if it had some more comments to explain the ordering, but it does have the right effect (flip then rotate). [01:25:06 CEST] <mkver> No, it sets the rotation, then it flips. [01:29:14 CEST] <mkver> av_display_matrix_flip is effectively multiplying the given matrix with a diagonal matrix (whose diagonal entries are +1 or -1 depending on hlip and vflip) *from the right*. [01:30:21 CEST] <mkver> In ordinary linear algebra, the vector to which the matrix is applied is written to the right of the matrix, i.e. if we apply several matrices/linear transformations in sequence, the rightmost matrix is applied first. [01:30:56 CEST] <jkqxz> Urgh. I confused the rotation direction in testing it and got it the wrong way around. [01:31:34 CEST] <mkver> But here it's the opposite: The untransformed vector (p, q, 1) is multiplied from the left to the transformation matrix to get the transformed vector. [01:32:32 CEST] <mkver> That explains the difference between this situation and how this stuff is usually presented in linear algebra books. [01:34:16 CEST] <jkqxz> Right, yes. It's flipping the matrix, rather than adding the transformation you would want to apply the flip to another matrix by multiplying. [01:34:40 CEST] <mkver> Not only you made that error; this error happens every time the SEI is parsed in the codebase. [01:35:33 CEST] <jkqxz> av_display_rotation_get() and av_display_rotation_flip() are not really doing similar things at all. [01:35:41 CEST] <jkqxz> *matrix_flip [01:37:35 CEST] <mkver> av_display_rotation_flip yields the matrix that corresponds to the transformation of applying the given flips after having applied the given matrix. [01:38:37 CEST] <jkqxz> Yes, this has been present since it was added in 2014. [01:39:40 CEST] <mkver> av_display_rotation_get meanwhile gives you an angle; the value is only correct for rotations, of course. [01:40:31 CEST] <jkqxz> So what is the nicest answer to this? Make a av_display_matrix_rotate() function, and use identity -> matrix_flip -> matrix_rotate in the decoders? [01:41:01 CEST] <mkver> I thought about creating a new function that applies flips, but before applying the given matrix. [01:42:07 CEST] <mkver> In other words, where av_display_matrix_flip multiplies columns by +1 or -1, this new function would multiply rows by +1 or -1 (corresponds to a multiplication with a diagonal matrix from the left). [01:48:38 CEST] <mkver> To another topic: In 4d56f7ab8f627aa140c1ede1bb61305f01cefcdd you made BSF see EOF so that they can flush any delayed packets. [01:49:06 CEST] <mkver> Does any of the current bsf actually need this? And more importantly: Does this really work? Because it seems that EOF does not even reach process_input_packet. Maybe it did work for avconv and not ffmpeg? [01:49:47 CEST] <mkver> I created a patch for this. See https://github.com/mkver/FFmpeg/commit/1c3703ad9df38a84128df9db138ff9daf477… [01:50:48 CEST] <mkver> But ffmpeg.c is not my forte. [01:52:07 CEST] <mkver> In particular, there is another if (ist->decoding_needed) { at https://github.com/mkver/FFmpeg/blob/1c3703ad9df38a84128df9db138ff9daf47789… and I don't know what to do at this point. Simply removing said check would give lots of error messages (that one sent another packet to a bsf after eof) when one uses the loop option. [01:57:58 CEST] <jkqxz> I think vp9_raw_reorder is the only bsf which uses flushing delayed packets. [02:01:11 CEST] <jkqxz> And it does still work in ffmpeg. [02:02:07 CEST] <jkqxz> Ah, but it isn't really for streamcopy which is what this is doing. [02:05:41 CEST] <mkver> So what was the actual reason for 4d56f7ab8f627aa140c1ede1bb61305f01cefcdd if it's not needed? Just because it is cleaner that way? [02:07:56 CEST] <jkqxz> And indeed it doesn't work in streamcopy. It doesn't even feed all the input into the bsf. [02:08:15 CEST] <mkver> Does it work with my patch? [02:09:14 CEST] <jkqxz> Wrt 4d56f7ab8, I don't know. Maybe the libav mailing list would say more. [02:10:33 CEST] <jkqxz> After your patch it does flush but didn't pass all the input? [02:11:43 CEST] <mkver> Ok. How can I reproduce such a "didn't pass all the input" scenario? [02:14:17 CEST] <jkqxz> Have a test file <http://ixia.jkqxz.net/~mrt/1ca3b2e86c4d1328a36899910f2fe663/vp9rr.ivf>. It contains three frames I, P, B. vp9_raw_reorder should turn them into I, superframe(P, B), show_frame(B). [02:15:01 CEST] <jkqxz> And it does that correctly when it's used as the output of an encoder, but in streamcopy it creates nothing without your patch or only the I frame with your patch. [02:17:04 CEST] <mkver> Ok. Maybe I have time to investigate this. (But feel free to solve it yourself, of course.) [02:19:26 CEST] <mkver> It at least works half-way for what I wanted to have: The information when there are no more frames coming to a bsf (in my case a modified h264_metadata). [02:20:28 CEST] <jkqxz> What are you doing with it? [02:21:30 CEST] <mkver> This way I can find out whether a parameter set was unused (i.e. not referenced by any slice) at all and then I can send a side-data-only packet with AV_PKT_DATA_NEW_EXTRADATA side-data that only contains the extradata that is really needed. [02:21:58 CEST] <mkver> (Of course, support for this had to be added to the relevant muxer (Matroska in my case).) [02:23:11 CEST] <jkqxz> I think the patch is correct, modulo weird interactions because ffmpeg.c is too complicated. [02:23:51 CEST] <mkver> Yeah, as I said, ffmpeg.c is not my forte. I don't feel "at home" there. [02:24:03 CEST] <mkver> At least it passes fate. [02:24:18 CEST] <jkqxz> I don't think anyone does, which is a problem. [02:24:29 CEST] <mkver> And I'm still unsure what to do in the looping case. [02:24:49 CEST] <mkver> What? I thought at least Michael Niedermayer does. [02:28:09 CEST] <mkver> The patches I mentioned are here: https://github.com/mkver/FFmpeg/commits/h264_metadata, if you want to take a look. [02:29:23 CEST] <ringo_> Hello [02:29:31 CEST] <ringo_> I think I posted my question to the wrong channel [02:29:38 CEST] <ringo_> ffmpeg user instead of ffmpeg devel [02:30:19 CEST] <ringo_> I want to use nvidia cuvid to decode a file and play over decklink output [02:30:22 CEST] <TheAMM> No, it was the right place [02:30:34 CEST] <TheAMM> It was about using ffmpeg, no? [02:30:53 CEST] <ringo_> no, it was about modifying ffmpeg code to possible fix a bug or limiation [02:30:58 CEST] <ringo_> no, it was about modifying ffmpeg code to possible fix a bug or limitation [02:31:44 CEST] <ringo_> I am a contributor to several open source projects including VLC .... and indirectly to ffmpeg as well [02:32:59 CEST] <ringo_> I want to know if the best way to fix the issue I encountered is to modify the decklink output module to support more pixel formats and do the conversion there [02:42:28 CEST] <jamrial> jkqxz: that sounds more like work for the vp9_superframe filter [02:42:45 CEST] <jamrial> the sample you linked, i mean [02:42:59 CEST] <jamrial> or does vp9_raw_reorder do the same thing? [02:59:31 CEST] <mkver> I actually don't know what the difference of vp9_raw_reorder and vp9_superframe is supposed to be. But it will have to wait until tomorrow: Good night. [11:43:25 CEST] <cone-865> ffmpeg 03Matthieu Bouron 07master:d83985ce11d0: avcodec/mediacodecdec: try to receive a frame after signaling EOF to the codec [11:43:26 CEST] <cone-865> ffmpeg 03Matthieu Bouron 07master:fef5ba40231d: avcodec/mediacodecdec: remove unneeded else block in ff_mediacodec_dec_send() [11:43:27 CEST] <cone-865> ffmpeg 03Matthieu Bouron 07master:7c2c5c4940a6: avcodec/mediacodecdec: re-indent after previous commit [13:43:54 CEST] <mkver> jkqxz: My preliminary analysis of vp9_raw_reorder is this: The check at https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffmpeg.c#L2008 fails for the second and third packet (which therefore aren't even sent to the bsf); if one adds -copyinkf to the command line, the packets are sent, processed and muxed correctly, but without the show-existing-frame at the end. With my patch and -copyinkf, all the packets are output [13:43:54 CEST] <mkver> correctly. [13:45:36 CEST] <mkver> There is just one thing that doesn't look right: The dts of the output packets. They are not monotonous; and they don't indicate the reordering: The dts delta for the superframe (i.e. two frames to decode) ends up being exactly the same like the dts delta for the first frame. [13:46:24 CEST] <nevcairiel> wasnt raw_reorder some rather unique special case for the vaapi encoder or something because it lacks any sort of proper bitstream generation logic [13:49:51 CEST] <jkqxz> Why did copyinkf help? The first packet should already be a key frame. [13:51:46 CEST] <jkqxz> Ok, that does explain why it was mmissing some of the packets even with your patch. Given that, it sounds like your patch is a good idea. [13:51:50 CEST] <mkver> Yes. And because it is a keyframe it gets sent to the bsf. But the next frames don't, because the output stream's frame counter is still zero (after all, the keyframe is cached and not output yet) and because they are not keyframes. [13:52:18 CEST] <jkqxz> nevcairiel: Yes. But it's also the only current bsf with weird delay logic. [13:52:41 CEST] <mkver> I am actually wondering whether it needs to have this weird delay logic at all. [13:53:27 CEST] <mkver> The only good reason would be to modify the dts and/or pts of the output packets before outputting them, so that e.g. dts is monotonous. [13:54:43 CEST] <mkver> If it is just some flags that need to be known later, then they can be kept, but do we really need to keep the actual packets for this? I am not sure about this. [13:56:59 CEST] <mkver> And even if this delay stuff can't be eliminated completely, I don't get why the keyframe can't be output right away. [13:57:15 CEST] <jkqxz> I think it should drop the dts stuff entirely and output dts == pts on every frame - I noticed going wrong with larger pyramids in vp9_vaapi but I haven't pursued it yet. [14:00:22 CEST] <mkver> It already outputs pts == dts (at least in your sample). And that leads to the usual "Application provided invalid, non monotonically increasing dts to muxer" errors. [14:00:55 CEST] <jkqxz> Because it hasn't been superframed? [14:01:47 CEST] <mkver> Adding the superframe bsf fixes these errors, that's true. If you are fine with this, then so am I. [14:04:10 CEST] <jkqxz> The superframe components correctly end up with the same timestamps. Since it's adding the show-frame packets, there is no way to avoid some of the pre-superframe stream having the same timestamps for some packets. [14:07:41 CEST] <mkver> Really? What about the following for our sample: I frame: dts -1, pts 0; P frame: dts 0, pts: NOPTS, B frame: dts:1, pts 1, show_existing frame: dts 2, pts 2. [14:08:31 CEST] <mkver> One could of course use the pts 2 for the P frame, too. At least the dts would be correct then. [14:14:18 CEST] <jkqxz> The calculation on timestamps to decide how far back to go needs to examine the whole stream before starting. E.g. a pyramid { I, B1, B2, B3, P } (vp9_vaapi with -bf 3 -b_depth 2) needs -2 dts to make { I, P, B2, B1, show-B2, B3, show-P }, and that sequence could be concatenated after the previous one which only had an offset of -1. [14:16:48 CEST] <mkver> So because it's impossible, we don't even try and leave it to vp9_superframe. Fine by me. [14:17:20 CEST] <jkqxz> Yes, exactly :) [15:09:50 CEST] <mkver> jkqxz: If I am not mistaken, VP9 allows to have coded frames that are never displayed, but just used internally as references in the decoding process. This makes me wonder how uniquely determined the output with show_existing_frames is when one is given the stream without show_existing_frames as input. [15:12:02 CEST] <mkver> More concretely: If I have I0, P2, B1 and ND (ND = No-Display) in this order as the beginning of the input, then where is the place for the show_existing_frame corresponding to the P frame? Before or after the ND? [15:22:13 CEST] <nevcairiel> it ultimately doesn't matter where it is [15:22:41 CEST] <nevcairiel> unless the ND is supposed to replace the reference slot that P went into [19:44:34 CEST] <llogan> twitter user wants to know which encoders support both intra and non-intra. h26*, libx26*, ffv1, mpeg*, libvpx*, wmv, snow. Any others? [19:45:38 CEST] <gnafu> libaom* is another prominent up-and-comer. [19:46:10 CEST] <llogan> forgot about that one [23:13:42 CEST] <cone-974> ffmpeg 03Paul B Mahol 07master:6473a5d35c16: avformat/id3v2enc: fix bug, CTOC flags take only one byte [00:00:00 CEST] --- Fri Jun 14 2019

1 0

ffmpeg.log.20190613
by burek 14 Jun '19

14 Jun '19

[02:14:11 CEST] <ringo_> Hello [02:15:04 CEST] <ringo_> I am using the latest git of ffmpeg (two days ago) ... I am trying to use ffmpeg tp decode an hevc file and output it over a decklink SDI [02:15:47 CEST] <ringo_> I have the latest nvidia kernel driver install and both the latest nvidia headers from git and the latest cuda_sdk as well [02:16:03 CEST] <ringo_> everything compiles and seems to load [02:16:19 CEST] <ringo_> but I have a pixel format conversion that I cannot solve and need some guidance [02:18:11 CEST] <ringo_> when I do NOT use hardware decoder (cuvid), ffmoeg can convert the input to AV_PIX_FMT_UYVY422 just fine [02:18:28 CEST] <ringo_> but when I enable -hwaccel cuvid -c:v hevc_cuvid [02:19:00 CEST] <ringo_> then it fails to find a way to convert the output pixel format (cuda or 420) to 422 [02:23:55 CEST] <ringo_> so, this works but it is not fast enough [02:23:56 CEST] <ringo_> ./ffmpeg -re -i /data/public/media/HEVC4K60.ts -ac 2 -ar 48000 -f decklink -pix_fmt uyvy422 'DeckLink 8K Pro (1)' [02:24:31 CEST] <ringo_> and this fails [02:24:31 CEST] <ringo_> ./ffmpeg -re -hwaccel cuvid -c:v hevc_cuvid -i /data/public/media/HEVC4K60.ts -ac 2 -ar 48000 -f decklink -pix_fmt uyvy422 'DeckLink 8K Pro (1)' [02:24:53 CEST] <ringo_> with this error [02:24:53 CEST] <ringo_> Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0' [02:24:54 CEST] <ringo_> Error reinitializing filters! [02:24:54 CEST] <ringo_> Failed to inject frame into filter network: Function not implemented [02:25:55 CEST] <ringo_> looking at the debug log, it is clear that the hevc_cuda does not support uyvy422 and instead outputs 420 or cuda or nv12 pixel format [02:26:14 CEST] <ringo_> and then ffmpeg cannot find a way yo do the pixel format conversion .... [02:26:48 CEST] <ringo_> if I try this [02:26:50 CEST] <ringo_> ./ffmpeg -re -hwaccel cuvid -c:v hevc_cuvid -i /data/public/media/HEVC4K60.ts -ac 2 -ar 48000 -f decklink 'DeckLink 8K Pro (1)' [02:27:10 CEST] <ringo_> then, the decklink module will complain about receiving the wrong pixel format as expected [02:27:26 CEST] <ringo_> [decklink @ 0x6f3380] Unsupported pixel format! Only AV_PIX_FMT_UYVY422 is supported. [02:27:26 CEST] <ringo_> Could not write header for output file #0 (incorrect codec parameters ?): Input/output error [02:28:00 CEST] <ringo_> I do not mind modifying code to fix this but need a little guidance. Should I modify the decklink module to take 420 and add a conversion to 422 inside of it? [02:28:37 CEST] <sim590> I'm trying to change my video's framerate from 29.97 to 25. I am seeing multiple posts proposing multiple things. For instance, I have tried this https://superuser.com/a/1291513 (lossless part) but I don't get satisfying results ... My audio is just stripped at some pointin the video. [02:49:25 CEST] <sim590> I want to keep the same length of the video, so I want to drop frames. [03:09:50 CEST] <darkapex> haasn: welp my vlc compile broke as archlinux updated libplacebo to 1.8. should i apply your patches on my tree right now, or wait for it to get merged and downgrade my arch package? [03:10:25 CEST] <darkapex> oops wrong channel sorry [03:38:32 CEST] <sim590> If I want to change the framerate of some video, but keep the same time length, does that mean I am forced to reencode or I can avoid reencoding? [03:40:12 CEST] <DHE> you must reencode in order to drop frames [04:20:36 CEST] <sim590> DHE: Alright. Thanks. [04:21:26 CEST] <sim590> Also, it seems like ffmpeg ignores -threads. No matter what I put (1 or 2), ffmpeg still uses 400% of CPU, so the 4 cores, hence 4 threads even though I specified -threads 2 (or 1). [04:22:29 CEST] <sim590> May be I have to set it after some options? [04:25:20 CEST] <another> the order of options matters [04:25:35 CEST] <another> stuff before -i are input options [04:25:46 CEST] <nicolas17> I thought -threads was global :o [04:25:47 CEST] <another> stuff before an output are output options [04:26:29 CEST] <sim590> Shouldn't this work? ffmpeg -y -i $file -threads 1 -r 25 -c:v libx264 -c:a aac -f matroska "${file%.*}_25fps.mkv [04:27:00 CEST] <sim590> Alright. Yes. It works. I really had to put -threads after -i. [04:28:30 CEST] <sim590> But it doesn't work if -threads cmoes after -f for instance. [05:03:27 CEST] <sim590> I'm using my three laptops to change the framerate of my videos now. I pass them by ssh like so "ssh host 'ffmpeg -i - ...' <file.MOV >fileout.mkv". It works well. However, the resulting file doesn't seem to have its duration encoded in the file. I guess that it makes sense because ffmpeg doesn't know about it as it is processing stream. I guess I can't work around that and have my resulting file have its [05:03:29 CEST] <sim590> duration encoded at the end, right? [05:05:13 CEST] <nicolas17> copy whole file and then run ffmpeg on it :( [05:35:48 CEST] <sim590> Yeah. That's what I do at the end .. [07:56:15 CEST] <eschie> Any help with debugging this HLS encoding issue would be super grateful => https://stackoverflow.com/questions/56570754/hls-encoded-video-audio-ffmpeg… [13:18:29 CEST] <acresearch> people is ffmpeg available in flatpak or snap? [14:29:52 CEST] <Aerroon> is it possible to burn in subtitles without reencoding the video? [14:30:47 CEST] <TheAMM> No. [14:31:38 CEST] <Aerroon> as in not possible with ffmpeg or not possible at all? [14:31:43 CEST] <Aerroon> i'm guessing it's the latter [14:32:28 CEST] <TheAMM> Burning means it's added to the video frames themselves, you have to encode to do that [14:32:43 CEST] <Aerroon> yeah, i figured [14:33:03 CEST] <Aerroon> but i was hoping that maybe since it's only additive there's some other possibility there [14:34:06 CEST] <TheAMM> You can add subtitles to a video file without touching the video stream, but you're asking about modifying the video stream, so you have to modify it to modify it [14:44:27 CEST] <ringo_> Hello [14:45:11 CEST] <ringo_> Anyone active today? I am trying to use latest git ffmpeg with latest nvidia to decode hevc and output to decklink [14:45:30 CEST] <ringo_> it works with software decoder but with hardware decoder it cannot perform the pixel format conversion [14:45:56 CEST] <ringo_> it is almost as if when you use cuvid, additional pixel format conversion is not possible [14:46:15 CEST] <ringo_> and hevc_cuvid does not support 422 which is required for decklink output [14:51:42 CEST] <kepstin> ringo_: cuvid decodes to graphics card memory, you might have to use a 'hwdownload' filter to copy it into cpu memory so stuff like pixel format conversions can be done [14:52:17 CEST] <kepstin> and yeah, depending on the codec and card generation, it might be limited to decoding 420 only [14:57:56 CEST] <BtbN> cuvid/nvdec simply cannot decode anything but 420 and in some cases 444 [15:58:26 CEST] <SixEcho> trac down? [16:04:27 CEST] <Freneticks> hey what is the purpose of -max_delay ? [16:04:32 CEST] <Freneticks> I'm not sure to understand ? [16:04:42 CEST] <Freneticks> "Set maximum muxing or demuxing delay in microseconds." [16:27:54 CEST] <Freneticks> also is there a way to aac reencode in a zerolatency way ? [16:29:00 CEST] <Freneticks> If I understand -preset veryfast and -tune zerolatency is only for x264 ? [16:29:36 CEST] <Freneticks> since my video is -c copy [16:38:07 CEST] <Ariyasu> -max_delay lets you add a delay to a track [16:38:17 CEST] <Ariyasu> it's usefull for fixing out of sync issues [16:42:07 CEST] <DHE> Is AAC even a delayed encode codec? [18:36:20 CEST] <rmbeer> hello [18:36:38 CEST] <rmbeer> i'm use this line for make a concatenate videos: ffmpeg -f concat -safe 0 -i /tmp/bsr3.txt video.mp4 [18:37:11 CEST] <rmbeer> but have a problem that also search videos in /tmp/ directory, how to maintain the directory for videos in the ./ ? [18:41:33 CEST] <rmbeer> https://paste.rs/W9L.mp4 [18:41:45 CEST] <rmbeer> wrong channel, sorry... [18:44:53 CEST] <kepstin> DHE: it has overlapped frames and requires preroll, so there's gonna be some delay [18:48:37 CEST] <kepstin> pretty much every lossy audio coded uses overlapping frames so none of them are true "zero latency", but some of them can be configured with low delay, opus down to 5ms minimum iirc? [18:50:46 CEST] <kepstin> and really, i don't think you can call it 0 delay unless the encoder outputs one frame for each 1 sample input ;) just collecting multiple samples into a frame introduces delay. [20:54:29 CEST] <ringo_> kepstin, what is the correct syntax for the download filter (I am assuming I need to use scale_npp) ... and where to do I place it (right before the -pix_fmt to 422)? [20:55:09 CEST] <kepstin> ringo_: I gave you the literal name of the filter to use [20:56:29 CEST] <kepstin> hmm, that said, I thought ffmpeg would automatically insert it in some cases. Can you please pastebin the command you're currently running and the full output? [20:57:08 CEST] <ringo_> full output with debug? [20:57:40 CEST] <kepstin> "-v verbose" might be useful, since that prints some info about what the filter chain setup is doing [21:12:42 CEST] <ringo_> here it is [21:12:42 CEST] <ringo_> https://pastebin.com/ss9ZVqep [21:14:01 CEST] <kepstin> ringo_: huh. I guess it should be sufficient for you to just add `-vf hwdownload` to that command to make it work [21:14:21 CEST] <kepstin> then the auto-inserted scale filter will be put after hwdownload [21:15:39 CEST] <ringo_> I added it to the wrong place maybe? [21:15:39 CEST] <ringo_> https://pastebin.com/741xyR4t [21:15:44 CEST] <ringo_> new error is [21:15:55 CEST] <ringo_> [hwdownload @ 0x112d880] Invalid output format uyvy422 for hwframe download. [21:16:10 CEST] <kepstin> ah, you'll probably need `-vf hwdownload,scale` then [21:16:32 CEST] <kepstin> or maybe `-vf hwdownload,format=nv12` [21:17:25 CEST] <ringo_> the scale one does not work .... [hwdownload @ 0x112d880] Invalid output format monow for hwframe download. [21:18:12 CEST] <ringo_> format=nv12 works!!! [21:19:09 CEST] <ringo_> but it behaces the same as no hardware decoder :( .... one cpu maxes out and I get dropped frames [21:19:10 CEST] <ringo_> Last message repeated 9 times [21:19:10 CEST] <ringo_> [decklink @ 0x6f33c0] There are not enough buffered video frames. Video may misbehave! [21:19:10 CEST] <ringo_> [decklink @ 0x6f33c0] There's no buffered audio. Audio will misbehave! [21:19:11 CEST] <ringo_> [decklink @ 0x6f33c0] There are not enough buffered video frames. Video may misbehave! [21:19:13 CEST] <ringo_> [decklink @ 0x6f33c0] There's no buffered audio. Audio will misbehave! [21:23:07 CEST] <ringo_> here is the full log [21:23:07 CEST] <ringo_> https://pastebin.com/ekCvMBZW [21:25:22 CEST] <ringo_> the cpu is already a Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz [21:25:37 CEST] <ringo_> not sure anything faster would help in this case [21:48:44 CEST] <ringo_> so, the bottleneck is either in the hwdownload or the conversion from nv12 to yuv422 ... is there anything I can do to "fix" this ... or is this a software/hardware limitation? [21:49:25 CEST] <ringo_> a multithreaded conversion would help ... I think the pixel format conversion is single threaded and in this case the frames are very large, i.e. 4k60 [22:07:39 CEST] <kepstin> ringo_: hmm. it might actually be possible to get the gpu to do the pixel format using the scale_npp filter. could be worth a try. [22:10:29 CEST] <kepstin> although it appears to only support yuv420p, nv12, and yuv444p, so taht doesn't help if you need 4:2:2 [22:22:39 CEST] <ringo_> kepstin, yes, I looked into scale_npp and it does not support 422 [22:23:44 CEST] <ringo_> why does this appear to work but gives me a double image? [22:23:45 CEST] <ringo_> ./ffmpeg -re -hwaccel nvdec -hwaccel_output_format uyvy422 [22:24:01 CEST] <ringo_> and system appears to keep up [22:25:13 CEST] <ringo_> but output image on SDI is double (side by side) and with incorrect colors [22:45:26 CEST] <th3_v0ice> What change in frame properties require filter reinitialization? Using the API. Width, height, pixel format, what else? [22:55:48 CEST] <kepstin> it really depends on the filter. [22:56:02 CEST] <kepstin> like the fps filter, for example, doesn't care about any of those fields. [22:56:37 CEST] <kepstin> where as some other filter might just save the inital values for something and segfault horribly if they change :/ [22:57:44 CEST] <kepstin> in general, for filters that manipulate video data in frames i'd go with that, and also the color range/primaries/trc [23:40:56 CEST] <MoziM> can ffmpeg extract the raw frames of a video without duplicates or interlaced frames? [23:42:27 CEST] <kepstin> MoziM: you get a big ol' "it depends on your requirements and your input video, but probably" [23:45:22 CEST] <kepstin> MoziM: duplicate frames can be detected and removed by filters. interlaced frames, if correctly marked as such, can be dropped using e.g. the select filter. If the frames are unmarked, you can consider using the idet filter to look for frames with combing artifacts, but it'll require some tuning. [23:46:28 CEST] <kepstin> are you trying to clean up a poorly detelecined video? [23:47:24 CEST] <th3_v0ice> kepstin, thanks [23:49:39 CEST] <MoziM> kepstin: i don't know what that would even look like :o [23:49:53 CEST] <MoziM> kepstin: lots horizontal lines? [23:50:15 CEST] <MoziM> kepstin: also, i'm just curious how videos in general work really [23:51:50 CEST] <kepstin> the typical computer representation of interlaced video combines two "fields" (half-frames) from different times into a single frame. the fields are alternating lines [23:52:10 CEST] <furq> if you're asking if dupe frames or interlaced frames are stored differently then it depends but usually no [23:52:11 CEST] <kepstin> so if you look at it without using a deinterlacing filter, you'll see horizontal stripes of two slightly different images [23:52:33 CEST] <kepstin> this effect is called "combing" [23:52:41 CEST] <BtbN> Technically, they are deinterlaced. Using the weave filter. [23:53:03 CEST] <BtbN> Without deinterlacing, they are two seperate fields. [23:53:35 CEST] <BtbN> But the default way for ffmpeg to transport them is two fields weaved into one frame. [23:55:15 CEST] <kepstin> when interlaced video is being transmitted as video (e.g. analog or SDI), rather than in computer memory, it'll send fields separately rather than combined into a single frame, yeah. [23:56:03 CEST] <kepstin> there's a lot of weird stuff we have to deal with in computer video that's just leftovers from old analog transmission systems :/ [23:56:36 CEST] <BtbN> Which for some reason someome thought would be a good idea to keep using for 1080p video in purely digital transmission [23:57:01 CEST] <kepstin> and a lot of the time, people get it wrong... https://www.kepstin.ca/dump/Screenshot%20from%202017-07-19%2023-36-08.png [23:57:05 CEST] <furq> interlaced frames are normally encoded by frame though right [23:57:15 CEST] <furq> like the macroblocks will span two fields [23:57:18 CEST] <kepstin> depends on the codec and encoder [23:57:18 CEST] <BtbN> h264 can do both [23:57:25 CEST] <furq> i know h264 has that PAFF mode but i don't think anything supports it [23:57:30 CEST] <furq> x264 apparently doesn't [23:57:40 CEST] <BtbN> nvenc _only_ supports PAFF [23:57:44 CEST] <furq> oh really [23:57:52 CEST] <BtbN> Which is why ffmpeg can't encode interlaced content with it [23:57:57 CEST] <kepstin> i think they added an interlaced mode to hevc that encodes fields as separate half-height frames or something? [23:58:08 CEST] <JEEB> kepstin: that mode already was in AVC [23:58:08 CEST] <BtbN> There is no way for ffmpeg to feed separate fields into an encoder [23:58:10 CEST] <BtbN> which nvenc wants [23:58:31 CEST] <JEEB> it just no longer has super special encoding modes like PAFF [23:58:46 CEST] <JEEB> if you just flag your picture as top/bottom field and interlaced [23:58:58 CEST] <JEEB> that should let you code field pictures in both AVC and HEVC [23:59:28 CEST] <kepstin> JEEB: ah, so it's all just metadata, not a different encoding mode? [00:00:00 CEST] <JEEB> yes, field pictures vs frame pictures [00:00:00 CEST] --- Fri Jun 14 2019

1 0

ffmpeg-devel.log.20190612
by burek 13 Jun '19

13 Jun '19

[00:11:56 CEST] <nevcairiel> I'm surprised that HEVC interlaced gets mentioned as rarely as it does, seems like we won and noone really cares about it [00:13:34 CEST] <nevcairiel> the reason ffmpeg outputs it half-height is technically not a bug, but a missing feature, since hevc interlaced streams are quite simply half-height frames and metadata :D [00:22:07 CEST] <mkver> Yes, the fact that HEVC is different in this regard with most (all?) the other codecs that have dedicated interlaced modes is the reason why I am interested in what counts as height for interlaced HEVC. [00:22:35 CEST] <mkver> with -> compared to [00:22:40 CEST] <nevcairiel> its different because they really didn't want to do interlaced, but in the last minute some industry people forced that metadata thing in [00:23:10 CEST] <mkver> Yes. Would have been good if interlaced had been abandonded long ago. [00:23:48 CEST] <nevcairiel> at one point someone tried to add interlaced support, but the first iteration of the patch was flawed and then apparently abandoned [00:23:53 CEST] <nevcairiel> never heard anything of it ever again [00:24:09 CEST] <Lynne> needing both container and codec metadata sounds fragile too [00:25:14 CEST] <nevcairiel> majority of players don't care or need container metadata for such things [00:25:52 CEST] <nevcairiel> hevc was designed with broadcast in mind, which means mpegts, and as such barely any metadata [00:26:16 CEST] <nevcairiel> mkv just wants to have nice values in their headers, but its not required for hevc, and will be ignored by most players [00:27:59 CEST] <mkver> Probably yes. Anybody who wants to support interlaced HEVC and tests actual files will indeed find out that mkv's header dimensions are unreliable. [00:29:30 CEST] <nevcairiel> Container dimensions are honestly quite meaningless on encoded bitstreams that have their own codec dimensions anyway. No matter if right or wrong. If it matches, its fine, if it doesn't match .. you can't exactly use container dimensions to decode a video of mismatching dimensions, so you still ignore it. [00:31:12 CEST] <mkver> Yes, they are normative in the standards, but are actually only informative (as far as encoded pictures are concerned; this does not apply to aspect ratio stuff). [00:31:54 CEST] <mkver> Huh, the way the picture display orientation SEI is parsed is all wrong. [00:32:18 CEST] <nevcairiel> even with aspect ratio its mostly a guessing game which value is actually correct, container vs. bitstream [00:33:03 CEST] <nevcairiel> i think i made it use container for mkv and mp4 and bitstream for everything else, or some shit like that [00:33:35 CEST] <mkver> True for mkv and mp4. [00:45:21 CEST] <cone-130> ffmpeg 03Limin Wang 07master:5fc8d87ba695: libavfilter/vf_cover_rect.c: free the allocated frame [01:20:54 CEST] <mkver> Good night! [03:00:33 CEST] <cone-130> ffmpeg 03Ruiling Song 07master:83f9da77684e: avfilter/vf_gblur: add x86 SIMD optimizations [03:00:34 CEST] <cone-130> ffmpeg 03Ruiling Song 07master:8f4963ad25ac: checkasm/vf_gblur: add test for horiz_slice simd [05:51:40 CEST] <vtorri99978666> michaelni hello [05:51:58 CEST] <vtorri99978666> michaelni do you plan to release 4.2 soon ? [05:52:10 CEST] <vtorri99978666> michaelni for the name , Srinivasa Ramanujan :) [12:04:54 CEST] <cone-451> ffmpeg 03Michael Niedermayer 07master:4896fa18add7: avcodec/h264_parse: Use 64bit for expectedpoc and expected_delta_per_poc_cycle [12:04:54 CEST] <cone-451> ffmpeg 03Michael Niedermayer 07master:914d6a7c1a7a: avcodec/interplayvideo: check decoding_map_size with video_data_size [12:04:54 CEST] <cone-451> ffmpeg 03Michael Niedermayer 07master:640e401aedb3: tests/ref/fate/nuv-rtjpeg: Preserve the original timestamps [12:04:54 CEST] <cone-451> ffmpeg 03Michael Niedermayer 07master:e5f92f3fbadb: avcodec/v4l2_m2m_dec: Fix memleak on ff_v4l2_m2m_codec_init() failure [12:04:54 CEST] <cone-451> ffmpeg 03Michael Niedermayer 07master:442375fee7f1: avcodec/mjpegdec: Check for non ls PAL8 [12:08:26 CEST] <cone-451> ffmpeg 03Peter Ross 07master:a212c8da48fe: avcodec/vp3: spin off get_eob_run and get_coeff coeff functions [12:08:27 CEST] <cone-451> ffmpeg 03Peter Ross 07master:43dbdee26491: VP4 video decoder [12:08:28 CEST] <cone-451> ffmpeg 03Peter Ross 07master:8913af7d94d4: avformat/riff: add VP4 fourcc [12:25:24 CEST] <JEEB> nice, vp4 [12:30:38 CEST] <j-b> very cool [12:30:56 CEST] <j-b> little usage, but very cool [12:41:11 CEST] <thardin> does this complete the entirely collection of duck codecs? [12:48:59 CEST] <pross> vp3.0 is missing [12:50:13 CEST] <kurosu> Does vp10 count as a duck codec? [12:51:09 CEST] <pross> vp 10 was quickly shelved, and became av1, no? [12:51:50 CEST] <kurosu> And besides that, that's post-google [12:52:33 CEST] <kurosu> (but duckduckgo got to complain) [12:54:49 CEST] <pross> i am waiting for a post-google world [13:05:25 CEST] <cone-451> ffmpeg 03Peter Ross 07master:f4c35a458f9d: fate: add VP4 test [15:29:03 CEST] <cone-451> ffmpeg 03James Almer 07master:f66bd0e8de2e: configure: add missing dnn dependency to derain filter [15:55:42 CEST] <cone-451> ffmpeg 03James Almer 07master:b8f1542dcbad: avfilter/vf_gblur: add missing preprocessor check [18:26:57 CEST] <tmm1> verizon fios in the usa just started broadcasting 4k hevc content, and it looks like ffmpeg is unable to decode it (Error parsing NAL unit #3. PPS id out of range: 0) [18:27:50 CEST] <tmm1> lots of "First slice in a frame missing." too [18:29:33 CEST] <kierank> tmm1: sure it's not partially encrypted? [18:31:35 CEST] <tmm1> not encrypted, this is after cablecard decrypted it [18:31:37 CEST] <tmm1> https://tmm1.s3.amazonaws.com/fios-hevc-usa.mpg [18:58:39 CEST] <nevcairiel> PPS id out of range is usually an indication of a bad cut or otherwise missing SPS/PPS data [18:59:33 CEST] <JEEB> tmm1: if you look with the trace_headers bsf see if there are any PPS/SPS things [18:59:57 CEST] <nevcairiel> actually plays for me [19:00:02 CEST] <nevcairiel> there are errors at the start [19:00:04 CEST] <nevcairiel> but then its fine [19:00:17 CEST] <nevcairiel> errors at the start of a broadcast recording are normal, tbh [19:00:22 CEST] <JEEB> yea [19:00:37 CEST] <JEEB> ok, if it plays then it is probably OK and the GOP is just longer than tmm1 has expected or something :) [19:02:04 CEST] <tmm1> hm i'm using ffplay from master and it doesn't play back [19:03:37 CEST] <nevcairiel> i never use ffplay, so *shrug* [19:04:46 CEST] <JEEB> tmm1: after a while brings up video for me with my older mpv [19:05:12 CEST] <mkver> And remuxing it to Matroska fails: Error parsing AAC extradata, unable to determine samplerate. [19:05:22 CEST] <mkver> So it's maybe the audio that's making problems? [19:05:32 CEST] <nevcairiel> i g et both audio and video during playback [19:05:39 CEST] <nevcairiel> but the fate of badly cut broadcast streams [19:05:49 CEST] <nevcairiel> you have to deal with corrupt data at the beginning [19:05:53 CEST] <JEEB> yea [19:06:02 CEST] <JEEB> or not corrupt but not necessary start-of-packets [19:06:12 CEST] <JEEB> tmm1: swdec works as well, I will attempt to rebuild now to make sure current master works [19:06:15 CEST] <jamrial> trace_headers shows sps+pps+vps in the first packet [19:06:32 CEST] <JEEB> ok, so then it's waiting for IRAP [19:06:45 CEST] <JEEB> both swdec and hwdec work for me [19:06:55 CEST] <JEEB> (with my earlier build from this year) [19:11:10 CEST] <mkver> Decoding audio results in "Sample rate index in program config element does not match the sample rate index configured by the container." and "Too large remapped id is not implemented. Update your FFmpeg version ..." together with the typical "upload sample" stuff. [19:11:33 CEST] <JEEB> mkver: that goes normal after a while [19:11:35 CEST] <nevcairiel> i get that too [19:11:36 CEST] <tmm1> hmm mpv is actually playing it fine for me too [19:11:39 CEST] <nevcairiel> but it just plays after [19:11:48 CEST] <tmm1> wonder what i was doing yesterday then.. [19:11:55 CEST] <tmm1> maybe it wasn't working with vtdec on my mac [19:12:59 CEST] <JEEB> I think VT might need a different format or something - not sure [00:00:00 CEST] --- Thu Jun 13 2019

1 0

ffmpeg.log.20190612
by burek 13 Jun '19

13 Jun '19

[00:27:51 CEST] <exonintrendo> how can i cut a video with a specific start time but also set the start time of the video's metadata? [01:07:35 CEST] <Kaedenn1> What does this error mean? [mjpeg @ 0x323f300] Format mjpeg detected only with low score of 25, misdetection possible! [01:07:59 CEST] <Kaedenn1> My command is just `ffmpeg -i timelapse.mjpeg -r 30 timelapse.mp4` [01:08:42 CEST] <nicolas17> it's just a warning, it detected mjpeg but it's not sure it's right [01:08:46 CEST] <nicolas17> is it mjpeg? :) [01:13:39 CEST] <cehoyos> DHE: No, in the past we had an ftp server, now it's only samples.videolan - but the idea of any sample is of course to make it publically readable, private samples are of limited usefulness;-( [01:16:02 CEST] <cehoyos> Kaedenn1: If the video is not mjpeg, we would like to have a sample [01:21:42 CEST] <Kaedenn1> The video is made via "cat images-today/snap-*.jpg > timelapse.mjpeg", where each image is indeed a valid jpeg [01:22:37 CEST] <Kaedenn1> unless ffmpeg expects more than just a bunch of catted jpegs in its desired flavor of mjpeg [01:22:54 CEST] <Kaedenn1> like sprinkles, cookie dough, m&ms, etc [01:23:52 CEST] <another> i think mjpeg was a little bit different in the headers [01:24:55 CEST] <nicolas17> do you still have the individual jpgs? [01:25:25 CEST] <another> could throw them into ffmpeg directly [01:25:32 CEST] <nicolas17> ffmpeg -pattern_type glob -i 'images-today/snap-*.jpg' [01:25:55 CEST] <Kaedenn1> I didn't know pattern_type was a valid argument [01:25:57 CEST] <Kaedenn1> Let me try that [01:26:38 CEST] <nicolas17> yeah by default it takes stuff like "foo-%03d.jpeg" for foo-000.jpeg, foo-001.jpeg... [01:26:46 CEST] <Kaedenn1> Yeah, but that's limited to a thousand images [01:26:47 CEST] <nicolas17> but if you want to use * you need -pattern_type [01:26:59 CEST] <nicolas17> what are your filenames like? [01:27:23 CEST] <Kaedenn1> timelapse/20190609/image-20190609130100.jpg [01:27:30 CEST] <Kaedenn1> image-YYYYMMDDHHMMSS.jpg [01:27:43 CEST] <nicolas17> ohh, yeah use glob then [01:27:59 CEST] <nicolas17> with HHMMSS you don't get consecutive numbers [01:28:08 CEST] <Kaedenn1> that works amazingly an bypasses the need for an intermediate step [01:28:15 CEST] <Kaedenn1> and* [01:28:20 CEST] <nicolas17> :) [01:29:14 CEST] <Kaedenn1> where does -r 30 go in that? [01:29:20 CEST] <Kaedenn1> After the input? [01:29:48 CEST] <Kaedenn1> My previous command had it as the last arg before the output file [01:30:27 CEST] <Kaedenn1> Yeah, it works there. [01:31:11 CEST] <nicolas17> everything before a -i is an input option [01:31:48 CEST] <DHE> cehoyos: I'll have to ask someone for permission tomorrow before uploading... this isn't something I normally do [01:32:04 CEST] <cehoyos> Thank you [01:33:08 CEST] <cehoyos> Kaedenn1: Yes, concatenating jpg's makes mjpeg, it is difficult to distinguish between jpeg and mjpeg, that's why you see the warning [01:33:28 CEST] <Kaedenn1> gotcha [01:34:13 CEST] <cehoyos> You can also pipe the images (as mjpeg) into FFmpeg if glob does not work for any reason (you don't need the harddisk memory in case you don't have it) [01:36:14 CEST] <Kaedenn1> this is true [01:36:57 CEST] <Kaedenn1> Because the timelapse capture takes several hours, and because I have the disk space for it, I just download everything then encode. Also makes it so if a single frame fails to download/encode it doesn't trash the entire thing [01:38:04 CEST] <cehoyos> Sounds like a good idea, FFmpeg may fail if a frame is missing. [01:39:13 CEST] <another> Kaedenn1: how are you capturing the jpegs? [01:42:59 CEST] <Kaedenn1> another: downloading them from a WAN-enabled camera [01:43:13 CEST] <Kaedenn1> the camera produces jpeg files when requested [01:44:25 CEST] <another> hmm ic [01:45:51 CEST] <another> you might be interested in motion: https://motion-project.github.io/ [01:48:47 CEST] <Kaedenn1> I'll make a note of that. This might be helpful for the replacement camera [01:48:58 CEST] <Kaedenn1> ...assuming I can get permission to mount it [03:05:05 CEST] <void09> how do you decode only the first n frames of a video? [03:06:11 CEST] <another> -frames:v 3 [03:06:31 CEST] <another> oh wait, decode [03:06:49 CEST] <void09> yes, i want to encode a video and the --limit parameter for the encoder does not work through ffmpeg [03:07:10 CEST] <void09> so i must tell ffmpeg to only process the first n frames of the input video [03:07:33 CEST] <c_14> what another said [03:07:44 CEST] <nicolas17> -frames sets the number of frames to encode, not decode, but the difference shouldn't matter in most transcoding cases [03:10:14 CEST] <void09> works, thanks [03:12:20 CEST] <void09> ffmpeg -i input.mp4 -c:v libaom-av1 -strict experimental -b:v 2M -pass 1 -an -f matroska /dev/null && ffmpeg -i input.mp4 -c:v libaom-av1 -strict experimental -b:v 2M -pass 2 -c:a libopus output.mkv [03:12:27 CEST] <void09> can you please explain how this works? [03:13:20 CEST] <nicolas17> what specifically? [03:13:22 CEST] <nicolas17> two-pass encoding? [03:14:28 CEST] <void09> yes, and that /dev/null redirect [03:14:36 CEST] <void09> and what's with the log file it creates [03:16:08 CEST] <furq> the log file is the only thing the second pass uses from the first pass [03:16:34 CEST] <furq> you can write the first pass video somewhere if you want but you might as well send it to null [03:16:54 CEST] <void09> i see the first pass goes on rather quickly, so i wonder what it does [03:17:14 CEST] <void09> if i send the video to /dev/null it doesn't seem like a real encode but some pre-processing stuff? [03:18:24 CEST] <nicolas17> the important part from pass1 is the log file, which has statistics on the video [03:18:42 CEST] <c_14> it mainly calculates video complexity so it knows where the encoder needs to throw bits and where it can save them [03:19:01 CEST] <c_14> so that the 2nd pass is as close to the given bitrate as possible (and the highest quality for said bitrate) [03:19:05 CEST] <furq> yeah it's just used for ratecontrol [03:19:20 CEST] <void09> oh, the thing is, i'm not using rate control but constant quality [03:19:29 CEST] <furq> for x264 or something that has good quality-based ratecontrol then you generally won't need to use it [03:19:45 CEST] <furq> but vpx and (presumably by extension) aom do not have good quality-based ratecontrol [03:19:49 CEST] <c_14> void09: that command is using constant bitrate and not constant quality [03:19:54 CEST] <furq> also yeah [03:20:01 CEST] <void09> c_14 i'm not using that command [03:20:10 CEST] <void09> jst the part of it with 2 pass [03:20:35 CEST] <nicolas17> afaik if you're using constant quality you don't need two-pass [03:20:39 CEST] <c_14> I'm not sure 2pass is used for anything but constant bitrate [03:20:40 CEST] <furq> you do with vpx [03:20:49 CEST] <c_14> with vpx isn't that the maximum bitrate? [03:20:50 CEST] <furq> vpx only enables certain features in the second pass [03:20:51 CEST] <void09> i was told libaom is not optimized for 1 pass [03:20:56 CEST] <furq> and i assume aom is the same [03:20:59 CEST] <furq> given its lineage [03:21:07 CEST] <void09> and i already got a 0.2kb file size reduction for a 30fps encode :) [03:21:12 CEST] <furq> nice [03:21:18 CEST] <void09> 30 frames* [03:21:29 CEST] <c_14> was going to say [03:21:29 CEST] <furq> the frames will probably look a bit nicer [03:21:32 CEST] <c_14> 200 bytes isn't that much [03:21:53 CEST] <void09> it was just black screen for the first 30 frames so i guess there was not a lot to optimise. but it still did [03:22:48 CEST] <void09> set this up in a virtualbox and i am going to start an insane slowest speed/max quality encode of a full length movie [03:23:10 CEST] <furq> i hope you have a nice calendar to time it with [03:24:53 CEST] <void09> it did 0.4 -0.3 fps in the beginning [03:25:10 CEST] <void09> but it was just intro logos and such. i think it's going to drop a lot in complex scenes [03:25:41 CEST] <void09> oh wait, already 0.2 fps, by selecting the slowest mode [03:26:01 CEST] <void09> so yeah, a calender would be appropiate :) [03:26:13 CEST] <void09> sometimes this summer it should be done though [03:26:20 CEST] <void09> some time* [03:26:29 CEST] <void09> sometime* [03:48:50 CEST] <another> be sure to test your setup with a shorter sequence first [04:03:16 CEST] <void09> of course, that's what i am doing now [04:03:58 CEST] <void09> something is wrong though. 4.5 MB for 100 frames already :( [04:06:51 CEST] <void09> there must be a bug somehwere [04:07:15 CEST] <void09> it's doing 11mbps for very simple slow moving logos [13:47:14 CEST] <^Neo> good morning friends, does anyone know of any way to capture smpte 2022-2 streams? [15:15:12 CEST] <another> void09: https://ffmpeg.org/ffmpeg-all.html#segment_002c-stream_005fsegment_002c-sse… [15:36:31 CEST] <ddubya> is it possible to encode near-lossless mpeg2 video, with -qscale 0 ? The max bitrate I'm seeing for 1080p is around 25mb [15:37:12 CEST] <ddubya> and some detail is lost compared to the source [15:41:27 CEST] <ddubya> my objective is to find something equivalent to prores or cineform but lower bitrates [15:42:21 CEST] <ddubya> that works with davinci resolve free version (so h264 is not an option) [16:56:43 CEST] <kepstin> ddubya: you'd also have to set -qmin, the default is 2. no idea if you'll run into any other issues. [16:59:19 CEST] <kepstin> (also, 1 is the minimum value for mpeg2) [17:03:37 CEST] <bostonmacosx> Helo there [17:05:10 CEST] <bostonmacosx> Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz [17:05:21 CEST] <bostonmacosx> is my processsor which static build should I use? [17:05:37 CEST] <kepstin> bostonmacosx: the one that matches your os [17:05:58 CEST] <bostonmacosx> https://johnvansickle.com/ffmpeg/ [17:06:10 CEST] <bostonmacosx> is all linux juust by processor [17:06:38 CEST] <kepstin> bostonmacosx: assuming you're using a 64bit operating system, "amd64" is the one you want [17:06:49 CEST] <bostonmacosx> RHEL6 [17:07:01 CEST] <bostonmacosx> eeven iif the processor is intel? [17:07:23 CEST] <furq> yes [17:07:27 CEST] <kepstin> amd created the 64bit processor extensions, so it's called amd64 for historical reasons. [17:07:37 CEST] <kepstin> intel and amd are compatible nowadays for that [17:07:41 CEST] <bostonmacosx> ah ok....good to know Ii'm uused to seeing x86_64 [17:07:48 CEST] <bostonmacosx> for 64 bit stuff [17:08:33 CEST] <furq> iirc intel still has to pay amd a license fee for amd64 [17:08:35 CEST] <furq> which is pretty cool [17:08:41 CEST] <kepstin> (iirc intel officially calls it "emt64", and "x86-64" is a vendor-neutral term) [17:08:53 CEST] <furq> amd should make it a term of the license that intel has to call it amd64 [17:08:55 CEST] <mooniac> my .mkv clip is a sequence of segments that I want to selecctively keep or drop, based on time stamps, in the final version. Is there a way to give time stamps in a text file in which I specify the "keep" segments or the "drop" segments? [17:11:24 CEST] <kepstin> mooniac: you might consider using the ffmpeg concat demuxer, which can take a list of files with input and outpoint. https://www.ffmpeg.org/ffmpeg-formats.html#concat-1 [17:11:37 CEST] <kepstin> mooniac: list the same file multiple times with different inpoints and outpoints [17:13:08 CEST] <mooniac> great, thanks [17:13:55 CEST] <kepstin> although that has some caveats - seeking isn't exact (keyframe boundaries only) since it concatenates before decoding. [17:14:36 CEST] <kepstin> if you want exact seeking you'd have to write out a filter chain (which you can put in a file with -filter_complex_script fwiw) [17:14:49 CEST] <kepstin> no really simple way [17:15:00 CEST] <mooniac> well, yes, I would have to have exact segment times, down to the second. [17:15:08 CEST] <mooniac> OK, then it seems a video editing software is better [17:17:02 CEST] <kepstin> yeah, this is one of those things where it's not very hard to write an application using ffmpeg apis that does that - but the ffmpeg cli doesn't have the functionality builtin. [17:17:38 CEST] <mooniac> thanks anyway. Good to hear that someone can at least *confirm* there is no easy way. [17:21:29 CEST] <kepstin> an easy to use filter could be written that does this... but not optimally, since it would have to spend time decoding and discarding the parts of the video you don't want instead of seeking over and skipping them (filters can't trigger seeking). [17:21:50 CEST] <kepstin> could be put into the ffmpeg cli itself, but it would be a per-input option, i think. might be ok that way. [17:33:58 CEST] <kepstin> heh, there's also the hilarious option of making an "edl demuxer" (input format) that runs the decoders inside the demuxer so it can do frame accurate timeline editing with seeking. there's precedent for that with the vapoursynth input i suppose. [18:30:50 CEST] <ddubya> kepstin, thank you, setting qmin gives me around 60-70mb now [20:19:36 CEST] <chinknot> is it possible to specify differnet scale filter for different sources in filter_complex? I'd liek to first scale one of the multiple inputs and finally scale the output video, is this what [in] and [out] are for? [20:20:58 CEST] <furq> chinknot: -i foo -i bar -filter_complex "[0:v]scale=1280:720[tmp];[tmp][1:v]concat,scale=1920:1080" [20:21:01 CEST] <furq> something like that [20:21:36 CEST] <chinknot> what is the [tmp] for? [20:21:55 CEST] <another> output for the first scal [20:21:59 CEST] <another> *scale [20:22:39 CEST] <chinknot> and is that concat there because you assumed I was using multiple video sources? [20:24:49 CEST] <chinknot> actually, where can I read more about [tag] in the documentation? I always get confused whenever people use them [20:25:28 CEST] <JEEB> probably documented somewhere in the libavfilter filter chain documentation [20:25:34 CEST] <JEEB> it's basically naming inputs and outputs [20:25:52 CEST] <JEEB> [some_input]split=2[first_output][second_output] [20:26:14 CEST] <ddubya> i'm using -c:v mpeg2video -qscale:v 0 -qmin 1 -qmax 1 -g 30, and I get a bitrate around 50-60mb. However there are blocking artifacts in the dark areas of frame, any suggestions? [20:26:16 CEST] <JEEB> the thing just has to be available in the filter chain [20:26:40 CEST] <ddubya> whilst still using mpeg2 [20:26:52 CEST] <JEEB> also ffmpeg.c can then -map those filter chain outputs as well like -map '[some_output]' [20:31:01 CEST] <ddubya> hmm using yuv422p seems to help [20:36:04 CEST] <furq> chinknot: you can replace concat with any filter that has two inputs and one output [20:36:18 CEST] <furq> or >1 inputs, i should say [20:37:43 CEST] <kepstin> ddubya: many of the generic options in https://www.ffmpeg.org/ffmpeg-codecs.html#Codec-Options apply to the mpeg2video encoder if you want to start poking at stuff. it looks like there is some perceptual masking stuff e.g. dark_mask that you could tweak. [20:38:22 CEST] <kepstin> ddubya: although as far as values and ranges for those options... only way to know what they do is read the c code i guess :( [20:39:14 CEST] <kepstin> (there's also private options on the mpeg2video encoder itself) [20:47:26 CEST] <ddubya> kepstin, yes I'm looking at -luma_elim_threshold now, nothing to be found online about it [22:14:02 CEST] <rustyraptor> Ok so I really don't know if this is the right place to discuss this. It's kinda weird so bare with me. [22:14:23 CEST] <rustyraptor> So I use 2 programs that use ffmpeg and melt to render and encode videos [22:14:30 CEST] <rustyraptor> Kdenlive and Shotcut [22:14:36 CEST] <rustyraptor> and I've had this happen to me twice. [22:14:49 CEST] <rustyraptor> If I try to open the video while it's rendering in VLC [22:14:58 CEST] <rustyraptor> The end result is a negative of the video. [22:15:05 CEST] <rustyraptor> Like the video but with the colors inverted. [22:15:19 CEST] <rustyraptor> How does that even work? [22:16:17 CEST] <rustyraptor> It might not be related to me opening the file though. It could be because I used hevc_nvenc instead of h264_nvenc when i encoded them. [22:16:31 CEST] <rustyraptor> I can't find anything about this anywhere. So I don't know if it's a bug. [22:16:55 CEST] <kepstin> rustyraptor: no idea what's going on, and you haven't provided enough information to even speculate on it. [22:21:19 CEST] <eschie> Can someone explain to me why an HLS encoded video would play fine until seeking past the buffer, upon which the audio drops out? [22:22:24 CEST] <eschie> I'm assuming it has to do with differing segment length between the video and audio? [22:24:16 CEST] <eschie> If so, would my encoding via ffmpeg benefit from strict duration? [22:36:04 CEST] <rustyraptor> kepstin: ok so I managed to replicate the process using the ffmpeg cli [22:36:12 CEST] <rustyraptor> Here is the output [22:36:20 CEST] <rustyraptor> https://pastebin.com/reCgYmX4 [22:36:40 CEST] <rustyraptor> I will try doing it with h264 to see if it's different. I have a feeling that may be the actual cause. not me trying to open it. [22:37:39 CEST] <kepstin> rustyraptor: by definition, mp4 files are unplayable while they're encoding, i'd expect players to error out with a 'missing moov' (or similar error) rather than play it [22:38:24 CEST] <kepstin> the issue is that with mp4 you can't write out some of the required decoder initialization settings stuff until it's done and at the end of the file [22:38:48 CEST] <kepstin> rustyraptor: if you want to play a file while it's encoding, use a different format. [22:39:02 CEST] <kepstin> (mkv works ok with current ffmpeg releases and most players, i think) [22:39:52 CEST] <rustyraptor> Oh ok [22:40:20 CEST] <rustyraptor> Well I'm mostly worried about the inverted colors. Would that be due to the mp4 format? [22:40:29 CEST] <rustyraptor> I'll put a screenshot on imgur [22:40:38 CEST] <kepstin> rustyraptor: it shouldn't be playable at all, i have no idea what your player is doing [22:41:39 CEST] <rustyraptor> No I mean after it's done rendering. [22:42:09 CEST] <kepstin> oh, you mean the complete encoded file displays with the colours inverted? [22:42:12 CEST] <kepstin> which players? [22:42:16 CEST] <rustyraptor> Yeah it's on vlc [22:42:32 CEST] <kepstin> only vlc, or can you reproduce it with e.g. mpv, ffplay? [22:43:01 CEST] <rustyraptor> I'll try one sec [22:43:41 CEST] <kepstin> and double-check to make sure you haven't accidentally enabled an option in vlc that inverts video :) [22:43:41 CEST] <rustyraptor> :O it works fine in MPV [22:43:57 CEST] <rustyraptor> but that can't be because VLC views the previous one fine [22:44:05 CEST] <rustyraptor> https://imgur.com/a/vwMvQYA [22:44:32 CEST] <kepstin> also compare the result of hevc_nvenc to e.g. libx265 to see if it's the codec or something with the particular encoder [22:44:57 CEST] <rustyraptor> Wait what the heck [22:45:03 CEST] <rustyraptor> there was a negate colors option enabled [22:45:06 CEST] <rustyraptor> in both [22:45:10 CEST] <rustyraptor> but only one turned out negative [22:45:16 CEST] <rustyraptor> how? [22:45:21 CEST] <kepstin> lol [22:45:36 CEST] <kepstin> ??? that's vlc for you i guess [22:45:41 CEST] <rustyraptor> lmao [22:45:56 CEST] <rustyraptor> I think I remember using it for a thermal camera video [22:46:16 CEST] <rustyraptor> but why it only shows when I used h265 is blowing my mind right now [22:46:30 CEST] <rustyraptor> Lets see if it does it in h264 [22:47:07 CEST] <rustyraptor> Nope [22:47:14 CEST] <rustyraptor> I toggled it on and off and nothing [22:47:16 CEST] <JEEB> probably depends on the full playback chain in vlc or something if the checkbox has no effect [22:47:30 CEST] <kepstin> I guess you have a bug to report to vlc, the negate colours option doesn't work with some codec/playback combinations [22:47:35 CEST] <JEEB> vlc should have a thing to check the full listing of modules utilized [22:47:46 CEST] <JEEB> but yea, it's a vlc thingamajig [22:50:44 CEST] <kepstin> i wouldn't be surprised if it's something like vlc is using a hardware decoding playback chain for h264 but software for h265 [22:51:23 CEST] <kepstin> (which is weird, because i'd expect an nvidia card with a hevc encoder to also have a decoder, but whatever) [23:00:27 CEST] <rustyraptor> Yeah I'll report it to VLC [23:00:37 CEST] <rustyraptor> though I do see a HEVC decoder in the GPU settings [23:01:55 CEST] <rustyraptor> https://imgur.com/UOIapOX [23:02:09 CEST] <rustyraptor> It's at the bottom there. Not as extensive as the others it seems [00:00:00 CEST] --- Thu Jun 13 2019

1 0