FFmpeg | 23 Oct 23:34 2014

Re: #3339(undetermined:open): Remuxing m2ts to mkv, Can't write packet with unknown timestamp

#3339: Remuxing m2ts to mkv,  Can't write packet with unknown timestamp
-------------------------------------+-------------------------------------
             Reporter:  Selur        |                    Owner:
                 Type:  defect       |                   Status:  open
             Priority:  important    |                Component:
              Version:  git-master   |  undetermined
             Keywords:               |               Resolution:
  av_interleaved_write_frame h264    |               Blocked By:
  regression                         |  Reproduced by developer:  1
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Changes (by cehoyos):

 * cc: peter_b (added)

Comment:

  <at> peter_b: Thank you for testing!
 Can you provide a short sample?

--
Ticket URL: <https://trac.ffmpeg.org/ticket/3339#comment:9>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
FFmpeg | 23 Oct 19:24 2014

Re: #3339(undetermined:open): Remuxing m2ts to mkv, Can't write packet with unknown timestamp

#3339: Remuxing m2ts to mkv,  Can't write packet with unknown timestamp
-------------------------------------+-------------------------------------
             Reporter:  Selur        |                    Owner:
                 Type:  defect       |                   Status:  open
             Priority:  important    |                Component:
              Version:  git-master   |  undetermined
             Keywords:               |               Resolution:
  av_interleaved_write_frame h264    |               Blocked By:
  regression                         |  Reproduced by developer:  1
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by peter_b):

  <at> cehoyos:
 I've reverted back to N-57590-ge166b82 (=one before 4eb49fdd), and there
 it works as expected.
 The resulting MKV file plays fine and audio/video is in-sync. Even after
 seeking.

 Complete, uncut commandline and console output:

 '''Old version:'''
 {{{
 =======================
 $ ffmpeg -fflags +genpts -i 00534.MTS -c copy output.mkv
 -----------------------
 ffmpeg version N-57590-ge166b82 Copyright (c) 2000-2013 the FFmpeg
 developers
(Continue reading)

FFmpeg | 23 Oct 19:15 2014

#4055(ffmpeg:new): MP3 encoding bitrates go above 320Kbps

#4055: MP3 encoding bitrates go above 320Kbps
-------------------------------------+-------------------------------------
             Reporter:  fidalgo      |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:  ffmpeg       |                  Version:  2.1.5
             Keywords:  mp3          |               Blocked By:
  encoding bitrate                   |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Summary of the bug: When I encode an mp3 using the guide in documentation,
 I'll get frames with bitrate higher than 320Kbps.
 How to reproduce:
 {{{
 % ffmpeg -i 2L38_01_96kHz.flac -codec:a libmp3lame -qscale:a 0
 2L38_01_96kHz.mp3
 }}}

 The file used is from here:
 http://www.lindberg.no/hires/test/2L38_01_96kHz.flac

 I'm using ffmpeg from rpm-fusion in Fedora 20:

 {{{
  ffmpeg version 2.1.5 Copyright (c) 2000-2014 the FFmpeg developers
   built on Jul  8 2014 20:44:17 with gcc 4.8.3 (GCC) 20140624 (Red Hat
 4.8.3-1)
   configuration: --prefix=/usr --bindir=/usr/bin
 --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg
 --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags='-O2
(Continue reading)

FFmpeg | 23 Oct 13:21 2014

#4054(avformat:new): libavformat: subtitles: provide a mechanism to guess subtitle character encoding

#4054: libavformat: subtitles: provide a mechanism to guess subtitle character
encoding
-----------------------------------+---------------------------------------
             Reporter:  11rcombs   |                     Type:  enhancement
               Status:  new        |                 Priority:  wish
            Component:  avformat   |                  Version:  git-master
             Keywords:  subtitles  |               Blocked By:
             Blocking:             |  Reproduced by developer:  0
Analyzed by developer:  0          |
-----------------------------------+---------------------------------------
 Sometimes, especially when ffmpeg is being called programmatically, it is
 difficult or impossible for the caller (or user) to know the character
 encoding of a subtitle file. It'd be useful for libavformat to provide a
 mechanism to detect the encoding if an option is set, using some
 combination of universalchardet, enca, or libguess.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4054>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
FFmpeg | 23 Oct 06:30 2014

Re: #2263(avformat:reopened): Read second SeekHead in Matroska files

#2263: Read second SeekHead in Matroska files
-------------------------------------+-------------------------------------
             Reporter:  eelco        |                    Owner:
                 Type:  enhancement  |                   Status:  reopened
             Priority:  wish         |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:  mkv h264     |               Blocked By:
  bounty                             |  Reproduced by developer:  1
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Changes (by 11rcombs):

 * cc: rodger.combs <at> … (added)

--
Ticket URL: <https://trac.ffmpeg.org/ticket/2263#comment:15>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac <at> avcodec.org
http://avcodec.org/mailman/listinfo/ffmpeg-trac
FFmpeg | 23 Oct 01:49 2014

Re: #2263(avformat:reopened): Read second SeekHead in Matroska files

#2263: Read second SeekHead in Matroska files
-------------------------------------+-------------------------------------
             Reporter:  eelco        |                    Owner:
                 Type:  enhancement  |                   Status:  reopened
             Priority:  wish         |                Component:  avformat
              Version:  git-master   |               Resolution:
             Keywords:  mkv h264     |               Blocked By:
  bounty                             |  Reproduced by developer:  1
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Changes (by 11rcombs):

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

Comment:

 Not quite. {{{a3920181}}} is a partial fix that solves a more serious
 problem when {{{-copyts}}} or {{{-c copy}}} are used (wherein the seek
 operation previously would have no effect, and now proceeds somewhat
 slowly). I have a patch on the ML that fixes this slow-seeking issue
 caused by failure to read the second SeekHead, but it hasn't been applied
 yet because we need to double-check some edge cases first.
 Oh, and a3920181 may speed up seeking in these files, but not by as much
 as reading the second SeekHead would.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/2263#comment:14>
FFmpeg <https://ffmpeg.org>
(Continue reading)

FFmpeg | 23 Oct 00:49 2014

Re: #2263(avformat:closed): Read second SeekHead in Matroska files

#2263: Read second SeekHead in Matroska files
-------------------------------------+-------------------------------------
             Reporter:  eelco        |                    Owner:
                 Type:  enhancement  |                   Status:  closed
             Priority:  wish         |                Component:  avformat
              Version:  git-master   |               Resolution:  fixed
             Keywords:  mkv h264     |               Blocked By:
  bounty                             |  Reproduced by developer:  1
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Changes (by cehoyos):

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

Comment:

 Fixed by Michael in a3920181

--
Ticket URL: <https://trac.ffmpeg.org/ticket/2263#comment:13>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
FFmpeg | 22 Oct 09:29 2014

#4054(undetermined:new): Stair Lifts - A Cost-Effective Way Of Getting Your Freedom Of Movement Back

#4054: Stair Lifts - A Cost-Effective Way Of Getting Your Freedom Of Movement Back
-------------------------------------+-------------------------------------
             Reporter:               |                     Type:  defect
  jospehgonzalez                     |                 Priority:  normal
               Status:  new          |                  Version:
            Component:               |  unspecified
  undetermined                       |               Blocked By:
             Keywords:               |  Reproduced by developer:  0
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Wheelchair lifts, also known as lifting lifts, are definitely the stair
 lifts for wheelchairs. These wheelchair consumers can negotiate stairs
 while not having to leave the wheelchair. At this time you'll examine what
 to search for when paying for a wheelchair lift. Make sure you read
 through assessment for Benefits of Stair Lifts from http://treppenlifte-
 welt.de. An overview on the subject of wheelchair lifts. Like stair lifts,
 widespread, there's also wheelchair lifts in several various designs and
 versions. The sole widespread aspect in all models will be the platform.
 Wheelchair lifts can be found in a variety of designs; they all have in
 typical the gear that has a solitary platform. Our enterprise devoted into
 the elimination of architectural boundaries by setting up stair lifts and
 detached. This internet site is devoted entirely to stair lifts, carry
 chairs also referred to as climbing stairs or chairs. Ladders chair curved
 portion, moveable stair raise stair raise chairs or climbing stairs and
 pool. We are going to generally be shut for you, both inside the option of
 your lifting tools and soon after set up. We've got brokers and
 organization advisors who will guidebook you to definitely make you really
 feel as safe and sound as possible throughout the process. Why we provide
 the most beneficial customer care to our clients. We now have speci <at> lised
(Continue reading)

FFmpeg | 22 Oct 01:52 2014

#4053(swscale:new): Scaling bayer crashes libswscale

#4053: Scaling bayer crashes libswscale
-------------------------------------+-------------------------------------
               Reporter:  cehoyos    |                  Owner:
                   Type:  defect     |                 Status:  new
               Priority:  important  |              Component:  swscale
                Version:  git-       |               Keywords:  crash
  master                             |  SIGSEGV
             Blocked By:             |               Blocking:
Reproduced by developer:  0          |  Analyzed by developer:  0
-------------------------------------+-------------------------------------
 {{{
 $ valgrind ./ffmpeg_g -cpuflags 0 -f rawvideo -s pal -pix_fmt
 bayer_rggb16le -i /dev/zero -s cif -f null -
 ==3875== Memcheck, a memory error detector
 ==3875== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
 ==3875== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
 ==3875== Command: ./ffmpeg_g -cpuflags 0 -f rawvideo -s pal -pix_fmt
 bayer_rggb16le -i /dev/zero -s cif -f null -
 ==3875==
 ffmpeg version N-67086-gdd3f156 Copyright (c) 2000-2014 the FFmpeg
 developers
   built on Oct 22 2014 00:56:03 with gcc 4.7 (SUSE Linux)
   configuration: --enable-gpl
   libavutil      54. 10.100 / 54. 10.100
   libavcodec     56.  8.102 / 56.  8.102
   libavformat    56.  9.101 / 56.  9.101
   libavdevice    56.  1.100 / 56.  1.100
   libavfilter     5.  2.100 /  5.  2.100
   libswscale      3.  1.101 /  3.  1.101
   libswresample   1.  1.100 /  1.  1.100
(Continue reading)

FFmpeg | 21 Oct 18:55 2014

#4052(undetermined:new): Memory leak in FFmpeg within iFFmpeg app for Mac OS X

#4052: Memory leak in FFmpeg within iFFmpeg app for Mac OS X
-------------------------------------+-------------------------------------
             Reporter:  erics72      |                     Type:  task
               Status:  new          |                 Priority:  important
            Component:               |                  Version:
  undetermined                       |  unspecified
             Keywords:  memory leak  |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Hi, I use iFFmpeg for video/audio file conversions, which uses the binary
 FFmpeg.  I've been noticing for sometime now that iFFmpeg would eat up a
 lot of my free memory on my Mac Pro.  I would have to quit the app, or
 sometimes restart my computer to get what it used up.

 I contacted iFFmpeg, about a possible memory leak in their app, and if
 there was a way to automatically purge it after the completion of
 transcoding.  They tell me that iFFmpeg doesn't have any memory leaks.
 Except for the 0.05% from Apple diagnostics.  But they did tell me that
 FFmpeg has memory leak issues, and to contact you guys to report this bug.

 Not sure if you are aware.  Is this an unresolved on-going issue, or will
 there be a bug fix in near future binary updates?  Or is there a
 workaround I can do to help/fix the memory leak?

 Not sure what version of the binary I have.  I'm guessing it's the latest
 one.  I checked a month ago, and realized I didn't need to download it.

 Much appreciated.

(Continue reading)

FFmpeg | 21 Oct 16:49 2014

#4051(avformat:new): Assertion error in mux.c with a slow input

#4051: Assertion error in mux.c with a slow input
-------------------------------------+-------------------------------------
               Reporter:  ubitux     |                  Owner:
                   Type:  defect     |                 Status:  new
               Priority:  important  |              Component:  avformat
                Version:             |               Keywords:  mux assert
  unspecified                        |  regression
             Blocked By:             |               Blocking:
Reproduced by developer:  0          |  Analyzed by developer:  0
-------------------------------------+-------------------------------------
 A bit tricky to trigger, I wasn't able to simplify any further. Here is
 the first python script you'll need:

 {{{
 ☭ cat <<EOF > /tmp/feed.py
 import sys, time

 fifo = open(sys.argv[1], 'wb')
 frame = '\x00' * (320*240*3)
 framecount = 0
 for i in range(1000):
     print 'write frame #%d' % framecount
     fifo.write(frame)
     framecount += 1
     time.sleep(.1)
 EOF
 }}}

 Create the video FIFO:
 {{{
(Continue reading)


Gmane