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

[burek]

[00:27:59 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:b0d8b7cb8e86: avformat/mov: Do not use reference stream in mov_read_sidx() if there is no reference stream
[00:44:42 CET] <cone-124> ffmpeg 03Timo Rothenpieler 07master:9e1e5213933d: avutil/cuda_check: fix usage of removed .c file
[10:32:39 CET] <OmniBlade> Hello, I'm trying to add support to the aud demuxer for a pcm format found in the Blade Runner game, but I'm having trouble correctly returning an end of data state.
[10:33:24 CET] <JEEB> AVERROR_EOF?
[10:34:00 CET] <OmniBlade> I'll give that a try, I take it I should return that when I know I have no more data to read
[10:38:01 CET] <OmniBlade> Thanks, tha appears to have solved the issue.
[10:38:50 CET] <OmniBlade> How do I go about submitting a patch, generate a patch set with git and then submit to the mailing list for review?
[10:39:48 CET] <JEEB> commit changes as usual, create format-patch and either use git send-email or attach the patch to a mail that you send to ffmpeg-devel at ffmpeg.org
[10:40:05 CET] <JEEB> format-patch is basically a patch that contains commit info
[10:40:18 CET] <JEEB> if it's multiple patches you can mkdir -p my_patch_set
[10:40:34 CET] <JEEB> and then git format-patch master..HEAD -o my_patch_set/
[10:40:51 CET] <OmniBlade> With each patch being a commit?
[10:41:00 CET] <JEEB> format-patch does that yes
[10:41:13 CET] <JEEB> you get 0001-*.patch, 0002-*.patch etc
[10:42:13 CET] <OmniBlade> Okay, thanks. I was planning to add a muxer for aud and extending the adpcm encoder to write the stream that it expects at some point as well.
[10:43:23 CET] <JEEB> you can see the documentation on git format-patch and send-email if  you want. the --help output of at least format-patch seems pretty good
[17:42:44 CET] <BBB> I'm using an older version for something and I get this message "Past duration 0.999992 too large", what does it mean?
[17:43:37 CET] <durandal_1707> which container?
[17:43:58 CET] <BBB> ivf
[17:46:50 CET] <durandal_1707> huh? it should not be present there afaik
[17:48:26 CET] <durandal_1707> some vfr/cfr nonsense
[18:15:45 CET] <nevcairiel_> JEEB: afaik US CC can have language codes, but its independent of the CC track, and instead shipped in some metadata in the TS container
[18:16:03 CET] <nevcairiel_> i remember seeing something a bout that from work
[22:00:02 CET] <JEEB> nevcairiel_: ok, so if you only transfer the cc packets it's not gonna be there
[22:09:46 CET] <kepstin> BBB: usual case where I see that is when the output on a filter chain is set to cfr, but the pts values on the frames are closer together than that (higher framerate). Some frames will be dropped in this case.
[22:10:35 CET] <kepstin> an easy way to trigger it is to use the concat filter, with the first input being lower framerate than the second - concat sets its output to the framerate of the first input, so everything gets messed up when it passes through frames from the second.
[22:10:58 CET] <kepstin> (that's a bug in the concat filter, it should just set the output framerate to undefined in that case)
[00:00:00 CET] --- Sat Feb 16 2019