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

[burek]

[00:01:46 CET] <ubitux> i'm looking for a sample where we get AVFrames with no pts
[00:02:00 CET] <ubitux> (i want to try the genpts flag)
[00:02:33 CET] <ubitux> any suggestion? i tried random avi & others in my small collection but -vf showinfo always shows meaningful pts
[00:02:47 CET] <ubitux> maybe i'm testing it wrong though and ffmpeg is doing smart stuff
[00:03:57 CET] <kierank> michaelni: ok I'll try to split the patches
[00:04:11 CET] <michaelni> kierank, thanks
[00:36:44 CET] <durandal_1707> anyone want to comment swaprect?
[01:03:34 CET] <kierank> michaelni: what sample is that
[01:04:37 CET] <kierank> which crashes
[01:27:26 CET] <michaelni> kierank, see inbox
[01:27:45 CET] <kierank> which email
[01:30:29 CET] <michaelni> hmm <kieran at kunhya.com>: host mx-biz.mail.am0.yahoodns.net[98.139.171.245] said:
[01:30:30 CET] <michaelni>     550 relaying denied for <kieran at kunhya.com> (in reply to RCPT TO command)
[01:31:42 CET] <kierank> yeah can you send to kierank at obe.tv
[01:34:56 CET] <michaelni> sent
[01:56:16 CET] <kierank> michaelni: sent a patch
[02:09:57 CET] <nullp0inter> i am getting the error: "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height" with this command: http://pastebin.com/fLnTMemT Can anyone tell me why it's wrong?
[02:20:48 CET] <J_Darnley> maybe you should post the actual error
[02:21:48 CET] <J_Darnley> It has been years since I first submitted the warning and error highlighting patch and people are still blind to it?
[02:26:51 CET] <nullp0inter> J_Darnley : not sure what you mean by highlighting, but does this help? http://pastebin.com/uuq1adz4
[02:27:18 CET] <J_Darnley> [libx264 @ 0xc8a880] width not divisible by 2 (853x480)
[02:28:48 CET] <J_Darnley> http://ffmpeg.org/ffmpeg-filters.html#scale-1
[02:32:43 CET] <nullp0inter> J_Darnley : testing using a formula and fixed heigh
[02:32:56 CET] <nullp0inter> J_Darnley : ty for the pointer, lets see if i can get this thing to work
[02:33:27 CET] <J_Darnley> "If one of the values is -n with n > 1, the scale filter will also use a value that maintains the aspect ratio of the input image, calculated from the other specified dimension. After that it will, however, make sure that the calculated dimension is divisible by n and adjust the value if necessary."
[02:33:38 CET] <J_Darnley> Hmm I bet that got cut off
[02:33:49 CET] <J_Darnley> "If one of the values is -n with n > 1, the scale filter will also use a value that maintains the aspect ratio of the input image, calculated from the other specified dimension."
[02:33:56 CET] <J_Darnley> "After that it will, however, make sure that the calculated dimension is divisible by n and adjust the value if necessary."
[02:39:30 CET] <nullp0inter> J_Darnley : thats helpful, trying now with -2:480
[02:45:56 CET] <nullp0inter> J_Darnley : that worked! thank you!
[04:04:07 CET] <cone-544> ffmpeg 03Ganesh Ajjanagadde 07master:42868ca569f3: avcodec/jpeg2000: replace naive pow call with smarter exp2fi
[04:04:07 CET] <cone-544> ffmpeg 03Ganesh Ajjanagadde 07master:c8905e0d67f5: swscale/utils: replace pow by exp2
[13:15:15 CET] <cone-442> ffmpeg 03Jean Delvare 07master:e74f1a121e94: avfilter/vf_delogo: round to the closest value
[13:39:11 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:cb93df0dcbd3: avcodec/aacsbr_tablegen: always initialize tables at runtime
[13:58:53 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:00c322014904: lavfi/show_palette: fix memory leak
[13:58:54 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:301c2784b350: lavfi/vf_overlay: fix memory leaks
[13:58:55 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:31f0d555e077: lavfi/vf_alphamerge: fix memory leaks
[13:58:56 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:924fcac52148: lavfi/af_channelmap: fix memory leak
[13:58:57 CET] <cone-442> ffmpeg 03Ganesh Ajjanagadde 07master:89bbf0197819: lavfi/af_amix: fix memory leak
[15:37:34 CET] <ubitux> 15:02 <Mandarinka> [14:43:44 CET] <BBB> nevcairiel: sse2 would be nice to have, but I think the curve of what kind of system has tends to trend towards higher-end, so sse4 baseline may just be ok
[15:37:36 CET] <ubitux> 15:02 <Mandarinka> Ubitux: I saw this in ffmpeg logs
[15:37:38 CET] <ubitux> 15:02 <Mandarinka> Intel didn't enable SSE4 on any of pre-Sandy Bridge Celerons or Pentiums, those were SSSE3-only until 2011. I don't know if it is meaningful to support such dualcores, but they would probably be good for 720p, while higher clocked ones (desktop ones, after OC, particularly the Westmere-based...) could perhaps be still capable of 1080p if they had assembly available.
[15:37:56 CET] <ubitux> 15:07 <Mandarinka> actually 65nm Core 2 also ends on SSEE3, so things like the original Core 2 Quads are in that group
[15:37:58 CET] <ubitux> 15:07 <Mandarinka> which are old but not hopelessly slow IMHO
[15:38:00 CET] <ubitux> 15:07 <Mandarinka> *SSSE3
[15:38:08 CET] <ubitux> just forwarding some follow up.
[15:38:28 CET] <BBB> I actually have one of those rare pre-sandybridge cpus with sse4 :-p
[15:38:45 CET] <BBB> we indeed used ssse3 as baseline for initial vp9 simd
[15:39:06 CET] <BBB> I just dont have a good solution for hevc that does not involve rewriting everything again
[15:39:16 CET] <nevcairiel> sse4 usage is probably just 1-2 instructions that could be macro'ed if someone cared
[15:40:10 CET] <nevcairiel> I would care if i had the time and knowledge to, but time is short enough as it is that I won't be learning this now ;)
[15:45:27 CET] <durandal_1707> anyone still needs hrtf like filter?
[16:28:36 CET] <cone-442> ffmpeg 03Michael Niedermayer 07master:e6971db12b8a: avformat/matroskaenc: Check codecdelay before use
[16:28:42 CET] <wm4> which distros are still Libav only?
[16:30:48 CET] <atomnuker> wm4: none, I think
[16:31:47 CET] <wm4> interesting
[16:57:39 CET] <cone-442> ffmpeg 03Michael Niedermayer 07master:8cfa912e250d: avformat/flacdec: remove unused return code assignment
[17:53:19 CET] <cone-442> ffmpeg 03Michael Niedermayer 07master:bc8b1e694cc3: avutil/mathematics: Fix division by 0
[18:02:35 CET] <ubitux> http://pastie.org/10621149
[18:02:37 CET] <ubitux> erm
[18:03:03 CET] <ubitux> 0 as DBL_MIN is pretty confusing
[18:03:34 CET] <Daemon404> should have printed ah hexfloat duh
[18:04:52 CET] <ubitux> i just realized DBL_MIN is actually strictly positive
[18:27:44 CET] <cone-442> ffmpeg 03Michael Niedermayer 07master:80ceb4696ab7: avformat/rmdec: Fix use of uninitialized variable
[19:03:28 CET] <atomnuker> https://0x0.st/-68.jpg
[19:04:24 CET] <RiCON> trippy
[19:30:38 CET] <J_Darnley> Spooky, scary skeletons with added scary filter!
[19:31:58 CET] <thardin> spoopy
[20:06:26 CET] <cone-442> ffmpeg 03Alex Agranovsky 07master:7fd1c85e5195: lavf/mpjpegdec: Fixed dereference after null check
[20:25:04 CET] <wm4> why even bother with ganesh
[20:39:54 CET] <cone-442> ffmpeg 03Andreas Cadhalpun 07release/2.4:073fcfe35800: mjpegdec: consider chroma subsampling in size check
[20:39:56 CET] <cone-442> ffmpeg 03Michael Niedermayer 07release/2.4:ab70292fd0c3: avutil/mathematics: Fix division by 0
[20:40:52 CET] <fritsch> nevcairiel: any idea when 2.8.4 is tagged - something still missing?
[20:43:30 CET] <michaelni> fritsch, i wanted to do a 2.8.4 release soon, anything you want backported ?
[20:45:15 CET] <fritsch> michaelni: thx for asking. No nothing that comes directly to my mind. There is currently a bug we have reported upstream concerning mp3 breakage with handbrake, but carl is looking after that
[20:45:53 CET] <fritsch> michaelni: perhaps: avformat/utils: estimate_timings_from_pts - increase retry counter, fixes invalid duration for ts files with hevc codec - then we could drop that from our custom patches
[20:46:12 CET] <fritsch> 2d8c2f1a28073d451c7db31291c333cb15ca3d0b that is
[20:47:33 CET] <michaelni> ok, ill backport that
[20:47:56 CET] <michaelni> will also backport it to other releases i maintain i guess unless it breaks something but i dont expect that
[20:49:45 CET] <fritsch> thx, much - the most critical bug, as said - is this mp3 bug: https://trac.ffmpeg.org/ticket/5047 - it seems handbrake produces such files by default
[20:49:52 CET] <fritsch> sadly I could not reach the handbrake maintainer yet
[20:51:21 CET] <Daemon404> fflogger, file it on their bug tracker
[21:38:30 CET] <wkelleher> howdy folks. working on a patch and I'm wondering if anyone can explain why in_picture->pict_type is being cleared during transcoding.
[21:40:01 CET] <wkelleher> I'd like to have pict_type available on the encoder's input AVFrame so I can optionally use it for scene change info
[21:41:00 CET] <nevcairiel> pict_type in encoder input is used by many encoders to force insertion of key-frames at pre-determined points
[21:41:19 CET] <nevcairiel> if every transcode would just blindly forward that info, it would seriously impact the performance of the encoders
[21:42:20 CET] <wkelleher> ok, that makes sense. how about optionally forwarding?
[21:43:03 CET] <Mavrik> Usually you don't want that forwarded at all, since there's no real gain for it, just quality loss.
[21:43:37 CET] <wkelleher> in this case, my encoder can't adaptively place i-frames
[21:43:57 CET] <wkelleher> but my hevc input stream has nice scene detection
[21:44:23 CET] <wkelleher> so I want to use the HEVC I-frame placement as a hint for the H.264 output
[22:37:02 CET] <cone-442> ffmpeg 03Claudio Freire 07master:124c3759386a: AAC encoder: fix OOB access in search_for_pns
[00:00:00 CET] --- Thu Dec 10 2015