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

[burek]

[13:12:49 CET] <skident> Hi everyone, is it possible to use a filter loudnorm linear without adding measured_* options?
[14:02:10 CET] <dfcnvt> Hi guys -- Can you tell me which of those compression and/or format is the lightest size or has the fastest rate of Camera Output as shown in this limited list:  https://i.imgur.com/sODQ3GZ.png
[14:03:22 CET] <pink_mist> afaik only H264 has even a chance of doing compression
[14:03:36 CET] <pink_mist> the others I don't believe do any compression at all
[14:07:41 CET] <pink_mist> I'm a complete noob at tht stuff though, so I may be completely wrong
[14:07:44 CET] <pink_mist> *that
[14:10:44 CET] <dfcnvt> pink_mist: Thanks -- I kinda thought so.  I think it's the format.  I guess I need to do the research by finding the size of the file and compare them (benchmark).
[14:15:03 CET] <dfcnvt> Seem there's 3 different "TYPE"s:   http://wiki.oz9aec.net/index.php/Pixel_formats
[14:15:16 CET] <dfcnvt> packed, compressed, planar
[14:32:42 CET] <iive> pink_mist, you are correct
[14:36:52 CET] <iive> the pixel formats does take different space. e.g. rgb and bgr are using 3 bytes per pixel. aka 24 bits per pixel. YUYV 4:2:2 are using 16 bits per pixel, (8*4+8*2+8*2)/4; YV12 is YUV420 and uses 12 bits per pixel.
[15:06:47 CET] <dfcnvt> iive: Thanks, I assume YUV12 would be the best to use -- with the interest of lightweight load and speed.
[15:07:15 CET] <dfcnvt> Whoops, I meant YV12
[15:07:25 CET] <dfcnvt> U & V looks the same.
[15:08:07 CET] <skident> Guys, is there somebody who built ffmpeg for Windows using MSVC2017 (release and debug versions)?
[15:09:01 CET] <iive> dfcnvt, have you tried h264, it has lossless mode.it might be using it. record a sample and check it with ffprobe.
[15:09:36 CET] <iive> otherwise yes, if the camera is not using interlace, use yv12, if it does yuyv 422 .
[15:09:54 CET] <iive> interlace should have died with crt tv.
[15:10:50 CET] <dfcnvt> Forgive me but I'm not quite catch up on the understanding of what's the "interlace" is.
[15:11:38 CET] <iive> well, i guess you've seen 720p and 1080p, there is 720i and 1080i.
[15:11:56 CET] <dfcnvt> nevermind, I checked the example of interlace -- http://www.infognition.com/tutorials/rip_guides/ntscfilmi.gif
[15:12:08 CET] <iive> interlace is when you separate the picture in odd and even lines and you combine fields from different time.
[15:12:39 CET] <iive> it kind of creates a comb effect on motion.
[15:12:52 CET] <dfcnvt> Gotcha, like in the example.
[15:14:19 CET] <dfcnvt> skident: I'm guessing you'd want to check the "Previous Builds" section here -- https://ffmpeg.zeranoe.com/builds/
[15:15:07 CET] <dfcnvt> Note, I'm just browsing out for you -- I have no knowledge whether this is reliable nor does it meet to your asking.
[15:15:41 CET] <iive> the example looks like telecine. it is when you want to increase fps, but instead of repeating frames, you repeat fields. this way you turn nice and progressive video into mixed mess of progressive and interlaced frames.
[15:15:46 CET] <skident> dfcnvt: no, I want to build ffmpeg libraries from sources on Windows and for Windows
[15:18:05 CET] <skident> I tried to follow instructions (http://ffmpeg.org/platform.html#Microsoft-Visual-C_002b_002b-or-Intel-C_002b_002b-Compiler-for-Windows) but unfortunately I faced with problems like msys2 doesn't know where is cl.exe located
[15:21:32 CET] <skident> or for example here is another manual https://trac.ffmpeg.org/wiki/CompilationGuide/WinRT, but it is only for Visual Studio 2015
[15:31:27 CET] <dfcnvt> skident: I see, this is out of my depth.
[18:32:21 CET] <devinheitmueller> Anyone interested in doing some consulting to address some bugs in libavcodecs HEVC decoder?
[18:32:31 CET] <jya> how can I get ffplay to properly downmix a video with a 5.1 audio when playing on stereo?
[18:32:36 CET] <jya> right now it just drops the channel
[18:34:13 CET] <JEEB> devinheitmueller: is this about making it output both fields into a single AVFrame?
[18:34:17 CET] <devinheitmueller> jya: I cannot speak to ffplay, but at least with ffmpeg it will downmix to stereo if you specify -ac 2
[18:34:22 CET] <devinheitmueller> JEEB: Wow, thats exactly the issue.
[18:34:38 CET] <jya> devinheitmueller: indeed, just tested that.
[18:34:46 CET] <jya> so just converted with ffmpeg first
[18:34:47 CET] <devinheitmueller> Ive got streams from a couple of different sources which exercise modes 1/2 and 9/10/11/12.
[18:35:02 CET] <devinheitmueller> Pardon, I mean pic_struct 1/2 and 9/10/11/12.
[18:35:59 CET] <JEEB> I've been thinking of taking a look at it since like none of the overall stuff actually handles separated fields automagically
[18:36:10 CET] <devinheitmueller> I cooked up a quick video filter to merge the two fields into a single AVFrame for certain known broadcast resolutions (i.e. 1920x540, 720x240, etc), but thats obviously a hack and it really should be fixed in the decoder itself.
[18:36:13 CET] <JEEB> buut, priorities are somewhere else
[18:36:35 CET] <JEEB> (and I don't deal in interlaced HEVC too much yet)
[18:37:04 CET] <devinheitmueller> My initial hope was that the code was close enough to the H.264 decoder that I could port the business logic.  Then I started looking at the actual code.  :-)
[18:37:12 CET] <JEEB> yea :D
[18:37:21 CET] <JEEB> thaat was my first guess/hope as well
[18:38:36 CET] <JEEB> also I wonder how much my next MPEG-TS patch will raise eyebrows. :P (drop non-trustable [read: subtitles/teletext] packets if PCR hasn't been received yet)
[18:38:59 CET] <devinheitmueller> Of course at least in my case Im hindered by my general lack of knowledge in how the standard operates (e.g. I had to look up what CTB stood for)
[18:39:28 CET] <devinheitmueller> Oh, Ive got a fun MPEG TS patch in the works as well, to properly handle streams > 26.5 hours.
[18:39:49 CET] <JEEB> there's actually lavf logic for that, but somehow that logic only triggers *once*
[18:40:13 CET] <JEEB> but IIRC people were OK with an option that does that within the demuxer
[18:40:38 CET] <devinheitmueller> Yeah, aside from the general improper handling of wraparound, in the cases where I do see it attempting it, it works exactly once.
[18:40:48 CET] <JEEB> yup
[18:41:08 CET] <devinheitmueller> I assume youre referring to the stuff in libavformat/utils.c.
[18:41:10 CET] <JEEB> you get it once from lavf (expected) and then ffmpeg.c's discontinuity logic catches it
[18:41:13 CET] <JEEB> yup
[18:41:24 CET] <JEEB> and the ffmpeg.c code in theory should be dead weight by now :P
[18:41:34 CET] <JEEB> yet it isn't, which is unexpected/boog in the lavf handling
[18:41:53 CET] <JEEB> I also have a patch from Japan for the wrap-around handling which I still don't understand myself 100%
[18:42:03 CET] <JEEB> but it seems to help with at least one sample I have
[18:42:13 CET] <devinheitmueller> Also bear in mind that the clock gets re-based in ffmpeg.c.  Hence even if you do wrapping at (1<<33) at the TS level, you still have to deal with the rebased clock wrapping around.
[18:42:34 CET] <JEEB> yes
[18:42:36 CET] <devinheitmueller> Hmm, if youve got a patch, send it along and I can compare it to what Ive done.
[18:43:21 CET] <JEEB> https://github.com/jeeb/ffmpeg/commit/dfeeeb226094a8b00f7319b89e4d3b3660326d35
[18:43:36 CET] <JEEB> I don't fully habla it so I haven't posted it on the ML yet
[18:44:14 CET] <JEEB> and that came to me without any comments etc :P
[18:44:25 CET] <JEEB> https://kuroko.fushizen.eu/screenshots/ffmpeg/blue_vanilla-orange_patched.png
[18:44:33 CET] <JEEB> this is the result with one of my samples
[18:44:52 CET] <JEEB> so it clearly fixes *something*
[18:46:17 CET] <JEEB> also I think durandal_1707 was looking for things to do, so you might want to poke him on #ffmpeg-devel regarding the HEVC thing
[18:46:21 CET] <devinheitmueller> I dont think that would work for streams that have B-frames.
[18:47:18 CET] <devinheitmueller> Doh, I didnt even realize there was an #ffmpeg-devel channel.
[00:00:00 CET] --- Thu Nov 29 2018