transcode-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Original]

[transcode-users] -y jpg,null ; extra frames issue


To: transcode-users@xxxxxxxxx
Subject: [transcode-users] -y jpg,null ; extra frames issue
From: S D <headers@xxxxxxxxx>
Date: Tue, 31 May 2005 14:22:01 -0400
Delivered-to: itdp@localhost
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;b=cMNZVvvBj5iDY/gDewnf9q2uZYYoWi7DC4EJtIjAkdljncK96P104HXQS0Sh06Z6gxpKzl8MMkiJ5Uy60e6HxJHObUknTRwXtSlTgwICWSULzpXlurJG++EGdScd5rsnxvIz8cRkcJST5w7UuQQbnO6MoFrnqfmCuAmTermY4+M=

All, 

I am  trying to  extract a  specific set of  individual frames  from a
movie for offline analysis.  I encounter a strange effect where I seem
to get more  frames that I requested.   I shall try to give  as full a
description as  I can in  the hopes that  somebody here may  have seen
something like  it and can give  me advice.  Apologies if the dscription 
seems too full. I checked the archives but could  not find any obvious 
mention of this effect.

The command I am using is this:

transcode -i /media/Films/0329111.avi -o frame. -y jpg,null -c
118598-118599,118749-118750,118842-118843,119803-119804,119868-119869,119920-119921,120000-120001,120056-120057

The goal  is to render to  jpg frames 118598,  118749, 118842, 119803,
119868, 119920,  120000, 120056 and  only those. This type  of command
generally works for this task,  even with 1000s of required frames.

Version is 0.6.14, system is FC1 with 2.4.22 kernel. The initial
headers printed out are these:

[transcode] (probe) suggested AV correction -D 0 (0 ms) | AV 0 ms | 0 ms
[transcode] auto-probing source /media/Films/0329111.avi (ok)
[transcode] V: import format    | DivX RIFF data, AVI (V=ffmpeg|A=ac3)
[transcode] V: import frame     | 592x384  1.54:1  
[transcode] V: bits/pixel       | 0.330
[transcode] V: decoding fps,frc | 23.976,1
[transcode] V: Y'CbCr           | YV12/I420
[transcode] A: import format    | 0x2000  AC3          [48000,16,2]  192 kbps
[transcode] A: export           | disabled
[transcode] V: encoding fps,frc | 23.976,1
[transcode] A: bytes per frame  | 8008 (8008.000000)
[transcode] A: adjustment       | 0@xxxx
[transcode] V: IA32 accel mode  | sse2 (sse2 sse mmxext mmx asm C)
[transcode] V: video buffer     | 10 @ 592x384
[import_ac3.so] AC3->PCM
[import_ac3.so] tcextract -a 0 -i "/media/Films/0329111.avi" -x ac3 -d
0 | tcdecode -x ac3 -d 0 -s 1.000000,1.000000,1.000000 -A 0

I capture the  stdout to audit what is done by  transcode. It is large
(one line per  frame) so I will describe snippets here.  Most of it is
stuff like this:

skipping frames [000000-003806], 117.10 fps, EMT: 0:02:38, ( 0| 0| 0) 
skipping frames [000000-003807], 116.96 fps, EMT: 0:02:38, ( 0| 0| 7) 


When a required  frame is dumped I  see a blank line in  my log, like so:

skipping frames [118843-119801], 153.48 fps, EMT: 1:23:16, ( 0| 0| 2) 
skipping frames [118843-119802], 153.64 fps, EMT: 1:23:16, ( 0| 0| 1) 

skipping frames [119804-119811],  90.18 fps, EMT: 1:23:17, ( 0| 0| 5) 
skipping frames [119804-119812], 102.97 fps, EMT: 1:23:17, ( 0| 0| 4) 

in  this case  indicating  that frame  119803  was rendered  to jpg  as
required.



But, sometimes  transcode will start extracting frames  where none are
requested and  continue until  a requested frame  is reached.   In the
case of  my example, the log  generated by exactly  that command shown
above shows this:

skipping frames [119921-119974], 145.60 fps, EMT: 1:23:23, ( 0| 0| 2) 
skipping frames [119921-119975], 148.34 fps, EMT: 1:23:23, ( 0| 0| 1) 

