Francesco Romani wrote:
On Sat, 2008-02-16 at 11:43 -0600, Carl Karsten wrote:
That's bad. I can understand your annoyance; unfortunately, transcode
v4l module is built around tv tuners/video capture cards (to be exact, I
have _two_ SAA713x cards and nothing else...), so it can work strangely
or no work at all if the v4l devices does not export the "expected"
interface.
I am pretty sure the problem is with the v4l driver. which is easy to say,
because it is 1/2 closed source. the tar has some .c and some .o - run make and
you get a kernel module. joy. I am going to press them to make it work with
transcode, so any API expectations you can offer would help. or maybe I can get
them to update transcode's import_v4l.c - any suggestions?
THe biggest problem is that I don't master the v4l2 specs as I should :(
If the producer whant to enhance the support, the best thing by far is
to patch import_v4l2.c; a patch against import_v4l.c will be appreciated
as well, even if it is less useful. Lastly, some hints to improve our
code bt ourselves will be appreciated as well.
hmm, looks like none of the people working on my VGA capture project is a v4l2
(or v4l) expert :) this is the first time i have ever thought of it. I will
try to recruit someone. If you know anyone who is also into Python, they may be
most willing to help (given the material will be Python presentations.)
If you could find some v4l2 spec links or something to direct them to, that
would be good.
[...]
An easy solution to my current problem would be to write a script that copies
frames to fill in the gaps so that there is one frame per second. but I would
rather hack the code and make it somehow use the file's timestamp.
That will be EXTREMELY welcome since it starts to address an historical
weakness of transcode (A/V synch troubles and madness with variable
frame rate).
Of course the idea is to properly handle all those issues in transcode
core and solve this problem once for all (...someday in the future...)
Given I don't really need it (yet) I don't have much interest in working on
anything but a proper long term fix. Is there currently a time index being
tracked?
No, we lack this. That's one of the biggest source of trobules. A proper
solution should of course introduce some kind of master time source.
sounds easy enough... :)
timeindex=0
timeindex+= frame_time
frame_time... where should that come from?
I can see passing i, fps, timeindex to the import module, and it can use what is
best to calculate frame_time.
I considered fpx*i (the frame index) in the controller loop, but that won't work
for variable fps.
which btw, I found out a bit about:
(11:28:20 AM) CarlFK: is there a codec that supports a variable fps?
(11:36:01 AM) Rathann: CarlFK: do codecs have a notion of fps?
(11:37:22 AM) CarlFK: Rathann I'm not exactly sure what the term is. file
format?
(11:37:36 AM) Rathann: we say container
(11:38:00 AM) CarlFK: ok, I can see container
(11:38:21 AM) Rathann: CarlFK: certainly nut, mkv and asf. I don't know about
mov.
Why is there both ptr->video_len and video_size ?
See comments in src/framebuffer.h (pasted here)
Can you add these two lines to the source?
Which ones? The quoted above?
yes. just something that reference why there are 2. most everything else
seemed self explanatory.
Sorry for pretty long answer and sorry again for being late answering;
for any other/further question, please do not hesitate to reply.
No need to apologize. It is very useful.
Glad to hear that. If you want to go ahead, wou will be VERY welcome on
transcode-dev. Please remember to provide patches against HEAD; working
on 1.1.0 is accepted as well, but new code should always go against
HEAD.
will do.
Carl K
