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

burek burek021 at gmail.com
Tue Dec 11 02:05:02 CET 2012


[00:18] <cone-298> ffmpeg.git 03Michael Niedermayer 07cbe43e62c9ac: ffserver: set oformat
[00:27] <cone-298> ffmpeg.git 03Michael Niedermayer 079929991da7b8: ffserver: set oformat
[00:31] <wm4> michaelni: 1. you should rename the "demuxer" avopt to "mime_type" (that's what it actually is), 2. you should make the mapping mime-type<->demuxer public (via two functions)
[00:55] <cone-298> ffmpeg.git 03Michael Niedermayer 071a5b7ce0ea67: riff: retry reading metadata without padding if it fails with
[00:55] <cone-298> ffmpeg.git 03Michael Niedermayer 07f1156fdc0234: riff: ignore ff_read_riff_info() failure.
[00:55] <cone-298> ffmpeg.git 03Michael Niedermayer 07c6850d38625b: riff: retry reading metadata without padding if it fails with
[00:55] <cone-298> ffmpeg.git 03Michael Niedermayer 0728e609a84fc9: riff: ignore ff_read_riff_info() failure.
[00:55] <cone-298> ffmpeg.git 03Michael Niedermayer 07455b98b7775c: riff: retry reading metadata without padding if it fails with
[00:55] <cone-298> ffmpeg.git 03Michael Niedermayer 07ec6271c01995: riff: ignore ff_read_riff_info() failure.
[00:55] <cone-298> ffmpeg.git 03Michael Niedermayer 0715526ac69f14: riff: retry reading metadata without padding if it fails with
[00:55] <cone-298> ffmpeg.git 03Michael Niedermayer 07c389ae543a5c: riff: ignore ff_read_riff_info() failure.
[00:56] <Daemon404> O_o
[00:56] <michaelni> o_O
[01:06] <cone-298> ffmpeg.git 03Michael Niedermayer 0720899c54f03c: http/utils: rename "demuxer" to mime_type
[01:07] <wm4> michaelni: thanks
[01:08] <cone-298> ffmpeg.git 03Michael Niedermayer 072a42b680e993: avidec: try to support oddly muxed MMES stream
[01:08] <cone-298> ffmpeg.git 03Michael Niedermayer 076d16f5c3f909: avidec: try to support oddly muxed MMES stream
[01:08] <cone-298> ffmpeg.git 03Michael Niedermayer 07436c011a77be: avidec: try to support oddly muxed MMES stream
[01:08] <cone-298> ffmpeg.git 03Michael Niedermayer 0773487f7dee13: avidec: try to support oddly muxed MMES stream
[01:08] <Daemon404> i think the bot is busted
[01:08] <ubitux> it's just missing the branch
[01:08] <ubitux> fixes are being backported
[01:08] <Daemon404> ah
[01:09] <wm4> it should print the branch too
[01:11] Action: michaelni writes a feature req to thresh
[01:17] <cone-298> ffmpeg.git 03Carl Eugen Hoyos 07a875a9a8339f: vqavideo: Reinitialise the actually used partial codebook bytestream-reader.
[01:31] <cone-298> ffmpeg.git 03Diego Biurrun 07ba0c8981200d: cosmetics: Fix dropable --> droppable typo
[01:31] <cone-298> ffmpeg.git 03Martin Storsjö 075d471b73d206: rtpdec: K&R formatting and spelling cosmetics
[01:31] <cone-298> ffmpeg.git 03Mans Rullgard 075c75708cf08d: configure: fix automatic processing of _extralibs in check_deps
[01:31] <cone-298> ffmpeg.git 03Michael Niedermayer 0778ac7ee97040: Merge commit '5d471b73d20616f5ac701ff62e5de49465cda264'
[02:05] <cone-298> ffmpeg.git 03Diego Biurrun 07998c1ee10cd0: configure: Have protocols select network code instead of depending on it
[02:05] <cone-298> ffmpeg.git 03Janne Grunau 07288bb3da16f5: svq3: make slice type value unsigned to match svq3_get_ue_golomb return type
[02:05] <cone-298> ffmpeg.git 03Mans Rullgard 07b8f3ab8e6a7c: ac3dec: output planar float only
[02:05] <cone-298> ffmpeg.git 03Michael Niedermayer 07b7d8484f272b: Merge commit 'b8f3ab8e6a7ce3627764da53b809628c828d4047'
[02:10] <cone-298> ffmpeg.git 03Mans Rullgard 0730b391642569: ac3dec: make downmix() take array of pointers to channel data
[02:10] <cone-298> ffmpeg.git 03Michael Niedermayer 07a93369845783: Merge commit '30b39164256999efc8d77edc85e2e0b963c24834'
[02:21] <durandal_1707> is there way to feed decoder raw packets without adding raw demuxer?
[02:34] <michaelni> image2/imag2pipe should work
[02:39] <durandal_1707> for audio too?
[02:40] <durandal_1707> i dont think so
[04:51] <cone-298> ffmpeg.git 03Mans Rullgard 07ec5da7aee277: ac3dec: decode directly into output buffers
[04:51] <cone-298> ffmpeg.git 03Martin Storsjö 07774e6fc9edec: libvpxenc: Support forcing keyframes
[04:51] <cone-298> ffmpeg.git 03Mans Rullgard 07d4f8cecc86ea: configure: fix automatic processing of _extralibs in check_deps
[04:51] <cone-298> ffmpeg.git 03Mans Rullgard 072dd95bd7cfd1: dsputil: remove unused macro WRAPPER8_16
[04:51] <cone-298> ffmpeg.git 03Michael Niedermayer 07529d3e002642: Merge remote-tracking branch 'qatar/master'
[04:51] <cone-298> ffmpeg.git 03Michael Niedermayer 077aabeea9ba0e: ac3dec: fix bugs in direct buffer use.
[11:09] <cone-851> ffmpeg.git 03Peter Ross 07e044cd4123fa: codec_desc: AV_CODEC_ID_SMPTE_KLV is data
[11:32] <cone-851> ffmpeg.git 03Peter Ross 07f540851ce320: mov: parse @PRM and @PRQ metadata tags
[12:20] <cone-851> ffmpeg.git 03Mans Rullgard 07f9e493c6f5bd: sh4: dsputil: remove duplicate of ff_gmc_c()
[12:20] <cone-851> ffmpeg.git 03Martin Storsjö 070d85663a4742: rtpdec: Rename a static variable to normal naming conventions
[12:21] <cone-851> ffmpeg.git 03Martin Storsjö 07ccb59c106a43: rtpdec: Remove an outdated todo comment
[12:21] <cone-851> ffmpeg.git 03Michael Niedermayer 076321e0289635: Merge remote-tracking branch 'qatar/master'
[12:42] <durandal_1707> michaelni: from quick look machines that failed tak test report warning for line 671
[12:44] <durandal_1707> it warns that operation may be undefined
[12:44] <durandal_1707> perhaps gcc bug?
[12:49] <michaelni> durandal_1707, try to do the ++ seperately on the next line
[12:49] <michaelni> i didnt notice the warning 
[12:50] <durandal_1707> well only old gccs seems to fail
[12:52] <wm4> looks like undefined behavior
[12:52] <durandal_1707> why?
[12:53] <wm4> not sure if it is, but "*a++=*a;"
[12:54] <durandal_1707> i have old gcc here too, so will try to reproduce
[12:58] <cone-851> ffmpeg.git 03Michael Niedermayer 074a5289ade32a: mips: disable ac3 downmix, until its updated to the new data layout.
[13:01] <iive> does C standard define how the parser is supposed to work?
[13:03] <iive> if parsing is done left to right, this could be equivalent of {*a=*a; a++;}. it could also be {*a=*(a+1); a++};
[13:05] <durandal_1707> i cant reproduce it here
[13:08] <cone-851> ffmpeg.git 03Paul B Mahol 074c7515286b26: takdec: silence/fix warning for undefined behavior
[13:10] <wm4> iive: AFAIK the parsing is well defined, but what matters here are semantics, and these are a bit "loose" to allow for optimization; so if durandal's issue is undefined behavior, it's about the semantics
[13:11] <iive> wm4: what does this mean?
[13:12] <wm4> even if the parse tree is well defined and the same for all compilers, behavior/semantics don't have to be
[13:27] <iive> wm4: what does this mean?
[13:28] <wm4> it means you're screwed
[14:06] <thresh> hello
[14:06] <durandal_1707> hello
[14:19] <thresh> michaelni: cone-851 should now output the branch as well
[14:20] <ubitux> thanks :)
[14:20] <ubitux> in blue? purple?
[14:20] <ubitux> rainbow?
[14:20] <thresh> yellow, for now
[14:20] <thresh> but I'm open for any suggestions
[14:21] <ubitux> :)
[14:23] <Compn> more glitter
[14:23] <Compn> and macarooooni noodles
[14:42] <cone-851> ffmpeg.git 03Michael Niedermayer 07master:ddbf0702c589: dsputil_mmx: switch to av_assert2()
[14:42] <michaelni> thresh, works great, thanks
[14:43] <durandal_1707> branch name should be before author name 
[14:52] <cone-851> ffmpeg.git 03Paul B Mahol 07master:d880c344087a: lavc: fix typo and avrn build dependencies
[15:02] <cone-851> ffmpeg.git 03Paul B Mahol 07master:a354839bfaa4: build: update mxf muxer dependencies
[15:18] <durandal_1707> wtf is this tools/bookmarklets.html?
[15:21] <ubitux> durandal_1707: https://www.ffmpeg.org/ffmpeg.html#tedcaptions
[15:33] <saste> anyone want to have a look at my segment patches?
[15:41] <cbsrobot> could we use a "|" as branch commit separator ?
[15:42] <cbsrobot> in my irc client the master:xxxxxx gets clickable automaticly
[15:42] <ubitux> or simply a space
[15:51] <cbsrobot> yes sure
[15:58] <wm4> ubitux: can ffmpeg stream these ted talks directly?
[15:59] <wm4> ubitux: also requesting support for youtube crap
[15:59] <ubitux> ted has a download link
[15:59] <ubitux> you can download the mp4 file, download the subtitles file with the bookmarklet, and then play with ffplay and -vf subtitles (or convert the sub to srt/ass and play it with another player)
[16:00] <wm4> ubitux: ah, libquvi enables mpv to directly play ted urls
[16:00] <ubitux> about adding integration of libquvi with ffmpeg, i'm not so sure
[16:00] <wm4> that's probably overkill
[16:01] <wm4> however, adding subtitle support to libquvi would be a good idea
[16:30] <cbsrobot> wm4 youtube crap is in xml - isn't it ?
[16:30] <wm4> cbsrobot: yes
[16:31] <wm4> the format is a bit overengineered too as far as I can see
[16:31] <wm4> even better, youtube has 2 subtitle formats
[16:31] <wm4> one for dialogue, one for signs
[16:31] <cbsrobot> i think ubitux won't touch anything with xml
[16:31] <ubitux> yup
[16:31] <ubitux> well i already did
[16:31] <ubitux> actually, with worse than xml
[16:32] <cbsrobot> but you can easely convert the youtube xml to ted subtitles
[16:32] <cbsrobot> ubitux: why not depend on an external xml lib ?
[16:32] <ubitux> ff_smil_extract_next_chunk() and ff_smil_get_attr_ptr() might help writing a new format
[16:32] <ubitux> cbsrobot: because that's not really xml
[16:32] <ubitux> it's often just broken markups
[16:33] <ubitux> like SAMI, being kind of open-tags-sometimes-closed-with-css-header
[16:33] <cbsrobot> well ok, maybe some xml libs are more forgivable ...
[16:34] <ubitux> i tried libexpat; while it's fine for HDS, it's not for most subtitles formats
[16:34] <cbsrobot> http://www.minixml.org/ looks interesting
[16:35] <cbsrobot> but I never tried it
[16:35] <kierank> hmm looks quite good
[16:35] <kierank> libxml2 is complicated
[16:36] <cbsrobot> sure some forks will prefer http://tibleiz.net/asm-xml/ , but it only works on x86
[16:36] <ubitux> fast!
[16:36] <kierank> it can't write xml though
[16:36] <kierank> (asmxml)
[16:37] <ubitux> printf can
[17:25] <durandal_1707> how to dump packets?
[17:26] <cone-851> ffmpeg.git 03Michael Niedermayer 07master:c73685398dee: swfdec: check lens validity
[17:27] <saste> durandal_1707, ffprobe -show_packets -show_data INPUT?
[17:29] <durandal_1707> i want do dump audio packets so i can use tham directly with another tool
[17:29] <durandal_1707> without writing teh dump muxer
[17:31] <durandal_1707> gues the only documentation about "sevc" in k3g1 is on chinese
[17:31] <durandal_1707> *guess
[17:33] <wm4> why does libavcodec etc. require -lSDL in the .pc file? this causes major inconveniences for applications
[17:33] <michaelni> j-b, it seems vlcticket 7860 contained a second file (which i somehow missed) this did produce a harmless infinite loop with ffmpeg, which ive just fixed
[17:34] <durandal_1707> wm4: huh, it should not be there
[17:34] <durandal_1707> for lavc at least
[17:34] <durandal_1707> lavd can be compiled with SDL
[17:34] <wm4> yes
[17:36] <saste> the flags are added to extra-flags, while they should be added only to the relevant library (lavd/lavfi)
[17:37] <saste> there is a lot of spam in libavcodec flags indeed
[17:38] <j-b> michaelni: may you be blessed by $deity
[17:39] <j-b> michaelni: not sure what was the first issue, maybe because we don't use HEAD
[17:54] <durandal_1707> hmm i have code for evrc-b and tag for it in 3gpp2 is secb
[17:54] <durandal_1707> i only have one sevc sample
[17:54] <durandal_1707> this is probably evrc-a
[18:02] <durandal_1707> looks like i downloaded wrong thing
[18:03] <durandal_1707> there is really too much speech codecs
[18:16] <durandal_1707> michaelni: ok to add codec ids that have no decoder? there are already some of them
[18:25] <michaelni> ok
[18:26] <durandal_1707> the thing is sevc sample have 2 channels
[18:26] <durandal_1707> and i fail to find more evrc samples
[18:29] <durandal_1707> end when decoding i get errors
[18:42] <durandal_1707> actually there are no errors when decoding but i get only silence
[18:43] <durandal_1707> so it looks like sample have no any speech
[18:47] <durandal_1707> lol files were hiden in A-codecs/suite
[19:49] <divVerent> hi... wondering why libavcodec's pkg-config file mentions -lSDL
[19:49] <divVerent> this makes it impossible to easily link to both ffmpeg and SDL2
[19:50] <divVerent> nothing in the .a file starts with SDL_, and when removing this -lSDL, programs still link fine
[19:51] <divVerent> libavcodec, libavformat, libavfilter, libavformat contain -lSDL
[19:51] <divVerent> but only libavdevice should (or maybe libavfilter too?)
[19:51] <divVerent> sure not libavcodec and libavformat
[19:52] <saste> divVerent, right
[19:52] <saste> now we need someone to fix the build system
[19:52] <divVerent> the fun part is that linking to both SDL and SDL2 causes no compile errors
[19:53] <divVerent> but SDL2 suddenly calls a SDL1 symbol... and ends up segfaulting
[19:53] <divVerent> inside SDL_CreateWindow()
[19:53] <divVerent> took me a while to track that down
[19:53] <divVerent> well... the build system does install different pkg-config files
[19:54] <divVerent> libswscale does not include -lSDL
[19:54] <divVerent> so there already must be SOME differentiation there
[19:55] <divVerent> libavutil is also clean
[19:55] <beastd> divVerent: probably $extralibs is a bit coarse 
[19:55] <beastd> oh ok, than maybe not
[19:56] <divVerent> it's indeed $extralibs
[19:56] <divVerent> libavutil e.g. doesn't use it
[19:56] <divVerent> libpostproc doesn't use -lm? Impressive
[19:57] <divVerent> just checked, libavfilter SHOULD not be needing SDL either... only libavdevice should
[19:58] <divVerent> ffplay.c and libavdevice/sdl.c are the only files including SDL.h
[19:58] <beastd> divVerent: would seem about right. i do not think the SDL dep in the other libs you stated is intentional
[19:58] <divVerent> both of which are perfectly justified ;)
[19:58] <divVerent> just wondering... when we DO clean this up... there probably are other deps that only libavdevice and ffplay use
[19:58] <divVerent> thinking of ALSA :P
[19:59] <divVerent> mainly wondering what else, basically, it looks like $extralibs needs to be split up
[19:59] <beastd> now, seems about the right to time to do it (if it can be done in time ;) )
[19:59] <divVerent> libavcodec and libavformat can use the same deps, even though libavformat e.g. has no use for libvorbis
[19:59] <divVerent> as one uses these two always together anyway
[20:00] <divVerent> libavfilter no idea, it SHOULD be useful without the other two, I suppose
[20:00] <divVerent> it maybe should have its own set of deps, basically
[20:00] Action: beastd is having a closer look now
[20:01] <divVerent> basically, the idea is splitting up $extralibs into $extralibs_devices, $extralibs_codecs... (and MAYBE $extralibs_formats too, but it's probably not worth to separate libavcodec and libavformat deps)
[20:02] <divVerent> and ffplay.c and libavdevice would get $extralibs_devices added (probably needs nothing special for ffplay.c, as it links to libavdevice anyway)
[20:02] <beastd> divVerent: I think if you want to split up all others at least making separate vars for all is warranted. will be hard to read/grasp otherwise+
[20:02] <divVerent> yes, just wondering about weird interactions between codec/format
[20:02] <divVerent> like, IIRC libvorbis doesn't work without libogg
[20:03] <divVerent> but generally... should I make a bug ticket about this?
[20:03] <divVerent> Soon[tm] mpv will be affected by this (that mplayer2 fork)
[20:03] <divVerent> as I am currently implementing a sdl2 video driver
[20:04] <divVerent> although I _may_ find a workaround by changing the order in which `sdl2-config --libs` and libav*'s libs are added
[20:04] <divVerent> so the SDL2 symbols have "priority" ;)
[20:04] <divVerent> still wondering why the linker didn't complain about the dupes, though
[20:04] <beastd> if you do not intend to work on it now, making a bug report so it won't be forgotten is a good idea. imho fixing would be a good thing as it is clearly generating wron deps
[20:05] <divVerent> I probably can't fix it quickly, as it's quite complicated without knowing everything which libs are used exactly where...
[20:05] <divVerent> so, a ticket it will be
[20:06] <beastd> divVerent: ok, tia
[20:07] Action: beastd looks up mpv
[20:08] <wm4> there's not much to look up, it's mplayer
[20:10] <divVerent> right :P
[20:10] <divVerent> ticket created
[20:10] <wm4> how reliable is AVPacket.duration in general? (it can be set to 0, I know, but other than that)
[20:15] <durandal_1707> this is mess there are different evrc versions
[20:16] <durandal_1707> EVRC-A is standardized as IS-127
[20:16] <durandal_1707> same name as found in qcp files
[21:02] <achour12> hi
[21:05] <achour12> is there any one can help ?
[21:06] <achour12> 0.o
[21:11] <michaelni> achour12, whats your question ?
[21:12] <achour12> well im trying with ffmpeg to do re-streaming
[21:13] <achour12> but when i put the link of rtmp + user+password
[21:13] <achour12> i doesnt work
[21:13] <achour12> it gives me error
[21:13] <achour12> password its not an internal or external command
[21:15] <achour12> i dont know what im doing wrong
[21:17] <thresh> speaking of branch/hash id separator, please decide on which one you want to use :)
[21:17] <cbsrobot> achour12: join #ffmpeg
[21:18] <cbsrobot> thresh: could you just use a space as an separator ?
[21:18] <cbsrobot> s/an/a/
[21:18] <thresh> if that's okay with michaelni and the rest
[21:18] <thresh> also, colour?
[21:18] <cbsrobot> for ubitux it's ok
[21:18] <cbsrobot> maybe ask michaelni 
[21:18] <ubitux> i wouldn't mind another color, but a space would be nice yes
[21:19] <cbsrobot> f.ex:
[21:19] <cone-851> ffmpeg.git 03Michael Niedermayer 07master:c3bb3334f683: h264: dont try to allocate scratchpad if linesize is not known
[21:19] <cbsrobot> ffmpeg.git Michael Niedermayer master c73685398dee swfdec: check lens validity
[21:20] <michaelni> thresh, i am with any color and seperator that people like ...
[21:21] <michaelni> am FINE with
[21:21] <achour12> michaelni can you help me plzzz
[21:21] <thresh> alright, so please choose one 
[21:21] <ubitux> achour12: this is a user question, please go ask the user channel (#ffmpeg), and pastebin
[21:21] <bcoudurier> hi guys
[21:21] <nevcairiel> The way i know the format, master remains in the current color, and the hash is uncolored but bold, like ffmpeg.git in front
[21:22] <nevcairiel> but anyway, i don't care =p
[21:22] <nevcairiel> space as separator and current colors would be fine for me
[21:26] <cbsrobot> hi bcoudurier 
[21:38] Action: durandal_1707 actually found windows app that decodes evrc in qcp
[21:39] <durandal_1707> which guess what! have ffmpeg in its dir
[21:45] <durandal_1707> and it nowhere mentions ffmpeg....
[21:48] <durandal_1707> and its plugin that decodes evrc looks like use avcodec :)
[21:48] <Compn> oooooo
[21:48] <Compn> lol
[21:48] <Compn> we dont have evrc i thought ?
[21:49] <Compn> i know i put an evrc sample in the samples repo...
[21:49] <durandal_1707> nope, you added it to "small" tasks page
[21:49] <durandal_1707> i failed to find source code that decodes something beside silence
[21:50] <Compn> does that windows app decode our sample properly ?
[21:50] <durandal_1707> yes it is song
[21:50] Action: Compn doesnt even know if our sample is valid...
[21:50] <Compn> oh good
[21:50] <Compn> ehe, i have a strange definition of 'small task' ... ;)
[21:55] <durandal_1707> plugin_init calls avcodec_register
[21:56] <durandal_1707> guess what codec - evrc
[21:57] <durandal_1707> guess i can find decoder func where easily
[21:58] <kierank> send them a gpl violation
[22:00] <durandal_1707> i'm still puzzled why i could get it work with dumped packets from qcp and ref code 
[22:00] <durandal_1707> *couldn't
[22:05] <Compn> durandal_1707 : is there an av_codec_id_evrc in strings avcodec51.dll ? :P
[22:05] <Compn> ehe
[22:06] <durandal_1707> avcodec53
[22:06] <Compn> whichever
[22:07] <durandal_1707> it is not in that dll but in separate
[22:10] <durandal_1707> hmm, gonna check lavf, it should have code that demuxes qcp
[22:22] <durandal_1707> looks like qcp demuxer is modified too
[22:23] <durandal_1707> guess i will just ask them source code :)
[22:24] <durandal_1707> michaelni: ^ what is exact procedure for this?
[22:25] <Compn> durandal_1707 : since you got code in there, you have the ability to demand source :)
[22:25] <Compn> i dont think we have a manual for requesting source
[22:25] <michaelni> durandal_1707, you could ask carl he did some license related work
[22:25] <Compn> i guess it goes ... email for source > no reply? > forward to SFLC via (person i forgot)
[22:26] <Compn> carl did a lot of work on it, yep
[22:26] <michaelni> person is saste
[22:27] <durandal_1707> so i will direct this to stefano?
[22:33] <durandal_1707> it is funny reversing known code
[22:38] <durandal_1707> the other plugin is ilbc decoder
[23:10] <wm4> is that cehoyos thing a bot?
[23:10] <ubitux> no point in repeating that differently
[23:12] <cbsrobot> lol
[23:14] <ubitux> anyway, that's called doing support :)
[23:23] <wm4> ubitux: remind me how this works with "split" vobsub packets
[23:23] <wm4> ubitux: apparently vobsub packets can be split - how do various muxers/demuxers/decoders in ffmpeg handle this?
[23:24] <ubitux> you mean the fragmented packets of dvdsubs ?
[23:24] <wm4> perhaps, yes
[23:24] <ubitux> the vobsub demuxer pack them into one packet
[23:24] <ubitux> that can be fed to the dvdsub decoder
[23:24] <ubitux> or directly muxed in mkv for instance
[23:24] <wm4> can't the dvdsub decoder take split packets?
[23:25] <wm4> s/split/fragmented
[23:25] <ubitux> i've tried to mux the fragments, it didn't work, so i guess no, but i'm not sure :)
[23:25] <wm4> sometimes the lavc dvdsub decoder doesn't decode subtitle packets from mplayer's demux_mpg (used for DVD playback)
[23:25] <ubitux> i wrote the vobsub demuxer really by trial and error
[23:26] <wm4> and I think that's the fragmented packet case
[23:26] <wm4> mplayer's spudec.c can handle this
[23:42] <cone-851> ffmpeg.git 03Michael Niedermayer 07master:623184afa218: itu H.263: Fix handling of PB blocks
[23:42] <cone-851> ffmpeg.git 03Michael Niedermayer 07master:e7101a7f3f6d: libavcodec/x86/mpegvideo: switch to av_assert2
[23:44] <ubitux> did Alex just rewrote af_asetnsamples?&
[23:45] <ubitux> wtf is wrong with these ppl? :(
[23:49] <saste> rewriting from scratch is more fun than mergework
[23:50] <ubitux> well, Justin just did the right thing to do
[23:50] <ubitux> he adapted working stuff, and added optimized stuff
[23:50] <ubitux> that was a pretty smart and efficient move
[23:50] <ubitux> too bad it doesn't happen more often
[23:51] <saste> ubitux: did you read my question?
[23:51] <ubitux> i guess i missed it
[23:51] <ubitux> call for review on segment?
[23:51] <saste> in a VOB, vobsub subtitles usually start far from the beginning of the file
[23:52] <saste> is there a way to tell ffprobe/libavformat to probe these streams, e.g. with ffprobe -show_streams?
[23:52] <ubitux> where did you ask this? oO
[23:52] <ubitux> i don't have it in my backlog
[23:52] <saste> i tried -probesize but didn't help
[23:52] <saste> i guess i was not connected yet then
[23:53] <ubitux> when we're speaking of VobSub we are talking about a .idx + a .sub (mpeg2 stream with bitmaps)
[23:53] <saste> yes
[23:53] <ubitux> are you just refering to dvd subtitles?
[23:53] <saste> yes
[23:53] <saste> in this file they start around 30s
[23:54] <saste> i can see the packets with ffprobe -show_packets
[23:54] <saste> but the subtitles streams are not show with ffprobe -i
[23:54] <ubitux> i've no idea
[23:54] <saste> *shown
[23:54] <wm4> increase the probe size or analyze duration?
[23:54] <saste> uhm ok
[23:55] <saste> i increased -probesize, to a size > of the position of the first subtitles packet
[23:55] <wm4> DVD does seem to have data structures outside of the mpeg packet stream that tell you the number of subtitles
[23:55] <saste> yes the famous IFO file
[23:56] <saste> still ffmpeg should guess the presence of the streams, since there are subtitles packets
[23:56] <ubitux> ffprobe finds the dvd sub within the .sub here
[23:56] <saste> and when decoding the file, the mpegps muxer warns that it found new subtitles streams
[23:56] <saste> ubitux, what is the ".sub"?
[23:56] <ubitux> the mpeg stream
[23:57] <ubitux> with bitmap subs
[23:57] <saste> yes but if embedded in a VOB?
[23:57] <ubitux> oh that, dunno
[23:58] <ubitux> we will need to support .IFO i guess
[23:58] <saste> wait -analyzeduration did the trick
[23:59] <saste> well i still have to get the difference between -analyzeduration and probesize
[00:00] --- Tue Dec 11 2012


More information about the Ffmpeg-devel-irc mailing list