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

[burek]

[01:13:04 CET] <cone-371> ffmpeg 03Mark Thompson 07master:d40a1ae7ecfe: vaapi_mpeg4: Restore changes overwritten by merge
[02:16:46 CET] <kierank> michaelni: which function do I use for rice code type 000001
[02:17:27 CET] <kierank> well unary coded part to be more precise
[02:20:53 CET] <kierank> ah it's in unary.h
[02:20:54 CET] <kierank> ...
[02:27:33 CET] <michaelni> i see you already found it ...
[02:31:02 CET] <cone-371> ffmpeg 03Michael Niedermayer 07master:0a5add45c752: avfilter/af_hdcd: Fix leak of memory allocated by ff_make_format_list()
[02:31:03 CET] <cone-371> ffmpeg 03Jonathan Campbell 07master:76c5a69e26af: libavutil: add av_lfg_init_from_data() function
[02:31:04 CET] <cone-371> ffmpeg 03Jonathan Campbell 07master:d5d474aea538: avcodec/ac3dec: add consistent noise generation option.
[02:34:10 CET] <kierank> I guess all the formats have a more fancy rice decode function
[02:34:14 CET] <kierank> let's write it naively first
[03:12:54 CET] <kierank> michaelni: don't know if I am missing something here but does it say anywhere what the length of dpcm_residual is?
[03:41:31 CET] <kierank> I'm guessing it should read 8-12?
[03:41:41 CET] <kierank> in 14496-2
[03:50:08 CET] <Cloudef> debianuser: https://www.youtube.com/watch?v=6T0iuFc15xI here is test from my gl capture thing I mentioned other day. I ended up writing my own raw container format
[03:50:24 CET] <Cloudef> It's encoded on the fly at 60fps to tmpfs with ffmpeg
[11:54:53 CET] <durandal_1707>  gonna push sds demuxer
[12:11:36 CET] <atomnuker> durandal_1707: yeah, it looks good to me
[12:48:38 CET] <debianuser> Cloudef: Looks good! Have you added support for your own container to ffmpeg? Or were you calling ffmpeg funcs from your own container parser?
[13:02:08 CET] <cone-173> ffmpeg 03Paul B Mahol 07master:7f9978b0bdfc: avformat: add MIDI Sample Dump Standard demuxer
[13:12:43 CET] <atomnuker> holy crap exp2 is so slow, doing it 30 odd times in a 2.5 ms frame takes about as long as the fft
[14:13:39 CET] <kierank> atomnuker: exp2 or exp2f?
[14:13:48 CET] <kierank> The former is double
[14:25:14 CET] <atomnuker> huh, I was using exp2, not exp2f
[14:25:24 CET] <atomnuker> got rid of it anyway
[14:25:46 CET] <kierank> I mean do you really need double precision
[14:25:49 CET] <kierank> But ok
[14:54:12 CET] <BtbN> wm4, did I interpret that mail right, that you are generally ok with the approach of the cuvid patch, as cuvid isn't a classic hwaccel?
[14:54:29 CET] <BtbN> I don't see an issue with this patch, failing on init whenever possible seems good to me.
[14:54:38 CET] <BtbN> As long as it doesn't introduce false positives.
[14:54:42 CET] <wm4> BtbN: no
[14:54:52 CET] <wm4> that was a reply to myself correcting myself
[14:55:28 CET] <wm4> actually thinking about it again, doesn't ffmpeg.c stop transcoding on decoder errors? (no idea)
[14:55:51 CET] <BtbN> no. If cuvid.c fails during decoding, but init succeeded, ffmpeg.c keeps going forever, but spamming errors.
[14:56:07 CET] <wm4> well then looks like my second suggesting is just the right thing
[14:56:37 CET] <BtbN> Isn't that exactly what this patch does? Return an error if the parameters are known not to work?
[14:57:33 CET] <wm4> no, he tries to move the failure to init by using probed parameters, which is Wrong(tm)
[14:58:01 CET] <BtbN> But decode already does return an error if decoding fails.
[14:58:07 CET] <BtbN> It's just that ffmpeg.c doesn't care.
[14:58:25 CET] <wm4> so because ffmpeg.c doesn't care we need an half-working hack in libavcodec?
[14:59:40 CET] <BtbN> I wonder why ffmpeg.c does keep trying to decode so aggressively
[14:59:56 CET] <BtbN> There should be some logic to make it give up if the last couple hundred frames failed to decode
[15:06:00 CET] <jkqxz> I think it's there to allow you to attach to broadcast streams in the middle, which might be bad for a lot of frames before a synchronisation point comes along which you can actually start decoding properly on.
[15:06:32 CET] <BtbN> so introducing a "fatal" error code there would be a good idea
[15:06:49 CET] <BtbN> To indicate that no matter how many more frames you throw at the decoding, nothing is going to get better
[15:07:03 CET] <jkqxz> Do you have any comment on the pacth adding a device reference to AVCodecContext and codifying the semantics of it?
[15:07:25 CET] <BtbN> Haven't seen that mail yet
[15:07:48 CET] <jkqxz> Unfortunately you wouldn't be able to throw that "fatal" error code in this case, because the stream could change to one which is supported.
[15:09:17 CET] <wm4> just add an "unsupported profile" error code
[15:09:46 CET] <BtbN> I'm not sure if cuvid supports on the fly parameter changes
[15:10:16 CET] <wm4> try one of the resolution change samples
[17:19:08 CET] <gradyplayer> I am working on a ttml encoder for ffmpeg, but currently it needs to work against 2.8 branch... if I am to contribute it, should I make a separate patch for 3.2, or HEAD?
[17:19:49 CET] <BtbN> no new features for anything but master are accepeted.
[17:19:59 CET] <gradyplayer> ok cool
[17:20:18 CET] <gradyplayer> thank you... I can patch my version locally and contribute back to master
[17:20:36 CET] <gradyplayer> also it based on the srt encoder
[17:20:49 CET] <gradyplayer> should I include the author of the srt encoder in the copyright?
[17:22:49 CET] <wm4> if you copied code that would probably be appropriate
[17:22:55 CET] <wm4> whether it's required... probably not
[17:22:59 CET] <cone-962> ffmpeg 03Marton Balint 07master:076fc75bdb8e: ffplay: do not preallocate video texture
[17:22:59 CET] <cone-962> ffmpeg 03Marton Balint 07master:f1214ad5d9ec: ffplay: fix indentation after last commit
[17:23:08 CET] <wm4> as long as the license is compatible
[17:23:35 CET] <gradyplayer> thanks wm4 I think it should be it is ffmpeg / lgpl
[17:24:10 CET] <gradyplayer> libavcodec/srtenc.c
[18:42:55 CET] <philipl> BtbN: this cuvid thing is ugly. For most problems, you do get an error back, either from CreateDecoder or from handle_video_sequence.
[18:43:41 CET] <philipl> There are some problems where it just stalls out. I don't know about his 5k/8k case, but i do know that the chroma subsampling has this problem - which is why I added that explicit check/error logic for it.
[18:44:02 CET] <philipl> but I did that based on the output of the cuvid parser, rather than doing any pre-creation parsing like his patch does.
[18:44:15 CET] <philipl> So the error appears to come from handle_video_sequence
[18:45:34 CET] <Cloudef> debianuser: I added decoder in ffmpeg
[18:46:13 CET] <philipl> and his patch is structurally broken anyway. The code runs at a point where you don't know the input pix fmt.
[18:47:12 CET] <philipl> It may or may not do the right thing with P010/P016 but if it does, it's a coincidence.
[18:49:13 CET] <philipl> and if I remember wm4's point correctly, there's no guarantee that these 'probed' fields are set, depending on what the calling code does.
[18:50:25 CET] <wm4> especially the pixel format
[18:50:37 CET] <wm4> it'll probably always work with ffmpeg.c, though
[18:50:56 CET] <philipl> which, ironically, he doesn't use.
[18:51:22 CET] <wm4> not sure what he uses, I assumed ffmpeg.c?
[18:51:31 CET] <philipl> He said he wrote his own client.
[18:51:44 CET] <wm4> oh
[18:52:02 CET] <wm4> then what jkqxz said could probably apply (if we get so far)
[18:52:19 CET] <philipl> And so the pixel format test is doubly pointless. I already made it error out on decoding the first frame. It just has to deal with that (like you made mpv deal with it).
[18:52:22 CET] <wm4> (which was: add an API that allows you to pre-probe hw decoder compatibility)
[18:52:28 CET] <philipl> Yeah.
[18:53:06 CET] <wm4> philipl: well it can also work if you use libavformat + libavcodec and don't discard the pix_fmt field (i.e. the "lucky combination" this would make work in ffmpeg.c)
[18:54:24 CET] <philipl> in fact, this is all weird. He himself says that createDecoder errors out for too-big resolution, so again, that will show up as a handle_video_sequence failure
[18:57:18 CET] <BtbN> philipl, it reads like the parser never calls the seqeuence callback, and just keeps eating packets, without error
[18:57:50 CET] <philipl> In the case of chroma subsampling, that's true. So I added explicit logic for that.
[18:58:10 CET] <BtbN> also seems to happen for unsupported high resolutions
[18:58:20 CET] <philipl> yes but in that case createDecoder does fail.
[18:58:32 CET] <philipl> So you will get a failure from handle_video_sequence in all his stated cases.
[18:58:39 CET] <philipl> So my question is why not just deal with that.
[18:58:51 CET] <philipl> Sure, it kinda sucks but it's not the end of the world. wm4 handled it.
[18:59:07 CET] <philipl> None of us wants a shitty hack
[18:59:11 CET] <BtbN> philipl, but it never calls handle_video_sequence.
[18:59:14 CET] <BtbN> That's the thing
[18:59:22 CET] <BtbN> the parser seems to know that it's not going to work, so doesn't bother.
[18:59:24 CET] <philipl> That's the part I don't believe.
[18:59:37 CET] <BtbN> I'm downloading the sample he linked right now to test
[18:59:43 CET] <BtbN> not exactly a fast server though
[19:00:17 CET] <philipl> I have 422 and 444 samples here that I test with and I know those errors will fire.
[19:01:41 CET] <philipl> I guess this is a large file sample? It would need to be >8K to fail on pascal :-)
[19:01:46 CET] <wm4> philipl: one thing I'm arguing for is having a special error code that signals this situation
[19:02:00 CET] <philipl> wm4: yeah. we discussed that before, and I agree on that one.
[19:02:16 CET] <philipl> We should return an error that says it's fatal so you can decide whether to retry or not
[19:02:16 CET] <wm4> and I think that's what this person really wants (probably?)
[19:02:33 CET] <jkqxz> I'm already thinking about adding the "test whether decoder/hwaccel might work" API for other purposes.
[19:02:59 CET] <philipl> jkqxz: Who would be responsible for probing sufficiently to have a chance of an accurate test?
[19:03:00 CET] <jkqxz> For decoders it lets you make the choice to use the software decoder instead (which is, I think, what this guy wants).
[19:03:19 CET] <jkqxz> For hwaccels it gives some indication whether the performance will be sane.  (So when someone tries to transcode the worst jellyfish on an Atom you can say "HAHA NOPE".)
[19:03:50 CET] <jkqxz> The user is.  They provide all of the probed parameters, possibly from lavf.
[19:03:56 CET] <BtbN> wm4, I think that person wants to not re-write or add logic in his application, and make ffmpeg behave in his favour instead.
[19:04:27 CET] <philipl> BtbN: yeah. I'm pretty sure that if he could fall back on frame decode errors, he wouldn't have this problem.
[19:04:27 CET] <jkqxz> philipl:  Also, coverity.  Apologies for disappearing last time.  What do I need to do?
[19:04:38 CET] <philipl> jkqxz: tell me your github email.
[19:04:39 CET] <wm4> BtbN: to be fair I'd probably prefer "eager" behavior too, but that's not how this stuff works (and not even hwaccels does)
[19:04:42 CET] <philipl> I'll send you an invite.
[19:04:52 CET] <wm4> you don't get around feeding at least one packet to the decoder before you see whether it's supported
[19:05:01 CET] <BtbN> wm4, I'd be ok with adding the resolution-check, but the pix_fmt one is just a hack.
[19:05:35 CET] <philipl> BtbN: resolution-check is only ok if existing code really leads to createDecoder not being called.
[19:05:42 CET] <jkqxz> philipl:  Same as my ML email, <sw at jkqxz.net>.
[19:05:45 CET] <philipl> ok
[19:07:15 CET] <philipl> jkqxz: hope that worked. Says here that only one sender/recipient combination can be invited per day :-P
[19:10:10 CET] <jkqxz> Got it, thanks.
[19:21:21 CET] <BtbN> The 8K sample is still downloading, at 300kB/s
[19:28:30 CET] <philipl> The patagonia one?
[19:28:33 CET] <philipl> That's on youtube...
[19:28:48 CET] <philipl> ChOhcHD8fBA
[19:28:52 CET] <philipl> youtube-dl etc
[19:31:23 CET] <philipl> Tried it.
[19:31:40 CET] <philipl> vp9 version plays fine, but it is true - the h264 version just silently stalls out. No error, no frames.
[19:36:20 CET] <BtbN> PATAGONIA 8K-ChOhcHD8fBA.mp4
[19:36:21 CET] <BtbN> yes
[19:36:29 CET] <BtbN> still 5 more minutes to go on the download
[19:36:47 CET] <philipl> [download] Destination: PATAGONIA 8K-ChOhcHD8fBA.f138.mp4
[19:36:47 CET] <philipl> [download] 100% of 724.25MiB in 00:57
[19:36:47 CET] <philipl> [download] Destination: PATAGONIA 8K-ChOhcHD8fBA.f140.m4a
[19:36:47 CET] <philipl> [download] 100% of 4.12MiB in 00:00
[19:37:06 CET] <BtbN> [download]  85.9% of 724.25MiB at 426.26KiB/s ETA 04:04
[19:37:11 CET] <philipl> sad panda.
[19:38:48 CET] <philipl> Yeah, so parsing goes into a black hole on the h264 clip
[19:38:51 CET] <philipl> No callbacks ever fire.
[19:40:05 CET] <philipl> How awesome. So we have an error case where CreateDecoder would return an error but the parser falls over so we never call CreateDecoder.
[19:40:37 CET] <philipl> And we have other errors where CreateDecoder doesn't return an error but decoding a frame returns an error
[19:40:57 CET] <philipl> and other errors where nothing fails but the decoded frame is garbage (chroma format case)
[19:41:00 CET] <philipl> how fun.
[19:42:21 CET] <BtbN> just the resolution check from his patch seems like an ok workaround for now
[19:59:30 CET] <philipl> wm4: would the resolution check work in mpv? Do the dimensions get filled in?
[20:04:12 CET] <wm4> philipl: probably
[21:40:29 CET] <cone-521> ffmpeg 03Michael Niedermayer 07master:d9d9fd9446eb: avcodec/error_resilience: Optimize motion recovery code by using blcok lists
[00:00:00 CET] --- Mon Jan 23 2017