Re: [FFmpeg-trac] #7160(avformat:new): hls fmp4 http upload - user agent and http method not respected for fmp4-segments

[FFmpeg]

#7160: hls fmp4 http upload - user agent and http method not respected for
fmp4-segments
-+-
 Reporter:  nitrat   |Owner:
 Type:  defect   |   Status:  new
 Priority:  important|Component:  avformat
  Version:  git-master   |   Resolution:
 Keywords:  hls fmp4 |   Blocked By:
  http upload|  Reproduced by developer:  0
 Blocking:   |
Analyzed by developer:  0|
-+-

Comment (by stevenliu):

 try the patch please: https://patchwork.ffmpeg.org/patch/8682/
 {{{
 ./ffmpeg -re -i ~/Movies/objectC/facebook.mp4 -c:v h264_videotoolbox -g 50
 -r:v 25 -f hls -v verbose -method PUT -hls_time 2 -hls_segment_type fmp4
 -hls_list_size 3 -hls_flags delete_segments
 http://127.0.0.1/output_test_liuqi.m3u8
 }}}

 in http server:


 {{{
 liuqideMacBook-Pro:custom_ffmpeg liuqi$ ls
 /usr/local/nginx/html/output_test_liuqi* /usr/local/nginx/html/*.mp4
 /usr/local/nginx/html/init.mp4
 /usr/local/nginx/html/output_test_liuqi.m3u8
 /usr/local/nginx/html/output_test_liuqi4.m4s
 /usr/local/nginx/html/output_test_liuqi5.m4s
 /usr/local/nginx/html/output_test_liuqi6.m4s
 liuqideMacBook-Pro:custom_ffmpeg liuqi$
 }}}

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

Re: [FFmpeg-trac] #6156(avdevice:reopened): Issue with FFMPEG ALSA CPU usage

[FFmpeg]

#6156: Issue with FFMPEG ALSA CPU usage
+
 Reporter:  mushm0m |Owner:
 Type:  defect  |   Status:  reopened
 Priority:  normal  |Component:  avdevice
  Version:  git-master  |   Resolution:
 Keywords:  alsa|   Blocked By:
 Blocking:  |  Reproduced by developer:  0
Analyzed by developer:  0   |
+

Comment (by kainz):

 So after having done some profiling runs on ffmpeg, I think it's just
 ffmpeg's processing loop causing most of the cpu use in this case, via
 smaller buffers (but large enough to make malloc/free expensive) and an
 accordingly larger amount of allocations.

 I added some debugging code to print the selected ALSA pcm hw buffer size,
 and compared profiling runs between ffmpeg with alsa-direct and ffmpeg
 with alsa-jack.  What happens is on the raspberrypi hardware, the i2s/pcm
 input has a 128KB buffer, and ffmpeg ends up allocating/deallocating this
 on every frame.  For comparison, the alsapulse plugin ends up using a 1MB
 buffer, but provides larger frames, so the allocations dont happen as
 often.

 Given all of the interactions above, I'm not really sure how best to
 mitigate this, and my usecase was aggravated by trying to combine the
 above with a concurrent v4l2 capture, which has proven challenging for
 other people with ffmpeg in the past.

 If the above behavior is considered a design bug, I suppose I could help
 find and/or test a solution to it, but I think the fix would end up going
 deep into the ffmpeg/libavcodec/transcoding code base, probably more than
 is comfortable.  Otherwise, I suppose this is really an unfortunate
 sideeffect of the hardware implementation.

 An easy mitigation could be to add a commandline argument(s?) to tell the
 alsa demuxer to limit the buffer(or periods etc) sizes to better match the
 platform vs what the drivers report as the maximum permissible values.

 Thoughts?

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

Re: [FFmpeg-trac] #7169(undetermined:new): First chapter of MP4 is always at 0.0

[FFmpeg]

#7169: First chapter of MP4 is always at 0.0
-+-
 Reporter:  jonata   |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  unspecified  |  undetermined
 Keywords:  mov  |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-
Changes (by cehoyos):

 * keywords:  chapters => mov
 * version:  3.4 => unspecified
 * component:  ffmpeg => undetermined


Comment:

 Please confirm that the issue is reproducible with current FFmpeg git head
 (nothing else is supported here) and provide the command line that allows
 to reproduce the issue together with the complete, uncut console output.

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

Re: [FFmpeg-trac] #7170(undetermined:closed): FFmpeg 4.0 has been released but git master is still tagged as n3.5-dev

[FFmpeg]

#7170: FFmpeg 4.0 has been released but git master is still tagged as n3.5-dev
-+-
 Reporter:   |Owner:
  peterbennett   |   Status:  closed
 Type:  defect   |Component:
 Priority:  normal   |  undetermined
  Version:  git-master   |   Resolution:  fixed
 Keywords:   |   Blocked By:
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
Changes (by cehoyos):

 * status:  new => closed
 * resolution:   => fixed


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

[FFmpeg-trac] #7170(undetermined:new): FFmpeg 4.0 has been released but git master is still tagged as n3.5-dev

[FFmpeg]

#7170: FFmpeg 4.0 has been released but git master is still tagged as n3.5-dev
-+-
 Reporter:   | Type:  defect
  peterbennett   | Priority:  normal
   Status:  new  |  Version:  git-
Component:   |  master
  undetermined   |   Blocked By:
 Keywords:   |  Reproduced by developer:  0
 Blocking:   |
Analyzed by developer:  0|
-+-
 Summary of the bug:
 How to reproduce:
 {{{
 % git checkout master
 % git describe
 n3.5-dev-3076-g92a0a6b
 }}}

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

Re: [FFmpeg-trac] #7169(ffmpeg:new): First chapter of MP4 is always at 0.0 (was: First chapter of MP4 is always 0)

[FFmpeg]

#7169: First chapter of MP4 is always at 0.0
--+--
 Reporter:  jonata|Owner:
 Type:  defect|   Status:  new
 Priority:  normal|Component:  ffmpeg
  Version:  3.4   |   Resolution:
 Keywords:  chapters  |   Blocked By:
 Blocking:|  Reproduced by developer:  0
Analyzed by developer:  0 |
--+--

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

[FFmpeg-trac] #7169(ffmpeg:new): First chapter of MP4 is always 0

[FFmpeg]

#7169: First chapter of MP4 is always 0
--+--
 Reporter:  jonata| Type:  defect
   Status:  new   | Priority:  normal
Component:  ffmpeg|  Version:  3.4
 Keywords:  chapters  |   Blocked By:
 Blocking:|  Reproduced by developer:  0
Analyzed by developer:  0 |
--+--
 Summary of the bug: MP4 files produced on ffmpeg with chapter marks being
 applied using ffmetadata always have the first chapter at 0.0

 How to reproduce:

 Test movie file:
 https://archive.org/download/mov-bbb/mov_bbb.mp4

 Chapters information (chapters.txt):
 {{{
 ;FFMETADATA1

 [CHAPTER]
 START=215300
 END=31
 title=First chapter should start at 2 sec

 [CHAPTER]
 START=31
 END=555000
 title=Second chapter

 [CHAPTER]
 START=555000
 END=865360
 title=Final chapter
 }}}


 Applying chapters
 {{{
 ffmpeg -i mov_bbb.mp4 -i chapters.txt -map_chapters 1 -c:a copy -c:v copy
 mov_bbb_with_chapters.mp4
 }}}

 or even specifying Apple text
 {{{
 ffmpeg -i mov_bbb.mp4 -i chapters.txt -map_chapters 1 -c:a copy -c:v copy
 -c:s mov_text mov_bbb_with_chapters.mp4
 }}}

 returns this output, confirming it is understanding the first chapter as
 2sec:
 {{{
 ...
 Chapter #0:0: start 2.153000, end 3.10
 Metadata:
   title   : First chapter should start at 2 sec
 ...
 }}}

 but running ffprobe -show_chapters:
 {{{
 ffprobe -show_chapters mov_bbb_with_chapters.mp4
 }}}

 confirms that in some way ffmpeg is setting the first chapter as 0.0:
 {{{
 ...
 Chapter #0:0: start 0.00, end 3.10
 Metadata:
   title   : First chapter should start at 2 sec
 ...
 [CHAPTER]
 id=0
 time_base=1/1000
 start=0
 start_time=0.00
 end=3100
 end_time=3.10
 TAG:title=First chapter should start at 2 sec
 [/CHAPTER]
 ...
 }}}

 VLC reads the correct information (it shows the first chapter correctly).
 Other players like MPV, MPC, QT, reads it as 0.0.

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

Re: [FFmpeg-trac] #7132(avfilter:new): Add threading capabilities to overlay filter

[FFmpeg]

#7132: Add threading capabilities to overlay filter
-+
 Reporter:  zerodefect   |Owner:
 Type:  enhancement  |   Status:  new
 Priority:  wish |Component:  avfilter
  Version:  git-master   |   Resolution:
 Keywords:  overlay  |   Blocked By:
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+

Comment (by richardpl):

 Threading will not help much, unless you have bunch of cores, SIMD will
 help much more.

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

Re: [FFmpeg-trac] #5366(avfilter:open): Support for Audio Filtering of Core Audio of OSX

[FFmpeg]

#5366: Support for Audio Filtering of Core Audio of OSX
-+-
 Reporter:  ponpon   |Owner:
 Type:  enhancement  |   Status:  open
 Priority:  wish |Component:  avfilter
  Version:  git-master   |   Resolution:
 Keywords:   |   Blocked By:
  audiotoolbox osx   |  Reproduced by developer:  0
 Blocking:   |
Analyzed by developer:  0|
-+-

Comment (by richardpl):

 I fail to see how that would be good addition.

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

Re: [FFmpeg-trac] #7066(avfilter:new): Video filter enhancement: fieldhint

[FFmpeg]

#7066: Video filter enhancement: fieldhint
-+
 Reporter:  ssp43|Owner:
 Type:  enhancement  |   Status:  new
 Priority:  wish |Component:  avfilter
  Version:  unspecified  |   Resolution:
 Keywords:  fieldhint|   Blocked By:
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+

Comment (by richardpl):

 Do you have short sample where this would be useful?

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

Re: [FFmpeg-trac] #7168(undetermined:closed): Making xdcam hd422 file (compatible to sony devices) from ffmpeg

[FFmpeg]

#7168: Making xdcam hd422 file (compatible to sony devices) from ffmpeg
-+-
 Reporter:  vimlesh1975  |Owner:
 Type:  defect   |   Status:  closed
 Priority:  normal   |Component:
  Version:  unspecified  |  undetermined
 Keywords:   |   Resolution:  duplicate
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-
Changes (by cehoyos):

 * status:  new => closed
 * type:  enhancement => defect
 * component:  ffmpeg => undetermined
 * version:  3.4 => unspecified
 * keywords:  xdcam hd422 =>
 * resolution:   => duplicate


Comment:

 Duplicate of ticket #5097. Please remember that only current FFmpeg git
 head is supported here.

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