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

[burek]

[00:19:54 CET] <peetah> ok after some more search, it seems the problem may come from visioforge which is used by their software
[00:20:34 CET] <peetah> they state that ffmpeg is dual licenced LGPL and GPL, but choose LGPL : http://visioforge.com/support/717091-Decoding-in-Video-Edit-SDK-with-FFMPEG
[00:21:26 CET] <peetah> this seems plain wrong to me, but the message is from 2013, so I don't know what was the licence status then
[00:22:04 CET] <JEEB> if they have compiled FFmpeg with --enable-gpl then that's a specific wish to utilize functionality that makes the license become GPL
[00:22:15 CET] <JEEB> LGPL is the default
[00:26:53 CET] <peetah> so it seems visioforge is the infringer and the software I'm talking about, and all the visioforge clients, just a collateral victim of visioforge poor choices
[01:09:56 CET] <MastaG> Hi, I'm reading up on the wiki on how to use the hls segmenter
[01:10:23 CET] <MastaG> I'm trying to transcode and transmux a live stream from tvheadend and publish it
[01:10:30 CET] <MastaG> Here's my paste: http://pastebin.com/F7hByLfQ
[01:11:13 CET] <MastaG> Error while opening encoder for output stream #0:2 - maybe incorrect parameters such as bit_rate, rate, width or height
[01:11:33 CET] <MastaG> Whats wrong with it? Stream #0:2 -> #0:2 (dvb_teletext (libzvbi_teletextdec) -> webvtt (native))
[01:13:31 CET] <llogan> show the *complete* output
[01:13:39 CET] <DHE> MastaG: you've got a typo. -hls_list_size size 10
[01:13:49 CET] <DHE> you've confused it
[01:18:05 CET] <DHE> MastaG: got it?
[01:21:15 CET] <MastaG> yeah
[01:21:31 CET] <MastaG> Here's the complete output: http://pastebin.com/nLr1ZvT8 without the size typo
[01:21:59 CET] <MastaG> I wonder what options I'm missing for the encoding of subtitles
[01:25:08 CET] <MastaG> I mean it already suggests to re-encode the subs from dvb_teletext to webvtt...
[01:25:37 CET] <MastaG> And the wiki does not specify a filename for the webvtt subs either
[01:33:31 CET] <MastaG> llogan: would you happen to find anything?
[01:37:26 CET] <MastaG> well I can also drop the subtitle track with -sn I guess..
[01:37:46 CET] <llogan> i stopped looking when i noticed you used -loglevel debug. it's too verbose
[01:37:55 CET] <MastaG> oh
[01:38:43 CET] <MastaG> well nm.. I'm not mapping the dvb subtitle track anymore.. so it works
[02:51:09 CET] <thebombzen_> does anyone know an easy way to turn a time duration into "seconds"
[02:51:13 CET] <thebombzen_> like a oneliner
[02:53:18 CET] <blb> thebombzen_: like, in code?
[02:53:27 CET] <thebombzen_> well yea
[02:54:13 CET] <thebombzen_> I haven't found an easy oneliner for everything, because the number of colons can vary. it could be h:m:s or m:s or just s
[02:57:17 CET] <thebombzen_> welp, apparently if you use the improved cut it's easy
[03:00:46 CET] <furq> what did you do
[03:05:07 CET] <thebombzen_> with improved cut, it's just: cuts -d':' -1 -2 -3 | awk '{ print $1 + (60 * $2) + (3600 * $3) }'
[03:05:13 CET] <thebombzen_> perhaps there's a way to do it in pure awk tho
[03:06:28 CET] <furq> what's "improved cut"
[03:10:01 CET] <tdr> not sure that would work if there was only like 2 field (minutes and second) since $1 would be minutes vs hours and the seconds would get multilied by 60 not 360
[03:10:08 CET] <tdr> 3600
[03:10:49 CET] <thebombzen_> oh it's the cuts command
[03:10:52 CET] <thebombzen_> it's like cut but doesn't suck
[03:11:28 CET] <thebombzen_> tdr: it does because cuts counts from the end. if you give that awk command no "hours" field it'll assume it's empty
[03:11:45 CET] <furq> http://vpaste.net/xPqBx
[03:11:49 CET] <furq> there's my shitty attempt anyway
[03:11:50 CET] <thebombzen_> and when it does the string->int conversion to multiply by 3600, it should work
[03:12:03 CET] <thebombzen_> I did figure it out with pure awk tho
[03:12:04 CET] <thebombzen_> wk -F: '{for (i=NF; i>1; i--) printf "%s%s", $i, FS; print $i }' | awk -F: '{ print $1 + (60 * $2) + (3600 * $3) }'
[03:12:05 CET] <tdr> hrm, awk could for sure do it too, you could code a payroll system with awk
[03:12:15 CET] <furq> that's with awks, not awk
[03:12:18 CET] <furq> get on my level
[03:12:20 CET] <thebombzen_> the hard part was reversing the fields
[03:12:47 CET] <thebombzen_> ah your method is better
[03:13:20 CET] <furq> you're a two awks on your shoulders kind of guy
[03:14:33 CET] <thebombzen_> yea whereas your prefer to be one big tots awk
[03:15:03 CET] <thebombzen_> although I do not actually say "tots awk" out loud because that would be tots awk
[03:22:53 CET] <thebombzen_> lol look at all the wrong answers to this question: https://stackoverflow.com/questions/6239350/how-to-extract-duration-time-from-ffmpeg-output
[04:01:49 CET] <RossW> llogan/fflogger, either of you watching?
[04:02:53 CET] <k_sze[work]> Is it acceptable for two JPEG decoders to decode an image to slightly different results?
[04:03:00 CET] <RossW> Wanted to send a big Cheers! and thanks to you guys for pointing pointing me in the right directions yesterday.
[04:03:08 CET] <k_sze[work]> I can understand if two JPEG encoders *encode* differently.
[04:03:19 CET] <RossW> Updated to ffmpeg version 3.2.4 (may not be the latest but it does).
[04:03:50 CET] <k_sze[work]> But shouldn't decoding be deterministic, barring postprocessing?
[04:03:58 CET] <RossW> Realized that there was a fundamental flaw in the idea of using timecode or frame*interval+offset, because there was always the chance I had missing stills
[04:04:16 CET] <c_14> k_sze[work]: many codecs aren't bitexact decodable
[04:04:24 CET] <c_14> especially jpeg what with embedded color profiles and whatever
[04:05:33 CET] <RossW> In the end, I wrote a script that writes a subtitle file, with the exact format (HH:MM) I want, keyed to the output video (so new subtitle every 40ms).
[04:05:33 CET] <tdr> k_sze[work], the spec doesnt say they are required to produce bit by bit identical output.  png would but not all the time with jpeg
[04:06:06 CET] <k_sze[work]> I see.
[05:55:23 CET] <YellowberryHN> How does one play an mp3 file from the terminal?
[06:02:50 CET] <furq> YellowberryHN: ffmpeg -i foo.mp3 -f alsa hw:0
[06:03:51 CET] <furq> although if you plan on doing this regularly, you probably want a proper player like mpd/moc/xmms2
[06:08:29 CET] <YellowberryHN> right
[06:08:56 CET] <YellowberryHN> writing a diagnostic script to test aspects of a server
[06:09:06 CET] <YellowberryHN> using that to test sound output
[06:09:13 CET] <YellowberryHN> if it's detected
[06:11:02 CET] <YellowberryHN> furq: "Requested output format 'alsa' is not a suitable output format"
[06:12:03 CET] <furq> what os
[06:12:26 CET] <furq> if it's a headless *nix server then you probably don't have alsa installed, or didn't when ffmpeg was built
[06:12:46 CET] <YellowberryHN> I have alsa installed
[06:13:20 CET] <YellowberryHN> posible that it wasn't built with alsa support
[06:13:26 CET] <furq> ffmpeg -devices
[06:14:14 CET] <YellowberryHN> Missing argument for option devices
[06:14:43 CET] <furq> uh
[06:14:47 CET] <furq> what version of ffmpeg is that
[06:15:47 CET] <YellowberryHN> ffmpeg version 0.8.20-6:0.8.20-0+deb7u1
[06:15:58 CET] <furq> oh wow that's ancient
[06:16:00 CET] <furq> is that debian wheezy
[06:16:14 CET] <YellowberryHN> yeah....
[06:16:21 CET] <furq> fun
[06:16:34 CET] <furq> https://www.johnvansickle.com/ffmpeg/
[06:16:51 CET] <furq> i forget if those builds have alsa support
[06:16:58 CET] <furq> you might need to build it yourself if they don't
[06:16:59 CET] <YellowberryHN> oh yeah
[06:17:04 CET] <YellowberryHN> forgot to mention
[06:17:09 CET] <YellowberryHN> armhf processor
[06:17:17 CET] <furq> there are armhf builds on there
[06:17:19 CET] <YellowberryHN> probably why it's ancient
[06:17:23 CET] <YellowberryHN> oh ok
[06:18:58 CET] <furq> tbh it might be easier to just use sox
[06:19:15 CET] <furq> wheezy has libsox-fmt-all which adds mp3 playback
[06:22:42 CET] <YellowberryHN> That worked, thank you very much
[06:22:51 CET] <YellowberryHN> maybe I should update my debian
[06:22:56 CET] <YellowberryHN> nah..
[06:23:00 CET] <YellowberryHN> thanks again
[06:23:02 CET] <furq> what worked, sox or the static ffmpeg?
[06:23:03 CET] <YellowberryHN> bye!
[06:23:06 CET] <YellowberryHN> sox
[06:23:19 CET] <furq> fair enough
[06:23:20 CET] <YellowberryHN> ffmpeg refused to run
[06:23:51 CET] <YellowberryHN> I think my download was corrupted somehow because it segfaulted
[06:24:27 CET] <YellowberryHN>  anyway, gotta jet, thanks again
[11:57:48 CET] <styler2go> How can i reduce the video size by percentage?
[12:18:17 CET] <dl2s4> styler2go, i guess two pass x264 could aim for specific filesize with a bit calculation. iirc
[12:18:33 CET] <styler2go> sorry, i ment resolution :/
[12:18:39 CET] <styler2go> Always forget size != resolution
[12:22:45 CET] <dl2s4> you could use -s <final_reslution>
[12:31:29 CET] <jkqxz> styler2go:  -vf scale=iw*70/100:-2
[12:32:50 CET] <dl2s4> this would scale it down 70%?
[12:33:39 CET] <jkqxz> To 70% of current size.
[12:35:29 CET] <dl2s4> ah yeah, what i meant :) and why -2?
[12:37:10 CET] <dl2s4> i investigated a bit and it seems -1 means to keep aspect ratio
[12:39:14 CET] <jkqxz> Because lots of things barf on sizes which aren't divisible by 2.
[12:39:50 CET] <jkqxz> (The first part would probably be better as iw*70/200*2 to match.)
[12:41:06 CET] <dl2s4> ah ok, thanks
[17:56:03 CET] <alexpigment> does anyone know how to get a list of pix_fmt options in FFMPEG?
[17:56:28 CET] <alexpigment> i need to make sure I know which pix_fmt options are specific to the 10-bit version of FFMPEG
[17:58:54 CET] <jkqxz> "ffmpeg -pix_fmts"?  Though I'm not sure what you mean by a "10-bit version" of ffmpeg.
[18:00:35 CET] <alexpigment> awesome. that's what i needed. for context, i have a build of ffmpeg that includes 10-bit x264 and x265. to trigger this, i need to have a list of pix_fmts that are exclusive to each. and when a pix_fmt is specified that is exclusive to 10-bit, it'll switch copies of ffmpeg (which are currently mutually exclusive for some reason)
[18:01:55 CET] <kepstin> alexpigment: ffmpeg should support the same pix_fmts in both cases, the difference is in which pix_fmts work with the video encoders...
[18:02:10 CET] <alexpigment> yeah, i guess i'm seeing that now :(
[18:02:26 CET] <kepstin> (like, you can use 10bit video in an ffmpeg with 8bit x264, and it'll just convert it down to 8bit before encoding)
[18:02:42 CET] <alexpigment> well, either way, this list gives me something to work with, since i only need 4:2:0, 4:2:2, and 4:4:4 variants
[18:03:00 CET] <alexpigment> kepstin: i specifically need 10-bit output
[18:03:05 CET] <alexpigment> because, of course, HDR requires it
[18:03:21 CET] <alexpigment> dithering down isn't necessary for my uses
[18:03:25 CET] <kepstin> alexpigment: right, so you have 2 ffmpegs, just name one ffmpeg_10 and run it whenever you need 10bit output?
[18:03:44 CET] <alexpigment> kepstin, this is for automated use based on a command line
[18:04:16 CET] <kepstin> so, how do you know when you need to use 10bit output vs 8bit output?
[18:04:18 CET] <alexpigment> but that's certainly a way to do it
[18:04:32 CET] <kepstin> is it based on the input file? based on telepathically reading the user's mind?
[18:04:43 CET] <alexpigment> keptstin, in my case, i would trigger it based on seeing yuv420p10le, for example
[18:04:59 CET] <kepstin> alexpigment: so, if the input is 10bit, you also want 10bit output?
[18:05:00 CET] <alexpigment> no, it's going to be piped in from a 10-bit BGRA renderer
[18:05:08 CET] <alexpigment> so the input is synthetic
[18:05:17 CET] <alexpigment> no transcoding is involved here
[18:05:24 CET] <kepstin> if the input's always 10bit, then just always use the 10bit encoder? I don't see the problem here.
[18:05:42 CET] <alexpigment> keptstin: 10-bit video is useless as a standard delivery format
[18:06:04 CET] <alexpigment> if you want something for blu-ray, web, or just generally playing on your computer, you need 8-bit
[18:06:30 CET] <alexpigment> however, if you need 4K HDR, you need 10-bit, as well as all the other special colorspace stuff
[18:06:30 CET] <kepstin> alright, so you have two different ffmpegs, you know which is which, and you know whether you want 8 or 10 bit output - so just run the correct one? :/
[18:07:16 CET] <alexpigment> i mean i suppose you have a point. i just planned to approach it differently
[18:07:44 CET] <alexpigment> by detecting pix_fmt in the command line parameters and then automatically using a particular variant of ffmpeg
[18:08:09 CET] <alexpigment> anyway, we'll see how it shakes out. thanks for the advice
[18:08:11 CET] <kepstin> alexpigment: is the user manually running ffmpeg, or is this generated by an application/script?
[18:08:19 CET] <alexpigment> the latter
[18:08:56 CET] <kepstin> then just have the script choose which ffmpeg based on whether it's doing 10bit or 8bit, simple enough :/
[18:08:56 CET] <alexpigment> aight, i gotta get back to this to finish up. thanks again!
[18:09:11 CET] <kepstin> I wouldn't bother trying to parse ffmpeg's command line arguments :)
[18:10:42 CET] <kepstin> (i assume you have static ffmpeg builds in this case; if it was dynamic, both ffmpegs would use the same x264 libs and you'd have to play with e.g. LD_LIBRARY_PATH to switch the bitness)
[18:11:02 CET] <alexpigment> it's dynamic, actually
[18:11:18 CET] <alexpigment> since ffprobe is needed, file size is saved by doing shared
[18:11:21 CET] <alexpigment> er
[18:11:29 CET] <alexpigment> sorry, it's *shared*
[18:11:44 CET] <alexpigment> i don't think the LD_LIBRARY_PATH thing works for Windows, does it?
[18:12:07 CET] <kepstin> ah, windows? It should be fine if the ffmpeg binaries are in separate directories, and the shared dlls used are in the same dir
[18:12:29 CET] <kepstin> same dir as the executables*
[18:13:11 CET] <alexpigment> kepstin - i think i'm missing your point
[18:13:21 CET] <alexpigment> do you mind elaborting a little bit so i understand the benefit?
[18:14:32 CET] <kepstin> alexpigment: you have ffmpeg.exe, ffprobe.exe along with a set of dlls like libavcodec.dll, libx264.dll, right?
[18:14:53 CET] <alexpigment> right
[18:15:25 CET] <kepstin> so the only difference between a ffmpeg supporting 10 bit encoding and one doing 8 bit encoding is that the x264 (and x265) dlls are different
[18:15:52 CET] <alexpigment> i'm not entirely sure that's true, but yes, most likely
[18:16:21 CET] <kepstin> trust me, that's true. you can actually switch it out without rebuilding ffmpeg by just changing the x264/x265 libraries :)
[18:17:19 CET] <alexpigment> ok, so how would you call each one separately?
[18:17:56 CET] <kepstin> alexpigment: but actually switching the dlls on windows is probably a pain, so I wouldn't do that. Just put the 10bit and 8bit ffmpeg builds each in their own directory
[18:18:05 CET] <kepstin> (along with their associated dlls)
[18:18:06 CET] <alexpigment> looking at the folder now, it seems that the avcodec-57.dll files are different. i assume those wrap up the encoders
[18:18:25 CET] <alexpigment> kepstin, yeah that's the plan at the moment
[18:18:38 CET] <kepstin> so you'd run ...\ffmpeg-10\ffmpeg.exe to do a 10bit encode, and ...\ffmpeg-8\ffmpeg.exe to do 8bit encode
[18:18:45 CET] <alexpigment> right
[18:18:45 CET] <kepstin> easy enough
[18:18:53 CET] <alexpigment> i think i'm missing something
[18:18:56 CET] <alexpigment> because that's the plan
[18:19:09 CET] <alexpigment> are you implying that i could do something to save redundancy?
[18:19:25 CET] <kepstin> alright, I'm just confused because you were talking about trying to figure out whether ffmpeg supported 10bit h264 or not
[18:19:58 CET] <alexpigment> kepstin: the point was that i was hoping to trigger off of a command line entry whether to use ffmpeg 10-bit for x265 or to use 8-bit
[18:20:19 CET] <alexpigment> in which case, i was hoping to just trigger off of a defined pix_fmt which only works with one or the other
[18:20:24 CET] <kepstin> alexpigment: ah, and there's no real way to do that without both implementing an ffmpeg command line parse and knowing info about the input file
[18:20:33 CET] <alexpigment> i already have logic to parse that command line, so it's pretty simple
[18:20:46 CET] <alexpigment> the input file is an RBGA pipe
[18:20:51 CET] <alexpigment> there is no transcoding being done here
[18:21:03 CET] <alexpigment> anyway, that's not terribly important though
[18:21:08 CET] <alexpigment> i think i've got all i need now
[18:21:24 CET] <kepstin> but in this case, you're writing an ffmpeg command line saying to use 10bit or 8bit, then reading it and trying to figure out whether you told it to use 10bit or 8bit
[18:21:45 CET] <kepstin> which seems a bit silly, just remember whether you wanted 10bit or 8bit in the first place :)
[18:22:11 CET] <alexpigment> the presets will be just FFMPEG command lines. adding a bit depth is simple, probably, but requires a new check that doesn't currently exist
[18:22:39 CET] <alexpigment> anyway, keptstin, i appreciate your help here, but i think we're talking in circles
[18:22:45 CET] <kepstin> i guess so
[18:22:54 CET] <alexpigment> and i have all i need at the moment
[18:27:01 CET] <kepstin> it's just that in a  given ffmpeg command, you can't always tell whether it's gonna be a 10bit or 8bit encode based *only* on the command line - if you don't explicitly specify an output pix_fmt, then it'll  determine which to used based on what the encoder supports.
[18:27:34 CET] <kepstin> so the same command line will give you 8bit output with an 8bit x264, and 10bit output with a 10bit x264, with no errors etiher way
[18:27:50 CET] <alexpigment> kepstin, yes, the pix_fmt will always be explicitly called in my cse
[18:28:49 CET] <alexpigment> *case
[18:29:02 CET] <kepstin> right. still would probably better to store which ffmpeg to use separately from the command line, but if you know there's always gonna be a "-pix_fmt yuv420p" in there somewhere, that would work.
[18:29:18 CET] <alexpigment> right. that's the current thinking
[18:29:24 CET] <alexpigment> it's always there, so it can be parsed
[18:29:54 CET] <alexpigment> outside of that, i would have to create a new field/flag in the preset code to store something that isn't directly used by FFMPEG
[18:30:19 CET] <kepstin> right, because it's not directly used by ffmpeg, it's a meta flag saying which ffmpeg to use :)
[18:30:25 CET] <alexpigment> i'd rather not make things messy in the preset definitions just to do something that can be inferred by the code to use a particular ffmpeg variant
[18:31:10 CET] <kepstin> alexpigment: fun thing, if you run "ffmpeg -h encoder=libx264" on your two ffmpegs, it'll print out a list of "Supported pixel formats" for the x264 library used
[18:31:28 CET] <kepstin> which i think is actually what you were asking for in the first place
[18:32:34 CET] <kepstin> so you should get "yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21" with the 8bit one, and "yuv420p10le yuv422p10le yuv444p10le nv20le" with the 10bit one (for x264)
[18:33:18 CET] <alexpigment> awesome
[18:33:22 CET] <alexpigment> even better info
[18:33:27 CET] <alexpigment> that was what i was hoping for originally
[18:33:37 CET] <alexpigment> thank you very much for that
[18:34:38 CET] <kepstin> x265 is a bit different, i'm not sure how yours is built, but a single x265 library can support multiple bit depths
[18:34:53 CET] <alexpigment> kepstin, yeah, it "supports it" but fails
[18:35:01 CET] <alexpigment> i think that's a problem with ffmpeg rather than x265 itself
[18:36:22 CET] <alexpigment> fortunately, i'm really only interested in 6 total - 420, 422, and 444, 8 and 10 of each
[18:36:46 CET] <kepstin> alexpigment: hard to say. it depends a lot on exactly how x265 was built; you need to do something special to get a single lib supporting all bit depths
[18:37:10 CET] <kepstin> it can be built to have separate libraries for separate bit depths like x264, too
[18:37:15 CET] <ember3> hi, is there a built-in way to extract per-frame motion, i.e. interpolated from motion vectors? I'd like to compute minima within a time interval. found extract_mvs.c but nothing exposed via in e.g. ffprobe yet
[18:37:58 CET] <alexpigment> yeah i heard yesterday that someone has a way to do it for x264 but it's just a patch at the moment. x265 (which is the only encoder i need 10-bit for) doesn't have a way as far as i understand to support multiple bit depths within ffmpeg
[18:38:58 CET] <kepstin> alexpigment: hmm, works for me with x265 - on linux at least. my linux distro installs one with 8, 10, and 12 bit support :/
[18:40:07 CET] <kepstin> the same command thing, "ffmpeg -h encoder=libx265" should tell you what your particular lib supports with each ffmpeg version
[18:41:09 CET] <kepstin> I get "yuv420p yuv422p yuv444p gbrp yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le yuv422p12le yuv444p12le gbrp12le gray" on my box with the multi-bit-depth support, and "yuv420p yuv422p yuv444p gbrp" on a different one where it can only do 8bit.
[18:41:58 CET] <kepstin> (I assume one built with 10bit support only would look like "yuv420p10le yuv422p10le yuv444p10le gbrp10le")
[18:42:26 CET] <alexpigment> kepstin: yeah, if you try to do yuv420p on the high bit depth one, it'll fail i believe
[18:42:31 CET] <alexpigment> at least in my tests
[21:40:21 CET] <SpeakerToMeat> Greetings.
[21:41:14 CET] <SpeakerToMeat> Question, when outputing a video to DPX codec, is there any way to set the bith depth of the dpx? can't find it
[21:42:15 CET] <JEEB> you feed it a specific format of video it supports
[21:42:38 CET] <JEEB> if you are talking of ffmpeg.c the simplest way might be to utilize -pix_fmt CORRECT_IDENTIFIER after the input
[21:43:02 CET] <JEEB> CORRECT_IDENTIFIER being one of the things listed in ffmpeg -pix_fmts
[21:43:15 CET] <SpeakerToMeat> So other than recoding the source video to another video format, and then recoding it to dpx, there's no way...
[21:43:24 CET] <JEEB> uhh
[21:43:27 CET] <JEEB> there's no recoding
[21:43:39 CET] <JEEB> input => pixel format conversion => output
[21:44:12 CET] <JEEB> input I should have probably noted as decoding and output as encoding
[21:44:37 CET] <JEEB> it's not like it's the *encoder* 's job to suddenly do the pixel format conversion
[21:44:51 CET] <JEEB> an encoder's job is to take an input and encode that image
[21:44:57 CET] <JEEB> or audio sample, or whatever
[21:45:30 CET] <SpeakerToMeat> JEEB: Then why am I getting 16 bith DPX from yuv422p10le ?
[21:45:50 CET] <JEEB> SpeakerToMeat: pardon?
[21:46:31 CET] <SpeakerToMeat> JEEB: Why when inputing yuv422p10le prores video and outputing DPX do I get 16 bit depth DPX instead of 10 bit (or 12 bit linear)
[21:46:32 CET] <JEEB> if it's easier to note by linking your full command line and terminal output in a pastebin-like site and linking it here, please do that
[21:46:52 CET] <SpeakerToMeat> Should I use a pastebin for a single line?
[21:47:10 CET] <JEEB> the terminal output is that short?
[21:47:43 CET] <JEEB> anyways, sounds like automagic conversion routine somewhere decides that is the best route :P
[21:48:07 CET] <JEEB> because you're not specifying the output format
[21:48:45 CET] <JEEB> AV_PIX_FMT_GBRP10BE and AV_PIX_FMT_GBRP10LE are supported by dpxenc
[21:49:00 CET] <JEEB> that said if you're converting from YCbCr to RGB that already kind of drops the input bit depth
[21:49:05 CET] <JEEB> because you're doing a big enough change
[21:54:02 CET] <SpeakerToMeat> JEEB: There you go http://pastebin.com/EMZ7WBue
[21:55:17 CET] <SpeakerToMeat> So I can't set the format if I'm moving from YCbCr to RGB? how do I find the formats dpxenc supports? and how is it specified on the command line? I'm missing it on --help, seriously :(
[21:55:51 CET] <JEEB> you can set the format just fine
[21:56:02 CET] <JEEB> it's what the automagic thing will try to convert the result
[21:56:36 CET] <JEEB> how to find the supported pixel formats I'm not sure since I've always just peeked at the source, but the list is properly defined for each encoder and decoder so in theory it should be possible to show them
[21:57:19 CET] <JEEB> ok, it's `ffmpeg -h encoder=dpx`
[21:57:21 CET] <JEEB> most likely
[21:57:34 CET] <JEEB> I just tested it with my encoder (utvideo)
[21:57:41 CET] <JEEB> and shows a list of pix_fmts that it takes in
[21:57:50 CET] <SpeakerToMeat> Ok I guess the formats are listed with pix_fmts? Yet it doesn't specify which dec/enc supports each of course
[21:57:59 CET] <SpeakerToMeat> thanks I'll check that
[21:58:16 CET] <SpeakerToMeat> JEEB: Yes, that lists the formats. thank you
[22:03:57 CET] <SpeakerToMeat> JEEB: Now do I read you right and if I specify the pixel format for out it'll be overriden by auto?
[22:08:33 CET] <SpeakerToMeat> Second question, if I have video at x*y input, can I output video at x*z (z > y) where the original image is left unscaled, but composited by layers onto a black background with an East (in imagemagick parlance, that is, vertically centered) centering?
[22:08:59 CET] <SpeakerToMeat> Let me google "add letterbox" that might give me a result
[22:09:09 CET] <furq> !filter pad
[22:09:09 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#pad-1
[22:09:37 CET] <SpeakerToMeat> thanks
[22:10:23 CET] <furq> you can use height=(1080-in_h)/2 if you only want to care about the output height
[22:10:54 CET] <furq> wait nvm ignore that
[22:11:19 CET] <furq> you can use x=(1080-in_h)/2
[22:25:32 CET] <SpeakerToMeat> furq: Or I can just put the numbers by hand, since I know the right numbers :)
[22:25:41 CET] <SpeakerToMeat> Of course I have to account for indexing from 0...
[22:26:28 CET] <Darby_Crash> hi guys i can't compile ffmpeg, configure run ok but make fail with this errors: https://clbin.com/1GWUg
[22:28:30 CET] <Darby_Crash> this is the config.log https://clbin.com/2G01m
[23:07:45 CET] <SpeakerToMeat> furq: perfect. thank you
[00:00:00 CET] --- Sat Mar  4 2017