On Thu, 2009-06-04 at 09:40 +0200, Antonio Beamud Montero wrote: > Francesco Romani escribió: > > On Wed, 2009-06-03 at 15:06 +0200, Antonio Beamud Montero wrote: > > > >> It's posible to use a output fps value not included in the frc table? > >> I'm trying to use a 2 fps rate in my output file, but the filter always > >> uses the input fps rate, i.e something like this (input at 12fps): > >> > >> transcode -i input.avi -y xvid -J modfps --export_fps 2 -o output.avi > >> > >> ---- > >> [filter_modfps.so] converting from 12.0000fps to 12.0000fps > >> ---- > >> > >> but: > >> > >> transcode -i input.avi -y xvid -J modfps --export_fps 5 -o output.avi > >> > >> ----- > >> [filter_modfps.so] converting from 12.0000fps to 5.0000fps > >> ----- > >> > >> Do I need to modify the libtc/ratiocodes.c to add my fps value? > >> > > > > Don't think so. Please paste the full output produced by the above > > > > transcode -i in.avi -y xvid -J modfps --export_fps 2 -o out.avi -c 0-1 > > > > Bests, > > > That's the output: [...] OK, that (and a little more investigation) confirms my initial thought.
As you noticed, if an unknown fps value is specified for export, transcode tries to infer the frc code from that value. If this step fails, the frc value remains zero, so it is overwritten by input value. Finally, the export fps value is overwritten again by the value converted by the frc one. The root of the problem is the failure in finding the frc from the fps. I've mixed feelings about this situation. Leaving the frc inconsistent will lead to trouble because the frc code is considered authoritative with respect to the raw fps value. We must avoid that, so to ignore the conversion from fps to frc is unlikely the way to go. The issue you're facing looks like a corner (and uncommon) case to me, neverthless this is a clue for an real underlying problem, which is having data values hardcoded into the code. That's fine for the common values used the 95% (or more) of the time, but I feel uncomfortable with the idea that's needed to edit the code for cover corner cases like that. As first step toward the solution, I'll add a message to notice the user that the export frc was been overwritten by the import one, as you're experienced. The real fix is trickier, however. Probably the best solution is to allow the user to extend the frc/fps table at runtime using some kind of configuration file. I'll reply again as soon as I figure out a feasible solution. Bests, -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
