[MEncoder-users] help with old divx for linux codec, please?

[Dieter]

> >>> Ffmpeg complains a lot about the mpeg4 output from mencoder.
> >> Considering that mencoder outputs mpeg4 encoded by libavcodec,
> >> I find your statement dubious. Have you submitted a bugreport?
> > 
> > Probably not.  Back when I was working on this I was more concerned
> > with the crashes than the mere complaints.
> 
> [mess cut out]
> 
> > It goes on like this for awhile, then settles down and grinds away quietly.
> 
> That shouldn't be happening, needless to say, and I don't think anyone 
> else is having that problem.

Capture:

  source: HD3000 tuner card, in analog mode, v4l2
  AMD64 running Linux 2.6.15-AS23-default

  /app/bin/mencoder -oac lavc -ovc lavc \
   -lavcopts acodec=mp2:abitrate=128:vcodec=mpeg4:vbitrate=16000:aspect=4/3   \
   tv://${CHANNEL}    \
   -tv device=/dev/${DEVICE}:driver=v4l2:norm=0:outfmt=yuy2:width=640:height=480:\
  saturation=${SATURATION}:contrast=${CONTRAST}:brightness=${BRIGHTNESS}:hue=50:adevice=/dev/dsp:amode=1:\
  forceaudio:audiorate=48000:chanlist=us-bcast:fps=29.97002997002997:volume=100 \
   -o $OUTFILE > $LOGFILE 2>&1 &

Convert-to-DV:

  AMD64 running FreeBSD 6.2

  ffmpeg -v 2 -shift 1 -async 100 -i input.mpeg4 -padcolor 010101 -padtop 0 -padbottom 0 \
  -padleft 40 -padright 40 -cropleft 0 -cropright 0 -pix_fmt yuv411p -s 640x480 \
  -r 30000/1001 /tmp/input.swap.dv

  -shift 1 swaps the interlace fields by shifting 1 scanline (a mod from Dan Maas)
  -padcolor 010101 is because 000000 comes out medium grey instead of black (a bug somewhere)

> > Often, when it hits the end, it will seek back and keep going.  No clue why
> > it would do this.  This only happens with the mencoder generated mpeg4,
> > not with the OTA mpeg2ts.

The bunch of complaints happens almost every time.
The seeks-back-and-keeps-going-when-it-hits-the-end happens frequently.

> >>> I don't know if the problem is with mencoder or ffmpeg or both.
> >>> I don't recall seeing it crash.
> >>>
> >>> Ffmpeg does crash from bad mpeg2ts input.  At least 2 different
> >>> problems resulting in seg fault and at least 1 floating point
> >>> exception.
> >> Bugreports with backtraces, please.
> > 
> > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-March/008436.html
> > 
> > Putting in an ugly hack to avoid calling memset() with a negative length
> > prevents the crash.  Probably not the best way to fix it.
> > 
> > The bad input is of course copyrighted, attempts to cut out a small
> > enough piece to be considered fair use didn't get very far.
> > 
> > I still got seg faults from some other bug after "fixing" this one.
> > 
> > While some of the ffmpeg developers were helpful. others were ... not.
> > I got fed up, unsubscribed and switched to working on other problems
> > where I could actually make some progress.
> 
> I see only one response to the message in the URL you posted: Mans 
> asking for a sample. If you couldn't provide a sample, then you can't 
> really blame anybody for not looking at your report further.

Tracing the problem down to calling memset() with a negative length
isn't sufficient?

> Of course, 
> you could be referring to a different thread in which ffmpeg developers 
> were unhelpful, but I don't see any evidence of that here.

I was referring to other threads, not to a request for a sample. 

> Anyway, if you can re-try extracting a small sample, or get more 
> comfortable about uploading a larger sample to mplayerhq's private ftp 
> (I have no idea how much is fair use), somebody might be able to help you.

Just grab some OTA mpeg2ts with bad reception (add an attenuator, or unplug
antenna altogether, or ...) and feed it to ffmpeg and watch ffmpeg crash in
a variety of ways.