encoding frame [119977],  12.67 fps,  4.2%, ETA: 0:00:00, ( 0| 0| 6)  
encoding frame [119978],  20.23 fps,  8.3%, ETA: 0:00:00, ( 0| 0| 5)  
encoding frame [119979],  25.14 fps, 12.5%, ETA: 0:00:00, ( 0| 0| 4)  
encoding frame [119980],  28.69 fps, 16.7%, ETA: 0:00:05, ( 0| 0| 3)  
encoding frame [119981],  31.40 fps, 20.8%, ETA: 0:00:03, ( 0| 0| 2)  
encoding frame [119982],  33.40 fps, 25.0%, ETA: 0:00:03, ( 0| 0| 1)  
encoding frame [119983],  28.72 fps, 29.2%, ETA: 0:00:02, ( 0| 0| 0)  
encoding frame [119984],  25.86 fps, 33.3%, ETA: 0:00:02, ( 0| 0| 9)  
encoding frame [119985],  27.18 fps, 37.5%, ETA: 0:00:01, ( 0| 0| 8)  
encoding frame [119986],  28.36 fps, 41.7%, ETA: 0:00:01, ( 0| 0| 7)  
encoding frame [119987],  29.50 fps, 45.8%, ETA: 0:00:01, ( 0| 0| 6)  
encoding frame [119988],  30.39 fps, 50.0%, ETA: 0:00:01, ( 0| 0| 5)  
encoding frame [119989],  30.99 fps, 54.2%, ETA: 0:00:00, ( 0| 0| 4)  
encoding frame [119990],  31.75 fps, 58.3%, ETA: 0:00:00, ( 0| 0| 3)  
encoding frame [119991],  32.43 fps, 62.5%, ETA: 0:00:00, ( 0| 0| 2)  
encoding frame [119992],  33.08 fps, 66.7%, ETA: 0:00:00, ( 0| 0| 1)  
encoding frame [119993],  33.73 fps, 70.8%, ETA: 0:00:00, ( 0| 0| 0)  
encoding frame [119994],  31.55 fps, 75.0%, ETA: 0:00:00, ( 0| 0| 8)  
encoding frame [119995],  32.10 fps, 79.2%, ETA: 0:00:00, ( 0| 0| 7)  
encoding frame [119996],  32.68 fps, 83.3%, ETA: 0:00:00, ( 0| 0| 6)  
encoding frame [119997],  33.13 fps, 87.5%, ETA: 0:00:00, ( 0| 0| 5)  
encoding frame [119998],  33.62 fps, 91.7%, ETA: 0:00:00, ( 0| 0| 4)  
encoding frame [119999],  34.10 fps, 95.8%, ETA: 0:00:00, ( 0| 0| 3)  
encoding frame [120000],  34.56 fps, 100.0%, ETA: 0:00:00, ( 0| 0| 2)  
skipping frames [120001-120003],  44.77 fps, EMT: 1:23:25, ( 0| 0| 8) 
skipping frames [120001-120004],  67.04 fps, EMT: 1:23:25, ( 0| 0| 7) 


Comments: Previous required frame was 119920,  next due frame is  120000. 
Note that for some  reason dumping started in a  sequence from 119976 until
the next required was reached.


The  end of the  log is  a blank  line for  the last  frame requested,
followed by another blank line and then the trailing header thingy:

skipping frames [120001-120054], 145.30 fps, EMT: 1:23:27, ( 0| 0| 2) 
skipping frames [120001-120055], 148.03 fps, EMT: 1:23:27, ( 0| 0| 1) 


clean up | frame threads | unload modules | cancel signal | internal
threads | done



The file in my example is an  814M divx created by mencoder from a DVD
(should be obvious which). 

 tcprobe -i 0329111.avi
[tcprobe] RIFF data, AVI video
[avilib] V: 23.976 fps, codec=DIVX, frames=136734, width=592, height=384
[avilib] A: 48000 Hz, format=0x2000, bits=16, channels=2, bitrate=192 kbps,
[avilib]    11406 chunks, 136869120 bytes, CBR
[tcprobe] summary for 0329111.avi, (*) = not default, 0 = not detected
import frame size: -g 592x384 [720x576] (*)
       frame rate: -f 23.976 [25.000] frc=1 (*)
      audio track: -a 0 [0] -e 48000,16,2 [48000,16,2] -n 0x2000 [0x2000] 
                   bitrate=192 kbps
           length: 136734 frames, frame_time=41 msec, duration=1:35:02.947


 midentify  0329111.avi
ID_VIDEO_ID=0
ID_AUDIO_ID=1
ID_FILENAME="0329111.avi"
ID_VIDEO_FORMAT=DIVX
ID_VIDEO_BITRATE=1000072
ID_VIDEO_WIDTH=592
ID_VIDEO_HEIGHT=384
ID_VIDEO_FPS=23.976
ID_VIDEO_ASPECT=1.8282
ID_AUDIO_CODEC=a52
ID_AUDIO_FORMAT=8192
ID_AUDIO_BITRATE=192000
ID_AUDIO_RATE=48000
ID_AUDIO_NCH=2
ID_LENGTH=5702


Note  I  have  experienced  this  effect on  a  few  files,  including
differently encoded  versions of this movie  (different video bitrates
and mp3 audio for example). I  can supply this file via scp to anybody
who wishes to use it for debugging/comparison.

Thanks in advance for any help, 

            Ryd


[Prev in Thread] Current Thread [Next in Thread]