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

[burek]

[00:23:31 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.2:aec21cd840bc: avcodec/ffv1enc: Fix size of first slice
[00:23:32 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.2:35ef033a19a6: avformat/oggdec: Skip streams in duration correction that did not had their duration set.
[00:23:33 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.2:3f779aef79b1: avcodec/mpeg4videodec: Fix undefined shifts in mpeg4_decode_sprite_trajectory()
[00:23:34 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.2:0e6febff5a7b: avcodec/ffv1enc: Allocate smaller packet if the worst case size cannot be allocated
[00:23:35 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.2:3ecbac566401: avformat: Add max_streams option
[00:23:36 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.2:64bb329afa9a: avutil: Add av_image_check_size2()
[00:44:01 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.1:0c2d6a219f28: avcodec/ffv1enc: Fix size of first slice
[00:44:02 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.1:119301d3129e: avformat/oggdec: Skip streams in duration correction that did not had their duration set.
[00:44:03 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.1:255e61c25b83: avcodec/mpeg4videodec: Fix undefined shifts in mpeg4_decode_sprite_trajectory()
[00:44:04 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.1:0131f5c37699: avcodec/ffv1enc: Allocate smaller packet if the worst case size cannot be allocated
[00:44:05 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.1:b18a571e2355: avformat: Add max_streams option
[00:44:06 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.1:6c96200ceb0f: avutil: Add av_image_check_size2()
[01:32:39 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.0:0bcc7ea5dc24: avcodec/ffv1enc: Fix size of first slice
[01:32:40 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.0:7c68d5e70151: avformat/oggdec: Skip streams in duration correction that did not had their duration set.
[01:32:41 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.0:efa164aa6850: avcodec/mpeg4videodec: Fix undefined shifts in mpeg4_decode_sprite_trajectory()
[01:32:42 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.0:667c9ed1f14c: avcodec/ffv1enc: Allocate smaller packet if the worst case size cannot be allocated
[01:32:43 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.0:7dd1cc6076ca: avformat: Add max_streams option
[01:32:44 CET] <cone-043> ffmpeg 03Michael Niedermayer 07release/3.0:76961f4f42d2: avutil: Add av_image_check_size2()
[01:54:41 CET] <cone-043> ffmpeg 03James Almer 07master:4e759072c216: avformat/matroskadec: allocate Colour related fields only if the file contains the relevant master
[01:54:42 CET] <cone-043> ffmpeg 03James Almer 07master:edb4f5da8125: avformat/matroskadec: remove the strict unofficial check for Colour elements
[18:31:36 CET] <kierank> michaelni: what does ff_update_block_index do?
[18:32:03 CET] <kierank> I'm trying to add 10-bit and 422/444 to mpeg4videodec
[18:32:30 CET] <kierank> am I right in saying mpegvideo is only 8-bit?
[18:36:41 CET] <kierank> also it's not clear in mpeg4video if you ever reset the predictor when you get a new slice
[18:38:32 CET] <kierank> the dc predictor
[18:50:44 CET] <Zeranoe> Anyone know a decent way to drop into GDB for a hang in FFmpeg, when the hang is not reproducible every time?
[18:50:56 CET] <Zeranoe> Oh, the hang also does not last forever....
[18:52:54 CET] <Compn> valgrind ?
[18:52:58 CET] <Compn> trying to see if xvid supports 10bit 
[18:53:02 CET] <Compn> but im not seeing it , kierank
[18:53:16 CET] <Zeranoe> I supposed you could redirect FFmpegs -loglevel debug into a bash loop and check the time against the last, and if it's above some threshold than drop into a gdb session 
[18:53:28 CET] <kierank> gdb attach during the hang
[18:53:48 CET] <Zeranoe> The thing is it could take 100 attempts to reproduce it
[18:53:57 CET] <Zeranoe> and I don't want to watch it the entire time
[18:55:09 CET] <Compn> ask carl to reproduce it ?
[18:55:26 CET] Action: Compn runs
[18:55:33 CET] <kierank> while 1 and wait for it to hang
[18:56:07 CET] <Zeranoe> kierank: I still have to watch it though, since the hang does not last forever
[18:56:37 CET] <Zeranoe> It's a momentary hang that does not happen every time. Pretty much the dream situation to debug.
[18:59:02 CET] <nevcairiel> sit in debugger and hit break all hotkey when it hangs
[18:59:23 CET] <nevcairiel> gdb .. :p
[20:10:42 CET] <durandal_1707> kierank: i got it working but with strange artefacts, white pixel is gray sometimes, and black becomes gray sometimes
[20:10:51 CET] <kierank> might need to clip
[20:11:01 CET] <kierank> you are probably overflowing
[20:11:08 CET] <durandal_1707> hmm
[20:21:03 CET] <kierank> or the transform is overflowing
[22:32:30 CET] <atomnuker> is it okay for encoders to set avctx->frame_size at the end of the encode function?
[22:33:07 CET] <atomnuker> (to be able to request a different amount of samples each frame?)
[22:35:50 CET] <atomnuker> the alternative would be to set frame_size to the lowest possible size, buffer the data from the avframe (it's audio, no need to ref) and set got_packet_ptr to 0 until I have a frame
[22:37:01 CET] <nevcairiel> dont we have a variable frame size flag
[22:37:09 CET] <nevcairiel> and audioo queue apis
[22:37:44 CET] <atomnuker> yeah, but that goes the other way around - the encoder can take in whatever you give it
[22:38:56 CET] <nevcairiel> changing it after encoding a frame seems risky
[22:39:37 CET] <atomnuker> it's what I was thinking, applications probably assume it's constant from init time until the end
[22:39:49 CET] <atomnuker> (but then how is AV_CODEC_CAP_SMALL_LAST_FRAME handled?)
[22:41:16 CET] <nevcairiel> its not really handled much, it just wont error if you pass less then frame_size
[22:41:42 CET] <nevcairiel> everything else is up to the encoder
[22:41:56 CET] <kierank> atomnuker: then how does the user know how many samples to send
[22:42:01 CET] <kierank> it's a circular problem
[22:42:21 CET] <kierank> 9:35 PM <"atomnuker> the alternative would be to set frame_size to the lowest possible size, buffer the data from the avframe (it's audio, no need to ref) and set got_packet_ptr to 0 until I have a frame
[22:42:25 CET] <kierank> afaik that's the only way
[22:46:25 CET] <nevcairiel> thats definitely the safest
[22:46:30 CET] <atomnuker> yep, that's much neater on a second thought
[22:46:43 CET] <nevcairiel> which audio codecs has varying frame sizes like that? especially when you would already know beforehand how big its going to be?
[22:47:14 CET] <kierank> well putting my realtime bias hat on, variable frame size screws you hard
[22:47:24 CET] <kierank> because you need to know the maximum buffering amount
[22:47:42 CET] <kierank> maybe the maximum is better for frame_size
[22:48:18 CET] <nevcairiel> that doesnt really reduce the amount of buffering, it just moves it, doesnt it
[22:48:18 CET] <atomnuker> opus allows you to pack up to 120 msec in a single packet, but that's more inefficient than just using single shorter sized frames
[22:48:45 CET] <kierank> nevcairiel: you don't want to reduce the buffering, you just need to know how much it is
[22:49:19 CET] <kierank> so you could wait 10, 100 or 1000 calls to the function, you don't know
[22:49:21 CET] <atomnuker> also actually reffing instead of copying would be really nice since opus's lowest frame size is also its lapping size
[22:49:59 CET] <nevcairiel> we might have an AVFrame queue with reffing
[22:50:01 CET] <atomnuker> so you'd just maintain a pool of reff'd frames to do analysis on and decide when you want to stop
[22:52:13 CET] <atomnuker> though how would e.g. 8 frames inputted -> 1 packet outputted work with respect to the audio frame queue which sets the timestamps?
[22:53:37 CET] <atomnuker> just using what ff_af_queue_remove() sets for the last frame seems to make the most sense, so that should be okay
[22:55:38 CET] <nevcairiel> if the bigger frames are always multiple of your frame_size, that makes it easy
[22:57:07 CET] <atomnuker> yep, that'll always be true
[23:23:05 CET] <durandal_1707> kierank: it's must be something else, will look tomorrow
[23:31:28 CET] <kierank> durandal_1707: ok, I have made good progress with mpeg-4 sstp
[00:00:00 CET] --- Mon Dec 12 2016