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

[burek]

[00:00:24 CEST] <philipl> exit
[00:01:42 CEST] <michaelni> syntax error
[00:11:39 CEST] <michaelni> ubitux, the problem is that while sps and pps in the context reviously where a copy that was unaffected by newly occuring *ps they now are just pointing in the array of ps so when a new ps comes in it wipes out the activated set
[00:12:04 CEST] <michaelni> at least thats how it looks in the diff, didnt debug this
[00:12:44 CEST] <nevcairiel> do they share the same list in frame threading? or does every thread at least get its own?
[00:13:48 CEST] <michaelni> i suspect frame threads get their own
[00:14:57 CEST] <michaelni> if my guess of all this is correct, the potential solutions are, leave the parameter sets as copies or make them full references that can survive their parents deaths or disallow sets between slices
[00:15:16 CEST] <nevcairiel> changes between slices are not allowed anyway, right?
[00:15:42 CEST] <michaelni> IIRC no, iam not sure there are files that contain changes
[00:15:54 CEST] <michaelni> there certainly are some with changes at field level
[00:16:13 CEST] <michaelni> possibly minor changes at slice level too (like quant matrixes) iam not sure ATM
[00:22:48 CEST] <michaelni> probably makes sense to go with the simplest solution and if that breaks something change it
[00:48:00 CEST] <jsebechlebsky> I've tried to `make fate`, I'm getting make: *** No rule to make target `libavcodec/mathops.c', needed by `libavcodec/mathops-test.o'.  Stop. Are the tests momentarily broken or am I doing something wrong?
[00:52:05 CEST] <jamrial> jsebechlebsky: try cleaning your build folder, either "make clean" or "rm libavcodec/mathops*"
[00:53:02 CEST] <jamrial> the latter only if you're doing an out of tree build
[00:53:26 CEST] <jamrial> otherwise you'll delete source files :p
[00:58:12 CEST] <jsebechlebsky> jamrial: luckily I've realized that before trying :-D I'm re-running the fate currently, but I guess it will solve the problem otherwise others would already have experienced the same problem :) Thanks for advice! 
[00:59:18 CEST] <jsebechlebsky> but I guess I should set up out of tree build anyway... 
[01:03:41 CEST] <cone-114> ffmpeg 03Lars Kiesow 07master:e9bb80d3dcc5: doc/filters: Remove duplicated setdar example
[01:35:57 CEST] <iive> ubitux: sorry for spamming the irc channel, but the discussion was on topic, since it was project policy, not geo politics.
[01:37:06 CEST] <iive> sometimes opposing views should be challenged. If somebody still feels like debating, feel free to do it, in public or private.
[01:44:56 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07master:e78515f2ae53: tests/fate/h264: Add test for xavc and somewhat odd pps/sps
[02:57:08 CEST] <michaelni> ubitux, this breaks too: ./ffmpeg -flags2 chunks -i ~/tickets/631/attachment.mp4  -f null -
[02:57:42 CEST] <michaelni> http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20111108/dae58f17/attachment.mp4
[03:01:47 CEST] <michaelni> fate-h264-xavc-4389 with threads too is broken
[03:10:22 CEST] <michaelni> ubitux, http://pastebin.com/Pu08PpDi <-- some quickly writen code for testing sps/pps with seperate references, feel free to use as you see fit
[04:38:11 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07master:79b6c9acd501: fate/prores: use aac fixed for audio to fix fate failures on arm
[07:14:48 CEST] <prelude2004c> hey guys.. so i have setup vdpau, h264, etc.. nothing pulls out the closed caption.. i am told closed caption works h264 encoding but now i am using that and it is not the case.
[07:45:40 CEST] <prelude2004c> yay.... !   -a53cc 1 works on h264.. so now i just have to port over to nvenc.c right ?
[07:50:20 CEST] <prelude2004c> shit.. i dont know how to do it :( 
[08:22:54 CEST] <prelude2004c> is anyone here to dump the a53cc code from h264.c to nvenc.c ? i need this working :( 
[08:23:19 CEST] <prelude2004c> for someone who understands what they are doing it may be as simple as just copy / paste but i dont know where to copy and paste it into
[10:10:35 CEST] <cone-875> ffmpeg 03Matthieu Bouron 07master:e0df56f25d09: lavc/vaapi_encoder_{h264,h265}: fix bad format warning
[10:21:49 CEST] <andrey_turkin> prelude2004c: I think h264.c has decoder side of things. You need encoder side for nvenc; if I understand correctly you need to ask nvenc to embed additional data in the bitstream somehow
[10:26:17 CEST] <cone-875> ffmpeg 03Matthieu Bouron 07master:15432a903e36: lavc/mediacodecdec_h264: switch to new BSF API
[10:26:18 CEST] <cone-875> ffmpeg 03Matthieu Bouron 07master:12f47539ca73: lavc/mediacodecdec_h264: rename input_ref to input_pkt
[10:26:37 CEST] <andrey_turkin> SEI payload code can be stolen from qsvenc_h264.c; nvEncodeAPI has pretty obvious tunable to add payloads to a frame
[11:30:02 CEST] <ubitux> michaelni: i've been reading the specs; so iiuc, you are sometimes allowed to reference different pps but only with the same content
[11:30:24 CEST] <ubitux> they seem to insist on the fact that it's the content that matters
[11:32:52 CEST] <michaelni> ubitux, i dont think you are allowed to reference diferent pps
[11:33:11 CEST] <michaelni> "When present, the value of the slice header syntax elements pic_parameter_set_id, frame_num, field_pic_flag,
[11:33:11 CEST] <michaelni> bottom_field_flag,     idr_pic_id,     pic_order_cnt_lsb,    delta_pic_order_cnt_bottom,    delta_pic_order_cnt[ 0 ],
[11:33:11 CEST] <michaelni> delta_pic_order_cnt[ 1 ], sp_for_switch_flag, and slice_group_change_cycle shall be the same in all slice headers of a coded picture."
[11:36:12 CEST] <ubitux> michaelni: http://ubitux.fr/pub/pics/pps-content.png
[11:36:15 CEST] <ubitux> refering to that
[11:37:04 CEST] <ubitux> will look at 7.4.3 you're quoting
[11:39:39 CEST] <michaelni> ubitux, i think they mean its allowed to repeat a PPS at a random place but only if its unchanged
[11:42:33 CEST] <michaelni> ubitux, there is also "7.4.1.2.4 Detection of the first VCL NAL unit of a primary coded picture" which lists "pic_parameter_set_id differs in value."
[11:53:52 CEST] <michaelni> ubitux, also keep in mind "coded picture: A coded representation of a picture. A coded picture may be either a coded field or a coded frame. ..."
[11:54:34 CEST] <michaelni> the spec allows pps changes between fields, there can be 2 fields in a AVPacket
[12:11:41 CEST] <BtbN> Hm, I'd say the cuvid decoder is working now. But something in ffmpeg/lav* disagrees with me there.
[12:21:26 CEST] <cone-875> ffmpeg 03Thomas Bernard 07master:1f8c0e44cb17: avformat/au: Write MetaData in AU Sun audio file header
[12:53:02 CEST] <cone-875> ffmpeg 03Nicolas George 07master:8b05a7ffe4d7: lavf/udp: fix dead code.
[14:59:46 CEST] <ubitux> michaelni: i'm a bit uncomfortable about having this change in the merge commit (the pastebin diff you sent)
[15:00:56 CEST] <michaelni> ubitux, what else do you suggest ?
[15:03:58 CEST] <ubitux> it might be unavoidable
[15:04:10 CEST] <ubitux> michaelni: can we have a fate test that covers this case?
[15:05:05 CEST] <michaelni> ubitux, e78515f2ae5383bd7e0a2ca2cac126180fad1492 (failed only with threads enabled though IIRC)
[15:05:37 CEST] <michaelni> ive also another one locally for something keyframe related but i didnt push as i suspect its a duplicate
[15:06:14 CEST] <ubitux> i don't have this hash locally
[15:06:24 CEST] <nevcairiel> did one of you test one of those broken cases with avconv, if its something in our base or just generally broken with the new concept=
[15:06:27 CEST] <nevcairiel> ?
[15:06:28 CEST] <ubitux> was that one of my tmp WIP merge?
[15:06:54 CEST] <ubitux> nevcairiel: most of the tests with avconv just error out quickly
[15:07:01 CEST] <ubitux> "can't parse nal, bye"
[15:07:03 CEST] <ubitux> iirc
[15:07:13 CEST] <nevcairiel> but we expect them to play, i guess?
[15:07:14 CEST] <michaelni> also the h->dequant_coeff_pps != pps_id -> "h->ps.pps != pps" change caused problems
[15:07:37 CEST] <ubitux> i followed the way it was done in libav
[15:08:44 CEST] <michaelni> ubitux, http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=e78515f2ae5383bd7e0a2ca2cac126180fad1492
[15:09:04 CEST] <ubitux> oh, new one, my bad
[15:09:09 CEST] <ubitux> cool, thanks
[15:09:55 CEST] <michaelni> also ill have to leave soon for probebly 2-3h 
[15:10:20 CEST] <michaelni> just saying so you dont think i ignore you ;)
[15:10:22 CEST] <nevcairiel> are all these problems caused by referencing the pps/sps instead of copying it?
[15:11:08 CEST] <michaelni> i dont know, i dont know what caused the keyframe & dts effects also i dont know what caused the chunk issue
[15:11:34 CEST] <michaelni> they where still there with my sps/pps ref patch
[15:11:47 CEST] <nevcairiel> overall the change should really not have that big of an impact, it just changes where the sps/pps are stored - with one key difference, they are not copied but referenced from the list
[15:12:23 CEST] <ubitux> there are actually much more changes
[15:12:55 CEST] <ubitux> like, the parser also doesn't use the h264context anymore to store the pps/sps
[15:13:09 CEST] <nevcairiel> well ok, that was the entire purpose of this change
[15:13:31 CEST] <ubitux> but it still uses the h264context which gets its pps/sps updated in some ways
[15:13:41 CEST] <nevcairiel> (personally i find this "parser shall be separate" thing a bit of a silly thing to spend so much time on, but shrug)
[15:14:43 CEST] <ubitux> so what michaelni fixed in his diff is to make sure we don't end up with a current pps/sps being NULL
[15:14:56 CEST] <ubitux> in case the pps/sps is removed from the active list of available sps/pps
[15:15:01 CEST] <ubitux> iiuc
[15:15:19 CEST] <nevcairiel> making the active sps/pps pointers seems like such an annoying idea
[15:15:32 CEST] <michaelni> ubitux, yes, not null and not changing mysteriously 
[15:15:55 CEST] <michaelni> nevcairiel, yes
[15:16:14 CEST] <ubitux> nevcairiel: many changes seems to rely on pointer equality that were specific fields equality before
[15:16:39 CEST] <nevcairiel> s/ps.sps->/ps.sps./ .. there i fixed it for the codebase =p
[15:17:13 CEST] <ubitux> well
[15:17:23 CEST] <ubitux> we could have the sps_ref not a pointer
[15:17:34 CEST] <ubitux> and ps.sps/pps still pointers to these
[15:17:39 CEST] <ubitux> :p
[15:17:54 CEST] <michaelni> ubitux, if you dont want the sps ref patch you could try to block sps/pps parsing to afect the active set
[15:18:16 CEST] <michaelni> the only tricky part is probably to let the ones between fields through
[15:18:29 CEST] <ubitux> it's not that i don't want, i'm just trying to figure out the impact on a codebase i don't know :)
[15:18:29 CEST] <michaelni> that could be done prior to the merge in a seperate commit
[15:19:59 CEST] <ubitux> btw, hevc seems to have this code already
[15:20:08 CEST] <ubitux> if you look at remove_{sps,pps}
[15:20:12 CEST] <nevcairiel> is generally modelled after hevc
[15:20:16 CEST] <nevcairiel> its*
[15:20:53 CEST] <michaelni> we have significantly fewer hevc samples so we wouldnt notice if that breaks something also i didnt check the hevc spec, might be slight differences
[15:21:43 CEST] <ubitux> so mmh, you think we can integrate your change before the merge somehow?
[15:22:29 CEST] <michaelni> btw why is the sps/pps anti copy change not seperate of other changes ?
[15:22:46 CEST] <michaelni> spliting that out might also make our life easier
[15:23:39 CEST] <michaelni> just some random ideas, i still didnt truly review the diff
[15:23:47 CEST] <ubitux> probably yes but how do you split a merge? :P
[15:24:51 CEST] <michaelni> thats easy, normal commits and a merge that does nothing or normal commit and a merge doing a subset
[15:25:05 CEST] <ubitux> ok
[15:25:09 CEST] <ubitux> btw, in the remove_pps, if we just don't nullify the current pps
[15:25:37 CEST] <ubitux> but still keep it referencing the same pps id (but then with eventual different pps data)
[15:25:48 CEST] <ubitux> will that be a problem in the cases we are trying to handle?
[15:26:12 CEST] <ubitux> i guess the parameters changes could have a security impact?
[15:26:47 CEST] <michaelni> yes, maybe, iam not sure, there are alot of checks 
[15:27:15 CEST] <michaelni> also with slice threads you decode several slices at once using the same SPS/PPS
[15:27:45 CEST] <michaelni> if that changes at some point between slice header parsing and later stages something would go wrong
[15:28:07 CEST] <ubitux> ok
[15:28:15 CEST] <michaelni> this whole sps/pps code is kind of annying on its own without merges :)
[15:29:41 CEST] <michaelni> need to leave now, will check log later
[15:30:01 CEST] <ubitux> see you, thanks
[15:42:57 CEST] <ubitux> nevcairiel: so to answer your question more accurately, libav crashes on one, and can't decode another
[15:43:18 CEST] <ubitux> so yeah the issues mostly overlap and we have to fix it ourselves
[15:44:05 CEST] <BtbN> Seems like the code in ffmpeg.c is not prepared for decoders producing hw frames
[15:47:01 CEST] <prelude2004c> <andrey_turkin>, thank you
[15:47:08 CEST] <prelude2004c> the code is already in h264.c 
[15:47:10 CEST] <nevcairiel> ubitux: i suppose thats "good"
[15:47:55 CEST] <prelude2004c> i need the code in nvenc.c to also support the ac53 . isn't it as simple as porting the code over to that .c library
[15:49:13 CEST] <andrey_turkin> it is
[15:49:31 CEST] <BtbN> So you want to patch the bitstream it generates to inject more stuff? oO
[15:49:48 CEST] <andrey_turkin> BtbN: nvenc supports injecting stuff
[15:50:32 CEST] <andrey_turkin> as I said earlier, the code for that is not in h264.c it is in qsvenc_h264.c
[15:51:07 CEST] <andrey_turkin> thankfully there shouldn't be need to patch bitstream
[15:51:25 CEST] <prelude2004c> when i take my transport stream input and i use the -a53_cc 1 , the closed caption works 
[15:51:40 CEST] <prelude2004c> when i use -c:v nvenc i can't use that flag to enable the cc
[15:51:57 CEST] <prelude2004c> so i would like to have the -a53_cc 1 enabled in nvenc so i can see the closed caption data
[15:53:20 CEST] <prelude2004c> i just don't know what to do about getting the closed caption data that is inside the video any other way :( 
[15:53:40 CEST] <prelude2004c> having -c:s copy doesn't do anything
[15:54:16 CEST] <BtbN> What kind of horrible hack is this?
[15:54:21 CEST] <andrey_turkin> c:s wouldn't work since A53 is a special case. It is not separate stream, it is attached to a video
[15:54:24 CEST] <andrey_turkin> I know, right?
[15:54:27 CEST] <BtbN> Why are there captions _in the video stream_?!
[15:54:35 CEST] <andrey_turkin> ask ATSC about that
[15:55:09 CEST] <prelude2004c> ya its a pain in the ass.. captions and teletext are inside the video itself.. not as a seperate PID.. apparently it is how it is done in north america :( 
[15:55:13 CEST] <andrey_turkin> and if you happen to also start looking at SDI you'll ask yourself that few more times
[15:55:35 CEST] <andrey_turkin> yes, exactly. So every H26* encoder and decoder has to support them...
[15:56:05 CEST] <prelude2004c> yup...so we have to also have nvenc support it as people use that for hardware encoding instead of the CPU's
[15:56:25 CEST] <prelude2004c> the ASIC chips inside the nvidia cards are so much faster and we use very little cpu resources
[15:56:34 CEST] <BtbN> But they have horrible quality.
[15:56:42 CEST] <andrey_turkin> altough I'm not sure why there is a -a53_cc flag anyway. Why not just attach captions if available without additional flags to enable that explicitely
[15:56:52 CEST] <prelude2004c> no, they don't... the quality is as good or better than the CPU's
[15:56:56 CEST] <BtbN> lol no
[15:56:58 CEST] <prelude2004c> the new cards support lossless
[15:57:09 CEST] <BtbN> x264 is _way_ ahead in terms of quality.
[15:57:28 CEST] <andrey_turkin> well it is better in quality vs x264 with preset=ultrafast )
[15:57:34 CEST] <BtbN> andrey_turkin, the flag makes sense, but i'd enable it by default.
[15:57:39 CEST] <prelude2004c> i have not found that BtbN ...  i use llhq
[15:57:42 CEST] <andrey_turkin> well at least that
[15:57:56 CEST] <andrey_turkin> I can give it a stab later today
[15:58:16 CEST] <prelude2004c> andrey_turkin, that would be awsome 
[15:58:33 CEST] <BtbN> I'm not sure if nvenc is the right place for that code.
[15:58:42 CEST] <prelude2004c> i want to finalize this thing.... btw BtbN , i got vdpau and nvenc going instead of the nvtranscoder and the cpu usage is pretty much the same.. so i am good with that
[15:58:48 CEST] <prelude2004c> much simpler command.. thank you for that
[15:58:57 CEST] <BtbN> It should be in some central place, so all the encoders can just use it.
[15:59:02 CEST] <ubitux> nevcairiel: ah, and it's also moving the dequant code, which has various effects on the random field check we do for those
[15:59:02 CEST] <andrey_turkin> BtbN: A53 doesn't look THAT horrible after you see subtitles encoded into analog VBI which is then placed into VANC area of SDI
[15:59:28 CEST] <prelude2004c> as andrey_turkin said.... why isn't it supported by default.. i mean if closed caption is there.. wouldn't everyone just want the option to be there.. why seperate or put up a flag in the first place.
[16:00:13 CEST] <prelude2004c> should be ON by default and should be turned off with flag if someone wants it off. 
[16:00:32 CEST] <andrey_turkin> BtbN: how do you propose to do that? There's basically one thing to do which is to encode subtitles into SEI message, and then it is codec-specific API to attach that message to a frame
[16:00:41 CEST] <Illya> Anyone use emacs for ASM stuff? How have you set it up for ffmpeg? (I know about the C styles on the website, and I already have nasm-mode on)
[16:00:54 CEST] <BtbN> the sei payload should be the exact same everywhere?
[16:01:02 CEST] <andrey_turkin> yes
[16:01:13 CEST] <BtbN> and generating that is what most of that code does.
[16:01:25 CEST] <andrey_turkin> yes
[16:01:42 CEST] <andrey_turkin> of course one can move that to utils.c or something
[16:02:10 CEST] <andrey_turkin> or mpegutils.c
[16:04:24 CEST] <ubitux> Illya: "asm" is very vague for syntax color, you should probably look for arch specific asm syntax (not an emacs user, can't answer)
[16:04:51 CEST] <andrey_turkin> on topic of horrible hacks - there are also two standards 608 and 708 and 708 captions usually also contain 608 captions just for kicks. I had some fuuun getting that all supported in a sane way
[16:06:33 CEST] <ubitux> supported in ccaption_dec.c 
[16:06:36 CEST] <ubitux> @_@
[16:07:01 CEST] <Illya> ubitux: sorry, I meant the ffmpeg style asm. 
[16:07:23 CEST] <Illya> ohh. you mean, like about different asm arch's i.e. arm/x86
[16:07:26 CEST] <andrey_turkin> one has to first get them off SDI stream
[16:07:41 CEST] <andrey_turkin> and then decide whether to use 608 at all if 708 is present
[16:07:48 CEST] <ubitux> Illya: yeah, and even on x86 you have different syntax (AT&T, intel)
[16:08:10 CEST] <ubitux> (ffmpeg uses intel on x86 for external asm files though)
[16:08:39 CEST] <andrey_turkin> I think ccaption_dec.c only supports 608 part?
[16:10:06 CEST] <ubitux> not according to the desc
[16:10:32 CEST] <andrey_turkin> from that I remember 708 is pretty big. Also code seems to filter 608 part out
[16:14:34 CEST] <andrey_turkin>     //skip 708 data     if (cc_type == 3 || cc_type == 2)         return AVERROR_PATCHWELCOME;
[16:22:28 CEST] <prelude2004c> hey andrey_turkin, thank you for looking into this.. been at it for like 2 weeks trying to find a work around :(
[16:22:40 CEST] <prelude2004c> this could not be more welcomed
[16:23:12 CEST] <andrey_turkin> I don't think there is a work around. Someone just has to bite the bullet and code it in
[16:23:43 CEST] <prelude2004c> if i could code C i would have done it already and updated the patch :(
[16:23:58 CEST] <prelude2004c> its time for me to start learning.. any suggestions ? 
[16:24:16 CEST] <prelude2004c> whats a good place to start?
[17:53:37 CEST] <ubitux> https://github.com/ubitux/FFmpeg/commit/3d35aa3d160f024e01e13ff2dcd29f1c493840d8
[17:53:39 CEST] <ubitux> i need help
[17:53:42 CEST] <ubitux> nevcairiel and michaelni 
[17:53:56 CEST] <ubitux> i summarized all the changes and what it fixed
[17:54:02 CEST] <ubitux> as well as what's left to fix or ignore
[17:54:21 CEST] <ubitux> this is starting to get way above my head
[17:57:20 CEST] <BtbN> great, seems like it's impossible to achive a full hw cuvid chain without heavily modifying ffmpeg*.c
[17:57:40 CEST] <BtbN> the init calls just happen way too early to pass the hwcontext from decoder to encoder.
[18:02:17 CEST] <jkqxz> This is a hwaccel rather than a decoder?  The way I use if for vaapi is by putting 'format=sw_format|hw_format,hwupload' at the start of the filter chain.
[18:02:29 CEST] <jkqxz> The first init succeeds with the sw_format and then when the decoder later returns hw_format it reconfigures to what you actually want (hwupload passes through hw frames unchanged).
[18:03:25 CEST] <DHE> something has come up for me that makes me want to add a feature: gzip:// file support, or something to that effect. files being transparently compressed
[18:03:38 CEST] <DHE> the specific use case is the HLS playlist
[18:05:15 CEST] <iive> DHE: i think that's been discussed before, even with some patches. Not sure what happened at the end.
[18:05:25 CEST] <BtbN> jkqxz, no, it's a complete decoder, which outputs CUDA pix_fmt frames.
[18:06:39 CEST] <BtbN> The problem is, to initialize the hw_frames_ctx, it needs picture width/height, which is not known until the first frame is decoded.
[18:07:37 CEST] <jkqxz> That's more fun.  You can make it kindof work by giving it a fake hwaccel instance to get the same behaviour, but it is just horrible.
[18:08:05 CEST] <BtbN> Yeah, a ffmpeg_qsv.c like solution seems better to me. So that creates the context and stuff.
[18:08:18 CEST] <BtbN> The only problem there is: That one has even less of an idea of the width/height
[18:09:21 CEST] <iive> BtbN: is width/height decoded by the driver, or by ffmpeg decoder?
[18:09:34 CEST] <BtbN> by cuvid
[18:09:50 CEST] <jkqxz> The latest set from elenril wants the user to create the hw_frames_ctx in the get_format callback, but that doesn't work if the frames (and information about them) are actually owned by the source API.
[18:10:26 CEST] <BtbN> I could easily make the decoder work with an external context, that's not the problem.
[18:10:48 CEST] <BtbN> The problem is, the cuda hwframes stuff needs to know the width/height and pix_fmt at init time, for the buffer pool
[18:11:15 CEST] <BtbN> Maybe i can allocate it, so I can pass it everywhere, but only init it on the first frame.
[18:12:32 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/hwcontext_cuda.c#L83 that one
[18:12:55 CEST] <jkqxz> That's really the same problem, I think.  If the source owns the frames you have to make the hw_frames_ctx anyway, so you need that information at the same time.
[18:13:04 CEST] <iive> BtbN: width/height should be known and available when get_format() callback is called.
[18:13:27 CEST] <BtbN> get_format callback?
[18:13:54 CEST] <jkqxz> iive:  They aren't if your external decoder is nasty and doesn't provide that information until it actually gives you a frame.
[18:14:15 CEST] <BtbN> It's not about it giving me a frame
[18:14:24 CEST] <BtbN> it gives me that information as soon as it has it available.
[18:14:32 CEST] <BtbN> But it needs to parse some bitstream for that.
[18:14:43 CEST] <BtbN> So it's not possible ad decode_init
[18:14:46 CEST] <BtbN> *at
[18:15:42 CEST] <iive> BtbN: isn't that the case for quite a lot of formats. e.g. mpeg2 have headers inside the bitstream
[18:15:56 CEST] <iive> so you need to feed it at least one packet to be parsed.
[18:16:01 CEST] <jkqxz> Hmm.  What is wrong with supplying the hw_frames_ctx externally at get_format() time then?
[18:16:18 CEST] <BtbN> initializing the hw_frames_ctx needs width/height for cuda.
[18:16:42 CEST] <BtbN> I'm don't have any get_format thing in my cuvid decoder. Did I just miss that?
[18:16:45 CEST] <jkqxz> You just said that you can get that without any frame decode.
[18:17:05 CEST] <BtbN> yeah, but it needs to call decode once, so there is some data to parse
[18:17:39 CEST] <iive> BtbN: yes, get_format() is called when this data is available. width/height/color format
[18:18:09 CEST] <BtbN> https://github.com/BtbN/FFmpeg/blob/master/libavcodec/cuvid.c that's the current implementation. Is get_format just another AVCodec callback I can implement?
[18:18:51 CEST] <iive> i think that vdpau checks few more things during get_format(), e.g. profile and stuff.
[18:18:52 CEST] <jkqxz> get_format() calls back from decode() when it needs to initialise a new stream form.  If you look at H.264, you get it when the parameter sets change and it needs to reinitialise.
[18:20:59 CEST] <jkqxz> Yeah, for hwaccels in ffmpeg.c get_format() lands in the hwaccel code to test whether it can actually support that stream (profile, colour format, etc.), and do the relevant setup.
[18:22:08 CEST] <jkqxz> This is also how the software fallback works - the hwaccel codec in ffmpeg_xxx.c can return an error and then the normal software code will run to make it set up something using software only.
[18:35:42 CEST] <BtbN> I'm not sure I understand that propperly yet. So in my decode_init, I call ff_get_format, which calls the get_format callback in the avctx?
[18:39:01 CEST] <BtbN> This cuvid decoder is not a regular hwaccell, like vdpau/vaapi/dxva. It's a full decoder.
[18:40:36 CEST] <BtbN> But looking at get_format in ffmpeg.c I understand why qsv has this dummy-HWAccel
[18:44:29 CEST] <jkqxz> Yeah, I think you end up needing the dummy-hwaccel.  Other things have it too - have a look at lavc/mmaldec.c.
[18:45:18 CEST] <BtbN> But I don't understand how get_format would help me there. It's also called at init time, before any data has been parsed.
[18:45:36 CEST] <jkqxz> Are cuda contexts interchangable such that you can create a new one and have the frames from a different one work with it?
[18:45:44 CEST] <BtbN> no
[18:46:18 CEST] <BtbN> But the cuda context is not the issue, it could even be global.
[19:04:20 CEST] <BtbN> Well, going to deal with this tomorrow.
[19:56:17 CEST] <prelude2004c> andrey_turkin , any update on the a53_cc in nvenc.c ?
[19:56:28 CEST] <prelude2004c> or wherever you think it belongs  :)
[19:56:49 CEST] <andrey_turkin> I have a patch, just checking if it works now
[19:57:58 CEST] <andrey_turkin> seems to be working
[19:58:20 CEST] <andrey_turkin> just need to find some sample with actual subtitles in it, not just empty stream
[19:58:41 CEST] <prelude2004c> give me the code i will tell you
[19:58:42 CEST] <prelude2004c> :)
[20:00:32 CEST] <andrey_turkin> https://gist.github.com/tea/f4f241056dcc7bd57c907d2a75c2bd3f
[20:07:41 CEST] <cone-906> ffmpeg 03Jan Sebechlebsky 07master:0e84eee7198d: libavutil/fifo: Fix fifo grow step
[20:16:43 CEST] <prelude2004c> andrey_turkin this on git?
[20:16:47 CEST] <prelude2004c> i got a bunch of errors on the patch
[20:17:22 CEST] <prelude2004c> http://pastebin.com/raw/6akRudsk
[20:17:54 CEST] <andrey_turkin> this is on git
[20:18:04 CEST] <prelude2004c> yup i am using git
[20:18:06 CEST] <andrey_turkin> it seems your master is obsolete
[20:18:10 CEST] <andrey_turkin> like a week old
[20:18:14 CEST] <prelude2004c> let me download again :) 
[20:18:15 CEST] <prelude2004c> sure.
[20:23:23 CEST] <andrey_turkin> it's weird how I always cannot find any test streams when I need them
[20:24:05 CEST] <prelude2004c> ok great.. no errors.. now it messes up DHE patch though 
[20:24:23 CEST] <andrey_turkin> which file?
[20:25:45 CEST] <DHE> I made a custom patch for libavformat/mpegts.c
[20:25:55 CEST] <prelude2004c> 48167d81dc8a89.patch
[20:25:59 CEST] <andrey_turkin> well my patch doesn't go there
[20:26:26 CEST] <prelude2004c> yes but i had to update to latest GIT for your patch to work
[20:26:33 CEST] <DHE> https://github.com/DeHackEd/ffmpeg/commit/48167d81dc8a89  This is the patch. I was planning on submitting it to the mailing list
[20:26:38 CEST] <andrey_turkin> ah I see
[20:26:39 CEST] <prelude2004c> DHE , would your patch already be in latest git ?
[20:27:07 CEST] <DHE> no, I have not submitted it yet
[20:27:27 CEST] <DHE> andrey_turkin: I'm breaking it in myself. the nature of the patch is it takes up to 26.5 hours to test it, or have a test input file that long
[20:27:43 CEST] <DHE> 90 gig test file. fun..
[20:29:09 CEST] <andrey_turkin> yeah. I once had an issue with timestamp wraparound error which occurred once every two weeks or so. That was fun to hunt down and then to test
[20:34:19 CEST] <prelude2004c> yes i have to test that but the problem with that its 26.5 hours takes me sooo long to test
[20:36:39 CEST] <prelude2004c> andrey_turkin .. testing now
[20:38:17 CEST] <prelude2004c> -a53_cc 1 right ?
[20:39:14 CEST] <prelude2004c> Reading option '-a53_cc' ...Unrecognized option 'a53_cc'.
[20:39:28 CEST] <andrey_turkin> a53cc
[20:39:53 CEST] <prelude2004c> my bad.. ok
[20:39:53 CEST] <andrey_turkin> same as with libx264 and qsv
[20:39:56 CEST] <prelude2004c> it started checking.
[20:40:53 CEST] <prelude2004c> ok.. the good news is... its working .. the bad news its all garbage :P 
[20:41:24 CEST] <andrey_turkin> quite possible I messed something up
[20:41:34 CEST] <andrey_turkin> does libx264 still works?
[20:41:37 CEST] <prelude2004c> oh.. and sometimes it freezes up but you are def. on the right track :) 
[20:41:45 CEST] <prelude2004c> yes libx264 works 
[20:41:51 CEST] <andrey_turkin> that is interesting
[20:41:55 CEST] <prelude2004c> or you want me to try again with x264 ? 
[20:42:01 CEST] <andrey_turkin> yes
[20:42:03 CEST] <prelude2004c> problem is i have to recompile with nvenc 
[20:42:22 CEST] <prelude2004c> the dumb thing is.. if i compile with --enable-nvenc .. it always uses nvenc regardless if i put the code as -c:v h264
[20:42:37 CEST] <andrey_turkin> that is strange. maybe libx264 gets switched off
[20:42:58 CEST] <prelude2004c> i think so.. its odd.. should not do that but ya.. i have t0 recompile ffmpeg with nvenc off and then i can use x264
[20:43:03 CEST] <prelude2004c> must be a bug somewhere
[20:43:13 CEST] <prelude2004c> is always been like that for as long as i can remember
[20:43:25 CEST] <andrey_turkin> maybe a feature. libx264 is gpl, nvenc is nonfree. Maybe configure defaults one off if other is on
[20:43:29 CEST] <prelude2004c> the good news is.. we have black lines  :) 
[20:43:38 CEST] <prelude2004c> maybe.
[20:43:52 CEST] <prelude2004c> ok let me make a copy of ffmpeg and re-compile it with just h264 .. one min
[20:45:28 CEST] <JEEB> uhh, why not just specify c:v libx264 :P
[20:45:43 CEST] <prelude2004c> it wont work ... jut uses the nvidia hardware 
[20:45:50 CEST] <prelude2004c> odd right ? 
[20:46:02 CEST] <JEEB> no, you were saying it was doing that with c:v h264
[20:46:07 CEST] <JEEB> which is not the same as c:v libx264
[20:46:16 CEST] <prelude2004c> oh .. then maybe.. let me try right now
[20:46:47 CEST] <JEEB> h264 is an encoder that doesn't exist in FFmpeg, it's just a video format and there's a list of things that gets selected with that video format. c:v libx264 would specifically request libx264
[20:47:19 CEST] <llogan> IIRC, nvenc is now non-non-free
[20:47:41 CEST] <andrey_turkin> ah right
[20:51:10 CEST] <prelude2004c> JEBB , h264 with nvenc works 
[20:51:16 CEST] <prelude2004c> so my bad ( again ) 
[20:51:19 CEST] <prelude2004c> learning quick though
[20:51:32 CEST] <JEEB> yes, because FFmpeg picks along some list for the h264 video format
[20:51:44 CEST] <JEEB> in other words, you never know which exact encoder you get with "h264"
[20:51:54 CEST] <JEEB> it gets even more fun with AAC if it has such a list, too
[20:52:16 CEST] <JEEB> (because avcodec has an internal encoder called like that)
[20:52:18 CEST] <prelude2004c> next time i know.. will never use it again :) 
[20:52:57 CEST] <prelude2004c> so andrey_turkin, yes libx264 works and words are good
[20:53:25 CEST] <andrey_turkin> can you give me a short stream sample with some captions in it? I guess I'll have to do some guessing
[20:53:58 CEST] <prelude2004c> the odd part... even with libx264 sometimes it stops .. not sure if source stops sending or a problem but at least we have something
[20:54:00 CEST] <prelude2004c> which is ok by me
[20:54:43 CEST] <prelude2004c> its odd... yes it works for a little bit then stops
[20:54:54 CEST] <BBB> michaelni: is my counting correct that the vote is currently 4 vs 4? that wouldnt be very helpful, sadly...
[20:55:03 CEST] <prelude2004c> then works again and stops.. its like the cc data only works for like 5 - 6 seconds and then ends.. then it continues and ends .. very strange.
[20:55:34 CEST] <andrey_turkin> weird. 
[20:56:23 CEST] <prelude2004c> yes like i am watching.. the cc is going well maybe 1- 2 seconds behind the chat but.. then it just stops .. then pauses for like 10 seconds.. then continues again .. like data went missing 
[20:57:18 CEST] <andrey_turkin> which is unlikely for A53 since it is strictly frame-level stuff. There is no global state 
[20:58:12 CEST] <prelude2004c> hum...
[20:58:15 CEST] <prelude2004c> check this out " http://tv.zazeen.com/cbcvancouverhd1150/cbcvancouverhd1150.m3u8 " 
[20:58:30 CEST] <prelude2004c> play that with vlc... see if subtitle one shows it for you
[20:59:19 CEST] <andrey_turkin> i found a small test file and there is definitely something wrong going on
[20:59:27 CEST] <prelude2004c> something is up.. so its not my player as vlc does it at exactly the same time
[20:59:41 CEST] <prelude2004c> on nvenc or x264 ?
[20:59:42 CEST] <prelude2004c> or both ?
[20:59:57 CEST] <andrey_turkin> libx264. I did touched it too
[21:01:53 CEST] <andrey_turkin> hmm, it's not my changes
[21:02:05 CEST] <andrey_turkin> someone broke A53 in the git? )
[21:03:47 CEST] <prelude2004c> at least we are getting somewhere :) a few minor changes and it will be 100% i am sure
[21:04:05 CEST] <andrey_turkin> actually nvenc worked for me flawlessly on a few seconds long clip
[21:04:12 CEST] <andrey_turkin> unlike libx264
[21:06:37 CEST] <prelude2004c> did you change something from the code you gave me for nvenc ?
[21:06:43 CEST] <andrey_turkin> no
[21:06:56 CEST] <prelude2004c> a few seconds.... it has to be longer because sometimes it work well for like 10 seconds or so.. then stops
[21:06:59 CEST] <prelude2004c> not sure how long it is but.. 
[21:11:16 CEST] <andrey_turkin> > check this out " http://tv.zazeen.com/cbcvancouverhd1150/cbcvancouverhd1150.m3u8 " 
[21:11:26 CEST] <andrey_turkin> doesn't work for me at all. Cannot even connect
[21:17:23 CEST] <andrey_turkin> I'm gonna need some samples to work with. I have some ATSC grabs with CC at work but I'm not going to get my hands on them until next week
[22:34:22 CEST] <JEEB> so what was this atmos thingy?
[22:34:34 CEST] <JEEB> got my first sample for it as I ordered the new mad max
[22:34:50 CEST] <TD-Linux> no one knows really
[22:50:23 CEST] <durandal_1707> Lies
[23:10:04 CEST] <cone-091> ffmpeg 03Michael Niedermayer 07master:fc07972582ac: avformat/dump: Use codec and QP limits from AVCodecContext
[23:13:47 CEST] <prelude2004c> andrey_turkin sorry
[23:13:57 CEST] <prelude2004c> replace the domain with 67.55.3.103
[23:14:13 CEST] <prelude2004c> so http://67.55.3.103...
[23:14:21 CEST] <prelude2004c> sorry i keep forgetting about that
[23:19:07 CEST] <andrey_turkin> I see now what you mean. It is really strange indeed. Can you record a minute or two of the source stream (not transcoded) ?
[23:19:34 CEST] <andrey_turkin> one with a lots of talking )
[23:45:27 CEST] <michaelni> BBB, hmm 4:4 :/
[23:46:07 CEST] <michaelni> theres still time thugh and there are many more developers
[23:47:21 CEST] <BBB> true :) lets give it a while
[23:55:22 CEST] <prelude2004c> yes i can .. please hold i will prepare a file on the server for you
[00:00:00 CEST] --- Sat Jun  4 2016