Recherche avancée

Sur d’autres sites (4038)

• FFMPEG : i need audio channels 7 & 8 to be the main audio track for a video

  10 avril 2013, par lo_fye

  I have a video with 8 channels of audio.

  I need tracks 7 (Left Stereo) and 8 (Right Stereo) to be the audio for the video (which I'm converting to flv).

  I've tried playing with -filter_complex and the join, amix, and amerge filters, as well as the -map parameter, but I can't seem to find the right combination of values :-/

  Output :

  /usr/local/bin/ffmpeg-1.0/bin/ffmpeg -i '/folder/video_name.mov' -f 'flv' \
  
  -s '320x240' -b '250k' -aspect '4:3' -ac 1 -ab '64k' -ar '22050' -y \
  
  /folder/video_name.flv
  
  
  
  ffmpeg version N-46241-g09ea482 Copyright (c) 2000-2012 the FFmpeg developers
  
    built on Nov  5 2012 07:33:09 with gcc 4.1.2 (GCC) 20080704 (Red Hat 4.1.2-46)
  
    configuration: --prefix=/usr/local/bin/ffmpeg-1.0
  
    libavutil      52.  1.100 / 52.  1.100
  
    libavcodec     54. 70.100 / 54. 70.100
  
    libavformat    54. 35.100 / 54. 35.100
  
    libavdevice    54.  3.100 / 54.  3.100
  
    libavfilter     3. 21.105 /  3. 21.105
  
    libswscale      2.  1.101 /  2.  1.101
  
    libswresample   0. 16.100 /  0. 16.100
  
  Guessed Channel Layout for  Input Stream #0.1 : mono
  
  Guessed Channel Layout for  Input Stream #0.2 : mono
  
  Guessed Channel Layout for  Input Stream #0.3 : mono
  
  Guessed Channel Layout for  Input Stream #0.4 : mono
  
  Guessed Channel Layout for  Input Stream #0.5 : mono
  
  Guessed Channel Layout for  Input Stream #0.6 : mono
  
  Guessed Channel Layout for  Input Stream #0.7 : mono
  
  Guessed Channel Layout for  Input Stream #0.8 : mono
  
  Guessed Channel Layout for  Input Stream #0.9 : mono
  
  Guessed Channel Layout for  Input Stream #0.10 : mono
  
  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/folder/video_name.mov':
  
    Metadata:
  
      major_brand     : qt
  
      minor_version   : 537199360
  
      compatible_brands: qt
  
      creation_time   : 2013-04-03 19:45:26
  
    Duration: 00:00:39.03, start: 0.000000, bitrate: 122149 kb/s
  
      Stream #0:0(eng): Video: prores (apch / 0x68637061), yuv422p10le, 1920x1080, 110585 kb/s, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 23976 tbn, 23976 tbc
  
      Metadata:
  
        creation_time   : 2013-04-03 19:45:26
  
        handler_name    : Apple Alias Data Handler
  
        timecode        : 00:59:53:00
  
      Stream #0:1(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32, 1152 kb/s
  
      Metadata:
  
        creation_time   : 2013-04-03 19:45:26
  
        handler_name    : Apple Alias Data Handler
  
      Stream #0:2(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32, 1152 kb/s
  
      Metadata:
  
        creation_time   : 2013-04-03 19:45:26
  
        handler_name    : Apple Alias Data Handler
  
      Stream #0:3(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32, 1152 kb/s
  
      Metadata:
  
        creation_time   : 2013-04-03 19:45:26
  
        handler_name    : Apple Alias Data Handler
  
      Stream #0:4(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32, 1152 kb/s
  
      Metadata:
  
        creation_time   : 2013-04-03 19:45:26
  
        handler_name    : Apple Alias Data Handler
  
      Stream #0:5(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32, 1152 kb/s
  
      Metadata:
  
        creation_time   : 2013-04-03 19:45:26
  
        handler_name    : Apple Alias Data Handler
  
      Stream #0:6(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32, 1152 kb/s
  
      Metadata:
  
        creation_time   : 2013-04-03 19:45:26
  
        handler_name    : Apple Alias Data Handler
  
      Stream #0:7(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32, 1152 kb/s
  
      Metadata:
  
        creation_time   : 2013-04-03 19:45:26
  
        handler_name    : Apple Alias Data Handler
  
      Stream #0:8(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32, 1152 kb/s
  
      Metadata:
  
        creation_time   : 2013-04-03 19:45:26
  
        handler_name    : Apple Alias Data Handler
  
      Stream #0:9(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32, 1152 kb/s
  
      Metadata:
  
        creation_time   : 2013-04-03 19:45:26
  
        handler_name    : Apple Alias Data Handler
  
      Stream #0:10(eng): Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, mono, s32, 1152 kb/s
  
      Metadata:
  
        creation_time   : 2013-04-03 19:45:26
  
        handler_name    : Apple Alias Data Handler
  
      Stream #0:11(eng): Data: none (tmcd / 0x64636D74)
  
      Metadata:
  
        creation_time   : 2013-04-03 19:45:30
  
        handler_name    : Apple Alias Data Handler
  
        timecode        : 00:59:53:00
  
  Please use -b:a or -b:v, -b is ambiguous
  
  Output #0, flv, to '/folder/video_name.flv':
  
    Metadata:
  
      major_brand     : qt
  
      minor_version   : 537199360
  
      compatible_brands: qt
  
      encoder         : Lavf54.35.100
  
      Stream #0:0(eng): Video: flv1 ([2][0][0][0] / 0x0002), yuv420p, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 250 kb/s, 1k tbn, 23.98 tbc
  
      Metadata:
  
        creation_time   : 2013-04-03 19:45:26
  
        handler_name    : Apple Alias Data Handler
  
        timecode        : 00:59:53:00
  
      Stream #0:1(eng): Audio: adpcm_swf ([1][0][0][0] / 0x0001), 22050 Hz, mono, s16, 88 kb/s
  
      Metadata:
  
        creation_time   : 2013-04-03 19:45:26
  
        handler_name    : Apple Alias Data Handler
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (prores -> flv)
  
    Stream #0:1 -> #0:1 (pcm_s24le -> adpcm_swf)
  
  Press [q] to stop, [?] for help
  
  frame=   33 fps=0.0 q=2.0 size=     108kB time=00:00:01.99 bitrate= 442.4kbits/s    
  
  frame=   66 fps= 65 q=2.0 size=     225kB time=00:00:02.97 bitrate= 619.0kbits/s    
  
  frame=   99 fps= 65 q=2.0 size=     341kB time=00:00:04.96 bitrate= 561.8kbits/s    
  
  frame=  136 fps= 67 q=2.0 size=     400kB time=00:00:05.99 bitrate= 547.5kbits/s    
  
  frame=  177 fps= 70 q=3.0 size=     482kB time=00:00:07.98 bitrate= 494.3kbits/s    
  
  frame=  210 fps= 69 q=3.7 size=     590kB time=00:00:08.96 bitrate= 539.7kbits/s    
  
  frame=  240 fps= 68 q=6.3 size=     660kB time=00:00:10.01 bitrate= 539.7kbits/s    
  
  frame=  264 fps= 65 q=6.7 size=     719kB time=00:00:11.01 bitrate= 535.2kbits/s    
  
  frame=  288 fps= 63 q=8.4 size=     772kB time=00:00:12.02 bitrate= 526.1kbits/s    
  
  frame=  312 fps= 62 q=15.4 size=     829kB time=00:00:13.65 bitrate= 497.4kbits/s    
  
  frame=  336 fps= 60 q=10.4 size=     875kB time=00:00:14.02 bitrate= 511.1kbits/s    
  
  frame=  360 fps= 59 q=10.6 size=     916kB time=00:00:15.01 bitrate= 499.9kbits/s    
  
  frame=  383 fps= 58 q=17.8 size=     957kB time=00:00:15.97 bitrate= 490.6kbits/s    
  
  frame=  411 fps= 58 q=6.5 size=    1008kB time=00:00:17.97 bitrate= 459.3kbits/s    
  
  frame=  437 fps= 57 q=9.7 size=    1046kB time=00:00:18.99 bitrate= 451.3kbits/s    
  
  frame=  460 fps= 57 q=7.7 size=    1086kB time=00:00:20.01 bitrate= 444.6kbits/s    
  
  frame=  489 fps= 57 q=11.3 size=    1144kB time=00:00:20.99 bitrate= 446.3kbits/s    
  
  frame=  512 fps= 56 q=10.3 size=    1182kB time=00:00:22.01 bitrate= 439.8kbits/s    
  
  frame=  535 fps= 55 q=21.5 size=    1225kB time=00:00:22.98 bitrate= 436.7kbits/s    
  
  frame=  564 fps= 55 q=18.3 size=    1280kB time=00:00:24.00 bitrate= 436.8kbits/s    
  
  frame=  587 fps= 55 q=8.5 size=    1311kB time=00:00:24.98 bitrate= 429.7kbits/s    
  
  frame=  610 fps= 54 q=11.9 size=    1349kB time=00:00:26.00 bitrate= 424.9kbits/s    
  
  frame=  636 fps= 54 q=7.5 size=    1383kB time=00:00:26.98 bitrate= 419.8kbits/s    
  
  frame=  659 fps= 54 q=9.6 size=    1421kB time=00:00:28.00 bitrate= 415.6kbits/s    
  
  frame=  683 fps= 54 q=20.0 size=    1471kB time=00:00:29.02 bitrate= 415.1kbits/s    
  
  frame=  711 fps= 54 q=6.4 size=    1518kB time=00:00:30.00 bitrate= 414.5kbits/s    
  
  frame=  742 fps= 54 q=6.2 size=    1558kB time=00:00:31.02 bitrate= 411.5kbits/s    
  
  frame=  774 fps= 54 q=2.5 size=    1601kB time=00:00:33.01 bitrate= 397.1kbits/s    
  
  frame=  816 fps= 55 q=2.0 size=    1632kB time=00:00:34.50 bitrate= 387.6kbits/s    
  
  frame=  861 fps= 56 q=2.0 size=    1670kB time=00:00:35.99 bitrate= 380.1kbits/s    
  
  frame=  905 fps= 57 q=2.0 size=    1706kB time=00:00:38.03 bitrate= 367.4kbits/s    
  
  frame=  936 fps= 58 q=2.0 Lsize=    1730kB time=00:00:39.05 bitrate= 362.8kbits/s
  
  video:1278kB audio:423kB subtitle:0 global headers:0kB muxing overhead 1.654557%

• FFmpeg priv_data for RTSP stream timing info

  9 septembre 2019, par m00ncake

  I am trying to get RTSP stream’s timing information using FFmpeg’s priv_data. I found two hacks to try obtaining the timestamps from priv_data, however, I am a bit unsure where to edit.

  AVPacket* packet;
  
  av_read_frame(formatCtx, packet);
  
  RTSPState* rtspState = formatCtx->priv_data; 
  
  RTPDemuxContext *rtpdemux = rtspState->rtsp_streams[packet->stream_index]->transport_priv;

  and

  RTSPState *state = _formatCtx->priv_data; 
  
  RTSPStream *stream = state->rtsp_streams[0]; 
  
  RTPDemuxContext *demux = stream->transport_priv; 
  
  demux→timestamp

  Should I write a new function to output the priv_data ? or rather edit rtpdec.c or rtsp.c to accommodate it ? From the looks of these two code snippets, it has something to do with AVFormatContext. Just a bit uncertain how I should tackle this problem.

• lavc/ffv1 : change FFV1SliceContext.plane into a RefStruct object

  11 juillet 2024, par Anton Khirnov

  lavc/ffv1 : change FFV1SliceContext.plane into a RefStruct object
  Frame threading in the FFV1 decoder works in a very unusual way - the
  
  state that needs to be propagated from the previous frame is not decoded
  
  pixels(¹), but each slice's entropy coder state after decoding the slice.
  For that purpose, the decoder's update_thread_context() callback stores
  
  a pointer to the previous frame thread's private data. Then, when
  
  decoding each slice, the frame thread uses the standard progress
  
  mechanism to wait for the corresponding slice in the previous frame to
  
  be completed, then copies the entropy coder state from the
  
  previously-stored pointer.
  This approach is highly dubious, as update_thread_context() should be
  
  the only point where frame-thread contexts come into direct contact.
  
  There are no guarantees that the stored pointer will be valid at all, or
  
  will contain any particular data after update_thread_context() finishes.
  More specifically, this code can break due to the fact that keyframes
  
  reset entropy coder state and thus do not need to wait for the previous
  
  frame. As an example, consider a decoder process with 2 frame threads -
  
  thread 0 with its context 0, and thread 1 with context 1 - decoding a
  
  previous frame P, current frame F, followed by a keyframe K. Then
  
  consider concurrent execution consistent with the following sequence of
  
  events :
  
  * thread 0 starts decoding P
  
  * thread 0 reads P's slice header, then calls
  
    ff_thread_finish_setup() allowing next frame thread to start
  
  * main thread calls update_thread_context() to transfer state from
  
    context 0 to context 1 ; context 1 stores a pointer to context 0's private
  
    data
  
  * thread 1 starts decoding F
  
  * thread 1 reads F's slice header, then calls
  
    ff_thread_finish_setup() allowing the next frame thread to start
  
    decoding
  
  * thread 0 finishes decoding P
  
  * thread 0 starts decoding K ; since K is a keyframe, it does not
  
    wait for F and reallocates the arrays holding entropy coder state
  
  * thread 0 finishes decoding K
  
  * thread 1 reads entropy coder state from its stored pointer to context
  
    0, however it finds state from K rather than from P
  This execution is currently prevented by special-casing FFV1 in the
  
  generic frame threading code, however that is supremely ugly. It also
  
  involves unnecessary copies of the state arrays, when in fact they can
  
  only be used by one thread at a time.
  This commit addresses these deficiencies by changing the array of
  
  PlaneContext (each of which contains the allocated state arrays)
  
  embedded in FFV1SliceContext into a RefStruct object. This object can
  
  then be propagated across frame threads in standard manner. Since the
  
  code structure guarantees only one thread accesses it at a time, no
  
  copies are necessary. It is also re-created for keyframes, solving the
  
  above issue cleanly.
  Special-casing of FFV1 in the generic frame threading code will be
  
  removed in a later commit.
  (¹) except in the case of a damaged slice, when previous frame's pixels
  
      are used directly
  

  • [DH] libavcodec/ffv1.c
  • [DH] libavcodec/ffv1.h
  • [DH] libavcodec/ffv1dec.c