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

[burek]

[00:02:20 CEST] <prelude2004c> writing file.. should take 1 - 2 min
[00:08:03 CEST] <rcombs> JEEB: apparently "object-based audio" crammed in a TrueHD substream
[00:08:26 CEST] <rcombs> I kinda doubt there's anything useful lavc could do with it other than note if it's present
[00:08:41 CEST] <rcombs> mostly it makes a little LED on receivers turn on
[00:08:56 CEST] <JEEB> aye
[00:09:17 CEST] <rcombs> it might try to be useful for height channels?
[00:09:56 CEST] <rcombs> or if you have 5.1 or 7.1 but the speakers aren't quite in the right places, apparently some receivers let you specify exact positions and it'll do& something, with that information
[00:10:06 CEST] <rcombs> there are probably around 7 people who have that setup
[00:10:20 CEST] <JEEB> sounds correect enough
[00:10:34 CEST] <rcombs> also DTS has their own version called DTS:X
[00:10:49 CEST] <rcombs> apparently this is duct-taped onto a DTS core stream like everything else
[00:11:10 CEST] <rcombs> I'd imagine this leads to extremely good compression efficiency
[00:11:28 CEST] <prelude2004c> andrey_turkin .. sorry for the delay
[00:11:29 CEST] <prelude2004c> http://67.55.1.151:8081/cmetv/output.ts
[00:11:36 CEST] <prelude2004c> that is the output TS with raw feed
[00:11:39 CEST] <JEEB> DTS core never had any cool compression efficiency ;)
[00:12:14 CEST] <prelude2004c> hey DHE, what do I do to patch up the code from your revision .. i should try to run it ? 
[00:12:51 CEST] <DHE> prelude2004c: what do you mean?
[00:13:10 CEST] <prelude2004c> the new git repo i downloaded the latest release and i am worried i will break files if i try to apply the patch 
[00:13:16 CEST] <prelude2004c> since there have been many changes from a week ago
[00:13:48 CEST] <prelude2004c> i wnat to fix this closed caption thing and give your code a full try with nvenc to see if the 26.5 hour thing is broken
[00:14:10 CEST] <DHE> it only affects mpegts.c which doesn't see that much action. I don't expect big problems
[00:14:31 CEST] <prelude2004c> btw, http://67.55.1.151:8081/cmetv/output.ts if you want to take that 6 min file.. its from the raw inputs .. you can simply use that for loop and try to replicate that 26.5 quickly to see if you can make it happen with that
[00:14:42 CEST] <prelude2004c> ok i will try now to patch that ..
[00:15:38 CEST] <prelude2004c> no errors.. thank you
[00:16:12 CEST] <DHE> then it will likely just work
[00:16:27 CEST] <prelude2004c> yup... i hope so .. if it's fixed
[00:16:41 CEST] <prelude2004c> are you able to give my source a go and see if the 26.5 happens with that source ? 
[00:16:55 CEST] <prelude2004c> maybe the type of content matters ? which i suspect should not be the case but.. who knows
[00:17:01 CEST] <DHE> I have my own source. it's a 28 hour recording. about 90 gigabytes large
[00:17:38 CEST] <prelude2004c> and it's good for you.. ok maybe because i had the other patch in it too ? could that have been causing issues ? meaning if i just use the latest patch maybe it works better
[00:19:50 CEST] <DHE> prelude2004c: there were two patches. one touched mostly the utils.c and the internal.h file, and that will conflict with different versions pretty easily. the mpegts.c patch is much cleaner and better
[00:20:03 CEST] <DHE> which have you been using?
[00:20:36 CEST] <prelude2004c> ok so i used the mpegts patch only
[00:20:40 CEST] <prelude2004c> before i was using both 
[00:22:13 CEST] <prelude2004c> oh what the hell... now i am getting " Overriding packet duration by frame rate, this should not happen " errors... unreal
[00:22:21 CEST] <prelude2004c> if not one then another :( 
[00:22:31 CEST] <DHE> using your sample video you pasted above?
[00:22:40 CEST] <prelude2004c> the original source
[00:25:08 CEST] <prelude2004c> output seems ok
[00:25:36 CEST] <andrey_turkin> yeah, I saw that one too
[00:26:12 CEST] <andrey_turkin> I think maybe it has to do with BtbN's recent patch on output frame duration
[00:37:04 CEST] <andrey_turkin> prelude2004c: I'm watching this transcoded with nvenc and I cannot understand if it's working properly or not ) This live on-the-fly captioning thing kinda sucks. I mean, I don't expect lipsync but it would be nice to get some synchronization
[00:37:22 CEST] <andrey_turkin> guess I'll just have to dump raw A53 commands and compare them
[00:39:50 CEST] <prelude2004c> um.. lipsync works for me
[00:39:58 CEST] <prelude2004c> i mean we have to get stuff from live sources
[00:40:12 CEST] <prelude2004c> its how we get the data .. sometimes in mpeg2video and other times in h264 format
[00:40:17 CEST] <prelude2004c> then we transcode to new bit rates and stuff
[00:40:18 CEST] <atomnuker> michaelni: it's 4 votes for no and 3 votes for yes or am I missing someone?
[00:40:19 CEST] <prelude2004c> these are not files
[00:40:54 CEST] <andrey_turkin> audio/video is in sync. Subtitles are way off - it looks like they type it in real time off the audio. There are some typos etc
[00:40:59 CEST] <michaelni> atomnuker, i didnt count, BBB said that, ill count at the end
[00:41:38 CEST] <BBB> atomnuker: I believe its michael/clement/carl/marton yes, and wm4/me/you/nevcariel no
[00:42:02 CEST] <BBB> I ignored the vote of thilo because he asked his approval to not affect the current count/vote
[00:43:35 CEST] <prelude2004c> weird right ? typos is an under statement :) 
[00:43:46 CEST] <prelude2004c> its like german to me :) 
[00:44:05 CEST] <prelude2004c> and the odd part is.. ( happens on h264 as well ) it goes for a little bit and then stops.. then goes then stops
[00:44:17 CEST] <atomnuker> it should be over 50% to pass, right?
[00:54:39 CEST] <DHE> prelude2004c: I'll see if I can track down that error you got during the game.
[00:57:38 CEST] <prelude2004c> ya no worries.. its working so less important.. not really sure if it means anything important but..
[00:57:59 CEST] <DHE> check it tomorrow around 9pm. :)
[00:58:06 CEST] <prelude2004c> really the only things i care about is keeping audio/video in sync... the closed caption works and lastly the 26.5 hours... all else is little things that have little effect
[00:58:28 CEST] <prelude2004c> DHE , thank you for your attention in these matters
[01:29:14 CEST] <DHE> prelude2004c: are you setting the framerate anywhere?
[01:33:23 CEST] <DHE> n/m
[01:34:27 CEST] <andrey_turkin> Looks like CC chunks are being reodered for some reason. For both libx264 and nvenc
[01:38:42 CEST] <andrey_turkin> nevermind, wrong way to dump them
[02:23:50 CEST] <cone-711> ffmpeg 03Michael Niedermayer 07master:b28e102875af: avformat/version: Add Ticket5421 to list of tickets possibly affected by a major bump
[02:23:50 CEST] <cone-711> ffmpeg 03Michael Niedermayer 07master:958bf659d84d: avdevice/lavfi: Do not set avg_frame_rate to the timebase
[03:16:25 CEST] <prelude2004c> DHE , i am 30fps
[03:16:38 CEST] <prelude2004c> the source is 60fps for most of channels.. i dont need 60fps
[03:17:05 CEST] <prelude2004c> <andrey_turkin> i am sure you will get them :) 
[03:46:19 CEST] <DHE> ah, you're overriding the 720p down to 30fps
[09:13:32 CEST] <cone-263> ffmpeg 03Muhammad Faiz 07master:1e6a0c9d140c: avfilter/avf_showcqt: render default font at 960x16
[10:14:30 CEST] <andrey_turkin> I now realize attaching A53 captions to the frames is not just hackish, it is just plain wrong
[10:16:57 CEST] <andrey_turkin> because frames can be dropped, or duplicated, or whatever. I get different output CC data after simply doing c:v copy! 
[10:19:01 CEST] <nevcairiel> stream copy would not change the CC data since its part of the stream, so unelss you invented something new to modify the bitstream and inject CC data
[10:20:41 CEST] <andrey_turkin> I think stream copy still depacketized and then repacketized that stream
[10:22:47 CEST] <andrey_turkin> here's what I did: I added some code to ffmpeg.c to dump attached A53 captions from decoded frames (just before they go into a filterchain)
[10:23:07 CEST] <andrey_turkin> and then I run it twice, once on original file and once on a file created with video stream copy
[12:02:28 CEST] <BtbN> Hm, is setting the packet duration wrong?
[12:03:34 CEST] <DHE> andrey_turkin: as said, yeah you're basically stuck in that boat. which is why I did it that way...
[12:04:24 CEST] <BtbN> If the subtitle data is in the frames, 60 -> 30 FPS sounds like a problem, yeah.
[12:04:50 CEST] <DHE> yes, A53 closed captions are inside the video payload itself as a sort of supplemental payload
[12:04:53 CEST] <andrey_turkin> exactly. Altough I see some problems even without frame conversion
[12:05:17 CEST] <BtbN> But I'm wondering about that Overriding packet duration warning.
[12:05:28 CEST] <DHE> there's two things going on here... :/
[12:05:37 CEST] <BtbN> The check is in ffmpeg.c, line 683.
[12:05:43 CEST] <andrey_turkin> it might or might not be related to your patch but timing is suspicious
[12:05:57 CEST] <BtbN> And yes, it's caused by nvenc now forwarding the frame/packet duration.
[12:06:06 CEST] <BtbN> But doing that seems correct to me?
[12:06:17 CEST] <DHE> I thought it was just timestamps that were forwarded
[12:06:50 CEST] <BtbN> Now also the duration, because it was already partially in place, just never setting the input duration.
[12:07:06 CEST] <BtbN> Should an encoder not do that?
[12:07:53 CEST] <DHE> so, I'm not an expert but it was my understanding that frames can come out of order due to b-frames and the like. which is why frames come out in DTS order even though you submit them in PTS order. doesn't that throw a wrench into that?
[12:08:24 CEST] <BtbN> yes, they can be re-ordered. But why would that affect their duration?
[12:09:09 CEST] <nevcairiel> BtbN: frames dont even have a duration field?
[12:09:37 CEST] <BtbN> av_frame_get_pkt_duration
[12:09:43 CEST] <nevcairiel> thats not what you think it is
[12:09:50 CEST] <nevcairiel> and shall not be used by encoders says the doxy
[12:10:18 CEST] <DHE> AVPacket does have a duration field
[12:10:19 CEST] <nevcairiel> pkt_* fields are decoding-only
[12:11:11 CEST] <nevcairiel> encoders should use the pts field for timestamps, not pkt_pts, and not touch any of the other pkt_ fields
[12:13:31 CEST] <BtbN> So leaving the output packet duration empty was actually correct?
[12:15:56 CEST] <nevcairiel> yes
[12:16:03 CEST] <nevcairiel> dont think any encoders produce a duration
[12:16:13 CEST] <BtbN> Audio encoders do aparently.
[12:16:16 CEST] <BtbN> And libvpx
[12:16:19 CEST] <nevcairiel> well its easy for audio
[12:16:26 CEST] <nevcairiel> sample rate and nb samples are duration
[12:16:42 CEST] <nevcairiel> video has no inherent duration
[12:17:07 CEST] <BtbN> For video it's aparently also wrong, as ffmpeg.c complains about duration being >0, just before it then sets the duration itself.
[12:58:22 CEST] <ubitux> nevcairiel: are you up for help wrt pps/sps merge?
[13:00:39 CEST] <DHE> I wrote a C application for transcoding. never touched the duration field and only did minor timestamp correction (conversion between timebases). works great
[13:00:55 CEST] <DHE> but I'm only processing one format, so that might be a reason?
[13:06:48 CEST] <nevcairiel> ubitux: i guess so
[13:14:41 CEST] <ubitux> nevcairiel: do you have any hint or will to look into one of the TODO in the commit message?
[13:16:21 CEST] <nevcairiel> are the two issues documented there the only known problems right now?
[13:16:40 CEST] <ubitux> i think so yes
[13:17:22 CEST] <cone-593> ffmpeg 03Timo Rothenpieler 07master:7c55f5d782ce: avcodec/nvenc: Don't set packet duration
[13:17:23 CEST] <ubitux> ah, mmh, there was an issue about dequant being mentioned, but i don't think michaelni gave much details
[13:17:24 CEST] <nevcairiel> i need to finish something right now, will poke it after
[13:17:37 CEST] <ubitux> sure, thank you
[13:24:29 CEST] <michaelni> ubitux, IIRC the h->dequant_coeff_pps != pps_id -> "h->ps.pps != pps" change broke multithreaded decoding when dequent changes, removing the check "fixed" it but that might be a bad fix
[13:25:39 CEST] <ubitux> do you have a sample/cmdline that i can reference in the description?
[13:26:39 CEST] <ubitux> but it's going to take me a very long time to fix these issues&
[13:26:56 CEST] <ubitux> i think it would be easier to fix the less important ones at the end of the merge of the batch
[13:27:35 CEST] <ubitux> the rest of the batch should be relatively easier, but the sei one might be tricky as well
[13:38:45 CEST] <michaelni> ubitux, IIRC it was just fate-h264-xavc-4389 with threads, results very vissible difference and error messages
[13:39:05 CEST] <michaelni> but maybe i mentioned this yestarday already
[13:53:40 CEST] <ubitux> michaelni: thanks, i updated the description
[14:01:13 CEST] <ubitux> the pointer comparison is done in several places though
[14:03:27 CEST] <ubitux> can be shown with git grep 'h->ps.[sp]ps [^ ]='
[14:03:44 CEST] <DSM_> what is sps/pps?
[14:04:10 CEST] <ubitux> sequence and picture parameter set rbsp
[14:05:31 CEST] <ubitux> respectively a bunch of information related to a sequence of pictures or pictures themselves, found in h264 (and actually hevc) bitstream
[14:06:16 CEST] <ubitux> (and can also be extracted and put in some container or any other "storage")
[14:07:06 CEST] <ubitux> that's it, all my "knowledge" on them so far :p
[14:07:16 CEST] <BtbN> looks like ff_get_format does not support decoders which support only hw output formats
[14:08:02 CEST] <DSM_> ubitux: ok. what are you trying to do with it?
[14:08:14 CEST] <DSM_> *you guys
[14:09:49 CEST] <ubitux> merging a refactoring commit from libav related to how it's handled between the parser and the decoder
[14:10:45 CEST] <ubitux> but it seems to be causing some issues as it's making a bunch of unmet assumptions
[14:12:09 CEST] <ubitux> https://github.com/ubitux/FFmpeg/commits/merge-libav more info here
[14:12:20 CEST] <ubitux> (in the last commit)
[15:07:40 CEST] <nevcairiel> ubitux: i dont suppose you considered just deciding not to merge the change? I've previously skipped (h264) refactoring if it turned out the new way is just problematic (either in general, or due to things our decoder does that theirs doesnt) .. and it does sound to me like there is a lot of problems the original change didnt consider
[15:12:19 CEST] <kierank> their h264 stuff is insane sometimes
[15:13:36 CEST] <nevcairiel> the current set sounds like rewriting the decoder just to be able to build the parser without the decoder being compiled ... which doesnt seem like a goal worth of such effort
[15:14:02 CEST] <nevcairiel> especially since it seems to cause a lot of problems right now
[15:32:03 CEST] <BtbN> hrm, looks like a decoder that's haccel-only was never intended and causes issues everywhere.
[15:32:30 CEST] <BtbN> So integrated downloading it is...
[15:36:33 CEST] <nevcairiel> i warned you :)
[15:37:10 CEST] <BtbN> It's not like that it wouldn't work. But in multiple locations there are checks and assert for a non-hwaccel format being present, that then cause a failure...
[15:37:49 CEST] <BtbN> The first one in ff_get_format, and another one somewhere in ffmpeg.c
[15:38:11 CEST] <BtbN> So I'll duplicate the entire vf_hwdownload_cuda filter, great...
[15:38:18 CEST] <BtbN> Which is then never going to be used.
[15:38:43 CEST] <BtbN> I could advertise NV12 support, but then fail if it's actually being used.
[15:56:25 CEST] <nevcairiel> didnt you say a few days ago that it would just be a matter of calling the download function from the hwcontext
[15:58:10 CEST] <BtbN> I'd have to rip it out of there first, and make it into a shared function. Which is kind of a problem as one is in avfilter and one in avcodec.
[15:58:24 CEST] <BtbN> The worst stuff already is in lavu, but it's still a lot of duplicated code.
[15:59:15 CEST] <nevcairiel> i dont get it, downloading the image is like two calls
[16:00:21 CEST] <nevcairiel> i still maintain the opinion that a hardware decoder that cannot output a software image is of questionable use anyway, forcing people to adopt using lavfi just for that etc
[16:00:51 CEST] <BtbN> Its primary use would be transcoding using nvenc.
[16:00:52 CEST] <nevcairiel> the hwcontext is specifically designed to make that easier, by promoting common operations into a common interface, which includes downloading images
[16:03:22 CEST] <nevcairiel> although i dont remember if the download functions are in the current ffmpeg version yet
[16:03:36 CEST] <BtbN> I think they are
[16:03:52 CEST] <BtbN> But I'm not going to use them. I need to cuMemcpy anyway, so I can just do that to the target frame.
[16:16:09 CEST] <ubitux> nevcairiel: yeah i actually think it's worth merging
[16:17:36 CEST] <ubitux> i also feel like there is a more far sighted goal behind this
[16:18:23 CEST] <ubitux> be it refactors with hevc, a new parser api, or something like that
[16:24:48 CEST] <BtbN> Is it safe to put an AVFrame on the stack, or should I allways use av_frame_alloc?
[16:25:24 CEST] <nevcairiel> not on stack
[16:41:01 CEST] <prelude2004c>  andrey_turkin , tricky hum?
[16:52:41 CEST] <durandal_170> michaelni: have you read my patch on ml
[17:13:43 CEST] <andrey_turkin> prelude2004c: well, I'm pretty sure my patch is fine so I'll be sending it to the ML. I'm also pretty sure you'll have hard time combining A53 captions output and frame rate conversion due to the way CC are handled
[17:14:37 CEST] <prelude2004c> can't we extract it on decoding and then map it to something to later integrate ? 
[17:14:47 CEST] <prelude2004c> also... why does it not look like garbage on the libx264 ?
[17:16:17 CEST] <prelude2004c> i am certain it can be done.. i have another encoder ( a bought one ) that converts down to 30fps and the closed captions all work fine
[17:16:22 CEST] <prelude2004c> has to be something there.
[17:16:39 CEST] <prelude2004c> same source .. same output settings... etc
[17:16:54 CEST] <andrey_turkin> That's correct way to do it; it is also a much larger development effort
[17:17:40 CEST] <andrey_turkin> I guess that encoder does this the right way (to extract CC commands and combine them into bigger chunks on output)
[17:18:04 CEST] <prelude2004c> i have no idea how it is done but it works 
[17:18:43 CEST] <prelude2004c> so if I run ffmpeg decode .. then -map the codec into a  pid
[17:18:49 CEST] <prelude2004c> then later join the pid.. would that not work ?
[17:18:56 CEST] <andrey_turkin> no it wouldn't
[17:19:03 CEST] <andrey_turkin> because there is no separate stream
[17:20:17 CEST] <andrey_turkin> we'd have to have some way to split video stream into video and CC streams and then to combine video/CC streams back while maintaining time sync
[17:22:26 CEST] <andrey_turkin> regarding difference between libx264 and nvenc you see - I've no idea why. Anyway, CC data will be compromised if you do any framerate conversion regardless of the codec. 
[17:25:40 CEST] <jsebechlebsky> Hello, is there some standardized way how static function should be documented (does it make sense to use doxygen comments there)?
[17:30:05 CEST] <prelude2004c> i completely get what you are saying
[17:30:07 CEST] <michaelni> durandal_170, ive just now taken a look, should i try to convert the tables for init vlc ? but they also could be left as is
[17:31:00 CEST] <prelude2004c> so somehow i have to get someone to customize something...
[17:31:05 CEST] <durandal_170> michaelni: how one can convert it?
[17:31:30 CEST] <prelude2004c> because if we drop frames, maybe dropping frames from closed caption too might work .. interesting part is the x264 is not garbage.. its in tact
[17:31:47 CEST] <prelude2004c> still pauses every once in a while but..
[17:31:59 CEST] <prelude2004c> this is a crazy problem that i need to find a solution for :( 
[17:32:17 CEST] <prelude2004c> i can't use 60fps so .. it's not easy at the moment
[17:32:53 CEST] <michaelni> durandal_170, dunno, maybe a dumb loop feeding it with all 16bit inputs then for each one knows how much the reader moved forward (length and from length and input one knows the bits) drop duplicates and you have the tables for init vlc ... at least thats the theory
[17:38:17 CEST] <prelude2004c> andrey_turkin .. here is another idea
[17:38:37 CEST] <prelude2004c> instead of doing a frame rate conversion down to 30fps... can't i use a video filter like " field " or something to cut the frame rates in half.. 
[17:39:03 CEST] <prelude2004c> everything here is ntsc .. maybe i can drop half the frames that way and leave the data in tact ? not sure if that makes sense 
[17:39:08 CEST] <prelude2004c> but just crossed my mind
[17:39:39 CEST] <andrey_turkin> not sure how you'd do it
[17:39:56 CEST] <BtbN> Basically, don't change the framerate if you want that CC mess to work at all.
[17:41:42 CEST] <andrey_turkin> the simplest thing that can probably work is to write pair of filters to separate video from CC data (and combine them back); then one could build complex graph to do frame rate conversion on "stripped" video frames. IIRC libavfilter already has something to do input synchronization
[17:42:20 CEST] <BtbN> Something else, how do i track down where "Error while decoding stream #0:0: Invalid argument" comes from? It's not coming from my decode function, and there is no error message before it.
[17:42:28 CEST] <prelude2004c> oh well i have absolutely now idea how to even go about it
[17:42:32 CEST] <BtbN> I'd guess there is some gdb magic for that?
[17:43:02 CEST] <BtbN> prelude2004c, use a non-broken caption format instead.
[17:43:16 CEST] <prelude2004c> i can't change the source
[17:43:17 CEST] <andrey_turkin> sometimes that is not an options
[17:43:22 CEST] <prelude2004c> its coming from the content providers like that
[17:43:31 CEST] <BtbN> Tell them to use a non-broken format instead.
[17:43:38 CEST] <nevcairiel> so decode the CC and convert it to something else =p
[17:43:55 CEST] <prelude2004c> yes right. why don't i move a large mountain with my bare hands :) 
[17:44:22 CEST] <BtbN> Does ffmpeg support that? CC to something else, in real time?
[17:44:26 CEST] <prelude2004c> yes that is what i am thinking.. decode it with the vdpau that i am using.. and somehow grab it.. map it to something else.. then insert it later on the nvenc encoding
[17:44:37 CEST] <prelude2004c> i just dont know how to do it
[17:44:56 CEST] <andrey_turkin> BtbN: there is something pretty hacky in lavfi device
[17:45:06 CEST] <prelude2004c> i am pretty sure this is common.. in north america many providers embed everything themselves 
[17:45:10 CEST] <prelude2004c> in the video i mean
[17:45:36 CEST] <andrey_turkin> yeah, until ATSC 3.0 is widespread this thing is not going to die
[17:45:40 CEST] <nevcairiel> they generate the CC  data to match the video though, trying to retain CC while changing video is just not going to be something that works very well
[17:46:10 CEST] <prelude2004c> ok video has interlace / deinterace frames or something right
[17:46:20 CEST] <prelude2004c> and i only need one of them.. so how do i go about dropping every other frame
[17:46:33 CEST] <prelude2004c> maybe just maybe there is something there ?
[17:46:49 CEST] <andrey_turkin> you see, you can do that with field filter; but you'll be stuck with 60fps progressive video
[17:47:19 CEST] <prelude2004c> hum... but it will cut down half the work on the encoder
[17:47:40 CEST] <prelude2004c> the reason i need that is because 60fps causes worse quality on the encoding than 30 fps as it has a lot more work to do.. or i hae to use more encoding power which i do not have
[17:47:44 CEST] <andrey_turkin> it will also halve the height
[17:47:57 CEST] <prelude2004c> oh.. half the height is not good :) 
[17:50:47 CEST] <prelude2004c> i am totally out of options here and i can't have 60fps .. and i dont know how to put anything together to try and pull out cc on decode with a filter :( 
[17:51:01 CEST] <prelude2004c> anyone know anyone with the knowledge to do it .. upwork is my friend
[17:51:14 CEST] <prelude2004c> been stuck on this stuff soooo long
[17:51:16 CEST] <BtbN> There is no option for you to have there.
[17:51:44 CEST] <andrey_turkin> there is, just not with existing ffmpeg code
[17:52:04 CEST] <iive> CC is closed captions, isn't it?
[17:52:16 CEST] <andrey_turkin> right
[17:52:34 CEST] <iive> i thought that they are in text form, so it should be quite easy to convert them to normal text subtitles...
[17:53:07 CEST] <andrey_turkin> there is a decoder that should work
[17:53:40 CEST] <andrey_turkin> question is what to do with converted subtitles
[17:59:33 CEST] <prelude2004c> ok i am onto something
[17:59:50 CEST] <prelude2004c> if i put -r 30 on the vdpau input i get the right closed caption data. but my video is in slow motino
[17:59:52 CEST] <prelude2004c> motion*
[17:59:56 CEST] <prelude2004c> what's that all about
[18:00:18 CEST] <prelude2004c> but.. the closed caption data is not garbage
[18:00:46 CEST] <andrey_turkin> well looks like you get your 60fps video but slowed down 2x
[18:00:59 CEST] <andrey_turkin> I wonder though. Do you target HLS?
[18:03:27 CEST] <DHE> you're not dropping frames, you're just stretching out the video
[18:03:37 CEST] <DHE> but since no frames are dropped, you don't lose any CC data
[18:15:28 CEST] <prelude2004c> DHE .. stretching out the frames.. my input is 60fps.. i put -r 30 on the input and the video goes in slomo
[18:15:42 CEST] <DHE> yep. that overrides the input framerate
[18:15:59 CEST] <prelude2004c> any way to fix that now .. so really i get my 30fps ... and i get my closed caption but the output looks like its going in slow motion :) 
[18:16:02 CEST] <DHE> but if you put it before the output rather than before the input, then it will convert the framerate by dropping/duplicating frames
[18:16:04 CEST] <prelude2004c> not looks like.. it is
[18:16:27 CEST] <prelude2004c> but somehow is there a way for me to put it on the input and then on the ouput make the video look normal ? 
[18:16:30 CEST] <prelude2004c> without converting
[18:16:36 CEST] <prelude2004c> that way my closed caption looks ok
[18:16:40 CEST] <prelude2004c> there has to be  away 
[18:17:00 CEST] <prelude2004c> even 30fps should not be visible to the eye
[18:17:19 CEST] <DHE> you'd be amazed. I can tell the difference between 30 and 60 :)
[18:17:29 CEST] <prelude2004c> ya i can tell too but most people do not care
[18:19:56 CEST] <prelude2004c> there is something here though.. the output is 30fps... maybe -r 30 on the output too
[18:19:57 CEST] <prelude2004c> hum..
[18:21:39 CEST] <prelude2004c> still slow motion with -r 30 on the input
[18:21:55 CEST] <prelude2004c> now i need to drop every other frame or something right.. to make it play regular rate
[18:22:37 CEST] <prelude2004c> i am not understanding something here but there is a combo here that might work.. if i set the -r30 input it sets the timestamps of the source to 30fps.. which brings everything inline.. the closed caption is also coming out normal
[18:22:49 CEST] <prelude2004c> so now.. on the output it shoudl be playing at 30fps... which is still good for me
[18:22:52 CEST] <prelude2004c> but its not.. its like 15fps
[18:23:19 CEST] <BtbN> how do you intend to convert 60 to 30 fps, without dropping every other frame?
[18:23:23 CEST] <nevcairiel> thats because you are just slowing things down with -r, not dropping any frames, slowing things down results playing in slowmo
[18:25:05 CEST] <prelude2004c> hum... ok so i am trying to understand that.. i am slowing things down to 30 fps.. so that wont work :( 
[18:25:38 CEST] <BtbN> The only non-broken way for your CC stuff is to not touch the framerate.
[18:26:10 CEST] <prelude2004c> what .. what about...
[18:26:36 CEST] <prelude2004c> ahhhhhh frustrating
[18:27:01 CEST] <prelude2004c> there is a way.. funny thing is... i used to see the closed caption data at some point somehow at 30fps
[18:27:10 CEST] <andrey_turkin> prelude2004c: what are you trying to achieve in the end?
[18:27:25 CEST] <prelude2004c> i can't remember but i had it working and then i lost it when i made so many changes 3 months ago... 
[18:27:33 CEST] <prelude2004c> in the end... i want the closed caption data at 30fps
[18:27:42 CEST] <prelude2004c> i can't use 60fps because i don't have enough encoding power to do all the channels
[18:27:55 CEST] <prelude2004c> and at 30fps,  i get better quality at 1.8mbit/s
[18:28:02 CEST] <prelude2004c> so i have to keep to 30fps as much as possible
[18:28:10 CEST] <andrey_turkin> do you need CC data in CEA 608?
[18:28:55 CEST] <andrey_turkin> I mean e.g. with HLS you have an option to use WebVTT; with MPEG-TS you can try DVB subtitles etc
[18:32:27 CEST] <prelude2004c> i dont care how the closed caption comes out to be honest
[18:32:39 CEST] <prelude2004c> i use hls playout but my input is mpeg-ts
[18:32:43 CEST] <prelude2004c>  -vf "field,scale=ih*2" this is wrong
[18:33:00 CEST] <prelude2004c> the scale is wrong i am sure... going to look at google unless someone sees the obvious
[18:34:41 CEST] <prelude2004c> my mind right now is on setsar or setdar in the video filter
[18:34:51 CEST] <prelude2004c> maybe metadata is in sar data ?
[18:57:28 CEST] <CoJaBo> So the BMP bug isn't fixed :/
[19:11:42 CEST] <durandal_170> what?
[19:11:52 CEST] <BtbN> Is setting width/height in AVCodecContext the right thing to do once the decoder extracted these from the bitstream?
[19:12:33 CEST] <durandal_170> CoJaBo: tried ffmpeg after fix?
[19:12:41 CEST] <BtbN> According to the doxy it is, allright.
[19:13:27 CEST] <durandal_170> BtbN: writing what?
[19:13:37 CEST] <BtbN> a decoder.
[19:14:27 CEST] <durandal_170> of what?
[19:15:08 CEST] <BtbN> h264, via cuvid
[19:15:13 CEST] <CoJaBo> durandal_170: Yes; it crashes the same way, just much later into the input file
[19:15:14 CEST] <DHE> nice, a53cc for nvenc is posted to the mailing list.
[19:15:42 CEST] <BtbN> Well, and also hevc and whatever else CUVID supports. But those are not exposed yet.
[19:15:48 CEST] <CoJaBo> durandal_170: Can you see anything obvious about the fix that would've fixed it only for the attatched testcase? I'll make a new one if need be :/
[19:16:37 CEST] <durandal_170> try make new one
[19:17:07 CEST] <DHE> BtbN: as the author of the libx264 patch, just glad to see the other encoders getting some love
[19:17:40 CEST] <BtbN> durandal_170, the doxy header says "During decoding, the decoder may overwrite those values as required while parsing the data.", so it's fine i assume.
[19:20:25 CEST] <DHE> isn't it the decoder's responsibility to fill those in so the app knows what it's receiving?
[19:20:41 CEST] <BtbN> Or the demuxers
[19:22:21 CEST] <rcombs> `element type mismatch 3 != 0` <-- I've seen this on a lot of AAC streams, even Fraunhofer's channel-check samples
[19:22:38 CEST] <rcombs> is this actually invalid, or what?
[19:34:35 CEST] <CoJaBo> durandal_170: ..so if I cut it down to the segment that it crashes at, it doesn't crash. It only crashes if fed the entire file...
[19:35:04 CEST] <durandal_170> How much big it is?
[19:36:40 CEST] <CoJaBo> 722GB
[19:39:09 CEST] <atomnuker> jesus christ
[19:39:17 CEST] <CoJaBo> durandal_170: fwiw, it spits out an error this time http://pastie.org/pastes/10864381/text?key=gzxyj2huiigib3x0rlg4sq
[19:39:32 CEST] <CoJaBo> atomnuker: yeh, it doesn't even fit on the internal drive >_>
[19:52:23 CEST] <BtbN> Is there a way to signal from the decode function that decoding has permanently failed, and there is no point in sending another frame?
[19:55:30 CEST] <rcombs> atomnuker: possibly relevant re: AAC question
[19:58:12 CEST] <nevcairiel> BtbN: no
[19:58:37 CEST] <BtbN> hm, not overy nice, but so be it.
[19:58:41 CEST] <BtbN> +l
[19:58:54 CEST] <BtbN> Guess the cuvid decoder is done then.
[19:59:14 CEST] <BtbN> Now it needs some stuff in ffmpeg.c to actually do zerocopy transcoding.
[20:03:54 CEST] <atomnuker> rcombs: does it only happen on non-stereo channel layouts?
[20:04:07 CEST] <rcombs> hmm, I don't believe I've seen it on stereo
[20:06:54 CEST] <atomnuker> it should only happen when there's an LFE channel
[20:07:29 CEST] <atomnuker> LFE has an element index of 3
[20:07:47 CEST] <atomnuker> it's special because it has only around 20 spectral coefficients
[20:08:23 CEST] <atomnuker> some encoders/encoder versions seem to put a type index of 0 in there, which is the index for a mono channel
[20:09:11 CEST] <rcombs> is that technically invalid, or just odd?
[20:09:34 CEST] <atomnuker> invalid, you can't do SBR with 20 coefficients
[20:09:47 CEST] <andrey_turkin> prelude2004c: try this https://github.com/tea/FFmpeg/tree/a53
[20:09:52 CEST] <atomnuker> so the decoder turns off SBR for that frame for that channel
[20:10:48 CEST] <andrey_turkin> Command line would look something like that:  ffmpeg -i output.ts -filter_complex '[0:v]split=2[main][cc]; [main]fps=30,scale=w=iw/2:h=-1[main_out]; [main_out][cc]combine_a53' -c:v nvenc -a53cc 1 scaled.mpg
[20:12:16 CEST] <rcombs> atomnuker: atomnuker maybe downgrade to a warning and/or make the message a little more informative?
[20:13:05 CEST] <rcombs> whoops double HL
[20:15:02 CEST] <atomnuker> I'm trying to find where the hell it gets set in the first place
[20:15:15 CEST] <rcombs> since it's technically invalid but apparently doesn't cause any user-facing issues
[20:15:33 CEST] <rcombs> so I occasionally get users posting that and assuming it's the cause of <whatever problem they're having>
[20:15:59 CEST] <rcombs> it's an error -> must be the cause of my problem
[20:16:39 CEST] <rcombs> since it happens in the Fraunhofer channel layout samples, maybe the FDK encoder?
[20:17:10 CEST] <rcombs> (I dunno if they also have their own internal one)
[20:27:29 CEST] <atomnuker> might be better to fix it by simply not calling sbr_apply for TYPE_LFE
[20:28:03 CEST] <atomnuker> maybe it was overlooked and all testing was done with stereo files
[20:28:58 CEST] <atomnuker> let me just test if the output's correct in the first place
[20:29:10 CEST] <atomnuker> (got an inception rip here which prints the warning on every frame)
[20:40:14 CEST] <rcombs> cool, thanks
[20:49:15 CEST] <cone-816> ffmpeg 03Michael Niedermayer 07master:d953b2857b5b: avcodec/utils: initialize delay in avcodec_parameters_to_context()
[20:51:38 CEST] <atomnuker> grr, the channel still needs to get upsampled, so sbr_turnoff has to be called
[20:56:12 CEST] <atomnuker> rcombs: do you remember/can you try to find a 5.1 HE-AAC sample which doesn't trigger that warning
[20:57:00 CEST] <atomnuker> it could be that the print simply shouldn't exist
[20:58:41 CEST] <rcombs> nothing off the top of my head, but that doesn't mean it doesn't exist
[21:10:03 CEST] <atomnuker> what encoder even does 5.1 with SBR
[21:10:18 CEST] <atomnuker> libfdk_aac gives up with more than 2 channels
[21:12:31 CEST] <BtbN> weird format name
[21:25:11 CEST] <BtbN> new decoder means lavc minor bump, right?
[21:27:22 CEST] <BtbN> andrey_turkin, you have maxwell gen 2 hardware, right?
[21:27:29 CEST] <BtbN> so, the one with a hevc DEcoder.
[21:29:49 CEST] <BtbN> could you test this: https://github.com/BtbN/FFmpeg/tree/cuvid
[21:30:33 CEST] <BtbN> ffmpeg -c:v hevc_cuvid -i some_hevc_video.mkv -c:v nvenc -y -o out.mp4
[21:39:10 CEST] <CoJaBo> What is the filesize limit for sample clips to ffmpeg?
[21:39:23 CEST] <rcombs> atomnuker: just confirmed audiotoolbox generates that
[21:39:26 CEST] <rcombs> including producing the warning
[21:40:03 CEST] <BtbN> CoJaBo, what? You mean the max input file size?
[21:40:13 CEST] <CoJaBo> Bug testcases
[21:40:23 CEST] <BtbN> ah
[21:40:33 CEST] <CoJaBo> I can't actually figure out how to cut this one dow this time... :/
[21:40:40 CEST] <BtbN> No idea, as small as possible, as large as neccessary I'd guess.
[21:40:54 CEST] <CoJaBo> ....come to think of it tho, IS there a max filesize limit (be it intentional or not) for bmp_pipe?
[21:41:04 CEST] <CoJaBo> It's nearly a terabyte
[21:41:23 CEST] <CoJaBo> At my connection speed, it would take almost a month to upload alone :/
[21:41:37 CEST] <BtbN> uhm, i think that's a bit too much
[21:41:43 CEST] <CoJaBo> Yeh :/
[21:41:54 CEST] <CoJaBo> It does not even fit on my internal drive
[21:42:38 CEST] <CoJaBo> This is the bug in question, anyway https://trac.ffmpeg.org/ticket/5598
[21:43:07 CEST] <CoJaBo> I was trying to look over the fix to figure out what else is going wrong, but I can't figure out what either the code or fix are doing :/
[21:43:20 CEST] <BtbN> do you know which frame in that huge file is causing it?
[21:44:26 CEST] <CoJaBo> I'm pretty sure I can truncate it after the bad frame, but I don't think that shaves that much off this time
[21:44:50 CEST] <BtbN> well, if it's just that bad frame, without any other ones, is that enough for trigger the bug?
[21:45:10 CEST] <CoJaBo> That was the first time, but not now; it only crashes if fed the entire input file from the start
[21:45:31 CEST] <CoJaBo> I actually can't figure out what kind of scenario would cause that with bmp_pipe tho??
[21:45:36 CEST] <BtbN> Did you considder the possibility that you might just plain run out of ram here?
[21:50:25 CEST] <CoJaBo> BtbN: RAM usage is a couple MB up till it hits the bad spot; it then spikes to 6GB, tho it *did* appear to render the rest of the file after that
[21:51:01 CEST] <BtbN> can you just cut of the beginning of the file, until that bad spot?
[21:52:04 CEST] <CoJaBo> ..something is weird here
[21:52:47 CEST] <CoJaBo> It looks like its only 5 or so mins in actually; that's probably closer to 50GB, tho that's still massive..
[21:53:00 CEST] <CoJaBo> Let me test to make sure I cut the correct frame tho....
[21:54:50 CEST] <BtbN> doesn't need to be overly precise
[21:55:04 CEST] <BtbN> if there's a few MB in front of it it doesn't matter
[21:55:35 CEST] <CoJaBo> Ok, I had the right frame number, just messed up when converting it to a size
[21:55:48 CEST] <CoJaBo> I was afraid I was off by a few hundred GB lol...
[21:56:30 CEST] <BtbN> are all images the exact same size? (I guess they are, as it's bmp?)
[21:56:35 CEST] <CoJaBo> Yes
[21:56:41 CEST] <BtbN> yeah, then it's not too hard
[21:57:02 CEST] <CoJaBo> Which is why I don't understand how it can crash at a specific point, but only when feed a lot of data before that point
[21:57:26 CEST] <CoJaBo> Unless there's some counter or something weird that's overflowing, but that's hard to see either..
[21:58:09 CEST] <BtbN> Is there some way i can generate a file that reproduces it?
[21:58:21 CEST] <BtbN> without needing 1TB+ of storage
[21:59:58 CEST] <CoJaBo> BtbN: If it's purely size-dependent, you can use the shell command in the bug to generate a sufficiently large file (use 7500 frames). But I don't think it is at this point...
[22:00:27 CEST] <BtbN> I have ~20GB of space available on my dev machine right now
[22:00:55 CEST] <CoJaBo> I believe I've found a 33GB span that triggers it
[22:01:46 CEST] <CoJaBo> Trying to narrow that down, but slow laptop is slow :/
[22:02:41 CEST] <CoJaBo> I'm not 100% sure this span is the same bug tho; the framecount is off, but it does not go hogwild on RAM
[22:04:22 CEST] <CoJaBo> Also doesn't generate any errors, huh.
[22:05:29 CEST] <BtbN> Maybe run memcheck on that machine for a while
[22:07:07 CEST] <CoJaBo> It happens at the same frame each run, but changing the start point changes the behaviour somehow (both where it crashes and how)
[22:35:29 CEST] <CoJaBo> ..so yeah, there was an old copy of ffmpeg in the directory i changed to :/
[22:42:03 CEST] <CoJaBo> BtbN: Def not a RAM issue; crashes on the same frame on 2 different laptops
[22:42:54 CEST] <BtbN> hm
[22:43:54 CEST] <flux> if you have the time (day? week?-)) you could try run it under valgrind?-o
[22:44:48 CEST] <BtbN> doesn't valgrind go crazy if you run it on ffmpeg anyway?
[22:44:49 CEST] <flux> though perhaps it's difficult if there is no actual crash
[22:45:06 CEST] <flux> btbn, I guess it should depend on if it uses hw accel or other difficult-to-understand-for-valgrind features
[22:45:56 CEST] <flux> cojabo, what you could do: pick a memory debugger library (ie. electric fence) and then terminate the program in the error condition so that the library gets to do its job
[22:46:18 CEST] <flux> then the allocation debugger should tell where the numerous allocations have been made
[23:09:23 CEST] <CoJaBo> flux: heh.. These take several hours to run as is, I'm running them on all computrs I have access to :/
[23:10:42 CEST] <CoJaBo> ...I've had a breakthru
[23:11:22 CEST] <CoJaBo> The content before doesn't matter, just the position in the stream
[23:12:53 CEST] <CoJaBo> I've found a case that I think I can reduce to a 25GB sparse file
[23:13:14 CEST] <cone-816> ffmpeg 03Michael Niedermayer 07master:bb3388fd60e5: avformat/dump: Print tbc value
[23:18:27 CEST] <CoJaBo> flux: What can I do to make ffmpeg blow thru an input file as fast as possible? E.g., just read the whole thing without actually doing anything
[23:27:12 CEST] <CoJaBo> -f null works... this is a lot easier to debug when it takes minutes instead of hours to run a file thru
[23:55:47 CEST] <BtbN> Yay, CUDA "zero-copy" transcoding works.
[00:00:00 CEST] --- Sun Jun  5 2016