Re: [FFmpeg-trac] #7023(undetermined:new): mediastreamvalidator failed with "Error injecting segment data"

[FFmpeg]

#7023: mediastreamvalidator failed with "Error injecting segment data"
-+-
 Reporter:  loki5100 |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:  hls  |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-

Comment (by loki5100):

 Is their any way that i can get access to the compiled ffmpeg with this
 patch included ? I try to download the compiled version 20180313-b173e03
 at https://ffmpeg.zeranoe.com/builds/ but it's seam it's not include this
 patch :(

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [FFmpeg-trac] #7083(avcodec:new): Decoder playing out frames at double speed

[FFmpeg]

#7083: Decoder playing out frames at double speed
+---
 Reporter:  baudouin0   |Owner:
 Type:  defect  |   Status:  new
 Priority:  normal  |Component:  avcodec
  Version:  git-master  |   Resolution:
 Keywords:  h264|   Blocked By:
 Blocking:  |  Reproduced by developer:  0
Analyzed by developer:  0   |
+---

Comment (by baudouin0):

 Ok I understand - when I played the ts steam in VLC media player or our
 own player (using ffmpeg) we saw the issue in that the picture would
 stutter with the P-frames comming out twice as fast and then a pause
 before the next I-frame. As that is quite complicated we looked into just
 compiling ffmpeg on its own and found this. Your right that it could be
 another issue we have not yet found. However that variable being set to
 zero is not correct. I may be able to use ffplay to see what the fix does.
 My understanding of what was intended in the code is limited so I not sure
 on the correct fix.

 I will try ffplay and get back to you.

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [FFmpeg-trac] #7083(avcodec:new): Decoder playing out frames at double speed

[FFmpeg]

#7083: Decoder playing out frames at double speed
+---
 Reporter:  baudouin0   |Owner:
 Type:  defect  |   Status:  new
 Priority:  normal  |Component:  avcodec
  Version:  git-master  |   Resolution:
 Keywords:  h264|   Blocked By:
 Blocking:  |  Reproduced by developer:  0
Analyzed by developer:  0   |
+---

Comment (by cehoyos):

 Replying to [comment:5 baudouin0]:
 > What I am saying is if you rebuild the ffmpeg code with the line
 >
 > printf("h264_slice_header_init() build=%d time_scale=%d
 ticks_per_frame=%d num_units_in_tick=%d\n", h->x264_build,
 sps->time_scale, h->avctx->ticks_per_frame, sps->num_units_in_tick);
 >
 > and run it on the bitstream I sent.
 >
 > You will see that the variable x264_build becomes zero.

 Yes, I saw this and I wrote above that I read this analysis that you sent.

 > This is a bug as it affects the way your decoder operates including the
 way in which the ticks and time scale are interpreted.

 My question is: How does it affect the way the decoder operates? How can I
 see a difference (be it in playback speed or something else) if I fix the
 issue with the poc you posted?

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [FFmpeg-trac] #7083(avcodec:new): Decoder playing out frames at double speed

[FFmpeg]

#7083: Decoder playing out frames at double speed
+---
 Reporter:  baudouin0   |Owner:
 Type:  defect  |   Status:  new
 Priority:  normal  |Component:  avcodec
  Version:  git-master  |   Resolution:
 Keywords:  h264|   Blocked By:
 Blocking:  |  Reproduced by developer:  0
Analyzed by developer:  0   |
+---

Comment (by baudouin0):

 What I am saying is if you rebuild the ffmpeg code with the line

 printf("h264_slice_header_init() build=%d time_scale=%d ticks_per_frame=%d
 num_units_in_tick=%d\n", h->x264_build, sps->time_scale,
 h->avctx->ticks_per_frame, sps->num_units_in_tick);

 and run it on the bitstream I sent.

 You will see that the variable x264_build becomes zero. This is a bug as
 it affects the way your decoder operates including the way in which the
 ticks and time scale are interpreted.

 Its up to you then to get to the bottom of it.

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [FFmpeg-trac] #7083(avcodec:new): Decoder playing out frames at double speed

[FFmpeg]

#7083: Decoder playing out frames at double speed
+---
 Reporter:  baudouin0   |Owner:
 Type:  defect  |   Status:  new
 Priority:  normal  |Component:  avcodec
  Version:  git-master  |   Resolution:
 Keywords:  h264|   Blocked By:
 Blocking:  |  Reproduced by developer:  0
Analyzed by developer:  0   |
+---

Comment (by cehoyos):

 Replying to [comment:3 baudouin0]:
 > You can then see this with the bitstream I have sent.
 How?
 What do I have to do to see the ''double speed'' issue?

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [FFmpeg-trac] #7083(avcodec:new): Decoder playing out frames at double speed

[FFmpeg]

#7083: Decoder playing out frames at double speed
+---
 Reporter:  baudouin0   |Owner:
 Type:  defect  |   Status:  new
 Priority:  normal  |Component:  avcodec
  Version:  git-master  |   Resolution:
 Keywords:  h264|   Blocked By:
 Blocking:  |  Reproduced by developer:  0
Analyzed by developer:  0   |
+---

Comment (by baudouin0):

 Many thanks for the quick response.

 When we play a mpeg transport stream into the decoder (ffplay or VLC
 3.0.1) we see the I-frame (which has a PTS time stamp in the ts before the
 SPS) played out followed by the P-frames at double speed then a gap before
 the next I-frame (and PTS) comes along. This does not happen on VLC 2.2.8
 but I have not found which version of ffmpeg these are built with. In
 trying to find out the cause of this problem we discovered the bug that
 the h->x264_build becomes zero rather than -1. So I added printf into the
 code as I have shown into h264_slice_header_init(). You can then see this
 with the bitstream I have sent. We can also fix the issue be setting
 time_scale in the h264 bitstream to 25000 rather than 5 but this is
 not correct as H264 ticks are always in fields regardless of the picture
 structure.

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [FFmpeg-trac] #7084(avfilter:new): Memory leak in libavfilter/graphparser.c

[FFmpeg]

#7084: Memory leak in libavfilter/graphparser.c
-+
 Reporter:  Kira |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:  avfilter
  Version:  unspecified  |   Resolution:
 Keywords:  leak |   Blocked By:
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+

Comment (by Kira):

 Replying to [comment:1 cehoyos]:
 > {{{
 > // reference: doc/examples/filtering_video.c
 > }}}
 > What is unclear about the first 13 lines of that file?
 >
 > Do you know why the issue is not reproducible with `ffmpeg`?
 I found that `ffmpeg` use `avfilter_graph_parse2` rather than
 `avfilter_graph_parse_ptr`. I think it's because of the different behavior
 between `avfilter_graph_parse2` and `avfilter_graph_parse_ptr`.

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac