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

[burek]

[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-matrix-and-chroma-placement/ 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