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

[burek]

[10:22:48 CET] <cone-759> ffmpeg 03Michael Niedermayer 07master:645c5e8c91ff: doc/encoders: Fix colums typo
[10:22:48 CET] <cone-759> ffmpeg 03Michael Niedermayer 07master:dfb5046cf33b: avcodec/mjpegdec: verify SOF len field validity
[10:22:48 CET] <cone-759> ffmpeg 03Michael Niedermayer 07master:ea30ac1e4082: avcodec/mjpegdec: Fix indention of ljpeg_decode_yuv_scan()
[10:30:08 CET] <cone-759> ffmpeg 03Paul B Mahol 07release/4.0:e44498984d3d: avformat/dsfdec: properly handle padded last packet
[10:30:09 CET] <cone-759> ffmpeg 03Paul B Mahol 07release/4.0:7c000b9cead0: avformat/dsfdec: fix calculation of size of data chunk
[13:39:02 CET] <durandal_1707> michaelni: can i get answer on ml about nut?
[15:53:43 CET] <cone-905> ffmpeg 03Carl Eugen Hoyos 07master:a07470ba372f: lavu/internal: Replace an empty loop with "do {}".
[17:25:57 CET] <jamrial> libaom keeps breaking shit
[17:26:17 CET] <BtbN> API stability is not modern
[17:26:31 CET] <BtbN> You just put everything into a Vagrant Container inside of a Docker container, and ship that
[17:26:43 CET] <j-b> jamrial: you should be happy: someone suggested a rolling-release of the AV1 spec.
[17:27:19 CET] <BtbN> That all sounds like h264 will eventually be patent free and still the most common codec
[17:29:15 CET] <jamrial> j-b: lol, that would screw with hardware implementations, and that's a big no-no
[17:30:39 CET] <BtbN> I'm really worried we'll end up with another libvpx as encoder, which so far seems to be the case
[17:30:57 CET] <nevcairiel> technically it always was libvpx =p
[17:31:02 CET] <nevcairiel> thats what it started out as
[17:33:11 CET] <jamrial> BtbN: there's rav1e precisely to prevent another vp9 situation with libvpx as the only foss compiler
[17:33:26 CET] <j-b> encoder :)
[17:33:33 CET] <jamrial> right
[17:33:40 CET] <j-b> rav1e, libaom and svt-av1 are already 3 foss encoders
[17:33:56 CET] <jamrial> nice, haven't heard of svt-av1
[17:34:41 CET] <nevcairiel> the intel svt compilers seem to be a bit .. peculiar
[17:34:44 CET] <jamrial> oh, Intel
[17:34:57 CET] <nevcairiel> damn now jamrial infected me with his compiler speak
[17:35:04 CET] <jamrial> :D
[17:36:30 CET] <j-b> nevcairiel: how peculiar?
[17:40:36 CET] <atomnuker> heh, "oh, Intel" says it all
[17:40:48 CET] <nevcairiel> they seem to be very specifically tuned around a very specific set of server hardware, and not really scale down from that, with really high memory requirements
[17:41:22 CET] <nevcairiel> (thats from looking at svt-hevc, svt-av1 doesnt seem to be public yet)
[17:47:51 CET] <atomnuker> can't be worse than av1, encoding 1080p was taking around 5 gigs of ram
[17:48:08 CET] <nevcairiel> it claims it wants 8 for 1080p
[17:48:23 CET] <nevcairiel> oh waits its only 6
[17:48:26 CET] <nevcairiel> but 16 for 4K
[17:55:00 CET] <atomnuker> okay thats worse
[17:55:31 CET] <nevcairiel> its specifically designed for running on the intel "scalable" branded server CPUs
[17:55:41 CET] <nevcairiel> which are probably assumed to also have a lot of memory
[17:57:00 CET] <nevcairiel> the good thing is that it probably threads quite well then
[17:57:15 CET] <nevcairiel> a soar point for libvpx and libaom
[18:07:52 CET] <J_Darnley> assembly people...
[18:08:50 CET] <J_Darnley> Is there a reason I can't abuse a SIMD bitpacking function that usually uses seprates source and dest buffers to operate on the same buffer?
[18:10:02 CET] <J_Darnley> The order of the reads and writes should ensure that no data I still need is altered.
[18:10:31 CET] <JEEB> michaelni: could you mention your stance on the nopts mpegts patch, as in the case you're not blocking it I'd love to take it forward. and if you think it's not a good enough improvement for some cases or that it breaks something for you mention that it's not good.
[18:11:17 CET] <JEEB> right now it just ended up in that discussion without a clear view whether it is not good enough or not
[18:14:24 CET] <nevcairiel> Didn't he say the other day that he would be fine with it, just that he might try to work on a buffering method in the future if time permits? That's what I read
[18:14:29 CET] <J_Darnley> hm, what was the instruction to flush memory?  sfence, mfence?
[18:14:35 CET] Action: J_Darnley find he reference
[18:14:51 CET] <JEEB> nevcairiel: yes, I'm just trying to make it clear on the ml
[18:20:00 CET] <atomnuker> J_Darnley: same buffer? as in mem<-mem?
[18:20:23 CET] <J_Darnley> yes
[18:20:39 CET] <J_Darnley> movu reg, [buffer]
[18:20:50 CET] <J_Darnley> ... processing ...
[18:20:59 CET] <J_Darnley> movu [buffer], reg
[18:22:34 CET] <J_Darnley> strictly speaking [buffer] is in two gpregs
[18:23:00 CET] <J_Darnley> the addresses start the same but slowly diverge because I read in more data than I wrte out
[18:26:25 CET] <atomnuker> not sure what shortcut you want to take here
[18:26:54 CET] <atomnuker> oh, you want to do it in-placec?
[18:26:59 CET] <atomnuker> *place
[18:28:18 CET] <J_Darnley> yes
[18:31:55 CET] <J_Darnley> Okay, that is very weird.  The first 50MiB to come out of the function is identical to a quick C hack I made.  (but that's only a few frames of data)
[18:36:46 CET] <kierank> iirc there was a reason we didn't go inplace
[18:37:12 CET] <J_Darnley> read-only buffers?
[18:40:20 CET] <kierank> dunno
[19:33:15 CET] <cone-905> ffmpeg 03Helmut K. C. Tessarek 07master:aaf917157479: libavcodec/libaomenc: fix breakage from upstream
[20:05:00 CET] <JEEB> michaelni: thanks
[20:05:08 CET] <zoff99> JEEB: ping
[20:05:19 CET] <JEEB> zoff99: pong
[20:05:37 CET] <zoff99> i am trying to get h264_mediacodec to work on android
[20:05:44 CET] <zoff99> been reading old irc logs
[20:06:00 CET] <zoff99> wihtout surface, that is
[20:06:07 CET] <JEEB> if you pass it the JVM, it should work just as a "normal" decoder
[20:06:24 CET] <JEEB> extra effort is only needed for the hwaccel side
[20:06:30 CET] <JEEB> (which means texture output)
[20:06:48 CET] <zoff99> yes i read that. but somehow it wont work
[20:07:16 CET] <zoff99> is it not accelerated without surface? is it using pure cpu then?
[20:07:35 CET] <JEEB> it is whatever your device gives for that format
[20:07:45 CET] <JEEB> for the oneplus one for example, HEVC was swdec
[20:07:49 CET] <JEEB> but AVC was hwdec
[20:07:53 CET] <zoff99> ah, so it could be accelerated then
[20:08:10 CET] <zoff99> is there an mediacodec encoder in ffmpeg aswell?
[20:08:40 CET] <JEEB> no
[20:09:33 CET] <zoff99> also not going to be?
[20:09:50 CET] <zoff99> anything planned?
[20:10:01 CET] <JEEB> not planned, but I don't think we have anything against it :P
[20:10:09 CET] <JEEB> watches pelcome as people say
[20:10:16 CET] <zoff99> :)
[20:10:25 CET] <zoff99> ok so here is my JNI part:
[20:10:25 CET] <zoff99> https://bin.disroot.org/?f97199138fd9d787#QnGfJpiWtE+WNfK921ZkRBoB5/u1xMQRTqApaeEGHCk=
[20:10:36 CET] <zoff99> but decoder open returns error
[20:10:39 CET] <zoff99> still
[20:12:18 CET] <JEEB> try if mpv-android works first since I kind of know that one logs various stuff nicely. after that start plugging in the FFmpeg logging framework into your thing
[20:12:19 CET] <zoff99> does the code snippet seem correct? could there be a threading issue
[20:12:35 CET] <zoff99> link?
[20:13:12 CET] <JEEB> https://github.com/mpv-android/mpv-android
[20:13:23 CET] <JEEB> APKs either from play store or from the release tab
[20:13:40 CET] <zoff99> ok just run the apk?
[20:13:44 CET] <JEEB> yea
[20:14:15 CET] <zoff99> and then?
[20:14:15 CET] <JEEB> also you can take a look at the JNI stuff if you want
[20:14:20 CET] <zoff99> what does it log?
[20:14:26 CET] <JEEB> all sorts of stuff :P
[20:14:29 CET] <JEEB> and if it works or not
[20:14:47 CET] <JEEB> then you can start plugging your FFmpeg library instances into the android logging framework
[20:14:49 CET] <zoff99> the debug version then?
[20:15:00 CET] <JEEB> debug version just has the debug bit on
[20:15:04 CET] <JEEB> no real other difference
[20:15:57 CET] <zoff99> media player? or what does the app do?
[20:15:59 CET] <JEEB> because if you plug in your API usage into a logger you should be able to figure out how far it gets :P
[20:16:04 CET] <JEEB> it's a player, yes
[20:16:17 CET] <JEEB> (also this is API usage and not development of FFmpeg, so technically this should go onto #ffmpeg)
[20:17:10 CET] <zoff99> oh. i read the logs of this channel
[20:17:28 CET] <zoff99> and 2 persons where asking this exact stuff and had same issue, thats why i joined here
[20:19:15 CET] <zoff99> ok so your app plays H264 mp4 file alright
[20:19:31 CET] <zoff99> hwdec: true
[20:20:02 CET] <JEEB> also you should have in adb logging a lot of stuff coming out from the ffmpeg decoding
[20:24:15 CET] <zoff99> it says something about mediacodec_copy
[20:25:21 CET] <JEEB> it's called like that within mpv
[20:25:25 CET] <zoff99> ok
[20:25:31 CET] <zoff99> well it all seems fine
[20:25:37 CET] <zoff99> also my code seems ok
[20:25:40 CET] <zoff99> very strange
[20:25:52 CET] <zoff99> what libs did u build for ffmpeg?
[20:25:57 CET] <zoff99> dependencies
[20:26:06 CET] <JEEB> you should be OK with just NDK and FFmpeg itself
[20:26:17 CET] <JEEB> since mediacodec itself only depends on NDK headers/libs
[20:26:23 CET] <JEEB> as in, android stuff
[20:26:48 CET] <zoff99> i could compile ffmpeg alright with h264_mediacodec
[20:26:55 CET] <zoff99> what ffmpeg version did u use?
[20:27:01 CET] <zoff99> i used n4.1 from github
[20:27:06 CET] <zoff99> release
[20:27:42 CET] <JEEB> it's been a while, but both the release in github as well as the settings/about screen should have the exact hash from master
[20:28:04 CET] <JEEB> I should really build newer stuff, but I've been busy/having to handle other things
[20:29:16 CET] <zoff99> cant figure out what i am doing wrong
[20:29:29 CET] <zoff99> did those 2 others guys get back to u? it was in july this year
[20:29:35 CET] <zoff99> the has the exact same issue
[20:29:46 CET] <JEEB> no idea, I don't have such long-term memory :P
[20:29:51 CET] <zoff99> :)
[20:30:05 CET] <zoff99> ok i have another issue with h264 encoder
[20:30:15 CET] <zoff99> i am working on a video conferencing app
[20:30:30 CET] <zoff99> now it use ffmpeg decoder and x264 encoder directly
[20:30:40 CET] <zoff99> works nice, but all software coding of course
[20:30:52 CET] <zoff99> now i wanted to use x264 encoder but via ffmpeg
[20:31:09 CET] <zoff99> and its impossible to know how to set the same options
[20:31:15 CET] <zoff99> no examples around
[20:31:38 CET] <zoff99> especially setting bitrate on the fly. seems impossible somehow
[20:48:09 CET] <JEEB> also I seem to be focusing on the negative way too much. I always forget to write "or if someone has a better idea"
[20:49:26 CET] <zoff99> i try my android build again. maybe you can help me on my 2nd issue?
[20:51:31 CET] <JEEB> in theory when you feed it a frame, reconfig_encoder in libavcodec/libx264.c is called
[20:51:47 CET] <JEEB> when that change is applied is a separate question
[20:52:30 CET] <JEEB> that does touch bit rate as well
[20:52:47 CET] <JEEB> so in theory from libavcodec's side if the values differ it should get applied
[20:52:59 CET] <JEEB> (now when x264 applies those changes depends on x264)
[20:53:08 CET] <zoff99> but how can i set the bitrate ?
[20:53:26 CET] <JEEB> see the reconfig_encoder function in libavcodec/libx264.c
[20:53:32 CET] <zoff99> int res = x264_encoder_reconfig(vc->h264_encoder, &param);
[20:53:40 CET] <zoff99> x262 is easy, i just call this directly
[20:53:45 CET] <JEEB> that's the final call yes
[20:54:09 CET] <JEEB> but you asked which specific values it was looking at from FFmpeg's side
[20:54:25 CET] <zoff99> yes
[20:54:37 CET] <zoff99> at ffmpeg i dont see any public reconfigure* api functions
[20:54:47 CET] <JEEB> thus so you can have the a-ha! moment I recommend you to look at libavcodec/libx264.c
[20:55:06 CET] <JEEB> as I already noted, that encoder does have a reconfig_encoder function, which is getting called at each frame
[20:55:58 CET] <JEEB> there is no separate function to reconfig the encoder
[20:56:13 CET] <zoff99> oh its called internally each frame, ook
[20:56:22 CET] <JEEB> you just update the values relevant to the AVFrame and AVCodecContext
[20:56:28 CET] <JEEB> and then feed the AVFrame to the encoder instance
[20:56:36 CET] <JEEB> for details, look in the location I specified
[21:00:28 CET] <zoff99> the bad thing is "avcodec_open2" does not really say what the issue is
[21:00:32 CET] <zoff99> it just does not work
[21:00:39 CET] <zoff99> no message why
[21:00:47 CET] <zoff99> i still think it needs a surface
[21:00:59 CET] <zoff99> or needs some option set, to tell it not to use a surface
[21:01:16 CET] <zoff99> somebody posted that on a message board somewhere that we traced the calls
[21:05:12 CET] <zoff99> int av_mediacodec_default_init(AVCodecContext *avctx, AVMediaCodecContext *ctx, void *surface)
[21:07:27 CET] <zoff99> is there an option or flag i have to set before calling "avcodec_open2" ?
[21:12:09 CET] <mateo`> zoff99: did you set the codec extradata ? they are mandatory for the mediacodec decoders
[21:12:17 CET] <zoff99> oh no
[21:12:20 CET] <zoff99> whats that?
[21:13:14 CET] <zoff99> is there an example in C ?
[21:14:32 CET] <mateo`> its a chunk of bitstream that corresponds to the codec configuration, for avc it's the sps/pps
[21:14:55 CET] <zoff99> i dont understand
[21:15:09 CET] <zoff99> i am trying to pass the "avcodec_open2" call
[21:15:14 CET] <zoff99> no data involved yet
[21:17:37 CET] <JEEB> zoff99: plug FFmpeg's logging into your app's debugging
[21:17:46 CET] <JEEB> the init() function does have plenty of logging there
[21:17:51 CET] <mateo`> the AVCodecContext you pass to avcodec_open2 must be configured first
[21:17:54 CET] <zoff99> JEEB: i dont understand what that means
[21:18:29 CET] <zoff99> mateo`: yes, i did that. but only like for normal h264 decoders
[21:18:43 CET] <mateo`> by settings the codec parameters, width, height, codec extradata, ...
[21:18:43 CET] <zoff99> mateo`: what are the extra mandatory values i need to set?
[21:18:49 CET] <JEEB> and yes, there is a function to generate AVCodecContext from the demuxer's properties
[21:19:39 CET] <mateo`> AVCodecContext.extradata / AVCodecContext.extradata_size
[21:20:06 CET] <zoff99> mateo`: mpv doesnt set these, as far as i can see in the source
[21:21:06 CET] <JEEB> there's a function that lets you generate a new AVCodecContext from AVCodecParameters
[21:21:13 CET] <JEEB> which should take care of some of the stuff :P
[21:21:30 CET] <zoff99> JEEB:  i am looking at vd_lavc.c
[21:22:03 CET] <mateo`> look for avcodec_parameters_* functions
[21:22:16 CET] <JEEB> yup, avcodec_parameters_to_context
[21:22:19 CET] <JEEB> that was it :P
[21:22:34 CET] <JEEB> just looked at some random test code I Wrote ages ago
[21:23:00 CET] <JEEB> 1. init AVCodecContext from AVCodec, pass params, open2
[21:23:32 CET] <zoff99> hmm
[21:23:43 CET] <zoff99> what are the minimum input i need for that function
[21:23:47 CET] <zoff99> is there a sample?
[21:23:53 CET] <zoff99> https://www.ffmpeg.org/doxygen/trunk/libavcodec_2utils_8c_source.html#l02092
[21:23:58 CET] <zoff99> this one right?
[21:24:15 CET] <JEEB> yes
[21:25:02 CET] <JEEB> ok, you don't need that if you don't have lavf used before lavc :P
[21:25:20 CET] <JEEB> you then just need to initialize the correct parts of AVCodecContext
[21:25:32 CET] <JEEB> but really, stick the logging callbacks
[21:25:36 CET] <JEEB> into your logging
[21:25:57 CET] <zoff99> ok.
[21:26:02 CET] <JEEB> https://ffmpeg.org/doxygen/trunk/group__lavu__log.html
[21:26:03 CET] <zoff99> logging example source?
[21:26:09 CET] <JEEB> see av_log_set_callback
[21:26:17 CET] <mateo`> and if you are using lavf, pick the video stream (AVStream), and call avcodec_parameters_to_context(avctx, stream->par); 
[21:26:34 CET] <zoff99> i dont have a stream at that
[21:26:49 CET] <zoff99> i get single frames, over network
[21:26:57 CET] <zoff99> i always use the same settings on the encoder
[21:27:26 CET] <mateo`> you will have to extract manually the codec parameters then
[21:27:41 CET] <zoff99> highly complex
[21:27:51 CET] <zoff99> with software decoder this all is 3 lines of code
[21:27:54 CET] <mateo`> craft manually the sps/pps in either the annex-b form or the avcc one
[21:28:35 CET] <JEEB> zoff99: or you feed the raw bit stream to the H.264 "demuxer" and then get it from there?
[21:28:54 CET] <JEEB> mediacodec requires it to initialize so either you or someone else handles it
[21:29:03 CET] <mateo`> yes but with mediacodec we (I) put this restriction so the decoder can fail at initialization if it does support the bitstream you pass to it
[21:29:51 CET] <mateo`> maybe I can make optionnal it ...
[21:30:05 CET] <zoff99> would be nice
[21:30:14 CET] <zoff99> can you tell me the source line in ffmpeg n4.1
[21:30:23 CET] <zoff99> the i can just for testing comment it locally
[21:30:24 CET] <JEEB> I don't really see how it would make things simpler. having it fail at init is more clear IMHO
[21:30:37 CET] <zoff99> i try logging now
[21:30:54 CET] <mateo`> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mediacodecdec.c#L135
[21:31:07 CET] <JEEB> zoff99: just add the H.264 "demuxer" in front if you don't want to do this yourself?
[21:31:23 CET] <mateo`> before that line add if (!avctx->extradata) return 0;
[21:31:37 CET] <zoff99> ok, i am confused
[21:31:42 CET] <zoff99> do i need the demuxer?
[21:31:48 CET] <JEEB> if  you want it to be done for you
[21:31:57 CET] <zoff99> i get raw data from h264 encoder, and put that into decoder
[21:32:03 CET] <zoff99> with software it works fine
[21:32:11 CET] <JEEB> yes, because the software thing will eat almost anything
[21:32:20 CET] <zoff99> i see
[21:32:20 CET] <JEEB> while with hwdec you probably want to know if your hardware isn't going to take it
[21:32:28 CET] <JEEB> and it's better to get that failure at init()
[21:32:30 CET] <JEEB> IMHO
[21:32:48 CET] <zoff99> video coding is complicated
[21:32:53 CET] <zoff99> makes my head hurt :)
[21:35:07 CET] <mateo`> JEEB: I think the same, however, if it's optional and if the user do not provide the extradata it is up to him to properly handle the failure when he grab the first frame
[21:35:20 CET] <mateo`> and maybe we can warn about it
[21:37:50 CET] <zoff99> ok, matrix users do not have voice :-(
[21:37:57 CET] <zoff99> thats why i cant talk with my phone
[21:38:53 CET] <mateo`> I will propose a patch on the ml tomorrow and see how it goes
[21:45:58 CET] <zoff99> mateo`: that line does not exist in version n4.1 :D
[21:46:32 CET] <zoff99> oops sorry
[21:46:37 CET] <zoff99> missed a "dec" in the name
[21:48:47 CET] <zoff99> mateo`: do i have to "ff_h264_ps_uninit(&ps);" before return ?
[21:48:57 CET] <JEEB> uhh
[21:49:18 CET] <zoff99> every other path in that file does it
[21:51:01 CET] <mateo`> just return 0 before calling ff_h264_decode_extradata()
[21:51:21 CET] <zoff99> yes i did. now compiling  again
[21:52:10 CET] <zoff99> ok now the log callback works :)
[21:52:21 CET] <zoff99> it says: looks like the input is annex_b already
[21:53:35 CET] <zoff99> "The input looks like it is Annex B already\n");
[21:54:29 CET] <zoff99> h264_mp4toannexb_bsf.c
[21:54:32 CET] <zoff99> string only happens here
[21:55:37 CET] <zoff99> mateo`: ok with that change i get a new message and crash
[21:56:12 CET] <zoff99> unsupported or unknown profile
[21:58:02 CET] <zoff99> seems i need the extra data
[21:59:42 CET] <JEEB> if it's raw annex B H.264 you're handling, it might just be simplest to use lavf for the input and parse it as raw H.264
[21:59:52 CET] <JEEB> that way the decoder initialization data will get parsed for you
[22:00:37 CET] <JEEB> and then you can just use the codecpar to your codec context function to initialize the AVCodecContext fields
[22:09:57 CET] <zoff99> JEEB: ok, i dont understand what that means
[22:10:14 CET] <zoff99> yes i get raw anndex b and repeat header h264 video frames
[22:10:18 CET] <zoff99> from encoder
[22:11:13 CET] <JEEB> if you handle the protocol yourself, then you will have to implement your own read etc callbacks for avformat
[22:11:23 CET] <JEEB> but that way you can utilize already available parsers
[22:11:25 CET] <JEEB> and logic
[22:11:39 CET] <JEEB> there's IIRC even an example for AVIO callbacks in the repo
[22:12:19 CET] <JEEB> http://www.ffmpeg.org/doxygen/trunk/doc_2examples_2avio_reading_8c-example.html
[22:12:22 CET] <JEEB> this one I think :P
[22:12:47 CET] <JEEB> http://www.ffmpeg.org/doxygen/trunk/avio_8h.html#a853f5149136a27ffba3207d8520172a5
[22:13:10 CET] <JEEB> then you can feed AVFormatContext that AVIO context
[22:27:34 CET] <zoff99> now i am getting frames
[22:27:44 CET] <zoff99> all green but at least i am getting something
[22:28:17 CET] <JEEB> is that with your own parsing or the lavf H.264 demuxer/parser?
[22:29:30 CET] <zoff99> own
[22:29:36 CET] <zoff99> i am not parsing anything
[22:29:56 CET] <JEEB> ok, so you're still attempting without the extradata I guess
[22:30:00 CET] <zoff99> i dont understand what that means. my app just takes frames at a time
[22:30:03 CET] <zoff99> yes
[22:30:14 CET] <zoff99> since i dont know how to extract it
[22:30:30 CET] <JEEB> I just told you for the record if you re-read my last 15 or so lines?
[22:30:35 CET] <JEEB> or not even that I think
[22:30:36 CET] <zoff99> lavf seems lots complicated
[22:30:45 CET] <JEEB> also what's your protocol?
[22:30:52 CET] <zoff99> its tox
[22:31:00 CET] <JEEB> ok, so not something that lavf speaks out of the box
[22:31:13 CET] <zoff99> probably not
[22:31:14 CET] <JEEB> if it was just rtp or udp then you wouldn't have needed custom IO
[22:31:29 CET] <zoff99> what i do is i just take what x264 gives me, raw data
[22:31:32 CET] <JEEB> zoff99: if it's a known working route then I'm not 100% sure if it's "complicated"
[22:31:37 CET] <zoff99> and put that into the decoder
[22:31:57 CET] <zoff99> ok, its complicated for me. since i have not done it yet
[22:32:17 CET] <zoff99> its rtp but with some own stuff
[22:32:38 CET] <zoff99> i put the data together so its exactly like at the encoder
[22:33:14 CET] <JEEB> ok, so if you want to go your way - sure. then I will stop recommending lavf's parsing. good luck.
[22:33:23 CET] <zoff99> ok
[22:38:42 CET] <zoff99> thats not the issue
[22:38:53 CET] <zoff99> i just dont understand what those things mean
[22:39:15 CET] <zoff99> the software encoder does it pretty good
[22:39:25 CET] <JEEB> because it's a known software decoder
[22:39:29 CET] <zoff99> was hoping to just switch to hw decoder without much change
[22:39:37 CET] <JEEB> it's our code and most likely it will eat pretty much whatever you feed it
[22:39:57 CET] <zoff99> will proably be easier for me to use mediacodec in java then
[22:40:04 CET] <zoff99> was hoping to avoid that
[22:40:12 CET] <JEEB> I don't see how that will be easier to be honest
[22:40:18 CET] <JEEB> if it's the same APIs underneath
[22:40:24 CET] <zoff99> because there a examples
[22:40:49 CET] <zoff99> in C with ffmpeg none of the examples are for my case sadly
[22:40:51 CET] <JEEB> there are examples of what I just mentioned, it is just that you specifically say that you do not want to utilize that way!
[22:41:11 CET] <JEEB> you specifically say that it feels complicated and thus you wanted to handle the parameter sets etc yourself
[22:41:28 CET] <JEEB> so we have the tools for you available, and even an example for the custom IO
[22:41:32 CET] <zoff99> http://www.ffmpeg.org/doxygen/trunk/doc_2examples_2avio_reading_8c-example.html
[22:41:36 CET] <zoff99> this one uses a file
[22:41:47 CET] <JEEB> the idea is that you have a callback
[22:41:54 CET] <JEEB> that doesn't change with what it is
[22:42:07 CET] <JEEB> I also linked http://www.ffmpeg.org/doxygen/trunk/avio_8h.html#a853f5149136a27ffba3207d8520172a5 for the AVIO context creation docs
[22:43:06 CET] <JEEB> what the example exactly uses for the IO is irrelevant as the main part is that it shows you how to define the AVIO callbacks
[22:43:25 CET] <JEEB> a file based thing is just one of the simplest things to make buildable
[22:43:36 CET] <zoff99> in my software i dont have callback to fill the data. it work differently
[22:43:56 CET] <JEEB> I did not have callbacks either in my matroska thumbnailer until I implemented them
[22:44:31 CET] <JEEB> anyways, I'm sorry if it feels to you like we don't have enough examples or don't help you enough. but it really feels like you're specifically saying "no" to the helping functionality we do have.
[22:44:45 CET] <zoff99> well you already gave me some pointers
[22:44:50 CET] <zoff99> i will check some more
[22:45:08 CET] <zoff99> if its too complicated i will switch to java, since proably i will need the encoder aswell
[22:45:54 CET] <JEEB> also with your patched-out thing, even if you kept feeding it enough AVPackets, did it ever get out proper images?
[22:46:04 CET] <zoff99> no
[22:46:13 CET] <JEEB> enough as in that you got PPS/SPS etc
[22:46:18 CET] <JEEB> the parameter sets
[22:46:28 CET] <JEEB> (aka what goes into extradata in various ways)
[22:46:40 CET] <zoff99> i set parameter manually hoping it would be enough
[22:46:51 CET] <zoff99> wasnt :)
[22:46:51 CET] <JEEB> you do know what parameter sets are, right?
[22:47:08 CET] <zoff99> i have the PPS and SPS
[22:47:12 CET] <JEEB> yes
[22:47:17 CET] <zoff99> there are tool to extract it
[22:47:21 CET] <JEEB> ok
[22:47:33 CET] <JEEB> then you should be able to generate AVCodecContext.extradata from that
[22:47:37 CET] <zoff99> it would mean to wait for the first data block
[22:48:07 CET] <zoff99> basically i was trying to find out if it was easy (for me) to switch to the HW decoder
[22:48:18 CET] <zoff99> now i know its more difficult then just 1 line
[22:48:39 CET] <JEEB> yes, if you were using the other functionality from the beginning
[22:48:42 CET] <zoff99> for exmaple on the raspi it was just decoder by name 'h264_mmal' and done
[22:48:50 CET] <JEEB> because then the extradata field would have been set
[22:48:52 CET] <zoff99> same for encoder on raspi
[22:49:00 CET] <zoff99> no extra data no nothing
[22:49:01 CET] <JEEB> encoder is a whole separate ball game
[22:49:17 CET] <JEEB> well you just got to that point when you disabled the check in the mediacodec decoder
[22:49:24 CET] <JEEB> so after that it's in MediaCodec's area
[22:49:28 CET] <JEEB> I'd say
[22:49:28 CET] <zoff99> yeah
[22:49:41 CET] <zoff99> just i hoped since it was so easy on the raspi
[22:49:55 CET] <JEEB> it would have been, IF you had been using lavf already
[22:49:56 CET] <JEEB> unfortunately
[22:49:57 CET] <zoff99> literally just rename the decoder name
[22:50:02 CET] <JEEB> I feel like I'm repeating myself
[22:50:07 CET] <zoff99> ok
[22:50:12 CET] <zoff99> thanks anyway
[22:51:17 CET] <JEEB> but as I said, if you are already parsing out the PPS/SPS
[22:51:27 CET] <JEEB> which you mentioned you had functionality for
[22:51:40 CET] <JEEB> then you could generate the extradata field from that :P
[22:51:43 CET] <JEEB> just fyi
[22:51:48 CET] <zoff99> no. i am using an external tool to look at it
[22:51:51 CET] <JEEB> ok
[00:00:00 CET] --- Thu Dec 20 2018