Recherche avancée

Sur d’autres sites (4848)

• FFmpeg on android is crashing in ff_h2645_extract_rbsp function

  6 décembre 2019, par TheWindLaugh

  I have used ffmpeg decode in my decode2 function, it just like this :

  AVPacket pkt;
  
  av_init_packet(&pkt);
  
  pkt.data = (uint8*)vd+16;
  
  pkt.size = vl-16;
  
  m_is_decoding = true;
  
  avcodec_send_packet(m_cctx, &pkt);
  
  int ret = avcodec_receive_frame(m_cctx, m_cfrm);

  Everything works great up until the avcodec_decode_video2 call :

  Build fingerprint: 'HUAWEI/VTR-AL00/HWVTR:9/HUAWEIVTR-AL00/9.1.0.201C00:user/release-keys'
  
  Revision: '0'
  
  cpuAbi/cpuAbi2: 'arm64-v8a#armeabi-v7a#armeabi'
  
  pid: 5829, tid: 6106, name: .myapp.online  >>> com.myapp.online <<<
  
  signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xcc180000
  
  
  
  backtrace:
  
       #00 pc 0064c098  /data/app/com.myapp.online-r3eLwyIHdUEbHPM-MUYw1g==/lib/arm/libapp.so (ff_h2645_extract_rbsp+52)
  
       #01 pc 0064c580  /data/app/com.myapp.online-r3eLwyIHdUEbHPM-MUYw1g==/lib/arm/libapp.so (ff_h2645_packet_split+592)
  
       #02 pc 0037c9e0  /data/app/com.myapp.online-r3eLwyIHdUEbHPM-MUYw1g==/lib/arm/libapp.so
  
       #03 pc 004e6d18  /data/app/com.myapp.online-r3eLwyIHdUEbHPM-MUYw1g==/lib/arm/libapp.so (avcodec_decode_video2+380)
  
       #04 pc 004e76a4  /data/app/com.myapp.online-r3eLwyIHdUEbHPM-MUYw1g==/lib/arm/libapp.so
  
       #05 pc 004eb344  /data/app/com.myapp.online-r3eLwyIHdUEbHPM-MUYw1g==/lib/arm/libapp.so (avcodec_send_packet+308)
  
       #06 pc 001df578  /data/app/com.myapp.online-r3eLwyIHdUEbHPM-MUYw1g==/lib/arm/libapp.so (_bio_binder_codec_video_::decode2(void*, yuv_r*, void const*, int)+1384)
  
       #07 pc 002e66b8  /data/app/com.myapp.online-r3eLwyIHdUEbHPM-MUYw1g==/lib/arm/libapp.so (hm_video_decode_yuv+244)
  
       #08 pc 0003f598  /data/app/com.myapp.online-r3eLwyIHdUEbHPM-MUYw1g==/lib/arm/libapp_yunguan.so (Device::DecodeVideo()+336)
  
       #09 pc 00037324  /data/app/com.myapp.online-r3eLwyIHdUEbHPM-MUYw1g==/lib/arm/libapp_yunguan.so (boost::detail::thread_data, boost::_bi::list1 > > >::run()+32)
  
       #10 pc 00046455  /data/app/com.myapp.online-r3eLwyIHdUEbHPM-MUYw1g==/lib/arm/libapp_yunguan.so
  
       #11 pc 00065ac7  /system/lib/libc.so (__pthread_start(void*)+22)
  
       #12 pc 0001e9ad  /system/lib/libc.so (__start_thread+32)

• youtube-dll won't download live stream

  26 juillet 2020, par NFC

  I'm trying to download a livestream in ubuntu 14 using youtube-dl but it will not download. I'm using the latest version of youtube-dl. Using Nasa channel as an example, here are the steps that I'm following

  


  1) youtube-dl —list-formats https://www.youtube.com/watch?v=21X5lGlDOfg

  


  2) youtube-dl -f https://www.youtube.com/watch?v=21X5lGlDOfg (also tried youtube-dl )

  


  The download hangs at roughly 512kb for hours. Is anyone able to successfully download the content ? Am I doing anything wrong ?

  


• avutil/threadmessage : split the pthread condition in two

  1er décembre 2015, par Clément Bœsch

  avutil/threadmessage : split the pthread condition in two
  Fix a dead lock under certain conditions. Let’s assume we have a queue of 1
  
  message max, 2 senders, and 1 receiver.
  Scenario (real record obtained with debug added) :
  
      [...]
  
      SENDER #0 : acquired lock
  
      SENDER #0 : queue is full, wait
  
      SENDER #1 : acquired lock
  
      SENDER #1 : queue is full, wait
  
      RECEIVER : acquired lock
  
      RECEIVER : reading a msg from the queue
  
      RECEIVER : signal the cond
  
      RECEIVER : acquired lock
  
      RECEIVER : queue is empty, wait
  
      SENDER #0 : writing a msg the queue
  
      SENDER #0 : signal the cond
  
      SENDER #0 : acquired lock
  
      SENDER #0 : queue is full, wait
  
      SENDER #1 : queue is full, wait
  Translated :
  
   - initially the queue contains 1/1 message with 2 senders blocking on
  
     it, waiting to push another message.
  
   - Meanwhile the receiver is obtaining the lock, read the message,
  
     signal & release the lock. For some reason it is able to acquire the
  
     lock again before the signal wakes up one of the sender. Since it
  
     just emptied the queue, the reader waits for the queue to fill up
  
     again.
  
   - The signal finally reaches one of the sender, which writes a message
  
     and then signal the condition. Unfortunately, instead of waking up
  
     the reader, it actually wakes up the other worker (signal = notify
  
     the condition just for 1 waiter), who can’t push another message in
  
     the queue because it’s full.
  
   - Meanwhile, the receiver is still waiting. Deadlock.
  This scenario can be triggered with for example :
  
      tests/api/api-threadmessage-test 1 2 100 100 1 1000 1000
  One working solution is to make av_thread_message_queue_send,recv()
  
  call pthread_cond_broadcast() instead of pthread_cond_signal() so both
  
  senders and receivers are unlocked when work is done (be it reading or
  
  writing).
  This second solution replaces the condition with two : one to notify the
  
  senders, and one to notify the receivers. This prevents senders from
  
  notifying other senders instead of a reader, and the other way around.
  
  It also avoid broadcasting to everyone like the first solution, and is,
  
  as a result in theory more optimized.
  

  • [DH] libavutil/threadmessage.c