Re: [FFmpeg-trac] #6294(avfilter:open): gif frame delay dropped from last frame when scale filter is used

2017-04-11 Thread FFmpeg
#6294: gif frame delay dropped from last frame when scale filter is used
+
 Reporter:  okor|Owner:
 Type:  defect  |   Status:  open
 Priority:  normal  |Component:  avfilter
  Version:  git-master  |   Resolution:
 Keywords:  fps |   Blocked By:
 Blocking:  |  Reproduced by developer:  1
Analyzed by developer:  0   |
+

Comment (by Gyan):

 As long as **shortest=1** works, it should work.

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


Re: [FFmpeg-trac] #6307(undetermined:new): detected tbr different past 3.1.7 (1080i H.264)

2017-04-11 Thread FFmpeg
#6307: detected tbr different past 3.1.7 (1080i H.264)
-+-
 Reporter:  korylprince  |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  unspecified  |  undetermined
 Keywords:   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-

Comment (by korylprince):

 Current HEAD 6268f2ca7b:


 {{{
 $ ffmpeg -i 1080i_29.97.mts
 *[master]
 ffmpeg version N-85467-g6268f2ca7b Copyright (c) 2000-2017 the FFmpeg
 developers
   built with gcc 6.3.1 (GCC) 20170109
   configuration:
   libavutil  55. 61.100 / 55. 61.100
   libavcodec 57. 92.100 / 57. 92.100
   libavformat57. 72.100 / 57. 72.100
   libavdevice57.  7.100 / 57.  7.100
   libavfilter 6. 84.101 /  6. 84.101
   libswscale  4.  7.100 /  4.  7.100
   libswresample   2.  8.100 /  2.  8.100
 Input #0, mpegts, from '/tmp/1080i_29.97.mts':
   Duration: 00:00:09.54, start: 0.390400, bitrate: 8896 kb/s
   Program 1
 Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448),
 yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 59.94 tbr,
 90k tbn, 59.94 tbc
 Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz,
 5.1(side), fltp, 384 kb/s
 Stream #0:2[0x1200]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] /
 0x0090), 1920x1080
 At least one output file must be specified
 }}}

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


[FFmpeg-trac] #6308(undetermined:new): fifo muxer broken with RTSP

2017-04-11 Thread FFmpeg
#6308: fifo muxer broken with RTSP
-+-
 Reporter:   | Type:  defect
  ChocolateArmpits   | Priority:  normal
   Status:  new  |  Version:
Component:   |  unspecified
  undetermined   |   Blocked By:
 Keywords:  fifo |  Reproduced by developer:  0
 Blocking:   |
