[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