[Ffmpeg-devel-irc] ffmpeg-devel.log.20121119
burek
burek021 at gmail.com
Tue Nov 20 02:05:02 CET 2012
[00:39] <cone-910> ffmpeg.git 03Michael Niedermayer 0727d39c225bb3: liavfi/avcodec: allow channel layouts with fewer channels than actually available.
[00:39] <cone-910> ffmpeg.git 03Michael Niedermayer 078a03a60b4af4: h264: Check gray scale CBP, fix out of array accesses.
[00:39] <cone-910> ffmpeg.git 03Michael Niedermayer 07e8fed4d3314c: error concealment: check that references are frames and not fields.
[01:24] <juanmabc> how could i get something like AVstream->file_size (which is deprecated) and always valid?
[01:26] <juanmabc> currently i compute from duration * time_base * bytes_per_sample * sample_rate
[01:26] <juanmabc> but duration not aways is valid
[01:26] <juanmabc> wich i don't care too much since i really want file_size, or to be more precise stream_size
[01:27] <juanmabc> the main issue i stream nicely on openal, but full preloading of the stream fails on some cases
[01:32] <juanmabc> it seems no field on the AVstream struct provides that for a grant, and file_size is deprecated, but, still, no avstream_get_size() or similar?
[01:34] <michaelni> juanmabc, maybe avio_size() is what you search
[01:34] <juanmabc> checking
[01:36] <juanmabc> is the AVIOContext provided in the usual av stack, i got format, codec, codeccontext and stream
[01:38] <juanmabc> AVFormat got one called pb, but since i want size of audio stream and that could be inside video container i want stream size on total container size
[01:40] <michaelni> juanmabc, you can get the filesize when the underlaying protocol supports it and the duration if a stream when its stored in the input and happens to be correct
[01:41] <michaelni> if you want a method that always works you have to read the whole movie
[01:41] <michaelni> there are movies where the stored duration is just wrong
[01:41] <juanmabc> yep, i guess that is the only left to do
[01:42] <juanmabc> i'm gonna leave it as "works based on underlying format"
[01:43] <juanmabc> mainly cause i would need memmoves too sinze i can't allocate unknown space in advance
[01:44] <juanmabc> i hate memmoves
[01:44] <juanmabc> thanks for the technical support
[01:48] <juanmabc> some formats seem never thought to be prebuffered
[01:49] <cone-910> ffmpeg.git 03Piotr Bandurski 07ade9960fc6f8: avrndec: support lowres for mjpeg
[01:49] <cone-910> ffmpeg.git 03Michael Niedermayer 0724c043c98ef2: mpegvideo: increase MAX_PICTURE_NUMBER.
[01:56] <cone-910> ffmpeg.git 03Piotr Bandurski 0745d8537ccf22: vble: do not abort when version is not 1
[02:07] <michaelni> burek, can you make fflogger also notify when a fate machine didnt submit new data since 2-3 days ?
[02:07] <michaelni> some of the boxes have the tendency to get stuck ...
[04:12] <cone-910> ffmpeg.git 03Michael Niedermayer 07ba353436a375: h264: dont stop parsing NALs without cleanup on DPC.
[08:50] Action: isildur curses irssi
[09:08] <durandal_1707> nevcairiel: what is DTS Express?
[09:09] <burek> is this currently possible with ffmpeg: http://ffmpeg.gusari.org/viewtopic.php?f=16&t=734
[09:10] <burek> michaelni ok, I'll see to add that feature too
[09:11] <Tjoppen> burek: shoving the raw image data to each node is probably going to be slower than simply encoding on the same machine
[09:12] <Tjoppen> or wait - you can generate each independently on each node? then maybe..
[09:12] <burek> well maybe, but I've heard of such server farms used for such thing
[09:13] <burek> they encode a dvd length movie in a couple of seconds
[09:13] <Tjoppen> well, you can try encoding a couple of raw h.264 streams and cat:ing them together
[09:13] <Tjoppen> and see what ffmpeg thinks of the result
[10:20] <cone-273> ffmpeg.git 03Carl Eugen Hoyos 07a5d4e94a97a6: Support iLBC in caf.
[11:00] <cone-273> ffmpeg.git 03Paul B Mahol 070dbf29722962: doc/general: move 8SVX codecs to right section
[11:00] <cone-273> ffmpeg.git 03Paul B Mahol 07086e305276d4: doc/general: remove 8SVX audio, there is no such codec
[11:00] <cone-273> ffmpeg.git 03Paul B Mahol 07305fe9ae5902: nut: add tag for PCM signed 8-bit planar
[11:27] <cone-273> ffmpeg.git 03Paul B Mahol 07b0d83e0dba55: doc/general: remove duplicate entry for ADPCM SMJPEG IMA
[12:18] <nevcairiel> durandal_1707: a low-bitrate DTS variant commonly used for commentary on Blu-ray discs
[12:19] <durandal_1707> nevcairiel: can lavf demux that?
[12:19] <nevcairiel> durandal_1707: ffmpeg-lavf can, yes, libav probably not
[12:21] <nevcairiel> i submitted a patch myself a while ago for the parser to properly split the frames
[12:24] <durandal_1707> nevcairiel: there are samples?
[12:24] <nevcairiel> no idea, i probably have a bunch of blurays at home which feature it
[12:26] <nevcairiel> i remember cutting a small sample as well, its probably hidden somewhere in my sample archives
[12:31] <durandal_1707> nevcairiel: if sample(s) are not available on samples.ffmpeg.org please upload them somewhere
[13:29] <cone-273> ffmpeg.git 03Michael Niedermayer 07fdbb6164a208: sbr: increase f_tablelim size, it appears it was too small by 1.
[14:21] <cone-273> ffmpeg.git 03Mans Rullgard 078f7b814f547d: build: set -U__STRICT_ANSI__ for newlib
[14:21] <cone-273> ffmpeg.git 03Mans Rullgard 075873b623a93c: configure: add basic support for ARM AArch64
[14:21] <cone-273> ffmpeg.git 03Diego Biurrun 073bd1eacd2a7d: configure: Refactor CPPFLAGS settings for glibc/uclibc
[14:21] <cone-273> ffmpeg.git 03John Stebbins 071c5805521c3e: PGS subtitles: Set AVSubtitle pts value
[14:21] <cone-273> ffmpeg.git 03Michael Niedermayer 074116151a4bf3: Merge commit '1c5805521c3e406886341d752ebf38f8d41e1d13'
[14:28] <cone-273> ffmpeg.git 03Diego Biurrun 0787af05c57579: x86: SPLATD: port to cpuflags
[14:28] <cone-273> ffmpeg.git 03Diego Biurrun 0789923fce7006: x86: h264_intrapred: Fix C function names in comments
[14:28] <cone-273> ffmpeg.git 03Michael Niedermayer 07e6d81ce22e43: Merge remote-tracking branch 'qatar/master'
[14:59] <ubitux> mmh
[15:00] <ubitux> is there a way to demux and decode one stream?
[15:00] <ubitux> (with the cmd line)
[15:00] <ubitux> (and decode only one)
[15:01] <durandal_1707> you need to demux everything to get something, no?
[15:01] <ubitux> well demuxing everything is not a problem
[15:01] <ubitux> the problem here is that i want to decode every pgssub
[15:01] <ubitux> but i can't map it to a null format
[15:01] <ubitux> since there is no encoder
[15:01] <ubitux> Stream #0:3 -> #0:3 (pgssub -> ?)
[15:01] <ubitux> Stream #0:4 -> #0:4 (pgssub -> ?)
[15:02] <ubitux> Encoder (codec none) not found for output stream #0:3
[15:02] <ubitux> :(
[15:02] <ubitux> using -map:s 0 -f null -
[15:02] <durandal_1707> lol, that is bug
[15:02] <ubitux> not really
[15:02] <durandal_1707> what pgssub decodes to?
[15:02] <ubitux> bitmaps :)
[15:03] <durandal_1707> you mean it creates bmps?
[15:03] <ubitux> it creates nothing
[15:04] <ubitux> it just uses the rects in the AVSubtitles struct
[15:04] <ubitux> there is no "raw" bitmap outputs for subtitles
[15:04] <durandal_1707> hmm i remember something...
[15:05] <durandal_1707> there is md5 protocol
[15:05] <ubitux> that won't help
[15:06] <durandal_1707> you sure?
[15:06] <ubitux> yes
[15:06] <durandal_1707> tried?
[15:06] <ubitux> yes
[15:07] <ubitux> we can't encode the pgssub
[15:07] <durandal_1707> than fix null so it works for subtitles ;)
[15:07] <ubitux> it does
[15:07] <ubitux> it just doesn't work when the encoder is unknown :(
[15:07] <ubitux> or well, doesn't exist
[15:08] <ubitux> ah i found a way :)
[15:08] <ubitux> -map:s 0 -c:s dvd_subtitle -f null -
[15:18] <ubitux> -map 0:s sorry
[15:31] <ubitux> j-b: what happened to the libswresample patch on vlc?
[15:31] <ubitux> don't you need it to play most of the audio now?
[15:36] <ubitux> heh, it's fun to see the mips guys berzerk on ffmpeg-devel
[15:37] <j-b> unmerged
[15:38] <ubitux> j-b: any technical reason?
[15:38] <j-b> don't remember
[16:18] <burek> is distributed processing supported in current ffmpeg? :)
[16:18] <burek> i.e. using server farms and such
[16:28] <cone-273> ffmpeg.git 03Piotr Bandurski 071b20877f34d9: vble: remove superfluous braces
[16:28] <cone-273> ffmpeg.git 03Michael Niedermayer 07c44a028e19c8: af_aresample: allocate at least 1 sample buffer. Fix null ptr dereference.
[16:34] <Compn> burek : google ffmpeg cluster
[16:34] <Compn> yep
[17:00] <ubitux> what happened to the concat demuxer btw?
[17:26] <ubitux> (seems Nicolas is motivated to continue to work on it \o/)
[17:52] <leandrosansilva_> Hello to all. When I read a video frame into a AVFrame, is it possible to access the buffer where the data is stored? Here I'm trying to use frame->data[0], but I couldn't get the size of it. Is it possible to know this value (size)?
[17:52] <nevcairiel> the size depends on the width/height and the pixel format
[17:54] <leandrosansilva_> Yes, in theory is pixel_size * width * height
[17:54] <nevcairiel> in practice too
[17:54] <nevcairiel> note that data[0] is only the first plane, the other planes may be in data[1] and data[2]
[17:54] <nevcairiel> for a common YUV setup
[17:55] <iive> beter use linesize instead of width*pixel_size
[17:55] <leandrosansilva_> i understand... if it were rgb it'd be data[0] for red, data[1] for green and data[2] for blue?
[17:55] <av500> no
[17:56] <nevcairiel> well, no or maybe
[17:56] <iive> leandrosansilva_: rgb planar formats are quite rare
[17:56] <av500> well, maybe there is planar RGB
[17:56] <nevcairiel> typically rgb is packed
[17:56] <nevcairiel> no separate planes
[17:56] <nevcairiel> it all depends on your pixel format =P
[17:56] <av500> sometimes they put an A to separate R and B that are always fighting
[17:57] <leandrosansilva_> ok, so for yuv I have to look at these 3 planes
[17:58] <leandrosansilva_> and the size of each plane is width * height, right?
[17:58] <av500> no
[17:58] <av500> it depends
[17:58] <av500> [17:52:51] <nevcairiel> the size depends on the width/height and the pixel format
[17:58] <iive> height*linesize
[17:58] <av500> yuv420 != yuv422 != yuv 444
[17:59] <iive> linesize is in bytes, and is used for faster access to the next line.
[17:59] <leandrosansilva_> ah, of course
[17:59] <iive> yuv formats use a trick, they use chroma channels at smaller resolutions. 1/2 and 1/4
[18:30] <cone-273> ffmpeg.git 03Michael Niedermayer 07ebf4750200d5: pthreads: increase MAX_BUFFERS due to 24c043c98ef22b9d4aa7a54ec5f1cebd21042dd7
[18:30] <cone-273> ffmpeg.git 03Gavin Kinsey 0719660a887677: Allow use of @ character in username and passwords embedded in URLs
[20:23] <cone-273> ffmpeg.git 03Clément BSsch 07c02ae4827191: swr: set default channel count options to 0.
[20:26] <leandrosansilva_> Hello to all. Is it "safe" to use testsrc video source (libavfilter) in a system in production? I need to generate a simple frame (using a single color as pattern) and I've just seen libav has a source called "color" which does this, but I couldn't find it on ffmpeg. But I found testsrc, which seems do to almost the same thing, but it doesn't seem to be safe to use it because it's said "mainly intended foro testing porpuses"...
[20:27] <ubitux> ffmpeg has a color source as well
[20:28] <ubitux> and yes, it is "safe"
[20:28] <ubitux> the testing purpose just means we use it for testing
[20:28] <ubitux> it's not to be interpreted as a warning
[20:28] <ubitux> just a hint about the usefulness
[20:29] <ubitux> ffplay -f lavfi -i color=c=purple
[20:29] <ubitux> this is an example for color source filter
[20:29] <leandrosansilva_> ok, I thought it mean you can break it, remove without a previous advice...
[20:29] <leandrosansilva_> thx
[20:30] <ubitux> no no, we won't break it; if at some point we change some options or anything, it will be along with a version bump
[20:30] <ubitux> like everything in the projectr
[20:32] <leandrosansilva_> ok, thx for your help :-)
[21:32] <ubitux> michaelni: btw, no comment on the ffserver/OPT_STRING patch?
[21:33] <ubitux> iirc you were a bit uneasy about the different OPT_STRING usage last time we talked about it
[22:05] <michaelni> ubitux, did you check all "git grep OPT_STRING" ?
[22:06] <michaelni> if you checked all then it should be ok
[22:15] <ubitux> yes i check them
[22:15] <ubitux> most of them are struct offset
[22:16] <ubitux> and i didn't see any const string set pre set_option calls, but maybe i'm mistaken
[22:17] <durandal_1707> is there way to tell decoder to decode up to number of samples set in stream duration?
[22:18] <durandal_1707> last frame handling is broken because codecs do not store number of encoded samples
[22:26] <cone-273> ffmpeg.git 03Bojan Zivkovic 07a74ae4691a45: mips: Optimization of AC3 FP encoder and EAC3 FP decoder
[23:15] <ubitux> michaelni: is the align 8 required for width & height with pp?
[23:28] <michaelni> ubitux, i think the code supports height %8 != 0 but its long ago ...
[23:30] <michaelni> about stride, if that isnt %8 == 0 it will be slow and so you shouldnt do that
[23:30] <michaelni> and with SSE of 16byte size it should become %16 == 0,
[23:31] <michaelni> but maybe better to ask for a stride of a multiple of 32 in the doxy to be a bit more future proof
[23:43] <ubitux> i just wanted to know if i could use a normal get buffer from lavfi
[23:43] <ubitux> without the need to align both w & h
[23:49] <michaelni> I suggest you try to align width if its easy
[00:00] --- Tue Nov 20 2012
More information about the Ffmpeg-devel-irc
mailing list