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

[burek]

[04:54:41 CEST] <atomnuker> why the hell is av_rescale_q outputting INT64_MIN? this makes no sense, all my timebases are in order and my timestamps are fine, monotonically incrementing
[04:59:53 CEST] <atomnuker> oh come on, swr_next_pts() requires input tb of 1/in_rate*out_rate, and if in_rate == out_rate == 48000 the result overflows the AVRational int and becomes negative
[05:10:59 CEST] <atomnuker> and now pulseaudio is giving me non-monotonic timestamps despite I explicitly asking it to give me monotonic timestamps
[05:11:15 CEST] <atomnuker> audio timestamps are hell
[05:22:21 CEST] <atomnuker> ^^ I'm using nut, my timestamps are in microseconds from av_gettime, my timebase is in miscroseconds, nothing complains, and I'm still getting junk timestamps
[07:18:52 CEST] <kierank> atomnuker: remember when I told you libswr was crap
[07:19:27 CEST] <atomnuker> yes, and I still say you're wrong and you wish it was crap!
[07:19:48 CEST] <atomnuker> its well designed, and it does make sense for the tb to be the common multiple of the samplerates
[07:19:50 CEST] <kierank> 10:59:54 AM <"atomnuker> oh come on, swr_next_pts() requires input tb of 1/in_rate*out_rate, and if in_rate == out_rate == 48000 the result overflows the AVRational int and becomes negative
[07:19:53 CEST] <kierank> lol
[07:20:00 CEST] <atomnuker> are you even reading?!?
[07:20:09 CEST] <atomnuker> I was complaining about avrational using ints rather than 64bit ints
[07:20:13 CEST] <kierank> so you've got to come up with some new random timebase
[07:20:19 CEST] <kierank> instead of the one you get from a file
[07:20:49 CEST] <atomnuker> its not random, its the common one between both samplerates
[07:21:18 CEST] <atomnuker> to get what you need you divide what you get by the other samplerate
[11:14:46 CEST] <niemand> Hi, I want to write a filter which duplicates frames if a certain condition applies. Is there a way to access the previous frame from inside the filter_frame function?
[11:25:18 CEST] <durandal_1707> niemand: only by caching it
[11:26:18 CEST] <niemand> durandal_1707, okay :/, thanks. Do you know an existing filter that does that?
[11:27:45 CEST] <durandal_1707> tmix,reverse,atadenoise ...
[11:28:01 CEST] <niemand> thanks, I will look at them
[11:28:07 CEST] <atomnuker> its not hard, just av_frame_ref() the current frame to your context and then move the ref if you want to duplicate it to a new frame
[11:28:22 CEST] <atomnuker> make sure to unref the frame you're replacing so you don't leak
[13:09:55 CEST] <January> atomnuker: why are you using microsecond timebase if youre using NUT
[13:10:24 CEST] <January> Just use the native timebase from each stream?
[13:15:19 CEST] <JEEB> I think he just wants to use current timestamp I guess
[16:19:00 CEST] <JEEB> fun
[16:19:09 CEST] <JEEB> sure seems to be plenty of API changes in vmaf
[17:57:33 CEST] <c3r1c3-Win> When it comes to multi-threading codecs in FFMPEG is there any criteria or rules or minimum gains that must be exhibited for a patch to be considered?
[17:58:17 CEST] <thardin> some sensible amount of speedup perhaps?
[17:58:36 CEST] <thardin> like if you add three extra cores but only get 10% faster then maybe that's not so useful
[17:59:22 CEST] <JEEB> also the added complexity I guess
[17:59:23 CEST] <c3r1c3-Win> ^ Yes, I'm looking for something along those lines.
[18:00:39 CEST] <c3r1c3-Win> If it doesn't exist, I completely understand, and will attempt to do so and publish my tests/findings, but if there are any guidelines/docs/criteria about, I'd love to read them before starting so I can provide proper test coverage.
[18:02:39 CEST] <atomnuker> if you do frame threading you can't really lose out on performance or make things more complex
[18:03:02 CEST] <atomnuker> slice threading should do well too, but combining them is sketch territory as only vp9 does that currently
[18:03:08 CEST] <c3r1c3-Win> I think it would be frame slices first (and possibly only).
[18:03:17 CEST] <atomnuker> which codec?
[18:03:36 CEST] <c3r1c3-Win> Also if I were to multi-thread the compressor and decompressor, should those be submitted as 2 patches or 1?
[18:03:42 CEST] <nevcairiel> 2
[18:03:50 CEST] <c3r1c3-Win> Excellent. Thank you.
[18:04:29 CEST] <c3r1c3-Win> atomnuker: I'm actually pulling up the source code right now to look, but I was thinking SpeedHq (if it isn't already).
[18:04:41 CEST] <atomnuker> we have a speedhq encoder?
[18:04:42 CEST] <c3r1c3-Win> I figured that would be a good start for me.
[18:07:10 CEST] <c3r1c3-Win> I only see a decoder.
[18:10:15 CEST] <c3r1c3-Win> Interesting, given that NDI uses SpeedHQ as it's codec...
[19:40:07 CEST] <Compn> c3r1c3-Win : do you have NDI source / spec ? 
[19:40:17 CEST] <Compn> its possible that no one really asked us to do a speedhq encoder,
[19:40:26 CEST] <Compn> e.g. apple prores was infininitely more popular 
[20:42:09 CEST] <cone-043> ffmpeg 03Mark Thompson 07master:7ff5310068d9: hwcontext_opencl: Remove unused variable
[20:42:09 CEST] <cone-043> ffmpeg 03Mark Thompson 07master:d4d29052c3ce: lavfi/framesync: Add namespace prefix to framesync_get_class
[20:44:26 CEST] <cone-043> ffmpeg 03Marton Balint 07master:bfa0b5044178: avformat/mxfdec: store next_klv in KLVPacket
[20:44:27 CEST] <cone-043> ffmpeg 03Marton Balint 07master:7ec90b168b9a: avformat/mxfdec: add support for determining essence wrapping scheme
[20:44:28 CEST] <cone-043> ffmpeg 03Marton Balint 07master:3cb19ba97e68: avformat/mxfdec: add some essence container uls from SMPTE draft
[20:44:29 CEST] <cone-043> ffmpeg 03Marton Balint 07master:459282389c40: avformat/mxfdec: extend mxf_handle_missing_index_segment for all clip wrapped essences
[20:44:30 CEST] <cone-043> ffmpeg 03Marton Balint 07master:6345770eeb97: avformat/mxfdec: compute both essence_offset and essence_length in mxf_compute_essence_containers
[20:44:32 CEST] <cone-043> ffmpeg 03Marton Balint 07master:f217be2cb8d0: avformat/mxfdec: simply use the first essence element for non frame-wrapped partition essence offset
[20:44:33 CEST] <cone-043> ffmpeg 03Marton Balint 07master:ae64c682084b: avformat/mxfdec: make edit_units_per_packet a track property
[20:44:33 CEST] <cone-043> ffmpeg 03Marton Balint 07master:1cea0e73d2b7: avformat/mxfdec: make current_edit_unit a parameter of mxf_compute_samples
[20:44:34 CEST] <cone-043> ffmpeg 03Marton Balint 07master:e7b1a8371878: avformat/mxfdec: add support for returning the partition for mxf_edit_unit_absolute_offset and mxf_absolute_bodysid_offset
[20:44:35 CEST] <cone-043> ffmpeg 03Marton Balint 07master:865e0c2d66d9: avformat/mxfdec: compute sample_count for all streams on seek
[20:44:37 CEST] <cone-043> ffmpeg 03Marton Balint 07master:404dc6bab5cd: avformat/mxfdec: avoid index_table->nb_ptses overflow in mxf_compute_ptses_fake_index
[20:56:35 CEST] <atomnuker> jkqxz: ping, could you look at my lavfi vulkan filters, I fixed the issues with the hwcontext
[21:00:30 CEST] <jkqxz> Not easily right now - I'm currently away from most of my test kit.
[21:03:09 CEST] <jkqxz> Well, I can have a look.  Not much testing though.
[21:20:03 CEST] <atomnuker> oh, ok, whenever you can then
[22:19:54 CEST] <kierank> c3r1c3-Win: you should reverse engineer nda
[22:19:55 CEST] <kierank> ndi
[22:20:00 CEST] <kierank> and i think they are moving to h264
[22:20:49 CEST] <JEEB> how utterly not surprising :)
[22:21:15 CEST] <JEEB> and yea I really dislike how they're calling themselves a standard while there's no spec nor an open implementation
[22:21:33 CEST] <JEEB> I'd expect at least one thing of those as a "standard"
[00:00:00 CEST] --- Mon Jun 25 2018