[Ffmpeg-devel-irc] ffmpeg-devel.log.20180311
burek
burek021 at gmail.com
Mon Mar 12 03:05:04 EET 2018
[02:38:03 CET] <jamrial> wm4: you should have stated why you nack it
[02:38:23 CET] <jamrial> you know this way it will end up in nicolas pretending you didn't do it
[02:52:44 CET] <wm4> I can't find any info on what type or semanticsa AV_OPT_DURATION uses
[02:53:47 CET] <wm4> seems like av_parse_time is effectively it
[02:54:25 CET] <wm4> * - If a date the syntax is:
[02:54:25 CET] <wm4> * @code
[02:54:25 CET] <wm4> * [{YYYY-MM-DD|YYYYMMDD}[T|t| ]]{{HH:MM:SS[.m...]]]}|{HHMMSS[.m...]]]}}[Z]
[02:54:26 CET] <wm4> cute
[03:02:55 CET] <wm4> jamrial: done
[03:02:59 CET] <wm4> I hope that's enough
[03:03:05 CET] <wm4> ffmpeg dev sure is stressful
[03:03:10 CET] <wm4> all that shitty infighting
[03:03:45 CET] <jamrial> thanks
[10:50:40 CET] <gagandeep> kierank: i have edited the file cfhd.c, now i want to test the code so do i have to always compile the ffmpeg full source and install it?
[11:04:23 CET] <durandal_1707> gagandeep: just type make, if you built static ffmpeg, you do not need to install it
[11:14:21 CET] <gagandeep> durandal_1707:i had followed the compiling procedure given on ffmpeg.org and had changed prefix to install in a custom dir
[11:15:08 CET] <nevcairiel> you dont need to install to test, just make a static build and run it straight from the build directory
[11:16:34 CET] <gagandeep> yeah, after typing make it only made some changes to main file and i can see ffmpeg, ffplay executable in the source directory thanks
[11:36:50 CET] <durandal_1707> gonna apply drmeter, and you guys can't stop me!
[13:05:32 CET] <BtbN> What was the name of that interlacing method again, where either both fields are in one frame, or two seperate fields?
[13:06:06 CET] <BtbN> Was it MBAFF vs. seperate fields?
[13:26:04 CET] <jkqxz> BtbN: PAFF (or sometimes PicAFF).
[13:31:20 CET] <JEEB> yea, MBAFF was the coding mode with two fields in one picture, interleaved. and PAFF was the one where the fields are separate field pictures
[13:44:51 CET] <cone-366> ffmpeg 03Paul B Mahol 07master:8fb0e51bd198: avfilter: add drmeter audio filter
[13:50:29 CET] <nevcairiel> technically thats not entirely accurate, MBAFF is characterized by being able to switch interlaced on and off on a per-macroblock basis, ie. the MB in MBAFF, not just stuff being in one frame
[13:51:29 CET] <JEEB> right, yes
[13:51:46 CET] <nevcairiel> vc1 for example supports both "field" and "frame" interlacing, but that doesnt make it mbaff
[14:11:12 CET] <wm4> I still wonder how controlling it per MB even makes sense
[14:17:22 CET] <jkqxz> Regions without any horizontal movement cleanly encode as frames, regions with such movement are better separated because edges don't match vertically (encoding combs is hard).
[14:18:45 CET] <wm4> sure is a lot of effort for something as shitty
[14:18:59 CET] <JEEB> yes, they then removed that with HEVC
[14:19:09 CET] <JEEB> and told the interlacism vanguard to just encode fields separately
[14:51:09 CET] <nevcairiel> mbaff definitely helps efficiency by encoding progressive blocks where possible, but yeah interlacing is dying so no fancy features in hevc
[14:52:49 CET] <JEEB> yup
[14:53:15 CET] <JEEB> I actually was on jct-vc when the cable TV group was trying to push its own working group for looking into interlacism optimizations
[14:53:41 CET] Action: jdarnley wishes interlacing would die sooner
[14:54:11 CET] <JEEB> but thankfully jct-vc just went "the performance benefit is already there for interlaced content so we will just KISS it"
[14:54:25 CET] <JEEB> "and this working group was not OK'd by anyone so it doesn't exist"
[15:05:19 CET] <kierank> JEEB: ironically a reason hevc is failing though
[15:06:26 CET] <JEEB> well it can still code the darn thing, and it should still be better off than AVC. and otherwise I'd look at the licensing mess as a bigger reason for things failing apart. unless I'm missing some angle here.
[15:08:52 CET] <kierank> it isn't better than avc
[15:08:54 CET] <kierank> that's the problem
[15:09:03 CET] <kierank> at best barely better
[15:09:49 CET] <nevcairiel> it took like a decade before mpeg2 was being replaced by avc in broadcast, its not like such things happen over night
[15:12:59 CET] <atomnuker> it still hasn't been fully replaced lol
[15:13:01 CET] <nevcairiel> you're facing off a lot more years of development in an existing codec against something brand new, afterall
[15:13:12 CET] <atomnuker> 80 megabit mpeg2 for 1080i25
[15:15:24 CET] <wm4> isn't mpeg2 patent free now
[15:15:55 CET] <nevcairiel> no
[15:16:50 CET] <JEEB> kierank: ok so the encoders aren't there yet. got it :) . that's something I 100% agree even with non-interlacism
[15:16:54 CET] <nevcairiel> technically there is one patent that doesnt expire until 2026, but some people question if thats enforceable since its way too new for something as old as mpeg2, and the last others expire sometime this year
[15:17:20 CET] <kierank> h.264 is like jpeg
[15:17:22 CET] <kierank> it's good enough
[15:17:50 CET] <nevcairiel> if you go 4k you quickly run into an area where hevc actually becomes better
[15:18:02 CET] <kierank> sure but 4k will die like 3d
[15:18:09 CET] <nevcairiel> doubtful
[15:18:10 CET] <JEEB> kierank: yea, you gained CABAC and a lot of good stuff with AVC
[15:18:21 CET] <nevcairiel> 4k is just a natural evoluion, bigger and better
[15:18:27 CET] <nevcairiel> its not a tacked on gimmick
[15:18:38 CET] <kierank> it took 40 years to move from sd to hd
[15:18:41 CET] <JEEB> while HEVC adds a lot of cool tools, but it's not easy to optimize that for visual perception
[15:18:45 CET] <kierank> 4k isn't going to happen in 10 years
[15:18:52 CET] <JEEB> and it doesn't have similar "omg nice" tools
[15:19:01 CET] <JEEB> compared to the previous format
[15:21:35 CET] <nevcairiel> 3d was always more of a gimmick, and especially at home it imho never really worked that well, but higher resolution is just a natural evolution, and you wont see anyone saying "oh we realized it sucks, we're just going back to giving you worse video again"
[15:22:05 CET] <JEEB> yes, and they still need 8K to hide teh compression artifacts of 4K
[15:22:17 CET] <JEEB> (from the mouth of a guy from EBU talking at NHK R&D last year)
[15:23:24 CET] <nevcairiel> the good thing about higher res is that you can just encode stuff "softer" and the high dpi of the screens will fake sharpness for you, so hevcs blur in favor of blocking works well with that
[15:24:04 CET] <kierank> you need to sit 1m away from the screen to see the difference between hd and 4k
[15:24:06 CET] <kierank> which nobody does
[15:24:14 CET] <nevcairiel> thats a myth anyway
[15:24:26 CET] <kierank> lol ok
[15:24:56 CET] <nevcairiel> you can resolve far smaller details with your eyes from usual seating distances
[15:29:30 CET] <atomnuker> 4k is already pretty much happening on the internet
[15:29:52 CET] <wm4> sounds like bullshit
[15:30:11 CET] <wm4> maybe if you directly plug in your windows DRM laptop into netflix' data center lol
[15:30:29 CET] <nevcairiel> 4k streaming netflix isnt that hard
[15:30:35 CET] <wm4> most people have shitty internet speed
[15:30:48 CET] <JEEB> sure, there's the bw limitations
[15:30:56 CET] <JEEB> but that was the case with HD video as well for a long time
[15:31:09 CET] <JEEB> and for example india is still on SD for wireless internet streaming
[15:31:19 CET] <JEEB> and there's stream dumps being offered on disks
[15:31:41 CET] <nevcairiel> netflix requires 25mbit for 4k hdr streaming, thats not that out of this world anymore in western countries
[15:31:57 CET] <JEEB> but I think at least on mobile platforms netflix does let you download versions? although I don't know what resolutions they restrict that to
[15:32:12 CET] <nevcairiel> (and some of those new TVs have that ability straight built in, no laptop required)
[15:32:32 CET] <JEEB> yes
[15:32:44 CET] <JEEB> my TV can receive netflix and amazon UHD
[15:32:47 CET] <wm4> TVs are probably more likely to fulfill insane DRM requirements of course
[15:32:51 CET] <JEEB> yes
[15:32:59 CET] <nevcairiel> there is also a bunch of STBs that can do it
[16:50:47 CET] <atomnuker> wm4: 4k streaming in official stuff? lol no, talking about the scene and youtube
[16:51:33 CET] <atomnuker> there are plenty of 4k bluray rips, most either with HDR or mistagged HDR as bt709 (or awful tone mapping, but that's rare)
[16:52:25 CET] <JEEB> well nowadays since even I can decrypt all of my UHD BDs
[16:52:29 CET] <JEEB> you can easily get the source streams
[17:12:04 CET] <klaxa> oh? maybe i should ask for that laptop with the bd drive back and try ripping my BDs again
[17:17:48 CET] <JEEB> BDs have been decryptable for a while, for UHD BDs you need one of those drives that lets you read them without requiring AACS v2
[17:18:04 CET] <JEEB> there's a list of them if you google for "uhd friendly"
[17:33:22 CET] <nevcairiel> yeah that works quite well
[17:33:31 CET] <nevcairiel> i only have like one disc i bought for testing, but it works
[18:05:56 CET] <atomnuker> you can rip them but I think decryption is quite recent, like no more than 6 months
[18:06:30 CET] <atomnuker> and still not all discs, there's a small list of around 70 discs (I think) which have had their keys busted
[18:08:25 CET] <nevcairiel> there is almost 900 discs listed in this key file, but of course many are the same movie in different releases
[18:10:28 CET] <nevcairiel> there is a good chance that any disc you buy is supported, or if you submit its metadata, that it will be
[18:25:55 CET] <atomnuker> cool, things have improved
[18:26:30 CET] <nevcairiel> still need one of those special drives though
[18:26:36 CET] <nevcairiel> wonder if they'll manage to defeat that eventually
[18:27:00 CET] <nevcairiel> (incidentally, the one I had was one of those)
[18:28:31 CET] <kurosu> btw, is Netflix UHD/4K always also HDR? Then, do they also serve 1080p HDR?
[18:28:36 CET] <kurosu> (and hi)
[18:30:07 CET] <nevcairiel> No, and no
[18:31:28 CET] <kurosu> ok, so not always 10 bits, but I guess it simpler to always enforce that restriction as some/most users would not be pleased to only be able to access "some" 4K content
[18:33:35 CET] <kurosu> restriction = h/w support which seems to equate Main10 hevc profile
[18:35:18 CET] <nevcairiel> They actually also have PQ HDR VP9 streams for mobile
[18:36:21 CET] <kurosu> yeah, I think we now someone who knows more about it
[18:37:00 CET] <kurosu> I thought it was restricted to mobile download though, but I didn't know it was also HDR, as this again narrows down the support
[18:39:26 CET] <kurosu> nevcairiel, you know surely better that, so can you confirm that Intel started supporting both main10 hevc and profile 2 (I think) vp9 at the same time? But nvidia first offered only main10, and then introduced 10bits vp9?
[18:40:37 CET] <kurosu> and no vp9 support with amd - hoping they'll fix that at some point
[18:40:46 CET] <atomnuker> they did 10bit hevc and vp9 all profiles at the same time
[18:40:55 CET] <atomnuker> kabylake
[18:41:07 CET] <jkqxz> No, Apollo Lake has 10-bit H.265 but only 8-bit VP9.
[18:41:23 CET] <kurosu> yeah, don't know what all the vp9 profiles represent. Some may be for 4:4:4
[18:41:32 CET] <atomnuker> well, skylake then is the last without those since it only supports vp8 and 8bit hevc
[18:41:47 CET] <kurosu> jkqxz, thanks, interesting to know when shopping for a potential HC system
[18:42:47 CET] <jkqxz> Apollo Lake also doesn't have any 10-bit encode. It's just the decode which is there.
[18:43:44 CET] <kurosu> I have a tablet with a MediaTek chip in it which seems to support "main8" and vp9, but not 10 bits for vp9&hevc, and starts to freeze above 1080p30 (eg 1080p60, while 720p60 is fine)
[18:44:00 CET] <kurosu> also it has a significant effect on drain (both hevc and vp9)
[18:48:08 CET] <jkqxz> Could be software? wbs did a lot of work on ffvp9 for ARM, it's entirely usable on ok devices.
[18:50:29 CET] <kurosu> yeah, I suspected it, even if it was advertised as h/w, due to the drain
[18:50:53 CET] <kurosu> but it is not *that* significant, so weak h/w was not out of the picture
[18:51:24 CET] <kurosu> note: never even fired up some logcat or anything to confirm what was the omx (?) decoder in use
[18:54:02 CET] <kurosu> also the freeze impacted the whole system (eg enable to play any video afterwards), which looks like a h/w device crashing
[18:54:14 CET] <kurosu> s/enable/unable
[19:31:39 CET] <jamrial> jkqxz: check the trace_headers patch i sent a few minutes ago if you can
[19:32:42 CET] <jamrial> jkqxz: ah, way ahead of me i guess :p
[19:47:41 CET] <cone-793> ffmpeg 03James Almer 07master:27d4249fadba: avcodec/chomp: move the reference in the bsf internal buffer
[19:47:41 CET] <cone-793> ffmpeg 03James Almer 07master:aba437a6d0a7: avcodec/dca_core: move the reference in the bsf internal buffer
[19:47:41 CET] <cone-793> ffmpeg 03James Almer 07master:9c6dd9d62488: avcodec/extract_extradata: move the reference in the bsf internal buffer
[19:47:41 CET] <cone-793> ffmpeg 03James Almer 07master:11bef2fe7232: avcodec/mov2textsub: move the reference in the bsf internal buffer
[19:47:41 CET] <cone-793> ffmpeg 03James Almer 07master:a1a0859ad52e: avcodec/remove_extradata: move the reference in the bsf internal buffer
[19:47:42 CET] <cone-793> ffmpeg 03James Almer 07master:c266049191e5: avcodec/trace_headers: move the reference in the bsf internal buffer
[19:59:09 CET] Action: JEEB loves getting patches like this linked https://github.com/jeeb/ffmpeg/commit/dfbf657f93cd8e641a3ad6138139b6f251892db5
[19:59:21 CET] <JEEB> I mean, a sample I happen to have on-hand seems to get fixed with this
[19:59:25 CET] <JEEB> but I have no means of reviewing it
[19:59:40 CET] <JEEB> other than "it seems to fix wrap-around handling when new streams get added to a program"
[20:15:30 CET] <JEEB> https://kuroko.fushizen.eu/videos/pid_switch_sample.ts
[20:15:35 CET] <JEEB> seems to be one of the samples that patch seems to fix
[20:19:19 CET] <JEEB> with this patch you get a pretty upwards chart
[20:19:26 CET] <JEEB> without it you get a nice drop
[23:44:22 CET] <tmm1> atomnuker: i'm seeing build failures on freebsd https://paste.ubuntu.com/p/rBTn82qRfM/
[23:55:08 CET] <atomnuker> k, I'll send a patch once it finishes building
[00:00:00 CET] --- Mon Mar 12 2018
More information about the Ffmpeg-devel-irc
mailing list