Francesco Romani wrote:
On Fri, 2008-02-15 at 23:05 -0600, Carl Karsten wrote:
Hi, sorry for being late.
[...]
I was at an hour long presentation with my VGA2USBLR gizmo hooked up to the
projector. I gave up trying to use the v4l interface
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?
I've planned some initial fixes for this, for example introducing some
fallbacks for some IOCTL calls, but nothing was done yet due to
chronical lack of time :(
understood. everything you are doing is appreciated.
btw, the presentation was:
Paul Smith - mapping solution from scratch with Mapnik, Django, and OpenLayers.
so almost topical :)
And quite interesting :)
I'll be sure to post the final product. although I have 100% of the vga, I only
have audio for the last 50%. (I tried to use my laptop mic, you can hear the
laptop's fan/HD wine, and if you listen really hard you can hear that someone is
talking, but i doubt anyone will be able to hear what he is saying. The video
camera showed up late, and once it was running it captured good sound.
I have an audio track. I want to make a video track. Not sure what format to
use. Size is secondary to quality. Huge is fine, as long as it is needed. I
am expecting a few gig per hour.
Any lossy codec with sanely-sized bitrate should be fine, since I'll
expect very static images with few differences, so the encoder will be
very happy and will delivery a fine job (hopefully!).
So far so good. fps/size is a problem, guessing I need to set some codec
parameters.
I have used transcode -i image_list.txt -x imlist - but here is the problem:
the images were not evenly across time. looking at the times, there are groups
of "quick" (1 second per frame) and groups of "slow" (3 seconds per frame.) (I
am guessing image complexity had something to do with it.) So applying a
constant fps means it will easily drift by 5 or 10 seconds. thus my quest to
get imlist to respect file timestamps.
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?
I have some questions about the code below.
Does MARK_TIME_RANGE set anything? (MARK made me think it did.)
Given a stream of A/V frames (so it is really a pair of two streams, but
let's start simpler), the -c options allow to select only some frame
ranges to be encoded. Like this: (use a fixed font to see this `figure')
(F = 1 frame)
-> FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
[ - range 1 - ] [ - range 2 - ]
[out_of_range][___in_range__][__out_of_range__][__in_range___][out
Everything after the decoder, so filters and encoder itself, will skip
all out_of_range frames to save processing time.
#define MARK_TIME_RANGE(PTR, VOB) do { \
/* Set skip attribute based on -c */ \
if (fc_time_contains((VOB)->ttime, (PTR)->id)) \
(PTR)->attributes &= ~TC_FRAME_IS_OUT_OF_RANGE; \
else \
(PTR)->attributes |= TC_FRAME_IS_OUT_OF_RANGE; \
} while (0)
the fc_time_contains() function checks if a given frame, identified by
it's id, is in any processing range or not.
Finally, the TC_FRAME_IS_OUT_OF_RANGE frame marks the frames that do NOT
belongs to such processing range, so frame that must be ignored by any
further processing stage.
OK. I haven't figured out how tc keeps track of time, wanted to make sure that
didn't have anything to do with it.
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? I concluded it was because some
filters used len and some used size, and no one had gotten around to making them
all the same.
How does anything's timing work? I thought there was something that would keep
the audio and video streams synced, but I don't see how.
transcode synchronization code is, to be VERY kind, either optimistic
(for non-VOB world) or very messy and poor (for VOB world). And
somethimes it is both.
I'll describe briefly and from a VERY HIGH point of view (in order to
hide the scary detauls).
- for VOB/MPEG stuff, the synchronization code is (mostly) in
import/tcdemux sources. Keep away if you can.
This code is very low-level and mpeg specific and tries to handle the
task by messying at stream-level. To make long (and painful) story
short: keep away. We (transcode-dev) should really nuke all this chaos
and rewrite the whole thing from the ground up because now it is pretty
unpredictable and unreliable.
- for anything else, but with the implicit assertion that this `else' is
something AVI-like, the synchronization is handled with
TC_FRAME_IS_SKIPPED and TC_FRAME_IS_CLONED flags.
Maybe you can find some interesting sample code in
import/v4l/import_v4l2.c
+++
A short term, band-aid like but still VERY useful and welcome task would
be provide a thin, generic synchronization layer that attempts to
normalize synchronization issues using the above two flags and frame
timestamps. This is not of course the definitive solution but it is
still a very important first step.
If you want to try this way, you will have all support that I can
provide (this offer is of course valid for anything else listening).
Other way, I'll add this task on top of my todo-list for 1.2.0.
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.
Carl K
