Log in

View Full Version : xvid encoded file doesn't play on standalone divx player


lam_das
18th January 2007, 23:35
I encoded the season premiere of 24 using xvid with ffmpeg on linux (no b-frames, no qpel, no gmc) and created a 1.2G file which I put on the dvd-rw disk and tried to play on my samsung dvd-v5650 player. It plays fine upto a point (plays 1 hr 15 mins out of 1 hr 25 mins of show) and then it freezes and comes back to menu.

Another symptom is that I can not seek 5 mins with 'next' button on the remote after it has crossed 25 mins position. It keeps coming back to 25 min position. At this very position, I can not fast forward faster than 2x. Play stops at close to 1hr 15 mins.

If I play the same file in mplayer, windows media player it plays fine.

If I play the same file in divx player in windows, it freezes at exactly the same spot.

So, what is about this xvid file that divx player and the standalone player don't like? I also figure that the freeze is close to 1GB mark. Is there a size limit on the divx player and the standalone player that they can't play files greater than 1GB.

$ file 24_2007-01-14_8-00PM_Day_6-_6-00AM_-_7-00AM-7-00AM_-_8-00AM.avi

24_2007-01-14_8-00PM_Day_6-_6-00AM_-_7-00AM-7-00AM_-_8-00AM.avi: RIFF (little-endian) data, AVI, 640 x 480, ~30 fps, video: XviD, audio: MPEG-1 Layer 3 (stereo, 48000 Hz)

already ruled out:

1. dvd+rw media.
2. with b-frames.

Any ideas?

Thanks a lot.

Forgot to mention: The ffmpeg cmdline
pass 1:

ffmpeg -threads 2 -y -f s16le -ar 48000 -ac 2 -f rawvideo -pix_fmt yuv420p -s 720x480 -aspect 1.33333333333333 -r 29.970 -i /tmp/fifodir_18406/vidout -aspect 1.33333333333333 -r 29.970 -deinterlace -croptop 0 -cropright 6 -cropbottom 4 -cropleft 14 -s 640x480 -vcodec xvid -b 1843200 -bt 32 -minrate 32 -maxrate 3600 -bufsize 65535 -flags +4mv+trell+loop -aic 1 -mbd 1 -cmp 2 -subcmp 2 -cgop 1 -pass 1 -passlogfile /tmp/xvid.18406.log -f avi /dev/null

pass 2:

ffmpeg -vol 218 -threads 2 -y -f s16le -ar 48000 -ac 2 -i /tmp/fifodir_18406/audout -f rawvideo -pix_fmt yuv420p -s 720x480 -aspect 1.33333333333333 -r 29.970 -i /tmp/fifodir_18406/vidout -aspect 1.33333333333333 -r 29.970 -deinterlace -croptop 0 -cropright 6 -cropbottom 4 -cropleft 14 -s 640x480 -vcodec xvid -b 1843200 -bt 32 -minrate 32 -maxrate 3600 -bufsize 65535 -flags +4mv+trell+loop -aic 1 -mbd 1 -cmp 2 -subcmp 2 -cgop 1 -pass 2 -passlogfile /tmp/xvid.18406.log -acodec mp3 -async 1 -ab 128 -f avi 24_2007-01-14_8-00PM_Day_6-_6-00AM_-_7-00AM-7-00AM_-_8-00AM.2.avi

lam_das
18th January 2007, 23:46
is it the trellis quantization?

foxyshadis
19th January 2007, 03:25
Trellis shouldn't affect playback in any way (although "shouldn't" and "won't" are two different things for video hardware). You might well be right about a 1GB limit, it could be that your file is improperly indexed. If it happens to Divx Player as well, it's definitely not your hardware player's fault.

It's hard to tell what the issue might be without the file, though the first 2K might help. (The index as well, everything past idx1, but that can be 10 megs or more.) So in the meantime, you might try updating ffmpeg and see if that resolves the error:
http://ffdshow.faireal.net/mirror/ffmpeg/

lam_das
19th January 2007, 03:43
do you know if there is any place where ffmpeg's command line arguments are explained a little bit? I just figured that it has its own mpeg4 vcodec as well and with -vtag divx, I just might be able to produce something for the divx player.

I did this on small clip only to find that divx produces bigger file than xvid and more blocky picture (loss in quality and gain in filesize). I just passed '-vcodec mpeg4 -b 1800 -vtag divx' because I don't know any other options for divx. Do you know what can I do to reduce blocks in the darker areas of the picture with divx?

