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

[burek]

[00:54] <madbytes> I'm generating a video using filter_complex but while overlaying a video. it doesnt include its audio. How can i fix this?
[00:57] <madbytes> c_14, http://pastie.org/9096356 In this command, i want "audio.mp3" to be added to the result video.
[01:01] <klaxa> pastebin the output too
[01:01] <klaxa> do people not read?
[01:06] <madbytes> http://pastie.org/9096366 Here.
[01:08] <klaxa> try adding -map 3 and scale it to 462x300 or 460x300
[01:08] <klaxa> using either -s or the scale video filter
[01:21] <xreal> klaxa: When adding an external MP3 created by lame, ffmpeg doesn't care about the 1105 samples "gap" at the beginning (at 44.1 kHz that's about 25 ms). Is there a way to fix this? It's not in sync with video.
[01:22] <klaxa> try using -itsoffset
[01:22] <klaxa> i think that's applied before the input
[01:22] <klaxa> set it to 0.025 then or -0.025
[01:22] <klaxa> not sure which way you have to shift
[01:22] <xreal> klaxa: oh, can't I do it on sample base?
[01:23] <klaxa> i don't think so
[01:23] <klaxa> you could add samples to the mp3
[01:23] <xreal> klaxa: I'd need to add it to the video then.
[01:23] <klaxa> why?
[01:23] <xreal> klaxa: the video starts 0.02504558 before the audio.
[01:24] <xreal> LAME adds 1105 samples at the beginning of each MP3
[01:24] <klaxa> then either remove those samples (not sure how) or set a negative offset for the mp3
[01:25] <xreal> oh wait wait
[01:25] <xreal> line 141: avctx->delay = lame_get_encoder_delay(s->gfp) + 528 + 1;
[01:25] <xreal> it takes care of the 529 samples encoder delay!
[01:25] <xreal> that are 11,9955 ms at 44.1 kHz
[01:28] <xreal> ahhhhhhhhhh
[01:28] <xreal> klaxa: Are you here?
[01:28] <klaxa> yes?
[01:28] <xreal> klaxa: 576 samples encoder delay + 529 samples decoder delay = 1105 samples
[01:29] <xreal> klaxa: addition, 1152 samples are added when using VBR
[01:29] <klaxa> okay
[01:29] <xreal> man, that's pretty deep LAME knowledge :D
[01:30] <xreal> lame --decode --decode-mp3delay -529
[01:30] <xreal> 576 samples = forward+backward MDCT transform
[01:44] <xreal> Yep, [x] ffmpeg does bugging mp3 decoding.
[01:44] <xreal> buggy*
[01:44] <xreal> Where can I report bugs?
[02:05] <klaxa> http://www.ffmpeg.org/bugreports.html
[02:16] <xreal> klaxa: do you know if it's possible to add the LAME header tag to an MP3 created by ffmpeg ?
[02:18] <klaxa> no idea
[02:18] <klaxa> i have never run into this issue before
[02:18] <xreal> klaxa: ffmpeg seems to be in very early development state, isn't it?
[02:18] <klaxa> not... really?
[02:18] <xreal> klaxa: there are many bugs, I've detected over several versions in the last days.
[02:19] <klaxa> well feel free to send patches to the ffmpeg-devel mailing list
[02:19] <xreal> klaxa: I'm not a programmer.
[02:19] <klaxa> ffmpeg's initial release was in 2000
[02:19] <xreal> I only can describe the problems.
[02:20] <klaxa> then write up bugreports
[02:20] <klaxa> so a developer can fix them
[02:20] <xreal> klaxa: I think, nobody cares about my bugs because <= 25 ms aren't a problem for anyone in here :D
[02:20] <klaxa> it's one of the important tasks of software development - writing bugreports
[02:20] <klaxa> i doubt that, audio/video sync precision is extremely important
[02:24] <xreal> klaxa: Is there a place where to upload a demo wav file?
[02:27] <c_14> Did you read the bugreports.html?
[02:27] <c_14> >Submitting Sample Media
[02:30] <xreal> c_14: LoL, I read the box but not the rest :)
[02:30] <xreal> => Email the ffmpeg mailing list and indicate the filename of the sample.
[02:30] <xreal> urgs
[02:30] <xreal> So I need a bug report on the website and on the mailing list?
[02:30] <xreal> I don't want to register at 1000 services.
[02:33] <xreal> Can't I write a complete bugreport and you post it?
[02:39] <xreal> oh great... avconv and ffmpeg have different results.
[02:41] <xreal> is there something like the "latest stable" of ffmpeg for win32?
[02:43] <c_14> You can try: http://ffmpeg.zeranoe.com/builds/win32/static/ffmpeg-latest-win32-static.7z
[02:44] <xreal> c_14: that's from GIT. Normally, you test the latest stable when doing bug reports.
[02:44] <xreal> this seems to be stable: http://ffmpeg.zeranoe.com/builds/win32/static/ffmpeg-2.2.1-win32-static.7z
[02:44] <JEEB> xreal, in general releases aren't kept in high regard in either libav or ffmpeg
[02:44] <JEEB> you should generally test against current HEAD
[02:45] <c_14> It even says so in the 3rd line on the bugreports.html
[02:46] <xreal> Can't I write a complete bugreport and you post it?
[02:52] <xreal> Hey, come on... I want to help you.
[03:13] <xreal> Could anyone please have a quick look over my bugreport before posting it?
[03:26] <xreal> There you go: https://trac.ffmpeg.org/ticket/3576
[03:40] <xreal> re
[06:57] <metulburr> instead of resaying everything, i will just post a link https://bbs.linuxdistrocommunity.com/showthread.php?tid=2081 ....trying to convert mp4 to mpg
[06:57] <metulburr> for pygame.movie
[06:59] <metulburr> ffmpeg -i ORIGINAL.mp4 -vcodec mpeg1video -an -ss 61 -t 19 output.mpg
[06:59] <metulburr> pridcues what i think might be the error
[06:59] <metulburr> [mpeg @ 0x19c9a40] VBV buffer size not set, muxing may fail
[06:59] <metulburr> but i am not sure what argument to give it
[07:00] <metulburr> ^produces
[10:35] <soman> Hi all. I use 'ffmpeg -i input.avi -vcodec copy -acodec copy -ss 00:02:22 -t 00:00:08 2.avi' to cut avi file but output files begins with sound but 1-2sec of blank black screen and sometimes the sound is muted but source videos is OK. what could be a problem? Xubuntu 12.04  ffmpeg version 0.8.10-4:0.8.10-0ubuntu0.12.04.1
[12:14] <anshul_> !log
[12:15] <soman1> Hi all. I use ffmpeg as 'ffmpeg -i input.avi -vcodec copy -acodec copy -ss 00:00:00 -t 00:00:15 output.avi' but get about 1-2 sec of empty black screen for every output video (sound is enabled while that screen is shown) and sometimes sound is muted when the source videos is OK. What could be a problem and how to fix that? ffmpeg version 0.8.10-4:0.8.10-0ubuntu0.12.04.1
[12:17] <blippyp_> soman1: First thing I'd do is update your ffmpeg: ffmpeg version 2.2.1 Copyright (c) 2000-2014
[12:21] <soman1> blippyp_: I'll try to find some ppa for ffmpeg.
[12:26] <diesel420> ffmpeg static build ftw
[12:27] <soman1> I tried it now (static build) - nothing changed
[12:37] <soman1> avisplit works well but output video's time is not corresponding specified time period from command line.
[12:39] <blippyp_> soman1: I haven't a clue what your problem might be - But I'm guessing it's related to the codec in the original file: run mediainfo on it and find out what codec it's using
[12:41] <soman1> blippyp_: here is info http://paste.kde.org/p5ywgmkhu/xsq3bf
[12:44] <blippyp_> soman1: All I can say is that I never work with xvid, so it wouldn't surprise me if that was your problem - maybe wait a bit and see if someone else can comment on that who does use xvid, or has had previous experience with xvid - It use to be a very common codec to use...
[12:45] <blippyp_> it's only a 13 minute video - maybe just re-encode it use x264, then run your command on it - it shouldn't take very long...
[12:46] <blippyp_> ffmpeg -i input.avi -c:v libx264 -crf 0 -preset ultrafast newfile.mkv
[12:47] <blippyp_> that will re-encode it quite fast (but will chew up a large chunk of space, so you'll probably want to delete it when you're done)
[12:48] <soman1> blippyp_: Unrecognized option 'c:v' + Failed to set value 'libx264' for option 'c:v'
[12:49] <blippyp_> you don't have x264
[12:49] <blippyp_> are you usng avcon?
[12:49] <soman1> OT works with -vcodec instead of c:v
[12:50] <blippyp_> -c:v works, I use it all the time - you got some other kind of build going on.... don't know what to tell you...
[12:51] <soman1> Now it works... I'll try my coommand on the result mkv and will write here about results
[12:52] <blippyp_> cool
[12:53] <blippyp_> oops - forgot to tell you to copy the audio - you might not have any sound - did you add that?
[12:55] <soman1> no. the file is about 1gb and it still works on it... It would be good to avoid blank screen at first.
[12:55] <blippyp_> if not re-run this: ffmpeg -i input.avi -vcodec libx264 -crf 0 -preset ultrafast -acodec copy -scodec copy output.mkv (this will re-encode the video and copy the audio and subtitle streams as well)
[12:56] <blippyp_> although it's using an mp3 codec, you might want to convert that to aac or ac3 or something
[12:57] <blippyp_> I usually use ac3 and libx264 (and I split video's all the time with precision)
[13:00] <soman1> unfortunately same command at mkv didn't help
[13:00] <blippyp_> post your video at pomf.se and then post the link here so I can download it
[13:01] <soman1> 185mb. ok?
[13:01] <blippyp_> really that big for 13 minutes?
[13:01] <blippyp_> that's too big
[13:01] <soman1> Yes.
[13:01] <blippyp_> it will only accept 50mb
[13:01] <blippyp_> do you know where you originally got it still?
[13:02] <soman1> I can send you it by p2p if 185mb is OK for you
[13:02] <blippyp_> no, I'd rather not
[13:02] <blippyp_> did you conver the audio or did you leave it as an mp3?
[13:03] <soman1> left as mp3. btw result mkv has sound
[13:03] <blippyp_> k, then try this:
[13:04] <blippyp_> ffmpeg -i input.avi -vcodec libx264 -acodec ac3 -scodec copy output.mkv
[13:05] <blippyp_> oops - don't forget the -crf 0 -preset ultrafast after the libx264
[13:08] <soman1> blippyp_: no success http://paste.kde.org/pqyc0picf/mf6k2y
[13:10] <blippyp_> I thought you said you updated your ffmpeg?
[13:10] <blippyp_> this is old - it's probably your problem
[13:11] <Jeroi> hello
[13:11] <blippyp_> it's not liking your format settings (probably for the audio) - you need to specify the bit rate or something
[13:11] <blippyp_> hi Jeroi
[13:11] <Jeroi> Is there any support how to setup windows minge Qt Creator to compile ffmpeg libs?
[13:12] <Jeroi> I get punch of errors
[13:12] <blippyp_> not a clue :(
[13:12] <Jeroi> Installed latest Qt5
[13:12] <Jeroi> opened one qtwrapper code for ffmpeg
[13:12] <Jeroi> and trying to compile the example
[13:12] <Jeroi> with mingw as my compiler
[13:13] <Jeroi> D:\mingw\include\stdlib.h:362: error: 'size_t' was not declared in this scope
[13:13] <Jeroi>  _CRTIMP void* __cdecl __MINGW_NOTHROW calloc (size_t, size_t) __MINGW_ATTRIB_MALLOC;
[13:13] <Jeroi>                                                        ^
[13:13] <Jeroi> similar errors like that
[13:14] <blippyp_> it's not understanding what size_t is...
[13:15] <blippyp_> maybe look in another source file and find out where it's being declared, then re-declare it again in that file
[13:15] <Jeroi> ok I removed my mingw path and now it seems it works but atm it dont find ffmpeg libs so some path names do not work in pro file I guess
[13:15] <blippyp_> not a clue - never used mingw :(
[13:17] <Jeroi> ok need to donwload ffmpeg libs
[13:17] <Jeroi> the folder does not exist any lib files
[13:17] <blippyp_> that would probably be a good start...  ;)
[13:17] <Jeroi> for the wrapper code
[13:22] <Jeroi> so I need only the lib folders?
[13:22] <Jeroi> libavutil
[13:22] <Jeroi> libavformat
[13:22] <Jeroi> and so one to include to my project to open video files?
[13:44] <galex-713> Hello again
[13:45] <galex-713> With -t/-ss options in ffmpeg, man page says it can support either hh:mm:ss[.xxx] or seconds
[13:45] <galex-713> Can I use ss[.xxx]? Like a number of seconds greater than 60
[13:46] <galex-713> The time in seconds plus the remaining ms
[13:53] <blippyp_> galex-713: no I don't think so - if you want to use ms you have to use the hh:mm:ss[.xxx] format
[13:54] <blippyp_> I might be wrong, but I'm pretty sure I've tried this and had to use the longer format (so I just stick with it now)
[13:59] <galex-713> argh
[17:46] <xreal> What does this answer by cehoyos mean? "Do you believe this is a regression?"
[17:46] <xreal> eeh question
[17:47] <xreal> I think, nobody understood my bugreport.
[17:47] <Bombo> xreal: i think that means a bug in the new version, that was not there in the version before
[17:48] <xreal> Bombo: So I need to test older versions, if the bug appears, too?
[17:48] <Bombo> xreal: think so
[17:48] <xreal> Bombo: ack. I hope, I can find any.
[17:49] <Bombo> xreal: if you find out when the bug happened it's easier to find/fix
[17:49] <Bombo> s/happened/appeared/
[17:50] <xreal> Bombo: Problem is, it might haven been built against another library version. So I can't test it correctly.
[17:51] <xreal> I'll try 1.01, 1.2, 2.02, 2.1, 2.13
[17:51] <JEEB> xreal, don't be put off by cehoyos
[17:51] <JEEB> just saying
[17:51] <JEEB> I've had my herps and derps with him, too :P
[17:52] <JEEB> generally #ffmpeg-devel has then helped if he hasn't gotten anywhere
[17:52] <xreal> JEEB: I simply didn't understand has question because I'm no native speaker :)
[17:52] <xreal> his*
[17:52] <JEEB> there's plenty of static builds so if you can find any release binaries for your platform, those should be good
[17:52] <JEEB> I think zeranoe made some?
[17:53] <JEEB> did you provide a means to replicate the issue in your ticket btw?
[17:53] <xreal> JEEB: My problem is concerning LAME. I think, the LAME lib is changing sometimes.
[17:53] <xreal> JEEB: https://trac.ffmpeg.org/ticket/3576
[17:53] <xreal> brb testing
[17:53] <JEEB> ok, so samples uploaded
[17:53] <JEEB> yeah
[17:54] <JEEB> you can reply "I am not sure, and I do not currently have the time to test"
[17:54] <JEEB> if you can't test :)
[17:54] <JEEB> cehoyos can then do that in case he wishes to
[17:56] <xreal> JEEB: I've just completed my tests with 5 stable releases.
[17:56] <xreal> 1 sec
[17:56] <xreal> interesting
[17:57] <xreal> Nope, the problem is always there.
[17:57] <xreal> v1.0.1 also had another problem: it created invalid WAV files :)
[17:58] <xreal> let me check older versions
[18:00] <xreal> Damn, I'd die for a non-GPL version with AAC support on win32 :(
[18:00] <xreal> I think, I'll pay someone on rent-a-coder, to write a howto.
[18:03] <xreal> Oh, things get worse before 0.8
[18:03] <JEEB> I don't think it's necessary to go that far
[18:03] <JEEB> a lot of stuff wasn't even ready at that point yet
[18:04] <xreal> JEEB: So the correct answer to "Do you believe this is a regression?" is "No." ?
[18:05] <JEEB> "I have tested X,Y,Z , and this does not seem to be a regression"
[18:05] <JEEB> x,y,z being the versions
[18:06] <xreal> thanks
[18:08] <xreal> JEEB: Do you think, this will ever be added? https://trac.ffmpeg.org/ticket/3577#ticket
[18:09] <JEEB> no idea, at least the defaults in lavf/lavc tend to try and not leave too much distringuishable information in the file
[18:09] <JEEB> but that looks similar to what libx264 writes
[18:09] <JEEB> so it could be an option there?
[18:09] <JEEB> not sure
[18:09] <JEEB> never used LAME API
[18:12] <xreal> JEEB: My main problem is: when I use extern LAME.exe, I can't mux audio and video correctly because of the padding LAME does.
[18:12] <xreal> So there's a gap at the begging, which makes everything out of sync.
[18:12] <xreal> beginning*
[18:13] <JEEB> btw, your problem is partially due to how ffmpeg deals with encoder delay. at least when it can read it
[18:13] <JEEB> if you take a mp4 file with encoder delay set for the audio track properly and lavf/lavc actually taking it into mention
[18:13] <JEEB> lavf will give you negative timestamps
[18:13] <JEEB> and if you deal with them correctly, it works as you'd assume
[18:13] <JEEB> BUT
[18:13] <xreal> JEEB: my problem is: how can I determin the correct delay :)
[18:13] <JEEB> if you output that mp4's audio into a wav
[18:13] <xreal> using LAME only, it's broken in FFMPEG.
[18:13] <JEEB> you will get the whole thing
[18:14] <xreal> JEEB: you know what?
[18:14] <xreal> Let me create a test file with tones and testing picture.
[18:14] <JEEB> because ffmpeg doesn't currently handle audio encoder delay in any way or form if your output format doesn't support some way of noting it (like wav)
[18:15] <JEEB> I've talked about it before on the -devel channels but there seems to be no concensus right now
[18:15] <xreal> JEEB: it handles it for MP3. But for the beginning only.
[18:15] <JEEB> xreal, are you actually reading what I'm saying?
[18:15] <xreal> JEEB: Seems like I don't understand itcorreclt.y
[18:16] <xreal> let me re-read it
[18:16] <JEEB> I'm telling you that this problem partially at least (if not most probably fully) is related to the fact that ffmpeg can't deal with encoder delay
[18:16] <JEEB> that is, if the encoder delay is coded somewhere
[18:16] <JEEB> like in my example with the mp4 file where it is actually written down
[18:16] <JEEB> libavformat and libavcodec will happily read that information, and use it
[18:16] <JEEB> and you will get audio packets with negative timestamps
[18:17] <JEEB> of which you of course generally cut off the negative timestamped ones
[18:17] <JEEB> now what does ffmpeg do?
[18:17] <JEEB> (in the case of ffmpeg -i hurrdurr.mp4 out.wav)
[18:17] <JEEB> it sees the negative timestamps
[18:17] <JEEB> and it sees the fact that wav can't handle negative timestamps
[18:18] <JEEB> thus it moves the starting point to the first negative timestamps
[18:18] <JEEB> and thus you get everything including the encoder delay in the wav
[18:18] <xreal> JEEB: Can't I tell it: "skip negativ timestamps" ?
[18:18] <JEEB> not that I know
[18:18] <JEEB> also I'm not sure if the timestamps can be read in your case, I'm just saying that if the timestamps will be read, you will still have that problem
[18:19] <JEEB> unless that gets fixed at some point
[18:19] <xreal> JEEB: From my POV, that's a bug of FFMPEG :)
[18:19] <JEEB> of course
[18:19] <JEEB> it is
[18:19] <xreal> kewl, I've found a real bug
[18:19] <JEEB> they just haven't decided how to deal with it yet
[18:20] <JEEB> and it's just kind of funny that if you use the libraries, and deal with the values given by it accordingly, you will get the correct result :)
[18:20] <JEEB> so the internals actually can handle it
[18:20] <JEEB> but not ffmpeg the command line app
[18:20] <JEEB> but yeah, in your case there's two layers
[18:21] <JEEB> 1) is the encoder delay written somewhere, and if it is - is it read? 2) when we get the encoder delay from the API, we have to now deal with it somehow in ffmpeg
[18:22] <xreal> JEEB: For MP3s encoded by LAME, it's easy and well documentated. But other MP3s could make trouble.
[18:22] <JEEB> yeah
[18:22] <JEEB> it's the same for AAC
[18:22] <JEEB> unless you have the encoder delay written somewhere
[18:22] <JEEB> you just can't make al ot of assumptions
[18:23] <JEEB> I thnk there's a code path for faac
[18:23] <xreal> JEEB: Actually, this might explain som things. I've decoded the AAC stream of a MP4 into WAV and there was a delay.
[18:23] <JEEB> and then that's it
[18:23] <xreal> JEEB: Does FFMPEG output the audio delay somehow?
[18:23] <JEEB> (faac leaves a "signature" and its encoder delay is known)
[18:23] <JEEB> xreal, as in, you want to check if it gets read?
[18:23] <JEEB> from the input
[18:23] <JEEB> not sure
[18:24] <xreal> JEEB: and the other way, when exporting to WAV.
[18:24] <xreal> "warning: 25 ms delay" or something
[18:24] <JEEB> well, we already know that ffmpeg will just blurp every decoded packet as-is to the WAV :P
[18:24] <JEEB> because wav doesn't support negative timestamps
[18:24] <xreal> JEEB: Yes, but with a known delay, I just could cut it.
[18:25] <xreal> JEEB: https://trac.ffmpeg.org/ticket/2325
[18:25] <xreal> :)
[18:26] <JEEB> yes, there probably is a nice amount of issues regarding encoder delay
[18:27] <xreal> JEEB: I don't even know, where to start when encoding a video in FFMPEG and audio in LAME cli ::(
[18:29] <JEEB> well, if you were the guy encoding stuff into AVI I think these are not exactly the biggest issues you'd be having
[18:30] <xreal> JEEB: I'd use AAC, but I don't trust FAAC.
[18:30] <JEEB> I was talking of a container, you brought up another audio format?
[18:30] <JEEB> your problems don't exactly change per audio format :D
[18:30] <xreal> Argh, let me expand my answer:
[18:31] <xreal> I'd use MP4 or MKV, but since my player doesn't support this, I'd need a new one. Since this would support AAC playback then, I wouldn't need MP3 anymore.
[18:32] <xreal> JEEB: Actually, I don't need MP3 to WAV using ffmpeg, but I just wondered, why I always get out of sync.
[18:32] <JEEB> anyways, just saying that the encoder delay in mp3 files is probably the smallest of delays you might have due to the ways things can work in AVI :P
[18:32] <xreal> JEEB: So switching to MP4/MKV would fix anything?
[18:32] <JEEB> not everything
[18:33] <JEEB> but at least you wouldn't get extra lulziness
[18:33] <JEEB> such as players handling b-frame delay and various hacks related to it differently
[18:33] <JEEB> and/or a player not liking your AVI output for whatever reason
[18:36] <xreal> JEEB: I'm confused now.
[18:39] <xreal> Unknown encoder 'libfdk_aac' ... d'oh
[18:41] <xreal> What's the GPL correct codec name
[18:41] <xreal> ?
[18:41] <JEEB> the best one in distributable builds, you mean?
[18:41] <JEEB> -c:a aac -strict experimental
[18:41] <JEEB> anyways, I'm off for a while
[18:41] <xreal> JEEB: Thanks for help.
[18:42] <xreal> rror: 2pass curve failed to converge ... narf
[18:54] <Jeroi> hello, can ffmpeg libraries open avc file?
[18:54] <Jeroi> I found one program that uses qt and ffmpeg to make meadia player, but the media player is unable to open avs files
[18:54] <Jeroi> I mean Avisynth files
[18:55] <Jeroi> I did read that ffmpeg has some kind of avisynth support directly to encode avs files
[18:55] <Jeroi> this should mean that ffmpeg lips are able to read avisynth files directly?
[19:54] <xreal> So, I should use CRF when using ffmpegs x264 encoder?
[19:55] <klaxa> see https://trac.ffmpeg.org/wiki/x264EncodingGuide
[19:55] <klaxa> in most cases yes
[19:56] <xreal> klaxa: isn't there a two pass crf? :)
[19:57] <klaxa> have you read the page?
[19:58] <xreal> klaxa: yep. I thought, Two-Pass doesn't use crf, but some kind of cbr/vbr
[19:58] <xreal> Sorry, I stopped ripping DVDs in 2006 and there was AutoGK with XviD :)
[19:59] <c_14> https://trac.ffmpeg.org/wiki/x264EncodingGuide#twopass
[19:59] <c_14> >This method is generally used if you are targeting a specific output file size and output quality from frame to frame is of less importance.
[20:00] <xreal> c_14: Yeah, I understand that. But I thought, there would be a second pass for CRF, too to increase the quality :)
[20:01] <c_14> Doing more than one pass doesn't increase the quality.
[20:01] <c_14> It just let's you determine the output filesize.
[20:02] <c_14> -'
[21:37] <brontosaurusrex> xreal, you should use crf (if you are not targeting specific size or average bitrate) and its single pass
[21:37] <xreal> brontosaurusrex: thanks
[22:43] <JDuke256> hello , whats h263 requires on compression ? yuv444 or yuv422 ?
[22:43] <JDuke256> or any other yuv type ?
[22:46] <klaxa> >Supported pixel formats: yuv420p
[22:46] <klaxa> you can find that out if you run: ffmpeg -help encoder=h263
[22:47] <JDuke256> i m writing code on C++
[22:47] <JDuke256> my problem is i dont know which format i need to use on Directshow to send h263 codec
[22:48] <JDuke256> i got MEDIASUBTYPE_YUY2
[22:54] <JEEB> directshow yuv420p is I420
[22:55] <JEEB> YV12 is the same, but with chroma channels swapped, so you'd have to give the pointers in another arrangement
[23:56] <xreal> JEEB: Is there an lossless audioformat, which supports delay? FLAC perhaps?
[23:56] <xreal> or OGG lossless?
[00:00] --- Tue Apr 22 2014