0

RV silently respects movie 'start_time' attribute

Doug MacMillan

August 11, 2016 01:45

None

Follow

The attribute "start_time" in my 48 FPS quicktime is -0.2254, or 14 frames.

RV skips the first 14 frames silently. 

I noticed this because I was ripping the frames using ffmpeg with the "-ss" option and I'm getting all 132 frames (14 more at the head.)

Is this one of those "go ahead and write your own handler to do whatever you want, since this isn't something that we or the majority of your customers care about?"

Noticed that FinalCut movies occasionally have this attribute non-zero.

Might be a good idea to at least mention this time value on the F4 info panel?

• Facebook
• Twitter
• LinkedIn

6 comments

• 0
  
  Jon Morley August 11, 2016 05:16

  Hi Doug,

  I am responsible for the code that respects that information, though I arrived at my decision based on lots of samples and not a formal document somewhere. If you can share your sample with me I might be able to make more sense out of what is going on. Feel free to open a support ticket if the material is sensitive.

  Can you please explain what you mean by:

  "go ahead and write your own handler to do whatever you want, since this isn't something that we or the majority of your customers care about?"

  I am not sure I follow. I am pretty confident that restricting the playback to the duration reported by the container is better than exclusively going off any one media stream. Incidentally since RV is a primarily a video player video stream duration always trumps that of audio.

  Anyway this behavior is in some of our compiled parts of RV so it isn't something that can be scripted around easily. But I am open to making changes if we can work together to hash out a plan. I can't make any promises about if/when those changes would come to pass, but it sounds like it would be good to understand your sample better.

  Please let me know more. How was the file created? What did you expect when you opened it? Did you expect -14 as the first frame? etc, etc.

  Thanks,
  Jon

• 0
  
  Doug MacMillan August 11, 2016 18:12

  Hi Jon, thanks for your prompt reply.

  I thought Alan Trombla was going to be the one reading this, so I added that disclaimer about "write your own handler" so you can ignore that. In either case, the 'feature' is not scriptable, so ignore that comment twice in rapid succession.

  I have a series of movies that were shot in 2010 on a Canon t2i, and the person used a "mark in" feature (scissors button) to select the footage he wanted.

  This appears to be encoded as this "start_time" metadata.

  The part I am troubled about is that RV presents this in-camera edit as though the 14 extra frames don't exist.

  I'm still looking for a sample movie that does not require me uploading this in-house footage.

   

  

• 0
  
  Doug MacMillan August 11, 2016 18:19

  FYI, here's the metadata... (minus sound stream and boring bits.)

  $ python -c "print 0.2254 * 59.94"
  13.510476

  $ ffprobe -v quiet -print_format json -show_streams bld_2124.mov
  {
  "streams": [
  {
  "index": 0,
  "codec_name": "h264",
  "codec_long_name": "H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10",
  "profile": "Constrained Baseline",
  "codec_type": "video",
  "codec_time_base": "1/120000",
  "codec_tag_string": "avc1",
  "codec_tag": "0x31637661",
  "width": 1280,
  "height": 720,
  "has_b_frames": 0,
  "sample_aspect_ratio": "0:1",
  "display_aspect_ratio": "0:1",
  "pix_fmt": "yuvj420p",
  "level": 50,
  "r_frame_rate": "60000/1001",
  "avg_frame_rate": "60000/1001",
  "time_base": "1/60000",
  "start_pts": -13524,
  "start_time": "-0.225400",
  "duration_ts": 132132,
  "duration": "2.202200",
  "bit_rate": "40489837",
  "nb_frames": "132",
  . . .

• 0
  
  Jon Morley August 11, 2016 18:28

  Hi Doug,

  I see. Thank you for the additional information. What you describe sounds mostly in alignment with other samples we have. The users in those cases expected only the footage within the cut region to be played. I can see how this is a bit unnerving to users that either don't know that is set in the file or still want to edit all possible data.

  It would be cool if the file could be loaded with all of the frames, yet have the FileSource in/out points be pre-populated to the cut range. If that happened then you would have the best of both worlds. Unfortunately there isn't a level of communication between the file reader plugins and the graph like that (at least not at the moment). I think the "easiest" thing to do for now would be to add another argument to the mio_ffmpeg file reader to respect that value or ignore it.

  I will look at it again when I break off some free time. In the meantime can you please tell me how stuck you are with the current behavior? Do you need those frames or were you mostly shocked they don't show up?

  Thanks,
  Jon

• 0
  
  Doug MacMillan August 11, 2016 18:40

  Sounds like we are in perfect agreement.

  No problem Jon! This is not a show-stopper.

  I have a tool here in RV that allows a user to select in-out points on the movie which spawns a movie-to-exr ripping process, and the offset was puzzling me.

  Now I work around this by offsetting the rip-edit-points using the metadata to match RV.

• 0
  
  Jon Morley August 11, 2016 20:05

  Hi Doug,

  Thanks for clarifying. I will keep this at a low priority. Probably see what I can do the next time I am in that plugin for a collection of updates. I will consider you set for now. Please let me know if this becomes more urgent.

  Thanks,
  Jon