AutoMen problem on Popcornhour

[weaver4]

I have a Popcorn Hour A-100 ( www.popcornhour.com ). I have a problem when I make a XviD avi in AutoMen and run it on the PopCornHour.

When I go fast-forward into the middle of a movie and then press the play button it can take up to 10 minutes before the movie starts playing again. Even if I go FF for a couple of seconds and and hit play again it will "pause" the frame, wait up to 10 minutes and then start playing again.

This does not happen on movies made with avi.net, autogk, or staxrip; only with tools that use mencoder (including command line encodes on Linux).

Buzz; I realize this is not a problem with AutoMen but a problem with the PopcornHour, but I am trying to help them debug the problem and I thought you might have some ideas.

[buzzqw]

have you tried to do a "direct copy stream" with virtualdub ?

also.. post a avinaptic report of this file.. i haven't at hand long avi to analyze

also, using XviD (of mpeg4), try checking in advanced settings Force DiVX 4CC

BHH

[weaver4]

I will try the Direct Stream Copy tonight and see if that helps.

I tried the DivX thing, it did not help.

Here is the avinaptic report. [This one was created on Linux; I will post the one for AutoMen later today.] I looked at this report and one that was created by autogk and the only thing that looked suspicious was this:

Container type: AVI OpenDML indexes multi-chunks (*)


=========================================
[ About file ]

Name: MyMovie.xlxeqhwsd.avi
Date: 2/03/2008 20:59:50
Size: 1,919,709,488 bytes (1830.778 MB)

[ Generic infos ]

Play duration: 02:23:27 (8606.889958 s)
Container type: AVI OpenDML indexes multi-chunks (*)
Number of streams: 2
Type of stream nr. 0: video
Type of stream nr. 1: audio
Audio streams: 1
ISFT: MEncoder 2:1.0~rc1-0ubuntu13.1
JUNK: [= MPlayer junk data! =]

[ Relevant data ]

Resolution: 640 x 256
Width: multiple of 32
Height: multiple of 32

[ Video track ]

FourCC: DX50/DX50
Resolution: 640 x 256
Frame aspect ratio: 5:2 = 2.5
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 5:2 = 2.5
Vprp aspect ratio: 4096:1683 = 2.433749
Framerate: 23.976023 fps
Number of frames: 206359 (125324)
Stream size: 1,767,313,228 bytes
Bitrate: 1642.696245 kbps
Qf: 0.418177
Key frames: 3506 (1; 240; 479; 718; 745; ... 206179)
Null frames: 1 (0)
Min key int: 1
Max key int: 239
Avg key int: 58.858813
Delay: 0 ms

[ Audio track ]

Audio tag: 0x55 (MP3)
Bitrate (container): 128 kbps CBR
Channels (container): 2
Sample rate (container): 48000 Hz
Chunks: 358624
Stream size: 137,711,616 bytes
Preload: 504 ms
Max A/V diff: 523 ms
Type: MPEG-1 Layer III
Chunk-aligned: Yes
Emphasis: none
Mode: joint stereo
Delay: 41.6875 ms

[ About MPEG4 encoding ]

User data: DivX503b1393p
User data: XviD0046
Packed bitstream: Yes
QPel: No
GMC: No
Interlaced: No
Aspect ratio: Square pixels
Quant type: H.263

[ Profile compliancy ]

Profile to check: MTK PAL 6000
Resolution: Ok
Framerate: 23.976023 <> 25
Warning: If you need a more complete report, then click on "DRF analysis"

This report was created by AVInaptic (18-11-2007) on 3 mar 2008, h 17:54:08

[buzzqw]

ok.. edit the bat encoding and add this "−noodml" without quotes (and for avi < 2gb size)

rencode and.. tellme :)

BHH

[weaver4]

That helped, but what does -noodml do?

[microchip8]

That helped, but what does -noodml do?

OpenDML, it writes indexes for AVI files bigger than 1 GB

[buzzqw]

the main problem is that multichuncks avi is not supported.. or at least.. not well supported in seeking after first seek...

i haven't knowledge on this.. but fsinapsi (author of avinpatic) have written something about ..

i will try to bother frank... :)

BHH

P.S. in next update i will add -noodml in automen

[weaver4]

OpenDML, it writes indexes for AVI files bigger than 1 GB

Froggy1; this all started from trying to make a *.avi file on Linux using your app "XvidEnc" that would run on the PopcornHour A-100. The PopcornHour people were convinced that it was a Linux problem so I tried mencoder on Windows using AutoMen and got the same problem.

Here is the thread from the PopCornHour forum.

http://www.networkedmediatank.com/viewtopic.php?t=2052

[microchip8]

Froggy1; this all started from trying to make a *.avi file on Linux using your app "XvidEnc" that would run on the PopcornHour A-100. The PopcornHour people were convinced that it was a Linux problem so I tried mencoder on Windows using AutoMen and got the same problem.

Here is the thread from the PopCornHour forum.

http://www.networkedmediatank.com/viewtopic.php?t=2052

hmm very weird, I'll add -noodml to the HW presets of xvidenc in the next release

[SeeMoreDigital]

Smooth navigation of "multi-chunk" or "multi-part" indexed .AVI files has always presented problems with hardware players.

If the "multi-part" .AVI file is less than 2GB, it's possible to use MPEG4Modifier to re-mux the .AVI file to the more robust OpenDML v2.0 standard.

Hence my discussion here (http://forum.doom9.org/showthread.php?p=1084749#post1084749).

[weaver4]

Thanks Guys! Here is what I posted in the popcornhour forum to tie things up.

http://www.networkedmediatank.com/viewtopic.php?p=17744#17744

=============================================

According to a thread in Doom 9 this problem appears to be a problem with "multi-chunk" or "multi-part" indexed .AVI files. Hope it can be fixed in the future.

http://forum.doom9.org/showthread.php?t=135511

In the short term it appears that if you are using mencoder you should keep your avi files shorter than 2 Gig and use the -noodml parameter.

BTW: buzzqw -- the author of AutoMKV and AutoMen; froggy1 -- the Author of XvidEnd and H264Enc (linux world), SeeMoreDigital -- the Doom9 Hardware Guru, all provided input on this problem. That's a pretty good team.