ilovejedd
19th January 2007, 04:25
Use xvid. I think I read somewhere that the mpeg4 codec in ffmpeg is just a non-optimized standard implementation. Basically, it was just taken from the sample code, probably. The -vtag argument just changes the fourcc code. You can even use -vcodec xvid -vtag divx if you want but that probably won't make a difference, playability-wise. I'm betting the problem is because the AVI is over 1GB. I think I read in the manual for my Philips DVP642 that the file size limit is 1GB. Maybe it's the same for your player?

Unfortunately, ffmpeg's documentation isn't very comprehensive and the commands probably differ depending on what you have enabled upon compile.

Try running the ffmpeg generated AVI through VirtualDub using Direct stream copy for both audio and video. All AVI files I converted using ffmpeg had garbage headers when I use -acodec mp3 so I always run them through VirtualDub.

lam_das
19th January 2007, 06:51
samsung dvd-v5650 manual doesn't say anything about the file size limit. manual:

CD-R AVI file
This unit can play the following video compression
formats within the AVI file format:
- DivX 3.11 contents
- DivX 4 contents (Based on MPEG4 Simple Profile)
- DivX 5 contents (MPEG4 simple profile plus
additional features such as bi-directional frames.
Qpel and GMC are also supported.)
- XviD MPEG4 compliant Contents.

This unit supports all resolutions up to maximum
below.

DivX5

720 x 480 @30fps
720 x 576 @25fps
: Maximum bitrate : 4Mbps

DivX3.11 & DivX4 & XviD

Bitrate may fluctuate:
Device may skip decoding
the high bitrate portions
and begin decoding again
when Bitrate returns to
normal.

So, it seems like there is no limitation.

I just removed all options like -aic, trellis, 4mv etc. for the xvid encode with ffmpeg. I had the same problem. divx player in windows stopped at filesize very close to 1024*1024*1024 and the standalone suffered the similar fate. How do I go about removing this limit? I don't suppose divx player can't play files >1GB while divx encoder can create them.

foxyshadis
19th January 2007, 10:34
Most likely ffmpeg is simply broken, and you'll need to use encraw or mencoder to create correct mpeg-4 avis over 1gb. Like ilovejedd mentioned, you could try making a copy through virtualdub, which is good at correcting bad streams, but it's difficult to automate that.

This doesn't seem to have anything to do with the hardware player or software divx player, other than their not being robust enough to handle mangled files.

lam_das
21st January 2007, 00:19
Try running the ffmpeg generated AVI through VirtualDub using Direct stream copy for both audio and video. All AVI files I converted using ffmpeg had garbage headers when I use -acodec mp3 so I always run them through VirtualDub.

I tried this with direct stream copy with audio and video and created an AVI file with and without 'use 1gb instead of 2gb for odml indexing' and file played in divx player to full but my standalone refused to play it to full still.

also, virtualdub complains about audio being vbr. how significant is that? where does this leave us?

I have updated ffmpeg to svn and its being re-encoded at this time. I will update.

lam_das
21st January 2007, 01:07
ok, updating ffmpeg doesn't help at all.

I noticed that with 1gb odml headers checked in virtualdub, the file plays thru full on the standalone, although I can't fast forward or jump 5 minutes chunks.

This has become a nightmare. I don't know what else to do to get it to create a usable avi file.

foxyshadis
21st January 2007, 08:32
Now that the file itself is fixed, I guess you're running into your standalone's limits. Which is not fun. =\ You might just have to split your movie in two, and play the two files sequentially. (Laserdisc memories.) Or worse, encode to less than 1gb. Otherwise what you have now (bad seeking) may be the best it gets.

Another option might be to contact samsung support directly and see if they have updated firmware or another fix for the problem.

lam_das
21st January 2007, 09:01
> samsung support directly and see if they have updated firmware

This might be worth a try.

Yeah, I think I am gonna stop here. Thanks a lot for the help, buddy!

ilovejedd
22nd January 2007, 06:38
virtualdub complains about audio being vbr. how significant is that?Not significant. It's encoded in CBR. The warning is just a result of the garbage headers. If you try opening the fixed AVI with VirtualDub, you'll see it's not complaining about VBR audio anymore.

lam_das
22nd January 2007, 07:23
good one there! indeed, virtualdub is not complaining anymore.