http://bugs.cinelerra.org/show_bug.cgi?id=530

           Summary: Clips which are direct copied may not start with an I
                    frame.
           Product: Cinelerra
           Version: 2.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: Medium
         Component: Rendering
        AssignedTo: [email protected]
        ReportedBy: [email protected]


Mpeg[24] encoding consists of I Frames followed by B and P Frames which are
relative to the preceding I frame. When cutting out a bit of mpeg, unless the
cut happens to be at an I frame, the frames from the cut up until the next I
Frame need to be reconstructed. Direct copying can proceed from the next I
Frame. Cinelerra doesn't do this correctly (or at all?).

Other software refers to I frames as "keyframes" which is confusing in the
light of Cinelerra's usage.

Reproducible: Always

Steps to Reproduce:
1.Start with an mpeg4 encoded quicktime file.
2.Create a project with random clips and no other effects
3.Render the file using the same encoding, size etc as the original
4. Play the clip using (for example) mplayer, single stepping through frames at
the transition points.

Actual Results:  
Mplayer complains that "warning: first frame is no keyframe" and displays
blocky video up until it does get the first I Frame. At each transition there
is also the same blocky video effect. 

Expected Results:  
Smooth video playback.

My source video was created with mencoder with the following options

    -ofps 16 -of lavf -lavfopts format=mov \
    -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1200:aspect=4/3:keyint=30

The compositor window does not show this effect, so somewhere there is code
which knows how to do the right thing. My source has an I Frame every 30th
frame. This effect would not manifest its self if every frame was a keyframe,
but the mencoder default is 250, which would result in up to 10 seconds of
broken video at 25fps.

Changing the encoding which forces re-encoding during rendering also makes this
effect go away, but of course this is a) slower and b) leads to generational
lossage.

If I do ffprobe on the source I get:
tmp $ ffprobe /var/media/rip/dalls-dvd-project/dalls-3-mpeg4.mov 
FFprobe version SVN-rUNKNOWN, Copyright (c) 2007-2008 Stefano Sabatini
  libavutil version: 49.10.0
  libavcodec version: 51.71.0
  libavformat version: 52.22.1
  built on Dec 18 2008 23:02:22, gcc: 4.1.2 20070925 (Red Hat 4.1.2-33)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
'/var/media/rip/dalls-dvd-project/dalls-3-mpeg4.mov':
  Duration: 01:04:22.50, start: 0.000000, bitrate: 1184 kb/s
    Stream #0.0(eng): Video: mpeg4, yuv420p, 720x576 [PAR 16:15 DAR 4:3], 16.00
tb(r)

Whereas ffprobe on the result of the render is:
tmp $ ffprobe /var/tmp/test-render.mov
FFprobe version SVN-rUNKNOWN, Copyright (c) 2007-2008 Stefano Sabatini
  libavutil version: 49.10.0
  libavcodec version: 51.71.0
  libavformat version: 52.22.1
  built on Dec 18 2008 23:02:22, gcc: 4.1.2 20070925 (Red Hat 4.1.2-33)
[mpeg4 @ 0x960a730]hmm, seems the headers are not complete, trying to guess
time_increment_bits
[mpeg4 @ 0x960a730]my guess is 1 bits ;)
[mpeg4 @ 0x960a730]Error, header damaged or not MPEG4 header (qscale=0)
[mpeg4 @ 0x960a730]header damaged
[mpeg4 @ 0x960a730]hmm, seems the headers are not complete, trying to guess
time_increment_bits
[mpeg4 @ 0x960a730]my guess is 1 bits ;)
[mpeg4 @ 0x960a730]Error, header damaged or not MPEG4 header (qscale=0)
[mpeg4 @ 0x960a730]header damaged
[mpeg4 @ 0x960a730]hmm, seems the headers are not complete, trying to guess
time_increment_bits
[mpeg4 @ 0x960a730]my guess is 4 bits ;)
[mpeg4 @ 0x960a730]warning: first frame is no keyframe
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/var/tmp/test-render.mov':
  Duration: 00:00:01.75, start: 0.000000, bitrate: 1602 kb/s
    Stream #0.0(eng): Video: mpeg4, yuv420p, 720x576 [PAR 1:1 DAR 5:4], 16.00
tb(r)

Note that there are additional "problems" ffprobe notes with the header.


-- 
Configure bugmail: http://bugs.cinelerra.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Reply via email to