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

[burek]

[00:00:02 CEST] <BtbN> *via the new API
[00:00:26 CEST] <BtbN> When told to do deinterlacing, it would just refuse to work via the old API
[00:00:30 CEST] <wm4> I have a patch for a mediafoundation wrapper which uses the new API
[00:01:45 CEST] <nevcairiel> wrap all the things
[00:01:57 CEST] <BtbN> It should even be possible to write an API emulation on the global level, under the assumption that a codec outputs one frame per packet, which is true for all current codecs
[00:01:58 CEST] <nevcairiel> and people ask me for a MFT which wraps avcodec
[00:02:17 CEST] <JEEB> &33
[00:02:21 CEST] <nevcairiel> BtbN: if thats the case, a codec should just stick to the decode function instead of the pair
[00:02:24 CEST] <wm4> BtbN: yeah, but that can get complex
[00:03:05 CEST] <wm4> (and impossible to handle if the codec actually uses the new api to its full capability)
[00:03:06 CEST] <nevcairiel> the new public decode API works with  decoders that dont implement the new internal API
[00:03:17 CEST] <nevcairiel> so it does "emulation" =p
[00:14:32 CEST] <durandal117> was there any reason to not touch alpha with drawutils?
[00:24:01 CEST] <Chloe> jamrial: I've ported the opengl dev to sdl2
[00:26:30 CEST] <jamrial> Chloe: great. post the patch so it can be reviewed and everything commited together next week
[00:31:01 CEST] <JEEB> durandal117: I'm poking at the timestamp code in ffmpeg.c way too much for my liking, but seems like making sure that the ts_offset gets applied into the delta @ line 3931 of ffmpeg.c seems to help
[00:50:31 CEST] <BtbN> that went easier than expected
[00:50:41 CEST] <BtbN> at least it now implements the two new functions, and still works.
[00:50:50 CEST] <BtbN> No idea if I'm implementing the new API correctly though
[00:51:00 CEST] <nevcairiel> you just cant test because ffmpeg.c doesnt implement it yet :D
[00:51:24 CEST] <BtbN> it's pretty straight forward though, with basically no duplication
[00:52:31 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/4fd41d774d6baf73bf24f5ff311d0396bbcc78d0
[00:53:11 CEST] <philipl> nice one.
[00:53:49 CEST] <cone-306> ffmpeg 03Michael Niedermayer 07release/2.8:8ddeae57ae72: avformat/avidec: Fix infinite loop in avi_read_nikon()
[00:53:49 CEST] <cone-306> ffmpeg 03Michael Niedermayer 07release/2.8:26eccf4bd8c7: swscale/swscale_unscaled: Fix packed_16bpc_bswap() with slices
[00:53:49 CEST] <cone-306> ffmpeg 03Michael Niedermayer 07release/2.8:48c51b796a4c: swscale/swscale_unscaled: Try to fix Rgb16ToPlanarRgb16Wrapper() with slices
[00:53:49 CEST] <cone-306> ffmpeg 03Michael Niedermayer 07release/2.8:ac60619acdb5: avcodec/ccaption_dec: Use simple array instead of AVBuffer
[00:53:49 CEST] <cone-306> ffmpeg 03Michael Niedermayer 07release/2.8:175a95bfddc5: avcodec/avpacket: clear side_data_elems
[00:53:49 CEST] <cone-306> ffmpeg 03Michael Niedermayer 07release/2.8:f8dcc9e71897: avcodec/g726: Add missing ADDB output mask
[00:53:49 CEST] <cone-306> ffmpeg 03Xinzheng Zhang 07release/2.8:0bdfdd6d2f57: avformat/utils: fix timebase error in avformat_seek_file()
[00:53:50 CEST] <cone-306> ffmpeg 03Michael Niedermayer 07release/2.8:e1ab851da65d: avformat/movenc: Factor check_pkt() out
[00:53:51 CEST] <cone-306> ffmpeg 03Michael Niedermayer 07release/2.8:0ffdabb58d36: avformat/movenc: Check packet in mov_write_single_packet() too
[00:54:04 CEST] <BtbN> just noticed an issue though. decode_packet may return EOF, which is not an error
[01:00:15 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/9d5de95187deedbbe92be0a15c67743effe63b59 that's better.
[01:00:38 CEST] <BtbN> from reading the avcodec.h explanations of the API, it should work as expected
[01:08:04 CEST] <philipl> BtbN: and maybe some day we'll be able to test it :-)
[01:12:43 CEST] <rcombs> wm4 has a patch for that
[01:33:12 CEST] <cone-306> ffmpeg 03Michael Niedermayer 07release/2.8:d828aabf0343: Changelog: Update
[01:33:24 CEST] <JEEB> durandal_1707: it seems like the difference probably is due to requirement of decoding or not since after adding a whole truckload of debug print statements a lot of them just aren't getting called with the lavfi input
[01:33:37 CEST] <JEEB> gotta love ffmpeg.c
[01:34:59 CEST] <JEEB> oh nope, that was just me copying an old command without vsync vfr
[01:48:11 CEST] <JEEB> durandal_1707: feel free to try out this diff with a lot of extra debug printing http://up-cat.net/p/5f86470a
[01:48:36 CEST] <JEEB> looks like adding the ts_offset to the initial dts in case of !ist->saw_first_ts helped
[01:48:58 CEST] <JEEB> but holy REDACTED how much random logic there is in ffmpeg.c >_<
[01:49:11 CEST] <JEEB> I am not comfortable with it
[01:59:20 CEST] <JEEB> durandal_1707: btw just using -vsync passthrough -copyts actually made it work!?
[01:59:24 CEST] <JEEB> without any changes
[01:59:33 CEST] <JEEB> I... don't even
[02:00:06 CEST] <JEEB> and I thought copyts and passthrough wouldn't work with itsoffset
[02:00:45 CEST] <durandal_1707> its bunch of hacks combination
[02:01:29 CEST] <JEEB> yes, that much I understand
[02:01:37 CEST] <JEEB> there's a truckload of hacks
[02:26:35 CEST] <BtbN> philipl, turns out, if you crash often enough, and thus don't close the cuvid decoder, your system runs out of cuvid decoders, and you have to reboot to make it work again.
[02:46:39 CEST] <Chloe> jamrial: 'will be ignored' is probably better, 'likely' might make still it sound like it's ok to make a PR
[03:29:48 CEST] <philipl> BtbN: Now you know how many you can have. :-)
[07:02:29 CEST] <cone-806> ffmpeg 03James Almer 07master:ff0ff33b0563: doc/general.texi: mention MLP/TrueHD encoding support
[09:56:35 CEST] <Chloe> Does anyone understand what 'opengl device depends on opengl context. this patch works on sdl renderer which works on X. in many cases X is opengB so patch is working for many cases, but is shity in general.' means?
[09:57:20 CEST] <Chloe> How am I supposed to use sdl without using sdl?
[09:57:26 CEST] <Chloe> I'm confused :s
[10:01:31 CEST] <rcombs> I'm not sure there's any meaning to be found there
[10:02:52 CEST] <Chloe> I'd like to know what the issue with the patch is rather than just: "hurr durr I want to submit it"
[10:04:44 CEST] <durandal_1707> wm4: are you good with dvdsub decoder?
[10:34:44 CEST] <nivi_> Hello. Where do I find the codebase of ffmpeg and to understand workflow 
[10:35:00 CEST] <nivi_> Can anyone help me in that 
[10:36:32 CEST] <durandal_17> nivi_: beef using this library. The source code is at deadbeef-hdcd. I've started work on an MPD plugin as well.
[10:36:47 CEST] <durandal_17> nivi_: http://git.videolan.org/?p=ffmpeg.git
[10:37:07 CEST] <durandal_17> stupid unix middle mouse copy paste
[10:48:29 CEST] <wm4> durandal_17: not really, depends?
[10:52:11 CEST] <durandal_17> wm4: see http://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199696.html
[10:52:45 CEST] <durandal_17> basically for some dvdsubs one get 1x1 bitmaps
[10:53:50 CEST] <durandal_17> also http://trac.ffmpeg.org/ticket/5825
[10:54:53 CEST] <durandal_17> ignore overlay thing, subs do not display with mpv too
[11:04:12 CEST] <cone-944> ffmpeg 03Josh de Kock 07master:ef42c1de2b43: Add CONTRIBUTING.md
[11:05:43 CEST] <BtbN> philipl, turns out adding deinterlacing to this is not as straight forward as I hoped
[11:05:55 CEST] <BtbN> being unable to test it doesn't help
[11:08:24 CEST] <wm4> unable to test?
[11:12:12 CEST] <BtbN> wm4, well, nothing uses the send_packet/receive_frame API yet.
[11:12:42 CEST] <BtbN> No idea how hard patching ffmpeg.c to do so is
[11:12:48 CEST] <wm4> durandal_17: well I don't know, they say it works in vlc, so surely there's a way to handle this reasonably?
[11:12:56 CEST] <wm4> BtbN: very hard
[11:13:04 CEST] <wm4> I can bury out my patch for this
[11:13:14 CEST] <BtbN> I don't care too much about it being correct
[11:13:22 CEST] <BtbN> Something that works at all is enough
[11:22:20 CEST] <wm4> BtbN: seems to apply, untested: http://sprunge.us/RMWa
[11:24:09 CEST] <BtbN> thanks. Have to make it stop segfaulting without that first, then I'll see how it goes
[11:27:40 CEST] <Chloe> TIL you can amalgamate patches into one file
[11:40:56 CEST] <BtbN> Great, the crash I'm seeing is not caused by me
[11:41:01 CEST] <BtbN> it's also in current git master
[11:45:15 CEST] <BtbN> so, bisect time
[12:00:51 CEST] <BtbN> At least this bisect can be easily automated
[12:53:12 CEST] <BtbN> philipl, looks like the flush-patch causes crashes in some edge cases, but I'm confused why, as the crash happens entirely outside of cuvid code
[12:54:38 CEST] <BtbN> philipl, https://btbn.de/images/test/crash_test.mkv -> ./ffmpeg -threads 1 -v trace -c:v h264_cuvid -i ~/crash_test.mkv -an -sn -c:v rawvideo -f null -
[13:28:20 CEST] <BtbN> I'm so confused: https://bpaste.net/show/be26a4798075
[13:28:26 CEST] <BtbN> since https://github.com/FFmpeg/FFmpeg/commit/86910b15c9ee2d5c377b137ec653c044572f94ff
[13:28:48 CEST] <BtbN> removing the flush function does not fix it, nor is it ever called. And none of the other changes looks like they might cause it oO
[13:34:14 CEST] <BtbN> hm, the code in libavformat/utils.c looks like it has some hard assumptions about h264 being decoded by the native h264 decoder
[13:50:00 CEST] <BtbN> It's amazing this didn't blow up earlier
[13:50:49 CEST] <JEEB> you'd be surprised how many things like that there are
[13:50:52 CEST] <BtbN> It started crashing because of the new fields, which causes this function, called on the cuvid context, interpreted by this: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264dec.c#L62
[13:51:12 CEST] <wm4> the joys of entangling code
[13:51:29 CEST] <BtbN> Simply because the code assumes if the codec is h264, it has to be the ffmpeg "h264" decoder.
[13:51:44 CEST] <JEEB> meanwhile I wonder how many things the actual change on line 11 in this breaks FATE-wise http://up-cat.net/p/5f86470a
[13:52:06 CEST] <JEEB> because this makes -vsync vfr do the same thing with -itsoffset 300 and -itsoffset $(date %+s)
[13:52:38 CEST] <JEEB> but because the timestamp stuff is so convoluted I have no idea if any of my changes are actually correct out of my test case
[13:52:56 CEST] <JEEB> also is not setting -vsync supposed to just duplicate the initial frame until the offset timestamp?
[13:53:01 CEST] <BtbN> Is there a better way to check for this than !strcmp(st->internal->avctx->codec->name, "h264")?
[13:53:02 CEST] <wm4> BtbN: and it was added by an essentially unreview patch by michaelni!
[13:53:05 CEST] <JEEB> because I just don't know :D
[13:53:18 CEST] <wm4> michaelni: maybe you should think before adding garbage code
[14:03:54 CEST] <michaelni> BtbN, JEEB why is st->internal->avctx not the libavcodec software decoder ?
[14:04:13 CEST] <BtbN> because it's the cuvid h264 decoder.
[14:04:23 CEST] <michaelni> I mean if this is the hw decoder you would be running the hw decoder twice
[14:04:36 CEST] <michaelni> once in the application and once in libavformat
[14:04:41 CEST] <michaelni> is that intended ?
[14:04:47 CEST] <BtbN> hm?
[14:04:56 CEST] <michaelni> or am i misunderstanding?
[14:05:09 CEST] <BtbN> the cuvid h264 decoder is completely inside of lavc, completely independend from the outside
[14:07:13 CEST] <michaelni> sure but libavformat opens a decoder to get some information about a stream, if thats the hw decoder then there would be 2 as the user app would also have a decoder independat of libavformat
[14:08:43 CEST] <BtbN> It indeed seems to open it twice
[14:09:52 CEST] <BtbN> But I don't see anything I could possibly do about that from inside of the cuvid decoder, and it also works just fine.
[14:10:52 CEST] <michaelni> not from the inside but the code setting up st->internal->avctx should maybe not open a hw decoder
[14:11:15 CEST] <michaelni> or if we want it to do that then indeed the avpriv_h264_has_num_reorder_frames() call is garbage
[14:12:04 CEST] <BtbN> Forcing it to use the software decoder for the initial parsing seems like the better solution. As it returns way more information about the stream.
[14:13:32 CEST] <ubitux> speaking of this, we should make the parsers fill some codec parameters instead of an avctx for probing
[14:13:41 CEST] <nevcairiel> blindly assuming the priv_data matches one decoder just based on codec id seems risky no matter what you do, though
[14:13:50 CEST] <ubitux> because probing doing decode is waaay too slow on some embedded targets
[14:14:54 CEST] <michaelni> ubitux, yes using the parsers is better, this stuff is from a time there was just one decoder for both app and libavformat
[14:15:40 CEST] <ubitux> ...and if parsers could avoid depending on the decoder that would be great too (hi hevc parser)
[14:20:56 CEST] <BtbN> Well, cuvid deinterlacing "works" now.
[14:21:12 CEST] <BtbN> Only issue is: The framerate and timestamps need to be adjusted
[14:25:41 CEST] <nevcairiel> and you cant really do that, since the timestamp timebase comes from the stream
[14:26:12 CEST] <BtbN> why can't I do that?
[14:26:24 CEST] <nevcairiel> A decoder simply cannot modify something it has no access to =p
[14:26:39 CEST] <BtbN> It does have access to the pts?
[14:26:51 CEST] <BtbN> And that's the only thing it sets, aside from the framerate
[14:26:58 CEST] <BtbN> which just needs to be multiplied by tw
[14:27:00 CEST] <BtbN> *two
[14:27:24 CEST] <nevcairiel> without changing the timebase, just changing the timestamps is not guaranteed to work
[14:29:29 CEST] <nevcairiel> if you have a timebase of 1/30 for 30 fps, then every frame has a nice pts of 1 .. 2 .. 3.. 4.. 5 .. etc. If you try to make that 60 fps, you would either have to insert new frames in between the "original" pts, but you cant since its integer, or change the timebase - which you also cant since its out of the control of the decoder
[14:43:47 CEST] <durandal_17> ubitux: i think my dvdsub patch is fine
[14:44:43 CEST] <ubitux> maybe? :)
[14:44:50 CEST] <ubitux> i don't know
[14:45:03 CEST] <ubitux> i'd love some dvd specifications one day though
[14:49:15 CEST] <BtbN> this is weird. There is the exact amount of frames coming out, even though the decoder definitely is frame-doubling
[14:50:17 CEST] <BtbN> So something must be dropping every second frame. Probably because of some timestamp issue
[14:54:02 CEST] <nevcairiel> cant fit 60 frames into a 30 fps timebase
[14:54:27 CEST] <BtbN> the timebase is more than large enough, with 40 ticks per frame
[15:02:23 CEST] <BtbN> this whole framerate/timestamp/timebase/pkt_timebase/... situation is a giant mess.
[15:02:39 CEST] <nevcairiel> its not htat bad, its just not designed for a decoder to "invent" frames :)
[15:02:48 CEST] <BtbN> It's entirely unimpressed if I change the time_base, framerate, duration, pts, anything
[15:03:01 CEST] <nevcairiel> like i said, decoders cannot influence this
[15:03:19 CEST] <BtbN> At least the h264dec software decoder does
[15:03:25 CEST] <BtbN> so I guess it has to be possible
[15:03:38 CEST] <nevcairiel> how does it do that? it has no reason to
[15:04:01 CEST] <BtbN> it divides the time_base by 2, and sets ticks_per_frame to 2.
[15:04:33 CEST] <nevcairiel> thats just for its internal timebase dealy, doesnt actually influece timestamps going through it
[15:04:47 CEST] <nevcairiel> as it still produces one frame from each input frame
[15:04:49 CEST] <nevcairiel> not suddenly two
[15:05:30 CEST] <nevcairiel> the use of codec time_bases is a bit confusing and often just best to ignore it :D
[15:05:53 CEST] <BtbN> but at least ffmpeg.c uses avcodeccontext time_base to calculate the duration and dts and a lot of other stuff
[15:16:45 CEST] <durandal_17> ubitux: height was increased by 1, but if statement that check height was not updated
[15:17:05 CEST] <BtbN> I don't understand why doubling the framerate and making up an in-between pts for the output frame isn't enough. Provided the pts step is big enough to allow an in-between value.
[15:21:48 CEST] <durandal_17> ubitux: and in next call to decode_rle fails, because h / 2 = 0 for h = 1
[15:28:00 CEST] <cone-589> ffmpeg 03Paul B Mahol 07master:6cbd47bf90d3: avcodec/dvdsubdec: ignore h <= 1 case, to properly decode subtitle
[15:55:17 CEST] <JEEB> lol libutvideo
[16:01:16 CEST] <nevcairiel> it was a 4yo ticket and the comment just said that it has been removed, so all fine =p
[16:01:24 CEST] <JEEB> right
[17:04:24 CEST] <philipl> BtbN: I'm relieved it wasn't my fault.
[17:04:51 CEST] <BtbN> well, you adding a field that's 0 caused it, because it just so happend to be what it accesses
[17:05:13 CEST] <philipl> Heh. I did the world a favour.
[17:05:22 CEST] <philipl> And you inspired me to go and try to make crystalhd work again.
[17:05:37 CEST] <philipl> It's regressed massively due to change elsewhere.
[17:06:01 CEST] <JEEB> was crystalhd that one external card thing?
[17:06:09 CEST] <philipl> Yes.
[17:06:14 CEST] <philipl> The broadcom one.
[17:06:15 CEST] <nevcairiel> do people really still use these things? they were kinda crappy when they were new =p
[17:06:36 CEST] <philipl> So, I've got this ancient laptop which is the only thing left I can physically put the card in
[17:06:45 CEST] <JEEB> :D
[17:06:46 CEST] <nevcairiel> heh
[17:06:57 CEST] <philipl> Amusingly, it has an nvidia gpu in it which used to do vdpau just fine.
[17:07:20 CEST] <philipl> With today's drivers, vdpau is basically unusable. It can't get enough device side memory to do anything useful.
[17:07:26 CEST] <philipl> Dunno what they changed.
[17:08:02 CEST] <philipl> So crystalhd. It was still using the old bsf api
[17:08:20 CEST] <philipl> and something has happened to wreck timestamps for h.263 content
[17:08:46 CEST] <philipl> and the h264 parser I instantiated to try and work out whether content is interlaced or not now just prints a constant stream of errors
[17:08:50 CEST] <philipl> *sigh*
[17:09:10 CEST] <philipl> This decoder could really benefit from the new API
[17:09:25 CEST] <durandal_17> just kill it
[17:09:44 CEST] <philipl> The hardware, for obscure reasons, sometimes returns individual fields and sometimes field pairs and you don't always know what you'll get until you've actually got it.
[17:10:14 CEST] <nevcairiel> well you cant output individual fields anyway, so you need to re-combine them
[17:10:24 CEST] <philipl> There's a pathological path through it where all the heuristics say it'll return a field pair and then it doesn't
[17:10:36 CEST] <philipl> so I just give up and return half a frame
[17:10:46 CEST] <philipl> because it's too late to wait for the second half
[17:11:12 CEST] <philipl> 90% of the code in that file is ridiculous interlaced hueristics.
[17:11:58 CEST] <philipl> nevcairiel: the other half of the fun is that if you try and pump the output another time and it turns out it needed another input frame, it'll deadlock instead of returning an error.
[17:12:20 CEST] <nevcairiel> sounds like deleting is the way to go
[17:12:21 CEST] <nevcairiel> :D
[17:12:39 CEST] <philipl> You also can't trust it if it says there's space in the input buffer.
[17:13:02 CEST] <philipl> Basically, it's the least trustworthy hardware I've ever seen.
[17:14:57 CEST] <philipl> I don't think I could delete it as long as I can physically use the hardware - it's the principle :-)
[17:27:58 CEST] <BtbN> philipl, https://github.com/BtbN/FFmpeg/ deinterlacing essentialy works. it "just" needs some way to handle the timestamps
[17:36:15 CEST] <philipl> BtbN: cool. Does it work if the existing timebase allows you to interpolate the pts as-is?
[17:36:24 CEST] <BtbN> no
[17:36:32 CEST] <BtbN> Something seems to discard any extra frames
[17:36:38 CEST] <BtbN> Or I made some silly mistake
[17:36:43 CEST] <philipl> weird.
[17:37:39 CEST] <philipl> wm4: so mpv already supports the new api right?
[17:37:46 CEST] <BtbN> there are like 6 diffrent ways to get and set pts/dts/duration/time_base/pkt_timebase/framerate/...
[17:37:48 CEST] <wm4> philipl: yeah
[17:37:52 CEST] <BtbN> And I have no idea how they all interact
[17:38:16 CEST] <wm4> philipl: not in a very ideal way (supporting both APIs makes this hard), but it does
[17:38:24 CEST] <BtbN> just doubling the framerate and making up an intermediate pts is not enough
[17:38:25 CEST] <philipl> BtbN: did you try with mpv?
[17:38:52 CEST] <BtbN> no, only ffmpeg itself
[17:39:01 CEST] <philipl> I'll try your branch now
[17:40:00 CEST] <BtbN> even with rawvideo output, the extra frames are missing
[17:40:58 CEST] <philipl> It's certainly not happy
[17:41:30 CEST] <JEEB> see with -debug_ts how many things go out of the decoder
[17:50:57 CEST] <philipl> Umm. Indulge me. How should I choose the mode from the command line.
[17:51:03 CEST] <philipl> Right now I'm getting identical output from debug_ts
[17:53:05 CEST] <BtbN> just -deint weave/bob/adaptive
[17:53:07 CEST] <BtbN> as decoder option
[17:53:19 CEST] <philipl> n/m. I managed to construct a command line that did a copy and ignored the decoder I specified :-P
[17:56:39 CEST] <philipl> Ok, so the 'decoder' output is what you want. There's twice as many lines
[18:01:30 CEST] <philipl> Then it looks like it runs through a filter (what filter?) which results in both frames coming out with the same pts
[18:01:42 CEST] <philipl> and then the muxer throws the second one away.
[18:02:13 CEST] <philipl> This is with the null muxer implying the wrapped_avframe 'encoder'
[18:04:39 CEST] <philipl> (or maybe it doesn't throw it away, but it definitely complains that it got the same pts on the second frame
[18:05:36 CEST] <JEEB> oh yes, one of the outputs says filter but I'm not sure it really goes through a filter
[18:05:42 CEST] <JEEB> there's a whole lot of timestamp magic in ffmpeg.c though
[18:06:19 CEST] <wm4> evil magic
[18:06:25 CEST] <JEEB> yes
[18:06:40 CEST] <JEEB> I spent last night trying to get timestamp offsets of unix timestamps working
[18:06:44 CEST] <JEEB> http://up-cat.net/p/5f86470a
[18:07:00 CEST] <JEEB> this made -vsync vfr work but I have no effing idea if I added the offset into the correct calculation
[18:07:15 CEST] <philipl> wm4: Yet, mpv isn't happy with this decoder output either.
[18:07:17 CEST] <wm4> I once fixed a bug by re-enabling some accidental dead code, but it broke some fate tests
[18:07:25 CEST] <wm4> philipl: what happens?
[18:07:38 CEST] <philipl> wm4: It gets very confused on seeks
[18:07:45 CEST] <JEEB> I was totally surprised that -vsync passthrough -copyts takes itsoffset into mention, though
[18:08:02 CEST] <JEEB> because passthrough sounds like it should take stuff from input and pass on
[18:08:14 CEST] <JEEB> oh well, I have no idea of the depths of this black magic
[18:10:33 CEST] <Chloe> why do we need an opengl renderer in ffmpeg?
[18:12:21 CEST] <philipl> wm4: I'm not sure what's really going on, I think it might be doing the right thing up until the seek
[18:13:21 CEST] <wm4> Chloe: because someone added it
[18:13:31 CEST] <wm4> philipl: shouldn't a seek just flush and discard all state?
[18:13:44 CEST] <JEEB> Chloe: you could go through the sad original thread
[18:13:51 CEST] <philipl> wm4: it should. but it sticks for a couple of seconds and then prints something like:
[18:13:58 CEST] <philipl> Invalid video timestamp: 8.880000 -> 6.200000
[18:14:03 CEST] <philipl> and then continues
[18:14:12 CEST] <philipl> This is with a simpler sample than my first test
[18:15:12 CEST] <wm4> I'm fairly sure mpv discards all state on seeks (and it also works with my MF wrapper, which uses the new API)
[18:16:16 CEST] <philipl> wm4: Well, there's multiple things that changed here. I'm getting dodgy seeking even with no deinterlacing.
[18:16:30 CEST] <philipl> Maybe something related to the new API usage
[18:17:55 CEST] <philipl> wm4: Yeah, so if I revert BtbN's changes, seeking is as it should be.
[18:18:13 CEST] <BtbN> i did not change anything regarding the flush
[18:18:26 CEST] <BtbN> and there's a bunch of new logic regarding timestamp calculation and frame counting
[18:20:10 CEST] <philipl> Yeah.
[18:20:43 CEST] <philipl> So I'd tentatively say mpv is doing the right thing with the extra frames, and there's a flush/seek problem that's not directly caused by the extra frames.
[18:20:56 CEST] <Chloe> JEEB: didn't really say much except the guy fixing some bugs. I still really don't think ffmpeg is the right place for an opengl renderer. I'm also quite reluctant about the sdl2 device.
[18:21:21 CEST] <philipl> BtbN: did you introduce new state that isn't reset on flush?
[18:21:24 CEST] <JEEB> then that's not the original thread
[18:21:34 CEST] <JEEB> I'm pretty sure there was a discussion about it and then it got merged somehow
[18:22:37 CEST] <BtbN> philipl, that's what I just said
[18:22:55 CEST] <philipl> BtbN: I'm not the fastest guy this morning. :-)
[18:26:48 CEST] <philipl> BtbN: Ok. I have flushing working now
[18:27:03 CEST] <philipl> There's still a timestamp warning coming out of mpv
[18:27:20 CEST] <philipl> Not sure what's leading to that but it works for practical purposes.
[18:27:26 CEST] <philipl> and it is showing the extra frames
[18:27:26 CEST] <BtbN> the first second_field timestamp is just + 1 of the previous
[18:27:45 CEST] <BtbN> Didn't come up with a better guess yet
[18:27:46 CEST] <philipl> V: 00:00:09 / 00:00:29 (32%) Cache: 10s+9MB
[18:27:46 CEST] <philipl> Invalid video timestamp: 9.580000 -> 9.440000
[18:27:46 CEST] <philipl> V: 00:00:09 / 00:00:29 (33%) Cache: 10s+9MB
[18:27:46 CEST] <philipl> Invalid video timestamp: 9.440000 -> 9.380000
[18:27:46 CEST] <philipl> V: 00:00:09 / 00:00:29 (33%) Cache: 10s+9MB
[18:27:48 CEST] <philipl> Invalid video timestamp: 9.740000 -> 9.680000
[18:27:51 CEST] <philipl> V: 00:00:01 / 00:00:29 (6%) Cache: 10s+17MB
[18:27:52 CEST] <Chloe> JEEB: could you give me a link?
[18:27:53 CEST] <philipl> This kind of thing on backward seeks
[18:29:04 CEST] <wm4> somewhat likely that these are actually what the decoder returns
[18:29:08 CEST] <philipl> BtbN: but I've got another sample that doesn't produce those at all.
[18:29:16 CEST] <philipl> maybe due to internal timebase
[18:29:22 CEST] <philipl> of the file
[18:29:32 CEST] <BtbN> it's not that unlikely that +1 is the correct value
[18:30:22 CEST] <philipl> Yeah, so that's probably it. 
[18:31:44 CEST] <philipl> BtbN: I've got an extremely pathological sample here that grinds to a halt after a second or so.
[18:31:49 CEST] <philipl> broadcast tv of course.
[18:35:17 CEST] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/3473fbe5e4c8da17e619115e5b1e966b61e44370
[18:35:20 CEST] <philipl> flush fix
[18:47:09 CEST] <BtbN> I'm still trying to understand what I need to change, and when, to get multiple frames working
[18:47:31 CEST] <BtbN> Modifying the timebase doesn't seem to do anything
[18:47:43 CEST] <philipl> Just remember that's an ffmpeg.c thing.
[18:47:50 CEST] <philipl> mpv seems to work fine
[18:48:15 CEST] <BtbN> But I want ffmpeg.c to work fine as well, even if it's just with those patches on top.
[18:48:41 CEST] <philipl> of course, but what I mean is it's not necessarily that you are doing anything wrong...
[18:49:26 CEST] <BtbN> well, most of that guesswork definitely is wrong
[18:50:34 CEST] <cone-409> ffmpeg 03Paul B Mahol 07master:260de8a264b7: avcodec/sheervideo: fix Y prediction in decode_ybr(i) for older formats
[18:50:34 CEST] <cone-409> ffmpeg 03Paul B Mahol 07master:6216b4780b16: avcodec/sheervideo: print internal format in debug log
[18:51:08 CEST] <BtbN> just realized that I don't even have to guess. Due to the cuvid delay, I know the previous timestamp way in advance
[18:51:16 CEST] <philipl> ah ha.
[18:53:52 CEST] <wm4> BtbN: well I don't think a codec can change the timebase by itself
[18:54:13 CEST] <wm4> that would require a new mechanism of some sort
[18:54:38 CEST] <BtbN> it can at least change time_base
[18:54:51 CEST] <BtbN> but that isn't too usefull from what it looks like
[18:55:10 CEST] <wm4> yeah, for decoders time_base is some alien WTF thing
[18:55:35 CEST] <BtbN> it's even deprecated
[18:55:44 CEST] <BtbN> so I guess I don't have to care about it
[18:55:57 CEST] <BtbN> the only problem is: ticks_per_frame still has something to do with it
[18:56:29 CEST] <wm4> ouch
[18:56:42 CEST] <BtbN> and ticks_per_frame is usualy 1
[18:56:53 CEST] <BtbN> But now I have two frames per tick
[18:58:08 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/5bc339bc19cd34d581ce6c591c95670fe3ac291e#diff-c5d740b1b8d5e156a473ed3a4e3ec7ecR2368
[18:58:14 CEST] <BtbN> i suspect it has something to do with that
[18:58:52 CEST] <wm4> (no idea what AVCodecContext.framerate is either)
[18:59:05 CEST] <BtbN> the framerate, as set by the decoder.
[18:59:18 CEST] <BtbN> actual frames per second
[18:59:28 CEST] <BtbN> according to avcodec.h, it's what decoders should use instead of time_base
[19:00:02 CEST] <BtbN> but it should work out
[19:00:08 CEST] <wm4> makes no sense to me, the framerate is implicitly defined by the timestamps of input packets
[19:00:19 CEST] <BtbN> ticks_per_frame is 1, so if I double the framerate, the duration calculated by that should halve
[19:00:40 CEST] <BtbN> yes, but some decoders output no frame duration
[19:00:48 CEST] <BtbN> and it's made up from the framerate if it's not set.
[19:04:34 CEST] <nevcairiel> the duration is largely irrelevant, if in doubt it lasts until the next frame
[19:04:38 CEST] <nevcairiel> the timestamps are the crucial aspect
[19:17:46 CEST] <BtbN> https://bpaste.net/show/a664f243a511 timestamps looks helathy to me
[19:18:28 CEST] <BtbN> but the framerate does not... hold on a second
[19:18:29 CEST] <Chloe> >takes my patch, makes a few lines of changes, slaps his name on it
[19:18:35 CEST] <Chloe> apparently this is how review works
[19:20:58 CEST] <BtbN> well... there's something important missing in this line: av_mul_q(avctx->framerate, (AVRational){2, 1});
[19:21:44 CEST] <BtbN> right, assigning the result
[19:33:21 CEST] <BtbN> I have absolutely no idea what it's complaining about. My only guess is that some part of ffmpeg.c is still tied to one packet -> one frame
[19:36:00 CEST] <wm4> hard to know
[19:36:16 CEST] <wm4> I only know that it should work if there's arbitrary buffering with them (as long as you have timestamps)
[19:36:42 CEST] <nevcairiel> it likely just doesnt expect the decoder to change the framerate and drops the frames again to match t
[19:36:44 CEST] <nevcairiel> it*
[19:36:55 CEST] <nevcairiel> because it generally doesnt make sense for a decoder to do it
[19:37:14 CEST] <BtbN> https://bpaste.net/show/abc7010032be
[19:37:40 CEST] <BtbN> this looks correct, one call to decode_packet, and then 3 calls to output_frame, where the third one results in an EAGAIN
[19:37:54 CEST] <BtbN> But then it decides to drop the frame
[19:38:04 CEST] <jamrial> oh nice, someone wrote hevc idct asm
[19:38:16 CEST] <JEEB> yeh, sasshka is doing that @ libav
[19:38:23 CEST] <JEEB> https://github.com/sasshka/libav/commits/hevc_parts2
[19:38:35 CEST] <jamrial> she just submitted it
[19:38:38 CEST] <JEEB> oh
[19:38:55 CEST] <nevcairiel> i hope we can adopt those without too much pain, this time
[19:39:04 CEST] <jamrial> yeah, i think idct is the same in both projects, so it should apply cleanly
[19:39:22 CEST] <JEEB> and here I thought that we already had IDCT asm for some reason
[19:39:23 CEST] <jamrial> it was mc the thing they changed a lot before writing asm
[19:40:28 CEST] <nevcairiel> seems kinda odd to use avx with xmm regs only, and not offer a sse variant on top of that, but what can you do :D
[19:42:25 CEST] <jamrial> nevcairiel: it is also x86_64 only
[19:43:13 CEST] <nevcairiel> at least the smaller variants would be nice to also add to 32-bit, but one thing at a time i guess
[19:47:21 CEST] <BtbN> From my understanding of things, the cuvid decoder operates propperly.
[19:47:37 CEST] <BtbN> I guess ffmpeg.c probes the framerate to be 25fps, and then sticks with that
[19:48:01 CEST] <JEEB> you can try -vsync passthrough -copyts
[19:49:17 CEST] <BtbN> yes, that looks better
[19:49:19 CEST] <BtbN> weird
[19:49:40 CEST] <JEEB> ffmpeg.c has very weird behaviors in its timestamp management code
[19:49:57 CEST] <JEEB> I'm not sure if anyone can actually at this point explain all of the modes and how they should work
[19:50:00 CEST] <BtbN> that results in a nicely deinterlaced 50fps file
[19:50:19 CEST] <BtbN> still looks a bit choppy though
[19:50:52 CEST] <JEEB> like, I didn't expect an -itsoffset of 300 seconds to lead to ffmpeg.c duplicating the first frame until that timestamp
[19:50:59 CEST] <JEEB> (without any vsync value)
[19:51:30 CEST] <JEEB> -vsync vfr seemed to fare a bit better but -itsoffset $(date %+s) broke horribly
[19:51:58 CEST] <JEEB> (which I managed to fix last night but unfortunately I cannot be sure if my changes were actually correct)
[19:52:10 CEST] <JEEB> and -vsync passthrough -copyts just worked
[19:52:17 CEST] <BtbN> well, the 50fps are working now. Now I'm just not sure if the actual deinterlacing is
[19:53:08 CEST] <JEEB> cool
[19:55:11 CEST] <BtbN> it looks way too choppy, it might just be outputting the same frame twice
[19:55:13 CEST] <jamrial> nevcairiel: applies and works :D
[19:55:23 CEST] <JEEB> najs
[19:56:11 CEST] <jamrial> nevcairiel: a quick test with a 1080p sample i created with x265 goes from 45fps to 53fps using one thread
[19:56:56 CEST] <jamrial> might be a good idea to compare it with openhevc's intrinsic version
[19:57:20 CEST] <JEEB> the thing I was using for benchmarking was 8000 frames of some UHD broadcast
[19:58:00 CEST] <JEEB> https://kuroko.fushizen.eu/samples/Japanese_Rugby_Game-4K_Channel.ts
[19:59:41 CEST] <nevcairiel> jamrial: i cna probably benchmark using my codebase with the intrinsics compared to those, if i find somet ime
[20:00:16 CEST] <jamrial> nevcairiel: that'd be great
[20:00:58 CEST] <jamrial> the SAD port to yasm was about 10% faster than the intrinsic version, so i expect something similar here
[20:04:21 CEST] <JEEB> with the sample I noted with -vframes 8000 I got ~28fps on an ivy bridge laptop and ~38fps with the intrinsics
[20:04:23 CEST] <jamrial> JEEB: i can't even play that file in real time. 56fps using all cores (haswell i5), and that's using ffmpeg with null output
[20:04:41 CEST] <JEEB> 28 being vanilla FFmpeg
[20:06:53 CEST] <BtbN> philipl, when used with mpv, does the deinterlacing actually work?
[20:07:08 CEST] <philipl> BtbN: yep. works correctly from visual inspection.
[20:07:28 CEST] <BtbN> I'm uploading a yadif comparison, and it looks like it's just doubling frames
[20:07:29 CEST] <jamrial> 4k hevc in software seems to be pretty much impossible, so better get that Pascal/Polaris card
[20:07:52 CEST] <nevcairiel> get a pascal card, stay away from amd for decoding tasks
[20:08:32 CEST] <philipl> BtbN: I'm clearly seeing both deinterlacing and the additional frames
[20:08:56 CEST] <jamrial> nevcairiel: haven't had any issues with amd, but then again my card is a first gen GCN not meant for anything beyond 1080p 60fps h264
[20:09:21 CEST] <jamrial> and that works fine with your lavfilters
[20:09:22 CEST] <nevcairiel> the hevc decoder is extremely slow
[20:09:28 CEST] <nevcairiel> 4k at 60 is nearly impossible
[20:09:43 CEST] <nevcairiel> while nvidia does like 1000 fps on 1080p, i forgot the 4k number
[20:10:12 CEST] <BtbN> probably 250
[20:11:01 CEST] <jamrial> nevcairiel: you mean it's slow on a rx480?
[20:11:04 CEST] <philipl> And now I've packed away my crystalhd laptop. I fixed the h.264 related regressions but that's quite enough insanity for one day. Apparently the pts values for h.263 in an avi have changed over the years and so that's broken now.
[20:11:10 CEST] <nevcairiel> jamrial: yes
[20:11:38 CEST] <jamrial> weird. 4k hevc is kinda a selling point for hardware decoding in new cards
[20:11:41 CEST] <BtbN> philipl, https://btbn.de/images/test/deint_cuvid_adaptive.mkv vs. https://btbn.de/images/test/deint_yadif.mkv
[20:11:53 CEST] <BtbN> the yadif one looks way better to me
[20:12:00 CEST] <BtbN> the cuvid one still looks like 25 fps
[20:12:08 CEST] <nevcairiel> jamrial: amd just fails at hardware decoding, always have, always will. the generation they announced 4k decoding on (iirc 7xxx) it was broken and eventually disabled through drivers
[20:12:17 CEST] <nevcairiel> 4k h264 i mean
[20:12:36 CEST] <kurosu> https://docs.google.com/spreadsheets/d/1ovWEjWBEiXjQB-Nku-_DWClmfleiNRIZYoII-m_5wgE/edit?usp=sharing <- some benchmark I ran a couple days ago
[20:12:37 CEST] <BtbN> And then there is nvidia, who implemented hevc encoding first.
[20:12:44 CEST] <jamrial> my card is a 7950. so it was meant to work wiht 4k content? hah
[20:12:49 CEST] <nevcairiel> it was, once
[20:13:47 CEST] <nevcairiel> nvidia also supports 8k decoding
[20:14:05 CEST] <philipl> BtbN: I've found the https://samples.ffmpeg.org/MPEG2/interlaced/ samples very useful.
[20:14:14 CEST] <jamrial> well, it works wonders with Vulkan in Doom 2016, so 4k hardware decoding can wait until i get a new monitor and card
[20:14:41 CEST] <nevcairiel> not to mention 4k vp9, where amd also only announced 1080p, and i dont think tehy actually enabled that in the drivers yet
[20:14:44 CEST] <BtbN> it bring games performances on AMD cards to the performance they allways had with OpenGL on nvidia.
[20:15:16 CEST] <philipl> BtbN: your cuvid file is identified as 25fps.
[20:15:17 CEST] <jamrial> no, it seems to beat nvidia opengl
[20:15:32 CEST] <BtbN> philipl, MPC-HC plays it as 50fps
[20:15:40 CEST] <BtbN> and the frame-count also indicated 50fps
[20:15:41 CEST] <nevcairiel> fwiw vulkan in doom is kinda broken
[20:16:00 CEST] <philipl> BtbN: Yeah, mpv is clearly playing it at 50. It's also complaining about timestamps.
[20:16:05 CEST] <nevcairiel> so far there hasnt been a vulkan or dx12 game which didnt have sever  implementation quirks
[20:16:11 CEST] <nevcairiel> new tech etc, so not too surprising
[20:16:12 CEST] <philipl> I want to say it's saying every extra frame has the same timestamp as the previous one
[20:16:21 CEST] <philipl> AV: 00:00:00 / 00:00:56 (0%) A-V:  0.000
[20:16:22 CEST] <philipl> Invalid video timestamp: 0.040000 -> 0.040000
[20:16:22 CEST] <philipl> AV: 00:00:00 / 00:00:56 (0%) A-V:  0.000
[20:16:22 CEST] <philipl> Invalid video timestamp: 0.080000 -> 0.080000
[20:16:22 CEST] <philipl> AV: 00:00:00 / 00:00:56 (0%) A-V: -0.000
[20:16:24 CEST] <philipl> Invalid video timestamp: 0.120000 -> 0.120000
[20:16:26 CEST] <philipl> AV: 00:00:00 / 00:00:56 (0%) A-V: -0.000
[20:16:29 CEST] <philipl> Invalid video timestamp: 0.160000 -> 0.160000
[20:16:31 CEST] <philipl> etc
[20:16:33 CEST] <BtbN> I verified that that's not the case.
[20:16:38 CEST] <wm4> same timestamp
[20:16:50 CEST] <wm4> (oh you said that)
[20:17:11 CEST] <philipl> BtbN: and yet, here we are :-)
[20:17:15 CEST] <wm4> but note that mpv doesn't care about the framerate or tickspersomething fields
[20:17:17 CEST] <jamrial> BtbN: https://www.youtube.com/watch?v=27zvYGSGrng mind, this is with high end cards
[20:17:52 CEST] <jamrial> nevcairiel: there's a Quake port in Vulkan :D
[20:18:59 CEST] <philipl> BtbN: I also have a challenge with my display running at 60Hz so these samples are juddery even when they're correct :-)
[20:20:26 CEST] <philipl> BtbN: If I force the fps to 60 in mpv (which means ignoring timestamps altogether), the two samples look about equivalent.
[20:20:43 CEST] <philipl> There's a little bit of hitching in different places in each one, but I think that's just deint limitations.
[20:21:00 CEST] <philipl> You've got the frames and it is deinterlacing them
[20:23:43 CEST] <BtbN> In MPC-HC both play at a smooth 50 FPS
[20:23:51 CEST] <BtbN> but the cuvid one looks choppy, like it's just 25FPS
[20:24:04 CEST] <BtbN> no interlacing artifacts, just not like 50 fps
[20:24:35 CEST] <philipl> So, if we believe mpv when it complains about timestamps not changing, is MPC-HC showing both frames 'at the same time'
[20:24:39 CEST] <philipl> so it looks choppy.
[20:24:58 CEST] <philipl> If you force it to ignore pts and do 50, does it look right?
[20:25:02 CEST] <philipl> That's my experience here.
[20:25:07 CEST] <BtbN> I don't think it can do that.
[20:26:34 CEST] <philipl> This also complains about pts not advancing: ffmpeg -debug_ts -i deint_cuvid_adaptive.mkv -map 0:0 -f null -
[20:27:57 CEST] <philipl> and if I look at that log, the decoder is reporting each pair of frames with the same pts.
[20:28:48 CEST] <BtbN> i printed the outgoing pts
[20:28:54 CEST] <BtbN> and it goes 0, 20, 40, ...
[20:29:20 CEST] <BtbN> https://bpaste.net/show/a664f243a511
[20:32:44 CEST] <philipl> https://bpaste.net/show/fbb892b09a00
[20:33:39 CEST] <philipl> Is your output from the actual encode or from a playback? Obviously mine is the playback
[20:34:01 CEST] <philipl> also debug_ts is from outside the decoder and something could be mangling it between you and the debug line
[20:35:31 CEST] <JEEB> yeah, ffmpeg.c has a whole lot of mangling there
[20:35:50 CEST] <JEEB> debug_ts just gives you hints whereabouts things are hitting the fan
[20:35:57 CEST] <BtbN> philipl, it's from debug logs is put into cuvid
[20:37:48 CEST] <philipl> BtbN: so. this is potentially confusing. to be clear, that debug log is me playing back your file without me using cuvid.
[20:37:58 CEST] <philipl> it is the file that is dodgy.
[20:38:13 CEST] <BtbN> But encoding it looks fine
[20:39:04 CEST] <philipl> yes. i believe the frame contents are right.
[20:39:14 CEST] <philipl> just these timestamps.
[20:39:52 CEST] <philipl> i havent tried looking at the raw mkv timestamps, but someone should.
[20:42:00 CEST] <BtbN> it's definitely something in ffmpeg.c if it's wrong
[20:43:30 CEST] <philipl> yes. i think youre doing it right in cuvid.c
[20:44:09 CEST] <nevcairiel> Like I said earlier, its likely not an expected or supported scenario for the decoder to change the framerate
[20:44:35 CEST] <BtbN> it doesn't change it.
[20:44:47 CEST] <BtbN> It detects it as 50fps right from the beginning
[20:45:11 CEST] <nevcairiel> but the actual frame rate is defined by the container timestamps =p
[21:08:00 CEST] <jamrial> ubitux: i think i fixed fate-copy-trac236, so two failing tests now
[22:07:07 CEST] <BtbN> philipl, https://gist.github.com/BtbN/4e291c9bbf39158094c7b8f38c2bbd44
[22:07:12 CEST] <BtbN> forgot to paste that
[22:10:06 CEST] <BtbN> The issue is quite obvious. Look at the time_base the encoder gets
[22:10:21 CEST] <BtbN> it's 1/25, so the timestamps have no way to advance in 1/50 of a second steps
[22:20:00 CEST] <BtbN> I guess it just takes the original framerate it got from the demuxer, inverts it to 1/25, and uses it as time_base?
[22:21:56 CEST] <Chloe> does ffmpeg have a list of internal AVCodecTags somewhere? I cant seem to find it
[22:26:14 CEST] <philipl> BtbN: indeed.
[22:28:00 CEST] <durandal117> Chloe: each container have own set of tags
[22:28:18 CEST] <BtbN> I'll just write the raw h264, and re-read it at a given rate. That should at least give me a file with the propper framerate
[22:28:41 CEST] <Chloe> durandal117: oh right :s
[22:28:42 CEST] <philipl> Yep. That'll prove your part is working.
[22:28:56 CEST] <Chloe> trying to map up CMFormatDescriptions to AVCodecIDs
[22:29:20 CEST] <philipl> wm4: So this cuvid deinterlacing thing. I'll need to pass a user flag through to it. What's the preferred way to pass decoder options in mpv?
[22:30:13 CEST] <BtbN> ok, doesn't work. the raw h264 muxer barfs on the invalid timestamps
[22:30:28 CEST] <BtbN> so raw yuv it is
[22:30:33 CEST] <BtbN> also complains, but doesn't abort
[22:30:58 CEST] <wm4> philipl: --vd-lavc-o=key1=val1,key2=val2
[22:31:51 CEST] <philipl> wm4: thanks. works as advertised.
[22:32:13 CEST] <philipl> appropriate to document where the hwdec is documented?
[22:33:09 CEST] <wm4> hm, probably
[22:33:39 CEST] <BtbN> philipl, I think it should be safe to merge the cuvid changes
[22:33:58 CEST] <BtbN> they have no effect on anything using the old API, so, everything
[22:34:58 CEST] <philipl> I believe it.
[22:35:04 CEST] <philipl> except mpv
[22:35:07 CEST] <philipl> where it seems to work
[22:35:23 CEST] <nevcairiel> your screwed up timestamps sound too broken to be worth merging, to be honest
[22:35:30 CEST] <nevcairiel> a known broken thing is always iffy :p
[22:35:38 CEST] <BtbN> The timestamps coming out of cuvid are fine
[22:35:44 CEST] <nevcairiel> people use it and expect it to be fine
[22:35:54 CEST] <philipl> with weave it still works as it yesterday
[22:35:54 CEST] <kierank> atomnuker: what were the problems again with your laptop?
[22:35:57 CEST] <BtbN> it's ffmpeg.c, with a bunch of unofficial patches to use the new API, that messes them up
[22:36:14 CEST] <BtbN> current ffmpeg.c can't even attempt to deinterlace
[22:39:13 CEST] <philipl> BtbN: anyway, you get a Ship It(tm) from me, for whatever it's worth.
[22:39:28 CEST] <philipl> just remember to include the flush fix. :-)
[22:39:37 CEST] <BtbN> The one just adding the new API is definitely fine
[22:39:37 CEST] <wm4> so what's the deal with the timestamps?
[22:39:49 CEST] <BtbN> wm4, the decoder doubles the frames for deinterlacing
[22:39:59 CEST] <BtbN> but with a 1/25 timebase you have kind of an issue for 50fps
[22:40:18 CEST] <BtbN> and the decoder can't influence the timebase
[22:40:31 CEST] <nevcairiel> personally i think that has no place in a decoder anyway :d
[22:40:41 CEST] <BtbN> in fact, the timebase the decoder gets is fine, it's 1/1000
[22:40:53 CEST] <BtbN> but ffmpeg.c mangles it, and converts to 1/25 for the encoder/muxer
[22:42:05 CEST] <BtbN> well, don't really have another choice
[22:42:17 CEST] <BtbN> unless I implement yadif in CUDA
[22:50:56 CEST] <philipl> BtbN: and as intellectually interesting as that might be, it's a waste of CPU and GPU resources vs the hardware deinterlacer.
[22:51:26 CEST] <BtbN> Is it even an actual hardware deinterlacer?
[22:51:34 CEST] <BtbN> Or just a CUDA kernel?
[22:52:15 CEST] <BtbN> testing yuv output is currently paused, I have to me 1.9T or trash to another hdd first...
[22:52:22 CEST] <BtbN> And mv won't free up any space until it's done.
[22:52:31 CEST] <BtbN> *to move
[22:52:33 CEST] <Chloe> if anyone is interested: CoreMediaIO device (wip) https://0x0.st/SDm.patch
[22:54:25 CEST] <Chloe> Works for extracting DV from camcorders at the moment
[22:54:36 CEST] <Chloe> It leaks, a lot, though.
[22:57:59 CEST] <Chloe> It's a little tricky though, because it can output three main 'types' of media: muxxed, audio, video, and other (text, subs etc). I figured the latter three would be the easiest to handle--I don't think my current method of getting the codecId is particularly reliable, but I'm not sure how else it could be done
[23:03:53 CEST] <philipl> BtbN: i think its hardware. its the same thing that vdpau exposes.
[23:04:14 CEST] <BtbN> I wouldn't be surprised if it's just done on GPU cores
[23:04:31 CEST] <BtbN> it's a task they are actually good at, not like video decoding.
[23:11:51 CEST] <philipl> despite that, i dont see any established cuda deinterlacing projects.
[23:13:35 CEST] <JEEB> that's because good things like that are hard to make, and thus it most often is just simpler to use the CPU-using stuff and/or improve it
[23:16:12 CEST] <philipl> fair point.
[23:19:28 CEST] <JEEB> I think the only widely used thing with gpu computing used that's related is NNEDI, that got an opencl version I think
[23:21:17 CEST] <philipl> https://www.researchgate.net/publication/263858534_GPU-Parallel_Implementation_of_the_Edge-Directed_Adaptive_Intra-Field_Deinterlacing_Method
[23:21:33 CEST] <JEEB> academia is academia
[23:22:11 CEST] <JEEB> of course, useful things should be picked out of academia, but just saying that it might not be a realistic implementation
[23:24:04 CEST] <philipl> i wouldn't expect it to be. but just reinforcing that its not really credible to write one in preference to using the hardware
[23:35:40 CEST] <BtbN> philipl, cuvid -> raw yuv -> hevc_nvenc
[23:35:47 CEST] <BtbN> looks perfect
[23:36:17 CEST] <philipl> jolly good
[23:37:06 CEST] <Chloe> Is anyone interested in low level device access on OSX?
[23:37:42 CEST] <Chloe> Wondering if I should even be adding this as a device, and not just as a separate stream ripper or something
[23:40:26 CEST] <BtbN> I wonder what nvenc hevc is doing though
[23:40:33 CEST] <BtbN> it's only like 2MB smaller than h264
[23:40:37 CEST] <BtbN> at the same quality level
[23:41:17 CEST] <nevcairiel> hevc is designed for 4k, you might see more savings there
[23:41:44 CEST] <BtbN> Or nvenc hevc is just bad.
[23:41:50 CEST] <BtbN> Which isn't too unlikely.
[23:41:55 CEST] <nevcairiel> not to mention that all nvenc is really strongly focused on streaming usage, in-home or twitch or whatever, so efficient file storage is not its goal
[23:42:13 CEST] <nevcairiel> ie nvenc hevc doesnt even support b frames
[23:42:26 CEST] <BtbN> I would have hoped that it still manages to be more efficient than h264
[23:42:44 CEST] <BtbN> Would be a nice intermediate protocol for streaming then
[23:56:17 CEST] <BtbN> Well, i managed to patch ffmpeg for it to work without that intermediate step.
[23:57:11 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/f6e0941a98de3ea78c817d3788a5c2ca40d6b4be
[23:58:09 CEST] <nevcairiel> arbitrarily increasing the timebase can have other negative effects though, as that might also get written to a file and then it may think its 100 fps instead of 25 :D
[23:58:19 CEST] <BtbN> I'm not too serious with that patch
[23:58:36 CEST] <BtbN> it just gets the job done for now
[23:59:11 CEST] <philipl> amusing.
[23:59:33 CEST] <BtbN> the only real solution I see is making ffmpeg aware of framerate-changes from the decoder
[00:00:00 CEST] --- Mon Sep 19 2016