Recherche avancée

Sur d’autres sites (9001)

• FFMPEG “buffer queue overflow, dropping.” while filter_complex concating

  8 août 2019, par March3April4

  I’m using the below command to concat several videos to a single video.

  ffmpeg -i /storage/emulated/0/Cache/1565235095822.mp4
  
  -i /storage/emulated/0/Cache/1565235097989.mp4
  
  -i /storage/emulated/0/Cache/1565235099167.mp4 
  
  -i /storage/emulated/0/Cache/1565235100276.mp4
  
  -i /storage/emulated/0/Cache/1565235096982.mp4
  
  -filter_complex [0:v:0] [0:a:0] [1:v:0] [1:a:0] [2:v:0] [2:a:0] [3:v:0] [3:a:0] [4:v:0] [4:a:0] concat=n=5:v=1:a=1 [v] [a]
  
  -map [v]
  
  -map [a]
  
  -max_muxing_queue_size 9999
  
  -preset ultrafast
  
  /storage/emulated/0/Cache/1565235101418.mp4

  The input videos are also made by ffmpeg, and are about 1 megabyte big. (Each consists of a single picture and an audio)

  The above command line works well for mainstream devices such as galaxy s10 series, but for models like Lg K10, the below line appears.

  [Parsed_concat_0 @ 0xb9ab05a0] Buffer queue overflow, dropping.

  The encoding does not stop even though the above line shows up, but the result video contains some time skips and missing audio.

  I assumed that this has to do with performance of the device itself, so, I tried to do the job without encoding. I’ve tried the concat demuxer with no luck.

  What else can I try to make this to work ? Any help will be thankful.

  ------------------Edit-------------------------

  The ffmpeg videos are create by the following command.

          String[] array = {
  
                   "-framerate", "1",
  
                  "-i", "targetVideo.png",
  
                  "-i", "targetAudio.mp3",
  
                  "-r", "14",
  
                  "-c:v", "libx264",
  
                  "-c:a", "aac",
  
                  "-pix_fmt", "yuv420p",
  
                  "-video_track_timescale", "90000",
  
                  "-c:a", "copy",
  
                  outputPath.mp4};

• FFMPEG Incompatible sprop-parameter-sets with libstagefright on Android 4.0 for H264

  7 août 2012, par user1582384

  I am having an issue with the RTSP SDP generated by FFMPEG in Android.
  I have the FFMPEG 0.11.1 compiled with NDK and running on Android. I use the FFSERVER to stream an mp4 file locally to the MediaPlayer.

  Here is the generated SDP description :

  08-07 14:04:04.034 : V/rtsp_server(20161) : o=- 0 0 IN IP4 127.0.0.1

  08-07 14:04:04.034 : V/rtsp_server(20161) : s=No Title

  08-07 14:04:04.034 : V/rtsp_server(20161) : c=IN IP4 0.0.0.0

  08-07 14:04:04.034 : V/rtsp_server(20161) : t=0 0

  08-07 14:04:04.034 : V/rtsp_server(20161) : a=tool:libavformat 54.6.100

  08-07 14:04:04.034 : V/rtsp_server(20161) : m=video 0 RTP/AVP 96

  08-07 14:04:04.034 : V/rtsp_server(20161) : b=AS:312

  08-07 14:04:04.034 : V/rtsp_server(20161) : a=x-dimensions:512,384

  08-07 14:04:04.034 : V/rtsp_server(20161) : a=rtpmap:96 H264/90000

  08-07 14:04:04.034 : V/rtsp_server(20161) : a=fmtp:96
  packetization-mode=0 ;profile-level-id=640015 ;sprop-parameter-sets=J2QAH62ECSZuIzSQgSTNxGaSECSZuIzSQgSTNxGaSECSZuIzSQgSTNxGaSEFWuvX1+T+vyfXrrVQgq116+vyf1+T69daq0BAGMg=,KO48sA==

  08-07 14:04:04.034 : V/rtsp_server(20161) : a=control:streamid=0

  08-07 14:04:04.034 : V/rtsp_server(20161) : m=audio 0 RTP/AVP 97

  08-07 14:04:04.034 : V/rtsp_server(20161) : b=AS:29

  08-07 14:04:04.034 : V/rtsp_server(20161) : a=rtpmap:97
  MPEG4-GENERIC/44100/1

  08-07 14:04:04.034 : V/rtsp_server(20161) : a=fmtp:97
  profile-level-id=1 ;mode=AAC-hbr ;sizelength=13 ;indexlength=3 ;indexdeltalength=3 ;
  config=1208

  08-07 14:04:04.034 : V/rtsp_server(20161) : a=control:streamid=1

  Running the same application on Galaxy S2 works since it uses libopencore. But on newer devices it crashes while trying to extract the width and height from the extradata.

  So the problem is with the sprop-parameter-sets.

  My question is why does libstagefright parse the sprop-parameter-sets differently and how could the existing string be converted for compatibility ?

