On Wed, 21 Jun 2006 11:19:57 +0200 Francesco Romani <[EMAIL PROTECTED]> wrote:
> On Tue, 20 Jun 2006 17:19:06 +0200 > Christian Bodenstedt <[EMAIL PROTECTED]> wrote: > > [...] > > Now that everything compiled well I ran a first test with: > > > > transcode -i test.mpg -c 0-100 -y x264,null,raw -o test.264 > > > > but it just created a 0 byte sized file. :-( Seems I should have a > > look at the source code now. > > Hi, I quickly (*really* quickly) hacked the attached patch. I did a quick test using the above command and the created file is equal to an encoding I made with the initial export_x264.c previously. Your patch seems to have the same effect like the changes I applied to my local copy. But my changes didn't take care about buffer sizes, so I didn't want to post a patch ;-) > At very first glance, it seems the problem is that there isn't a clean > way to known buffer sizes in audio/video frames, at least at encoding > step. You are talking about the buffer "outframe->video_buf" which is provided through the third parameter of "*encode_video(...)", aren't you? I was stumbling over "outframe", too (and I didn't manage to find any documentation on it). To go on I'll need some informations: - In which function will "outframe->video_buf" be allocated? - If it's already allocated when *encode_video() is entered: - what is its size? - How can I find out this size? - If it should be allocated into "*encode_video()": - where will it be free()ed? - where shall it's size be stored? - Where is the documentation on this topics? Bye for now, Christian Bodenstedt
