Tom Metro wrote:
> Roger,
>
>> ...here is the current version...
>
> Thanks for sharing your script. We should get it uploaded to the wiki.
>
>
>> I have not noticed any sync issues.
>
> I converted an Xvid using it, and it produced a nice looking picture,
> but garbled audio when played back via the mvpmc filesystem browser.
I don't believe I have tried any xvid stuff yet.
>
> mplayer -identify reports:
>
> AVI file format detected.
> ID_VIDEO_ID=0
> ID_AUDIO_ID=1
> VIDEO: [XVID] 624x352 12bpp 23.976 fps 990.6 kbps (120.9 kbyte/s)
> ID_DEMUXER=avi
> ID_VIDEO_FORMAT=XVID
> ID_VIDEO_BITRATE=990592
> ID_VIDEO_WIDTH=624
> ID_VIDEO_HEIGHT=352
> ID_VIDEO_FPS=23.976
> ID_VIDEO_ASPECT=0.0000
> ID_AUDIO_FORMAT=85
> ID_AUDIO_BITRATE=128648
> ID_AUDIO_RATE=0
> ID_AUDIO_NCH=0
> ID_LENGTH=2596.80
> ...
> Forced audio codec: mad
> Opening audio decoder: [libmad] libmad mpeg audio decoder
> AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 16000->192000)
> ID_AUDIO_BITRATE=128000
> ID_AUDIO_RATE=48000
> ID_AUDIO_NCH=2
> Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3)
>
>
> I thought maybe the problem was AC3 audio, and although I don't know
> what ID_AUDIO_FORMAT=85 correlates to, it appears to be using the MPEG
> audio codec, so I'd presume MP3.
>
>
> I also tried running the script against a MythTV NUV file using Myth's
> RTJpeg codec, and it didn't seem to like it. I presume that's because
> mplayer doesn't support RTJpeg. It doesn't seem to be able to play those
> files. I've looked at several transcoding tools, and although several
> support the NUV container, I've yet to see any that say they support
> RTJpeg. To work around this I ended up coding up a script that used the
> same technique nuvexport does of having mythtranscode output raw video
> to a FIFO. If your script was MythTV-specific, it might be a good
> approach to use as well to insulate it from MythTV-specific video format
> detection and decoding.
I had not really made it MythTV specific, I was using it to convert
various things from other sources. And right now I don't have any
.nuv files, my biggest conversion needs for MythTV type files were the
HDTV tuner card outputs which are mostly pretty regular (MPEG2/AC3).
Adding a bit of code to handle these other formats is probably not
a bad idea.
>
> Using this technique I've gotten playable video from an RTJpeg file, but
> so far with horrible audio sync problems and video that seems to
> degraded into slow motion. Perhaps the bitrate is too high, or something.
My calculations of derating video bitrates may need to be adjusted
for formats like Xvid and mp4 where the same bitrate in mp4 is really
equivalent to a much higher bitrate in mpeg2. My current set of
bitrate adjustments are based on mpeg2 to mpeg2 and adjusting
the bitrate down based on resolution, adjusting to formats with higher
effective bitrates would require upping the bitrate to get reasonable
images out in those other format cases. See the abps, and mbps
variables.
>
> With the giant matrix of transcoders, codecs, and options, it's very
> frustrating and time consuming trying to zone in on the settings that
> work. At least seeing your mencoder command lines I knew one set of
> output options that should work with the MVP.
That was at what I was attempting, at least get something that
worked, and that is alot of why I convert everything to a certain
limited set, a number produce odd results.
>
>
>> Any reasonable comments are welcome...
>
> I noticed in your code that samples the source video in several places
> that you aren't making use of the -identify switch, which is
> specifically meant to produce output that can be parsed.
The answer to this one is I did not find the -identify option,
so I did it the hard way, it is a big man page. That would have
made most of the parsing alot easier....
>
>
> I don't follow why you have options like:
> -vf cropdetect -srate 48000 -ofps 30000:1001
> -lavcopts vcodec=mpeg2video:acodec=mp3:abitrate=192...
>
> which affect the output video, which you are just throwing away. (I
> guess -vf cropdetect might be useful, as it probably impacts the
> dimensions reported.) Also, if you specify -ovc raw, isn't -lavcopts
> meaningless? (I'd expect mencoder to point that out.)
Yes, I copied the lines from earlier lines and did not take the time
to eliminate things that were not needed, if it worked I did not
worry about the extra.
The cropdetect was to used on letterbox and similarly clipped
video, alot of the hdtv stuff comes this way.
>
>
> Structurally, I'm not following why you do this:
>
> if [ -f "$1" ] ; then
> export TMPFILE=`/bin/mktemp`
> if [ $DEBUG == 1 ] ; then
> echo "Temp file is $TMPFILE"
> fi
>
> # sample in several places
> mencoder -of mpeg -frames 5 -vf cropdetect -srate 48000 -ofps
> [...]
> else
> echo "Usage: ${0} <videofiletoconvert>"
> echo " "
> exit -1
> fi
>
>
> The statements inside the first part of the if-clause seem to be no
> different than the statements that follow in the rest of the script.
> They all are intended to execute as long as the supplied argument is a
> file, right? So I'd expect:
>
> if [ ! -f "$1" ] ; then
> echo "Usage: ${0} <videofiletoconvert>"
> echo " "
> exit -1
> fi
>
> export TMPFILE=`/bin/mktemp`
> [...]
>
> # sample in several places
> [...]
I think it is more of the order I wrote the code in, that I really
did not go back in reorganize it in a more obvious way.
>
>
> Why are audio and video rates and resolutions hard coded:
>
> export srate=48000
> export abitrate=192
> [...]
> echo "This file is not MPEG1 or MPEG2 - transcoding"
> mencoder [...] expand=640:480
>
> I assume as a matter of simplification. In some cases this will result
> in wasteful upconversion of video and audio, when the original settings
> might have been perfectly playable on the MVP, just the wrong format.
>
> -Tom
>
The video resolutions were hard coded to match what the largest the
mvpmc would play nicely, I could get it to go to 720x480 but it did not
seem to add much so I stayed with 640x480. srate and abitrate are
audio, see "abps" (average bps) for the calculation of the video bit
rate. And the video resolution is only hardcoded in some places
the lower resolutions that work were left the same, if I did not know
if it worked or not I converted it to a resolution that I knew worked
correctly, some resolutions produced bad results.
I did not mess with the audio rates because after some testing
I found that it did not affect file size or conversion speed in any
large way, so I hardcoded them reasonably high. The video I played
more tricks with because it does make a big difference.
Roger
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Mvpmc-users mailing list
Mvpmc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mvpmc-users
mvpmc wiki: http://mvpmc.wikispaces.com/
