From: Roman S. <rvs@Sun.COM> - 2003-01-14 03:51:21
|
On Fri, Jan 10, 2003 at 02:07:33PM -0500, Dan Dennedy wrote: > On Mon, 2003-01-06 at 01:54, Roman Shaposhnick wrote: > > > Now, I would argue, that always setting 'aaux_as.pc4.ef' and 'aaux_as.pc4.tc' > > to 1 is safer than what libdv does right now and I'd say that the patch from > > attachment #1 is worth applying. > > I will apply the patch. Thanks! > > But the real question here is: may be > > we want our end user to decide all this ? So how about conveying values for > > some members of the aaux_as and aaux_asc to the _dv_raw_insert_audio() via > > its second argument 'audio' ? If there are some architectural or even > > I looked into this as a result of this email. I am not going to make any > of this configurable right now. The more I looked at how the interface > works, it begs a reorganization to add more options in a coherent way. > We are too close to a 1.0 release and keeping this API stable. > Therefore, since current encoding does not implement emphasis, we should > just set the flag correctly per your patch and not touch the interface. > The 1.0 release and interface should be sufficient for basic encoding, > meaning limited to 2 channel, 16bit, no emphasis. I agree 100% with you. Besides, we really need client code to make some use out of this potential configurability and that's not going to happen in quite some time. Thus, leaving it as is in 1.0 and working on in for the 1.1(?) would be the smartest thing. > Beyond the 1.0 release, I think we should try to address more audio > issues like 4 channel support, 12 bit encoding, apply emphasis, and > whatever else through a better interface. We may also wish to > collaborate more with FFMPEG for overall improved speed and quality. I would be interested in working on that. I have a preliminary patch which adds some flexibility to the interface and I would be more than happy to polish it and eventually include in libdv 1.1. By the way, is there a branch for such things ? Or is it too early to ask for that ? One more thing we need, is a library of DV samples ( 1-10 frames is enough ) captured by different camcorders using different settings. So if there's no problem with hosting them at SF, we can ask folks on this list to help us with that. How about that ? > > 3. 'aaux_as.pc1.af_size' is a tricky one and if there's somebody who > > can explain all ramifications of it being less than what was in > > original frame, I will be more that interested to listen. For > > now, I don't think I've noticed any difference. > > Do you mean why the particular hard-coded values subtracted from the > samplesperframe in _dv_raw_insert_audio()? Those are the minimum number > of samples per frame per the spec (assumption), and the af_size field > counts the amount over the minimum. No, it's not what bothers me. See below. > Otherwise, the general strategy, and which kino tries to employ, is that > if the dv frame is being updated, then we get the number of existing > samples and use it. Therefore, there should not be a loss of samples. On > the other hand, if the frame is being encoded from a blank, virgin DV > frame, then we use a locked audio sequence of samples per frame as > provided by dv_calculate_samples. That's the problem. I've done some checking and it turns out that libdv calculator doesn't seem to be in sync with the camcorder's DV encoder. The potential issue here is that when libdv calculator demands more samples than the camcorder, there is no way for you to do this: 1. Select a region of X frames. 2. Export audio from that region. 3. Generate X frames from scratch. 4. Use audio from step 2 to dub this frame sequence. you just won't have enough samples. On the other hand, it will also happen if X existing frames from one part of the video stream were to be dubed using audio extracted from the same number of frames located in a different spot of your footage. By the way, I don't know how commercial applications get away with such scenario, but I wouldn't be surprised if they were silently inserting additional samples where they need to. The ultimate question, of course, is why dv_calculate_samples works the way it does. Is this algorithm documented as a part of a DV spec, or is it just good enough ? If the later holds, it might be interesting to look into patterns of af_size generated by different camcorders. One more argument to have this library of DV samples I was talking about earlier. > I appreciate your analysis. What more can you tell about the af_size > problem? Thanks. I really don't have a lot of constructive things to say about this issue right now, but I will try to investigate this a little bit more. Thanks, Roman. |