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

[burek]

[11:39] <l0p3n> Hey! How can I convert a wav to aiff?
[11:40] <juanmabc> what gives the ingenuous $ ffmpeg -i filein.wav fileout.aiff ?
[11:43] <l0p3n> juanmabc: Oh it was that easy. Thanks!
[11:44] <juanmabc> welcome to transcoding
[11:47] <Leoneof> it's possible to cut some scenes by using ffmpeg?
[11:48] <Leoneof> for example, i have movie 5min, and i don't want a scene that starts from 1:00 to 1:05
[11:54] <Mavrik> Leoneof: yeah
[11:54] <Mavrik> check "-ss" and "-t" parameters
[11:54] <Mavrik> with -codec: copy
[12:19] <Leoneof> Mavrik: i can't figure out :|
[12:22] <Mavrik> um.
[12:28] <Leoneof> Mavrik: here is my tries: ffmpeg -sameq -ss 00:10 -t 5:00 -i old.mp4 new.mp4
[12:30] <klaxa> Leoneof: is it h264? (also you forgot -codec: copy) if it's h264 you cannot easily cut between keyframes (you have to start cutting off at a keyframe)
[12:31] <Leoneof> what does this mean? Unrecognized option 'codec:'
[12:32] <Leoneof> klaxa: it's H.264 / AVC
[12:33] <klaxa> try replacing -codec: copy with -vcodec copy -acodec copy
[12:33] <klaxa> also if you want a scene from 1:00 to 1:05 (i'll assume it's 5 minutes) use -ss 1:00:00 -t 300
[12:34] <Leoneof> klaxa: i want all duration, except 1:00 to 1:05
[12:34] <klaxa> ah
[12:35] <klaxa> then you need to run it twice, also merge it afterwards
[12:35] <klaxa> you could do that with mkvmerge, that would change the container though
[12:37] <Leoneof> klaxa: good, can ffmpeg merge two mp4 ?
[12:37] <Leoneof> instead of mkvmerg
[12:37] <Leoneof> mkvmerge*
[12:37] <klaxa> i don't think so...
[12:39] <klaxa> i think you could remux the resulting mkv to mp4 though... not so sure about that either though
[12:40] <Leoneof> ok, thank you
[12:41] <Leoneof> i've to get some snooze :)
[12:41] <klaxa> :)
[13:36] <tuxx_> hey guys...
[13:37] <tuxx_> i need to encode a video in realtime
[13:37] <tuxx_> and store it on a FAT32 medium... i use avio_open, avio_close for the file handling...
[13:38] <tuxx_> is there some way to assess the size of the file?
[13:40] <klaxa> tuxx_: http://stackoverflow.com/questions/238603/how-can-i-get-a-files-size-in-c does that help?
[13:47] <tuxx_> klaxa: i know how to use fstat :)
[13:47] <tuxx_> but with avio_open/avio_close
[13:47] <tuxx_> i dont have the filedescriptor
[13:47] <tuxx_> or at least i dont see where.. must be buried in the struct somewhere
[13:47] <klaxa> hmm...
[13:47] <tuxx_> im reading the code of libavcodec
[13:47] <tuxx_> to see where it stores the fd
[13:48] <tuxx_> but anyway i stumbled over this:
[13:48] <tuxx_> int64_t avio_size (AVIOContext *s)
[13:48] <tuxx_> that seems to be what i need
[13:49] <tuxx_> i guess...
[14:19] <tuxx_> hey guys.. i've managed to open a new file for the encoded data upon reaching the 4GB limit
[14:20] <tuxx_> however the new file starts with p frame data only.. how can i force the first frame to be an iframe?
[14:34] <snagnever> hey! i have a converting question... im developing a web system that might have video converting feature. i would like to know which would be the best way to work with batch converting and which server would be the best deal for that. thx ;]]
[14:38] <ubitux> what do you mean by "server"?
[14:39] <ubitux> batch converting can be done in multiple ways depending on your needs&
[14:39] <snagnever> right, sorry, the hosting service... like amazon ec2, for instance
[14:39] <ubitux> you can use a shell script, a classic queue system in python, a huge performance monster in Go, etc etc etc
[14:42] <snagnever> well, i have two scenarios: ONE that i will receive a video with all settings according to what i want (codecs, bitrate and stuff) but i'll generate a "lower quality" (with lower bitrate) for slow connections
[14:42] <snagnever> the other scenario is when i would receive any kind of video and would have to convert to h264, aac, 720p
[14:43] <klaxa> if you have computation power bursts amazon ec2 isn't a bad option
[14:43] <klaxa> if you constantly get videos and reencode all the time a root server might be better suited money-wise
[14:45] <snagnever> klaxa, like in scenario ONE the EC2 would be cool; but in scenario TWO would be better to get some other VPS/dedicated
[14:45] <snagnever> ?
[14:45] <klaxa> no it soley depends on how many videos per time you have to reencode
[14:45] <klaxa> if you get let's say 1 video per week, ec2 is more economic
[14:46] <klaxa> if you get 9001 videos per hour a root server will be suited better
[14:46] <tuxx_> hey guys.. do iframes always occur at a fixed rate?
[14:46] <tuxx_> i.e. every tenth frame is an iframe
[14:46] <tuxx_> or can i force an iframe in between
[14:46] <hp566tg> I need a code line for converting videos to work on my iPod 160G Classic.  Anybody have one?
[14:47] <klaxa> tuxx_: i think in h264 there is a maximum number of frames between i-frames, at scene-changes there is often an i-frame inserted to reduce errors i guess?
[14:47] <klaxa> i think from the spec you could add i-frames everywhere since they store whole frames
[14:48] <klaxa> i'm by no means qualified to make any statement though
[14:48] <snagnever> klaxa humn i see... well, we'll get a considerable amount of videos a day
[14:49] <tuxx_> klaxa: i see. thanks
[14:49] <klaxa> again about the server things, i'm by no means an expert, what i state is merely the result of my logic :P
[14:49] <tuxx_> divVerent: hey mate are you there?
[14:49] <JEEB> ec2 and stuff is pretty agressive on pricing, and encoding does use cpu "nicely", also the cpu power of such instances generally isn't too fast
[14:50] <JEEB> generally I wouldn't try to bring in ec2 unless you really, really have the need for that
[14:50] <JEEB> (and even then it would be automated up/down process for single videos or small packs of them)
[14:50] <klaxa> which would reduce pricing right?
[14:52] <JEEB> I know certain companies do use ec2 for encoding but those usually have very specific needs and have it set very specifically to minimize costs. Otherwise using ec2 and friends for encoding makes generally no sense
[14:53] <snagnever> jeeb klaxa i see... yeah, i was concerned about pricing...
[14:53] <snagnever> i really consider using the S3 for storing the videos
[14:53] <snagnever> but i have to find some place to encode them
[14:54] <snagnever> jeeb can you suggest me?
[14:54] <JEEB> I'd probably grab a nice dedi or even buy a server and colo it at ovh/kimsufi or hetzner if I was on a budget
[15:09] <snagnever> JEEB thank man, i´ll take a look
[15:10] <tuxx_> JEEB:mouth shutting time!
[15:11] <snagnever> JEEB but how about the traffic? i've never hired a dedi or bought a server :P how does it usually work?
[15:12] <klaxa> you usually have a certain amount of badwidth for which you get the full advertised speed, in most cases your connection speed gets limited (in many cases to 10 mbit/s) once you exceed your bandwidth for the month
[15:12] <JEEB> yup
[15:12] <JEEB> the stuff's usually written down on the site :P
[15:12] <klaxa> that depends on the hoster however
[15:13] <klaxa> yeah
[15:13] <JEEB> also generally I trust companies that outrights say their limits more than those that say they have "unlimited" bandwidth
[15:13] <JEEB> *outright
[15:14] <klaxa> unlimited* \footnote *unlimited means limited
[15:14] <snagnever> humn right, good to know
[15:14] <snagnever> thanks again guys
[15:58] <jonwil> does ffmpeg encode VP6?
[15:59] <JEEB> jonwil, nope
[16:00] <jonwil> ok, I found references suggesting it did (or that someone was working on it at least)
[16:26] <jonwil> aha, it was an SoC project
[16:37] <xroberx> Hi, I'm getting this error in Android when trying to avformat_open_input an image sequence: [image2 @ 0x1e25b0] Could find no file with with path '/mnt/sdcard/Android/data/com.test.player/files/m%04d.jpg' and index in the range 0-4
[16:38] <xroberx> In /mnt/sdcard/Android/data/com.test.player/files/ there are a bunch of files like m0001.jpg, m0002.jpg, m000n.jpg
[16:38] <xroberx> The exact same code runs fine on Linux
[16:39] <xroberx> Any idea why is this happening ?
[16:39] <bizulk> hi. can wirh define UYVY with the AVColoSpace enum.I unable to which value UYVY can correspond.
[16:39] <JEEB> xroberx, can you look how ffmpeg handles such things? It could be that it's expecting the system's shell or whatever handle it, while Android really doesn't have much of a shell in there
[16:39] <JEEB> as in, see how avformat_open_input and whatever is behind it does it
[16:40] <xroberx> JEEB: I know that the glob pattern requires some help by the system, but I read the documentation of image2 demuxer and the %nd formats is built-in
[16:40] <JEEB> you should really check it in there :P
[16:40] <JEEB> as in, not the documentation but the code
[16:41] <xroberx> let me see
[16:41] <JEEB> because in any case leads for the problem will be appearing there
[16:43] <divVerent> xroberx: two things to check
[16:43] <bizulk> ok. Nothing to do with it. It is about pixel format
[16:44] <divVerent> xroberx: first, by the error we know that find_image_range returned -1
[16:45] <divVerent> xroberx: so none of the file names m0000.jpg, m0001.jpg, m0002.jpg and m0003.jpg did not exist
[16:45] <xroberx> that's not possible, the files really exist in the file system and with readable permissions
[16:45] <divVerent> basically, we know that avio_check("/mnt/sdcard/Android/data/com.test.player/files/m0001.jpg", AVIO_FLAG_READ) failed
[16:45] <xroberx> in the same directory I have a video and the video is opened succesfully
[16:45] <divVerent> OR the file name building failed and e.g. %04d may not work right on android
[16:45] <divVerent> I see these two possibilities
[16:47] <divVerent> avio_check eventually hits file_check then stat()
[16:47] <divVerent> so maybe stat()'s st_mode flag behaves weird? wouldn't suppose that
[16:47] <divVerent> but the check there is actually wrong, it checks if the owner can read, and NOT if the current user can ;)
[16:48] <divVerent> as for the file name building, can you run it in strace -fe open?
[16:48] <divVerent> actually
[16:48] <divVerent> as for the file name building, can you run it in strace -fe open,stat,access?
[16:49] Action: jonwil wonders how hard it would be to write a VP6 encoder...
[16:49] <divVerent> http://elinux.org/Android_Debugging#strace as for strace
[16:49] <xroberx> divVerent: avformat_open_input() returns ENOENT (-2) which is "No such file or directory"
[16:49] <divVerent> xroberx: that alone doesn't tell much
[16:49] <divVerent> we need to check what it actually did
[16:51] <xroberx> divVerent: but the thing is that if I pass "m0001.jpg" instead of "m%04d.jpg" to avformat_open_input(), I get the exact same error: [image2 @ 0x1df850] Could find no file with with path '/mnt/sdcard/Android/data/com.test.player/files/m0001.jpg' and index in the range 0-4
[16:51] <xroberx> this latter code works fine on Linux
[16:51] <divVerent> we still have two possibilities to blame
[16:51] <divVerent> either the file existence/access check
[16:51] <divVerent> or the file name building
[16:52] <xroberx> divVerent: you said that stat() checks if the owner can read ????
[16:52] <xroberx> no wonder it doesn't work
[16:52] <divVerent> huh?
[16:52] <divVerent> what are the file permissions?
[16:52] <divVerent> this would happen if you set ---rwxrwx
[16:53] <xroberx> ----rwxr-x system   sdcard_rw
[16:53] <divVerent> wtf, really?
[16:53] <divVerent> still, it checks the file itself, not the directories above it
[16:53] <xroberx> yeah, and they are the same in both the emulator and a real device :S
[16:54] <divVerent> can you also paste the output of "mount" regading the sdcard?
[16:55] <divVerent> the odd thing here is, ffmpeg makes an assumption that's USUALLY right
[16:55] <divVerent> namely, that the owner of a file is the one with most rights on it
[16:55] <divVerent> this NORMALLY is the case, as the owner could chnage the permissions anyway, so there is little point in restricting him
[16:55] <xroberx>  /dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
[16:55] <divVerent> but yes
[16:55] <divVerent> with this fmask and dmask...
[16:56] <divVerent> in case of a mount, it actually SOMEWHAT makes sense
[16:56] <divVerent> the uid 1000 is totally banned from accessing it
[16:56] <xroberx> I get your point about the owner, but the "others" permissions is set to r-x which should be enough to actually read the file
[16:56] <divVerent> if it were regular file perms, it'd be stupid as the owner can just chmod it
[16:56] <divVerent> no, no
[16:56] <divVerent> the issue is elsewhere
[16:57] <divVerent> it shouldn't be using stat() to begin with
[16:57] <divVerent> access() is the function to use here
[16:57] <divVerent> I can make a file with permissions 000 and still read it
[16:57] <divVerent> e.g. if I am root
[16:57] <divVerent> or if there is an ACL giving me permission
[17:04] <xroberx> divVerent: that check is not done for videos ?
[17:04] <divVerent> yes
[17:04] <xroberx> :S
[17:04] <xroberx> but as I said videos load fine
[17:04] <xroberx> with the same permissions
[17:05] <divVerent> yes
[17:05] <divVerent> these don't do that check
[17:05] <divVerent> can you try replacing the file_check fucntion by this:
[17:06] <divVerent> https://gist.github.com/4046518
[17:06] <divVerent> oops, it has a bug
[17:06] <divVerent> https://gist.github.com/4046520
[17:06] <divVerent> this is better
[17:06] <divVerent> this is to be put into libavformat/file.c
[17:07] <xroberx> ok, let me recompile everything...
[17:07] <divVerent> too bad access() is somewhat broken on windows
[17:07] <divVerent> so this can't be used as is
[17:08] <divVerent> but if it works for you, I'd like you to create a ticket on the ffmpeg bug tracker with mentioning that this code fixes the issue for you
[17:08] <divVerent> so the ffmpeg devs can build a "real" fix based on it
[17:11] <Eitsew> hey folks, question
[17:11] <Eitsew> I'm stumped what this means:
[17:12] <Eitsew> Stream #0:0, 0, 1/90000: Audio: pcm_f32le ([3][0][0][0] / 0x0003), 44100 Hz, stereo, 2822 kb/s
[17:12] <Eitsew> the [3][0][0][0] bit, I mean
[17:12] <Eitsew> is that channels by any chance?
[17:12] <divVerent> that's the "fourcc"
[17:12] <divVerent> you can ignore it
[17:12] <divVerent> the internal format number
[17:12] <Eitsew> oh? well that was a red herring
[17:13] <divVerent> basically, floating point 32bit little endian has the number 3 in ffmpeg
[17:13] <Eitsew> in that case, how on earth do I convert wave to mp3?
[17:13] <divVerent> the channel count is mentioned here though
[17:13] <divVerent> "stereo"
[17:13] <tuxx_> divVerent: jo!
[17:13] <divVerent> I have to go soon, sorry
[17:13] <Eitsew> oh, okay
[17:13] <tuxx_> divVerent: oh no! :)
[17:14] <Eitsew> thought mp3 supported stereo?
[17:14] <divVerent> sure does
[17:14] <divVerent> where is your problem with converting to mp3?
[17:14] <Eitsew> [mp3 @ 0x20d6bc0] Invalid audio stream. Exactly one MP3 audio stream is required.
[17:15] <Eitsew> ... wait, do I need to force lame to be the encoder?
[17:15] <tuxx_> divVerent: i have a question.. i am doing that vnc realtime encoding and need to split files at 4GB.. i alread found avio_size to findout the size of my file... at > 4GB i wld then like to close it and open a new file and continue writing in there..
[17:15] <Eitsew> even if the file is whatever.mp3
[17:15] <divVerent> Eitsew: no idea what you are doing here
[17:15] <divVerent> does your input file maybe have multiple audio streams?
[17:15] <Eitsew> no, it only has one
[17:15] <tuxx_> divVerent: that seems to work perfect, however I dont get an i-frame so that in the beginning i only see the relevant changes.. is there a way i can force the encoder to give me an i-frame?
[17:16] <divVerent> tuxx_: no, you can't
[17:16] <tuxx_> divVerent: oh no :(
[17:16] <divVerent> or rather... you can
[17:16] <divVerent> by totally stopping an restarting the codec context too
[17:16] <tuxx_> divVerent: i'd have to close the encoder, and restart it?
[17:16] <divVerent> yes
[17:16] <tuxx_> damn
[17:16] <divVerent> you have to anyway, if you also make a new format context
[17:16] <divVerent> re-owning a codec context may or may not work, usually does not
[17:16] <tuxx_> divVerent: alright then :( so be it.
[17:16] <divVerent> I amn actually amazed it worked THAT well for you :P
[17:17] <tuxx_> divVerent: hehe yea.. i can see the click ticking in the corner
[17:17] <tuxx_> but nothing else :)
[17:17] <xroberx> divVerent: Thank you very much for your help, I got it finally working with your fix
[17:17] <tuxx_> everything else is black :)
[17:17] <tuxx_> xroberx: yea.. divVerent rules
[17:18] <Eitsew> folks, this is my command line input and result: http://ss.westie.sh/UOy2
[17:18] <Eitsew> no, it's not a screenshot, it's an inline text file
[17:18] <xroberx> divVerent: could you please submit that patch upstream or tell me how to do it ?
[17:18] <divVerent> xroberx: you should do it, because you may get further stuff to test
[17:18] <divVerent> https://ffmpeg.org/trac/ffmpeg/
[17:18] <divVerent> this is the tracker
[17:18] <divVerent> as bug title, I suggest to mention that it can be reproduced on Linux too
[17:19] <divVerent> by e.g. having root own the file, and chmodding it to 0055
[17:19] <divVerent> "----r-xr-x"
[17:19] <divVerent> because then everyone can test it, not just android users
[17:19] <xroberx> yeah, in fact Android is just a layer on top of Linux
[17:20] <divVerent> so, maybe "image2: cannot open files not readable by owner"
[17:20] <Eitsew> did anyone manage to view that file? :)
[17:20] <divVerent> Eitsew: get rid of -c copy
[17:21] <divVerent> with the command the way you wrote it, you tried to force pcm audio into a mp3 container
[17:21] <divVerent> that's not gonna work
[17:21] <Eitsew> ah ha, yes
[17:21] <Eitsew> that's better
[17:21] <Eitsew> thanks!
[17:22] <divVerent> np
[17:22] <xroberx> divVerent: I cannot thank you enough for your help, I was struggling to get this working for a couple of days, thank you and see you soon
[17:22] <xroberx> goodbye guys
[17:22] <divVerent> cu now
[17:31] <beastd> Eitsew: copy tells to not re-encode the stream (e.g. in your case you told to stuff the original PCM audio stream from the input WAV into the output MP3 file; fortunately lavf refused to do so)
[17:42] <Eitsew> ah, thank you beastd!
[17:42] <Eitsew> sorry for the lack of acknowledgement, I cba to set up screen to actually chime me :P
[17:44] <beastd> Eitsew: np. just trying to help you to understand why it did not work.
[17:52] <Eitsew> beastd, it was part of my attempt to strip id3 data
[17:52] <Eitsew> s/i3d/meta/;
[17:52] <Eitsew> s/id3/meta/;
[17:52] <Eitsew> rather
[17:52] <Eitsew> :P
[17:54] <beastd> :)
[18:26] <mkaito> I'm having issues recording from x11grab. Apparently, I'm dropping frames rather randomly, which causes the audio to go out of sync. Any ideas what I should be looking at?
[19:03] <klaxa> mkaito: cpu-load and I/O
[19:04] <klaxa> mkaito: if you have a lot of ram or a fast I/O device try recording to that
[19:04] <klaxa> i had a similar issue, recording to /tmp/ solved the issue for me
[19:04] <mkaito> tmp doesn't hold enough for me
[19:04] <mkaito> but I'm recording to a dedicated sata3 drive
[19:05] <mkaito> but yeah, it might just be the cpu
[19:05] <klaxa> what codec are you using?
[19:05] <klaxa> you probably should try using a less complex one
[19:06] <mkaito> ffv1
[19:06] <mkaito> tried huffyuv and x264 at ultrafast
[19:06] <mkaito> same deal
[19:07] <klaxa> ffv1, huffyuv and x264 are rather complex, but lossless
[19:08] <klaxa> storing raw frames is out of question anyways...
[19:08] <mkaito> I'm open to ideas :)
[19:08] <mkaito> I'm reencoding afterwards anyway
[19:09] <klaxa> if your I/O is fast enough, did you try raw yuv?
[19:10] <klaxa> since it's x11grab i guess you want the recording to be as lossless as possible
[19:10] <lemonzest> yeah mount /tmp as tmpfs and record into ram :D
[19:10] <klaxa> another problem tied to this is color space conversion
[19:10] <lemonzest> just make sure you copy the file, or it will vanish when power goes
[19:11] <klaxa> another option may be utvideo (cue: JEEB)
[19:11] <mkaito> lemonzest: my recordings are 80-100Gb on average. Send me some ram, brah.
[19:11] <lemonzest> ouch
[19:12] <klaxa> if you made a pipe in ram big enough it might work :P
[19:12] <mkaito> at some point you have to empty ram as fast as it fills
[19:12] <mkaito> so it's the same deal
[19:12] <mkaito> I could just pipe rawvideo... but I really don't think the drive is fast enough
[19:13] <klaxa> not exactly if you have I/O bursts
[19:13] <klaxa> which isn't very uncommon with new video codecs
[19:13] <mkaito> is there a list of codecs with some description on complexity that I can check?
[19:13] <mkaito> I might just try them one by one
[19:13] <klaxa> ffmpeg -codecs ?
[19:14] <klaxa> are you sure it's your cpu? did you run htop or something at the same time?
[19:14] <mkaito> well
[19:14] <mkaito> I'm recording myself playing a video game
[19:14] <klaxa> ah well...
[19:14] <mkaito> all cores hover at around 80% while playing and recording
[19:14] <mkaito> 60-80%
[19:14] <klaxa> hmm...
[19:15] <klaxa> i'm not sure, but binding the game threads to one set of the cpu and the ffmpeg threads to the other set of the cpu might increase performance
[19:15] <klaxa> i'm no expert on multi-threading by any means though
[19:15] <mkaito> that might work
[19:15] <klaxa> just a wild guess
[19:16] <mkaito> if that doesn't work, it should be the drive speed
[19:16] <mkaito> I'll keep fiddling with settings and see how that goes
[19:16] <mkaito> :)
[19:16] <klaxa> otherwise try reducing resolution, 720p instead of 1080p is fine :P
[19:17] <mkaito> I would have to scale it on the fly
[19:17] <mkaito> isn't that expensive?
[19:17] <klaxa> i meant reduce resolution of the game, but hmm... interesting point
[19:18] <klaxa> play around with -vf scale and see if that kills the performan-- no that doesn't make sense after all
[19:18] <lemonzest> raid some SSD's
[19:18] <lemonzest> and in ssd terms, bigger is usually faster (more channels)
[19:18] <mkaito> too expensive for me
[19:19] <klaxa> raid 0!
[19:19] <klaxa> ah and yeah using -vf scale would only decrease performance since ffmpeg still gets the same resolution from the x11grab device
[19:21] <mkaito> I *guess* I could set the game to 720p
[19:21] <mkaito> but I'd like to exhaust other options first :P
[19:25] <mkaito> running the game itself is a little brittle, and changing the resolution entails quite some fiddling. I'll still play the game at 1080 while not recording... so I'd like to avoid it if at all possible.
[19:25] <klaxa> did you try reducing the nice value of ffmpeg?
[19:35] <mkaito> klaxa: nope, haven't done that. it starts at 15, maybe I should lower it
[19:38] <klaxa> okay i'mma get going, i've been at university for over 10 hours
[19:38] <klaxa> args wrong channel, lol
[19:43] <mkaito> o/
[20:46] <stephanedev> hi everyone.i am using the ffmpeg API to stream a video over rtp and i am having some issues like freezing and latency
[20:47] <stephanedev> this video stream is created using the ffmpeg API from images generated live
[20:49] <stephanedev> i set the frequency in the codec context to 20 fps
[20:51] <stephanedev> for every frame i encode, i check how much time the encoding takes and then wait for (1000/20 ms - encoding_time) before getting the next frame and encoding it
[20:52] <stephanedev> however it seems the process of encoding + writing to the socket sometimes takes longer than the period between 2 frames (here 50ms)
[20:54] <stephanedev> is there a way i can take that delay into account in the packet pts?
[20:55] <stephanedev> right now i just do: packet.pts = av_rescale_q(codecCtx.coded_frame->pts, codecCtx.time_base, m_formatCtx->streams[0]->time_base);
[21:04] <stephanedev> does anyone have experience in using the ffmpeg API to stream over rtp images that are generated live?
[21:43] <stephanedev> sorry if this question sounds silly, but is it ok to increment the AVFrame pts by more than one between 2 calls to avcodec_encode_video2?
[21:49] <stephanedev> of course not between every 2 calls (otherwise i would just change the codec context time base), but just when my encoding process didn't have time to encode one frame
[21:52] <Mavrik> stephanedev: which output codec?
[21:53] <stephanedev> Mavrik: thank you for answering. output codec is vp8
[21:53] <Mavrik> afaik VP8 as H.264 doesn't expect constant framerate so it's ok
[21:54] <stephanedev> i guess from your answer that some codecs do expect it, so maybe my approach is wrong
[21:57] <stephanedev> if for some reason my encoding process is unable to encode fast enough for a limited amount of time, how can it take into account the missing frames in the generated stream?
[00:00] --- Sat Nov 10 2012