Recherche avancée

Sur d’autres sites (10125)

• How to put QUdp packets into AVPacket/FFmpeg

  11 juin 2014, par user2772673

  I want to write a application that had to receive udp packets by QT UdpSocket, packets consists metadata and video.

  Video data is the same as from ffmpeg udp stream.

  I divided this packets and selected video data, now I want to put this video data into AVpacket, decode it and display in window.

  So I have Qbytearray from udp socket and don’t know how to convert it to AVpacket.
  (when I write this Qbytearray to file I have proper video file so data is good)

  procFrame is called every time I get a UDP packet. In constructor I have codec initialization and other init stuff.
  Cdatagrams contains one frame of video ( key frame or differential frame). Codec is mpeg2

      void myThread::procFrame()
  
      {
  
          findex++;
  
          if(av_read_frame(pFormatCtx,&packet)<0)///now pFormatCtx pointing to file on disk
  
              qDebug()<<"avreadframe failed";
  
  
  
          Spacket.data = new uint8_t[Cdatagrams.size()];///Spacket is empty packet that I want to fill by Qbytearray Cdatagrams 
  
  
  
          memcpy(Spacket.data,Cdatagrams.data_ptr(),Cdatagrams.size());////here is the problem
  
  
  
          int framecount;
  
          int frameFinished;
  
  
  
          avcodec_decode_video2(pCodecCtx,pFrame,&frameFinished,&Spacket);
  
              qDebug()<<  "framefinished " </ Write pixel data
  
              for(y=0; ydata[0]+y*pFramew->linesize[0], width*3);
  
  
  
              emit frameReady(img);
  
          }
  
  
  
      }

  In this version I have frameFinished==0 so Spacket isn’t properly prepared

• avformat/mpegtsenc : Changed Video PES packet length to 0.

  12 avril 2014, par Graham Booker

  avformat/mpegtsenc : Changed Video PES packet length to 0.
  The rational for this is another issue that plex has exposed.  When it is
  
  conducting a transcode of video to HLS for streaming, my father noticed
  
  artifacts when played on his GoogleTV (NSZ-GT1).  He sent me a test file
  
  and I reproduced it on my device of the same model.  It is important to
  
  note that the artifacts were not present when streaming to VLC or QuickTime
  
  Player.  I copied the command-line that plex used, and conducted all of the
  
  following tests using FFmpeg git.
  Transcode to HLS : artifacts on playback
  
  Transcode to TS : playback is fine
  
  Cat HLS segments into a single TS : playback is fine
  
  Segment single TS file to segments : artifacts on playback
  
  Segment single TS file to segments using Apple’s HLS segmenter : playback is
  
  fine
  At this point I carefully examined the differences between Apple’s HLS
  
  segmenter output and FFmpeg’s.  Among the considerable differences, I
  
  noticed that the video PES packets always had a 0 length.  So I continued :
  Transcode to HLS using FFmpeg with 0 length PES packets : playback is fine.
  
  Segment single TS to segments with 0 length PES packets : playback is fine.
  All failures mentioned are only on the GTV since it is the only player on
  
  which I could reproduce artifacts.  I only tested the GTV, VLC, and
  
  QuickTime Player though, so my test case is limited.  I do not know if
  
  other players exhibit this issue.
  Since it was useful last time, I have uploaded the test file as
  
  hls_pes_packet_length.m4v along with its associated txt file which contains
  
  the transcode command-line that was used.
  Reviewed-by : Kieran Kunhya <kierank@obe.tv>
  
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavformat/mpegtsenc.c
  • [DH] tests/ref/lavf/ts

• Revision 5182befa49 : ads2armasm_ms : Add an ALIGN 4 after ENDP This makes sure that labels for data s

  19 mars 2014, par Martin Storsjo

  Changed Paths :
   Modify /build/make/ads2armasm_ms.pl

  
  
  ads2armasm_ms : Add an ALIGN 4 after ENDP

  This makes sure that labels for data symbols directly after
  functions get properly 4-byte-aligned (when the source is assembled
  in thumb mode).

  Previously, if declaring a data symbol directly after a function, the
  symbol could end up pointing to the unaligned address (if the total
  size of the thumb function didn't end up being a multiple of 4). The
  data in the symbol itself ended up aligned, but the symbol pointed to
  the preceding unaligned position.

  That is, a source file looking like this :
  — -
  ...
  ENDP

  symbol
  DCD 0x12345678
  — -

  could end up being assembled into
  symbol :
  xxxxx2 : 0000
  xxxxx4 : 5678
  xxxxx6 : 1234

  (This doesn't happen if the symbol label is on the same line as the
  DCD directive.)

  By adding an ALIGN 4 directly after the ENDP we make sure the symbol
  itself gets aligned properly.

  This isn't an issue with the original, untranslated arm source,
  since it only is built in arm mode where all instructions are 4 byte,
  and since the gnu assembler automatically adds the padding before the
  symbol even in thumb mode.

  Change-Id : Iadbeebd656b0197e423e79a12a7d3ef8859cf445