On Wed, Sep 12, 2012 at 07:24:15PM -0500, Bruce Dubbs wrote: > Armin K. wrote: > > Dana 11.9.2012 18:42, [email protected] je napisao: > >> Author: ken > >> Date: 2012-09-11 10:42:11 -0600 (Tue, 11 Sep 2012) > >> New Revision: 10651 > > > >> @@ -79,6 +79,12 @@ > >> <para> > >> Required patch: > >> <ulink > >> url="&patch-root;/transcode-&transcode-version;-ffmpeg-1.patch"/> > >> + : Note that although this allows > >> <application>transcode</application> > >> + to compile with current <application>ffmpeg</application>, it > >> fails if > >> + it calls ffmpeg at runtime, e.g. for certain format > >> conversions. The > >> + remaining parts of the application, such as <command>tccat</command>, > >> + work and <command>ffmpeg</command> can be invoked outside of > >> + <command>transcode</command> if needed. > >> </para> > > > > I think this could go into seperate <note> </note> section below the > > Additional Downloads since it is not really "a download". What do you say? >
The reply I was going to make to Armin, before I saw this response from Bruce : Yes, it would probably be better as a note. I've had this hanging around from my 7.2 issues, and finally used it enough to say that it does work adequately - in some circumstances. > That's reasonable, but I'm not sure what it is saying. How does it > fail? Seg fault? Error message? Hang? What format conversions? > on stderr (I guess) - transcode: symbol lookup error: /usr/lib/transcode/export_ffmpeg.so: undefined symbol: avcodec_thread_init followed by the normal messages from libdvdcss, and then it processes the input file (which takes a long time even if it works) but writes nothing (except what I guess is a header) to the output - I killed it rather than waiting to see if it would complete. That was for h264 which my build of ffmpeg clains to support for both encoding and decoding. From my notes, it also failed with -y dv and -y dvraw : one of those worked some time in the past year (gave a *huge* output file!) with a similar set of configure options to transcode. Of the formats I use, extracting audio (only) to wav works fine. > I think the comment is more than a note. Perhaps a caution would be > better and rewording is certainly needed. > > -- Bruce I'd forgotten we had a caution construct, but this isn't something that will swallow the user's data (you still have the input file), so I'm not convinced that a stronger warning is needed. I tried to be terse because (a) this is just a comment on the effects of the patch, and (b) some jurisdictions may suggest this sort of usage is not OK. I can try rewording it, but I'm not willing to try multiple transcodes to available formats to see which fail (and anyway, some of them might need libraries I don't use). The example is accurate, although not particularly detailed. Usually I write too verbosely, and then often trim that before the commit. Here, I'm open to suggestions, but I don't really see how to enhance the text of the note ? For me, the most important part of this package is tccat, which works. After that, ffmpeg can be invoked from the command line to process the vob file to something usable. Perhaps I should mention that google is mostly unhelpful here - 99% of the results are for transcoding in general, and the 1% (a link to the transcode list) indicated that nothing much seemed to be happening there. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
