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

[burek]

[03:51:09 CEST] <cone-264> ffmpeg 03James Almer 07release/3.1:a9c1ef262636: avcodec/bitstream_filters: check the input argument of av_bsf_get_by_name() for NULL
[03:51:09 CEST] <cone-264> ffmpeg 03James Almer 07release/3.2:ecafc4af95b4: avcodec/bitstream_filters: check the input argument of av_bsf_get_by_name() for NULL
[03:51:09 CEST] <cone-264> ffmpeg 03James Almer 07release/3.3:660e4c0c961c: avcodec/bitstream_filters: check the input argument of av_bsf_get_by_name() for NULL
[03:51:10 CEST] <cone-264> ffmpeg 03James Almer 07release/3.4:bc2301429e9c: avcodec/bitstream_filters: check the input argument of av_bsf_get_by_name() for NULL
[03:51:12 CEST] <cone-264> ffmpeg 03James Almer 07release/4.0:9cc5337247b2: avcodec/bitstream_filters: check the input argument of av_bsf_get_by_name() for NULL
[10:20:12 CEST] <JEEB> michaelni: https://patchwork.ffmpeg.org/patch/9836/ I don't /think/ there are any other ISMV tests, and I checked that all changed tests' results seem to make sense (the three updated ones were just the version value of that one box, no other values were changed)
[10:20:19 CEST] <JEEB> boxdumper <3
[20:06:44 CEST] <philipl> BtbN: For when you get back, I created a PR for the new SDK stuff.
[20:07:11 CEST] <BtbN> Can't really accept PRs, as it will get overwritten by the mirror script, but I'll look into it.
[20:08:47 CEST] <philipl> Fair. Can I push to videolan for this repo? I've never tried. If you're ok with it, I'll try and push it
[20:08:47 CEST] <BtbN> Did the nvenc header really not change at all?
[20:08:53 CEST] <philipl> It did not. I did a careful diff.
[20:09:12 CEST] <BtbN> Yeah, pushing to videolan will end up on github automatically.
[20:09:37 CEST] <philipl> They added a name to that anonymous inner struct in the vp8 params, which was nice, after all the problems I had setting it. Can't use it until we drop old SDK support of course.
[20:10:33 CEST] <BtbN> Patch looks fine to me, feel free to push it to the videolan repo
[20:10:47 CEST] <philipl> Done. It worked.
[21:07:21 CEST] <philipl> n
[22:12:58 CEST] <Robert34> Hi, I use avcodec_decode_audio4 on raw aac frames. The resulting AVFrame struct always has nb_samples == 1024. This is wrong, since only the average is 1024 samples/frame, any ideas?
[22:16:02 CEST] <rcombs> nope, that's how many samples in a (LC or similar-profile) AAC frame
[22:20:36 CEST] <Robert34> Then how is it possible that the 'stts' atom doesn't only contain 1024 samples/frame?
[22:20:57 CEST] <kierank> what does it say
[22:21:20 CEST] <kierank> 1024 is correct
[22:23:51 CEST] <Robert34> 242 f with 1024; 1 f with 384; 2 f with 1024; 1 f wit 1280; 1 f with 1056; 80 f with 1024;  ........... and so on, the average is indeed 1024, but some have more or less
[22:24:04 CEST] <kierank> buggy mux
[22:24:42 CEST] <Robert34> ?
[22:26:25 CEST] <Robert34> I am trying to restore the 'stts' table and therefore need those "wrong" values. Otherwise the audio is out of sync with video
[22:27:52 CEST] <Robert34> there are even frames which have 351232 samples
[22:33:46 CEST] <nevcairiel> aac frames always have 1024 samples, or 960 in those profiles
[22:34:01 CEST] <nevcairiel> there is no way around that
[22:37:11 CEST] <Robert34> But there must be a way to manually count the samples in one frame, right?
[22:39:13 CEST] <Robert34> What would be the purpose of the 'stts' table if all frames really contain 1024 samples?
[22:44:19 CEST] <kierank> could have formats (e.g opus) which are variable
[22:53:48 CEST] <Robert34> So I gues it's sort of a cheap hack from the encoder to keep the audio and video in sync?
[22:54:12 CEST] <Robert34> the codec of my file is AAC LC
[22:58:11 CEST] <kierank> looks like a corrupt file
[23:01:23 CEST] <Robert34> it's the recording of a .m3u live stream. So if the network does not deliver audio it kind of makes sense to put "fake" samples into the stts. But that also means there is no way to recover them...
[00:00:00 CEST] --- Mon Jul 30 2018