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

[burek]

[01:53:29 CEST] <cone-047> ffmpeg 03Peter Ross 07master:b12432721611: fate: add dst decoder test
[15:12:10 CEST] <cone-931> ffmpeg 03Zhong Li 07master:ef56c28b2596: lavf/qsvvpp: add extra_hw_frames support
[15:12:11 CEST] <cone-931> ffmpeg 03Zhong Li 07master:e62f625163f8: lavf/qsvvpp: add P010 output format support
[17:22:17 CEST] <jamrial> jkqxz, BtbN, philipl: i just finished implemented the encode api equivalent of 061a0c14bb
[17:22:48 CEST] <jamrial> and i need your help adapting the existing encoders using the decoupled api callbacks. nvenc, vaapi, amf, etc
[17:24:51 CEST] <BtbN> Should be straight forward for nvenc at least. No idea about the others.
[17:25:30 CEST] <BtbN> Though it's probably going to end up with the awkward constructs it claims to avoid, since nvenc actually works pretty well with the current design.
[18:23:29 CEST] <jamrial> jkqxz, BtbN, philipl: https://github.com/jamrial/FFmpeg/commits/encode_api if you want to take a look
[18:24:45 CEST] <jamrial> BtbN: i implemented it for the librav1e patch on the ml, and it wasn't awkward, so dunno
[18:25:25 CEST] <philipl> looking
[18:34:23 CEST] <jamrial> the main benefit with this change is that we can remove the fallback encode2 callback implementations in all these encoders, since now those using only the receive_packet callback will also work for people still using avcodec_encode_video2()
[18:38:31 CEST] <Lynne> I don't get it
[18:39:50 CEST] <Lynne> its just encode2() but you need to call a function to get a frame/packet
[18:41:39 CEST] <Lynne> the new api was meant to simplify async-like encoders and decoders, this just makes it more like the old api
[18:43:12 CEST] <nevcairiel> its capabilities are still quite the same, an encoder can consume any number of frames through the request api, and produce as many as it likes
[18:44:45 CEST] <nevcairiel> the really big difference is in the external API
[18:44:56 CEST] <nevcairiel> could've done the same with encode2 by just re-definining it slightly
[18:47:30 CEST] <nevcairiel> but I don't see how people calling avcodec_encode_video2 could use encoders that use the new API, at least if an encoder actually produces more packets then input frames, say for example interlaced encoding with one packet er field
[18:48:18 CEST] <philipl> Presumably it should fail? On the decode side, a decoder that only supports the new API will fail to work with the old decode API
[18:48:56 CEST] <Lynne> if this was done for backwards compatibility, why? the old api will be removed eventually, this is just a stopgap for a year or two
[18:49:31 CEST] <nevcairiel> for decoders people considered this easier to work with in the decoder themselves
[18:49:39 CEST] <nevcairiel> so presumably the same would be true for encoders
[18:49:57 CEST] <nevcairiel> it gets to decide to  request a new frame itself, instead of relying on the external callback to be called
[18:50:03 CEST] <nevcairiel> its just a bit more explicit
[18:52:03 CEST] <nevcairiel> one entry point to drive the logic, instead of two that somehow interact
[18:53:09 CEST] <jamrial> Lynne: the decode and encode2 callbacks are left alone to prevent having to rewrite a hundred or so decoders/encoders
[18:53:50 CEST] <jamrial> the old encode public functions can be removed after the above commits, as the internal callbacks are not related to them anymore
[18:54:20 CEST] <jamrial> the old decode functions could be removed right now for the same reason, but i don't see that happening anytime soon
[18:54:41 CEST] <jamrial> i don't know how many library users already ported their code to send/receive
[18:59:58 CEST] <Lynne> well they can't be removed until the bump, but I don't see how the commit helps
[19:20:24 CEST] <jamrial> Lynne: if you look at the current code you'll notice that the avcodec_send_frame() and avcodec_receive_packet() functions are calling avcodec_encode_video2() and avcodec_encode_audio2() for encoders using the encode2 callback
[19:20:44 CEST] <jamrial> the above patches makes them instead call the callback directly
[19:24:53 CEST] <jamrial> actually, even after those patches the old functions couldn't be removed, because the frame threading code for some reason uses them...
[19:47:49 CEST] <Lynne> ah, I see
[19:56:36 CEST] <maxine> hi, i was just wondering, if i wanted to contribute a patch that fixes mkv encoding of webvtt subs (https://trac.ffmpeg.org/ticket/5641) would it be better to preserve its ability to recognise the webm style stuff or simply drop it in favour of what the matroska spec says?
[21:36:11 CEST] <cone-207> ffmpeg 03Stephan Hilb 07master:1954161628ab: avformat/nut: add cpia codec
[22:57:48 CEST] <jdarnley> maxine: usually ffmpeg strives to maintain reading of "invalid" files
[22:59:34 CEST] <maxine> so the old behaviour should be preserved, ok. thanks!
[23:12:06 CEST] <cone-207> ffmpeg 03Paul B Mahol 07master:80e68ce11686: avfilter/vf_normalize: fix filtering of RGB0 formats
[23:23:10 CEST] <j45> maxine, jdarnley: the ticket references encoding and decoding, but maxine's question appears to be about *encoding*.  seems if the question as stated is what was intended, then the question is do you want ffmpeg to preserve *writing* invalid files? 
[23:23:57 CEST] <jdarnley> Probably not by default.
[23:24:01 CEST] <maxine> j45: actually, i did mean decoding of webm style encoded matroska files.
[23:24:08 CEST] <maxine> sorry for not being clear
[23:24:11 CEST] <jdarnley> There us the "strict" option for that
[00:00:00 CEST] --- Tue Jun 11 2019