Hi,
On Mon, Sep 6, 2010 at 9:19 PM, Oskar Welzl <li...@welzl.info> wrote: > Hi Marco, > > I didn't see the mailing list in the headers of your mail, so I keep the > private as long as you do. If this wasn't your intention, feel free to > cc the list again. ;) > sure it was an error. The fine "Reply" button in google mail ;). Added back the ML to the loop with my apologies. > > > Am Montag, den 06.09.2010, 11:30 +0300 schrieb Marco Ballesio: > > transcoding with GStreamer is a tricky art, that's why we have gnonlin > > - but not in Fremantle ;) -. I suggest you to check, first of all, on > > this guide: > > > > http://gentrans.sourceforge.net/docs/head/manual/html/index.html > > > > Thanks; great material! > (Gnonlin, btw, is available for Fremantle in extras-testing.) > > > are you able to transcode using a similar pipeline on a pc (and > > qtmux)? > > I found a way to get things working meanwhile on the N900 (at the > bottom of this mail), using two components from gstreamer0.10-ffmpeg. - > I'm *not* happy though, as I don't like to create dependencies; also, I > assume that the muxers/encoders that come with Fremantle make better use > of the hardware and are faster. (Dont know...) > > What I don't understand is that only a combination of three things > (filesrc+nokiaamrnbenc+hantromp4mux) doesn't work. Replacing the real > files with some kind of test input/output produces good results. Like: > > audiotestsrc ! nokiaamrnbenc ! hantromp4mux >> works > filesrc ! nokiaamrnbenc ! nokiaamrnbdec ! pulsesink >> works > filesrc ! nokiaamrnbenc ! hantromp4mux >> doesn't work > > In order to avoid combining these three into one pipe, I split the work > into two gst-launch lines. One processes the audio and stores it to the > file system. This needs to be done using ffmux_amr, thus introducing the > dependency on gstreamer0.10-ffmpeg: > > $ gst-launch-0.10 \ > filesrc location="infile.mp4" ! decodebin ! \ > audioconvert ! audioresample ! \ > nokiaamrnbenc band-mode=7 ! \ > ffmux_amr ! filesink location=sound.amr > > In a second step, I read the video stream from the original file and mux > it with the previously stored audio. With hantromp4mux, this produced a > file that did not work on S60 phones, so I replaced hantromp4mux with > ffmux_3gp. The dependency was already there, anyway: > > $ gst-launch-0.10 ffmux_3gp name=muxer ! \ > filesink location="outfile.3gp" \ > filesrc location="sound.amr" ! amrparse ! \ > queue ! muxer.audio_00 \ > filesrc location="infile.mp4" ! decodebin ! \ > videoscale ! \ > "video/x-raw-yuv, width=176,height=144" ! \ > videorate ! \ > "video/x-raw-yuv, framerate=15/1" ! \ > ffmpegcolorspace ! \ > dsph263enc bitrate=50000 ! \ > queue ! muxer.video_00 > > Bingo! Beautiful 3GP container with AMR-NB audio and H.263 video. Sent > as MMS, works. > > I tried later to use ffmux_3gp with my original one-liner, but no luck. > > In my experience you may have issues with the caps/capsfilter used in the pipeline and because of where you've put the "queue" elements. This is why I redirected you to that manual, written by an expert on the subject, and to the GStreamer developers' ML. Maybe later today I'll have some time to give your pipeline a try on the N900 and get a precise image of what needs to be done. Regards, Marco > > The site you pointed me to made me recall how MP4-muxers in general > don't cope well with missing EOS-signals from the source. Maybe this is > one of the problems here... Wouldn't know how to check right now, but I > think it might be worth investigating. > > > Regards, > > Oskar > > > >
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
