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

[burek]

[00:27] <durandal_1707> isn't 10 bit interlaced material a myth?
[00:27] <JEEBsv> no
[00:27] <JEEBsv> much of the pro stuff is like that
[00:27] <durandal_1707> you have such samples?
[00:28] <JEEBsv> nothing share'able
[00:28] <JEEBsv> but yes, I've had such things on hand
[00:28] <JEEBsv> although generating such samples out of publicly available stuff shouldn't be too hard :)
[01:49] <wm4> ubitux: somehow I get weird behavior when trying to seek in some vobsubs, example: https://www.dropbox.com/s/tkak5bxsjcfh4t1/sub.txz (unpack with tar xf)
[01:50] <wm4> seeking to a certain pts seems to return packets at a much later time
[01:51] <wm4> I'm suing avformat_seek_file() with stream_index==-1, so the pts values should be in AV_TIME_BASE
[01:53] <wm4> heh, rescaling the PTS to the stream's timebase seems to return correct results
[01:53] <wm4> so which is it
[01:54] <wm4> the behavior that works, or the behavior that is documented?
[01:55] <wm4> ff_subtitles_queue_seek() doesn't even use stream_index
[01:55] <wm4> so I suppose it's a bug
[02:31] <wm4> this is so horrible
[02:31] <wm4> why do subtitles require a different seek function in the first place
[02:32] <wm4> not that this "new" seek API solves any actual problems seeking has...
[04:05] <cone-922> ffmpeg.git 03Michael Niedermayer 07master:797762fcf3c5: avfilter/af_aecho: silence "maybe uninitialized warning"
[04:05] <cone-922> ffmpeg.git 03Michael Niedermayer 07master:64c54f8333dd: avfilter/af_compand: silence "maybe uninitialized" warnings
[10:13] <ubitux> wm4: ff_subtitles_queue_seek() was extracted from ass seeking and i re-used it
[10:13] <ubitux> it's not in the generic code because it requires the queue context, which is in the private context
[10:13] <ubitux> and the generic index system for seeking wasn't enough so it wasn't used (iirc)
[10:14] <wm4> anyway, it means the only situation where you'd want to use the "new" seek API is the case where the API is buggy, which is quite fun
[10:14] <ubitux> the "new" seek api fallbacks on the old anyway
[10:15] <ubitux> seeking with subtitles is a bit tricky anyway, but last time i tried it worked
[10:15] <wm4> what's tricky about it?
[10:16] <ubitux> they are sparsed, and have duration overlaps
[10:17] <wm4> you just need to sort hem by start time
[10:17] <ubitux> that's the case
[10:20] <ubitux> brb
[10:21] <ubitux> wm4: can you give me a seeking position that fails with that file?
[10:22] <wm4> just seeking a minute in should return packets that are way ahead
[10:25] <wm4> also, I wonder why it used to work...
[10:26] <ubitux> mmh and we still don't have a vobsub muxer to test that properly ofc..
[11:04] <ubitux> wm4: i added some debug, and it seems to work
[11:05] <ubitux> -ss picks sub 386/4117, which sounds correct somehow
[11:05] <ubitux> lookup ts=60000000
[11:05] <ubitux> select ts=59850000 (386/4117)
[11:06] <ubitux> mmh
[11:06] <ubitux> it's not correct indeed
[11:14] <ubitux> wm4: ok i get it
[11:14] <ubitux> the sub has multiple streams, so the timestamps are not rescaled
[11:14] <ubitux> ...and so it doesn't work :)
[11:15] <nevcairiel> at least you know where the issue is now :)
[11:16] <ubitux> i'm not used to external subtitles files with multiple streams :p
[11:35] <ubitux> michaelni_: can you remind me why aa86d2d8846155ccdbb6f8824294a548fe42dfc2 ?
[11:36] <ubitux> it's actually a bit problematic to know within the seek callback if the ts are rescaled or not because of this
[11:36] <nevcairiel> the more important question is why there is a nb_streams check in there, it gives the seek function a rather inconsistent state
[11:37] <nevcairiel> at the very least it should also change stream_index to 0, so the seek function knows
[11:38] <wm4> but really, the "old" seek function should just work
[11:38] <ubitux> nevcairiel: it's to make sure it's not rescaled on a wrong stream
[11:39] <nevcairiel> but why move the code at all then
[11:40] <nevcairiel> since seek functions still need to handle stream_index == -1
[11:41] <ubitux> yes that's my question actually
[11:48] <ubitux> mmh
[11:49] <ubitux> wm4: what was your concern about the seek 2 api?
[11:54] <michaelni_> ubitux, just woke up (so not sure my brain works already ;), about the comit it looks like its missing stream_index=0
[11:55] <michaelni_> about nb_streams==1, ff_subtitles_queue_seek() only supports nb_streams==1
[11:55] <ubitux> yeah but that's not the only problem actually
[11:56] <ubitux> http://pastie.org/8305537
[11:58] <ubitux> so within the read_seek2(), if stream_index is specified, timestamps will be rescaled
[11:58] <ubitux> otherwise you have to rescale them yourself
[11:58] <ubitux> which i do in vobsub by recalling the api function specifying a stream
[11:59] <ubitux> (sbg chunk likely wrong)
[12:08] <ubitux> michaelni_: i can't parse the read_seek2 doxy
[12:08] <ubitux>      * Seeking will be done so that the point from which all active streams
[12:08] <ubitux>      * can be presented successfully will be closest to ts and within min/max_ts.
[12:08] <michaelni_> the hunk for avformat_seek_file() looks wrong
[12:08] <ubitux> why?
[12:09] <ubitux> if a stream index is specified, or if there is only one stream, we rescale timestamps based on its time base
[12:10] <ubitux> if the callback receives a stream_index != -1 it can assume rescaled timestamps
[12:10] <ubitux> otherwise it can recall the api func specifiying a stream_index, or do some other kind of seeking
[12:10] <michaelni_> if a stream index is specified the timestamps are already in that streams timebase
[12:11] <ubitux> oh
[12:11] <ubitux> mmh ok
[12:13] <ubitux> i wanted to rely on avformat_seek_file to do the rescaling for me
[12:13] <ubitux> but i guess i can't
[12:14] <ubitux> for ts it's not really a problem, but with the two additionnal bounding ones, it can be a pain
[12:16] <ubitux> maybe i should just use the API v1 :-°
[12:16] <j-b> michaelni_: out f curiosity, why isn't http://trac.ffmpeg.org/attachment/ticket/2686/aac-improvements-wip-v4-vbr.patch applied?
[12:18] <nevcairiel> because its flawed, the author is still working on it
[12:19] <nevcairiel> he'll submit it to the ml when its ready
[12:20] <j-b> how more flawed than the current one can it be?
[12:22] <michaelni_> ubitux, with the v1 API how could the user specify that he wants to seek 10sec forward but not backward relative to the current position ?
[12:22] <ubitux> no idea
[12:23] <ubitux> well i'll just rescale within vobsub for now
[12:26] <michaelni_> also when there are multiple streams that can be seeked independantly, the more costly to decode streams should start closer to the point to where all can be presented
[12:28] <michaelni_> because all streams need t be decoded until the point where they can be presented correctly before they can be presented to the user
[12:28] <michaelni_> and decoding a few seconds of subtitles is cheaper than a few seconds of video
[12:29] <michaelni_> (not entirely on topic but it seems not in the docs and should be)
[12:32] <michaelni_> a practical implementation of a demuxer might seek on the video stream and once a keyframe is found seek the subtitles (assume that can be done independantly) so that the subtitle before that video keyframe is choosen
[12:37] Action: ubitux just realized vobsub demuxer has a huge problem..
[13:47] <cone-767> ffmpeg.git 03Anton Khirnov 07release/1.1:251b4655be73: vcr1: add sanity checks
[13:47] <cone-767> ffmpeg.git 03Anton Khirnov 07release/1.1:8dc4b2c92e49: pictordec: break out of both decoding loops when y drops below 0
[13:47] <cone-767> ffmpeg.git 03Michael Niedermayer 07release/1.1:580418bd5585: avfilter/vf_fps: make sure the fifo is not empty before using it
[13:47] <cone-767> ffmpeg.git 03Michael Niedermayer 07release/1.1:701543a081e0: avcodec/mjpegdec: Add some sanity checks to ljpeg_decode_rgb_scan()
[13:47] <cone-767> ffmpeg.git 03Michael Niedermayer 07release/1.1:6bfa823b70ec: Merge commit '8dc4b2c92e492aa172327d10c926d5ca3a04371c' into release/1.1
[14:16] <cone-767> ffmpeg.git 03Paul B Mahol 07master:5a16a1d508d5: avfilter/af_asetnsamples: remove .needs_writable as it is not required
[14:25] <cone-767> ffmpeg.git 03Anton Khirnov 07release/1.1:1e9d234c0c62: pictordec: pass correct context to avpriv_request_sample
[14:25] <cone-767> ffmpeg.git 03Anton Khirnov 07release/1.1:4cb3efc206a6: lavf: avoid integer overflow when estimating bitrate
[14:25] <cone-767> ffmpeg.git 03Anton Khirnov 07release/1.1:f3c7e604fabd: 4xm: check that bits per sample is strictly positive
[14:26] <cone-767> ffmpeg.git 03Anton Khirnov 07release/1.1:9486e9871287: ape demuxer: check for EOF in potentially long loops
[14:26] <cone-767> ffmpeg.git 03Martin Storsjö 07release/1.1:3d91117df003: alac: Limit max_samples_per_frame
[14:26] <cone-767> ffmpeg.git 03Martin Storsjö 07release/1.1:aade60ab1657: matroskadec: Check that .lang was allocated and set before reading it
[14:26] <cone-767> ffmpeg.git 03Michael Niedermayer 07release/1.1:dfe0ba46bf48: Merge commit 'aade60ab165716523788cd11caf03ae61b40144a' into release/1.1
[14:26] <cone-767> ffmpeg.git 03Michael Niedermayer 07release/1.1:5c6aea5c31bf: avformat/utils: Fix bitrate overflow check
[14:36] <cone-767> ffmpeg.git 03Martin Storsjö 07release/1.1:7b9bcd993c10: 4xm: Check that the read track value is non-negative
[14:36] <cone-767> ffmpeg.git 03Martin Storsjö 07release/1.1:790606cfe97e: alac: Check that the channels fit at the given offset
[14:36] <cone-767> ffmpeg.git 03Michael Niedermayer 07release/1.1:68c990466990: mjpegb: Detect changing number of planes in interlaced video
[14:36] <cone-767> ffmpeg.git 03Martin Storsjö 07release/1.1:b01e4d80c69d: mpegvideo: Avoid 32-bit wrapping of linesize multiplications
[14:36] <cone-767> ffmpeg.git 03Michael Niedermayer 07release/1.1:de5e00336988: Merge remote-tracking branch 'qatar/release/9' into release/1.1
[14:36] <cone-767> ffmpeg.git 03Michael Niedermayer 07release/1.1:87908de715c2: avcodec: add emuedge_linesize_type
[16:37] <cone-767> ffmpeg.git 03Michael Niedermayer 07release/1.1:fbbd6317e2c1: avcodec/vcr1: replace redundant checks from libav (8aba7968dd604aae91ee42cbce0be3dad7dceb30)  by asserts
[16:37] <cone-767> ffmpeg.git 03Michael Niedermayer 07release/1.1:6d2e3efd7c9c: avcodec/vcr1: return the actual number of consumed bytes
[20:16] Action: durandal_1707 made big cosmetic patch
[20:21] <cone-767> ffmpeg.git 03Paul B Mahol 07master:b077d8d9082d: avfilter: remove redundant .get_(audio/video)_buffer initializations
[20:37] <cone-767> ffmpeg.git 03Paul B Mahol 07master:d2382903d6f2: avfilter/vf_rotate: fix 'oh' option description
[21:44] <cone-767> ffmpeg.git 03James Almer 07master:2df184f3d5af: doc: fix install-doc dependencies
[21:44] <cone-767> ffmpeg.git 03James Almer 07master:1e97ae4ba363: doc: rename *install-doc to *install-html
[21:50] <michaelni_> durandal_1707, b077d8d9082d057d4c7abd9e0b1a98f9651cfaa8 breaks fate
[21:50] <michaelni_> fate-filter-pixfmts-vflip
[21:54] <durandal_1707> but i did not changed that filter
[21:54] <michaelni_> yes and ?
[21:58] <durandal_1707> its breaking in xyz something
[21:58] <michaelni_> yes, i confirm thats what iam seeing too
[21:58] <michaelni_> and no i dont know why
[21:58] <durandal_1707> but fate list yuyv packed something...
[22:00] <durandal_1707> ah that is unrelated issue...
[22:17] <durandal_1707> perhaps something overwrites format and causes it be treated as rgb48?
[22:20] <durandal_1707> well sws does that...
[22:21] <durandal_1707> it appears adding it back to vf_format fixes it
[22:25] <durandal_1707> but why vflip breaks but transpose doesn't...
[22:42] <cone-767> ffmpeg.git 03Paul B Mahol 07master:4cf1900ba7e4: avfilter/vf_format: add .get_video_buffer back
[22:48] <cone-767> ffmpeg.git 03Michael Niedermayer 07master:c4c3a3d580fa: vformat/tee: fix uninitialized use of ret
[23:06] <durandal_1707> michaelni_: is see that commented pool code in avfilter/video.c, i'm gonna remove it
[23:09] <cone-767> ffmpeg.git 03Paul B Mahol 07master:ffde17e70fd9: avfilter/vf_histeq: remove unused item from filter private context
[23:12] <wm4> durandal_1707: what is GBRAP16 useful for?
[23:13] <durandal_1707> wm4: didn't you looked at commit itself?
[23:14] <wm4> oh, I see... question still stands
[23:15] <durandal_1707> its like asking: what is LIGHT useful for?
[23:15] <wm4> troll
[23:22] <durandal_1707> i plan to use it in geq
[00:00] --- Sun Sep  8 2013