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

[burek]

[02:22:59 CEST] <Bagel> Hi! I just installed FFMPEG v.4 and when I try to execute ffmpeg it just flickers command prompt for a fraction of a second and nothing occurs afterwards
[02:32:56 CEST] <klaxa> it's not a gui program, you use it from the command line
[02:33:10 CEST] <klaxa> ok
[02:54:12 CEST] <dl2s4> :)
[09:08:38 CEST] <bartsimps0n> Hi. I have a high resolution, very low bitrate video (because of the content; there's very little movement).  I am dealing with a third party transcoding system that refuses to create high bitrate renditions of low bitrate source.
[09:09:02 CEST] <bartsimps0n> So I'm trying to pre-transcode a forced high bitrate version of the source video. Yes, I know that's silly.
[09:11:14 CEST] <bartsimps0n> I can't get -minrate or -b:v to force a high bitrate.  (using e.g. -minrate 8M -b:v 8100000 etc.). Is what I"m trying to do possible?
[09:12:17 CEST] <bartsimps0n> (actually, the 3rd party system refuses to create a high resolution rendition of a low bitrate source. I misspoke the first time)
[09:15:34 CEST] <hero100__> bartsimps0n, if the video container is mpegts, you can set muxrate. Not sure if it's a good idea.
[09:17:33 CEST] <bartsimps0n> hero100__: urgh.
[09:17:39 CEST] <bartsimps0n> hero100__: thanks
[09:19:52 CEST] <bartsimps0n> hero100__: hm. that might have worked actually.  :) let me see what this broken system does with it
[10:15:53 CEST] <bartsimps0n> hero100__: it worked.  thanks again.
[10:16:15 CEST] <hero100__> nope
[14:08:08 CEST] <mort> What unit is AVCodecContext's bitrate in? bits/sec or kbit/sec or something else?
[14:16:42 CEST] <BtbN> should be bits
[15:19:48 CEST] <Zgrokl> hello I try to open a udp stream but ffmpeg hang on when i put -f rtp
[15:20:47 CEST] <Zgrokl> but i need to put the -f because if I don't i get a green screen
[15:38:05 CEST] <Zgrokl> how do you -i udp://rtp// ?
[15:44:59 CEST] <mort> So, the video frames created by h264_v4l2m2m are green (as if only the Y-bytes are used and the U and V bytes are set to 0). That doesn't seem quite right
[15:45:18 CEST] <mort> this isn't a problem with my code, because it also happens when using the ffmpeg CLI tool
[15:45:54 CEST] <BtbN> What even uses that stuff?
[15:46:06 CEST] <mort> well, the hardware I'm working with at the moment for one
[15:46:58 CEST] <mort> the theory is that it's a common API for a bunch of hardware ecnoders and decoders to use, so I imagine it'll be used by more stuff in the future too
[15:47:49 CEST] <BtbN> I'd expect more vendor specific APIs instead
[15:49:06 CEST] <mort> I sure hope not, because having to write encoder and decoder wrappers for each weird hardware API kinda sucks
[15:50:22 CEST] <mort> anyways, I'm trying to compile ffmpeg 3.2 (the version which creates green frames is 3.4). Maybe that solves it.
[15:54:02 CEST] <BtbN> So you are trying two outdated versions only?
[15:54:08 CEST] <mort> BtbN: by the way, in ffmpeg 4.0, I get the error "The encoder timebase is not set." from avcodec_open2 from https://www.ffmpeg.org/doxygen/4.0/libavcodec_2utils_8c_source.html#l00538 line 758, even when the time_base field is set in the AVCodecContext. Any idea what could cause that?
[15:54:40 CEST] <mort> https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/encode_video.c that has that issue even when compiling with my system ffmpeg libraries (from arch linux), and you can clearly see it sets time_base
[15:55:16 CEST] <BtbN> That error is printed when AVCodecContext.time_base is invalid.
[15:55:59 CEST] <mort> so https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/encode_video.c#L110 sets time_base incorrectly?
[15:56:29 CEST] <BtbN> the check is num <= 0 || den <= 0
[15:56:59 CEST] <mort> yeah, I've read it, but that makes no sense, because (1 <= 0) is false and (25 <= 0) is false
[15:57:37 CEST] <BtbN> well, the check is pretty straight forward. Something else must be setting it.
[15:58:48 CEST] <mort> Oh, my bad. I was linking to old versions of the headers. I was sure I had removed that -I flag.
[16:20:36 CEST] <Zgrokl> i finaly resolved my issue using 2 input faking the multicast request like this the second input of ffmpeg can get the incoming rtp
[16:20:38 CEST] <Zgrokl> nvm
[16:20:58 CEST] <Zgrokl> but now i get RTP: missed 3-10 packets, any idea why ?
[16:26:51 CEST] <mort> well, h264_v4l2m2m produces green frames with ffmpeg 4.0 too :(
[16:29:40 CEST] <jkqxz> mort:  What hardware?  The support varies a lot between vendors, and each one has their own quirks which can make the common code not work.
[16:31:26 CEST] <jkqxz> I think it was mainly written and tested on qualcomm, with some testing on imx and exynos.  If you're using something else then I would not have bet on it working.
[16:36:40 CEST] <mort> jkqxz: it's a qualcomm venus encoder in the dart sd410, I know the encoder works properly because when using my own encoder wrapper based on https://git.linaro.org/people/stanimir.varbanov/v4l2-encode.git it works
[17:03:53 CEST] <zevarito> Does anyone know why deprecation warnings on OSX are treated as warnings and compiling the same code on Ubuntu those become errors?
[17:05:14 CEST] <kepstin> zevarito: what errors specifically, can you provide a link to the build output?
[17:06:04 CEST] <zevarito> sure, hold on a second
[17:08:34 CEST] <zevarito> warning: 'avcodec_decode_video2' is deprecated [-Wdeprecated-declarations] vs  error: 'int avcodec_decode_video2(AVCodecContext*, AVFrame*, int*, const AVPacket*)' is deprecated [-Werror=deprecated-declarations]
[17:08:47 CEST] <zevarito> first is osx, second ubuntu
[17:09:46 CEST] <zevarito> ffmpeg 3.4.2
[17:10:16 CEST] <zevarito> does make sense for Ubuntu since that function was removed, but why it compile in OSX is what doesnt make sense
[17:10:32 CEST] <furq> is that clang on osx
[17:10:38 CEST] <mort> zevarito: the Ubuntu version is apparently compiled with --Werror
[17:10:41 CEST] <mort> -Werror*
[17:10:50 CEST] <zevarito> hmmm you right
[17:11:01 CEST] <zevarito> it is clang
[17:11:20 CEST] <mort> that flag tells the compiler to interpret warnings as errors; I don't know if you're not giving Clang -Werror on macOS or if Clang ignores -Werror
[17:12:23 CEST] <zevarito> the flag is there so maybe you right and clang is ignoring it
[17:12:27 CEST] <furq> do you have a default CFLAGS in your env or something
[17:12:39 CEST] <furq> Werror definitely isn't enabled by default on linux
[17:13:13 CEST] <zevarito> nope
[17:13:15 CEST] <mort> zevarito: is this compiling your code which uses ffmpeg or are you compiling ffmpeg itself?
[17:13:28 CEST] <zevarito> mort: my code
[17:14:04 CEST] <zevarito> but Ive checked configure and compile of the library and it is the same for both platforms, however you guys give me a good hint to lookup for
[17:14:36 CEST] <mort> the solution is to either stop using deprecated functions, or remove -Werror from your makefile :)
[17:15:54 CEST] <zevarito> mort: hehe, well, I am working on remove depreacted functions, but wonder why that happen, also, Ive checked wrong, the flag isnt there :/
[17:16:18 CEST] <mort> could you pastebin your makefile?
[17:16:30 CEST] <zevarito> project uses cmake btw
[17:16:51 CEST] <mort> oh, the cmakelists.txt then
[17:17:31 CEST] <zevarito> sure, hold on
[17:19:14 CEST] <zevarito> mort: https://pastebin.com/hw4FWrwk
[17:21:14 CEST] <mort> run `env | grep error` and see if anything looks relevant
[17:21:56 CEST] <zevarito> nothing in both platforms
[17:22:48 CEST] <furq> you don't need to worry about your env if it's cmake
[17:22:52 CEST] <furq> cmake completely ignores that
[17:23:09 CEST] <furq> which for once is useful and not annoying
[17:23:30 CEST] <mort> I didn't know that, intresting
[17:24:17 CEST] <mort> zevarito: what file is it warning about?
[17:24:57 CEST] <mort> as in, which contains the deprecated function calls
[17:25:45 CEST] <zevarito> well, there are severals, I am migrating the project from the shi*** libav ;)
[17:26:57 CEST] <zevarito> perhaps shouldnt say that, apologies
[17:27:04 CEST] <furq> nah it's fine
[17:27:26 CEST] <furq> you can probably just add -Wno-deprecated-declarations to cmake
[17:27:47 CEST] <furq> it's more of a bandaid than a solution though
[17:28:21 CEST] <mort> it's possible that one of the included cmake files add -Werror
[17:28:47 CEST] <zevarito> furq: yep, I could try that
[17:28:51 CEST] <mort> I know Google stuff loves -Werror, which is really nice when you're using a different version of the compiler than what Google has standardized on and your compiler generated a warning they didn't anticipate
[17:28:57 CEST] <zevarito> mort: that happend for sure
[17:29:03 CEST] <zevarito> so it inherits the flag ?
[17:29:20 CEST] <mort> I don't know, I've used cmake very little
[17:29:49 CEST] <zevarito> maybe gcc and clang differ on that, one inherit the flag if a dep is using it and the other not
[17:29:50 CEST] <furq> fwiw you probably want to migrate to the new api anyway
[17:30:03 CEST] <furq> so you might as well just add -Wno-deprecated-declarations for now
[17:30:08 CEST] <furq> https://ffmpeg.org/doxygen/3.4/group__lavc__encdec.html
[17:30:10 CEST] <zevarito> furq: yup, I am on that, you mean av_send_frame etc ?
[17:30:13 CEST] <furq> yeah
[17:30:19 CEST] <zevarito> yup, I am on that
[17:30:36 CEST] <mort> but if "include" is the C-style include where it basically just copy/pastes one file into another, and cmake has a way to add a flag to a global cflag and webrtc is doing that, that would affect later stuff too
[17:31:12 CEST] <zevarito> mort: do you think it is cmake and not gcc ?
[17:31:32 CEST] <zevarito> if it is cmake should be consistent across platforms ?
[17:31:35 CEST] <mort> yes, GCC and Clang have no say in what they're called with, it's cmake that's deciding to add -Werror to your compiler on linux but not on macOS
[17:31:46 CEST] <zevarito> alright
[17:32:32 CEST] <mort> cmake itself isn't inconsistent across platforms I think, but I assume one can do different stuff for different platforms using it
[17:33:22 CEST] <zevarito> Ive checked that versions differ, osx cmake is 3.11.1 while ubuntu has 2.8.12.2
[17:33:27 CEST] <zevarito> perhaps that is the trick
[17:34:49 CEST] <mort> https://cmake.org/cmake/help/v3.0/command/include.html " and run CMake code from the file given. Variable reads and writes access the scope of the caller (dynamic scoping)." - It sounds like if webrtc's cmake file adds -Werror to CMAKE_CXX_FLAGS, that would affect your stuff too
[17:35:43 CEST] <zevarito> mort: yup that make sense
[19:00:34 CEST] <memo1> hi, now that ffserver is out, what options i have to set remote video server?
[19:00:51 CEST] <kepstin> what's your target player?
[19:22:34 CEST] <f-safinaskar> hi
[19:53:37 CEST] <FishPencil> Is there any crf value > 0 that would retain visual quality of the source though 1000s of reencodes?
[19:55:49 CEST] <kepstin> no, although you might be able to find a value that has acceptable quality for certain video sources and numbers of re-encodes.
[19:56:17 CEST] <kepstin> but really, you should be spending less time re-encoding videos :)
[19:58:08 CEST] <FishPencil> I'm looking to save some blu-rays, but it's going to really annoy me if the quality isn't the "same". Trying to decide what crf value to use
[19:58:28 CEST] <kepstin> use -c copy
[19:58:43 CEST] <kepstin> there's no reason to bother re-encoding at all if you have the space for it
[20:00:30 CEST] <FishPencil> Maybe I should just buy a couple TB HDD and put them all on there
[20:01:07 CEST] <FishPencil> Should be about 40 blu-rays for a 2TB drive
[20:01:18 CEST] <kepstin> if you're re-encoding, it's up to you to decide how much quality loss you're ok with, trading off vs. how big of file size you're ok with.
[20:01:58 CEST] <kepstin> a quality level high enough to have minimal effect over many re-encodes is probably not gonna give you much file size savings over simply copying the video as-is (although you'd really have to test this to be sure)
[20:02:01 CEST] <furq> remuxes usually aren't that much bigger than transparent encodes
[20:02:10 CEST] <FishPencil> I'm fine rencoding, but it needs to look and sound the same
[20:02:23 CEST] <furq> emphasis on remuxes because you will save a ton of space just by doing that
[20:02:42 CEST] <FishPencil> You mean -c copy furq?
[20:02:53 CEST] <furq> sure if you want to do it with ffmpeg
[20:03:06 CEST] <furq> m2ts is typically about 15% overhead
[20:03:10 CEST] <FishPencil> How do I save any space simply be remuxing it
[20:03:14 CEST] <furq> ^
[20:03:15 CEST] <kepstin> you might want to consider using blu-ray specific tools if you want to keep chapters and stuff
[20:03:17 CEST] <FishPencil> oh dang
[20:03:23 CEST] <furq> yeah use makemkv or something
[20:03:31 CEST] <furq> especially if you have actual discs and you need to break the encryption
[20:03:39 CEST] <FishPencil> already have that done
[20:03:54 CEST] <FishPencil> Just have a bunch of m2ts now
[20:03:56 CEST] <kepstin> but even if you don't, makemkv will, uh, make mkvs from your m2ts files
[20:05:00 CEST] <FishPencil> The playlist .mpls files really only have helpful chapter marks right?
[20:05:17 CEST] <FishPencil> There's not really anything else I'd want to retain?
[20:05:36 CEST] <furq> i think track metadata is stored outside the m2ts as well
[20:05:39 CEST] <furq> like language and such
[20:06:17 CEST] <furq> if you already have it decrypted then you can just use bdinfo
[20:06:26 CEST] <furq> that does the remuxing with ffmpeg
[20:07:48 CEST] <furq> https://github.com/schnusch/bdinfo
[20:10:31 CEST] <FishPencil> mkv has fairly low overhead right?
[20:14:32 CEST] <FishPencil> m2ts -> mkv was about 6.4% smaller
[20:24:33 CEST] <furq> mkv is about as low as anything else
[20:28:11 CEST] <kerio> mpegts is especially overheady
[20:29:50 CEST] <furq> 15% is probably on the high side tbh
[20:39:52 CEST] <FishPencil> So if I can expect a 5% savings my remuxing, that's two extra blurays for 2TB, or roughly 42 BD's. Pretty rough estimates though
[20:40:09 CEST] <FishPencil> s/my/by
[20:42:22 CEST] <FishPencil> Assuming a 2TB drive is roughly $60, that's like $1.4 per BD. Not bad considering the original prob cost $20+
[20:43:33 CEST] <FishPencil> All of that is to say I don't think I'll be reencoding them. The cost savings doesn't really make sense to me
[20:43:41 CEST] <furq> you can generally save a lot more by removing audio tracks you don't want
[20:44:19 CEST] <furq> or if it's dtshd/dtsma audio you can losslessly strip the extensions out
[20:45:02 CEST] <furq> -bsf:a dca_core if you're using ffmpeg
[20:45:10 CEST] <furq> i imagine there's some way to coerce bdinfo into using that
[20:46:29 CEST] <furq> you can also obviously just get rid of the features you don't want
[20:46:42 CEST] <FishPencil> I'll probably end up using mkvtoolnix along with a small program I wrote that uses libbluray to extract the chapter marks from the mpls.
[20:46:45 CEST] <furq> it's not uncommon to get a 50% reduction after doing all that
[20:48:18 CEST] <furq> if your playback chain doesn't support dtshd then it's a massive saving to get rid of it
[20:49:19 CEST] <kerio> can't you extract the lossless track and encode that with opus or something
[20:49:38 CEST] <furq> well he wants no degradation
[20:49:46 CEST] <kerio> flac
[20:49:49 CEST] <FishPencil> I use mpv so I assume it can do dtshd.
[20:49:59 CEST] <furq> flac would probably end up bigger
[20:50:11 CEST] <FishPencil> Do you know if all blurays also ship with a lossy option if they include dtshd
[20:50:42 CEST] <furq> yes
[20:50:46 CEST] <furq> that's how dtshd works
[20:51:06 CEST] <furq> it's a regular dca core stream and then the extensions on top
[20:51:14 CEST] <furq> so it'll degrade to core if your player doesn't support the extensions
[20:52:04 CEST] <zevarito> furq: mort: thanks for your help, Ive ended adding -Wall -Werror with add_definitions before add_directory to replicate ubuntu behavior in osx, couldnt find the exact cause of the problem and must go on.
[20:52:42 CEST] <FishPencil> does mpv support it? Is the quality actually any better? I'm not really an audio guy
[20:52:55 CEST] <furq> apparently it does
[20:53:04 CEST] <furq> you used to need libdcadec but that got folded into ffmpeg a while ago iirc
[20:53:17 CEST] <furq> as to the quality, it probably makes no difference
[20:59:31 CEST] <kerio> 64kbps/channel opus is perceptually lossless
[21:00:40 CEST] <FishPencil> If I go down the "perceptually lossless" trail I'm going to end up encoding the video too
[21:00:49 CEST] <kerio> but that takes time and effort
[21:01:06 CEST] <kerio> and introduces generation loss
[21:01:26 CEST] <kerio> just keep the audio i guess
[21:01:35 CEST] <kerio> it's not gonna mean much when you're keeping 40gb of video
[21:02:13 CEST] <kerio> hm where would one hypothetically obtain a bit-exact dump of a dvd or bluray?
[21:02:18 CEST] <kerio> like what should one search for
[21:02:19 CEST] <kerio> hypothetically
[21:02:51 CEST] <FishPencil> the hash?
[21:03:04 CEST] <kerio> no like
[21:03:12 CEST] <kerio> bdrip is a reencoding
[21:03:25 CEST] <FishPencil> oh
[21:03:42 CEST] <furq> kerio: dtshd goes up to like 25mbit
[21:03:47 CEST] <furq> so it's a significant saving if you drop it
[21:04:04 CEST] <kerio> i should get some radiohead in dtshd
[21:04:09 CEST] <kerio> 🤔
[21:04:10 CEST] <FishPencil> I wrote my own program that uses libaacs. It's an exact byte for byte decrypted dump.
[21:04:51 CEST] <FishPencil> libbluray also has some "example" tools that can do a similar thing
[21:07:10 CEST] <furq> i guess you could probably try converting dtshd to flac
[21:07:17 CEST] <furq> it won't be a huge saving though
[21:08:13 CEST] <furq> unless you downmix to stereo or something
[21:08:13 CEST] <FishPencil> furq: so for some of my blurays I only have AC-3
[21:08:19 CEST] <kepstin> if it's higher than 48kHz/16bit you could downsample it when saving it to flac, might help.
[21:08:30 CEST] <furq> that's another good point
[21:08:42 CEST] <furq> this is assuming you have any dtshd in the first place
[21:08:58 CEST] <FishPencil> I have "TrueHD" is another
[21:09:12 CEST] <FishPencil> s/is/in
[21:09:18 CEST] <furq> there's at least two different dts-hd codecs
[21:09:24 CEST] <furq> one of them is lossy and only 3-6mbps
[21:09:39 CEST] <furq> dts-hd high resolution is the lossy one, dts-hd master audio is the lossless one
[21:10:04 CEST] <furq> high resolution is just for 7.1 support iirc
[21:10:37 CEST] <FishPencil> ffprobe shows: Audio: truehd (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), s32 (24 bit)
[21:11:00 CEST] <furq> not sure why it's flagging that as ac3
[21:11:54 CEST] <furq> it's probably only worth converting dts-hd ma or truehd to flac if you're going to downmix and/or downsample it
[21:12:23 CEST] <furq> and also doing that will ruin any chance of spdif passthrough if that matters to you
[21:12:59 CEST] <furq> and then any other audio format is small enough that you might as well just keep it
[23:12:36 CEST] <zerodefect> Is it plausible to change the channel count in an AC3 stream on the fly? Secondly, does FFmpeg support it? Using the C-API for the record.
[23:20:49 CEST] <JEEB> zerodefect: the decoder at least can switch normally
[23:21:07 CEST] <JEEB> so if you feed it AC3 that is first 5.1, and then switches to stereo and vice versa, it will do that
[23:21:58 CEST] <zerodefect> Awesome thanks! On the encoder front, is it not supported or do you not know?
[23:24:27 CEST] <zerodefect> Searched using my favourite search engine (on the encoding front) and there were some posts that were quite old describing problems.
[23:24:34 CEST] <JEEB> no idea, would have to look at ac3enc's encode_frame
[23:24:35 CEST] <zerodefect> I need to brush up on using cmdline!
[23:24:56 CEST] <JEEB> I only know on the decoding front because broadcast can switch between stereo and 5.1 in the same track
[23:28:13 CEST] <zerodefect> Ah ok. I did a simple code search through the github mirror. Noticed that firstly there was a fixed/float version and I think quite a bit is written in assembler. Not search friendly
[23:28:34 CEST] <zerodefect> Of course, not blaming FFmpeg for that!
[23:29:19 CEST] <JEEB> libavcodec/ac3enc_template.c
[23:29:22 CEST] <JEEB> seems to be the relevant file
[23:29:52 CEST] <JEEB> found with `git -B2 grep AVFrame -- libavcodec/ac3*`
[23:30:06 CEST] <JEEB> since encoding a frame function takes an AVFrame
[23:30:54 CEST] <zerodefect> Ah, nice. Thanks.
[23:31:23 CEST] <JEEB> also that -B2 goes after the grep, copypasta fail
[23:31:39 CEST] <JEEB> (yes, I first failed and wrote it like that and got told that -B2 is not a valid git parameter)
[23:33:39 CEST] <zerodefect> :)
[23:35:34 CEST] <zerodefect> Is your line of work involved in broadcast @JEEB?
[23:35:50 CEST] <JEEB> more or less
[23:36:09 CEST] <JEEB> at least I deal plenty with various broadcast multiplexes :)
[23:37:40 CEST] <zerodefect> I've noticed your name in the libass channel too
[23:37:55 CEST] <JEEB> I poke a lot of stuff with my fingers :)
[23:38:45 CEST] <JEEB> (I am unfortunately not able to always give random stuff the amount of time I'd like to, though)
[23:39:27 CEST] <zerodefect> Yes, I know that feeling.
[23:44:37 CEST] <zerodefect> I think by mentioning multiplexer I could give a good guess the company you work for.
[00:00:00 CEST] --- Thu May 17 2018