Analyzed by developer:  0|
-+-
 fifo muxer doesn't work when used with RTSP. Used by itself RTSP works
 properly. fifo used with TCP or UDP works correctly (mpegts muxer). Using
 latest snapshot compiled with MingW 64bit on Windows 7 64bit.

 Ffplay is used to listen for incoming RTSP stream.
 {{{
 ffplay -f rtsp -rtsp_flags listen rtsp://localhost:8088
 }}}

 Ffmpeg is used to encode a single audio stream that is sent using
 fifo+rtsp to the same localhost port. The command fails. If used with fifo
 autorecovery the output just keeps restarting but doesn't do anything
 successful either.
 {{{
 $ ffmpeg -v 9 -loglevel 99 -re -f lavfi -i sine -acodec aac -f fifo -map
 0:a -fifo_format rtsp rtsp://localhost:8088
 ffmpeg version N-85461-gcd8e627 Copyright (c) 2000-2017 the FFmpeg
 developers
   built with gcc 6.2.0 (Rev2, Built by MSYS2 project)
   configuration:
   libavutil  55. 61.100 / 55. 61.100
   libavcodec 57. 92.100 / 57. 92.100
   libavformat57. 72.100 / 57. 72.100
   libavdevice57.  7.100 / 57.  7.100
   libavfilter 6. 84.101 /  6. 84.101
   libswscale  4.  7.100 /  4.  7.100
   libswresample   2.  8.100 /  2.  8.100
 Splitting the commandline.
 Reading option '-v' ... matched as option 'v' (set logging level) with
 argument '9'.
 Reading option '-loglevel' ... matched as option 'loglevel' (set logging
 level) with argument '99'.
 Reading option '-re' ... matched as option 're' (read input at native
 frame rate) with argument '1'.
 Reading option '-f' ... matched as option 'f' (force format) with argument
 'lavfi'.
 Reading option '-i' ... matched as input url with argument 'sine'.
 Reading option '-acodec' ... matched as option 'acodec' (force audio codec
 ('copy' to copy stream)) with argument 'aac'.
 Reading option '-f' ... matched as option 'f' (force format) with argument
 'fifo'.
 Reading option '-map' ... matched as option 'map' (set input stream
 mapping) with argument '0:a'.
 Reading option '-fifo_format' ... matched as AVOption 'fifo_format' with
 argument 'rtsp'.
 Reading option 'rtsp://localhost:8088' ... matched as output url.
 Finished splitting the commandline.
 Parsing a group of options: global .
 Applying option v (set logging level) with argument 9.
 Successfully parsed a group of options.
 Parsing a group of options: input url sine.
 Applying option re (read input at native frame rate) with argument 1.
 Applying option f (force format) with argument lavfi.
 Successfully parsed a group of options.
 Opening an input file: sine.
 detected 2 logical cores
 [AVFilterGraph @ 0045a9c0] query_formats: 2 queried, 3 merged, 0
 already done, 0 delayed
 [lavfi @ 00458cc0] All info found
 [lavfi @ 00458cc0] stream 0: start_time: 0.000 duration:
 -209146758205323.719
 [lavfi @ 00458cc0] format: start_time: 0.000 duration:
 -9223372036854.775 bitrate=705 kb/s
 Input #0, lavfi, from 'sine':
   Duration: N/A, start: 0.00, bitrate: 705 kb/s
 Stream #0:0, 1, 1/44100: Audio: pcm_s16le, 44100 Hz, mono, s16, 705
 kb/s
 Successfully opened the file.
 Parsing a group of options: output url rtsp://localhost:8088.
 Applying option acodec (force audio codec ('copy' to copy stream)) with
 argument aac.
 Applying option f (force format) with argument fifo.
 Applying option map (set input stream mapping) with argument 0:a.
 Successfully parsed a group of options.
 Opening an output file: rtsp://localhost:8088.
 Successfully opened the file.
 Stream mapping:
   Stream #0:0 -> #0:0 (pcm_s16le (native) -> aac (native))
 Press [q] to stop, [?] for help
 cur_dts is invalid (this is harmless if it occurs once at the start per
 stream)
 [graph_0_in_0_0 @ 00520640] Setting 'time_base' to value '1/44100'
 [graph_0_in_0_0 @ 00520640] Setting 'sample_rate' to value '44100'
 [graph_0_in_0_0 @ 00520640] Setting 'sample_fmt' to value 's16'
 [graph_0_in_0_0 @ 00520640] Setting 'channel_layout' to value
 '0x4'
 [graph_0_in_0_0 @ 00520640] tb:1/44100 samplefmt:s16
 samplerate:44100 chlayout:0x4
 [format_out_0_0 @ 00521bc0] Setting 'sample_fmts' to value 'fltp'
 [format_out_0_0 @ 00521bc0] Setting 'sample_rates' to value
 '96000|88200|64000|48000|44100|32000|24000|22050|16000|12000|11025|8000|7350'
 [format_out_0_0 @ 00521bc0] auto-inserting filter
 'auto_resampler_0' between the 

Re: [FFmpeg-trac] #6294(avfilter:open): gif frame delay dropped from last frame when scale filter is used

2017-04-11 Thread FFmpeg
#6294: gif frame delay dropped from last frame when scale filter is used
+
 Reporter:  okor|Owner:
 Type:  defect  |   Status:  open
 Priority:  normal  |Component:  avfilter
  Version:  git-master  |   Resolution:
 Keywords:  fps |   Blocked By:
 Blocking:  |  Reproduced by developer:  1
Analyzed by developer:  0   |
+

Comment (by okor):

 A command so intuitive it almost writes itself : D

 But really, thank you very much Gyan, I appreciate in the workaround. I'll
 probably run with this in the mean time. I'll leave this ticket open
 though since it's still valid.

 Would it be safe to assume that this "hack" would work with later stable
 versions of ffmpeg? Works well with 3.2.4 which I believe is what is
 considered stable.

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


Re: [FFmpeg-trac] #6302(undetermined:closed): gif frame delay dropped from last frame when output to webm

2017-04-11 Thread FFmpeg
#6302: gif frame delay dropped from last frame when output to webm
-+-
 Reporter:  okor |Owner:
 Type:  defect   |   Status:  closed
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:   |   Resolution:  duplicate
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-
Changes (by cehoyos):

 * priority:  important => normal
 * component:  ffmpeg => undetermined


Comment:

 Replying to [comment:2 okor]:
 > But that only works if you know what your frame rate should be which we
 will not.
 That sounds unlikely (the command line you posted makes no sense to me)
 but please post all usage questions on the user mailing list.

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


Re: [FFmpeg-trac] #6307(undetermined:new): detected tbr different past 3.1.7 (1080i H.264)

2017-04-11 Thread FFmpeg
#6307: detected tbr different past 3.1.7 (1080i H.264)
-+-
 Reporter:  korylprince  |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  unspecified  |  undetermined
 Keywords:   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-

Comment (by cehoyos):

 Please provide {{{ffmpeg -i}}} output for current FFmpeg git head to make
 this a valid ticket.

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


Re: [FFmpeg-trac] #6294(avfilter:open): gif frame delay dropped from last frame when scale filter is used

2017-04-11 Thread FFmpeg
#6294: gif frame delay dropped from last frame when scale filter is used
+
 Reporter:  okor|Owner:
 Type:  defect  |   Status:  open
 Priority:  normal  |Component:  avfilter
  Version:  git-master  |   Resolution:
 Keywords:  fps |   Blocked By:
 Blocking:  |  Reproduced by developer:  1
Analyzed by developer:  0   |
+

Comment (by Gyan):

 There's a hack method which works if you use a build from earlier than
 23rd Dec 2016.

 `ffmpeg -f lavfi -i color=00 -i 7GPW_LivingRoom.gif -filter_complex
 
"[1]reverse,trim=end_frame=1[t];[1][t]concat[g];[0][g]scale2ref[bg][gif];[bg]setsar=1[bg];[bg][gif]overlay=shortest=1,scale=-2:-2"
 livingroom.mp4`

 The idea is to duplicate the last frame of the GIF and append it to
 itself, and use that going forward. The reason for the 23 Dec 2016 cutoff
 is because there's a bug (#6292) with some video filters at present,
 involving the shortest option.

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


Re: [FFmpeg-trac] #6294(avfilter:open): gif frame delay dropped from last frame when scale filter is used

2017-04-11 Thread FFmpeg
#6294: gif frame delay dropped from last frame when scale filter is used
+
 Reporter:  okor|Owner:
 Type:  defect  |   Status:  open
 Priority:  normal  |Component:  avfilter
  Version:  git-master  |   Resolution:
 Keywords:  fps |   Blocked By:
 Blocking:  |  Reproduced by developer:  1
Analyzed by developer:  0   |
+

Comment (by okor):

 Ah, so it does. The other filter I'm using with gifs creates a canvas to
 set the background color for transparent regions in gifs: `ffmpeg -f lavfi
 -i color=00 -i livingroom.gif -filter_complex
 "[0][1]scale2ref[bg][gif];[bg]setsar=1[bg];[bg][gif]overlay=shortest=1,
 scale=-2:-2" livingroom.mp4`

 And that results in a 2 second video yet again.

 Or just with the canvas filter: `ffmpeg -f lavfi -i color=00 -i
 livingroom.gif -filter_complex
 "[0][1]scale2ref[bg][gif];[bg]setsar=1[bg];[bg][gif]overlay=shortest=1,
 scale=-2:-2" livingroom.mp4`

 Same thing, a 2 second video where I'd expect a 4 second video.

 So maybe some filters break the gif timings and others do not? And
 possibly all simple filters.

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


Re: [FFmpeg-trac] #6307(undetermined:new): detected tbr different past 3.1.7 (1080i H.264)

2017-04-11 Thread FFmpeg
#6307: detected tbr different past 3.1.7 (1080i H.264)
-+-
 Reporter:  korylprince  |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  unspecified  |  undetermined
 Keywords:   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-

Comment (by korylprince):

 I submitted the video clip through the VLC uploader referenced on the
 first page. It's not showing up here, so if there's an issue, you can also
 download it from my latest comment on the blender bug:
 https://developer.blender.org/T51153

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


[FFmpeg-trac] #6307(undetermined:new): detected tbr different past 3.1.7 (1080i H.264)

2017-04-11 Thread FFmpeg
#6307: detected tbr different past 3.1.7 (1080i H.264)
-+-
 Reporter:  korylprince  | Type:  defect
   Status:  new  | Priority:  normal
Component:   |  Version:
  undetermined   |  unspecified
 Keywords:   |   Blocked By:
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
 The tbr of a 1080i H.264 clip is detected differently with versions 3.1.7
 and early detecting '''29.97 tbr''' (which should be correct) and versions
 after 3.1.7 (I've tested 3.2, 3.2.4, and current 3.3-dev) detecting
 '''59.94 tbr'''.

 I don't want to say either is wrong, because I don't know what the correct
 answer is; The behavior is definitely different. I don't know exactly how
 interlaced video works, but the fps should be 29.97 for this clip.

 The clip in question is recorded from a Panasonic HDC-TM700.

 This was discovered because newer versions of blender (including 3.2+
 versions of ffmpeg) detect the given clip at 59.94 fps instead of 29.97
 fps, meaning the video is imported twice as long as the audio. The bug
 report is here: https://developer.blender.org/T51153

 I am attaching logs for versions 3.1.7, 3.2, 3.2.4, and 3.3-dev (commit
 efa89a8), and the clip used, 1080i_29.97.mts .

 Command used:
 {{{
 ffprobe -v 9 -loglevel 99 -report 1080i_29.97.mts
 }}}


 Here is the relevant output from each ffprobe command:

 3.1.7:

 {{{
 Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p,
 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
 }}}

 3.2:

 {{{
 Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(top
 first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 59.94 tbr, 90k tbn, 59.94
 tbc
 }}}

 3.2.4:

 {{{
 Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(top
 first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 59.94 tbr, 90k tbn, 59.94
 tbc
 }}}

 3.3-dev:

 {{{
 Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(top
 first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 59.94 tbr, 90k tbn, 59.94
 tbc
 }}}


 As you can see, 3.1.7 has 29.97 tbr, and the reset are identical and 59.94
 tbr. My guess is this is incorrect, and it should be detected as 29.97
 tbr.

 I think the problem is in libavformat judging from the comments on the
 blender bug.

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


Re: [FFmpeg-trac] #2617(avformat:open): Playback of HLS fails when one of the variant streams are down

2017-04-11 Thread FFmpeg
#2617: Playback of HLS fails when one of the variant streams are down
+
 Reporter:  kyl416  |Owner:
 Type:  defect  |   Status:  open
 Priority:  normal  |Component:  avformat
  Version:  git-master  |   Resolution:
 Keywords:  hls |   Blocked By:
 Blocking:  |  Reproduced by developer:  1
Analyzed by developer:  0   |
+

Comment (by gorilla.maguila):

 We have added a bounty:

 https://www.bountysource.com/issues/1414531-playback-of-hls-fails-when-
 one-of-the-variant-streams-are-down

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


Re: [FFmpeg-trac] #2617(avformat:open): Playback of HLS fails when one of the variant streams are down

2017-04-11 Thread FFmpeg
#2617: Playback of HLS fails when one of the variant streams are down
+
 Reporter:  kyl416  |Owner:
 Type:  defect  |   Status:  open
 Priority:  normal  |Component:  avformat
  Version:  git-master  |   Resolution:
 Keywords:  hls |   Blocked By:
 Blocking:  |  Reproduced by developer:  1
Analyzed by developer:  0   |
+

Comment (by gorilla.maguila):

 The issue is still reproducible with latest git:


 {{{
 ffplay
 http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8
 -loglevel debug
 ffplay version N-85461-gcd8e62746f Copyright (c) 2003-2017 the FFmpeg
 developers
   built with gcc 6.3.1 (GCC) 20170306
   configuration: --prefix=/usr --disable-debug --disable-static --enable-
 avisynth --enable-avresample --enable-fontconfig --enable-gnutls --enable-
 gpl --enable-ladspa --enable-libass --enable-libbluray --enable-
 libfreetype --enable-libfribidi --enable-libgsm --enable-libmodplug
 --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb
 --enable-libopenjpeg --enable-libopus --enable-libfdk-aac --enable-
 libpulse --enable-libschroedinger --enable-libsoxr --enable-libspeex
 --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab
 --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264
 --enable-libx265 --enable-libxvid --enable-nonfree --enable-shared
 --enable-version3
   libavutil  55. 61.100 / 55. 61.100
   libavcodec 57. 92.100 / 57. 92.100
   libavformat57. 72.100 / 57. 72.100
   libavdevice57.  7.100 / 57.  7.100
   libavfilter 6. 84.101 /  6. 84.101
   libavresample   3.  6.  0 /  3.  6.  0
   libswscale  4.  7.100 /  4.  7.100
   libswresample   2.  8.100 /  2.  8.100
   libpostproc54.  6.100 / 54.  6.100
 [http @ 0x7faedc0012c0] Setting default whitelist
 'http,https,tls,rtp,tcp,udp,crypto,httpproxy'
 [http @ 0x7faedc0012c0] request: GET
 /adultswim/big/streams/playlists/toonami.m3u8 HTTP/1.1
 User-Agent: Lavf/57.72.100
 Accept: */*
 Range: bytes=0-
 Connection: close
 Host: amd.cdn.turner.com
 Icy-MetaData: 1


 [hls,applehttp @ 0x7faedc000920] Format hls,applehttp probed with
 size=2048 and score=100
 [http @ 0x7faedc005cc0] request: GET
 /hls/live/249295/adultswim_6/main/1/stream_Layer1.m3u8 HTTP/1.1
 User-Agent: Lavf/57.72.100
 Accept: */*
 Connection: close
 Host: adultswimhls-i.akamaihd.net
 Icy-MetaData: 1


 [http @ 0x7faedc005cc0] HTTP error 403 ForbiddenB sq=0B f=0/0
 [AVIOContext @ 0x7faedc004160] Statistics: 1780 bytes read, 0 seeks
 http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8:
 Server returned 403 Forbidden (access denied)
 }}}


 Other player such as vlc can handle the stream:


 {{{
 vlc http://amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8
 VLC media player 2.2.4 Weatherwax (revision 2.2.3-37-g888b7e89)
 [00e64148] core libvlc: Running vlc with the default interface.
 Use 'cvlc' to use vlc without interface.
 [7fa6a8005ed8] httplive stream: HTTP Live Streaming
 (amd.cdn.turner.com/adultswim/big/streams/playlists/toonami.m3u8)
 [7fa6a8005888] http access error: error: HTTP/1.1 403 Forbidden
 [7fa6a8005888] http access error: error: HTTP/1.0 403 Forbidden
 [7fa6a8005888] access_mms access error: error: HTTP/1.0 403 Forbidden
 [7fa6a8005ed8] core stream error: no suitable access module for
 
`http://adultswimhls-i.akamaihd.net/hls/live/249295/adultswim_6/main/1/stream_Layer1.m3u8'
 [7fa6a8c07728] http access error: error: HTTP/1.1 403 Forbidden
 [7fa6a8c07728] http access error: error: HTTP/1.0 403 Forbidden
 [7fa6a8c07728] access_mms access error: error: HTTP/1.0 403 Forbidden
 [7fa6a8005ed8] core stream error: no suitable access module for
 
`http://adultswimhls-i.akamaihd.net/hls/live/249295/adultswim_6/main/1/stream_Layer2.m3u8'
 [7fa6a8c07d88] http access error: error: HTTP/1.1 403 Forbidden
 [7fa6a8c07d88] http access error: error: HTTP/1.0 403 Forbidden
 [7fa6a8c07d88] access_mms access error: error: HTTP/1.0 403 Forbidden
 [7fa6a8005ed8] core stream error: no suitable access module for
 
`http://adultswimhls-i.akamaihd.net/hls/live/249295/adultswim_6/main/1/stream_Layer3.m3u8'
 [7fa6a8c094f8] http access error: error: HTTP/1.1 403 Forbidden
 [7fa6a8c094f8] http access error: error: HTTP/1.0 403 Forbidden
 [7fa6a8c094f8] access_mms access error: error: HTTP/1.0 403 Forbidden
 [7fa6a8005ed8] core stream error: no suitable access module for
 
`http://adultswimhls-i.akamaihd.net/hls/live/249295/adultswim_6/main/1/stream_Layer4.m3u8'
 [7fa6a8c0a1b8] http access error: error: HTTP/1.1 403 Forbidden
 [7fa6a8c0a1b8] http access 

Re: [FFmpeg-trac] #6294(avfilter:open): gif frame delay dropped from last frame when scale filter is used

2017-04-11 Thread FFmpeg
#6294: gif frame delay dropped from last frame when scale filter is used
+
 Reporter:  okor|Owner:
 Type:  defect  |   Status:  open
 Priority:  normal  |Component:  avfilter
  Version:  git-master  |   Resolution:
 Keywords:  fps |   Blocked By:
 Blocking:  |  Reproduced by developer:  1
Analyzed by developer:  0   |
+

Comment (by Gyan):

 Works if you call scale from within a filter_complex.

 {{{
 λ ffmpeg -i 7GPW_LivingRoom.gif -filter_complex scale=-2:-2 fc-out.mp4
 ffmpeg version N-85457-g8378466507 Copyright (c) 2000-2017 the FFmpeg
 developers
   built with gcc 6.3.0 (Rev2, Built by MSYS2 project)
   configuration:  --enable-avisynth --enable-libmp3lame --enable-libopus
 --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265
 --enable-cuda --enable-cuvid --enable-schannel --enable-decklink --enable-
 fontconfig --enable-frei0r --enable-libass --enable-libbluray --enable-
 libbs2b --enable-libcaca --enable-libfreetype --enable-libfribidi
 --enable-libgme --enable-libgsm --enable-libilbc --enable-libmfx --enable-
 libmodplug --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-
 libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libsoxr
 --enable-libspeex --enable-libtheora --enable-libtwolame --enable-
 libvidstab --enable-libvo-amrwbenc --enable-libwavpack --enable-libwebp
 --enable-libxavs --enable-libxvid --enable-libzimg --enable-openssl
 --enable-libsnappy --enable-gpl --enable-opencl --enable-opengl --enable-
 libcdio --enable-libfdk-aac --enable-libkvazaar --enable-librubberband
 --enable-libssh --enable-libtesseract --enable-libzvbi --enable-
 chromaprint --enable-libopenh264 --enable-libopenmpt --enable-netcdf
 --enable-sdl2 --enable-libzmq --extra-cflags=-DLIBTWOLAME_STATIC --extra-
 cflags=-fopenmp --extra-libs=-lgomp --extra-libs=-lstdc++ --extra-
 cflags=-DLIBSSH_STATIC --extra-ldflags='-Wl,--allow-multiple-definition'
 --extra-cflags=-DCACA_STATIC --extra-cflags=-DMODPLUG_STATIC --extra-
 cflags=-DCHROMAPRINT_NODLL --extra-libs=-lstdc++ --extra-
 cflags=-DZMQ_STATIC --disable-w32threads --extra-cflags=-DPTW32_STATIC_LIB
 --extra-libs=-lpthread --extra-libs=-lwsock32 --extra-
 cflags=-DKVZ_STATIC_LIB --enable-version3 --enable-nonfree --enable-
 filter=frei0r --disable-debug
   libavutil  55. 61.100 / 55. 61.100
   libavcodec 57. 92.100 / 57. 92.100
   libavformat57. 72.100 / 57. 72.100
   libavdevice57.  7.100 / 57.  7.100
   libavfilter 6. 84.101 /  6. 84.101
   libswscale  4.  7.100 /  4.  7.100
   libswresample   2.  8.100 /  2.  8.100
   libpostproc54.  6.100 / 54.  6.100
 Input #0, gif, from '7GPW_LivingRoom.gif':
   Duration: N/A, bitrate: N/A
 Stream #0:0: Video: gif, bgra, 2432x1556, 100 tbr, 100 tbn, 100 tbc
 Stream mapping:
   Stream #0:0 (gif) -> scale
   scale -> Stream #0:0 (libx264)
 Press [q] to stop, [?] for help
 No pixel format specified, yuv444p for H.264 encoding chosen.
 Use -pix_fmt yuv420p for compatibility with outdated media players.
 [libx264 @ 004bc800] using cpu capabilities: MMX2 SSE2Fast SSSE3
 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
 [libx264 @ 004bc800] profile High 4:4:4 Predictive, level 5.2,
 4:4:4 8-bit
 [libx264 @ 004bc800] 264 - core 148 r2762 90a61ec - H.264/MPEG-4
 AVC codec - Copyleft 2003-2017 - http://www.videolan.org/x264.html -
 options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7
 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1
 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=4 threads=6
 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0
 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1
 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25
 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0
 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
 Output #0, mp4, to 'fc-out.mp4':
   Metadata:
 encoder : Lavf57.72.100
 Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv444p,
 2432x1556, q=-1--1, 100 fps, 12800 tbn, 100 tbc
 Metadata:
   encoder : Lavc57.92.100 libx264
 Side data:
   cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
 frame=  400 fps= 33 q=-1.0 Lsize= 937kB time=00:00:03.97
 bitrate=1932.9kbits/s dup=398 drop=0 speed=0.324x
 video:931kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
 muxing overhead: 0.589860%
 [libx264 @ 004bc800] frame I:2 Avg QP:19.71  size:443142
 [libx264 @ 004bc800] frame P:100   Avg QP:22.09  size:   292
 [libx264 @ 004bc800] frame B:298   Avg QP:30.84 

Re: [FFmpeg-trac] #6294(avfilter:open): gif frame delay dropped from last frame when scale filter is used

2017-04-11 Thread FFmpeg
#6294: gif frame delay dropped from last frame when scale filter is used
+
 Reporter:  okor|Owner:
 Type:  defect  |   Status:  open
 Priority:  normal  |Component:  avfilter
  Version:  git-master  |   Resolution:
 Keywords:  fps |   Blocked By:
 Blocking:  |  Reproduced by developer:  1
Analyzed by developer:  0   |
+

Comment (by okor):

 Would it help to start a bounty or donate? I really appreciate all the
 help.

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


Re: [FFmpeg-trac] #4437(avdevice:open): AVFoundation recording has consistent intermittent frame drops

2017-04-11 Thread FFmpeg
#4437: AVFoundation recording has consistent intermittent frame drops
-+-
 Reporter:  LordHDL  |Owner:  mateo
 Type:  defect   |   Status:  open
 Priority:  normal   |Component:  avdevice
  Version:  git-master   |   Resolution:
 Keywords:   |   Blocked By:
  avfoundation bounty|  Reproduced by developer:  1
 Blocking:   |
Analyzed by developer:  0|
-+-

Comment (by LordHDL):

 I wasn't aware at the time of posting this ticket, but I've recently
 learned about VFR, CFR, and how they relate to each other.  Based on my
 testing with other software, it seems I can only capture every frame
 properly when recording VFR, as CFR will guarantee that frames are lost as
 the sources in question (contrary to what I previously thought) are
 ''not'' a constant rate.  Their advertised rate is 60 but in practice the
 FPS always fluctuates, making CFR unreliable for recording.

 I believe recording with the native input frame rate as variable might be
 the solution (as it was in other software) but I haven't been able to test
 it.  I tried `-vsync 0` (input, output, and also both at once) but the
 resulting video is always considered constant.  How do I tell ffmpeg to
 use VFR for input (and really that should be the default behavior)?

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


Re: [FFmpeg-trac] #6302(ffmpeg:closed): gif frame delay dropped from last frame when output to webm

2017-04-11 Thread FFmpeg
#6302: gif frame delay dropped from last frame when output to webm
+-
 Reporter:  okor|Owner:
 Type:  defect  |   Status:  closed
 Priority:  important   |Component:  ffmpeg
  Version:  git-master  |   Resolution:  duplicate
 Keywords:  |   Blocked By:
 Blocking:  |  Reproduced by developer:  0
Analyzed by developer:  0   |
+-
Changes (by okor):

 * priority:  normal => important
 * component:  undetermined => ffmpeg


Comment:

 Thank you for responding : )

 I did find some other similar bug reports which mentioned `-vsync cfr` as
 a potential work around (for googlers: `ffmpeg -i input.gif -r 15 -vsync
 cfr ouput.webm` is what I used). But that only works if you know what your
 frame rate should be which we will not. We also don't want to make the
 video any larger in file size than it needs to be so the video should use
 the lowest frame rate it can for the content ... but if the gif is 60fps
 then that's what ffmpeg should do. It also takes between 5-24x time to
 process vs without a fixed frame rate ... as long as 48seconds for a 2
 frame source gif. In our case that won't work as we are using ffmpeg
 behind a web request.

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


Re: [FFmpeg-trac] #6306(undetermined:new): Wrong first frame using new decode API

2017-04-11 Thread FFmpeg
#6306: Wrong first frame using new decode API
-+-
 Reporter:  s0m3 |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  unspecified  |  undetermined
 Keywords:   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  1
-+-

Comment (by s0m3):

 The test case decodes and exports (as BMP files) all frames of the
 specified video file.
 The first exported frame is "0_834166.bmp" instead of "0_0.bmp".
 The second number "831466" is the pts in 100ns unit.

 I know from a dedicated software (elecard StreamEye) this is the pts of
 frame 3, not 1.

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


Re: [FFmpeg-trac] #6305(undetermined:new): Negative AVIndexEntry::timestamp value

2017-04-11 Thread FFmpeg
#6305: Negative AVIndexEntry::timestamp value
-+-
 Reporter:  s0m3 |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  unspecified  |  undetermined
 Keywords:   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  1
-+-

Comment (by s0m3):

 I forgot to say I tested it on windows with ffmpeg win32 build v3.2.4 and
 git snapshot 21070404-1229007.

 When running the sample, each AVIndexEntry::timestamp will be printed.
 You should see timestamp=-1024 for index entry 1 and timestamp=-512 for
 entry 2 which is, obviously wrong.

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


[FFmpeg-trac] #6305(undetermined:new): Negative AVIndexEntry::timestamp value

2017-04-11 Thread FFmpeg
#6305: Negative AVIndexEntry::timestamp value
-+-
 Reporter:  s0m3 | Type:  defect
   Status:  new  | Priority:  normal
Component:   |  Version:
  undetermined   |  unspecified
 Keywords:   |   Blocked By:
 Blocking:   |  Reproduced by developer:  1
Analyzed by developer:  0|
-+-
 I'm developping a multimedia player based on FFmpeg library.

 To do frame stepping, I need to associate frame numbers and frame times
 (timecodes).
 If AVStream::nb_index_entries is != 0, I use AVIndexEntry structure,
 otherwise, I build an "index" manually.

 I have a sample video (25fps, 60s, with timecode) where AVIndex entries
 are wrong.
 index_entries[0].timestamp and index_entries[1].timestamp are negative. In
 fact, all following timestamps are correct except there's an offset of 2
 so index_entries[10].timestamp is the correct timestamp of frame 8 not 10.

 I checked timestamp values with another dedicated software (elecard
 StreamEye) so ffmpeg is buggy here.

 Let me know if you need any information.

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


Re: [FFmpeg-trac] #6292(avfilter:new): overlay filter shortest doesn't work and ffmpeg hangs if 2nd input is longer

2017-04-11 Thread FFmpeg
#6292: overlay filter shortest doesn't work and ffmpeg hangs if 2nd input is
longer
-+-
 Reporter:  Gyan |Owner:
 Type:  defect   |   Status:  new
 Priority:  important|Component:  avfilter
  Version:  git-master   |   Resolution:
 Keywords:  overlay  |   Blocked By:
  regression |  Reproduced by developer:  0
 Blocking:   |
Analyzed by developer:  0|
-+-

Comment (by Gyan):

 **shortest=1** exhibits the same behaviour with the **haldclut**,
 **hstack** and **vstack** filters. The **blend** filter shows the same bug
 if the first input (the A or top video) is the shorter stream. If the 2nd
 input is shorter, ffmpeg displays "Error while filtering" but otherwise
 exits normally.

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


[FFmpeg-trac] #6304(undetermined:new): Unable to parse some subtitles with a system ffmpeg compiled HandBrake

2017-04-11 Thread FFmpeg
#6304: Unable to parse some subtitles with a system ffmpeg compiled HandBrake
-+-
 Reporter:  slaanesh | Type:  defect
   Status:  new  | Priority:  minor
Component:   |  Version:
  undetermined   |  unspecified
 Keywords:   |   Blocked By:
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
 Summary of the bug: Different behaviours with subtitles in HandBrake
 compiled with libav vs ffmpeg.

 As part of my daily usage, I've seen that HandBrake compiled with a system
 ffmpeg (unsupported by HandBrake) gives complete feature parity except for
 the parsing of UTF-8 subtitles in movie streams. Since Fedora defaults to
 ffmpeg, I'm trying to make it work with that.

 How to reproduce: Build HandBrake with the following patch applied:

 
https://github.com/negativo17/HandBrake/blob/master/cf1571f3bf314638a608784f19f80edb736e8144.patch

 To allow building HandBrake with a system installed ffmpeg and not its own
 bundled copy of libav. Behaviour is then different. I'm sure that there is
 something in the way that HandBrake uses libav for parsing the subtitles.
 Unfortunately the HandBrake developers are not interested in making the
 program work with anything but their libav bundle; so maybe someone here
 can shed some light.




 Importing a movie which has UTF-8 subtitles in a system ffmpeg compiled
 HandBrake, result in the subtitle stream not being available (like if it
 wasn't there):

 {{{
 [10:51:05] dvd: not a dvd - trying as a stream/file instead
 Input #0, matroska,webm, from '/home/slaanesh/Downloads/convert/Macross -
 Full/1.1 Macross II/Macross II Lovers Again/Macross II Lovers Again.mkv':
   Metadata:
 title   : Macross II: Lovers Again - Part 1
 encoder : libebml-0.7.5 & libmatroska-0.7.7
 creation_time   : 2010-09-01T18:03:39.00Z
   Duration: 02:17:03.90, start: 0.00, bitrate: 1393 kb/s
 Stream #0:0(Macross II: Lovers Again - Part 1): Video: mpeg4 (DX50 /
 0x30355844), yuv420p, 640x480 [SAR 1:1 DAR 4:3], 23.98 fps, 23.98 tbr, 1k
 tbn, 30k tbc (default)
 Metadata:
   SUBJECT : www.anime-legion.net
   COMPOSER: Nicholi
   COPYRIGHT   : #anime-leg...@mircx.com
   LANGUAGE: Macross II: Lovers Again - Part 1
 Stream #0:1(eng): Audio: vorbis, 48000 Hz, stereo, fltp (default)
 Stream #0:2(jpn): Audio: vorbis, 48000 Hz, stereo, fltp
 Stream #0:3(eng): Subtitle: subrip (default)
 [10:51:05] add_ffmpeg_subtitle: unknown subtitle stream type: 0x17808
 }}}

 Doing the same with a bundled libav compiled HandBrake allows the subtitle
 stream to be parsed correctly:

 {{{
 [10:29:12] dvd: not a dvd - trying as a stream/file instead
 Input #0, matroska,webm, from '/home/slaanesh/Downloads/convert/Macross -
 Full/1.1 Macross II/Macross II Lovers Again/Macross II Lovers Again.mkv':
   Metadata:
 title   : Macross II: Lovers Again - Part 1
   Duration: 02:17:03.89, start: 0.00, bitrate: N/A
 Stream #0:0(Macross II: Lovers Again - Part 1): Video: mpeg4 (Simple
 Profile) [DX50 / 0x30355844]
   yuv420p, 640x480 [PAR 1:1 DAR 4:3], PAR 1:1 DAR 4:3
   23.98 fps, 1k tbn (default)
 Metadata:
   SUBJECT : www.anime-legion.net
   COMPOSER: Nicholi
   COPYRIGHT   : #anime-leg...@mircx.com
   LANGUAGE: Macross II: Lovers Again - Part 1
 Stream #0:1(eng): Audio: vorbis
   48000 Hz, stereo, fltp (default)
 Stream #0:2(jpn): Audio: vorbis
   48000 Hz, stereo, fltp
 Stream #0:3(eng): Subtitle: srt (default)
 }}}

 If I convert the video with the system ffmpeg skipping HandBrake the
 subtitle stream is manipulated correctly:

 {{{
 $ ffmpeg -v verbose -i Macross\ II\ Lovers\ Again.mkv -strict experimental
 -ac 2 -c:a aac -c:v hevc_nvenc -preset medium output.mkvffmpeg version
 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers
   built with gcc 6.3.1 (GCC) 20161221 (Red Hat 6.3.1-1)
   configuration: --arch=x86_64 --bindir=/usr/bin
 --datadir=/usr/share/ffmpeg --disable-debug --disable-static --disable-
 stripping --enable-avfilter --enable-avresample --enable-bzlib --enable-
 cuda --enable-cuvid --enable-libnpp --enable-doc --enable-fontconfig
 --enable-frei0r --enable-gnutls --enable-gpl --enable-iconv --enable-
 libass --enable-libbluray --enable-libcdio --enable-libdc1394 --enable-
 libebur128 --enable-libfdk-aac --enable-libfreetype --enable-libfribidi
 --enable-libgsm --enable-libkvazaar --enable-libmfx --enable-libmp3lame
 --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264
 --enable-libopenjpeg --enable-libopus --enable-libpulse