• Interfacing to an Xbox Optical Drive

  1er octobre 2013, par Multimedia Mike — xbox

  The next generation Xbox is going to hit the streets soon. But for some reason, I’m still interested in the previous generation’s unit (i.e., the original Xbox). Specifically, I’ve always wondered if it’s possible to use the original Xbox’s optical drive in order to read Xbox discs from Linux. I was never curious enough to actually buy an Xbox just to find out but I eventually came across a cast-off console on a recycle pile.

  I have long known that the Xbox has what appears to be a more or less standard optical drive with a 40-pin IDE connector. The only difference is the power adapter which I surmise is probably the easiest way to turn a bit of standardized hardware into a bit of proprietary hardware. The IDE and power connectors look like this :

  
  
  

  Thus, I wanted to try opening an Xbox and plugging the optical drive into a regular PC, albeit one that supports IDE cables, and allow the Xbox to supply power to the drive. Do you still have hardware laying around that has 40-pin IDE connectors ? I guess my Mac Mini PPC fits the bill, but I’ll be darned if I’m going to pry that thing open again. I have another IDE-capable machine buried in my closet, last called into service when I needed a computer with a native RS-232 port 3 years ago. The ordeal surrounding making this old computer useful right now can be another post entirely.

  Here’s what the monstrosity looks like thanks to characteristically short IDE cable lengths :

  
  

  

  Click for larger image

  
  

  Process :

  1. Turn on Xbox first
  2. Turn on PC

  Doing these things in the opposite order won’t work since the kernel really wants to see the drive when booting up. Inspecting the 'dmesg' log afterward reveals interesting items :
  

  <br />
hdd: PHILIPS XBOX DVD DRIVE, ATAPI CD/DVD-ROM drive<br />
hdd: host max PIO5 wanted PIO255(auto-tune) selected PIO4<br />
hdd: UDMA/33 mode selected<br />
[...]<br />
hdd: ATAPI DVD-ROM drive, 128kB Cache<br />

  Why is that interesting ? When is the last time to saw disk devices prefixed by ‘hd’ rather than ‘sd’ ? Blast from the past. Oh, and the optical drive’s vendor string clearly indicates that this is an Xbox drive saying ‘hi !’.

  Time To Read
  When I first studied an Xbox disc in a normal optical drive, I noticed that I was able to read 6992 2048-byte sectors — about 14 MB of data — as reported by the disc table of contents (TOC). This is just enough data to play a standard DVD video animation that kindly instructs the viewer to please use a proper Xbox. At this point, I estimated that there must be something special about Xbox optical drive firmware that knows how to read alternate information on these discs and access further sectors.

  I ran my TOC query tool with an Xbox Magazine demo disc in the optical drive and it reported substantially more than 6992 sectors, enough to account for more than 2 GB of data. That’s promising. I then tried running 'dd' against the device and it was able to read… about 14 MB, an exact quantity of bytes that, when divided by 2048 bytes/sector, yields 6992 sectors.

  Future (Past ?) Work
  Assuming Google is your primary window into the broader internet, the world is beginning to lose its memory of things pertaining to the original Xbox (Microsoft’s naming scheme certainly doesn’t help searches). What I’m saying is that it can be difficult to find information about this stuff now. However, I was able to learn that a host needs to perform a sort of cryptographic handshake with the drive at the SCSI level before it is allowed to access the forbidden areas of the disc. I think. I’m still investigating this and will hopefully post more soon.