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

[Corey Hickey]

Dieter wrote:
>>>>> 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 &

I don't see anything wrong with the lavcopts portion of the above
command; however, I don't have any TV hardware with which to test. Try
encoding to some intermediate format (like -ovc raw) and see if you have
trouble encoding from that; if you do, then you have a sample file to
upload.

>>> 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?

I don't know; I can't speak for Mans, but, personally, I would want to
find a more fundamental cause before fixing that part, if possible.

For what it's worth, the relevant section of error_resilience.c has been
changed since then, anyway, so at least the bad memset() usage has been
fixed.

>> 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.

I can't do that, and, I bet, neither can most of the people who might
otherwise look at your bug. If you can't provide a sample, then you're
probably out of luck.

-Corey