[FFmpeg-devel] debuggin ffmpeg

[Wolfgang Haupt]

On 02/18/2014 03:19 PM, Maxim Polijakowski wrote:
> Am 18.02.2014 14:05, schrieb Wolfgang Haupt:
>>
>> On 02/18/2014 01:37 PM, Maxim Polijakowski wrote:
>>> Am 18.02.2014 11:41, schrieb Wolfgang Haupt:
>>>> Hi ffmpeg-devs,
>>>>
>>>> I'm quite new to ffmpeg just trying to figure out how the mpegts 
>>>> demuxer works in detail.
>>>> Therefore I started debugging into ffprobe (-show_frames).
>>>> However I wonder how you guys do debugging because every second 
>>>> variable is optimized out.
>>>> I guess optimizing is rather important in ffmpeg, so I'd like to 
>>>> ask if it's safe to disable optimizing for debug builds?
>>>
>>> I debug the ffmpeg executable quite often. Below the description of 
>>> how I do that:
>>>
>>> 1) obtain the debug build by running
>>>
>>> cd [path/to/your/ffmpeg/local/clone]
>>> ./configure --enable-debug=3 --disable-optimizations 
>>> --disable-inline-asm
>>> make
>>>
>>> 2) fire up GDB and type in the following commands:
>>>
>>> gdb [path/to/ffmpeg/executable]
>>> set args -i [path/to/input/file] test.avi [or some other output file 
>>> or null]
>>> break libavformat/mpegts.c:135 [or some other line]
>>> run
>>>
>>> Surely, you can do the same with ffprobe and use another debugger...
>>>
>>> Best regards
>>> Maxim
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>>
>>
>> Thx all for your hints, I use gdb in exact the way you stated.
>> It's just the configure parameters I wasn't sure about, because I 
>> once tried debugging on an ARM device with compiled NEON and a dev 
>> told me to better not disable optimizations there.
>> I guess ARM NEON is a very special case and I'm working on x64_64 
>> right now.
>> That's basically why I wanted to ask here, how ffmpeg devs do debugging.
>
> Yes, I understand your interest. Debugging multimedia applications is 
> not a trivial task due to huge amount of data being transfered back 
> and forth. Therefore, one need to exactly know what to search for 
> before starting to debug.
>
> I use several debugging approaches when dealing with codecs or formats:
> --> write special purpose verbose functions using "av_log", 
> "av_hex_dump", "av_pkt_dump" etc. in order to print out relevant 
> information
> --> utilize various hash and checksum algorithms for comparing big 
> data chunks
> --> write special purpose GDB scripts for dumping internals of binary 
> executables if their source code isn't available
> --> use scriptable emulators when working with executables for 
> platforms other than x86/x64_64
>
> A common example of such an approach would be debugging a particular 
> video frame. Neither ffmpeg nor GDB will stop automatically anywhere 
> you want. You need to either
> rewind to the desired frame manually or do smth like that:
>
> if (avctx->frame_number == 1333)
>     av_log(avctx, AV_LOG_ERROR, "Stopping at frame: %d\n", 
> avctx->frame_number);
>
> Add this to the "xxx_decode_frame" method of your demuxer or decoder, 
> recompile the project, fire up your debugger, set the break point at 
> the 2nd line of the above mentioned code and you will fall into the 
> debugger as far the desired frame has been reached...
>
> Best regards
> maxim
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>

Awesome. Thanks for clarifying your approaches, that's really helpful as
I think debugging is one of the most challenging tasks out there.