Identify an error in rm format video

[kakuilan]

    var vdo *vidio.Video
    vdo, err = vidio.NewVideo(filepath)
    if err != nil {
        return
    }

err:
no video data found in /tmp/upload/acd9bc2b5543f08633.rm

and the file exists.

[Krzysztofz01]

I would first verify that the version of FFmpeg you are using, is compiled in such a way that it supports the mentioned file format. If not, the solution may be to install/compile a different version of FFmpeg.

I am not very familiar with this file format, but while browsing forums, I noticed that people often encounter problems with this format in terms of streams. Could the problem, be that Vidio assumes that the first stream is the video stream? What do you think about it, @AlexEidt?

[kakuilan]

My version number is

$ ffmpeg   -version
ffmpeg version 3.4.13 Copyright (c) 2000-2023 the FFmpeg developers
built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-44)

$ ffprobe   -version
ffprobe version 3.4.13 Copyright (c) 2007-2023 the FFmpeg developers
built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-44)

[AlexEidt]

The error would be coming from L129 in video.go, so the issue is that the ffprobe call on the video is not returning anything when called. Try running

ffprobe -show_streams -select_streams v -print_format compact -loglevel quiet <filename>

and see what it prints out. If it doesn't print out any metadata then either that rm file does not contain any video or ffprobe can't deal with that file type.

@Krzysztofz01 vidio does not assume the first stream is a video stream. When reading the video, the -map 0:v:<n> parameter is passed in, indicating that the user wants the nth video stream, so no assumptions made there.

[kakuilan]

The error would be coming from L129 in video.go, so the issue is that the ffprobe call on the video is not returning anything when called. Try running

ffprobe -show_streams -select_streams v -print_format compact -loglevel quiet <filename>

and see what it prints out. If it doesn't print out any metadata then either that rm file does not contain any video or ffprobe can't deal with that file type.

@Krzysztofz01 vidio does not assume the first stream is a video stream. When reading the video, the -map 0:v:<n> parameter is passed in, indicating that the user wants the nth video stream, so no assumptions made there.

Thank you, I found a rm format file test, can identify. I think that's why yesterday's file only had audio and no video.

$ ffprobe -show_streams -select_streams v -print_format compact -loglevel quiet ./test.rm
stream|index=1|codec_name=rv30|codec_long_name=RealVideo 3.0|profile=unknown|codec_type=video|codec_time_base=1/25|codec_tag_string=RV30|codec_tag=0x30335652|width=320|height=240|coded_width=320|coded_height=240|has_b_frames=1|sample_aspect_ratio=0:1|display_aspect_ratio=0:1|pix_fmt=yuv420p|level=-99|color_range=unknown|color_space=unknown|color_transfer=unknown|color_primaries=unknown|chroma_location=unspecified|field_order=unknown|timecode=N/A|refs=1|id=N/A|r_frame_rate=25/1|avg_frame_rate=25/1|time_base=1/1000|start_pts=0|start_time=0.000000|duration_ts=70400|duration=70.400000|bit_rate=317958|max_bit_rate=N/A|bits_per_raw_sample=N/A|nb_frames=N/A|nb_read_frames=N/A|nb_read_packets=N/A|disposition:default=0|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:forced=0|disposition:hearing_impaired=0|disposition:visual_impaired=0|disposition:clean_effects=0|disposition:attached_pic=0|disposition:timed_thumbnails=0

[Krzysztofz01]

vidio does not assume the first stream is a video stream. When reading the video, the -map 0:v:<n> parameter is passed in, indicating that the user wants the nth video stream, so no assumptions made there.

Right, that's not what I meant. What I meant was that the NewVideo function returns the first stream containing a video, and I was thinking if maybe an error occurs as a result of that fact.