[Ffmpeg-devel] Re: [PATCH] PKT_FLAG_B

[Michael Niedermayer]

Hi

On Tue, Aug 08, 2006 at 06:19:09PM +0200, Baptiste Coudurier wrote:
> Hi
> 
> Michael Niedermayer wrote:
> > 
> > (dts==pts && has_b_frames) -> frame is a b frame, alternatively you
> > can just extract it out of the video packet, this is very easy, it
> > just requires searching for a byte sequence and then looking at the
> > following byte and gxf has a special case for mpeg1/2 anyway so i see
> > no big problem with that ...
> 
> That is ugly. Frame is already parsed earlier, code will be duplicated.

no it depends on the container, mpeg in avi, nut, mov, ... will not
be parsed


> Also assuming b frame regarding pts/dts difference is not exact, 

elaborate / bugreport
and i prefer to fix a bug instead of changing the AVPacket or AVParser
API to workaround it


> and
> has_b_frames is not set when stream copying.

the parser should set it, if it does not thats a bug which you can fix if
you like, alternatively you can assume it to be always 1


> 
> > furthermore
> > 
> > gxf spec: -------------- NOTE on MPEG GoP structure target values
> > The parameters (I-pictures per GoP, P-pictures per I-picture and B- 
> > pictures per I-picture) are target values provided to the MPEG
> > encoder. The result stream may not meet this cadence at the
> > discretion of the encoder. These values are provided for information
> > purposes only. --------------
> > 
> > -> the relate code is wrong, values should be set to 
> > AVCodecContext.max_b_frames and AVCodecContext.gop_size and for the
> > stream copy case they are 0 or random either is fine
> 
> I do not agree with that. Stream copy is exactly like if it was encoded.
> It is muxer/parser job to parse the stream and gather infos and to SET
> them if they can be known, and they can and parsed, I just need access
> to the parser from the muxer. I don't get your point here.
> 
> Players (broadcast servers) does not behave correctly if B and P values
> are 0, random will be just wrong.

elaborate, which broadcast server does what? the spec clearly says
"These values are provided for information purposes only."

and about setting them correctly for the stream copy case, thats not
possible as they represent encoder parameters not parameters which depend
on the stream


> 
> > and the media field number should be set to dts and time line field
> > number to pts, not a random +=2 every frame variable
> 
> That is right. media field number is actually dts, 

good so we agree


> computed correctly
> internally 

no your calculation is wrong, try a telecined mpeg 


> since lavf does not readjust/correct timestamps when stream
> copying.

well elaboarte + bugreport

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is