[Ffmpeg-devel-irc] ffmpeg-devel.log.20120506
burek
burek021 at gmail.com
Mon May 7 02:05:03 CEST 2012
[00:28] <CIA-122> ffmpeg: 03Ronald S. Bultje 07release/0.10 * r746f1594d7 10ffmpeg/libavcodec/ (h264.c h264_ps.c): (log message trimmed)
[00:28] <CIA-122> ffmpeg: h264: additional protection against unsupported size/bitdepth changes.
[00:28] <CIA-122> ffmpeg: Fixes crashes in codepaths not covered by original checks.
[00:28] <CIA-122> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[00:28] <CIA-122> ffmpeg: (cherry picked from commit 732f9fcfe54fc9a0a7bbce53fe86b38744c2d301)
[00:28] <CIA-122> ffmpeg: Conflicts:
[00:28] <CIA-122> ffmpeg: libavcodec/h264.c
[00:28] <CIA-122> ffmpeg: 03Paul B Mahol 07release/0.10 * rcf5e119d4a 10ffmpeg/libavcodec/tta.c:
[00:28] <CIA-122> ffmpeg: tta: use skip_bits_long()
[00:28] <CIA-122> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[00:28] <CIA-122> ffmpeg: Signed-off-by: Anton Khirnov <anton at khirnov.net>
[00:28] <CIA-122> ffmpeg: (cherry picked from commit 9aff2d17533576f4ff52531e534f1319fb36a590)
[00:28] <CIA-122> ffmpeg: Signed-off-by: Reinhard Tartler <siretart at tauware.de>
[00:28] <CIA-122> ffmpeg: 03Paul B Mahol 07release/0.10 * r994c0efcc7 10ffmpeg/libavcodec/tta.c:
[00:28] <CIA-122> ffmpeg: ttadec: CRC checking
[00:28] <CIA-122> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[00:28] <CIA-122> ffmpeg: Signed-off-by: Justin Ruggles <justin.ruggles at gmail.com>
[00:28] <CIA-122> ffmpeg: (cherry picked from commit 2af3dc8698707f800f83f5fc890571a6a119866e)
[00:28] <CIA-122> ffmpeg: Signed-off-by: Reinhard Tartler <siretart at tauware.de>
[00:28] <CIA-122> ffmpeg: 03Ronald S. Bultje 07release/0.10 * r7240cc3f8b 10ffmpeg/libavcodec/mjpegdec.c: (log message trimmed)
[00:28] <CIA-122> ffmpeg: jpeg: handle progressive in second field of interlaced.
[00:28] <CIA-122> ffmpeg: Progressive data is allocated later in decode_sof(), not allocating
[00:28] <CIA-122> ffmpeg: that data leads to NULL dereferences.
[01:43] <CIA-122> ffmpeg: 03Michael Niedermayer 07release/0.10 * r25a2802239 10ffmpeg/libavformat/4xm.c:
[01:43] <CIA-122> ffmpeg: 4xmdemux: Check chunk size
[01:43] <CIA-122> ffmpeg: Fixes over reading the header array
[01:43] <CIA-122> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[01:43] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:43] <CIA-122> ffmpeg: (cherry picked from commit 474e31c904f766b6989fe614c3fb093e697c847f)
[01:43] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:43] <CIA-122> ffmpeg: 03Michael Niedermayer 07release/0.10 * r1ca4e70b6c 10ffmpeg/libavcodec/cook.c:
[01:43] <CIA-122> ffmpeg: cook: check subacket count
[01:43] <CIA-122> ffmpeg: Fixes out of array writes.
[01:43] <CIA-122> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[01:43] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:43] <CIA-122> ffmpeg: (cherry picked from commit 5a35bd92ad6b535fd5d3a7513169661de66ec247)
[01:43] <CIA-122> ffmpeg: 03Michael Niedermayer 07release/0.10 * ra4846943a3 10ffmpeg/libavformat/xmv.c:
[01:43] <CIA-122> ffmpeg: xmvdemux: dont let current_stream become invalid.
[01:43] <CIA-122> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[01:43] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:44] <CIA-122> ffmpeg: (cherry picked from commit 13381577d181fa732d6d2fa0491fa2ff50186546)
[01:44] <CIA-122> ffmpeg: 03Michael Niedermayer 07release/0.10 * rfe8508b948 10ffmpeg/libavformat/mov.c:
[01:44] <CIA-122> ffmpeg: 03Michael Niedermayer 07release/0.10 * r0d40fbaef0 10ffmpeg/libavcodec/iff.c:
[01:44] <CIA-122> ffmpeg: iff: fix null ptr dereference
[01:44] <CIA-122> ffmpeg: Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
[01:44] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:44] <CIA-122> ffmpeg: (cherry picked from commit 41abc9da50ba7a7b68bbbf6622475ce7a3c72e3f)
[01:45] <j-b> hmm
[12:02] <CIA-122> ffmpeg: 03Carl Eugen Hoyos 07master * r84aea80f78 10ffmpeg/libavformat/oggparsevorbis.c: oggparsevorbis.c: Check for OOM when using av_mallocz.
[12:43] <burek> is it possible in lutrgb filter to reference another pixel component, for example to rotate colors with lutrgb="r=b,g=r,b=g"
[12:44] <Compn> whoa
[12:44] <Compn> sounds interesting
[12:45] <burek> yes, I also wasn't aware of that filter :)
[12:53] <Compn> it may be a good idea to come up with a page of examples for the video filters
[12:53] <Compn> with screenshots ;)
[12:53] <burek> that would be cool
[12:54] <burek> ffmpeg is missing a lot of example usage, like wiki or something
[12:54] <burek> for people to see what is it capable of
[12:54] <burek> but I don't want to complaint all the time :)
[12:54] <Compn> its good to complain , gives us stuff to work on
[13:09] <wolfgangw> hi, i'm looking into how one could use lutrgb to calculate a 3x3 matrix transform lut. as it stands now apparently one can't because it is not possible to reference "the other" components when evaluating the expression for one component, like lutrgb="r=r*1 + g*2 + b*3: [...]". i want to do xyz->rgb transform where this is required. burek pointed me at libavfilter/vf_lut.c. looking at that now. it seems that it might indeed be
[13:09] <wolfgangw> easy to add, yes?
[13:16] <Compn> better wait for stefano or other devs to show up :)
[13:16] <Compn> or make a feature request on http://ffmpeg.org/trac/ffmpeg
[13:17] <wolfgangw> Compn, thanks, any idea when one of them usually shows up? is there a "best time" to ask for awesome features?
[13:17] <wolfgangw> not that ffmpeg is not awesome already
[13:18] <Compn> sorry, i dont know what time people show up
[13:18] <Compn> we're all in different countries :)
[13:18] <Compn> diff time zones
[13:18] <wolfgangw> sure, thanks. i'll add something to trac
[13:22] <burek> btw, is it possible to generate some test video, using ffmpeg? for example something like: ffmpeg -i /dev/null -vf rgbtestsrc='s=320x240' -vcodec ...
[13:23] <Compn> probably -f rawvideo -i /dev/urandom
[13:24] <Compn> but there is probably and easier way i just dont remember
[13:24] <Compn> probably probably
[13:24] Action: Compn goes to wake up, bbl
[15:25] <wolfgangw> is this a faq: when i use 'ffplay -pix_fmt <some format>' it nags about deprecated option '-pix_fmt' and to use '-pixel_format' instead (looking at ffplay.c's opt_frame_pix_fmt() (lines 3000-3004) where 'pixel_format' is returned anyway. but then i get 'Option pixel_format not found.' what gives?
[16:37] <CIA-122> ffmpeg: 03Nicolas George 07master * r8ad1964ec5 10ffmpeg/libavfilter/buffersrc.h:
[16:37] <CIA-122> ffmpeg: buffersrc: fix av_buffersrc_add_ref doxy.
[16:37] <CIA-122> ffmpeg: av_buffersrc_add_ref can handle audio too now.
[16:37] <CIA-122> ffmpeg: 03Nicolas George 07master * rba7395aace 10ffmpeg/ffmpeg.c: ffmpeg: replace av_vsrc_buffer_add_frame by av_buffersrc_add_frame.
[16:37] <CIA-122> ffmpeg: 03Nicolas George 07master * r6073ce71d0 10ffmpeg/libavfilter/Makefile: lavfi: install buffersrc.h.
[16:37] <CIA-122> ffmpeg: 03Nicolas George 07master * r317b2b7e92 10ffmpeg/libavfilter/ (buffersrc.h src_buffer.c):
[16:37] <CIA-122> ffmpeg: lavfi: remove av_buffersrc_buffer.
[16:37] <CIA-122> ffmpeg: It is no longer used anywhere.
[16:37] <CIA-122> ffmpeg: Furthermore, the header it was declared in was not installed,
[16:37] <CIA-122> ffmpeg: so it can not be considered part of the public API.
[16:37] <CIA-122> ffmpeg: 03Nicolas George 07master * r6ec1e0fed9 10ffmpeg/ffmpeg.c: ffmpeg: replace av_buffersrc_buffer with av_buffersrc_add_ref.
[16:37] <CIA-122> ffmpeg: 03Nicolas George 07master * r67a316bbda 10ffmpeg/libavfilter/vsrc_buffer.h: vsrc_buffer: deprecate the header.
[16:37] <CIA-122> ffmpeg: 03Nicolas George 07master * rfe511b6e32 10ffmpeg/libavfilter/asrc_abuffer.h: asrc_abuffer: deprecate the header.
[16:37] <CIA-122> ffmpeg: 03Nicolas George 07master * r675e83bb5c 10ffmpeg/libavfilter/ (asrc_abuffer.h src_buffer.c): asrc_abuffer: deprecate av_asrc_buffer_* functions.
[16:37] <CIA-122> ffmpeg: 03Nicolas George 07master * r870ca6a238 10ffmpeg/ffmpeg.c: ffmpeg: do not include vsrc_buffer.h.
[16:37] <CIA-122> ffmpeg: 03Nicolas George 07master * raaa94f2890 10ffmpeg/libavfilter/vsrc_buffer.h: vsrc_buffer: deprecate av_vsrc_buffer_add_video_buffer_ref.
[16:37] <CIA-122> ffmpeg: 03Nicolas George 07master * r4d4350f47a 10ffmpeg/libavfilter/ (buffersrc.h src_buffer.c vsrc_buffer.h):
[16:37] <CIA-122> ffmpeg: src_buffer: update get_nb_failed_requests name.
[16:37] <CIA-122> ffmpeg: Implement av_buffersrc_get_nb_failed_requests.
[16:37] <CIA-122> ffmpeg: Deprecate av_vsrc_buffer_get_nb_failed_requests.
[17:32] <CIA-122> ffmpeg: 03Philip Langdale 07master * rd1ac8e1034 10ffmpeg/libavcodec/crystalhd.c: (log message trimmed)
[17:32] <CIA-122> ffmpeg: CrystalHD: Improve detection of field pair -> two fields content.
[17:32] <CIA-122> ffmpeg: Istvan Sebok provided a sample where field pair -> two fields content
[17:32] <CIA-122> ffmpeg: was being misdetected by the existing logic. I added an additional
[17:32] <CIA-122> ffmpeg: test to check the input picture type as identified by our h.264
[17:32] <CIA-122> ffmpeg: parser.
[17:32] <CIA-122> ffmpeg: Signed-off-by: Philip Langdale <philipl at overt.org>
[17:32] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * radfa53b91f 10ffmpeg/libswresample/x86/audio_convert.asm:
[17:32] <CIA-122> ffmpeg: swr-x86-SIMD: 3 instructions less for stereo planar->packed s32/flt->s16
[17:32] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:32] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * r72ae583b7d 10ffmpeg/libswresample/x86/ (audio_convert.asm swresample_x86.c):
[17:32] <CIA-122> ffmpeg: swr-x86-simd: stereo unpack S16/S32/FLT-> S16/S32/FLT SSE/SSE2 (16 new SIMD functions)
[17:32] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:32] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * r11ad5f0d7d 10ffmpeg/libswresample/x86/swresample_x86.c:
[17:32] <CIA-122> ffmpeg: swr-x86-simd: create prototypes with macros, this is simpler.
[17:33] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:58] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * rf10aeab69c 10ffmpeg/libswresample/audioconvert.c:
[19:58] <CIA-122> ffmpeg: swr: audioconvert: consider mono to be planar
[19:58] <CIA-122> ffmpeg: This way it will be handled by the planar==planar SIMD
[19:58] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:58] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * rcbbc472467 10ffmpeg/libswresample/x86/ (audio_convert.asm swresample_x86.c):
[19:58] <CIA-122> ffmpeg: swr-x86-simd: add ff_unpack_2ch_int16_to_int16/int32/float_a_ssse3
[19:58] <CIA-122> ffmpeg: more than 10% faster (tested on sandybridge)
[19:58] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:13] <PapaSmurf007> I'm trying to add some watermarking capabilities in p-frame motion vectors to the mpeg2video codec in FFMPEG. After the picture type is determined to be a P-frame, I can modify the MV, but I'm having trouble determining how/what to update so that the residual is recomputed given the changed MV.
[20:19] <Compn> secret watermarks huh?
[20:23] Action: Daemon404 puts on his tinfoil hat
[20:23] <PapaSmurf007> lol
[20:24] <Compn> something like that can only be used for evil, you know
[20:24] <Compn> you should abandon that research
[20:24] <PapaSmurf007> ol
[20:24] <PapaSmurf007> what about copyright protection of videos?
[20:24] <PapaSmurf007> is that evil?
[20:25] <Daemon404> i dont think you wanna open that can of worms in a foss channel
[20:25] <Compn> its evil to bankrupt people based on some kid torrenting a film i think
[20:25] <nevcairiel> copyright is important for foss people as well, we're equally unhappy when someone steals our code
[20:26] <nevcairiel> what the lawyers to in case of "big content"''s copyright is another matter entirely
[20:26] <nevcairiel> s/to/do/
[20:27] <PapaSmurf007> i actually work on the side of detecting secret watermarks in digital media
[20:27] <Compn> stenography
[20:27] <Daemon404> stegano*
[20:27] <PapaSmurf007> no, thats the person who writes ... yeah, he got it
[20:27] <PapaSmurf007> steganography
[20:27] <PapaSmurf007> i work on steganalysis
[20:28] Action: Compn writes down things and calls it stenography
[20:28] <Compn> :P
[20:28] <PapaSmurf007> but to detect watermarks, one must embed watermarks
[20:28] <Daemon404> steganalysis can also be used for evil, mind you ;)
[20:28] <nevcairiel> i read that article on ars a while ago about the hidden al-Qaeda documents in a porn movie
[20:28] <nevcairiel> fun stuff
[20:28] <PapaSmurf007> yeah, that was pretty recent
[20:29] <Daemon404> and poorly executed
[20:29] <PapaSmurf007> porn videos are an excellent cover source
[20:29] <Daemon404> dunno why it was news
[20:29] <PapaSmurf007> the vast amount of porn traffic on the internet makes it hard to find that one video/image with the hidden info
[20:29] <nevcairiel> the article was more about steganography in general then that particular case
[20:30] <nevcairiel> although it was triggered by it
[20:30] <Daemon404> stegano is no substitute for proper encryptio.
[20:30] <PapaSmurf007> the coverage of this recent discovery of video steganography in use was pitiful
[20:30] <nevcairiel> Daemon404: can encrypt the data before hiding it, too :)
[20:31] <Daemon404> ;p
[20:31] <Daemon404> what comes to mind more than that
[20:31] <Daemon404> is that audio watermarking 'protection' used in some blurays
[20:31] <PapaSmurf007> well, if you don't want people to know that you are communicating, encryption won't work
[20:31] <nevcairiel> that cinavia crap?
[20:31] <Daemon404> yea
[20:32] <nevcairiel> funny thing is that it relys on the player to do the right thing when it finds it
[20:32] <Compn> so they kill bin laden , and then rifle thru his briefcase for clues or hints ?
[20:32] <nevcairiel> use a foss player, and its just ignored :P
[20:32] <Compn> and then find nothing
[20:32] <Compn> pretty dumb way of gathering intelligence
[20:33] <PapaSmurf007> i've used ffmpeg for this previously in a trivial way - i just modified MVs and didn' update the residuals, but that causes distortion in the video
[20:33] <PapaSmurf007> if you update the residuals, you can achieve equivalent perceptible quality at the cost of slightly higher bitrates
[20:33] <PapaSmurf007> so i'm trying to do it that way
[20:35] <Compn> someone who knows mv stuff might show up later PapaSmurf007
[20:35] <Compn> like michaelni
[20:35] <Daemon404> i kind of doubt michaelni is keen on watermarking
[20:35] <Daemon404> <_<
[20:36] <PapaSmurf007> well like i said, i work on the detection side
[20:36] <PapaSmurf007> i'm just trying to make my work more realistic but doing more realistic watermarking
[20:36] <PapaSmurf007> by* not but
[20:37] <PapaSmurf007> i'll ust keep searching motion_est_template.c and mpegvideo_enc.c
[20:38] Action: Daemon404 doesn't go to ravenholm... er... mpeg*.c
[20:40] <Compn> bad things happen there
[20:40] <Compn> ravenholm, we dont go there anymore.
[20:41] <PapaSmurf007> i found a nice comment there: //this function is dedicated to the braindamaged gcc
[21:10] <ubitux> mmh i wonder how to handle subtitles with duration up to the next sub
[21:10] <ubitux> demuxer should demux two subs maybe
[21:11] <ubitux> but if the last subtitle has a duration "up to the end" i guess i need to access the format duration
[21:12] <ubitux> </monologue>
[21:19] <iive> ubitux: hum? sort them by starting time.
[21:20] <ubitux> the issue is that if you want to convert to some other subtitle format, you need to know the duration of the subtitle event
[21:21] <ubitux> ASS for instance doesn't have anything to mark an event as "last until next sub"
[21:21] <ubitux> while some formats like microdvd or sami have
[21:23] <michaelni> ubitux, simple hack would be to use something big as duration
[21:23] <michaelni> what can a decoder do except display till end ?
[21:25] <michaelni> hmm
[21:25] <michaelni> rereading i see now you meant "next sub" not end of file
[21:25] <nevcairiel> could as well be end of file
[21:25] <nevcairiel> who knows if there is a next sub :)
[21:27] <ubitux> yes there are two issues
[21:27] <ubitux> subtitles event which last to the next sub (can be avoided with the demuxer going to the next sub)
[21:27] <ubitux> and subtitles event which last to the next sub when there is... no next sub ( end of file)
[21:27] <ubitux> which leads to the end of the media
[21:28] <ubitux> indeed a huge duration can work here
[21:28] <michaelni> or parser could wait till next sub and fill duration
[21:28] <michaelni> this may need to be optional to avoid unwanted delay whe its unneeded
[21:28] <nevcairiel> next sub could be a long time
[21:28] <nevcairiel> during playback, you cant wait that long
[21:29] <ubitux> i don't like the huge duration if you convert the subtitles to another format
[21:29] <nevcairiel> even when transcoding its not ideal, you need to place it near the audio/video of the same timestamps, or the demuxing afterwards would find it too late
[21:29] <nevcairiel> not to mention that duration is only a 32-bit int, with certain high timebases (like mkv uses), it already overflows
[21:37] <iive> ubitux: you can't have perfect conversion from .ass to sami. For once .ass allows a subtitles to appear independent of one another on different location on the screen.
[21:38] <ubitux> the issue is sami ass which is a bit more problematic imo
[21:38] <ubitux> (sami or even microdvd)
[21:38] <iive> e.g. translation of road sign. it could stay for a long time and a lot of other subtitles would be shown and hidden while it is still on.
[21:39] <ubitux> yes sure, but i care more about any formats ass
[21:45] <cbsrobot_> ubitux: btw. when I convert srt to ass and use the vf_ass to do hard subs, the fontsize in the ass file is not regognized
[21:45] <cbsrobot_> I didnt investigate it further
[21:46] <cbsrobot_> but when I convert ass files in a commercial subtitle editor it works
[21:49] <ubitux> the issue is in the process of converting srt to ass, or during vf_ass hardsub?
[21:50] <ubitux> the font support in vf_ass is quite limited iirc
[21:54] <cbsrobot_> I let you know when I have more time ...
[21:56] <PapaSmurf007> Okay, I believe I should be able to modify p_mv_tables in the encode_thread function of mpegvideo_enc.c, and the proper residuals "should" be computed by mpeg_motion_internal function of mpegvideo_common.h for the modified MVs...does this sound correct to anyone?
[21:57] <PapaSmurf007> ...going back to watermarking in P-frame motion vectors for those who missed the earlier discussion...
[21:59] <PapaSmurf007> michaelni: someone mentioned that you have some knowledge of this aspect of MVs in mpeg2video codec
[22:00] <burek> ubitux, do subtitles have some "default" duration maybe?
[22:01] <ubitux> in ASS it seems they don't
[22:01] <ubitux> if i understand your question well
[22:01] <ubitux> i was hoping that something like a zero-duration would make the subtitle last until the next one
[22:01] <ubitux> but it seems not
[22:03] <burek> maybe a default duration might be used to hide the text if no new events have occurred by that time
[22:03] <ubitux> that would be nice but it doesn't seem available in ass
[22:09] <burek> oh I see.. SAMI does not have end time
[22:12] <burek> well, you could count the number of letters in the title and produce some "guessed" duration based on text length, I guess
[22:14] <ubitux> burek: this will lead to overlapping subtitles
[22:14] <ubitux> a new subtitle event must replace the previous one
[22:14] <ubitux> and in microdvd it seems there is a similar feature
[22:14] <ubitux> like "{12434}{} foo"
[22:15] <ubitux> (start at frame 12434 and keep it until the next event)
[22:15] <burek> I guess you don't have access to entire subtitle in advance?
[22:15] <burek> but line by line, right?
[22:19] <CIA-122> ffmpeg: 03Martin Storsjö 07master * rdee48d095d 10ffmpeg/libavformat/rtpdec_h264.c:
[22:19] <CIA-122> ffmpeg: rtpdec_h264: Convert commented out code into setting an unused variable
[22:19] <CIA-122> ffmpeg: It is worth keeping instead of removing, in case reading this
[22:19] <CIA-122> ffmpeg: bit becomes necessary at some later point.
[22:19] <CIA-122> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[22:19] <CIA-122> ffmpeg: 03Martin Storsjö 07master * rf3d471f45f 10ffmpeg/libavformat/rtpdec_h264.c:
[22:19] <CIA-122> ffmpeg: rtpdec_h264: Clean up comments
[22:19] <CIA-122> ffmpeg: Split long comments, move long comments at the end of lines to
[22:19] <CIA-122> ffmpeg: separate lines above, fix vertical alignment, fix up comment style
[22:19] <CIA-122> ffmpeg: (unify trailing dots - comments had a mix of 2, 3 or 4 dots, where
[22:19] <CIA-122> ffmpeg: it would be just as good without them at all).
[22:19] <CIA-122> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[22:19] <CIA-122> ffmpeg: 03Martin Storsjö 07master * r2ed503af9f 10ffmpeg/libavformat/rtpdec_h264.c:
[22:19] <CIA-122> ffmpeg: rtpdec_h264: Add missing newlines to av_log calls
[22:19] <CIA-122> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[22:19] <CIA-122> ffmpeg: 03Martin Storsjö 07master * r0b3ac9fe05 10ffmpeg/libavformat/rtpdec_h264.c:
[22:19] <CIA-122> ffmpeg: rtpdec_h264: Cosmetic cleanup
[22:19] <CIA-122> ffmpeg: Add/fix spacing, split long lines, align assignments where suitable.
[22:19] <CIA-122> ffmpeg: Signed-off-by: Diego Biurrun <diego at biurrun.de>
[22:19] <CIA-122> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[22:19] <CIA-122> ffmpeg: 03Martin Storsjö 07master * rb97d21e4d6 10ffmpeg/libavformat/rtpdec_h264.c:
[22:19] <CIA-122> ffmpeg: rtpdec_h264: Free old extradata before clearing the pointer
[22:19] <CIA-122> ffmpeg: This avoids memory leaks if there actually was some extradata
[22:19] <CIA-122> ffmpeg: set before.
[22:19] <CIA-122> ffmpeg: 03Janne Grunau 07master * r29d27b5425 10ffmpeg/libavformat/mpegenc.c:
[22:19] <CIA-122> ffmpeg: mpegmux: add stuffing to avoid incomplete PCM frames
[22:19] <CIA-122> ffmpeg: Fixes https://bugzilla.libav.org/show_bug.cgi?id=244
[22:19] <CIA-122> ffmpeg: 03Mans Rullgard 07master * r47d18d5354 10ffmpeg/libavcodec/ (6 files):
[22:19] <CIA-122> ffmpeg: aacps: align some arrays
[22:19] <ubitux> burek: ATM it's a "one event at a time", but i guess i'll have to cache one sub in advance or something like this
[22:19] <CIA-122> ffmpeg: This is required for SIMD optimisations.
[22:19] <CIA-122> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[22:19] <CIA-122> ffmpeg: 03Mans Rullgard 07master * rbf1945af30 10ffmpeg/libavcodec/ (Makefile aacps.c aacps.h aacpsdsp.c aacpsdsp.h):
[22:19] <CIA-122> ffmpeg: aacps: move some loops to function pointers
[22:19] <CIA-122> (61 lines omitted)
[22:20] <burek> ubitux, it's a logical problem.. did you check out how did other converters solve that problem?
[22:21] <ubitux> most of the subtitles tools have a preload system so it's easier
[22:21] <ubitux> not a "stream" design like ffmpeg has
[22:21] <burek> I see. And you are writting this for ffmpeg only?
[22:22] <burek> I mean not as a shared lib or something
[22:22] <ubitux> well i'm working on the issue in ffmpeg
[22:22] <michaelni> PapaSmurf007, changing the mv in the ME should work but there will be a quality reduction
[22:23] <ubitux> michaelni: no particular conflicts with Anton's filtering work?
[22:23] <michaelni> you would have to reduce the quantizer to compensate
[22:26] <michaelni> ubitux, didnt notice anything ...
[22:26] <ubitux> ok, great :)
[22:26] <ubitux> he seems to be working on audio filtering at the moment
[22:26] <ubitux> so i was wondering
[22:27] <michaelni> i just saw 1 or 2 conflicts in todays merge related to avfilter and they where trivial
[22:28] <ubitux> ok
[22:29] <michaelni> btw, if there are areas of avfilter that arent covered by fate this probably should be imroved
[22:29] <RobertNagy> can anyone point me to where the formats are chosen for auto conversion between filters?
[22:31] <RobertNagy> from what I've searched it seems to always choose "link->in_formats->formats[0];"
[22:31] <RobertNagy> ah
[22:31] <RobertNagy> nvm
[22:32] <RobertNagy> found pick_format
[23:38] <PapaSmurf007> michaelni: regarding the quality reduction due to MV modification, I thought that the residual error would compensate for the quality reduction do to sub-optimal MV usage at the expense of a potentially higher bitrate?
[23:39] <PapaSmurf007> hmm, maybe quantization will increase due to a larger prediction error frame
[23:42] <PapaSmurf007> and thus result in quality reduction
[00:00] --- Mon May 7 2012
More information about the Ffmpeg-devel-irc
mailing list