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

[burek]

[00:00] <michaelni> yes, i found no samples that use this codepath when i wrote it
[00:12] <durandal_1707> BuxiNess: speed not match libopenjpeg or?
[00:12] <durandal_1707> s/not/now
[01:47] <durandal_1707> michaelni: try: ffmpeg -f lavfi -i smptehdbars=hd720 -pix_fmt rgb48 /tmp/o.jp2
[01:47] <durandal_1707> i get funny effect with jpeg2000
[01:49] <durandal_1707> ^the native decoder
[02:28] <johnsmith> Hey all, has anyone here have had experiance using/playing around with av_write_frame(..)..?
[02:28] <michaelni> BuxiNess, if you have time, one more jpeg2000 patch on ffmpeg-devel to review " [FFmpeg-devel] [PATCH] jpeg2000: fix overflow in dequantization"
[12:28] <cone-574> ffmpeg.git 03Nicolas Bertrand 07master:f56fe04de3cc: jpeg2000: Initialize only once mqc arrays
[12:28] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:dc072c98677f: Merge remote-tracking branch 'qatar/master'
[12:40] <saste> wm4, ping on demuxing.c patch
[12:41] <saste> i'm not sure I want to add support for resampling though
[12:46] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:f57119b8e58c: jpeg2000: fix overflow in dequantization
[14:11] <wm4> saste: I'm not sure whether it's worth fixing at all, because at least audio is usually planar, and it doesn't make sense to write planar into a raw file
[14:24] <b_jonas> :(
[14:25] <saste> wm4, the file is about demuxing, not about writing audio to a raw file
[14:33] <b_jonas> argh, I'll have to chime in the mailing list because apparently they didn't read the bug ticket replies
[14:33] <b_jonas> let me see where I subscribe
[14:36] <b_jonas> though if the patch is safe in cvs and the question is only whether it should be included in the 1.2 branch, then I probably don't much care about that
[14:36] <b_jonas> (re https://ffmpeg.org/trac/ffmpeg/ticket/2684 )
[15:09] <saste> wm4, are you going to repost your edited patch, or should I fix and apply it myself?
[15:10] <wm4> saste: AFAIK the requested changes were kind of trivial, so feel free to apply them yourself
[15:10] <wm4> if it's more convenient for you that I make the changes I can do that too, though
[15:11] <wm4> does anyone know whether decoder stereo downmix or libswresample/libavresample is preferable? any quality or correctness differences?
[15:11] <saste> wm4, as you prefer
[15:11] <saste> i prefer you do the work ;-)
[15:12] <wm4> ok
[15:13] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:786b0968dd29: ffplay: remove explicit idct option
[15:14] <wm4> saste: btw. are you saying that FFMIN(decoded, pkt.size) is unneeded and just decoded should be returned?
[15:16] <michaelni> wm4, decoders can in theory do downixing often with less cpu than full decode and downmix outside
[15:16] <wm4> michaelni: yes, but are there differences in quality and correctness?
[15:16] <saste> wm4, I'm not sure if video_decode() returns the size of the decoded data
[15:17] <saste> in that case you don't need to make a distinction, you can assume ret = decoded_data_size
[15:17] <wm4> saste: there's some extra code in the video path: "+        decoded = pkt.size;"
[15:18] <saste> yes, it's that i don't know which is the meaning of the return value, that's why I asked (and I put a "?")
[15:18] <saste> but maybe my remark was not founded
[15:18] <wm4> saste: well, the example's decode_packet function returns how much of the packet was decoded
[15:19] <wm4> saste: I'll make it a little bit more explicit
[15:20] <michaelni> the file might store a downmix matrix, that matrix might be used by the decoders downmix, and the decoder might export that downmix and some application might pass that on to swr. 
[15:21] <michaelni> depending on which of these "mights" are true one could be better or more correct than the other
[15:22] <lukaszmluki> Hi, Is Nicolas George here?
[15:23] <saste> lukaszmluki, no, he's almost never on irc
[15:23] <lukaszmluki> ok, thanks
[15:28] <wm4> also why does demuxing.c allocate a sample buffer?
[15:31] <wm4> also maybe this really should be done in libavcodec/utils.c instead
[15:36] <michaelni> khali, as you are in MAINTAINERS you should be op in here
[15:41] <wm4> so, why is there no simple do-planarize function
[15:41] <wm4> this is probably what 99% of libavcodec users going to need
[15:41] <wm4> s/do-planarize/de-planarize/
[15:45] <saste> wm4: this is required since rawaudio expects non aligned data
[15:46] <wm4> is there a planar raw audio demuxer that can actually read this stuff?
[15:46] <saste> wm4, no
[15:46] <wm4> then it makes more sense to write the first plane only
[15:46] <wm4> which is much simpler
[15:47] <saste> can i force the codec to write 1-aligned data?
[15:47] <wm4> I mean: fwrite(frame->extended_data[0], 1, frame->linesize[0], audio_dst_file);
[15:47] <saste> wm4, yes
[15:47] <saste> when i wrote the example, i was striving to keep A/V symmetry
[15:47] <saste> there is probably no sense into it
[15:48] <saste> also i wanted to avoid to rely on other libraries (lswr, lsws)
[15:49] <wm4> I can actually play the video output with mplayer's rawvideo
[15:50] <saste> in theory we could pass a linesize argument to the rawaudio demuxer, but that would be rather artificial
[15:50] <saste> since there are no such planar rawaudio files on the wild
[15:51] <wm4> hm for some reason I can get clear audio with luckynight-partial.shn, but not with some other rather normal mkv file
[15:51] <wm4> anyway.
[16:04] <khali> michaelni: as you wish :) I don't really care
[16:05] <khali> michaelni: I have a fix for the coverity issue, I must go shopping now, I'll post it when I return
[16:05] <michaelni> ok
[16:05] <khali> michaelni: is there a way to ask Coverity to test with the patch before we apply it?
[16:05] <michaelni> AFAIK no
[16:26] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:4cdb42b428ef: avcodec/012v: improve stride selection
[16:41] <khali> michaelni: should I put any reference in the patch header when fixing a Coverity issue?
[16:46] <cehoyos> khali: Yes, please add such references, see for example f73d6d2af7a2b30a647d945b590962a2ab54ff3b
[16:51] <khali> done, and sent
[17:03] <khali> and now is swimming pool time - -ETOOHOT
[17:14] <saste> kierank, ping
[17:14] <kierank> saste: pong
[17:14] <saste> kierank, hey!
[17:15] <saste> i'm doing evil things with H.264+MP4, I want to encode H.264 once, and store to MPEG-TS and to MP4 at the same time
[17:15] <kierank> you'll have to either duplicate the sps/pps
[17:15] <kierank> or rip it out
[17:15] <saste> because of this i hacked the tee_bsfs option, in order to apply separated bitstream filters to the same input
[17:16] <cone-574> ffmpeg.git 03Jean Delvare 07master:b6d0bb6086d1: lavfi/delogo: Fix sign extension issue
[17:16] <cone-574> ffmpeg.git 03Jean Delvare 07master:9e4bb091401f: lavfi/delogo: Document where parameter show=1 draws its rectangle
[17:16] <saste> the problem is that i'm fighting with extradata stuff, I'm using the command:
[17:16] <saste> $ffmpeg -i $input -map 0 -flags:v +global_header -c:v libx264 -flags:a +global_header  -c:a libvo_aacenc -bsf:v remove_extra -f ssegment -segment_format mpegts out-%03d.ts
[17:17] <saste> which is failing in the bitstream filter
[17:17] <saste> it seems I cannot set global header (required by MP4) and then strip it with h264_mp4toannexb
[17:18] <saste> kierank, >you'll have to either duplicate the sps/pps
[17:18] <saste> to your knowledge this can/could be done with some bitstream filter?
[17:18] <kierank> i don't see why not
[17:18] <saste> my attempts with h264_mp4toannexb and remove_extra failed
[17:19] <cehoyos> kierank: Can you analyze the mp4 stream at the bottom of ticket 2777? FFmpeg thinks that recovery points only happen every ~17 seconds.
[17:20] <kierank> cehoyos: yes
[17:20] <cehoyos> Please do so;-)
[17:20] <kierank> 5 mins to download
[17:21] <cehoyos> I am afk but I will see your conclusions - than you!
[17:24] <saste> kierank, it's always failing at line h264_mp4toannexb.c:84
[17:24] <saste> extradata + 2 + unit_size > avctx->extradata + avctx->extradata_size
[17:26] <kierank> saste: not sure about the bsf
[17:26] <kierank> i've never used it before
[17:26] <saste> kierank, it's required when copying from MP4 -> MPEG-TS
[17:35] <kierank> cehoyos: there don't appear to be any recovery points in that file
[17:37] <kierank> there are points which probably are recovery points but none are flagged correctly
[17:46] <cehoyos> Does that mean that FFmpeg behaves correctly or incorrectly?
[17:47] <cehoyos> by skipping several hundred frames before showing anything
[18:01] <kierank> Correctly I guess
[18:09] <saste> kierank: SPS/PPS -> these are H.264 specific terms, not directly related to MP4/MPEG-TS, right?
[18:09] <kierank> Yes
[18:10] <saste> too many unknown terms in my equation, i'll probably give up...
[18:10] <kierank> The storage of them is different
[18:10] <kierank> Mp4 had global header
[18:10] <kierank> TS has repeated on keyframes
[18:11] <JEEB> in-band vs out-of-band
[18:11] <saste> i suppose this is stored in the codec extradata, and updated during the encoding process
[18:11] <cone-574> ffmpeg.git 03Carl Eugen Hoyos 07master:149def7781fd: configure: Only build ffserver if SA_RESAMPLE is available.
[18:11] <cone-574> ffmpeg.git 03Carl Eugen Hoyos 07master:8e3c5c70ca9f: g726: Do not try to decode more than one channel.
[18:11] <cone-574> ffmpeg.git 03Carl Eugen Hoyos 07master:aecb9d39bc66: rmdec: Forward error messages from rm_assemble_video_frame() to the caller.
[18:11] <saste> but then the encoder needs to be aware of the format container, since different format will require different headers
[18:12] <saste> so basically I don't know how I am supposed to interpret extradata (and debug related problems)
[18:14] <saste> cehoyos, no commit hash?
[18:14] <cehoyos> For a ticket that nobody is interested in?
[18:14] <cehoyos> I will close the rv ticket later with all three hases.
[18:14] <cehoyos> hashes.
[18:14] <saste> cehoyos, how do you know people is not interested?
[18:15] <cehoyos> That qnx compilation was broken for a long time and nobody reported it and that nobody set the ticket to "reproduced" (I cannot reproduce it)
[18:15] <cehoyos> (It was broken because of a change in qnx)
[18:16] <cehoyos> But I sent an email to the mailing list, that is important imo;-)
[18:21] <cehoyos> If anybody wants to comment on ticket 2777, please do so!
[18:22] <cone-574> ffmpeg.git 03Carl Eugen Hoyos 07master:289737c8be28: configure: Disable avresample if an old version of yasm is used.
[20:16] <durandal_1707> michaelni: see 374 line of libswresample/swresample.c
[20:17] <durandal_1707> it asserts if layout is unset
[20:17] <durandal_1707> and there is probably lavfi thing that resets channel count using layout 0
[20:17] <durandal_1707> which is retarded
[20:18] <durandal_1707> for testing remove check at 128 of libavfilter/asrc_aevalsrc.c
[20:19] <durandal_1707> and than try to create 9 channe; audio: ffmpeg -f lavfi -i aevalsrc=0|0|0|0|0|0|0|0|0
[20:22] <durandal_1707> also try this: cat /dev/zero > /tmp/out.pcm
[20:23] <durandal_1707> and abort after file reaches few MBs
[20:23] <durandal_1707> ffmpeg -channels 22 -f s16le -i /tmp/out.pcm /tmp/o.wav
[20:24] <cehoyos> ffmpeg -ac 22 -f s16le -i /dev/zero ?
[20:24] <durandal_1707> produced wav can't be filtered, afade,aecho,volume gives "Error while decoding stream #0:0: Cannot allocate memory"
[20:24] <durandal_1707> cehoyos: yes
[21:14] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:0a06e6e49b9b: av_frame_get_buffer: Do not fail when the channel layout is unknown
[22:18] <cone-574> ffmpeg.git 03Paul B Mahol 07master:673d4e82d4c5: fate: add tests for stereo3d filter
[22:33] <durandal_1707> when will it be possible to burn subtitles stream?
[22:33] <cehoyos> works fine here
[22:35] <durandal_1707> with filters?
[22:35] <cehoyos> I suspect it does not work without filter or do I misunderstand?
[22:35] <durandal_1707> subtitle filter takes files
[22:36] <wm4> ubitux kept talking about that
[22:36] <cehoyos> You mean text subtitles have to be written to an ass file first?
[22:36] <wm4> you'd need to add a subtitle path to lavfi
[22:36] <wm4> cehoyos: any file type should work
[22:37] <durandal_1707> wm4: then add it :)
[22:37] <wm4> it doesn't have to be ass, as long as there's a lavc decoder AFAIK
[22:37] <wm4> where decoder means converter
[23:17] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:f3d138ab2292: avdevice/lavfi: fix input with unknown channel layout
[23:17] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:aac57c765ff4: avfilter/asrc_aevalsrc: fix cases of unknown channel layout
[23:50] <wm4> michaelni: any chance to get correct chroma placement in libswscale? currently it seems to always use mpeg1 placement, but mpeg2/h264 placement would be better
[23:55] <Compn> chroma placement
[23:56] <wm4> Compn: ?
[23:57] <durandal_1707> michaelni: bunch of filters use av_get_channel_layout_nb_channels(), this just does not work for >8 channels
[00:00] --- Sun Jul 14 2013