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

[burek]

[10:20:42 CET] <JEEB> yay, first version of my thing done
[10:25:10 CET] <jya> the upgrade from ffvpx from 3.4 to 4.0.2 has introduced a playback regression which can easily be seen when watching https://www.youtube.com/watch?v=lG5LZNhfyGM 
[10:26:14 CET] <jya> that's the diff https://hg.mozilla.org/mozilla-central/rev/29daa22239e9 of the full change and the windows configuration: https://hg.mozilla.org/mozilla-central/diff/29daa22239e9/media/ffvpx/config_win64.h
[10:26:22 CET] <jya> is there anything obvious in there?
[10:26:41 CET] <jya> the drops of frames doesn't appear to be performance related
[10:27:06 CET] <jya> i have a very fast machine, the CPU barely go over 10% oplaying that content at 1080p60
[10:28:41 CET] <nevcairiel> why does your config have all asm disabled, that'll make a crawling slow decoder
[10:28:50 CET] <jya> may have to wait until BBB is back online
[10:29:25 CET] <jya> nevcairiel: which bit?
[10:29:40 CET] <nevcairiel> its not like this is a change in the config
[10:29:43 CET] <nevcairiel> but still
[10:30:31 CET] <nevcairiel> oh wait i looked at the wrong config, i lost my sc roll position in the diff
[10:47:06 CET] <cone-844> ffmpeg 03Paul B Mahol 07master:f2179afb01a3: avformat/nutdec: fix obvious typo
[10:47:59 CET] <jya> nevcairiel: the only thing of significance was the removal of the superframe parser, replaced by a bsf.
[10:48:21 CET] <jya> Maybe we didn't do that change properly 
[10:50:22 CET] <JEEB> something like this http://up-cat.net/p/cb86ba34
[10:51:27 CET] <JEEB> although I might as well make the first one "subtitles"
[10:51:31 CET] <JEEB> since that's what it is
[11:17:27 CET] <JEEB> lol
[11:18:04 CET] <JEEB> for some reason if I skip the first subtitle packet ffprobe's show_programs drops the resolution
[11:18:16 CET] <JEEB> but it only drops a single packet so at least that seems to work \o/
[11:20:31 CET] <JEEB> http://up-cat.net/p/b33395bf
[11:21:14 CET] <JEEB> that fixes start_time etc as well, since we lose the outlier
[11:29:20 CET] <cone-844> ffmpeg 03Paul B Mahol 07master:6f058b5cef67: avformat/nut: add support for yuva444/422p12 pixel format
[11:36:29 CET] <cone-844> ffmpeg 03Paul B Mahol 07master:e9817636a7e1: avformat/flac_picture: try to guess PNG by actual picture data
[11:36:30 CET] <cone-844> ffmpeg 03Paul B Mahol 07master:5e6b93bb4dc4: avformat/id3v2: use png header to get PNG signature
[12:05:55 CET] <thardin> doesn't anyone happen to have SMPTE 429-5 on hand?
[12:06:05 CET] <thardin> michaelni?
[12:10:56 CET] <thardin> oh boy, mxfsplit segfaults on that DCP MXF subtitle file
[12:12:21 CET] <durandal_1707> and ffmpeg?
[12:13:54 CET] <thardin> mxfdec can't make sense of it, but it doesn't crash at least
[12:14:06 CET] <thardin> hah wikileaks has the SMPTE specs
[12:14:24 CET] <cone-844> ffmpeg 03Paul B Mahol 07master:d9a91d58a17f: avformat/movenc: treat ALAC same as FLAC and write correct info
[12:30:58 CET] <durandal_1707> atomnuker: does aac supports single FL/FR ... channel layouts?
[12:32:43 CET] <atomnuker> as in dual mono?
[12:32:55 CET] <atomnuker> or as in a non-center mono
[12:33:37 CET] <atomnuker> nope, not even with PCEs
[12:42:48 CET] <JEEB> umm
[12:43:01 CET] <JEEB> dual mono *is* a thing and you can find the AVOption for the .jp mapping of it
[12:43:08 CET] <JEEB> seems to be disabled by default
[12:43:27 CET] <JEEB> thardin: yes, it also has the DCF or so specs, which was funny (and one of the newer versions of qtff.pdf)
[12:48:01 CET] <atomnuker> JEEB: yeah, but doesn't have direct support for it
[12:48:47 CET] <JEEB> right
[12:58:53 CET] <cone-844> ffmpeg 03Paul B Mahol 07master:ddefd05507fd: doc/metadata: fix error in timebase description
[13:22:26 CET] <thardin> JEEB: neat
[13:27:34 CET] <JEEB> the sony dump had various random stuff :D
[13:38:32 CET] <Compn> new or old dumb
[13:38:33 CET] <Compn> dump
[13:44:06 CET] <JEEB> at this point it's been a few years
[14:03:26 CET] <kierank> av500: did you message me yesterday
[14:03:41 CET] <kierank> On some MMS to email gateway
[14:03:57 CET] <kierank> Number was from Germany
[14:07:06 CET] <durandal_1707> is there any way to drop trailing metadata like ape tags from lavf utils.c?
[14:22:27 CET] <cone-844> ffmpeg 03Fan Gang 07master:c6e1966c1a1a: avcodec/ass_split: fix a memory leak defect when realloc fails
[17:40:16 CET] <cone-232> ffmpeg 03Paul B Mahol 07master:78e7b70395e9: avformat/ffmetadec: do no limit size of tags to 1024
[18:37:37 CET] <durandal_1707> michaelni: does libnut have relevant EOR code?
[18:52:19 CET] <michaelni> durandal_1707, i suspect it does not
[18:54:22 CET] <durandal_1707> michaelni: nut demuxer nowhere checks for FLAG_EOR, so this is never implemented
[19:10:26 CET] <cone-232> ffmpeg 03Andriy Gelman 07master:5282db5929f2: avcodec/mpeg: Initialize quarter_sample parameter from previous thread.
[19:10:27 CET] <cone-232> ffmpeg 03Lauri Kasanen 07master:b4c8c03b0040: swscale/output: VSX-optimize 16-bit yuv2plane1
[19:43:14 CET] <durandal_1707> michaelni: why nut_write_trailer have assert1 for option which is set by user?
[19:56:53 CET] <durandal_1707> michaelni: so EOR frames have zero data_size or actual size of frame header?
[20:12:21 CET] <durandal_1707> michaelni: also for long 10h nut sample auto generated ffmpeg spits bunch of pts errors after 9:25 when demuxing
[20:12:53 CET] <durandal_1707> michaelni: also 
[20:12:58 CET] <durandal_1707>     Last message repeated 957 times
[20:13:21 CET] <durandal_1707> [nut @ 0x246ae40] frame size > 2max_distance and no checksum
[20:29:48 CET] <michaelni> durandal_1707, the assert should only be reached if its assumtion (about the user option) is true
[20:29:57 CET] <michaelni> ill document this better
[20:31:54 CET] <michaelni> EOR size refers to size of packet IIRC
[20:33:09 CET] <michaelni> about nut bugs, feel free to add me to the CC of the tickets if you like, so i dont forget
[20:58:35 CET] <BradleyS> 5282db5929f25ca9566a47ad217794842b364afc can be cherry-picked onto release/4.1
[21:22:37 CET] <durandal_1707> michaelni: somehow pts get fcked up
[21:47:15 CET] <durandal_1707> michaelni: found bug and fixed it!
[21:54:48 CET] <cone-232> ffmpeg 03Paul B Mahol 07master:6bfc935232fb: avformat/nutdec: fix pts overflow
[22:32:30 CET] <jya> nevcairiel: i think I see why in the logs "The deprecated avcodec_decode_* API cannot return all the frames for this decoder. Some frames will be dropped. Update your code to the new decoding API to fix this."
[22:32:55 CET] <nevcairiel> ah yeah thats because of the b sf
[22:33:59 CET] <jya> is there an easy way to get the old API to work, or must we rework it all?
[22:37:19 CET] <jya> that sucks big time 
[22:49:43 CET] <nevcairiel> jya: probably cant do that with the old api. could do something quick and dirty and call the bsf before the decoder, but thats also code changes, so might as well do it properly.
[22:50:20 CET] <jya> nevcairiel: the plan would be to have something small and safe enough to uplift to release
[22:50:28 CET] <jya> right now that seems to drop over 10% of the frames
[22:50:41 CET] <jya> with that particular 1080p60 from YT
[22:50:44 CET] <nevcairiel> it depends how many superframes there are, but yeah
[22:51:29 CET] <jya> it's really sad that the old API wasn't fully removed then, what's the point of keeping something that no longer work :(
[22:52:23 CET] <nevcairiel> changing to the new api is really not that hard and depending on how your code was structured may not  even require much work at all
[22:54:29 CET] <jya> it's just a matter of sending a frame / receiving it?
[22:54:43 CET] <jya> got a link to an example handy, or some doc?
[22:54:58 CET] <nevcairiel> yeah its basically just split, send a packet in, and receive frames
[22:55:06 CET] <nevcairiel> in this case send a superframe, and receive more then one frame
[22:57:55 CET] <nevcairiel> trying to find an example or doc that seems adequate
[23:00:28 CET] <nevcairiel> but the jist of it is really quite simple, i nstead of decode_video2, you  just call send(pkt); and then loop over receive(frame) until you get EAGAIN or EOF
[23:01:22 CET] <jya> nevcairiel: this is what we used to do with the decode bit, at least for audio
[23:01:28 CET] <jya> why not keep that ?
[23:02:54 CET] <nevcairiel> mostly because it was undocumented to do that with video, and the old api was terrible for that (having to manually adjust the avpacket etc), and we needed an e ntirely new one for encoding anyway, because m:n input/output was not supported there at all
[23:03:08 CET] <nevcairiel> the new api also theoretically supports full async decoding, or more advanced threading
[23:03:10 CET] <nevcairiel> if thats ever used
[23:04:06 CET] <jya> nevcairiel: from which version of libavcodec is the new API supported?
[23:05:03 CET] <nevcairiel> 3.1 apparently
[23:05:20 CET] <nevcairiel> ie 2.5 years now
[23:08:33 CET] <jya> what's the libavcodec version for those ?
[23:09:03 CET] <nevcairiel> 58
[23:09:33 CET] <nevcairiel> wait, thats wrong
[23:09:38 CET] <jya> hmm 57 apparently (just checkout release/3.1
[23:09:45 CET] <nevcairiel> yeah  57
[23:09:50 CET] <nevcairiel> but not all 57s have it
[23:09:57 CET] <jya> ohhh ffs
[23:10:07 CET] <nevcairiel> it was added here:
[23:10:07 CET] <nevcairiel> 2016-04-21 - 7fc329e - lavc 57.37.100 
[23:10:39 CET] <jya> wm4 I'm not surprised :)
[23:11:34 CET] <jya> no codecs supporting that API
[23:11:38 CET] <jya> the log states
[23:11:43 CET] <jya> they all do now?
[23:11:50 CET] <nevcairiel> thats a bit misleading
[23:11:57 CET] <nevcairiel> the api works with all  codecs that use the old internal api
[23:12:06 CET] <nevcairiel> but at that time no codec used the new internal api
[23:12:15 CET] <jya> ah ok, so just no codec natively supporting it
[23:12:39 CET] <jya> i still think the old API should be made to work, or not be there at all
[23:12:49 CET] <nevcairiel> its impossible to make it work
[23:12:57 CET] <nevcairiel> without changing its semantics
[23:13:11 CET] <nevcairiel> which would still result in you having to change your code
[23:13:14 CET] <nevcairiel> so that would be pointless
[23:14:02 CET] <nevcairiel> not sure when the old api was officially deprecated and when its slated for removal
[23:15:04 CET] <nevcairiel> oh in the same commit even
[23:15:08 CET] <jya> may as well be removed seeing that it no longer works
[23:15:14 CET] <nevcairiel> so they'll probably be removed in  59 then
[23:24:30 CET] <BtbN> When did the old API stop working? It just doesn't support multiple output frames per input
[23:24:58 CET] <jya> nevcairiel: there's no need to use an AVParser with the new API I gather
[23:25:06 CET] <nevcairiel> not for vp9
[23:25:19 CET] <jamrial> i don't think it's been scheduled for removal yet. there are no guards or anything for it
[23:25:21 CET] <jya> BtbN: well, more like the parser+old_api no longet work
[23:25:25 CET] <nevcairiel> with other codecs your experience may vary
[23:25:41 CET] <nevcairiel> depending on what your demuxer outputs etc
[23:25:50 CET] <nevcairiel> generally ffmpegs parsers job is considered a demuxers job
[23:25:54 CET] <nevcairiel> vp9 was .. special
[23:25:57 CET] <nevcairiel> which is why it was changed
[23:26:26 CET] <jamrial> vp9 parser was doing packet splitting, which was a bad idea as this resulted in split packets making it to muxers
[23:26:43 CET] <jya> well, we went with the idea that a demuxer demux a container, and a decoder decode the bytestream
[23:26:47 CET] <jamrial> so the parser was changed to simply mark keyframes, and a bsf was added to handle the splitting internally within the decoder
[23:26:51 CET] <nevcairiel> jamrial: well it was  deprecated in 2016, so guards or not, users have been warned long enough that there  is no blocker to doing it
[23:26:54 CET] <jya> so the demuxer shouldn;'t know about what it's demuxing
[23:27:54 CET] <nevcairiel> jya: thats all fine for competent containers like mp4 and mkv, but what do you do if there are no clear frame boundaries and someone has to figure out where frames start and end? thats practically what ffmpeg parsers do, generally as part of avformat, ie. demuxing.
[23:28:18 CET] <jya> that's fine we only support mp4 and webm :D
[23:28:22 CET] <jya> (and ogg)
[23:28:53 CET] <jamrial> yeah, most parsers were written to assemble full frames out of raw bitstreams. the vp9 parser however was being unique and splitting frames instead :p
[23:29:47 CET] <jya> right, so < 58, use parser and old API, >= 58 don't use parser and new API
[23:30:07 CET] <jya> what about vp8, need the parser too ?
[23:30:15 CET] <jya> (more an issue with Libav IIRC)
[23:30:20 CET] <jamrial> vp8 parser just marks keyframes
[23:30:24 CET] <jamrial> so probably not
[23:30:35 CET] <nevcairiel> the superframe splitting stuff was only vp9
[23:30:39 CET] <jamrial> if you're using webm/mp4 only, those are correclty marked already
[23:32:01 CET] <jya> so the old api only outputs the superframe?
[23:32:17 CET] <nevcairiel> whichever is first in that superframe probably
[23:32:34 CET] <nevcairiel> actually, thinking about it, should this actually be a problem?
[23:32:42 CET] <nevcairiel> arent additional frames in superframes invisible?
[23:33:02 CET] <jamrial> nevcairiel: it's only a problem because the frame mt code is not playing nice with the autoinserted split bsf, it seems
[23:33:12 CET] <nevcairiel> oh right
[23:33:19 CET] <nevcairiel> frame m t
[23:33:34 CET] <nevcairiel> because we call it multiple times, it outputs some older frames from before the superframe
[23:33:41 CET] <nevcairiel> without threading it should probably  work
[23:33:47 CET] <jamrial> yeah
[23:34:08 CET] <nevcairiel> one of these days we should make frame mt more smart and dynamic
[23:34:13 CET] <nevcairiel> probably after the old api is dead =p
[23:34:38 CET] <jya> here's the video it's quite noticeable
[23:34:39 CET] <jya> https://www.youtube.com/watch?v=lG5LZNhfyGM
[23:34:42 CET] <jya> 1080p60
[23:35:00 CET] <nevcairiel> i still use the old api for audio in my code
[23:35:04 CET] <nevcairiel> i was being lazy :/
[23:35:12 CET] <nevcairiel> re-did video some time ago
[23:35:12 CET] <BtbN> the video looks smooth here
[23:35:13 CET] <jya> stream 302 with youtube-dl
[23:35:28 CET] <jya> BtbN: not using firefox 64 and later
[23:35:41 CET] <BtbN> This is ff65.0b4
[23:35:46 CET] <nevcairiel> BtbN: it would only be a problem if you use a new ffmpeg with a player that uses the old api and threading
[23:35:48 CET] <atomnuker> nevcairiel: more smart and dynamic? in what ways?
[23:35:52 CET] <jya> must enable vp9 (right click on the video and select stats for nerds)
[23:35:53 CET] <nevcairiel> also probably no hardware
[23:36:18 CET] <jya> BtbN: which OS are you using?
[23:36:29 CET] <BtbN> Windows 10
[23:36:39 CET] <jya> sure you're getting vp9?
[23:36:45 CET] <BtbN> I am according to the stats
[23:36:46 CET] <jya> oh, what graphic card?
[23:36:56 CET] <BtbN> gtx1060
[23:37:00 CET] <nevcairiel> atomnuker: I imagine a more flexible pool of worker threads, so that we can retrieve finished frames without being required to have new data to fill those slots, for example
[23:37:02 CET] <jya> there you go, HW decoder
[23:37:19 CET] <jya> yeah, that will be butter smooth
[23:37:20 CET] <nevcairiel> ie. make frame-mt join the spirit of decoupled send/receive
[23:37:36 CET] <BtbN> It stopped being smooth the moment I opened the stats though
[23:38:12 CET] <jya> did you enable webrender?
[23:38:17 CET] <cone-232> ffmpeg 03Michael Niedermayer 07master:52ba824c6581: avcodec/rasc: Check input space before reading chunk
[23:38:18 CET] <cone-232> ffmpeg 03Michael Niedermayer 07master:35a603050d6c: avcodec/dvdsubdec: discard accumulated buffer on error
[23:38:19 CET] <cone-232> ffmpeg 03Michael Niedermayer 07master:7aaab127bebb: avcodec/clearvideo: Check remaining input bits in P macro block loop
[23:38:19 CET] <BtbN> Not that I'm aware of, let me check
[23:38:25 CET] <jya> it's still on the work for nvidia
[23:38:43 CET] <jya> webrender will be enabled for nvidia last, we've done amd and intel in 65 already
[23:38:58 CET] <BtbN> nothing on about:config for *webrender* is changed from defaults
[23:39:08 CET] <jya> about:support
[23:39:26 CET] <jya> in graphics -> compositing section
[23:39:26 CET] <BtbN> Compositing: WebRender
[23:39:32 CET] <jya> interesting
[23:39:54 CET] <jya> maybe it's enabled on the beta or you're part of the lucky test sample
[23:40:02 CET] <BtbN> It's dev edition
[23:40:10 CET] <jya> we enabled it to a small % of the population I believe
[23:40:22 CET] <BtbN> 65 is by far the best running FF in a long while
[23:40:31 CET] <BtbN> that might explain why
[23:40:35 CET] <jya> that's great to hear
[23:40:57 CET] <BtbN> And since nvidia finally fixed their crashing driver the other day, I also stopped sending dozens of crash reports about twitch per day
[23:41:32 CET] <jya> I had to disable the windows HW decoder for vp9 on nvidia 10xx for 10 bits videos
[23:41:39 CET] <jya> was resetting like crazy
[23:42:06 CET] <BtbN> Twitch is just normal h264 though. And it was still crashing tabs every once in a while.
[23:42:28 CET] <BtbN> The whole tab started glitching out, elements flashing white
[23:42:56 CET] <BtbN> Fixed since nvidia driver 417.21
[23:43:35 CET] <jya> really? never experienced this (1080ti here)
[23:43:52 CET] <jya> for testing the reset with P010 format, set media.wmf.force.allow-p010-format to true
[23:43:52 CET] <BtbN> Only ever happened on Twitch, and only on some streams.
[23:44:00 CET] <BtbN> But for those streams it happened every 5 minutes
[23:44:16 CET] <jya> and load https://jyavenard.github.io/htmltests/tests/webm-hdr.html
[23:44:20 CET] <BtbN> Switching to a transcoded stream fixed it, so it must be something their encoder was doing
[23:44:39 CET] <BtbN> As the Source stream comes straight from the Streamer
[23:44:52 CET] <jya> to save processing/bandwidth, the original stream is whatever the broadcaster is sending, it's not touched
[23:45:15 CET] <BtbN> Yeah, and only those were crashing, if at all
[23:45:20 CET] <jya> i can;'t image the hassle it must be to make their transcoded work and have the same kf as the original
[23:45:22 CET] <BtbN> any of the Twitch-Transcode always ran fine
[23:45:59 CET] <jya> would be interested to no if that last 10 bits videos work for you with your 1060 and the media.wmf.force.allow-p010-format set 
[23:46:06 CET] <jya> to know
[23:46:10 CET] <BtbN> https://crash-stats.mozilla.com/report/index/7b00819d-462c-4e45-b4b0-d3a540181214 that's one of those crashes btw.
[23:46:15 CET] <BtbN> one sec
[23:46:22 CET] <jya> in which case can relax the restrictions a bit
[23:47:22 CET] <jya> that crash is in the GPU process, should recover smoothly normally
[23:47:40 CET] <BtbN> It put the Tab in a "This tab has crashed" state
[23:48:02 CET] <BtbN> The video at the very bottom is just white with that flag set
[23:48:11 CET] <jya> it's crashed the content process too?
[23:48:18 CET] <jya> I'll investigate
[23:48:49 CET] <BtbN> It seems fixed since nvidia released the driver that specifically claims to fix video decoding crashes (in Edge though)
[23:50:06 CET] <BtbN> Yeah, that 10 bit video is definitely not working.
[23:50:57 CET] <jya> i typically get all green, all black and shortly after a driver reset 
[23:51:10 CET] <BtbN> It's just all white here, audio plays fine, no crashes or anything
[23:51:45 CET] <jya> that was the card I used when I added P010 format support, I struggled for 4 days wondering what I did wrong, until I got an intel one and miracle all worked first go
[23:52:14 CET] <BtbN> I might have copied the wrong crash report. That one is way too recent, the fixed driver as already installed by then. Must be of something else
[23:52:19 CET] <BtbN> One sec, I'll dig for an actual one
[23:52:21 CET] <jya> P010 is microsoft name for NV12 in 10 bits 
[23:52:32 CET] <BtbN> they are unfortunately gone from about:crashes already
[23:53:05 CET] <jya> if it got fixed with the new drivers, there wouldn't much we could have done anyway
[23:53:20 CET] <BtbN> Yeah, it was pretty clear it was a driver issue
[23:53:29 CET] <jya> I'm about to run out of battery, will resume tomorrow. thanks
[23:53:30 CET] <jya> good night
[23:53:42 CET] <BtbN> night
[00:00:00 CET] --- Sat Dec 15 2018