Again, about cutting video fragments and saving them to MPEG2 file.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Again, about cutting video fragments and saving them to MPEG2 file.

wl2776
Administrator
Sorry for repeating posts about the same problem, however, it is very important for me.
I am kind of missing some basics about MPEG2 video and will be happy if someone can explain me this or point to the tutorial/explanation.

My goal is to cut some fragments from a video clip and save them to another shorter video clip.
As I've written earlier, suppose this: |==*****======********==| is the initial video clip, spread in time.

I must obtain the shorter video clip, containing only (*) frames, (=) frames must be discarded.

I have some success with this, but when the clip is played, in the place, where two different (*) fragments meet, some "transition" effects occur with squares of invalid data.

These effects occur because a movie player meets some B-frames, which don't have corresponding P or I frame (it was discarded as falling in (=) area) and builds corresponding picture basing on wrong data.

I must get rid of these effect, so that the clip was played smoothly.

Overall, my strategy is the following.
1. av_read_frame(input, &pkt); av_free_packet(&pkt) until the I-frame is met.
  Then save that I-frame and go to point 2 below

2. av_read_frame(input, &pkt) ; av_write_frame(output,&pkt) ; av_free_packet(&pkt) until the end of the fragment is met.
 Then av_read_frame(input, &pkt) ; av_write_frame(output,&pkt) ; av_free_packet(&pkt) until the I-frame is met.
Save that I-frame (and free packet, of course).

3. av_seek_frame to the beginning of the next fragment and go to point 1 above.

What is wrong in that algorithm?

When processing the second fragment I correct timestamps of the read frames so that avoid big gaps in timestamps in the resulting video. They are correct, and basing on them solely, a movie player should play everything as I suppose.
However, that's not the case.
If I load the resulting video in the avidemux program ( http://avidemux.org/ ) and have it show frames step by step, it appears that two B-frames which follow the first I-frame in the second fragment (as av_read_frame gives them) are displayed before that I-frame.
Reply | Threaded
Open this post in threaded view
|

Re: Again, about cutting video fragments and saving them to MPEG2 file.

Paul Kelly-3
On Fri, 25 Jul 2008, Vladimir Eremeev wrote:

> If I load the resulting video in the avidemux program ( http://avidemux.org/
> ) and have it show frames step by step, it appears that two B-frames which
> follow the first I-frame in the second fragment (as av_read_frame gives
> them) are displayed before that I-frame.

That is perfectly normal. That is why MPEG has separate DTS (decode time
stamp) and PTS (presentation time stamp). Here is a typical sequence of
MPEG video frames showing the order in which they are received and played:
IPBBPBBPBBIBBPBBPBBIBBPBBPBB Receive Order
  IBBPBBPBBPBBIBBPBBPBBIBBPBBP Display Order

Note the offset of one frame (each I or P frame is displayed while the
next I or P frame is being decoded), and see also that although the two B
frames are received after the I-frame, they are displayed before it. So I
think you need to drop those two B-frames from your stream completely. And
it may also help to set the "broken GOP" {GOP = Group of Pictures} flag in
the GOP header, although I'm not sure how to do that with FFmpeg. In fact
there is probably a very simple way to do this with FFmpeg that hides
these complexities? I'm not experienced enough to know. See
http://outflux.net/unix/software/GOPchop/ for a useful discussion however
(scroll down to "KNOWN ISSUES" for the most relevant part).

Paul
_______________________________________________
libav-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user