Recherche avancée

Sur d’autres sites (6757)

• Android ffmpeg save and append h264 streamed videos

  8 octobre 2012, par Stefan Alexandru

  I need to save a video file generated by two video streams coming from two different sources. I'm using rtsp over tcp/ip, and the videos are encoded with h264.
  I need to first record the video from the first source and than continue with the second source.
  So what I tried was to declare two AVFormatContext instances, initialize both with avformat_open_input(&context, "rtsp://......",NULL,&options)
  and then read frames with av_read_frame(context,&packet)
  and write them in the video file av_write_frame(oc,&packet);
  It works fine saving the video from the first source, but if by example I saved y frames from the first context, when I try reading and saving the frames from the second context in the same file, for the first y frames I am tring to save, av_write_frame(oc,&packet2);
  would retun -22, and would not add the frame to the file.

  I think the problem is that the context variable remembers how many frames were read, and it gives every read packet an identification number, to make sure it isn't written twice. But when I'm using a new context those identification numbers reset, the AVOutputFormat or the AVFormatContext also retain the id of the package they are expecting to receive, and would not write anything until they receive a package with that id.
  Now I'm wondering how could I solve this inconvenience. I can't find any setter for that id, or any way to reuse the same context. I thought to modify the ffmpeg sources but they are pretty complex and I couldn't find what I was looking for.
  An alternative would be to save the two video in two different files but, I don't know how to append them afterwards, as ffmpeg can only append videos encoded with mpeg and rencoding the video isn't really an option, as it will take to much time. Also I couldn't find any other functional way to append two mp4 videos encoded with h264.

  I'll be happy to hear any kind of usable ideea to this problem.

• Revision a766d8918e : Cleanup inside vp9_reconinter.c. Using block width and block height instead of

  8 août 2013, par Dmitry Kovalev

  Changed Paths :
   Modify /vp9/common/vp9_reconinter.c

  
  
  Cleanup inside vp9_reconinter.c.

  Using block width and block height instead of their logarithms. Using
  SUBPEL_BITS and SUBPEL_SHIFTS constants instead of magic numbers.

  Change-Id : I4e10e93c907c8a5e1cb27dfe74d1fcdcc4995448

• Revision fd44975bc8 : Make Rand8Extremes more extreme Previous code didn't do what was expected, we w

  19 avril 2013, par John Koleszar

  Changed Paths :
   Modify /test/acm_random.h

  
  
  Make Rand8Extremes more extreme

  Previous code didn't do what was expected, we want numbers within 16 of
  the extrema.

  Change-Id : I20c18627c482ec66e8405ddad74ca9276c0c65dc