[FFmpeg-trac] #1487(avformat:new): ffmpeg's mpeg mux bug(s) never fixed...
    FFmpeg 
    trac at avcodec.org
       
    Sun Jan  6 20:07:15 CET 2013
    
    
  
#1487: ffmpeg's mpeg mux bug(s) never fixed...
------------------------------------+------------------------------------
             Reporter:  downuse     |                    Owner:
                 Type:  defect      |                   Status:  new
             Priority:  normal      |                Component:  avformat
              Version:  git-master  |               Resolution:
             Keywords:  mpegps      |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
------------------------------------+------------------------------------
Comment (by downuse):
 Replying to [comment:12 cehoyos]:
 > I believe this was fixed, please test again.
 ---
 Yes, scr is now begin with 0, but it's not continuous,
 such as
 00:00:00.00 (0)
 00:00:00.00 (225)
 00:00:00.01 (450)
 00:00:00.01 (675)
 00:00:00.01 (900)
 00:00:00.01 (1125)
 00:00:00.01 (1350)
 00:00:00.50 (12233) -> it should be like 00:00:00.02
 00:00:00.50
 00:00:00.51
 i think this line in avformat/mpegenc.c
 line:985 scr= FFMAX(best_dts+1, scr);
 cause the scr jmp.
 and if it is possible, please do something with scr_ext, it's now 0
 anywhere.
 ----
 video stream should have both PTS and DTS in I and P frame, B frame only
 have PTS because its PTS=DTS
 PTS should have some time (like 00:00:00.04) later than DTS
 the first PTS of each stream should be same,
 and first PTS of video stream is AV_NOPTS_VALUE in current git head.
 ----
 by the way, what do rel_space,premux_packet and predecode_packet mean...
 i don't understand how to result "best_i".
-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1487#comment:13>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
    
    
More information about the FFmpeg-trac
mailing list