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

[burek]

[00:00:04 CET] <atomnuker> avframes carrying hw stuff can't adjust data pointers!
[00:00:17 CET] <atomnuker> so that's why, I take it back, its not that retarded
[00:00:25 CET] <BtbN> Which is why for hwframes cropping is only possible at the right and bottom
[00:01:06 CET] <atomnuker> yep, using the width and height only since you can't touch the data pointers
[00:01:10 CET] <BtbN> I have never seen a decoder output something with cropping at the top or left
[00:01:25 CET] <BtbN> On CUDA frames you actually could though
[00:01:32 CET] <BtbN> since CUdevptr supports pointer arith just fine
[00:01:59 CET] <atomnuker> anyway its not by convention
[00:02:07 CET] <atomnuker> btw most decoders actually do crop from top and left
[00:02:13 CET] <atomnuker> software decoders that is
[00:02:30 CET] <BtbN> I tried returning CUDA frames with their actual height from nvdec
[00:02:32 CET] <BtbN> It exploded
[00:02:34 CET] <atomnuker> they allocate and pad all sides to handle motion compensation
[00:03:20 CET] <atomnuker> so any api user wanting direct decoding to their buffer need to call that special function which based on codec_id and with/height returns the padded buffer dimension
[00:03:20 CET] <TD-Linux> bonus points, a webm file that dynamically changes resolution https://bug1232045.bmoattachments.org/attachment.cgi?id=8715035
[00:05:35 CET] <BtbN> I think the primary reason those cropping fields exists is so that there's not 200 places that implement cropping logic themselves
[00:05:41 CET] <tmm1> so in vf_cropdetect if i replace frame->crop_* with the computed values, will they be used when encoding that frame later?
[00:05:49 CET] <BtbN> Which isn't trivial to do with alignment and everything
[00:06:12 CET] <JEEB> tmm1: ffmpeg.c most likely not
[00:06:16 CET] <tmm1> i'm trying to, for instance, create a cropped preview image with -vf cropdetect,thumbnail -vframes 1 out.jpg
[00:09:53 CET] <tmm1> because apply_cropping() happens before the filter chain?
[00:23:16 CET] <nevcairiel> <BtbN> A lot of decoders return 1080p with a height of 1088 and crop_bottom of 8 <-- that seems like a bug if that happens, cropping bottom or right doesn't even require  any data pointer adjustments, so unless you disabled some cropping options, that really shouldnt be happening
[00:23:50 CET] <BtbN> No idea at which point apply_cropping is called
[00:23:59 CET] <BtbN> maybe it never even leaves the decoder from an outside perspective
[00:24:11 CET] <nevcairiel> additionally, decoding can also apply any odd left/top cropping if you tell it that you're fine with unaligned data pointers
[00:24:53 CET] <nevcairiel> if you were to crop off say 16 pixels from the top, i believe it would apply that in software mode
[00:25:19 CET] <nevcairiel> actually top cropping should never really have alignment issues, since its full lines
[00:26:29 CET] <nevcairiel> but yeah top/left cropping is exceedingly rare in the real world
[00:30:44 CET] <BtbN> I remember some code just logging "Braindead cropping is not supported" if you tried
[00:53:56 CET] <cone-491> ffmpeg 03Mark Thompson 07master:ff007e30d8d4: vaapi_h264: Add workaround for bad SEI in old Intel drivers
[00:53:57 CET] <cone-491> ffmpeg 03Mark Thompson 07master:4251e25272d6: Merge commit 'ff007e30d8d45ba1ff2b2a4615f1cd5bafb50626'
[00:55:46 CET] <cone-491> ffmpeg 03Mark Thompson 07master:c77da21e5d15: vaapi_h264: Do not use deprecated header type
[00:55:47 CET] <cone-491> ffmpeg 03Mark Thompson 07master:040a92c21f2a: Merge commit 'c77da21e5d15056b8ba060ee5ce9e73f26653612'
[01:10:49 CET] <cone-491> ffmpeg 03Mark Thompson 07master:476d301316aa: cbs: Add a missing return value check
[01:10:50 CET] <cone-491> ffmpeg 03Mark Thompson 07master:22aed77687f8: cbs_h2645: Fix memory leak on when reading SEI fails
[01:10:51 CET] <cone-491> ffmpeg 03Mark Thompson 07master:d5fcf9426110: h264_metadata: Fix clearing SEI payload in error case
[01:10:52 CET] <cone-491> ffmpeg 03Mark Thompson 07master:620f88a0b94a: vaapi_h264: Add missing return value check
[01:10:53 CET] <cone-491> ffmpeg 03Mark Thompson 07master:6727cfea5e41: Merge commit '620f88a0b94a651c6cc912b1fb32d308762d59b5'
[01:15:29 CET] <jamrial> jkqxz: oh cool, thanks
[01:29:12 CET] <cone-491> ffmpeg 03James Almer 07master:f399172d6e84: avcodec/proresdec: align dequantization matrix buffers
[01:30:20 CET] <jkqxz> jamrial:  No, thank you!  You've made that all very easy now :)
[02:29:30 CET] <jamrial> atomnuker: yeah
[02:30:16 CET] <jamrial> it's the main reason bsfs like aac_adtstoasc and dca_core exist
[02:30:39 CET] <jamrial> convert the bitstream without having to re encode
[02:31:35 CET] <atomnuker> was thinking of writing a lossless jpeg transposer but I decided not to
[02:47:31 CET] <tmm1> what is the policy on backporting into release/3.4 ?
[02:48:24 CET] <JEEB> as usual, bug fixes can go in
[02:48:28 CET] <JEEB> no new features
[02:48:54 CET] <tmm1> if there are simple bug fix commits on master i care about, can i just cherry-pick them over?
[02:48:58 CET] <tmm1> or only my own commits?
[02:50:11 CET] <JEEB> given that not many people look at backports I'd say it's acceptable if you back-port what you feel is required
[02:53:26 CET] <jamrial> tmm1: bug fixes and documentation fixes/changes/additions only, basically
[02:53:45 CET] <jamrial> tmm1: and yes, cherry picking stuff from master is the usual way to backport fixes
[02:54:56 CET] <cone-491> ffmpeg 03Steven Liu 07release/3.4:d55794fafc9e: avformat/hlsenc: fix base_output_dirname is null when basename_size is 0 bug
[02:54:57 CET] <cone-491> ffmpeg 03Steven Liu 07release/3.4:6ad4d3c92f09: avformat/hlsenc: fix missing first segment bug in fmp4 mode
[02:54:58 CET] <cone-491> ffmpeg 03Steven Liu 07release/3.4:9ccb6de56c6f: avformat/hlsenc: reindent hlsenc code
[02:54:59 CET] <cone-491> ffmpeg 03Steven Liu 07release/3.4:fac3cfb6c18e: avformat/hlsenc: check hls segment mode for ignore the init filename
[02:55:00 CET] <cone-491> ffmpeg 03Steven Liu 07release/3.4:e3c09fb98618: avformat/hlsenc: reindent hlsenc code
[02:55:01 CET] <cone-491> ffmpeg 03Timo Rothenpieler 07release/3.4:62e99f026aea: avformat/hlsenc: allocate space for terminating null
[02:55:02 CET] <cone-491> ffmpeg 03Steven Liu 07release/3.4:67c079383538: avformat/hlsenc: write fmp4 init header after first AV frame
[02:55:24 CET] <tmm1> thanks!
[02:55:39 CET] <jamrial> tmatth: next time make sure to add -x to your cherry-pick command :p
[02:55:47 CET] <jamrial> err, tmm1
[02:56:01 CET] <tmatth> jamrial: you had me worried for a second ;)
[02:56:15 CET] <jamrial> sorry about that :p
[02:56:39 CET] <tmm1> ah, i'm surprised that's not default
[03:01:30 CET] <tmm1> >Trailing whitespace found in tests/ref/fate/sub-cc-scte20.
[03:01:36 CET] <tmm1> hrmf push rejected
[03:16:42 CET] <cone-491> ffmpeg 03Aman Gupta 07master:3f1a540204a8: avcodec/mpeg12dec: parse A53 caption data embedded in SCTE-20 user data
[03:16:43 CET] <cone-491> ffmpeg 03Aman Gupta 07master:ff8f40a63092: avcodec/mpeg12dec: ensure a53_caption_size is reset on malloc failures
[06:51:46 CET] <philipl> BtbN: So. First off, I was dumb and was using the wrong value for an unset reference frame. It's -1 and not 255 like for vp9.
[06:51:59 CET] <philipl> That makes the error message go away. But it still doesn't decode properly.
[06:52:11 CET] <philipl> I've got mpeg2 working, but not mpeg1. Don't really understand that failure
[10:39:31 CET] <BtbN> sounds like fun
[12:13:40 CET] <durandal_170> how to name dtsx removal bsf?
[12:30:30 CET] <JEEB> dts_core_extractor?
[12:30:42 CET] <JEEB> since if I understand it correctly it strips all extensions?
[12:33:11 CET] <nevcairiel> maybe he wants to only strip the dtsx extension
[12:41:06 CET] <JEEB> right, /25
[12:44:26 CET] <durandal_170> there is already dts core extractor bsf
[17:14:59 CET] <cone-336> ffmpeg 03James Almer 07master:b72ac6dbb815: configure: fix writing library dependencies to config.sh
[17:14:59 CET] <cone-336> ffmpeg 03James Almer 07master:5c2a01f064d5: Makefile: fix distclean target
[17:14:59 CET] <cone-336> ffmpeg 03Diego Biurrun 07master:9e48de3cc86c: configure: Miscellaneous minor changes
[17:14:59 CET] <cone-336> ffmpeg 03Diego Biurrun 07master:d070b9b703a5: configure: Coalesce some arch configuration and PIC handling
[17:14:59 CET] <cone-336> ffmpeg 03Martin Storsjö 07master:bad7ce1d82f0: makedef: Pass EXTERN_PREFIX from configure to makedef
[17:14:59 CET] <cone-336> ffmpeg 03James Almer 07master:c7812b3bcffa: Merge commit '5c2a01f064d5ab2b309d25c7f46c6c4471838d90'
[17:15:00 CET] <cone-336> ffmpeg 03James Almer 07master:b449af20d5d4: Merge commit '9e48de3cc86c732d9cebd496d6f0a2b7e7732754'
[17:15:01 CET] <cone-336> ffmpeg 03James Almer 07master:1146a7a363ab: Merge commit 'd070b9b703a542429a13db9623109ae20474c775'
[17:15:02 CET] <cone-336> ffmpeg 03James Almer 07master:edef07569ccc: Merge commit 'bad7ce1d82f0b7da55086b8c6124eff0d35a1b1a'
[18:17:33 CET] <cone-336> ffmpeg 03Timo Rothenpieler 07master:4fb20d4e3a48: configure: call flatten_extralibs in a subshell
[20:46:42 CET] <_Vi> Is there some reason that input files support only `-t` option which output files support both `-t` and `-to`? It's convenient to specify range from-to (-ss ... -to ...) for input file without manually calculating length for `-t`. I've tried sending a patch that enables `-to` for input files to the mailing list, but got no reply.
[20:48:45 CET] <_Vi> Update: explored maillist archives and saw one answer (which I have not received per e-mail). Shall I join two commits into one, fix the minor doc issue and re-send the patch?
[20:55:40 CET] <jdarnley> No.  We usually prefer separate patches for unrelated changes.
[20:56:22 CET] <jdarnley> And if you're not subscribed to the mailing list you need to ask people to Cc you
[20:58:12 CET] <_Vi> jdarnley, OK. What about the `-to` feature? Shall I just wait or done some next step? (relevant maillist message: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/219186.html )
[20:59:06 CET] <_Vi> The implementation is trivial and straightforward, but may be inelegant due to duplicated code.
[20:59:14 CET] <jdarnley> If people have forgotten about the original message then simply reply to it and remind people (or just send the word "bump")
[21:00:47 CET] <jdarnley> Ah, just read that, I guess you should join the commits as requested.
[21:00:59 CET] <_Vi> jdarnley, Is the linked message an invitation to fix the problem (about "@emph{input/output}") or just a notice?
[21:01:36 CET] <_Vi> So, joining, fixing the "input/ouput" and re-sending is a good idea for advancing the feature, is it?
[21:02:37 CET] <jdarnley> He's telling you to change it, I think.  You are adding the feature so that -to becomes an input option.  I think he's telling you that you missed a spot.
[21:04:14 CET] <_Vi> I agree with all that, but am not very familiar with FFmpeg development mailing list culture and patch submission lifecycle.
[21:05:41 CET] <jdarnley> Sure, everybody starts somewhere
[21:06:43 CET] <jdarnley> Please ask if you have any more questions.
[21:08:49 CET] <_Vi> Shall I consider replier Moritz a reviewer and add the respective e-mail address in "To:" explicitly?
[21:09:33 CET] <jdarnley> No.  He is subscribed to the list so he will see the email through it.
[21:11:05 CET] <_Vi> jdarnley, (When submitting patches to Git, one is supposed to find a reviewer based on recent related commits and send directly to him/her. I though there may be similar thing for FFmpeg).
[21:12:11 CET] <jdarnley> Do you mean for the Git software itself?  I wouldn't know.  I'm only a user of it.
[21:12:42 CET] <jdarnley> As for FFmpeg, no.  Devs are supposed to share the load of reviewing patches on the mailing list.
[21:14:07 CET] <alevinsn> michaelni:  Is the MAINTAINERS documentation up to date in that you are the maintainer of mpegvideo?
[21:14:45 CET] <_Vi> jdarnley, Yes, Git software itself. Such system should be self-balancing and helps manage volume of mailing lists somewhat (patches are supposed to be sent there only after some review).
[21:14:51 CET] <michaelni> alevinsn, yes 
[21:17:32 CET] <alevinsn> michaelni:  I have a case in which some mpeg2 720p59.94 video is being determined as having a field_order of AV_FIELD_BB.  This is the case after the call to avformat_find_stream_info() returns.  However, later, after reading frames, it gets corrected to AV_FIELD_PROGRESSIVE
[21:17:56 CET] <alevinsn> I spent a little time seeing what is going on in mpegvideo_parser, but there's a lot there
[21:18:28 CET] <alevinsn> This particular stream likely has copyrighted content in it, so I'm not sure of the best way to proceed
[21:19:25 CET] <michaelni> probably first thing is to try a few older releases, if one works bisect should be interrestng
[21:20:05 CET] <michaelni> if that gets nowhere then the next question is if the interlaced related flags are consistent or changing
[21:20:34 CET] <michaelni> if they are changing then its not so easy for any code to return what the user thinks is best
[21:21:00 CET] <alevinsn> well, other software reports it as progressive
[21:21:23 CET] <alevinsn> such as TSReaderLite
[21:21:31 CET] <alevinsn> I haven't checked with MediaInfo yet
[21:23:10 CET] <alevinsn> I'm using an hwaccel--would that make any difference?
[21:23:15 CET] <alevinsn> D3D11
[21:23:46 CET] <alevinsn> using git log, mpegvideo_parser.c hasn't changed since October 2016
[21:26:29 CET] <alevinsn> ok, I'll see what I can do to help isolate the issue--thanks
[22:56:45 CET] <beastd> BTW how was VDD this year?
[22:58:22 CET] <durandal_1707> boring... iirc
[23:03:24 CET] <kierank> durandal_1707: you were not there
[23:03:47 CET] <durandal_1707> yeah
[23:06:32 CET] <beastd> IIRC my last time at VDD was 2014 or 2015. I guess I would like to go again. Maybe next year, but you never know...
[23:06:54 CET] <durandal_1707> beastd: ffmpeg leader, carl was on nttw2
[23:07:29 CET] <JEEB> beastd: it was pretty fun talking to people and annoying TD-Linux . talks were fun and unfortunately the recordings' audio was very low
[23:07:48 CET] <TD-Linux> mad that JEEB didn't go to karaoke
[23:08:12 CET] <JEEB> yea I had to do the good work sheeple thing
[23:08:21 CET] <durandal_1707> and which songs would he sing?
[23:12:54 CET] <atomnuker> it was nice, I gave a talk and j-b still hasn't uploaded any of the talks to youtube
[23:13:08 CET] <durandal_1707> thats shame
[23:13:23 CET] <kierank> atomnuker's talk was good
[23:13:30 CET] <JEEB> atomnuker: poke the Wilawar dude on #videolan - he said he wanted to filter the audio and get them to j-b :P
[23:13:40 CET] <JEEB> from the captures
[23:14:04 CET] <beastd> atomnuker: I noticed in the schedule. Would love to hear your talk! 
[23:14:39 CET] <JEEB> beastd: https://bambuser.com/channel/VDD17
[23:14:45 CET] <JEEB> this is with the funkologic audio
[23:14:48 CET] <JEEB> needs filtering
[23:27:02 CET] <cone-336> ffmpeg 03John Stebbins 07master:ac922f942fa2: lavf/movenc: allow writing avc3 sample entry type
[23:27:03 CET] <cone-336> ffmpeg 03Fredrik Hubinette 07master:a6fdd75fe644: avformat/mov: Check size of STSC allocation
[23:35:34 CET] <beastd> JEEB: Thanks for the pointer.
[23:37:37 CET] <cone-336> ffmpeg 03Umair Khan 07master:e510a8251b3f: libavcodec/als: remove check for predictor order of a block
[23:37:38 CET] <cone-336> ffmpeg 03Umair Khan 07master:55937bb4a7df: libavcodec/als: fix address sanitization error in decoder
[23:47:53 CET] <cone-336> ffmpeg 03Carl Eugen Hoyos 07master:ce001bb8fc66: lavf/mxf: Support 60fps output.
[23:48:22 CET] <TimothyGu> Is it a bad sign that I now prefer C++ over C
[23:50:15 CET] <kierank> Yes
[23:51:26 CET] <atomnuker> you need help, look at some nice decoder code or write asm
[23:51:46 CET] <kierank> Write cineform asm
[23:57:18 CET] <durandal_1707> write cineform encoder
[00:00:00 CET] --- Fri Nov 17 2017