Hey all,
I've had the best HD results with huffyuv in an AVI container, but something is going wrong with the number of frames.
ffmpeg and mplayer both see the proper ~5310 frames (~178 seconds), but pix_movie reports only 750 frames.
Everything works fine with small files (640x480) but with these highres files (1280x960) I am only able to play the first 750 frames.
Can someone take a look?
Otherwise I'm stuck with using mjpeg.
Thanks. .b.
PD says: <reader> : Checking: /home/bbogart/tmp/step+repeat/step+repeat007-1280x960-huff-mencoder.avi <AVI reader> : MainHeader: MicroSecPerFrame=33366 MaxBytesPerSec=0 PaddingGranularity=0 Flags=[ HAS_INDEX IS_INTERLEAVED TRUST_CKTYPE ] TotalFrames=750 InitialFrames=0 Streams=1 SuggestedBufferSize=0 WxH=1280x960 Scale=0 Rate=0 Start=0 Length=0 <AVI reader> : StreamHeader: Type=vids Handler=HFYU Flags=[ ] InitialFrames=0 Scale=1001 Rate=30000 Start=0 Length=5332 SuggestedBufferSize=1469368 Quality=0 SampleSize=0 Rect l,r,t,b=0,1280,0,960 rs r:0 ds:36 t:1413894985 s:24 <AVI reader> : InfoChunk Software: MEncoder dev-SVN-r26940 addd 0 24 rs r:24 ds:36 t:1263424842 s:3572 addd 24 3572 <AVI reader> : Reading index from offset: 1072970868 <AVI reader> : WARNING: stream header has incorrect dwLength (5332 != 750) <AVI reader> : Stream 0 vids : HFYU (0x55594648) 750 chunks (2.93KB) <reader> : Initialized video stream (chunk tblsz: 750, fmtsz: 116) <codec keeper> : Found 5 plugins (/usr/lib/avifile-0.7,A:22,V:32) <FFMPEG video decoder> : looking huffyuv <ffhuffyuv> : if you have troubles - use Win32 codec instead <codec keeper> : Created video decoder: FF Huffyuv <ffhuffyuv> : doesn't support DR1
mplayer says: AVI file format detected. ID_VIDEO_ID=0 [aviheader] Video stream found, -vid 0 AVI: ODML: Building ODML index (1 superindexchunks). AVI: No audio stream found -> no sound. VIDEO: [HFYU] 1280x960 16bpp 29.970 fps 342111.9 kbps (41761.7 kbyte/s) Clip info: Software: MEncoder dev-SVN-r26940 ID_CLIP_INFO_NAME0=Software ID_CLIP_INFO_VALUE0=MEncoder dev-SVN-r26940 ID_CLIP_INFO_N=1 ID_FILENAME=step+repeat007-1280x960-huff-mencoder.avi ID_DEMUXER=avi ID_VIDEO_FORMAT=HFYU ID_VIDEO_BITRATE=342111848 ID_VIDEO_WIDTH=1280 ID_VIDEO_HEIGHT=960 ID_VIDEO_FPS=29.970 ID_VIDEO_ASPECT=0.0000 ID_LENGTH=177.91 ID_SEEKABLE=1
Hey Johannes,
I'm currently using svn r2603 (trunk directory).
I'm trying now with gmerlin compiled in.
Ok, I've compiled in gmerlin support.
pix_movie does report the proper number of frames (5065).
But for some reason when I seek above 4902 (starting at 4903) the video locks up and will not seek anymore. In order to reset seeking I have to reload the video file.
This is still a marked improvement!
Is gmerlin now an official replacement for libavifile, libmpeg3 ?
Even my m2t file plays, but does not seek, so gmerlin seems to support more formats.
The files I'm working with are 5GB, a bit big to put online. Anything small does not seem to show the issue.
Here is the ffmpeg command I used to generate the files:
ffmpeg -intra -an -sameq -ss 7 -t 169 -i step+repeat007.m2t -vcodec huffyuv -s 1024x768 step+repeat007-1024x768-huff.avi
src is over 5000 frames.
the m2t file is 2GB, so I can try and put that up, but I think it would be easier for you to just generate a huff file by scaling up whatever video content you have.
Thanks Johannes.
.b.
IOhannes m zmoelnig wrote:
B. Bogart wrote:
i can confirm something like this: after converting jose luis' pdcon-video using your ffmpeg line, i get a video with 5064 frames, of which i can access 4901 frames (with 4902 being the 1st "locked" frame) however: - #4901 seems to display the last frame of the video (as displayed e.g. by vlc, mplayer or avidemux (note that the latter displays Gem's #4901 as the correct #5064) - seeking still works if i select earlier frames
this means that somehow the frame2position calculations is screwed up.
This is still a marked improvement!
Is gmerlin now an official replacement for libavifile, libmpeg3 ?
yes. Gem still has support for everything, but gmerlin is definitely the future way to go: it wraps all the rest.
Even my m2t file plays, but does not seek, so gmerlin seems to support more formats.
and more.
fgmasdr IOhannes
Hi Johannes,
Great this part is reproducible. (more or less) Sounds like the same root of the issue anyhow.
Please let me know if you get a chance to take a look at the frame2position calculation.
..b
IOhannes m zmoelnig wrote:
B. Bogart wrote:
should be fixed in the 0.92 branch of Gem https://pd-gem.svn.sourceforge.net/svnroot/pd-gem/branches/0.92/Gem
fgmasdr IOhannes
B. Bogart wrote:
Thanks Johannes,
Not in trunk/ ?
why would you want it in trunk if there is a release?
fgmasdr IOhannes
PS: but yes, it's in trunk as well; the mail was mainly a hint that now there _is_ a branch for 0.92, meaning that it's to be released but now it's too late anyhow