[MEncoder-users] unable to encode to dvvideo - can't initialize dv format!

[Jelle de Jong]

Reimar � wrote:
> On Sun, Mar 15, 2009 at 12:23:48AM +0100, Jelle de Jong wrote:
>> Killer issues I still have is the major cpu load making it impossible to
>> do a live recording see my previous other email tread on the mailinglist
>> for this.
> 
> DV is more optimized for hardware encoding than software. Also nobody
> cares much about it so it lacks SIMD optimizations, and in addition to
> that it is a high bitrate codec.
> 
>> (see also the yuv422p -> yuv420p can I make mencoder output yuv420p)
> 
> Maybe by removing the "format=422P" part?
> 
> 
>> $ ffmpeg -i output0.dv -target pal-dv output1.dv
>> Input #0, dv, from 'output0.dv':
>>   Duration: 00:00:00.84, start: 0.000000, bitrate: 57600 kb/s
>>     Stream #0.0: Video: dvvideo, yuv422p, 720x576, 57600 kb/s, PAR 59:54
>> DAR 295:216, 25 tbr, 25 tbn, 25 tbc
>>     Stream #0.1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
>>     Stream #0.2: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
>> Output #0, dv, to 'output1.dv':
>>     Stream #0.0: Video: dvvideo, yuv420p, 720x576 [PAR 59:54 DAR
>> 295:216], q=2-31, 200 kb/s, 90k tbn, 25 tbc
>>     Stream #0.1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
>>
>> The ffmpeg output seems more then 50% smaller in file size (see
>> output0.log) why is this?
> 
> Because the 4:2:2 DV format is 50 MBit/s and the 4:2:0 format is 25
> MBit/s.
> I'd expect the duplicate audio streams to be an FFmpeg bug, but not
> really sure.

I improved the recording command a bit by rebuilding the command and
using 8 treads. The cpu does not hog to 100% anymore and uses around 70%
with is still an awful lot (mpeg4 runs ok). The disk usage is pretty low
so that is also not an issue, but the 1GB mem I have runs out pretty
fast, so it will eventually generate video buffer overflows. (please see
the output3.log attachment)

Would somebody please have a look at the output3.log and maybe tell me
what exactly goes wrong during recording, and does it do the same on your
system? How do your logs look like?

Again thank you Reimar for responding, and you were right on top with the
removing the "format=422P part. The ffmpeg output now looks like:

$ ffmpeg -i output3.dv -target pal-dv output4.dv
Input #0, dv, from 'output3.dv':
  Duration: 00:00:01.48, start: 0.000000, bitrate: 28800 kb/s
    Stream #0.0: Video: dvvideo, yuv420p, 720x576, 28800 kb/s, PAR 59:54
DAR 295:216, 25 tbr, 25 tbn, 25 tbc
    Stream #0.1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Output #0, dv, to 'output4.dv':
    Stream #0.0: Video: dvvideo, yuv420p, 720x576 [PAR 59:54 DAR
295:216], q=2-31, 200 kb/s, 90k tbn, 25 tbc
    Stream #0.1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s

However both the output of the output3.dv and output4.dv will only show a
black windows when playing with mplayer the few secs audio I have seem to
fine but without actual moving video and longer play time, I can never be
sure if the sync is correct.

Somebody willing to test the command I used with there devices and see
how it records?

Thanks in advance,

Jelle de Jong
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output3.log
Type: text/x-log
Size: 38830 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mencoder-users/attachments/20090315/1a1a7b8d/attachment.bin>